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

Резюме

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

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

1. Введение

1.1. Игры сегодня

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

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

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

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

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

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

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

Рис 2. Представление игры в объектно-центрированной модели

1.1.2. Переход к COTS
(прим. перев. COTS - component off the shelf, методология, предписывающая разработчикам использование сторонних компонентов.)

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

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

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

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

1.1.3. Применение готовых игровых движков

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

• Ограничения через архитектуру движка. Игровые движки обычно создаются под конкретную игру, и это сказывается на их архитектуре. Попробуйте использовать Unreal Engine, движок игры от первого лица, для создания футбольного симулятора.
• Ценовые ограничения. Игровые движки являются чрезвычайно дорогими. Передовой движок может стоить сотни тысяч долларов [2] (уже миллионы - прим. ред.). Решение об использовании подобных движков заранее означает, что игра должна стать хитом, чтобы окупить начальные вложения. К сожалению, для того чтобы удовлетворить запросы максимального сегмента рынка, разработчики значительно ограничены в выборе типа, жанра и специфики создаваемой игры.

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

1.2. Цели и задачи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3. Решаемые в данной диссертации задачи

Основными задачами, решаемыми в данной диссертации, являются следующие:

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

2. Обзор литературы по вопросам разработки архитектуры ПО

2.1. Описание разработки игр в современной литературе

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

Книга Кевина Хавкина и Дэвида Астла (Kevin Hawkin and David Astle) под названием OpenGL Game Programming - хороший пример типичной книги о разработке игр. Книга раскрывает многие тонкости графики в компьютерных играх и рассказывает о том, как реализовать их с помощью OpenGL API. В книге освещены аналитическая геометрия, принципы освещения, текстурирования, трансформаций и различные другие темы, посвященные программированию трехмерной графики. После прочтения этой книги читатель будет иметь основательные познания в области графики и OpenGL API, но использование этих знаний в контексте сложной системы, такой как, например, игра, останется для него загадкой.

Получается, что несмотря на то, что книга очень хорошо написана, охватывает многие технические детали формирования пикселей с помощью OpenGL, она практически не содержит информации об архитектуре игры. Примеры, используемые в книге, имеют чрезвычайно упрощенную архитектуру. Один единственный игровой объект вмещает в себя все - графику, ИИ, физику и т.д. (см. рисунок 4 ниже). Такой подход к описанию игры возможен в случае рассмотрения какой-либо детали, специфичной части игры, но он является АБСОЛЮТНО неадекватным, неправильным в случае реальных игр. Простейшего логического деления на уровне классов абсолютно не достаточно для проекта, объем которого стремиться к миллионам строк кода.

Рис 4. Структурная декомпозиция на уровне объектов\классов

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

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

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

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

2.2. Последние новости с книжного фронта разработки игр

2.3. Первая и единственная попытка описания игровой архитектуры

Книга Эндрю Роллингса и Дэйва Морриса (Andrew Rollings and Dave Morris), названная Game Architecture and Design, единственная к настоящему моменту книга, которая рассказывает о разработке игр с точки зрения их архитектуры. Предложенная в книге архитектура спроектирована по принципу Дэйва Родерика, смысл которого заключен в следующей фразе: "Игра - это просто база данных реального времени с красивым интерфейсом пользователя". Такое утверждение может показаться верным, однако данная диссертация придерживается слегка измененного принципа Родерика: игра - это система компонентов, работающих с базой данных, и имеющая красивый интерфейс пользователя.

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

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

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

2.4. Архитектура программного обеспечения

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

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

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

3. Методология

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

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

