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

В настоящее время существует большое количество книг посвященных теме разработки игр. Однако большинство из них описывает детали специфичных сфер разработки, а не архитектурные модели и общие подходы к разработке игр. Разумеется, эти книги в той или иной мере решают свои задачи, однако не существует вообще никакой литературы о том, как организовать описываемые первыми книгами конкретные специализированные компоненты игр в готовый продукт, в законченную игру.
Книга Кевина Хавкина и Дэвида Астла (Kevin Hawkin and David Astle) под названием OpenGL Game Programming - хороший пример типичной книги о разработке игр. Книга раскрывает многие тонкости графики в компьютерных играх и рассказывает о том, как реализовать их с помощью OpenGL API. В книге освещены аналитическая геометрия, принципы освещения, текстурирования, трансформаций и различные другие темы, посвященные программированию трехмерной графики. После прочтения этой книги читатель будет иметь основательные познания в области графики и OpenGL API, но использование этих знаний в контексте сложной системы, такой как, например, игра, останется для него загадкой.
Получается, что несмотря на то, что книга очень хорошо написана, охватывает многие технические детали формирования пикселей с помощью OpenGL, она практически не содержит информации об архитектуре игры. Примеры, используемые в книге, имеют чрезвычайно упрощенную архитектуру. Один единственный игровой объект вмещает в себя все - графику, ИИ, физику и т.д. (см. рисунок 4 ниже). Такой подход к описанию игры возможен в случае рассмотрения какой-либо детали, специфичной части игры, но он является АБСОЛЮТНО неадекватным, неправильным в случае реальных игр. Простейшего логического деления на уровне классов абсолютно не достаточно для проекта, объем которого стремиться к миллионам строк кода.
Для того чтобы увидеть проблемы, связанные с подобным микроскопическим подходом к архитектуре, рассмотрим некоторые вопросы, с которыми постоянно сталкиваются разработчики компьютерных игр. Во-первых, подобная схема не затрагивает вопросов совместимости, крайне важных при коммерческом подходе к игре: игра должна работать как на многочисленных игровых консолях, так и на ПК. Во-вторых, подобный код напрочь лишен возможности повторного использования из-за того, что объект намертво привязан к своему поведению. Таким образом, данная часть архитектуры не является ни гибкой, ни масштабируемой из-за того, что она представляет собой систему со слишком тесной связью и, изменяя ее, вы рискуете повлиять на всю систему в целом.
Книга Руди Ракера (Rudy Rucker) Software Engineering and Computer Games делает попытку научить разработке игр с повторно используемой архитектурой. В книге рассматривается создание каркаса игры по принципу "Документ\Вид" приложения. Упор делается на то, что используя описанный в книге каркас, разработчик может создавать различные игры, просто расширяя этот каркас, предлагаемый автором в качестве "народного автомобиля" и средства решения всех проблем.
Книга рассказывает о том, каким образом шаблоны проектирования могут быть использованы в контексте разработки игровых приложений, и почему возможность повторного использования кода так важна для разработчиков игр. Автор использует архитектуру "документ\вид" для того, чтобы отделить данные от кода, ответственного за их визуализацию, и вследствие этого появляется возможность изменения данных без переписывания кода.
Данная идея предоставляет большую гибкость в вопросах, связанных с игровыми объектами, в тоже время она достаточно ограничена. Искусственный интеллект и физика все еще остаются в ведении объекта, что делает их изменение чрезвычайно затруднительным. Таким образом, в авторской архитектуре система визуализации представляет собой нечто отделенное от объекта, однако при этом автор продолжает использовать механизмы прямого, непосредственного взаимодействия между графикой и данными, что делает оба компонента взаимозависимыми и что "слегка" противоречит выбранному шаблону проектирования "документ/вид".

2.2. Последние новости с книжного фронта разработки игр
Большинство последних книг, посвященных разработке игр - такие как, например, Game Programming Gems или AI Game Programming Wisdom - предполагают, что их читатели являются достаточно опытными разработчиками. Приведенный в этих книгах различный код представляет собой хорошие решения различных часто встречающихся проблем. Вопросы, решаемые в этих книгах, принадлежат к классу проблем, часто возникающих в процессе реализации различных идей, и их решения обычно описываются одним-двумя классами на языке C++.
Подобные книги - действительно большие помощники в области разработки игр, предлагаемые в них решения практически не зависят от выбранной при разработке архитектурной модели. В общем, это книги для программистов, занимающихся непосредственно реализацией различных алгоритмов предметных областей, но не для системных проектировщиков. Иными словами, рассматриваемые книги, что называется, обязательны к изучению всем, кто занимается играми, но в них ничего не говорится о том, как из описанных жемчужин создать цельное ожерелье. Руководствуясь предлагаемыми решениями, разработчики смогут решать трудные и специфичные задачи, но они могут не понимать, как собрать описанные кусочки в рабочую систему и где, в какой части системы можно применить полученные знания наилучшим образом.

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

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

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

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

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

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

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

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