Анализ проблем архитектуры компьютерных игр

Аннотация:

Тилинина Н.Ю., Губенко Н.Е. Анализ проблем архитектуры компьютерных игр. В представленной статье рассматриваются основные проблемы существующих современных методов разработки архитектур компьютерных игр, проводится анализ в результате которого представлены условия создания «хорошей архитектуры».

Ключевые слова: архитектура, графика, ПК, разработчик, компьютерная игра, компоненты системы

Постановка проблемы

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

«Архитектура – это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а также принципы, определяющие проектирование и развитие системы» (Стандарт IEEE 1471). Абсолютно любая игра имеет архитектуру вне зависимости от того, проектировалась она или нет. Архитектура может быть восстановлена уже по существующей игре. При создании игры проработка архитектуры может существенно уменьшить объем работ при её реализации, так как исправление архитектуры в общем случае проще, чем исправления кода реализации [1]. Описание архитектуры позволяет скрыть сложность игры при помощи абстракции и разделения ответственности между подсистемами. Наличие описания архитектуры, как правило, упрощает обсуждение и принятие решений, касающихся разрабатываемой игры.

Современные методы и их недостатки

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

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

Методы Кевина Хавкина и Дэвида Астла, которые описаны в книге под названием OpenGL Game Programming – хороший пример типичной «методички» о разработке игр. Книга раскрывает многие тонкостей графики в играх и рассказывает о том, как их можно реализовать с помощью OpenGL API. Здесь освещены аналитическая геометрия, принципы освещения, текстурирования, трансформаций и различные другие темы, посвященные программированию трехмерной графики. После прочтения этой книги читатель будет иметь 214 основательные познания в области графики и OpenGL API, но использование этих знаний в контексте сложной системы, такой как, например, игра, останется для него загадкой [3].

Получается, что несмотря на то, что охвачены многие технические детали формирования пикселей с помощью OpenGL, практически не содержится информации об условиях создания хорошей и легко модернизируемой архитектуры игры. Методы, используемые в книге, имеют чрезвычайно упрощенную архитектуру. Один единственный игровой объект вмещает в себя все – графику, ИИ, физику и т.д. (см. рис.1)

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

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

Руди Ракер в своей книге Software Engineering and Computer Games представляет метод с повторно используемой архитектурой. Автор рассматривает создание каркаса игры по принципу "Документ\Вид" приложения. Упор делается на то, что, используя описанный каркас, любой разработчик может создать игру, просто расширяя этот каркас, предлагаемый автором в качестве средства решения всех проблем [4].

Метод создания архитектуры "документ\вид" используется для того, чтобы отделить данные от кода, ответственного за их визуализацию, и вследствие этого появляется возможность изменения данных без переписывания кода. Эта идея предоставляет большую гибкость в вопросах, связанных с игровыми объектами, в тоже время она достаточно ограничена. Искусственный интеллект и физика все еще остаются в ведении объекта, что делает их изменение чрезвычайно затруднительным. Таким образом, в авторской архитектуре система визуализации представляет собой нечто отделенное от объекта, однако при этом продолжается использование механизма прямого, непосредственного взаимодействия между графикой и данными, что делает оба компонента взаимозависимыми и что противоречит выбранному шаблону проектирования "документ/вид".

Роллингс и Моррис, авторы Game Architecture and Design, дают обзор уже существующих архитектурных моделей игровых приложений и пытаются выделить основные элементы игровой архитектуры (см. рис 2).

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

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

Переход к сторонним компонентам

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

Переход к системам, построенным на COTS, является первым шагом на пути масштабного изменения игр, принципов их разработки и планирования. Однако несмотря на то, что метод использования готовых компонентов способен улучшить качество игры и сократить время ее разработки, использование объектноориентированного подхода приведет к тому, что компоненты едва ли будут более полезны, чем обычные библиотеки функций, помогающие оперировать объектами. В таком случае игровые объекты будут все еще ответственны за обработку своих же данных, а именно, за рендеринг, за искусственный интеллект, звук, и т.д. 216 Другими словами, при создании архитектуры, разработчики пытаются использовать преимущества COTSкомпонентов, но вместе с этим оперируют слишком большими и сложными игровыми объектами. Что, в свою очередь, приводит к тому, что при разработке объектов создатели игры жестко привязаны к используемым COTS–компонентам (см. рис. 3).

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

Применение готовых игровых «движков»

К настоящему моменту в развитии игровой индустрии можно выделить общую тенденцию совмещения всех COTS–компонентов в игровом ядре, также известном как игровой «движок». Компании, которые разрабатывают игры покупают очень мощные и эффектные игровые «движки», что позволяет им создавать игру, используя уже проверенный и надежный каркас. Этот прием является выдающимся примером повторного использования кода, вместе с тем, возможными последствиями таких покупок могут быть ограничения возможностей разработчиков потому, что сторонний движок может не учитывать особенностей игры. Использование игровых «движков» создает ограничения через архитектуру «движка». Они обычно создаются под конкретную игру, и это сказывается на их архитектуре. Например, попытка использовать Unreal Engine, который подходит игре от первого лица, для создания футбольного симулятора закончится неудачей

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

Условия хорошей архитектуры

Таким образом, с учетом представленных выше проблем, можно сформулировать список вполне разумных и универсальных критериев, которые помогут в создании хорошей архитектуры компьютерной игры:

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

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

Выводы

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

Литература

1. Создание архитектуры программы или как проектировать табуретку [Электронный ресурс] // Stimul, 2018: [сайт] – Режим доступа:http://www.stimul.biz/ru/ru/lib/articles/mind–maps – Загл. с экрана.
2. Архитектура игры [Электронный ресурс] // gamedev.ru, 2018: [сайт] – Режим доступа: https://gamedev.ru/code/terms/Architecture – Загл. с экрана
3. Astle D., Beginning OpenGL game programming / Astle D., Hawkins K. – 1–е изд. – Course Technology PTR, 2004. – 337 с.
4. Rucker R., Software Engineering and Computer Games/ Rucker R. – 1–е изд. – Addison–Wesley Professional, 2002. – 642 с.
5. Rollings A., Game Architecture and Design/ Rollings A., Morris D.– 1–е изд. – New Riders, 2003. – 960 с