210 likes | 355 Views
Разработка AI Middleware SDK. Алексей Осипенко Руководитель службы R&D Buka Entertainment Enterprises oalexey@buka.ru. Почему об этом имеет смысл подумать?. Разработка игровой логики является одним из самых проблемных мест в gamedev -е.
E N D
Разработка AI Middleware SDK. АлексейОсипенко Руководитель службы R&D Buka Entertainment Enterprises oalexey@buka.ru
Почему об этом имеет смысл подумать? • Разработка игровой логики является одним из самых проблемных мест в gamedev-е. • Это одно из самых недетерминированных мест в разработке... • ... и определяющих, получится ли, в итоге игра или нет.
Проблема изменения архитектуры • Геймдизайнеры предлагают изменения в системе игровой логики не сообразуясь с ее программной архитектурой. • Изменения вносятся на поздних этапах работы, когда большая часть кода уже написана. • Постепенно утрачивается концептуальная целостность. • Архитектура перестает быть понятной самим программистам.
Как можно изменить эту ситуацию • Все члены команды, имеющие отношение к логике игры, должны иметь представление о ее программной архитектуре. • Это представление должно опираться на простую графическую модель архитектуры. • Модель должна соответствовать текущему положению дел. • Поддержание соответствия модели и программного кода не должно вносить дополнительные накладные расходы.
Откуда можно взять модель • Архитектура содержится в программном коде и должна извлекаться из него. • Механически извлеченная из кода модель почти всегда имеет бессистемный характер – все абстракции «свалены в одну кучу». • Такая модель «замусорена» деталями реализации и вспомогательными абстракциями. • Невозможно вычленить многие значимые идеи.
Возможный способ преодоления описанных трудностей • Использовать инкапсуляцию для фильтрации малозначимых деталей. • Программисты должны скорпулезно следовать механизмам инкапсуляции, предусмотренным в языке. • Визуализировать только интерфейсы. • Помечать важные абстракции комментариями специального вида. • Подчас, трудоемко и не поддаётся верификации. • Механизмы все равно остаются «за кадром»!
Можно «зайти с другого конца» • Строить не модель по коду, а код по модели. • Преимущества: • Модель систематизирована и имеет осмысленную визуальную структуру. • Можно отобразить вещи, не извлекаемые из кода. • Недостатки: • То, что не может быть извлечено из кода, не будет перенесено в код автоматически. • Поддержка согласованности модели и кода сложна, трудоемка и не всегда доступна для верификации.
В чем корень проблемы • Элементы, составляющие архитектуру системы, не всегда имеют однозначное отображение на семантику языка программирования и наоборот. • Семантика языков программирования очень богата – многие идеи возможно реализовать несколькими различными способами. • Большинство идей не отображаются прямо на семантику языка – для их реализации требуются сложные конструкции. • Многие важные для понимания архитектуры элементы возникают только в runtime -е.
Двухуровневая система • Можно разнести значимые элементы архитектуры и детали реализации на разные уровни. • Уровень, реализующий архитектуру должен иметь взаимно однозначное соответствие с ее моделью: • Всем элементам этого уровня соответствуют элементы модели. • Изменения в модели, внесенные путем ее визуального редактирования, должны немедленно отражаться в реализации. • На верхнем уровне должны быть отражены и абстракции времени выполнения. • Этот уровень должен реализовываться как runtime environment (middleware).
А как же код реализации? • Реализация должна ограничивать возможности редактирования модели: • Изменения, противоречащие имеющейся реализации должны автоматически ограничиваться. • Эти ограничения должны базироваться на поведении реализации, а не на ее исходных текстах – еще одно «за» для runtime environment. • Должны иметься эффективные механизмы управления связыванием элементов реализации времени выполнения.
А так вообще бывает? • В индустриальном программировании роль такого runtime environment выполняют базы данных. • Схема базы данных достаточно полно отражает организацию данных системы. • Там же содержатся ограничения, верифицирующие соответствие вносимой информации архитектуре системы – СУБД поддерживает целостность данных. • В БД имеются механизмы – триггеры. • Имеется широкий спектр инструментальных средств для визуализации и редактирования схемы базы данных.
Почему реляционные базы данных не являются решением для нас? • Базы данных ориентированы на структурированное хранение данных: • Системы на их основе, в основном, «регистрируют» реальный мир. • Ограничения, закладываемые в базу, отражают правила внесения информации, не всегда проецирующиеся на законы и правила реального мира. • Для реализации игровой логики нужна система моделирования мира. • Изменения в схеме БД приводят к рассогласованию с остальным кодом системы.
Наш вывод из приведенных предпосылок • Для реализации «верхнего» уровня игровой логики нужна объектная база данных. • Эта база должна быть системой времени выполнения – middleware. • Для поддержания однозначного соответствия с реализацией эта база должна поддерживать изменения «на лету». • Применение такой базы в играх будет возможным только в случае достижения приемлемого быстродействия.
Выработанная нами архитектура системы AI Middleware.
Схема интерфейса играющего с системой
Что может дать использование AI Middleware SDK • Возможны быстрое создание и адаптация игрового мира в соответствии с потребностями game designer-а посредством интуитивно понятных инструментов, предполагаемых в данном SDK. • Использование средств такой системы задает определенную методологию, позволяющую детерминировать процесс разработки. • Выражение игровых концепций в терминах такой системы позволяет снизить количество логических ошибок в игре благодаря встроенному как в ядро системы, так и в средства разработки контролю логической связности.
Что может дать использование AI Middleware SDK (2) • В комплект SDK можно включить типовые решения для популярных игровых жанров включающие в себя: • Набор базовых примитивов для формирования объектов игрового мира – unit-ов, правил и т.п.; • Набор средств разработки, позволяющий, выбрав жанр разрабатываемой игры, автоматически сформировать «скелет» игрового проекта. • Зависимость логики игры от средств визуализации минимальна. Возможна быстрая адаптация существующих продуктов к новейшим средствам визуализации. Средства SDK позволят визуализировать функционирование логики игры в отсутствии какой бы то ни было системы визуализации, что позволяет разрабатывать логику игры совершенно независимо от других ее компонентов.
Что может дать использование AI Middleware SDK (3) • В SDK можно включить широкий спектр алгоритмов для формирования ИИ как игры в целом, так и для задания сложной логики отдельных игровых объектов. В этот список входят: • Конечные автоматы, настраиваемые как с помощью визуальных средств системы так и программно; • Деревья принятия решений; • Нейросети; • Генетические алгоритмы; • Алгоритмы для часто встречающихся задач: поиск пути, расчет столкновений и т.п.
Что может дать использование AI Middleware SDK (4) • Система должна иметь многоуровневый программный интерфейс, позволяющий, с одной стороны, максимально просто решать типовые задачи и, с другой стороны, вносить изменения в поведение всей системы на любом уровне. Это позволяет быстро начать работу с системой, сразу имея зримый результат, и решать все нетривиальные задачи, возникающие в виду специфики разрабатываемой игры, по мере все более глубокого знакомства. • Такая система позволяет геймдезайнеру решать большинство возникающих проблем самостоятельно, не прибегая к помощи разработчиков. • Позволяет команде разработчиков реализовывать более сложные и масштабные проекты, не ограничивая квалифицированных разработчиков и оставляя широкие возможности для творчества.
Что еще? • Возможность создания и модификации объектов игрового мира - как с помощью визуальных средств, так и программно. • Встроенная синхронизация игровых миров, существующих на различных машинах в рамках сети. Таким образом многопользовательский режим реализуется в игре с изначально и без каких бы то ни было дополнительных усилий.