Какой путь выбрать, кратчайший или оптимальный?
Программисты - люди в большинстве своем ленивые. Это так, и ничего с этим не поделаешь. Не верьте, если кто-то попытается убедить вас в обратном. Не замечали, мы почти инстинктивно пытаемся воспользоваться самой короткой дорогой из пункта «А» в пункт «Б»? Порой кратчайший путь - это единственное, что мы видим, приступая к выполнению задачи. Зачем я все это говорю? Так и быть, раскрою вам один маленький секрет. Кратчайший путь далеко не всегда лучший. Как ни жаль, но это правда. Чем больше вы, разработчик, руководитель проекта, понимаете в программировании, тем чаще сможете подходить к своему программисту и говорить: «Слушай, то, что ты тут сотворил, - это, конечно, здорово, но какого черта ты не сделал так-то и так-то? Я ведь именно этого хотел!» Еще лучше, если вы, уважаемый разработчик, действительно знаете, что хотите получить, и зададите конкретный способ реализации с самого начала.
Возможно, у вас появится искушение спросить нас, программистов: если вы знаете, что короткий путь не всегда лучший, то почему не обращаете внимание на действительно лучший путь? Отвечаю: только потому, что лучший путь не всегда является кратчайшим. Вообще-то, это не так уж и плохо, что большинство программистов рассуждают именно так, поскольку это означает, что работа будет сделана вовремя. Если бы при создании программного кода мы стремились к полному совершенству, то проект отнимал бы в три раза больше времени, и при этом он содержал бы только треть планировавшихся деталей. А ведь может быть и того хуже, как с игрой Trespasser, мы закончили ее с перерасходом бюджета и серьезным опозданием, игра просто блистала с технологической точки зрения, но была совсем неинтересной.
| Справа показан пререндеренный (предварительно прорисованный) кадр из популярной игры Interstate '76 компании Activision. (Использовано с разрешения компании Activision, Inc.) Снизу - последняя работа Курта Арнлунда, игра Slave Zero компании Accolade. (Использовано с разрешения компании Accolade, Inc.) |  |
|
 |
