Игровой движок

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

Для того чтобы спроектировать по-настоящему гибкую и масштабируемую систему игры, необходимо не только понимать специфику игровых приложений, но и иметь представление об архитектуре программного обеспечения в общем. Книга Software Architecture in Practice, написанная Леном Бассом, Полем Клементсом и Риком Казманом (Len Bass, Paul Clements, and Rick Kazman) представляет собой хорошее введение в тематику разработки архитектуры программного обеспечения. Кроме того, авторы объясняют само понятие архитектуры ПО, рассматривают основные концепции, общепринятые подходы к проектированию программ, эталонные модели и стандартные примеры архитектур. Книга описывает многочисленные критерии качества архитектуры и рассказывает о том, какие методы лучше применять и каких подходов придерживаться, чтобы придать архитектуре требуемые свойства. Книга будет полезна как при выборе архитектурной модели, так и при реализации выбранной архитектуры. Авторы создали обширный справочник, который позволит существенно сократить поиск и выбрать одну из эталонных архитектурных моделей в качестве основы построения вашей системы.

Другой книгой, подробно разбирающей задачи проектирования и их решения, является книга Чарльза Ричтера (Charles Richter) под названием Designing Flexible Object-Oriented Systems with UML. Автор рассматривает большое количество относительно простых технологий, позволяющих повышать гибкость архитектуры. В книге описано несколько способов увеличения согласованности и уменьшения количества взаимозависимостей в системе, рассматриваются преимущества и недостатки абстрагирования и конкретизации на уровне классов и дается сравнение таких методов проектирования как специализация и агрегация. Ричтер в деталях рассказывает о том, как анализировать гибкость динамических диаграмм (например, диаграмм процессов).

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

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

Одной из проблем подобного метода создания архитектуры игрового приложения является то, что такие качественные критерии как гибкость и расширяемость редко учитываются при планировании и проектировании системы. Так, например, компании id software при создании новой игры приходилось переписывать практически весь код предыдущей. Что наглядно видно на примере использования архитектуры игры Quake 3[2] для создания Doom 3. Несмотря на то, что обе игры принадлежат к одному жанру FPS и во многом похожи. Фактически, их единственное отличие заключается в улучшенной графике. С тех пор как развитие игр фактически свелось к улучшению графики, основной причиной переделывания структуры одной игры при создании новой является то, что существующие модели и архитектурные шаблоны не поддаются расширению. Пример проблем, с которыми столкнулась id, безусловно не единичен. Большинство (если не все) компании тратят время на переписывание звуковой системы игры, системы интерфейса пользователя и т.д., просто потому что существующий код невозможно встроить в новую игру.

Рис 1. Архитектура Роллингса и Морриса (Rollings and Morris)

Роллингс и Моррис (Rollings and Dave Morris), авторы Game Architecture and Design, дают обзор существующих архитектурных моделей игровых приложений и пытаются выделить, насколько это возможно, основные элементы игровой архитектуры (см. рис 1 выше). Игра, построенная по схеме компонентов, представленная на рисунке 1, будет работать, но я считаю, что подобная сеть взаимоотношений и многочисленные связи между компонентами, сильно ограничивают расширяемость системы и возможность ее повторного использования в других проектах. Удобная архитектура должна не только логически разделять систему на подсистемы, она также должна предусматривать легкую замену или модификацию любой подсистемы без перестраивания системы целиком.

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

Переход к системам, построенным на COTS (COTS - component off the shelf, методология, предписывающая разработчикам использование сторонних компонентов(плагинов).), является первым шагом на пути масштабного изменения игр, принципов их разработки и планирования. Однако несмотря на то, что использование готовых компонентов способно улучшить качество игры и сократить время ее разработки, использование объектно-ориентированного подхода приведет к тому, что компоненты едва ли будут более полезны, чем обычные библиотеки функций, помогающие оперировать объектами. Игровые объекты все еще ответственны за обработку своих данных, а именно, за рендеринг, за искусственный интеллект, звук, физику и т.д. Одним словом, игры пытаются использовать преимущества COTS-компонентов и вместе с этим оперируют слишком большими и сложными игровыми объектами. А это в свою очередь приводит к тому, что при разработке объектов разработчики жестко привязаны к используемым COTS-компонентам (см. рис. 2).