Далее, после выполнения предварительных исследований (шаги 1 и 2), приступим непосредственно к проектированию архитектуры. На данном этапе необходимо произвести расширение выбранной архитектурной модели за счет объединения различных идей и подходов других моделей. Это необходимо для того чтобы учесть не только изначальные требования к архитектуре, описанные в главе 1, но и добавить дополнительные функциональные возможности, выявленные на стадии анализа. Дальнейший процесс проектирования - путь проб и ошибок, путь уточнения и дополнения архитектуры, выбранной за базовую, то есть обычный процесс разработки, в результате которого постепенно будет вырисовываться окончательная архитектура. После того как архитектура будет спроектирована, наступает ответственный момент проверки ее жизнеспособности. Сперва нужно попробовать применить архитектуру при разработке простейшей модели одной из ранее рассмотренных игр. Это поможет проверить, что поддерживает ли разработанная система функционал, заложенный в процессе проектирования. Следующим шагом проверки является построение системы близкой по масштабам к настоящей игре и качественная проверка параметров заложенных в архитектуру. К сожалению, разработка полноценной версии игры коммерческого уровня для полной демонстрации возможностей спроектированной архитектуры выходит за рамки данной диссертации. Тем не менее, будет построен прототип игры, на примере которого будут продемонстрированы важнейшие черты, функции и качества архитектуры. Прототип поможет выявить плюсы и минусы, возможности и ограничения, а также основные принципы использования спроектированной архитектуры.

3.1. Анализ игр с точки зрения ПО

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

3.1.1. Выбор игр для анализа

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

Игровые жанры также делятся на несколько подкатегорий, например одиночные (singleplayer) игры и игры по сети, игры с 2D и 3D графикой, и т.д., очевидно, что архитектура игры подобных подгрупп в целом одинакова, c учетом некоторых дополнений, связанных со спецификой подгруппы. Так, например, различия между играми с 2D и 3D графикой, но принадлежащими к одному жанру, локализованы в одном компоненте, однако, типы компонентов и схемы их взаимодействия остаются одинаковыми. В итоге я надеюсь убедить вас, что одна архитектура способна обеспечивать построение всех, подобных игр.

3.1.1.1. Существующие жанры игр

• Файтинг
  Рынок впервые узнал о существовании игр этого жанра в далеком 1991 благодаря Capcom и Street Fighter II. У молодых (и не очень) геймеров появилась возможность слиться воедино со своим воинствующим аватаром и вступить в рукопашный бой с другими героями. Это было начало золотой эры аркадных игр [15]. Такие игры наиболее просты по своей природе. Они должны быть простыми для игрока, быстрыми и захватывающими.
• Шутер от первого лица (FPS)
  Этот жанр был создан Джоном Кармаком (John Carmack) и студией id Software в 1992 году вместе с игрой Wolfenstein 3D [4]. Игра предзнаменовала начало новой эры трехмерных миров в компьютерных играх. К этому жанру можно отнести очень разнообразные игры - от Doom и Quake, сводящихся к примитивному "убей их всех", до комплексного с точки зрения геймплея проекта Halo. Игры этого жанра чаще всего находятся на острие технологического прогресса, что особенно заметно по графике. Гонка технологий, используемых в таких играх - настоящее бедствие для игрового рынка.
• Платформер
  Наверняка каждый из вас помнит Super Mario Bros. и Donkey Kong. В этих проектах игрок ведет своего незадачливого персонажа через разнообразные лабиринты. От игрока требуется реакция и отличное владение джойстиком. Рынок платформеров относительно невелик на ПК, но доминирует на консолях.
• Стратегия
  Современные "электронные" стратегии - прямые потомки настольных предков. Суть представителей этого жанра в следующем: устанавливается система правил, в рамках которой игрок решает задачи, полагаясь на тактику и стратегическое мышление, а не на быстроту реакции. Жанр включает в себя игры от пошаговой 2D-классики Civilization до трехмерной и реальновременной Warcraft III.
• Ролевая игра (RPG)
  Ролевые игры также уходят корнями в среду, далекую от электронных устойств. Это фактически интерактивные истории, в которых игрок принимает на себя роль одного из персонажей. Один из столпов таких игр - "прокачка" героя - управление им с целью развития определенных навыков и способностей.
• Спортивный симулятор
  В упрощенном виде, это компьютерные версии реальных видов спорта. Дают выступить в роли профессионального атлета, не положив всю жизнь на тренировки. Кроме того, недовольные результатом суперкубока, вы можете устроить матч-реванш в Madden NFL со своим соседом.

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

3.1.1.2. Некоторые специфичные отличия игр

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

