1 / 21

Разработка AI Middleware SDK.

Разработка AI Middleware SDK. Алексей Осипенко Руководитель службы R&D Buka Entertainment Enterprises oalexey@buka.ru. Почему об этом имеет смысл подумать?. Разработка игровой логики является одним из самых проблемных мест в gamedev -е.

steve
Download Presentation

Разработка AI Middleware SDK.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Разработка AI Middleware SDK. АлексейОсипенко Руководитель службы R&D Buka Entertainment Enterprises oalexey@buka.ru

  2. Почему об этом имеет смысл подумать? • Разработка игровой логики является одним из самых проблемных мест в gamedev-е. • Это одно из самых недетерминированных мест в разработке... • ... и определяющих, получится ли, в итоге игра или нет.

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

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

  5. Откуда можно взять модель • Архитектура содержится в программном коде и должна извлекаться из него. • Механически извлеченная из кода модель почти всегда имеет бессистемный характер – все абстракции «свалены в одну кучу». • Такая модель «замусорена» деталями реализации и вспомогательными абстракциями. • Невозможно вычленить многие значимые идеи.

  6. Возможный способ преодоления описанных трудностей • Использовать инкапсуляцию для фильтрации малозначимых деталей. • Программисты должны скорпулезно следовать механизмам инкапсуляции, предусмотренным в языке. • Визуализировать только интерфейсы. • Помечать важные абстракции комментариями специального вида. • Подчас, трудоемко и не поддаётся верификации. • Механизмы все равно остаются «за кадром»!

  7. Можно «зайти с другого конца» • Строить не модель по коду, а код по модели. • Преимущества: • Модель систематизирована и имеет осмысленную визуальную структуру. • Можно отобразить вещи, не извлекаемые из кода. • Недостатки: • То, что не может быть извлечено из кода, не будет перенесено в код автоматически. • Поддержка согласованности модели и кода сложна, трудоемка и не всегда доступна для верификации.

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

  9. Двухуровневая система • Можно разнести значимые элементы архитектуры и детали реализации на разные уровни. • Уровень, реализующий архитектуру должен иметь взаимно однозначное соответствие с ее моделью: • Всем элементам этого уровня соответствуют элементы модели. • Изменения в модели, внесенные путем ее визуального редактирования, должны немедленно отражаться в реализации. • На верхнем уровне должны быть отражены и абстракции времени выполнения. • Этот уровень должен реализовываться как runtime environment (middleware).

  10. А как же код реализации? • Реализация должна ограничивать возможности редактирования модели: • Изменения, противоречащие имеющейся реализации должны автоматически ограничиваться. • Эти ограничения должны базироваться на поведении реализации, а не на ее исходных текстах – еще одно «за» для runtime environment. • Должны иметься эффективные механизмы управления связыванием элементов реализации времени выполнения.

  11. А так вообще бывает? • В индустриальном программировании роль такого runtime environment выполняют базы данных. • Схема базы данных достаточно полно отражает организацию данных системы. • Там же содержатся ограничения, верифицирующие соответствие вносимой информации архитектуре системы – СУБД поддерживает целостность данных. • В БД имеются механизмы – триггеры. • Имеется широкий спектр инструментальных средств для визуализации и редактирования схемы базы данных.

  12. Почему реляционные базы данных не являются решением для нас? • Базы данных ориентированы на структурированное хранение данных: • Системы на их основе, в основном, «регистрируют» реальный мир. • Ограничения, закладываемые в базу, отражают правила внесения информации, не всегда проецирующиеся на законы и правила реального мира. • Для реализации игровой логики нужна система моделирования мира. • Изменения в схеме БД приводят к рассогласованию с остальным кодом системы.

  13. Наш вывод из приведенных предпосылок • Для реализации «верхнего» уровня игровой логики нужна объектная база данных. • Эта база должна быть системой времени выполнения – middleware. • Для поддержания однозначного соответствия с реализацией эта база должна поддерживать изменения «на лету». • Применение такой базы в играх будет возможным только в случае достижения приемлемого быстродействия.

  14. Выработанная нами архитектура системы AI Middleware.

  15. Схема интерфейса играющего с системой

  16. Что может дать использование AI Middleware SDK • Возможны быстрое создание и адаптация игрового мира в соответствии с потребностями game designer-а посредством интуитивно понятных инструментов, предполагаемых в данном SDK. • Использование средств такой системы задает определенную методологию, позволяющую детерминировать процесс разработки. • Выражение игровых концепций в терминах такой системы позволяет снизить количество логических ошибок в игре благодаря встроенному как в ядро системы, так и в средства разработки контролю логической связности.

  17. Что может дать использование AI Middleware SDK (2) • В комплект SDK можно включить типовые решения для популярных игровых жанров включающие в себя: • Набор базовых примитивов для формирования объектов игрового мира – unit-ов, правил и т.п.; • Набор средств разработки, позволяющий, выбрав жанр разрабатываемой игры, автоматически сформировать «скелет» игрового проекта. • Зависимость логики игры от средств визуализации минимальна. Возможна быстрая адаптация существующих продуктов к новейшим средствам визуализации. Средства SDK позволят визуализировать функционирование логики игры в отсутствии какой бы то ни было системы визуализации, что позволяет разрабатывать логику игры совершенно независимо от других ее компонентов.

  18. Что может дать использование AI Middleware SDK (3) • В SDK можно включить широкий спектр алгоритмов для формирования ИИ как игры в целом, так и для задания сложной логики отдельных игровых объектов. В этот список входят: • Конечные автоматы, настраиваемые как с помощью визуальных средств системы так и программно; • Деревья принятия решений; • Нейросети; • Генетические алгоритмы; • Алгоритмы для часто встречающихся задач: поиск пути, расчет столкновений и т.п.

  19. Что может дать использование AI Middleware SDK (4) • Система должна иметь многоуровневый программный интерфейс, позволяющий, с одной стороны, максимально просто решать типовые задачи и, с другой стороны, вносить изменения в поведение всей системы на любом уровне. Это позволяет быстро начать работу с системой, сразу имея зримый результат, и решать все нетривиальные задачи, возникающие в виду специфики разрабатываемой игры, по мере все более глубокого знакомства. • Такая система позволяет геймдезайнеру решать большинство возникающих проблем самостоятельно, не прибегая к помощи разработчиков. • Позволяет команде разработчиков реализовывать более сложные и масштабные проекты, не ограничивая квалифицированных разработчиков и оставляя широкие возможности для творчества.

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

  21. Вопросы?Спасибо за внимание.

More Related