Компьютерные игры. Как это делается

       

Техника - это еще не все


Не следует думать, что вы сделаете все самостоятельно только потому, что можете писать программы с бешеной скоростью, по 1000 строк в день, и любите игры. Написать компьютерную игру - это все равно, что рассказать историю, - и хотя самого «рассказчика» создают программисты, без хорошего сюжета для рассказа не обойтись. Яркое художественное оформление, захватывающий сюжет, надежный движок, качественные режимы многопользовательской игры, не говоря уже о вдохновляющей музыке, - для хорошей игры требуется многое. И чтобы, взявшись за проект, довести его до конца, вам необходимо вникнуть во все эти детали, или хотя бы уверенно в них ориентироваться.

А чтобы постичь все тонкости представления различных элементов игры, вам необходимо понять их реализацию в среде, которую вы используете для того, чтобы рассказать историю. Однобитный графический поток позволяет получить замечательную частоту кадров, однако я сомневаюсь, что кто-нибудь по достоинству оценит визуальные эффекты вашей игры, решись вы использовать подобное программное ядро. Отчасти понимание того, что значит правильно рассказать хорошую историю, приходит с опытом - обычно возрастающим, если вы не ленитесь играть в чужие игры.

Наконец, необходимо уметь работать с людьми, которые помогают вам (как любой член команды, создающей игру) рассказывать эти истории. Вам необходимо иметь хорошие инструменты, необходимо научить остальных всему, что они должны знать, чтобы работать с вашей технологией, а прежде всего вам необходимо иметь терпение и решительность для того, чтобы выполнить все вышеперечисленное. И сохранять их до конца.

В нашей индустрии нет места для начальников-наполеонов, а также людей с высокомерным или замкнутым характером. Само собой, подобные типы появляются время от времени, но их игра находит свое последнее пристанище на полке для уцененных товаров (там же, к сожалению, заканчивается их карьера, а также карьера тех, кто с ними работал)... или, еще хуже, игра вообще не выходит на рынок. Если вы вдруг почувствуете, что работаете на кого-то, а не с кем-то, немедленно уходите, потому что в «смертельной схватке» на поле боя, именуемом «рынок игр», вы - на проигрывающей стороне.


Майкл Макграт поясняет свои советы на примере игры Red Baron II компании Dynamix и проблем, так замучивших ее программистов.

Скриншоты из игры Red Baron 3D. Первый - подвижные контрольные плоскости указывают на маневр противника. Второй - новые варианты облачности и эффекты наложения слоев, создающие ощущение неба, полного опасностей. (Использовано с разрешения компании Dynamix.)




Red Baron II - типичный пример избытка технических переделок и недостатка предвидения в процессе разработки. В Red Baron 3D большая часть программистской работы состояла в вылавливании ошибок и попытках разобраться в коде, чтобы мы могли добавить в игру новые возможности и технологии. Когда началась переработка Red Baron 3D, создававшие игру инженеры или уже покинули Dynamix, или перешли в другие проекты. Код был плохо документирован, из-за чего мы столкнулись с нескончаемыми трудностями, связанными с его переработкой, и не было никого, кто мог бы помочь в нем разобраться. Переделать игру было бы гораздо проще (я уверен, что первоначальной команде это было по силам), если бы программа была хорошо структурирована. Но код, будучи плодом труда многих и многих людей, которые совсем не заботились о том, чтобы снабдить его хоть сколько-нибудь приличным описанием, был ужасающе загадочен. В дополнение к этому, в тех местах, где проект все-таки был хорошо продуман, код был сверхабстрактен и сверхтехничен.

Игре Red Baron II очень не повезло. Изначально разработанная под DOS, позже она переделывалась сначала под Windows 95, потом под DirectX и, наконец, под 3D-платы. В итоге код игры перекраивался столько раз, что под конец стал невообразимо громоздким. Основная проблема заключалась не в самой реконструкции, а скорее в том, что технология привела, как оказалось, к «переоценке» возможностей повторного использования кода и нарушению модульности. Вырезая некоторые части, приходилось сохранять остальные, склеивая их кое-как. В результате программу стало очень трудно читать и понимать. Если бы код с самого начала был хорошо продуман и выстроен по модульному принципу, то игра могла быть завершена гораздо быстрее, независимо от преимуществ технологии, которые вдохновляли на внесение изменений.


Не следует понимать это утверждение в том смысле, что «нужно было использовать Си++». Мы пользовались этим языком. Однако объектно-ориентированное программирование со всеми его достоинствами может стать настоящим кошмаром при злоупотреблении плохо продуманным проектом и применением техники «заплаток». Никогда не позволяйте «завораживающим» возможностям языков программирования убедить вас, что соблюдение принципа «бритвы Оккама» и удобочитаемость программы уже не существенны. Никогда.

Уильям Оккам, философ, живший в 13-14 веках, вывел закон экономии, известный сегодня как «бритва Оккама». Вот его формулировка: следует отказываться от понятий, не являющихся необходимыми.

В дополнение к общению с другими специалистами через Usenet и посещению различных конференций Майкл Макграт предлагает несколько полезных книг, на которые стоит обратить внимание желающим заняться программированием игр:

• Computer Graphics: Principles and Practice, Second Edition in С. Авторы Foley, van Dam, Feinern Hughes (Addison-Wesley, 1996)

• Руководство по программированию («красная книга») и справочник OpenGL («синяя книга»)

• Серия The Graphics Gems, под редакцией Andrew S. Glassner, James Arvo, David Kirk, Alan W. Paeth и Paul S. Heckbert (Academic Press и АР Professional, 1993-1995)

• Artificial Intelligence. Автор Patrick Henry Winston (Addison-Wesley, 1992)

В настоящее время Майкл Макграт занят написанием программного кода для игр Desert Fighters и Aces of the Pacific II, а в его планах на будущее - переписать Netrek и возобновить участие в создании научно-фантастических боевых летных симуляторов и стратегических игр.

Аллен Джексон (Allen Jackson), Origin Systems

Аллен Джексон работал в компании Origin в течение ряда лет, и ему посчастливилось принимать участие в создании многих экшен-игр и космических симуляторов, отмеченных разнообразными наградами. В их числе: Crusader: No Remorse, Crusader: No Regret, Wing Commander Prophecy и Wing Commander Prophecy: Secret Ops. В первую очередь Аллен имеет дело с игровым кодом высокого уровня, а именно с разработкой интерфейса, приложениями Win32 GUI, объектами, определяемыми в игре, и сетевыми вопросами.

В данном разделе Аллен Джексон делится тремя советами по написанию кода для игр, ссылаясь при этом на свои последние работы, на практике подтверждающие предлагаемые рекомендации.


Содержание раздела