Разрабатываемый проект No Magic!
Практическая реализация описанных паттернов варьируется в зависимости от выбранного игрового движка. В данном исследовании рассматриваются возможности Unreal Engine, которые легли в основу архитектуры проекта No Magic!. Основной акцент сделан на использовании системы акторов (Actors) и компонентов (Actor Components), а также на инструментарии визуального программирования Blueprints.
Основной задачей в реализации модульного подхода при разработке проекта является обеспечение возможности геймдизайнеру и дизайнеру уровней работать над проектом без необходимости вносить изменения в код, то есть использовать простые модули, собирать на их основе уровни, настраивать логику и игровой баланс.
объекты-триггеры
Триггеры — невидимые объекты, которые реагируют на попадание в них других игровых объектов, — могут либо совсем не иметь внутри себя логики, либо реализовывать её в зависимости от того, заданы в них дополнительные параметры или нет. В случае, если для триггера не указаны параметры, он никак не влияет на игровой процесс.
В проекте No Magic! реализован универсальный триггер, определяющий поведение игры при входе игрока в новый сегмент уровня. Он принимает на вход два параметра:
- ссылку на барьер, блокирующий предыдущий сегмент;
- ссылку на сцену со следующим уровнем.
Триггер и его параметры
Геймдизайнеру достаточно разместить триггер на уровне и через пипетку (Actor Picker) указать конкретный барьер или уровень для загрузки. При дальнейшей разработке функциональность триггера может быть дополнена.
акторы как параметры для других акторов
Возможность использовать блюпринты акторов в качестве параметров позволяет геймдизайнеру реализовывать множество комбинаций, быстро их настраивать и тестировать.
Примером могут служить турели — статичные объекты, имеющие параметр оружия. Турель не является монолитным объектом, а использует иерархическое наследование от базового класса BP_Tablet_Base, функционал которого расширяется в наследниках, одним из которых является BP_Tablet_Turret, имеющий слот под класс оружия.
Турель и её параметры
Оружие — это тоже актор, наследуемый от базового класса BP_Weapon_Base. Можно реализовать разные варианты оружия: постоянно отслеживающее персонажа, стреляющее по определённой области, выпускающее снаряды в нескольких направлениях и так далее. Так как оружие — это параметр турели, то можно быстро переключать тип оружия и менять поведение турели на уровне.
Для турелей установлено оружие, наводящееся на персонажа
Оружие, в свою очередь, также имеет параметр снаряда, который можно в любой момент изменить, как и другие параметры.
Параметры оружия
В данном примере задача программиста состоит в том, чтобы реализовать библиотеку акторов оружия в соответствии с документацией, а уже задача геймдизайнера — установить для каждой турели на уровне нужный вариант оружия.
сегментация уровней
Для управления прогрессией игрока была разработана система сегментов уровня, или квестов. Каждый сегмент включает в себя невидимый управляющий актор, который оценивает текущую игровую ситуацию.
Актор сегмента содержит набор условий, который настраивается в редакторе. Геймдизайнер может задать количество противников, которых нужно победить, или указать конкретные турели, которые нужно уничтожить.
Параметры одного из сегментов
Акторы сегментов не являются универсальными, условия в них прописываются индивидуально, но все они наследуются от общего класса. Если несколько сегментов имеют одинаковый набор формальных условий, то геймдизайнер может использовать один и тот же логический модуль сегмента.
Общий актор прогрессии BP_Level_Controller содержит массив ссылок на эти сегменты. Если дизайнеру нужно изменить порядок прохождения уровня, ему не нужно переписывать скрипт — достаточно изменить порядок элементов в массиве. Это позволяет быстро и гибко настраивать логику прохождения уровня, состоящего из любого количества сегментов.
Массив с условиями прохождения сегментов уровня
дизайн через данные
Примером реализации паттерна Data-Driven Design является модуль триггера, запускающий режим диалога, когда персонаж игрока входит в триггер. Использование Data Assets позволило вынести настройку контента — текста — за пределы кода. Это исключает риск случайного изменения логики при редактировании текста.
Для запуска диалогов используется класс BP_DialogTrigger. Его единственным значимым параметром является ссылка на файл DA_DialogConfig. Этот ресурс содержит массив структур, включающих имя персонажа и произносимый текст. Нарративный дизайнер работает в удобном табличном интерфейсе, создавая десятки диалогов, которые геймдизайнер просто «привязывает» к нужным местам на карте.
Интерфейс настройки диалогов
Отображение в интерфейсе
система событий
Так как отдельные элементы игровой логики — модули — являются универсальными и не имеют прямых ссылок друг на друга, то для обеспечения их взаимодействия реализуется система событий через Event Dispatcher. Это единая система, обрабатывающая все события на уровне. Любой актор может передать в систему событий сообщение либо подписаться на интересующее его событие.
Пример связи объектов через систему событий
Таким образом обеспечивается минимальная связность системы, а геймдизайнер может выстраивать сложные логические цепочки, не задумываясь над настройкой связей, так как всё общение между модулями происходит «в фоне» и заранее настраивается программистом.
фреймворк проекта
В результате практической реализации изученных паттернов в проекте No Magic! сформировался целостный модульный фреймворк, объединяющий три уровня взаимодействия:
- Инструментальный уровень. Программист в соответствии с требованиями проекта создаёт базовые модули (триггеры, контроллеры, базовые классы и интерфейсы взаимодействия). Эти модули лишены уникального контекста и максимально универсальны.
- Уровень сборки. Геймдизайнер использует визуальный интерфейс редактора для сборки и настройки объектов. Сложные игровые сущности создаются путём объединения модулей и настройки их параметров.
- Уровень управления. Геймдизайнер и нарративный дизайнер управляют игрой через внешние структуры данных, в то время как логика работы игры остаётся скрытой и обеспечивается программистом.
Сформированный фреймворк позволил превратить разработку из линейного процесса написания кода в гибкий и распределённый процесс работы, удобный для всех участников команды.