Рис 2. Сочетание метода COTS-разработки и объектно-центрированной модели

Вдобавок объектно-ориентированный подход ограничивает возможность повторного использования, даже при применении технологии COTS-компонентов[3]. Код, описывающий объект, всегда остается наихудшим в смысле повторного использования, но при совмещении объектно-ориентированных и COTS-технологий этот код содержит в себе еще и вызовы функций различных специализированных компонентов. Таким образом, при переходе на новый проект разработчики часто вынуждены переписывать код вследствие подобного взаимодействия объекта и компонентов. Даже хорошо спланированная и разработанная иерархия классов не способна уменьшить риск переписывания кода из-за того, что объекты остаются жестко связанными с используемыми COTS-компонентами. Я полагаю, что существует архитектура, способная значительно сократить количество переписываемого кода, вследствие ликвидации жестких взаимосвязей.

Совмещения всех COTS-компонентов в игровом ядре и есть игровой каркас - движок.

Постановка задачи по проектированию архитектуры

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

· Требования к архитектуре: Поддержка концепции COTS-компонентной разработки

Во-первых, архитектура должна иметь строгую логическую структуру. Необходимо таким образом разделить систему на логически независимые части, чтобы каждая из подсистем могла быть разработана и оттестирована независимо от других. Это требование согласовывается с требованиями к COTS-системам, и я буду придерживаться принципов COTS-концепции.

Для того чтобы проверить, отвечает ли полученная архитектура данному требованию, разработчик должен продемонстрировать, что компоненты системы были разработаны и оттестированы независимо. Эти компоненты должны легко интегрироваться в итоговом игровом приложении и не требовать для этого больших изменений игрового кода. В идеале разработанные компоненты должны соединяться также легко, как если бы мы соединяли их на логическом уровне.

· Требования к архитектуре: Сокрытие деталей реализации и доступность применения без знания предметной области (локализация предметных областей)

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

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

Требования к архитектуре: Гибкость и модифицируемость

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

Для того чтобы проверить, отвечает ли полученная архитектура данному требованию, достаточно продемонстрировать, что разные игры могут быть написаны на ее основе.

· Требования к архитектуре: Масштабируемость и эксплутационная надежность

Другими критическими требованиями к архитектуре, также вытекающими из проблемы быстрого роста стоимости разработки, являются масштабируемость и эксплутационная надежность. Успешные игры часто появляются заново с различными дополнениями и улучшенным качеством. Так, например, компания Blizzard последовательно выпускала три версии своей игры под названием Warcraft, от Warcraft до Warcraft 3. В последней версии были добавлены новые герои и красивая трехмерная графика, но основа во всех трех версиях оставалась очень похожей. Успешная архитектура должна легко позволять подобную эволюцию игры.

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

· Производительность и другие качественные параметры не являются приоритетными

Может показаться странным, что я не считаю производительность ключевым, главным требованием при проектировании архитектуры программ, предметная область которых постоянно напоминает о высокой планке производительности. Причина в том, что производительность в действительности играет несравнимо меньшую роль в вопросах межкомпонентного взаимодействия, чем производительность самих компонентов и подсистем игры. Например, отрисовка 10 миллионов треугольников одного объекта гораздо сильнее влияет на производительность, чем единичное межкомпонентное воздействие на графическую систему, вызывающее эту отрисовку. Я не стану игнорировать производительность при разработке архитектуры, но требования, описанные выше, имеют более высокий приоритет и значимость.

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

Выбор подходящих архитектурных концепций

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

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

Рассмотрим некоторые архитектурные концепции, применение которых поможет нам реализовать требуемые качества в конечной архитектуре.

· Многоуровневость (слоистость)

Многоуровневая архитектурная концепция описывает разделение функционала системы на иерархические уровни, каждый из которых обеспечивает работу вышестоящего уровня и является его потомком[4]. Метод слоев поддерживает возможность повторного использования, располагая код, специфичный для данного приложения, на более высоких уровнях (слоях), позволяя разработчикам заново использовать каркас, образованный нижними уровнями. А возможность повторного использования неразрывно связана с нашими требованиями к конечной архитектуре такими, как гибкость и модифицируемость.