• 2D и 3D игры
  • 2D-игры работают с двухмерным пространством. Примерами таких игр являются игры аркадного жанра, например Super Mario Brothers, и стратегии, например Starcraft.
  • Мир 3D-игр имеет три измерения. Важно различать 2D-игры, использующие 3D-графику, например Warcraft 3, и истинные 3D-игры с трехмерным представлением мира, например Quake. В нашем случае это различие является важным из-за того, что игры 2D и 3D могут отличаться не только в графической области, но и в других компонентах, таких как ИИ, физика и т.д. Все игры попадают в ту или иную категорию, поэтому окончательный выбор должен содержать по одной игре из каждой группы.
• Не-сетевые, сетевые и Многопользовательские игры
  • Игры, не поддерживающие игру по сети, не требуют поддержки распределенных данных и распределенного исполнения кода. Практически все игры поддерживают данный тип.
  • Сетевые игры - это игры, в которых игроки участвуют в совместной игре, их взаимодействие обеспечивается сетевыми технологиями. Большинство подобных игр используют простую клиент-серверную модель взаимодействия и обычно ограничивают максимальное число игроков (клиентов), одновременно играющих по сети.
  • Многопользовательские игры (Massively Multiplayer Online Games - MMOG). Некоторое время существовали в виде текстовых многопользовательских игр (MUD), но затем обрели второе дыхание и стали чрезвычайно популярными с приходом 3D-графики в этот вид игр. Примером подобной игры может служить Everquest. MMOG поддерживают одновременное присутствие тысяч игроков в виртуальном мире. Мы не будем рассматривать этот особый и дорогой на настоящий момент вид игр, но я уверен, что эта тема станет предметом будущих исследований.
• Различия в ИИ - единичные юниты или группы, команды
  • ИИ для единичных юнитов предполагает наличие интеллекта у отдельного игрового объекта, который меняет свое поведение в зависимости от ситуации. В играх с таким вариантом ИИ не существует общего "мозгового центра", координирующего действия юнитов в соответствии с некой общей стратегией.
  • Игры с командным ИИ расширяют предыдущую модель и вносят в игру эффект взаимодействия между игровыми объектами. Объекты по-прежнему могут иметь свой собственный разум, но в игре появляется новая, отдельная от игровых объектов система, отвечающая за тактику и стратегию.

3.1.2. Игры, выбранные для анализа

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

Starcraft

Первой анализируемой игрой будет стратегия Starcraft от Blizzard Entertainment. Особенностями этой игры являются двухмерная изометрическая графика и превосходный, один из самых увлекательных, игровой процесс. Игра была выпущена в 1998 году и надолго стала эталоном в жанре стратегий в реальном времени (RTS). Выбрана для анализа в силу следующих причин: она является двухмерной, предлагает однопользовательский вариант игры и обладает командной системой ИИ.

Рис 6. Starcraft

Unreal Tournament

Unreal Tournament - игра компании Epic Games Inc. - является одним из лучших сетевых экшенов от первого лица. Игра способна одновременно поддерживать до 16 игроков, которые находятся на футуристичных аренах для боев и пытаются убить друг друга. Игра является трехмерной, игрок способен управлять одним персонажем (в общем случае). Первая игра из серии Unreal была выпущена в 1999 году, а все последующие стали планомерным развитием и улучшением базовой технологии. Unreal Tournament выбрана для анализа в силу следующих причин: она является трехмерной игрой, поддерживает игру по сети, и заложенный в нее ИИ в основном управляет одиночными юнитами.

 
Рис 7 и 8. Unreal Tournament

3.1.3. Анализ выбранных игр

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

Начнем с рассмотрения требований заказчиков/игроков, которым должна удовлетворять реальная игра. Будем выявлять подсистемы, необходимые в проектируемой архитектуре.

3.1.3.1. Анализ требований Starcraft с применением технологии Use Case
[Прим. пер. Use Case - технология сбора и анализа потенциальных требований, предъявляемых заказчиком к проектируемому ПО. Анализируются несколько возможных сценариев взаимодействия проектируемой системы с конечным пользователем или программой-посредником. Доп. инф. см. по адресу: en.wikipedia.org/wiki/Use_Case.]

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

