ЕСЛИ ПРОВЕСТИ АНАЛОГИЮ С АВТОМОБИЛЕМ, ТО ИГРОВОЙ ДВИЖОК — ЭТО НЕ СОВСЕМ ТО ЖЕ, ЧТО ДВИГАТЕЛЬ ВНУТРЕННЕГО СГОРАНИЯ. СКОРЕЕ, СОВОКУПНОСТЬ СИЛОВЫХ ДЕТАЛЕЙ КУЗОВА, ПОДВЕСКА И, ЕСТЕСТВЕННО, САМ ДВИГАТЕЛЬ. НА ПОЛУЧИВШИЙСЯ СКЕЛЕТ РАЗЛИЧНЫЕ ПРОИЗВОДИТЕЛИ НАВЕШИВАЮТ ДЕТАЛИ ЭКСТЕРЬЕРА И ИНТЕРЬЕРА, КОТОРЫЕ И ПОСТУПАЮТ КОНЕЧНОМУ ПОТРЕБИТЕЛЮ
Исторически сложилось так, что игровым движком принято называть совокупность программных абстракций, с которой работают программисты ИИ (искусственного интеллекта), моделлеры физического поведения игрового мира и программисты шейдеров (они же — создатели игрового контента).
Бестиарий
Часто случается так, что жизненный цикл игрового движка прекращается на первой же игре — уже в момент выпуска движок является морально устаревшим. Конечно, с точки зрения экономии ресурсов это абсолютно неправильно, но сложившиеся правила игрового бизнеса не позволяют перевести старый программный код на новые аппаратные рельсы. Так было не раз, и, думаю, так будет и в будущем. Ты, наверное, воскликнешь: «Как же, черт побери, хорошо работать на игровых консолях!» И в какой-то мере ты прав. Для повторного использования кода на консолях есть гораздо больше пространства, если учесть, что жизненный цикл игрового железа составляет не два-три года, как на PC, а в несколько раз больше. Однако в кустах нас поджидает парочка жирных и хищных «но». Во-первых, не так просто пробраться на консольный рынок, там нас ожидает строгий face-контроль платформодержателя, а игру ждут пытки, по сравнению с которыми испанская инквизиция покажется сборищем воспитательниц детского сада. Во-вторых, стоимость разработки под современную консоль значительно выше, чем под PC, хотя, конечно, можно сорвать больший куш, но, впрочем, это не тема статьи.
Ты тут же вспомнишь о RenderWare, Unreal Engine, Source и прочих монстрах геймдела. Как же так? Эти технологии имеют длительный жизненный цикл! Не забывай, что эти движки разрабатывались опытными командами от крупных компаний, которые зашибают основные деньги на лицензировании и поддержке своих продуктов. Примечательно, что на просторах нашей необъятной крупные игроки рынка наконец осознали, что могут зарабатывать деньги подобным же образом. Собственно, кроме предоставления технологий, они обеспечивают продюсерское участие в проектах молодых студий, что позволяет начинающим командам избежать типичных ошибок новичков. Конечно, пока качество отечественных движков оставляет желать лучшего — как в плане качества картинки, так и в плане производительности. Будем надеяться, что рано или поздно наше отставание от капиталистов будет ликвидировано, особенные надежды возлагаем на недавние экспансии иностранных инвестиций в наш игропром.
Толстый огр
Впрочем, спустимся с небес на грешную землю и вернемся к нашим баранам. Для молодых команд (буржуи называют их Indie team — пока молодая и пока независимая компания) многие компании предоставляют солидные скидки на свои технологии. Кроме того, существует масса бесплатных открытых движков, которые вполне пригодны для создания современных игр. Типичный пример — Ogre 3D (Open source graphics engine), к использованию которого примеряются многие начинающие игроделы. К слову, существует русский ресурс, посвященный Ogre. Еще одно «кстати»: недавно (в декабре 2005) питерская студия Lesta выпустила игру «Стальные Монстры», сделанную на этом движке. Выбор Lesta оправдан, поскольку Ogre — объектно ориентированный кросс-платформенный движок (Windows и Linux), который развивается и поддерживается разработчиками (сейчас они уже перевалили за версию 1.0.6). В качестве рендера в Ogre используются DirectX 7.0, DirectX 9.0, и openGL 1.5, что, с одной стороны, обеспечивает солидную гибкость, с другой — порождает рыхлый исходный код движка с массой лишних классов-wpapper'ов. Движок поддерживает различные шейдеры: Cg, HLSL, GLSL (к примеру, используется развитая идеология материалов). Для экспорта мешей из 3D-редакторов существует масса экспортеров, поддерживаются следующие редакторы: Milkshape3D, 3D Studio Max, Maya, Blender и Wings3D. Возможно использовать скелетную анимацию и прогрессивные меши. Менеджмент сцены организован просто и в то же время гибко, имеются объекты сцены, предопределенные на многие случаи жизни, поддерживаются алгоритмы BSP и Octree. Реализовано несколько алгоритмов построения теней. Поддерживаются системы частиц и несколько алгоритмов отображения неба. Функциональность движка легко расширяется за счет того, что он реализован по объектно ориентированным принципам и поддерживает развитую систему плагинов.
Приятно, что движок качественно документирован и имеет обширное Community. К недостаткам можно отнести только отсутствие встроенного качественного редактора игрового мира (сцены), жуткие тормоза и (по большому счету) отсутствие моделирования физики сцены. Однако, как показывает практика, решать эти проблемы гораздо проще, чем писать движок с нуля.
Nebula device
Ogre — не единственный качественный бесплатный движок. Также заслуживает внимания продукт немецкой компании Radon Labs — Nebula Engine, построенный по принципам клиент-серверной архитектуры и являющийся объектно ориентированным движком, как и Ogre. В отличие от злобного людоеда, Nebula предоставляет более широкие возможности для построения различных сценариев. Любой объект движка имеет символьное имя, который позволяет получить C++-указатель на объект. Другими словами, можно свести всю разработку игры на базе Nebula к написанию скриптов и исключить участие кода на C++. Еще одно отличие от Ogre — то, что Nebula работает только под управлением Windows и только с DirectX. Также здесь имеются классы для реализации сетевых баталий. Поддерживаются шейдеры (HLSL и FX-файлы DirectX), скелетная анимация, системы частиц, тени. Аналогично Ogre, отсутствует физика и встроенный редактор (общее место всех бесплатных движков!), зато предоставляется приличная документация и развитая инфраструктура всевозможных утилит. Дата последнего обновления — июнь 2005 года, текущая версия 2.0.
Irrlicht engine
Упоминания заслужил и бесплатный движок Irrlicht Engine. Этот кросс-платформенный движок (Windows и Linux) работает с DirectX (8.1, 9.0), openGL 1.5 и собственными программными рендерами. Поддерживает шейдеры и расширяемую библиотеку материалов, анимацию (скелетную и морфинг), собственную систему оверлеев. Как и большинство 3D-движков, этот движок написан на C++ и подчиняется всем законам ООП. Понимает меши всех основных форматов. Реализует системы частиц, стенсильные тени, небо и т.д. Предоставляется качественная документация, последнее обновление датировано декабрем 2005 года, текущая версия 0.14.0.
Unreal engine 3
Итак, мы сказали пару слов о доступных движках. Настало время вернуться к теме любимых «Мерседесов»
. Когда задумываешься о них, сразу же вспоминаешь компанию Epic Games с ее линейкой Unreal и соответствующими движками. Последним продуктом этой конюшни является Unreal Engine 3, который смело позиционируется как настоящее и будущее индустрии развлечений. Основные платформы для этого движка — это DirectX 9.0, Xbox 360 и PlayStation 3. Поддерживается графический конвейер, способный работать с 64-битным цветом (HDR), все современные техники освещения (в том числе параметризованная модель освещения Фонга), продвинутые динамические тени (от стенсильных до размытых мягких теней), — все это становится возможным благодаря развитой системе материалов. С помощью редакторов контента разработчики могут редактировать (не отходя от кассы) все эффекты и материалы вплоть до констант шейдеров. Неудивительно и наличие систем частиц, которые можно редактировать с помощью специализированного редактора эффектов. Неотъемлемая часть UE3 — физический движок на базе NovodeX (надеюсь, никто еще не забыл о компании Ageia, ждем в марте месяце 2006 года). Все материалы объектов сцены обладают также физическими характеристиками, например трением. Имеется редактор моделирования физики, который позволяет не только создавать физически реалистичные модели, но и симулировать, настраивать и оптимизировать поведение этих моделей. Возможности анимирования моделей практически не ограничены, с помощью средств движка можно создавать высококачественную скелетную анимацию, которая тесно связана с физической моделью поведения тел, известной как RagDoll. Специальный редактор AnimTree позволяет создавать и просматривать все аспекты анимирования модели.В комплекте движка идет набор экспортных утилит для всевозможных 3D-редакторов. Стандартное системное окружение позволяет создать на базе движка игровую логику любого уровня сложности. Поддерживаются следующие обобщенные игровые объекты: игроки, NPC, инвентарь, оружие и триггеры. Подсистема искусственного интеллекта содержит готовые алгоритмы поиска пути (с учетом триггеров, лестниц и дверей), навигации (с учетом локальных тактических задач), принятия решений и командного «разума». Коллективный разум подходит для реализации шутеров от первого и третьего лица, а также тактических игр. В качестве сценарного языка используется визуальная скриптовая система UnrealKismet. Для разработки демок и заставок на движке используется система UnrealMatinee. Звуковой движок поддерживает все основные звуковые форматы для всех целевых платформ, в том числе объемный 5.1 звук и Dolby Digital. Поддерживается трехмерное позиционирование, разделение звука и смещение по Доплеру. В редакторе сцены UnrealEd работа со звуком осуществляется с помощью специального визуального инструмента.
Естественно, полностью доступны сетевые игрища, которые являются лицом бренда Unreal. Сетевое взаимодействие организовано на базе протокола UDP, клиент-серверная система поддерживают до 64-х игроков, система без выделенного сервера — до 16-ти игроков. Естественно, возможны игрища между людьми, сидящими на разных платформах. Из анонсированных проектов, под которые лицензирован этот движок, в глаза бросается Duke Nukem Forever и Star Wars: Republic Commando. Список вышедших игр на базе технологий Unreal воистину необъятен. На DTF есть перевод описания движка. Стоимость лицензии на использование UE3 для одной платформы составляет $750 тыс., за каждую дополнительную платформу предлагается доплачивать по сто тысяч безусловно правильных денег.
Renderware
Продукт компании Criterion (с аппетитом сожрана Electronic Arts), в отличие от UE3, являет собой сегодняшний день. Основные платформы для этого движка — PlayStation 2, PlayStation Portable, Xbox, GameCube, PC и N-Gage. Основанный на компонентной архитектуре, RenderWare Studio 2.0 предоставляет комплексную систему для разработки игр — от прототипирования игры до тестирования и сборки конечных билдов. Вся эта система завязана на четкой формализации всех процессов разработки. На данный момент RenderWare является корпоративным стандартом для электроников и закуплен (вместе с Criterion) для дальнейшей унификации и формализации процесса разработки сверхунифицированных и формализованных игр от EA
. Черт побери, кто-нибудь знает, чем отличаются FIFA 2005 от FIFA 2006?.. Кто это сказал, что одним байтом?!Source engine
Еще одно имя, которое пока у всех на слуху, — это компания Valve со своим движком Source, на котором были сделаны Half-Life 2, Day of Defeat: Source, Counter Strike: Source. С использованием этой же технологии компания Troika Games (о ней нужно говорить «либо хорошо, либо никак») выпустила модненькую RPG Vampire the Masquerade: Bloodlines, а Smiling Gator Productions ваяет очередную «нетленную» MMORPG Twilight War: After the Fall, которую сами авторы именуют не много не мало как Extreme Online Roleplaying Game (XORG).
Теперь покопаемся в его кишочках… В отличие от описанных мной движков, Source предназначен только для Windows-платформы и только для DirectX. Язык разработки — С++. Как и любой уважающий себя движок, этот поддерживает солидную библиотеку материалов, системы частиц, несколько моделей освещения и затенения. Аналогично Unreal Engine 3, материалы Source несут в себе и физический смысл, то есть поверхности игровых объектов сумеют катиться, скользить и т.д.
Source силен сетевым кодом, который отлаживается огромными толпами геймеров по всему миру начиная с 1999 года. Кроме обычной скелетной анимации, движок предоставляет возможности по анимированию лиц, симуляции речи, мимики лица и выражения глаз. В качестве физического движка используется самое современное на сегодня программное решение на базе Havok 2. Собственно, Half-Life 2 — это самый удачный пример активного использования физики в gameplay. Еще одной традиционно сильной стороной технологий Valve является искусственный интеллект. Персонажи в Source умеют принимать эффективные навигационные решения исходя из поставленных тактических задач, воспринимают окружающую информацию привлекая слух, зрение и нюх, умеют «работать» в команде. Звук в движке также тесно связан с физикой и логикой игрового мира, поддерживается трехмерный 5.1. звук и эффект Доплера. Имеется собственная система оверлеев. Все ресурсы, используемые Source, редактируются встроенными инструментами: моделирование лиц, игрового мира и игровой логики, оверлеи, всевозможные инструменты экспорта моделей из популярных 3D-редакторов. На сегодня перспективы Source, по сравнению с конкурентами, скрыты в тумане, что связано с пришествием консолей следующего поколения. Скорее всего, Valve не захочет терять столь привлекательный рынок, и компания сейчас ведет работы по созданию движка нового поколения, работающего на всех популярнейших платформах. Поживем — увидим.
Doom 3 engine
Думаю, представлять банду Джона Кармака не нужно. Эти люди стояли у истоков шутеров и полигональных игр, поэтому просто необходимо сказать пару слов об их последнем движке. На нем были сделаны следующие игры: естественно, Doom 3, add-on к нему Doom 3: Resurrection of Evil, Quake 4, разрабатываемые в данный момент Pray, Enemy Territory: Quake Wars на движке с поддержкой технологии MegaTexture. Изначально планировалось доработать движок Quake 3 до потребностей сегодняшнего дня, однако позже команде Кармака стало ясно, что необходимо полностью переработать код. И вот, получившийся движок имеет очень мало общего с кодом для движков предыдущих Quake. Если раньше движки от ID были написаны на чистом С, то теперь D3 может похвастаться объектно ориентированными концепциями.
В остальной же функциональности движок вряд ли опережает современные решения на базе Unreal Engine 3. Да, есть освещение, есть тени, для будущих игр планируется сделать поддержку мягких теней, есть технология для анимации лица наподобие технологий Source. Есть даже технология громадных текстур, названная MegaTexture — она позволяет сделать текстуры земли и строений более детализированными и не повторяющимися. В целом же технология Doom 3 постепенно уходит в прошлое, а Кармаку и компании придется приложить значительные усилия, чтобы их технологии хотели лицензировать в будущем, — на одном имени далеко не уедешь
Понятия
Как уже было сказано, движок — это совокупность программных абстракций. Конечно, разные движки отличаются друг от друга деталями, но все они оперируют одинаковыми понятиями и выполняют одинаковые функции. Следовательно, в общем они похожи. Для начала определимся с терминами данных, которые обрабатываются движком.
Самой высокоуровневой абстракцией в любой игре являются игровые объекты со своими игровыми характеристиками, такими как здоровье, энергия. Игровыми объектами управляет пользователь и подсистема ИИ. Такой объект подчиняется действию туземной физической модели. Случается, что функциональности игровых объектов, имеющихся в движке, не хватает для реализации всех фишек геймплея, соответственно, разработчики игры реализуют собственные игровые объекты. Фактически они моделируют логику игры. Конечно же, нам хочется идеала: чтобы единственным кодом, который пришлось бы писать в процессе разработки, был код геймплея. Жаль, но ничто в этом мире не идеально. Очень часто модели поведения игровых объектов реализуются на языке, отличном от языка движка (обычно С++). Для этого используются сценарные языки, такие как Lua и Python, в основном чтобы было возможно изменять и отлаживать игровую логику без перекомпиляции исходного кода движка (она занимает до черта много времени!). Плюс, конечно — для того чтобы упростить и без того сложный игровой код. Правда, зачем нужна небезопасная возможность работать напрямую с памятью, если при разработке логики игры оперируют только абстракциями игровых объектов? Жизненный цикл игровых объектов обеспечивается специальным менеджером, который также связывает игровые объекты с подсистемой и алгоритмами ИИ плюс с пользователем. Аналогично игровым объектам, особняком в движке стоят так называемые оверлеи, или сущности для реализации пользовательского интерфейса. Часто используются готовые решения, такие как Crazy Eddie's GUI. Оверлеи также описываются сценариями, причем широко используются сценарии XML для представления иерархий элементов пользовательского интерфейса. Оверлеи, конечно, не имеют никакого отношения к рендерингу сцены, зато с их помощью пользователь управляет игровыми объектами.
Сцена
Перейдем на один уровень абстракций ниже — где-то на этом уровне появляются абстракции, существующие в любом современном движке. Управление сценой возлагается на менеджер сцены, который хранит иерархию объектов сцены, производит проверку видимости объектов, управляет камерой, источниками света, небом, туманом и прочими объектами сцены. Рассмотрим пример «простейшей» сцены: автомобиль едет по дороге мимо фонаря (см. рис. «Иерархия простой сцены»). К корню (root) сцены присоединяется статичный (в процессе игры не передвигается) объект — дорога (плоскость), для этого объекта устанавливается материал — асфальт с текстурой двухполосной дороги. Дифференцирование всех объектов сцены на статичные и динамичные производится ради оптимизации. На обочине дороги устанавливается фонарный столб со своим материалом. На верхушке столба располагается фонарь — это нестатичный источник света, поэтому для него заранее можно рассчитать карту освещенности всех статичных элементов сцены: дороги и столба. Таким образом можно сэкономить при расчете освещения.
Теперь начинается самое интересное. На дорогу помещается кузов машины, к нему присоединяются четыре колеса и два направленных источника света — фары. Машина передвигается по дороге, вместе с ней передвигаются фары, то есть два источника света, поэтому для каждого кадра необходимо рассчитывать освещенность дороги и столба фарами, а также освещенность машины фонарем со столба. Прибавь к этому расчет тени от машины, которую она отбрасывает на дорогу от фонаря, расчет карты отражения: кузов лакированный, соответственно, в нем можно разглядеть дорогу и столб.
Посмотрим, как происходит типичный цикл рендеринга такой сцены. Сначала проверяются все динамичные объекты. Для тех объектов, которые изменили свое положение на сцене, пересчитываются их мировые координаты. Далее вызывается один из алгоритмов отбрасывания невидимых объектов (BSP, Octree). Затем для материалов объектов сцены, подвергаемых рендерингу, устанавливаются шейдерные константы для источников света, различных матриц преобразования. И только после этого графический процессор начинает обработку видимой геометрии.
Меши, модели и их материалы
Мы плавно перешли к понятиям моделей и мешей. Изображение, которое ты видишь на экране, составлено из кучи полигонов (треугольников), они и образуют единые и неделимые наборы геометрии — меши. Например, кузов автомобиля и его колеса — это различные меши. Вместе они составляют модель автомобиля. Почему именно так, а не иначе? Предполагается, что в игре нельзя разбить кузов автомобиля, нельзя разрезать и разделить его на составные части, которые перемещались бы относительно друг друга. Колеса же могут перемещаться (например изменять свою ориентацию относительно двух осей), поэтому они реализованы в модели автомобиля как составные части. Каждый меш обладает своим материалом — способом отображения геометрических данных на экране.
Материал — это совокупность нескольких текстур, различных состояний графического конвейера, а также вершинная и фрагментная программы (шейдеры). Игровые объекты разбиваются на меши и модели исходя из соображений моделирования физики и логики игрового мира, а также способности графического конвейера отрендерить картинку. Конечно, хотелось бы иметь возможность оперировать десятками тысяч игровых объектов, взрывать стены и изменять земной ландшафт ковровыми бомбардировками, но современные графические технологии пока не позволяют реализовать все это в реальном времени. Пока все, на что мы способны, — это моделировать поведение сотни моделей, взаимодействующих друг с другом, и отображать со значительной аппроксимацией картинку. Так вот интересность геймплея достигается за счет таланта и работы дизайнеров и художников. В любой современной игре геометрия занимает наибольшее место в памяти. Для повышения скорости загрузки мешей их геометрия сохраняется в бинарных форматах, часто уникальных для каждого движка. Материалы же, напротив, часто хранятся в виде сценариев, причем дифференцируются следующим образом: отдельно хранятся шейдеры и состояния конвейера (например, в *.fx-файлах), отдельно — наборы текстур и цветов. В код движка их обычно не встраивают, чтобы оставалась возможность вмешаться оперативно и без перекомпиляции самого движка. На рисунке «Сценарий материала» ты можешь увидеть кусок сценария, описывающий материал стекла транспорта из Quake 4.
Системы частиц
Не все объекты сцены будет разумно представлять в виде мешей. Например, клубы дыма или пулеметные гильзы могут появляться на экране сотнями, тратить на них много памяти нецелесообразно. Для отображения таких объектов применяют системы частиц — абстракции, управляющие множествами спрайтов. На каждый спрайт тратится четыре вершины, то есть около 50-ти байт памяти. На вершины натягивается текстура. При моделировании систем частиц дизайнер изменяет их насыщенность, траектории, скорости и цвета, в итоге получаются огонь, дым, гильзы, снаряды и т.д. Параметры систем частиц сохраняются в специализированных сценариях — для оперативной правки. При создании систем частиц разработчики оперируют понятиями эмиттер и аффектор частиц.
Эмиттер — это сущность, из которой испускаются частицы, характеризуется скоростью испускания частиц, количеством частиц, плотностью и т.д. Аффектор — это сущность, которая воздействует на траекторию движения частиц, то есть некий модификатор, изменяющий на каждом кадре местоположение и цвета каждой частицы. На рис. «Система частиц» приведен пример подобного сценария из Quake 4.
Освещение
Расчет освещения для всех моделей сцены — чертовски трудоемкая задача. Разработчики игр стараются максимально снизить подобные издержки, поэтому создают статические карты освещения, для того чтобы можно было не пересчитывать на каждом кадре кучу лишних источников света. Передвигаемых лампочек в любой игре одна-две, они действительно освещают модели в масштабе реального времени. Существуют следующие виды источников света: точечные (лампочка), направленные (солнце), споты (фары, прожектор).
Рядом с проблемой освещения стоит проблема построения теней, которые отбрасываются и принимаются объектами сцены, — самая трудоемкая часть рендеринга. Сейчас фотореалистичные мягкие тени строятся в реальном времени только в отдельных демонстрационных программах и примерах. В реальной игре разработчики стараются использовать предварительно рассчитанные (статические) тени, а для динамичных объектов строятся тени четкие либо упрощенные до максимума (например кружок на полу). Сравни качество мягких и четких теней на соответствующих рисунках — картинка стоит тысячи слов, особенно там, где указаны FPS.
Менеджмент ресурсов
При создании движков разработчики стараются придерживаться концепций систем управляемых данными (data driven system). Фактически получается, что различные сценарии (ресурсы) загружают другие ресурсы и управляют ими. При этом движок играет роль фабрики, на которой обрабатываются ресурсы, из которых получается конечный продукт — геймплей. Если ресурсы обрабатываются всеми подсистемами движка, то контроль над жизненным циклом ресурсов, а также процесс загрузки ресурсов в память возлагается на подсистему менеджмента ресурсов. К таким подсистемам предъявляются следующие требования:
ВОЗМОЖНОСТЬ ДЕКОДИРОВАТЬ ЗАГРУЖЕННЫЕ РЕСУРСЫ В ФОРМАТЫ, ПОНИМАЕМЫЕ ГРАФИЧЕСКИМИ API, ВВВВВВВВВВВВВВВВВ, ЗВУКИ, ТЕКСТУРЫ И Т.Д. ИЗ ОДНОГО ФОРМАТА В ДРУГОЙ;
ЗАГРУЗКА РЕСУРСОВ В ПАМЯТЬ ИЗ ФАЙЛОВОЙ СИСТЕМЫ, ИЗ АРХИВА И ИЗ СЕТИ;
ПАРСИНГ И ИСПОЛНЕНИЕ СЦЕНАРНЫХ РЕСУРСОВ.
В зависимости от используемых сценарных языков, реализуются различные механизмы передачи данных в движок и обратно. Кроме загрузки ресурсов, подсистема менеджмента должна контролировать правильность выгрузки ресурсов и освобождения памяти, иначе оперативная память будет исчерпана в рекордно короткие сроки.
Диагностика
На этапе разработки и, как показывает реальная жизнь, на этапе эксплуатации часто требуется проанализировать ошибки программы. Для решения подобных задач в движке задаются стратегии обработки ошибок, анализа сбоев, ведутся протоколы работы (логи). В некоторых случаях покупатели (!) игр участвуют в поиске ошибок: служба поддержки просит их выслать «некоторые файлики» — протоколы ошибок и всевозможные дампы. Диагностика ошибок игры в целом и движка в частности заметно осложняется условиями работы, а именно тем, что код работает в реальном времени. Именно по этой причине в играх редко используется многопоточность — она содержит потенциальную угрозу безопасной работе.
Редактор
Главными инструментами для любого разработчика игры являются всевозможные редакторы игрового контента. Для полноценного создания игры не хватает возможностей 3D Studio, Maya и т.д., в этих трехмерных редакторах создаются только модели и анимация к ним. Для создания игровых уровней, программирования игровой логики, программирования физических моделей, редактирования материалов, доведения до ума анимации, расстановки освещения и теней, создания систем частиц применяются редакторы, встроенные в движки.
Коротко о главном
Если тебя вдруг посетила идея взяться за написание движка, подумай сто раз, а лучше двести. Конечно, если ты не ставишь перед собой задач завоевать мир, вполне реально создать движок, а затем и игру на нем. Если ты четко представляешь себе цель (например самообразование, создание движка, который умеет текстурировать модельку и освещать ее непременно одной лампочкой), то ты ее достигнешь. В любом случае сразу забудь бредни по поводу кросс-платформенности кода, независимости от графического API — это нереально. Не думай, что кто-то в индустрии захочет пользоваться твоим шедевром. Пиши шедевр для себя, для удовольствия, для level_up'а наконец. Используй по максимуму готовые решения, не изобретай велосипед, изучи STL, Boost. Если же хочется не возиться с движком, а просто создать свой трехмерный тетрис, используй готовые практически бесплатные решения: движки Orge, Irrlicht или Nebula, звуковую библиотеку OpenAL, простенькую ODE или Tokamak-физику. И тогда вероятность, что твой проект станет завершенным, намного повысится
ИГРОВЫМ ДВИЖКОМ ПРИНЯТО НАЗЫВАТЬ СОВОКУПНОСТЬ ПРОГРАММНЫХ АБСТРАКЦИЙ, С КОТОРОЙ РАБОТАЮТ ПРОГРАММИСТЫ ИИ (ИСКУССТВЕННОГО ИНТЕЛЛЕКТА), МОДЕЛЛЕРЫ ФИЗИЧЕСКОГО ПОВЕДЕНИЯ ИГРОВОГО МИРА И ПРОГРАММИСТЫ ШЕЙДЕРОВ (ОНИ ЖЕ — СОЗДАТЕЛИ ИГРОВОГО КОНТЕНТА)
ЧАСТО СЛУЧАЕТСЯ ТАК, ЧТО ЖИЗНЕННЫЙ ЦИКЛ ИГРОВОГО ДВИЖКА ПРЕКРАЩАЕТСЯ НА ПЕРВОЙ ЖЕ ИГРЕ
ПОКА КАЧЕСТВО ОТЕЧЕСТВЕННЫХ ДВИЖКОВ ОСТАВЛЯЕТ ЖЕЛАТЬ ЛУЧШЕГО И В ПЛАНЕ КАЧЕСТВА КАРТИНКИ, И В ПЛАНЕ ПРОИЗВОДИТЕЛЬНОСТИ
OGRE 3D (OPEN SOURCE GRAPHICS ENGINE) — К ЕГО ИСПОЛЬЗОВАНИЮ ПРИМЕРЯЮТСЯ МНОГИЕ НАЧИНАЮЩИЕ ИГРОДЕЛЫ
NEBULA ENGINE ПОСТРОЕН ПО ПРИНЦИПАМ КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРЫ
UNREAL ENGINE 3 ПОЗИЦИОНИРУЕТСЯ КАК НАСТОЯЩЕЕ И БУДУЩЕЕ ИНДУСТРИИ РАЗВЛЕЧЕНИЙ
НА ДАННЫЙ МОМЕНТ RENDERWARE ЯВЛЯЕТСЯ КОРПОРАТИВНЫМ СТАНДАРТОМ ДЛЯ ЭЛЕКТРОНИКОВ
SOURCE ПРЕДНАЗНАЧЕН ТОЛЬКО ДЛЯ WINDOWS-ПЛАТФОРМЫ И ТОЛЬКО ДЛЯ DIRECTX
ИГРОВЫМИ ОБЪЕКТАМИ УПРАВЛЯЕТ ПОЛЬЗОВАТЕЛЬ И ПОДСИСТЕМА ИИ. ТАКОЙ ОБЪЕКТ ПОДЧИНЯЕТСЯ ДЕЙСТВИЮ ТУЗЕМНОЙ ФИЗИЧЕСКОЙ МОДЕЛИ
ИЗОБРАЖЕНИЕ, КОТОРОЕ ТЫ ВИДИШЬ НА ЭКРАНЕ, СОСТАВЛЕНО ИЗ КУЧИ ПОЛИГОНОВ (ТРЕУГОЛЬНИКОВ), КОТОРЫЕ ОБРАЗУЮТ ЕДИНЫЕ И НЕДЕЛИМЫЕ НАБОРЫ ГЕОМЕТРИИ — МЕШИ
ДЛЯ ОТОБРАЖЕНИЯ ДЫМА, ОГНЯ, ГИЛЬЗ ПРИМЕНЯЮТ СИСТЕМЫ ЧАСТИЦ
ТЕНИ — НАИБОЛЕЕ ТРУДОЕМКАЯ ЧАСТЬ РЕНДЕРИНГА
ПРИ СОЗДАНИИ ДВИЖКОВ РАЗРАБОТЧИКИ СТАРАЮТСЯ ПРИДЕРЖИВАТЬСЯ КОНЦЕПЦИЙ СИСТЕМ УПРАВЛЯЕМЫХ ДАННЫМИ (DATA DRIVEN SYSTEM)
ГЛАВНЫЕ ИНСТРУМЕНТЫ ЛЮБОГО РАЗРАБОТЧИКА ИГРЫ — ВСЕВОЗМОЖНЫЕ РЕДАКТОРЫ ИГРОВОГО КОНТЕНТА
TONY