· Данные управляют всем (data-centered)

По существу, управляемость данными - это концепция, требующая наличия централизованного хранилища данных при полной независимости (друг от друга) клиентов, выполняющих обработку информации из хранилища[7]. Реализация этой концепции предлагает простой способ объединения различных систем, вследствие того, что клиенты могут ничего не знать друг о друге, а хранилище данных может ничего не знать о клиентах.

· Независимые компоненты

Данная концепция определяется наличием независимых компонентов (в общем случае, процессов), взаимодействие которых осуществляется посредством системы сообщении. Для корректного взаимодействия через систему сообщений компоненты "подписываются" на получение той информации, которую они обрабатывают. Одним из интересных преимуществ концепции независимых компонентов является то, что необязательно все компоненты должны присутствовать в системе при ее загрузке на исполнение и работе. Особенность распределенной системы взаимодействия посредством сообщений состоит в необязательности существования "подписчиков" на "опубликованные" (т.е. рассылаемые) сообщения. Качественно спроектированная подобная система допускает добавление/удаление функций и компонентов в любое время.

· Потоковая архитектура

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

· Система систем (SoS или System of Systems). Интегрируемость

По сути дела, проектировщики часто используют идеи концепции системы систем при интегрировании множества сложных и разнородных систем в одну, более общую суперсистему[8]. Подход SoS интересен тем, что он описывает построение систем в различных программах, реализующих представления различных предметных областей, т.е. как раз таких систем, как игры или приложения промышленного уровня. Графика, физика, ИИ и т.д. являются, вообще говоря, различными предметными областями, но в случае игр они объединяются и используются совместно в одном приложении. Кроме того, систему, на концептуальном уровне SoS, представляют как множество, объединение подсистем (компонентов или в терминологии SoS, определений ("Definition")). Другими словами, игра - это объединение таких компонентов, как системы ИИ, системы физики, системы отображения и т.д.

Подобная точка зрения на вопросы архитектуры игры будет весьма полезна нам, ведь она удовлетворяет нашему изначальному требованию о сокрытии деталей реализации и доступности применения без знания предметной области. Это действительно становится возможным, если считать (и реализовать соотв.) графический "движок" законченной системой, и определить игру, как результат его взаимодействия с остальными системами.

Теперь перейдем с логического уровня на физический и рассмотрим как эти компоненты буду располагаться рамках проекта.

При проектировании такого рода систем рассматривается как правило несколько вариантов, если отбросить все которые явно по тем или иным причинам не подходят для игровых.

Первым глобальным и определяющим решением является то, каким образом движок обособлен от самого приложения его использующего. Тут возможно три основных варианты и их производные.

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

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

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

Третий вариант на мой взгляд наиболее интересен. Этот подход заключается в плагинной архитектуре. Плагин (от англ. plug-in) -- независимо компилируемый программный модуль, динамически подключаемый к основной программе, предназначенный для расширения и/или использования её возможностей[11]. Также может переводиться как «модуль». Плагины обычно выполняются в виде разделяемых библиотек. Принцип такой архитектуры заключается в том, что каждая подсистема выделена в отдельный независимый плагин, который имеет свой постоянный интерфейс. Эти плагины подключаются к ядру, которое занимается их менеджментом. Далее пользователь из ядра получает набор интерфейсов реализуемых в плагинах, с которыми ему и предстоит работать. Плюсы такой архитектуры заключаются в том, что все плагины могут разрабатываться независимо и любая подсистема может быть реализована несколькими принципиально разными плагинами. Например, система рендеринга может быть реализована двумя плагинами, один будет использовать Direct3D, а другой - OpenGL. А приложению использующему движок будет без разницы какой плагин в данный момент подключен и через что реализуется тот или иной функционал, т.к. это остается на более низком уровне абстракции. Такой подход может быть реализован для любой подсистемы движка. Неизменным остается лишь ядро. Но у этого подхода тоже есть свои минусы, основной из них это трудоемкость проектирования, оно заключается в том, что чтобы вся система работала как надо и плагинная архитектура могла проявить все свои достоинства все подсистемы должны практически изначально иметь четкие продуманные интерфейсы, которые будут реализовывать плагины.

