Джей Стелли (Jay Stelly) Valve Software
Джей Стелли (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, показывали разительное отличие в производительности в зависимости от объема памяти, используемой под текстуры, и того факта, складывается ли ваше изображение из текстур, чьи размеры являются степенью двойки.
В конце концов, мы создали набор приемов, которые позволили 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 (группа новостей)
