Реферат
Эта статья является призывом для проведения исследований в области архитектуры игрового движка и дизайна, более всеобъемлющего и глубокого понимания которого мы считаем необходимым для его развития. Мы представляем ряд ключевых аспектов, которые могут помочь определить объём проблемы и предоставить каталог вопросов, которые, как мы считаем, определяют области, представляющие интерес для будущих исследований.
1. Введение
Начиная со Spacewar в 1961 году [Fleming 2007], компьютерные игры были повсюду в течение чуть более четырех с половиной десятилетий. Около двух десятилетий назад, большинство игр разрабатывались небольшими командой программистов, если не отдельными людьми, как правило, были написаны с нуля с очень немногими компонентами пригодными для повторного использования. В молодой отрасли, которая очень сильно проектно-ориентирована, это не стало большой неожиданностью; однако, когда отрасль выросла, вырос и размер проектов. Это изменение обусловило ряд достижений в технологии производства, и Гарлан и Шоу [Garlan и Show 1994 ] признали, что одной из характеристик прогресса в языках программирования и инструментов было регулярное повышение уровня абстракции — или концептуального размера программных дизайнерских строительных блоков
. Аналогичные повышения уровня абстракции произошли в течение развития компьютерных игр к концу 1980-х годов, когда появились первые системы с повторно используемыми компонентами. Это компоненты , которые мы сейчас называем игровыми движками.
Как выясняется, существует общее согласие, что игровые движки не только полезны, но в связи со сложностью современных компьютерных игр, действительно необходимы для разработки игр. Учитывая это, существует на удивление небольшой объем литературы по дизайну игровых движков. Имеющиеся исследования в основном сосредоточены на подсистемах игровых движков, таких как рендеринг, AI (искусственный интеллект) или сети. Тем не менее, вопросы, касающиеся общей архитектуры игровых движков, которые соединяют эти подсистемы, не менее важны.
Это отсутствие литературы и исследований, касающихся архитектуры игрового движка приводит в недоумение. Книги на эту тему, например, от Эберли [Eberly 2000 года], как правило, лишь кратко описывают архитектуру высокого уровня, вместо того, чтобы погрузиться прямо вниз до самого низкого уровня и описания того, как отдельные компоненты движка реализуются. Часто авторы представляют свою собственную архитектуру как де-факто решение для их определенного набора проблем, не обязательно оправдывая процессы принятия решений, которые привели к их конструкции, а лишь сообщают о личных предпочтениях авторов. Такая литература предлагает превосходный источник информации для написания движков, но дает мало помощи в проектировании оного, когда требования отличаются от описанного решения.
Мы считаем, что существует ряд моментов, которые должны быть исследованы, в отношении процесса разработки игрового движка. В данной работе мы не пытаемся ответить на вопросы, на которые необходимо получить ответы, но мы хотели бы привлечь академическое сообщество, а также игровую индустрию, к поиску этих ответов. Цель этого документа в первую очередь состоит в том, чтобы представить эти вопросы и обеспечить отправную точку для обсуждения, а также поощрять обсуждение разработки игровых движков и их архитектуры.
2. Вопросы исследования
В этом разделе мы представляем ряд вопросов, ориентированных на диапазон возможных тем исследований в рамках игр и разработки игровых движков. Вопросы, которые мы ставим можно грубо разделить на вопросы терминологии и вопросы архитектуры и дизайна игрового движка. При этом мы никоим образом не пытаемся дать их исчерпывающий список или даже изучить их подробно во всех деталях. Вместо этого мы надеемся, что мы можем разжечь обсуждения об этих и подобных темах, и вызвать более строгий осмотр их влияния.
2.1 Терминология нехватка языка Разработки игр
Игровая индустрия относительно молода, и как таковая она по-прежнему испытывает нехватку общей терминологии. Это верно внутри самой игровой индустрии, и между игровой индустрией и новыми играми, связанными с научными кругами. Однако для того, чтобы облегчить строгое изучение любого предмета, как с чисто академической, так и практической точки зрения, способность эффективно общаться имеет первостепенное значение.
Отсутствие формального терминологии приводит к коммуникации наперекор, как сетовал Стивенс [Stephens 2001], указывая на путаницу между понятиями Игровые движки
и Движки рендеринга
, ясно демонстрируя необходимость создания языка разработки игр.
Мы считаем, что такой язык должен охватывать определения игровых движков и компонентов этих движков, а также другие аспекты, связанные с разработкой игр, таких как жанр игры, ныне устаревшая классификация которого была представлена Сойером [Sawyer 1996]. Что касается технических аспектов архитектуры игрового движка, попытка Фолмера по созданию эталонной архитектуры [Folmer 2007] можно рассматривать как шаг в правильном направлении. Тем не менее, эти две темы представляют собой лишь небольшую часть предметной области и в дополнение к дальнейшему исследованию этих областей, дополнительное исследование необходимо, чтобы определить масштабы языка разработки игр.
2.2 Что есть Игровой Движок: где находится грань между игрой и игровым движком?
Как упоминалось выше, существуют разногласия по поводу того, чем именно является игровой движок, иногда с фундаментальными различиями в определениях. Симпсон [Simpson 2002] сообщает о путанице между игровыми движками и самими играми, а также об ошибочном описании игровых движков как игрового компонента для отображения графики игр.
Определения игрового движка, которые не ограничены отдельными компонентами движков, часто очень широки и расплывчаты. Например, Фреймворк состоит из набора различных инструментов, утилит и интерфейсов, которые скрывают детали низкого уровня различных задач, которые составляют видеоигру
[Sherrod 2007]. Возникает главная проблема в вопросе, где лежит граница между игровым движком и самой игрой.
Есть признаки того, что общий консенсус может быть слиянием в определение игрового движка, однако. Более конкретные описания были предложены, например от Льюиса и Якобсона [Lewis и Jacobson 2002], что игровые движки это набор модулей симуляционного кода, которые непосредственно не задают поведение игры (логику игры) или окружение игры (данные об уровне)
. Хотя это, безусловно, приближает нас к пониманию границы игрового движка и игровой логики, этот разрыв все еще четко не определён и остаётся множество перекрытий.
В качестве первого шага к исследованию игровых движков и их компонентов, исследования в этой области должны будут изучить компьютерные игры, чтобы определить программные компоненты, которые являются общими и уникальными для различных типов игр. Это должно привести к пониманию четкого различия между кодом игрового движка и игрового кода, помогая установить эту границу.
2.2.1 Наборы инструментов: Является ли набор инструментов частью игрового движка?
Вопрос, который становится все более актуальным состоит в том, что из набора инструментов, который должен сопровождать современный . В настоящее время художники для создания игрового контента используют в основном готовые пакеты 3D моделирования и анимации, такие как Maya или 3D Studio Max. Эти пакеты создания контента по большей части не были предназначены для создания игровых активов [Blow 2004], и должны быть дополнены экспортерами, редакторами мира и скрипт-редакторами, сделанными специально для игрового движка. Такие инструменты заполняют пробел между программным обеспечением генерации активов и игровым движком и часто обеспечивают интерфейс между художником и программистом. Без этих инструментов не было бы игры. Тем не менее, важный вопрос, который необходимо ответить, должны ли такие инструменты рассматриваться как входящие в рамки определения игрового движка?
2.3 Жанр игры: Как разные жанры влияют конструкцию игрового движка?
Дизайн и определение игрового движка в настоящее время оказываются неразрывно связаны с игрой которая использует движок. Обширную тематику компьютерных игр в целом можно подразделить на несколько игровых жанров, таких как игры стратегии-реального-времени (RTS) или шутеры-от-первого-лица (FPS). Коммерчески доступные игровые движки, как правило, более специализированными к требованиям, с которыми сталкиваются игры определенного жанра. Это позволяет им проводить жанроспецифические оптимизации, но, как правило, в ущерб гибкости. В то время как такие различия между жанрами часто вытекают в различия между подходами, сосредоточив внимание на общности нам следует начать получать перспективу и более четкое определение того, чем является игровой движок и из каких компонентов он должен состоять.
Мы считаем, что формальное изучение конструкции движка по отношению к жанру может привести к определению игрового движка, который не зависит от жанра.
2.3.1 Убердвижок (uberengine): Можно ли создать игровой движок независимый от жанра?
В настоящее время игровые движки в основном написаны для конкретных игровых жанров. Для каждого из них необходимы некоторые оптимизации и при попытке придумать более общее решение возникают трудности. Возможность использовать один игровой движок для любого жанра игры, вместо использования ряда жанроспецифичных движков, однако, потенциально может обеспечить большую выгоду разработке игр. Помимо финансовой экономии в связи с использованием только одной системы, которая должна поддерживаться, uberengine
будет содействовать передаче программистов и художников между проектами.
Пока что ещё нет систематики игровых движков, которая бы позволила определить все общие черты между различными игровыми движками. Хотя внешне многие движки, кажется, имеют аналогичные функциональные возможности, вопрос, который нуждается в постановке — есть ли что-то, что можно было бы назвать игровым движком, который пригоден играм любого жанра. Другими словами, при осмотре двух совершенно разных игр разных жанров, сможет ли разработчик распознать движок
в каждой из них, особенно учитывая широкий спектр игр, которые включают так называемые серьезные игры
, которые зачастую являются симуляциями сценариев реального мира? Мы убеждены, что решение этой проблемы окажется возможным, в конце концов.
2.4 Зависимости дизайна: Как проблемы низкого уровня влияют дизайн верхнего уровня?
Эталонные архитектуры, такие как по Доэрти [Doherty 2003] или Фольмеру [Folmer 2007] приводят описание дизайна верхнего уровня, но редко исследуют влияние проблем низкого уровня на системную архитектуру как таковую. По нашему убеждению манера, в которой вопросы низкого уровня влияют на архитектурный дизайн и неразрывно связаны с фактом очень быстрого темпа технологических изменений. Такие технологические изменения происходят на низком уровне, с точки зрения аппаратного или программного обеспечения интерфейсов и возможностей, и могут напрямую влиять на эволюцию отдельных или нескольких компонентов игрового движка.
Например, несколько лет назад функция рендеринга была достигнута с использованием фиксированной функции конвейера, в то время как сегодня мы используем программируемые шейдеры. Изначально можно было предположить, что такие изменения будут ограничены в пределах одного модуля или компонента игрового движка. В случае шейдеров, это, очевидно, будет связано с рендерингом. Тем не менее, также возможно, что функциональность может быть переведена из одной части движка в другую, например, часть расчетов физического движка могла бы быть выполнена с помощью шейдеров.
Другой пример — использование нескольких процессоров, предоставляющих ресурсы, которые современный игровой движок должен использовать максимально эффективно. Эти ограничения и требования приведут к фундаментальным изменениям в архитектуре игрового движка (на некотором уровне или других), превращая архитектуру движка в многопоточную [Tulip et al.2006].
Понятно, что технологические изменения влияют высокоуровневую архитектуру, но еще не установлено, в какой степени. Кроме того, необходимо задать вопрос, есть ли какие-либо методы проектирования движка, которые могут применяться для минимизации влияния будущего внедрения новых разработок в технологию компьютерных игр.
2.5 Лучшая практика: Существуют ли конкретные методы проектирования или архитектурные модели, которые используются или должны быть использованы, для создания игрового движка?
Здравый смысл подсказывает, что проектирование сверху вниз, и реализация снизу вверх обеспечит решение подходящее для разработки игровых движков. Тем не менее, не важно как игровые движки появляются на свет. Эмпирические наблюдения показывают, что многие движки растут и развиваются с течением времени. Опасность растущих проектов заключается в том, что функции могут выйти из-под контроля, явление, известное как ползучесть характеристик
, как правило, из-за того, что первоначальные цели были плохо определены в начале проекта. Это оборачивается неудачей, когда реализация, наконец, встречается с оригинальными требованиями, когда цели уже могли измениться. Архитектура, однако, может быть не в состоянии поддерживать эти новые требования, и становится необходимым добавление обходных путей, ласково называемых хаками
. Как кратко упомянуто выше, значительная часть имеющейся литературы, кажется, не замечает этот вопрос вообще, концентрируясь исключительно на реализации отдельных компонентов движка, подходя к делу с точки зрения микроархитектуры, в отличие от макроархитектуры.
Вопрос, который мы ставим, есть ли наилучшая практика
для разработки игровых движков, которая может помочь устранить или, по крайней мере, уменьшить эти проблемы?
3. Резюме исследовательских вопросов
Хотя, как правило, атаковать
конкретные проблемы просто, научный подход будет тянуть назад, чтобы увидеть более широкую картину и выявить тенденции. Эта абстракция затем может быть использована для выявления пробелов в области знаний и открыть идеи, которые другие могли упустить из виду. Наша задача, как ученых, состоит в том, чтобы смотреть на различные дизайны и найти общности, чтобы позволить нам попытаться собрать воедино лучший дизайн
.
Целью данного призыва к исследованиям является повышение академического интереса в области архитектуры и дизайна игрового движка. Поэтому нашу программу исследований можно определить как:
- создание единого языка разработки игр;
- идентификация программных компонентов, которые являются общими для всех видов компьютерных игр;
- установление четких границ между игровым движком (код) и игровым кодом;
- определение роли инструментов создания контента в процессе разработки игры и как части игровых движков;
- идентификация связей между игровыми жанрами и архитектурой игрового движка;
- идентификация компонентов, которые являются общими для всех типов игровых движков, что позволяет определить эталонную архитектуру жанронезависимого игрового движка;
- исследование влияния низкоуровневых вопросов на высокоуровневую архитектуру игрового движка;
- идентификация «наилучшей практики» для разработки игровых движков.
В данной работе мы определили несколько ключевых аспектов, которые могут помочь определить пространство проблемы архитектуры и дизайна игрового движка. Мы поставили ряд вопросов, которые, по нашему мнению, могут предоставить направления для будущих инициатив. Возможным следующим шагом будет организация ознакомительного совещания заинтересованных сторон из индустрии и научных кругов. Это может привести, впоследствии, к созданию комитета или рабочей группы по координации исследований по данным темам и получению возможных конечных результатов, являющихся открытым общепринятым стандартом разработки игровых движков.
Список источников
1. Blow, J. 2004. Game development harder than you think. ACM Queue 1, 10, 28–37.
2. Doherty, M. 2003. A software architecture for games. University of the Pacific Department of Computer Science Research and Project Journal 1, 1.
3. Eberly, D. H. 2000. 3D Game Engine Design. Morgan Kaufmann.
4. Fleming, J., 2007. Down the hyper-spatial tube: Spacewar and the birth of digital game culture. Available from: http://www.gamasutra.com.
5. Folmer, E. 2007. Component based game development. In Component-Based Software Engineering, vol. 4608 of LNCS, 66–73.
6. Garlan, D., and Shaw, M. 1994. An introduction to software architecture. Tech. Rep. CMU/SEI-94-TR-21,ESC-TR-94-21, Carnegie Mellon University, Pittsburgh, PA. CMU Software Engineering Institute.
7. Lewis, M., and Jacobson, J.2002. Game engines in scientific research. Communications of the ACM 45, 1,27–31.
8. Sawyer, B. 1996. The Ultimate Game Developer’s Source-book. Coriolis.
9. Sherrod, A. 2007. Ultimate 3D Game Engine Design & Architecture. Charles River Media.
10. Simpson, J. , 2002. Game engine anatomy 101. Available from: http://www.extremetech.com.
11. Stephens, N., 2001. “game engine” versus “rendering engine”. Letters to the Editor, http://www.gamasutra.com.
12. Tulip, J., Bekkema, J., and Nesbitt, K. 2006. Multi-threaded game engine design. In Proceedings of the 3rd Australasian Conference on Interactive Entertainment, 9–14