На определенном этапе вносить серьезные изменения в ключевые интерфейсы может оказаться весьма трудоемким и повлечь переработку многих плагинов. При грамотном проектировании основных интерфейсов должно быть как можно меньше, остальные же подвергаются изменениям без какого либо ущерба. Также при плагинной архитектуре стоит опасаться такого эффекта как «DLL Hell». «DLL hell» (DLL-кошмар, буквально: DLL-ад) -- тупиковая ситуация, связанная с управлением динамическими библиотеками DLL в операционной системе Microsoft Windows[11]. Сущность проблемы заключается в конфликте версий DLL, призванных поддерживать определённые функции. DLL hell -- пример плохой концепции программирования, которая, подобно скрытой мине, приводит к резкому возрастанию трудностей при усложнении и совершенствовании системы. Поэтому эксперты рекомендуют избегать или ограничивать применение DLL, обуславливающих такого рода конфликты. Для того, что бы этого не произошло надо изначально четко определить набор плагинов.

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

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

Определение принципов межмодульного взаимодействия

Как было описано в пункте 2.1.3 архитектура движка должна вобрать в себя лучшее из уже сформировавшихся архитектурных решений, так же выше было определено, что основной парадигмой архитектуры будет ее плагинность и соответствие COTS принципам.

Так вся архитектура строится на межмодульном взаимодействии я считаю что начать проектирование стоит с определения того, как это межмодульное взаимодействие будет осуществляется.

Самый просто способ это просто передача между модулями указателя на экземпляр класса или интерфейс. Но нам нужно так же помнить о том, что движок должен работать с несколькими языками программирования и хранение структуры класса в памяти для каждого языка свое, по этому передавать указатель на класс попросту не получится, приведет к ошибкам. Для подобных случаев компания Microsoft предоставляет готовое решение Component Object Model (COM).

Принцип работы архитектуры COM в двух словах можно объяснить следующим образом.

Код классов располагается в библиотеках (DLL), которые регистрируются в специальном разделе системного реестра. Каждый класс реализует один или несколько известных COM-интерфейсов. DLL экспортирует функцию для создания экземпляра указанного класса, которая возвращает указатель на базовый интерфейс IUnknown (все классы обязаны реализовывать этот интерфейс).

Каждому интерфейсу (описанию интерфейса) сопоставляется уникальный идентификатор (Global unique identifier - GUID).

Для создания экземпляра класса пользователь вызывает функцию CoCreateInstance(GUID) из библиотеки COM. Именно она занимается просмотром записей в реестре, загрузкой DLL и вызовом функции создания экземпляра.

Пользователь работает с объектом через указатель на интерфейс.

Для контроля существования объекта используется подсчет ссылок. После использования экземпляра класса, пользователь обязан вызвать IUnknown->Release() для уничтожения объекта.

Архитектура COM предполагает независимость от компиляторов, и поэтому бинарный формат COM-интерфейсов строго регламентирован[9].

COM-интерфейс можно воспринимать как базовый абстрактный класс - без конструктора, деструктора и полей данных. На самом деле, именно так он и описывается в C++.

Указатель на COM объект можно воспринимать как указатель на экземпляр класса, который наследован от базового абстрактного класса.

В бинарном виде указатель на COM объект представляет собой указатель на экземпляр объекта, в первых четырех байтах которого содержится указатель на таблицу виртуальных функций (vtable).

Для реализации архитектуры движка было решено использовать упрощенную COM модель, т.е. обмен интерфейсами осуществлялся между модулями системы, без их регистрации в системном реестре, что позволит в дальнейшем сделать эту архитектуру кроссплатформерной т.к. практически полные аналоги COM есть и в NIX'овых системах и приставках (по крайней мере XBox 360).

Проектирование архитектуры

В этом разделе я займусь описанием непосредственно спроектированной мною архитектуры движка.

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

Следующим шагом я разбил все технологии и решения, которые планируется заложить в базовую архитектуру движка по модулям и записал их в текстовом виде.

Ядро