Рис 9. Use-case диаграмма "играем в Starcraft"

Рис 10. Декомпозиция системы на уровне модулей

Основываясь на функциональной диаграмме (рис. 9), мы можем определить набор логических модулей, используемых в проекте Starcraft. Графический модуль отображает двухмерные объекты, модуль интерфейса пользователя обрабатывает команды игрока и т.д. Подчеркну, что диаграмма 10 просто перечисляет типы функциональности, поддерживаемые в игре, она не является диаграммой компонентов и не показывает их физическое разделение, т.е. разделение на уровне кода.

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

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

3.1.3.2. Рассмотрение взаимодействия модулей системы

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

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

Рис 11. Выбор объекта (межсистемное взаимодействие)

На рисунке 11 показан пример межсистемного взаимодействия. Фокус в том, что представленная диаграмма не является схемой архитектуры. Эта диаграмма описывает последовательность действий, выполняемых по сценарию "Выбор объекта", и показывает, каким образом графическая подсистема вплетена в процесс маршрутизации сообщения о нажатии на клавишу мыши и выбора соответствующего объекта. Судя по диаграмме 11, система игровой логики вызывает графическую систему, однако вместо нее (системы игр. логики) может быть и другая система. Возможно, что переменная (поле), хранящее текущую позицию на экране, является частью объекта из системы игровых данных (Game Data), и значение этой переменной устанавливается графической системой совсем в другое время, а не в момент, показанный на рисунке 11. Важным является следующее - для того чтобы определить, какой из игровых объектов выделен, необходимо участие двух систем: системы пользовательского интерфейса и графической системы. Прискорбно, но для того чтобы мы могли начать создавать архитектуру, необходимо проанализировать все важнейшие сценарии взаимодействия. (Другие цепочки взаимодействия различных компонентов рассмотрены в приложении.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература

[1] "3 Million Lines of Code." EdGames. Sept. 13 2004.

[2] "3D Engines Database: Unreal Engine 3." DevMaster.net. Sept 14. 2004.

[3] "A $30 Billion Dollar Industry." Aug. 2003.

[4] "A Brief History of the FPS." Aug. 2003.

[5] Adolph, Steve "Reuse and Staying in Business." Gamasutra. 12 Dec. 1999. Sept 12. 2004.

[6] Alves, Carina. Joao Bsco Pinto Filho and Jaelson Castro. "Analysing the Tradeoffs Among Requir ements, Architectures and COTS Components." Centro de Informatica, Universidade Federal de Pernambuco Recife, Pernambuco. Sept. 5 2004.

[7] Bass, Len. Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley, 1998.

[8] Busto, Roberto Del. "Games and Simulations." Aug. 2003.

[9] Calvert, David. "Software Architectural Styles." 3 June 1996. Aug. 16 2004.

[10] "Definition: System of Systems." The Free Dictionary.com. Oct. 7 2004.

[11] "Domain-specific Software Architectures." Aug. 2003.

[12] Duffy, R. "Software Architecture." Sept. 12 2004.

[13] E. Berard. Essays in Object-Oriented Software Engineering. Prentice Hall, 1992.

[14] Fristrom, Jamie. "Manager in a Strange Land: Most Projects Suck." Gamasutra. 17 Oct. 2003. Sept. 12 2004.

[15] "History of Arcade Games." Aug. 2003.

[16] "How to Make a COTS Project Fail." Aug. 2003.

[17] Nilson, Roslyn; Kogut, Paul; & Jackelen, George. Component Provider's and Tool Developer's Handbook Central Archive for Reusable Defense Software (CARDS). STARS Informal Technical Report STARS-VC-B017/001/00. Unisys Corporation, March 1994.

[18] Rollings, Andrew and Dave Morris. Game Architecture and Design. The Coriolis Group, 2000.

[19] Sloan, Jason and William Mull. "Doom 3 FAQ." Aug. 2003.

[20] "Unreal Tournament History". Oct. 20 2004.