Мне повезло, поскольку мой друг, пытавшийся найти такую же работу, рассказал обо мне агенту по найму...
«Многие начинали с тестирования игр, а со временем становились разработчиками или продюсерами. Главное - упорно идти к намеченной цели, и все получится», - заключает Курт Арнлунд.
Джей Стелли (Jay Stelly), Valve Software
Джей Стелли - старший инженер-программист Valve Software, талантливейшей команды дизайнеров, программистов, художников, аниматоров и звукорежиссеров, создавших Half-Life, одну из самых нашумевших игр 1998 года. Последняя на сегодня работа Джея - сетевая игра Team Fortress 2, выпущенная Valve и Sierra Studios.
Когда Джея попросили осветить те аспекты программирования игр, которые прежде всего будут полезны и важны для инженеров-программистов, он обрисовал общую ситуацию, уделив особое внимание вопросам скорости вывода изображения на экран и ограничения памяти, возникающих при включении в игру поддержки 3D-ускорителей. Все его примеры касаются движка Half-Life, построенного на технологии Quake/Quake II, которая первоначально была приобретена Valve у id Software, а затем в значительной мере переработана.
Программному ядру любой игры всегда присущи определенные технические ограничения. Некоторые из них, вроде предполагаемой платформы (процессор, объем ОЗУ, место на жестком диске и т.д.) и требуемых ею технических характеристик (скорость вывода графики, время загрузки и т.д.), вы можете определить сами, другие же обусловливаются оборудованием, которым располагает ваша аудитория. Конечно же, сделанный выбор будет иметь определенные последствия. Рассмотрим конкретный пример.
Half-Life поддерживает 3D-ускорители. Благодаря этому пользователи, располагающие соответствующей техникой, получили лучшее качество изображения и более высокую частоту кадров. Казалось бы, все просто, верно? Однако нам пришлось слегка попотеть...
Самая большая проблема состояла в том, что многие из представленных на рынке 3D-ускорителей располагали лишь 2 мегабайтами памяти для хранения текстур.
Дело усугубляло то, что для большинства ускорителей затраты на подкачку новых текстур взамен старых были достаточно высоки, поэтому применение более 2 Мбайт памяти значительно снижало частоту кадров. Для Half-Life это означало, что каждая отдельная сцена в игре должна была использовать не более 2 Мбайт отображаемых текстур.
Программирование дает возможность снять некоторые из вышеперечисленных вопросов. Однако время, отведенное для написания программ, строго ограничено. Хороший инженер в состоянии оценить сложность проблемы и выбрать правильный подход к ее решению. Многие из принимаемых при создании игры решений диктуются необходимостью найти компромисс между различными техническими ограничениями. Именно так было и с Half-Life.
Уже на ранних этапах разработки в Valve осознали, что управление памятью текстур в случае 3D-плат выливается в серьезную проблему, главной причиной которой является 2-мегабайтное ограничение текстур на каждую сцену. Собственную текстуру имела не только окружающая обстановка, но и каждый персонаж, а также любой вид оружия, которым персонаж обладал. Задние планы вне помещений были полностью составлены из больших текстур. Кроме того, движок был разработан таким образом, что львиная часть данных по эффектам освещения в игре также хранилась в виде текстур. Воленс-ноленс, но нам пришлось тратить время, отведенное под программирование, на решение данного вопроса. Иначе б нам просто не хватило текстур для получения того качества изображения, к которому мы стремились! Фактически проблема оказалась значительно более серьезной, нежели простое ограничение в 2 Мбайт для некоторых плат. Выяснилось, что почти все 3D-платы, существовавшие на рынке на момент выпуска Half-Life, показывали разительное отличие в производительности в зависимости от объема памяти, используемой под текстуры, и того факта, складывается ли ваше изображение из текстур, чьи размеры являются степенью двойки.
| Джей Стелли: «Инженер-ас, в отличие от заурядного инженера, видит вопрос в комплексе, целиком, что позволяет быстро локализовать важные проблемы и потратить время, отведенное под программирование, на их решение». (Приводится с разрешения компании Sierra Studios.) |  |
В конце концов, мы создали набор приемов, которые позволили Half-Life использовать больший объем текстур и при этом эффективно работать с 2-мегабайтными 3D-платами. Художники переработали текстуру персонажей и элементов интерфейса, комбинируя несколько текстур в одну карту с размером, кратным степени двойки. Программисты добавили в ядро игры подсистему для управления палитрой текстур, которая позволила хранить большее количество текстур в том же объеме памяти, а также изменили части прорисовки, дабы по возможности рисовать все полигоны с одинаковой текстурой за один раз (с целью минимизации подкачки текстур). Ну а платы с недостатком памяти получили возможность автоматически упрощать текстуру (что, конечно, ухудшает качество изображения, но улучшает динамику).
Другое качество, отличающее хорошего инженера от посредственного, - способность правильно определить время на решение конкретной задачи. На нашу проблему можно было затратить как значительно больше, так и значительно меньше времени. Очень важно выбрать верные критерии оценки вариантов решения. За балансом времени, выделенного на программирование, необходимо следить в течение всего процесса создания игры. Не забывайте о приоритетах, ведь хорошие инженеры могут улучшить абсолютно любой фрагмент технологии, поработав над ним.
Я считаю, что правильная постановка задачи и верная оценка решений - два очень важных момента, которые выделяют Half-Life на фоне других игр.
Теперь о преимуществах и недостатках использования лицензионного движка. Стоит ли начинающему программисту пытаться создать движок самостоятельно? Джей Стелли считает, что принять в данном случае верное решение очень сложно, и важно знать, как ведется разработка.
Над созданием лучших 3D-движков трудятся коллективы опытных программистов, многие из которых заняты этим не первый год. Следовательно, результат представляет собой плод многолетних нелегких изысканий в данной области. Впрочем, даже те игры, которые не могут похвастаться движками уровня Quake III или Unreal Tournament, способны предъявить вам свидетельства того, что над их программным ядром трудились настоящие профессионалы.
Иначе говоря, создание собственного движка, как правило, требует привлечения целой команды высококвалифицированных программистов, но нередко это выходит дешевле, чем покупка лицензии на готовый движок. Однако существуют определенные моменты, из-за которых использование лицензионных продуктов может оказаться предпочтительным, несмотря на увеличение затрат.
Во-первых, эти движки уже были в деле, а значит, они более надежны. Вы покупаете не только технологию, но и время, которое было затрачено на ее разработку и тестирование. Во-вторых, у ваших инженеров отныне есть время на построение собственно игры или поиск решений для преодоления технических ограничений купленного движка. В-третьих, использование лицензионным движков предоставляет преимущества в области маркетинга и найма. Покупатели, имевшие дело с играми на данном движке, априорно благосклонны к вашему проекту. Наконец, велика вероятность привлечения в команду специалистов, уже знакомых тонкостями заложенной в движке технологии. Не упускайте из виду и вполне очевидную возможность быстро создать работающий прототип игры.
В Интернете можно найти целый ряд ресурсов, полезных для программистов игр. Ниже приведен краткий список сайтов, заслуживающих наибольшего внимания. (Веб-сайты, посвященные разработке игр, перечислены в главе 24.)
• Game Programming MegaSite www.perplexed.com/GPMega
• Visual Basic Explorer www.vbexplorer.com
• Game Programming Galaxy www.geocities.com/SiliconValley/Vista/6774/
• Game Programming '99 www.gameprog.com
• New Game Programmer's Guild http://pages.vossnet.de/mgricken/newgpg/
• Amit's Game Programming Information http://www-cs-students.stanford.edu/-amitp/gameprog.html
• GameProgrammer.com www.gameprogrammer.com
• Viper's C/C++ Page www.europa.com/-viper
• rec.games.programmer (группа новостей)
Чарльз Гоу (Charles Gough), Bungle Software
Чарльз «Чаки» Гоу начал программировать в девять лет, когда отец показал ему основные команды Applesoft Basic на стареньком Apple IIe.
Чаки не имел никакого отношения к прославленной стратегии Myth II: Soulblighter, выпущенной Bungle Software, зато в очень скором временя игроки получат возможность увидеть его работу в игре, которая «весной 2000 года ураганом распространится по планете и продвинет Bungie еще дальше по дороге мирового господства».
Чаки делится своими мыслями с начинающими программистами.
1. Как можно скорее создайте работающую версию игры. Чем раньше будут готовы движок и основные элементы, тем больше останется времени на проверку и шлифовку самой игры. Кроме того, и вашей команде, и издателям будет легче проникнуться, вашим видением игры, если они смогут ознакомиться с работающим прототипом.
2. Чтобы достичь цели, вы должны быть готовы на компромиссы в отношении собственного программного кода. Предположим, у вас появилась идея великолепного, совершенно уникального алгоритма прорисовки. Одна беда - он медленно работает, а значит - отвлекает от игры, отнимая время на свою доводку. Результат: вы теряете издателя. Комментарии излишни...
«Памятка разработчика» от Чаки:
Игра должна быть интересной. Например, если вы создаете РПГ, можно, конечно, отразить в ней всю правду жизни и заставить виртуальных персонажей есть, спать и ходить по нужде. Но кому это нужно? Если ваш герой умрет от запора, потому что вы не следили за счетчиком дерьма, это может показаться забавным, но только поначалу, потом все эти штучки наскучат. Вывод: стремление сделать игру интересной должно стать основным приоритетом. Новейшие и самые лучшие технологии не спасут, если игра окажется скучной.
Есть ли у Bungie примеры, подтверждающие данный совет?
Серия Myth! Блестящий пример применения этих правил к жанру, который за все предыдущее время претерпел лишь минимальные изменения. До Myth все стратегии в реальном времени обязательно содержали достаточно длинный период возведения построек, и только после этого начиналось сражение, на которое вы не могли оказать никакого влияния, кроме как изменяя число и рода войск, вовлеченных в драку.
Так вот, команда, работавшая над Myth, увидела огромный потенциал в собственно битвах, сделав основной упор на тактику сражения. Лучше всех имевший представление о том, как это должно выглядеть, Джейсон Джонс (Jason Jones) написал простую демонстрационную программу, состоящую из крошечной 3D-карты, гнома-гренадера, отряда нежити, вооруженного топорами, и базового движка, отражающего законы физики. Поначалу он планировал использовать полигональные 3D-модели персонажей и объектов, но вскоре понял, что, во-первых, это резко снизит частоту кадров, а во-вторых, на разработку движка уйдет слишком много времени. Тогда Джейсон изменил спрайтовый код из игры Marathon и использовал его для быстрого создания демо-версии. И что вы думаете? Такого простого начала хватило, чтобы попасть на обложку журнала Computer Game Strategy Plus...
Необходимость компромисса (между сроками, бюджетом, самой игрой и используемыми технологиями) - лейтмотив данной главы. Пришлось ли при создании Myth II: Soulblighter столкнуться с обычными трудностями, возникающими при написании любой игры?
Главная проблема состояла в том, что игру нужно было выпустить меньше, чем через год после выхода первой части. Естественно, ребятам хотелось «изменить, улучшить, добавить», но очень скоро стало ясно, что на все это нет времени. Зато они сосредоточились на самых ударных идеях - на поиске путей, интерфейсе и стрельбе. А вот от реализации таких вещей, как создание персонажей, полностью составленных из полигонов, «недвуногих» юнитов (кавалерия и катапульты), а также горящих деревьев и прочих «красивостей» пришлось отказаться.
Когда Чаки спросили, какие справочные материалы он считает полезными для начинающих игровых программистов, он ответил, что превыше всего ценит общение с опытными кодерами и изучение их программ. «Нет ничего лучше, чем поговорить с тем, кто уже написал несколько игр, или посмотреть настоящие исходные коды...» Программистам, не располагающим такой возможностью, Чаки советует читать книги, второй по значимости полезный источник, особенно университетские учебники, хотя и добавляет, что «найти среди них хорошие довольно трудно».
Майкл Д. Макграт (Michael D. McGrath), Dynamix/Sierra
Майкл Макграт - инженер-программист компании Dynamix. Он работал над созданием популярного симулятора воздушных сражений времен Первой мировой войны Red Baron 3D, а в прошлом участвовал в ряде других проектов, включая Netrek (свободно распространяемая программа) и Extreme Warfare (Trilobyte). Майкл предлагает вашему вниманию несколько советов, касающихся программирования и разработки игр, и перечисляет наиболее распространенные грубые ошибки, встречающиеся в игровой индустрии.