Система журналирования

Сбор сведений об аппаратной составляющей ПК

Отладочная консоль

Базовая имплементация скриптовой системы

Система событий (сообщений)

Главная система событий

Менеджер подключаемых из модулей систем событий

Пространство рендеринга

Обработчик WinApi окна для Windows

Установка WinApi хуков для возможности рендеринга в «чужое» окно или компанент.

Система управления подключаемыми модулями (плагинами)

Базовая файловая система

Файловая система (FS) (Plugin)

Хранение файлов в паках (виртуальная файловая система)

Загрузчик текстур

Загрузчик шрифтов

Загрузчик моделей

Статичные модели

Анимированные модели

Загрузчик звуков и музыки

Загрузчик материалов

Универсальный загрузчик (возвращает указатель на файл)

Plugin Пользовательские форматы паков с данными

Plugin Пользоаптельские форматы текстур, шрифтов, моделей и т.д.

Игровые сцены (Plugin)

Статичные объекты

Динамические объекты

Ландшафт

Поддержка BSP и OCtree

Работа с камерами

Статичное освещение

Динамичное освещение

Определение столкновений

Система анализа видимости

Физический движок

2D спрайтовый движок

Менеджер системы частиц

Графический пользовательский интерфейс

Plugin Пользовательские компоненты интерфейса

Подсистемы менеджмента ресурсов

Менеджер текстур

Менеджер моделей

Менеджер звуков

Менеджер материалов

Plugin Пользовательский менеджер на базе основного

Plugin Пользовательские объекты сцены

Система менеджмента ввода (Plugin)

Обработка мыши

Обработка клавиатуры

Обработка джойстика

Система визуализации (графическая подсистема) (Plugin)

2D подсистема визуализации

Примитивы

Рендеринг текстур

Возможность совмещения 2D и 3D графики т.е. использование 3D моделей в двухмерной системе координат

Graphical User Interface (GUI)

Алгоритм уменьшения количества полигонов модели (Mesh LOD)

Отсечение по фрустуму

High Dinamic Range(HDR) освещение

Отражения

Graphical Processor Unit(GPU) программы

Рендеринг в текстуру

Рельефное текстурирование по технике normal mapping

Рельефное текстурирование по технике parallax mapping

Небо

Система рендеринга замкнутых помещений

BSP деревья

Статичные тени Lightmaps

Динамичные тени Shadow volumes

Оптимизация с использованием порталов

Рендеринг открытых пространств

Octree

Ландшафты (карты высот)

Динамические тени по технологии hardware shadow mapping

Звуковая система (Plugin)

Поддержка звуковых файлов формата OGG

Поддержка звуковых файлов формата WAV

3D звук, позиционирование в 3D пространстве, как источников звука, так и головы «слушателя»

EAX эффекты окружения

В резултате такого разбиения я систематизировал все планируемые «фичи». Определился с основными подсистемами движка и функционалом который они должны реализовывать. Так же я определил подсистемы которые тоже в свою очередь могу расширятся за счет сторонних плагинов. Теперь можно перейти к составлению схемы движка в целом. Понятно, что центральным элементом системы выступает ядро, все остальные системы, как уже неоднократно писалось выше подключаются к ядру. Пользователь же находясь на самом верхнем уровне абстракции общается только с интерфейсами предоставляемыми ядром, у него так же сохраняется возможность запросить интерфейс любой подсистемы и работать с ней напрямую, но об уровнях абстракции я напишу чуть ниже. В результате я спроектировал систему удовлетворяющую всем вышеупомянутым требования. Сама схема представлена на рисунке 3.

Рис. 3 Упрощенная схема архитектуры движка DPE

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

Уровни абстракции архитектуры движка

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

Движок все-таки накладывает определенные ограничения на пользователя, к примеру, опуститься до уровня GAPI(интерфейсов DirectX или OpenGL) ему никто не даст. Идеология движка заключается в том, что пользователь не получает исходные коды движка, в его распоряжении оказывается лишь набор интерфейсов, сам движок - набор библиотек и документация к интерфейсам. По этому изначально пользователю доступно лишь несколько верхних уровней абстракции, о которых я напишу чуть ниже.