Чаще всего, при изучении системы Blueprints и UnrealEngine в целом, человек знакомится именно с тем, как писать конкретную игровую логику, а также постепенно набирает себе словарь нод визуального программирования для реализации этой логики. Однако в целях обучения, вся подобная логика рассматривается на примерах простых алгоритмов, с которыми легко разобраться даже новичку. В процессе он сам учится создавать более сложные атомарные алгоритмы (то есть алгоритмы, сложность которых заключена в них самих, а не в связях с другими системами и функциями).
Однако, при разработке полноценной игры зачастую недостаточно уметь выстраивать один сложный алгоритм, необходимо проектировать систему взаимосвязанных блоков логики. При этом, не имея опыта, порой сложно в самом начале оценить реальную сложность этих связей.
Некоторые жанры менее требовательны к подобному, в то время как другие, наоборот, без этого не могут существовать.
Например, нет никаких сомнений, что создавать RPG — это сложная задача. Подобные игры включают в себя такие системы как: квесты, прокачка, диалоги, экономическую систему и т. д., которые очевидно сильно переплетены между собой. Однако с теми же самыми системами вы легко столкнетесь, например, в симуляторе фермера (хоть и в меньшем масштабе), что уже далеко не так очевидно.
И именно с такими взаимосвязанными системами чаще всего и возникают проблемы у начинающих разработчиков. Все они переплетаются в один клубок, и сложно найти подход к тому, как именно они должны строиться и связываться. Именно подобные системы мы будем рассматривать в этой главе.
Ни для кого не секрет, что, чтобы решить большую задачу, лучше всего разделить её на блоки поменьше. В комплексных системах необходимо применять аналогичный подход. Для упрощения этого процесса я выделил несколько главных характеристик, через призму которых мы будем далее рассматривать процесс формирования системы механик:
— Самостоятельность систем — Единая система связей и Визуальность — Доступность
Самостоятельность систем
При старте разработки связки крупных систем, разработчик, привыкший писать отдельные алгоритмы, зачастую также пытается представить весь комплекс систем как единый алгоритм. Однако, подобный объем разнообразной логики образует перегруженную систему, и, не имея опыта, человек просто путается в своих умозаключениях и не понимает с чего начинать писать такую систему и как ее организовывать в целом.
Гораздо проще в такой ситуации применять принцип схожий с Атомарностью, рассмотренной ранее. То есть воспринимать всю систему не как одну сущность, а как набор сущностей, объединенных некой логикой.
Возьмем для примера систему квестов.
Как это выглядит с точки зрения игрока: персонаж берет квест с доски поручений. Он отображается в дневнике всех квестов. После чего игрок выполняет действие для шага в квесте, в дневнике отображается прогресс. И так до тех пор, пока квест не будет завершен.
На первый взгляд это выглядит как одна большая система, но на деле это комплекс систем поменьше: дневник существует сам по себе, и просто отмечает пункты готовыми, когда условия выполняются. Сам квест также не одна логическая структура, а набор отдельных (зачастую сложных систем).
Шагами квеста могу быть: действие диалоговой системы (поговори с персонажем), инвентарной системы (добудь какой-то ресурс или предмет), взаимодействие с другими игровыми персонажами (убить кого-то, ограбить) и т. д.
Свести все разнообразие сущностей в одну систему практически невозможно. Но также и сходу написать взаимосвязанный комплекс сложных систем — также непростая задача. Поэтому, в такой ситуации правильным подходом будет придерживаться принципа самостоятельности систем. В такой структуре каждая система самодостаточна (может работать без вмешательства других) и лишь принимает некоторые вводные данные и отдает результат в ответ.
Таким образом сложная структура квеста преобразуется в набор небольших шагов, которые на самом деле не образуют никакой комплекс, а лишь выполняют свою часть работы и передают ситуацию дальше (по аналогии с конвейерной лентой сборки).
Предположим, персонажу нужно дойти до некого места. На месте стоит триггер, который фиксирует, что персонаж его пересек. В данной системе этому триггеру вовсе не обязательно знать, что вообще существует такая вещь, как квест. У него есть только одна простая задача — послать сигнал в нужное место, когда игрок достигнет цели.
Вывод: Все подсистемы сложной структуры должны быть самостоятельными блоками, которые выполняют конкретную функцию.
Единая система связей и Визуальность
Однако, несмотря на то, что превращая систему в набор тасков, мы значительно понижаем сложность системы для восприятия, гораздо более актуальной становится связь этих блоков друг с другом. И вот здесь уже без общей системы не обойтись.
Потому, как если выстраивать связь по-разному для разных сущностей, она перестанет быть очевидной и превратит разработку в постоянные попытки вспомнить, как обратиться к конкретной мини-системе.
Глобально я выделяю три системы связи между блоками системы:
— Горизонтальные связи — Система с централизованным хранением информации — Менеджер, как связующее звено
Сразу оговорюсь, что чаще всего все эти три системы комбинируются в том или ином виде, но для простоты базового понимания мы рассмотрим их по отдельности.
— Горизонтальные связи
Структура, в которой каждый блок системы знает, какой блок или блоки необходимо запустить после своего выполнения.
Дневник квестов активирует место на карте, которое в свою очередь запускает диалог, когда персонаж его достигает.
С точки зрения старта — это самая простая система. Однако у нее есть два значительных минуса:
— Настройка каждой отдельной сущности. Вы не можете просто создать блок «диалог» и использовать его как универсальную единицу, поскольку каждый диалог должен вести к иным последствиям, чем другие. Там образом вам либо придется создавать систему чайлдов, плодя сущности в Content Browser, или делать логику следующего блока доступной для настройки во Viewport, и настраивать цепочку блоков уже на карте.
— Сегментированность. Проблема напрямую вытекает из первого пункта. В итоговом виде в такой системе у вас нет единого места, где вы можете посмотреть всю логику вашего квеста. Вам необходимо последовательно идти по цепочке всех сущностей, чтобы сложить общую картину (аналогичную проблему мы уже обсуждали, когда говорили про цепочки функций, которые любят делать программисты, начиная работать с блюпринтами).
Исходя из обозначенных минусов, такая система связей подойдет только небольшим проектам, где не требуются длинные и разветвленные логические цепочки действий.
— Система с централизованным хранением информации
В основе своей такая система аналогична предыдущей с тем лишь отличием, что вся логика последовательности действий хранится не в самом блоке системы, а в некоторой общей системе хранения, например, в DataTable, к которой блоки лишь обращаются, чтобы узнать следующий шаг.
Дневник квестов узнает у системы хранения, что ему нужно активировать место на карте, которое в свою очередь, когда персонаж его достигнет, узнает, что далее необходимо запустить диалог.
Данная система решает обе проблемы прошлой: разработчик получает единое место, где он может сразу видеть, выстраивать или редактировать последовательность, а сами блоки достаточно универсальны, поскольку информация о последовательности хранится не в них самих.
Однако такая система имеет одно большое ограничение: система хранения не интерактивна.
Она может хранить последовательность шагов, но не может сама проверять правильность их выполнения, проводить логические операции и выстраивать какую-то логику между этапами. Все эти функции ложатся на блоки системы, что означает, что в каждом блоке необходимо будет прописать систему всех проверок и вариантов связи, что усложняет структуру блока и неизбежно ведет к дублированию кода между блоками.
Такая структура подойдёт только играм с линейной последовательностью действий в системе, не требующей большого количества проверок, развилок и сложной логики связей между блоками.
— Менеджер, как связующее звено
Структура, в которой роль связующего звена выполняет некая единичная сущность (менеджер). Именно менеджер получает информацию от блока, обрабатывает её и дает команду, какой блок запустить следующим.
Игрок получает квест, создается менеджер этого квеста. Менеджер добавляет в дневник запись о квесте и активирует первый блок: точку до которой игроку нужно дойти. Когда игрок достиг точки, она сообщает об это менеджеру. Тот проверяет, все ли условия выполнены для старта следующего блока и, получив подтверждение, активирует блок Диалога.
В такой структуре вся логическая нагрузка снимается с отдельных блоков и ложится на менеджер. К тому же, поскольку менеджер — это одна сущность, игроку просто видеть всю логику квеста, а также выстраивать проверки на выполнение всей последовательности блоков.
Менеджер также может комбинироваться с системой хранения информации, если ее слишком много, чтобы визуально удобно разместить ее в самом менеджере.
Еще стоит отметить, что сам менеджер может быть реализован крайне разными способами. Это может быть актер, который размещается на уровне в момент активации квеста или, например, быть компонентой, которая крепится к актеру персонажа или контроллера игрока (что лично для меня является самым удобным вариантом).
Вывод: Система связей должна быть универсальна для всех блоков логики системы. А также, в идеале, иметь общую визуализацию для упрощения работы и редактуры системы. Однако сложность этой системы связей выбирается в зависимости от размера и потребностей вашего проект.
Доступность
Пункт, напрямую связанный с упомянутой выше визуальностью. Важно помнить, что в конечном итоге выстраивать связи между блоками и создавать те же самые квесты будут не разработки, а, например, гейм-дизайнеры, нарративные дизайнеры или дизайнеры уровней.
Поэтому необходимо делать систему как можно более понятной и простой, чтобы даже не искушенные в системах работы игрового движка люди могли эффективно работать с созданной вами структурой, без необходимости постоянно обращаться за помощью к техническим специалистам.
А следовательно, система связей обязательно должна иметь визуальную оболочку в виде Блюпринтов (даже если была написана при помощи C++) в которых можно наглядно выстраивать логику связей, соединяя отдельные блоки с помощью Execution Wires.
Вывод из второй главы
Для написания комплекса систем, необходимо разделить их на атомарные блоки, а затем правильно настроить связь этих блоков, которая будет обеспечивать обмен информации, а также логику их выполнения.
При этом важно обеспечить визуальное удобство этой системы.
