В прошлых главах мы рассмотрели, как создавать сами системы, однако работа на этом не заканчивается, ведь любая система затем используется для реализации игрового контента всех возможных типов. При это заниматься этим, по большей части, будут не сами разработчики, а другие специалисты, участвующие в проекте (что мы уже поверхностно затронули в блоке про Доступность).
Таким образом, ответственность разработчика — не только создать систему, но и организовать структуры взаимодействия с ней. В этой главе мы рассмотрим следующие аспекты подготовки системы к использованию:
— Заполнение системы данными — Настройка систем на уровне — Удобство тестирования изменений — Расширение функционала взаимодействия с движком — Визуальные оболочки
Заполнение системы данными
Любая игра содержит в себе огромное количество параметров и контента: урон, здоровье, стоимость, время восстановления способности, строчки в системе диалогов и т.д. И большинство из этих параметров будет вводиться, убираться и меняться на протяжение реализации всего проекта.
И если вы просто оставите все эти данные внутри кода или блюпринта, то без помощи разработчика никто не сможет эффективно с ними взаимодействовать, что будет серьезно замедлять процесс разработки вашего проекта.
UE предлагает различные системы хранения данных, и далее мы рассмотрим, в каком случае стоит применять ту или иную структуру. Нами будут рассмотрены:
— DataTables — DataAssets
А также мы поговорим про Structures и Enumerations, как об инструментах для организации хранения данных.
Структуры хранения данных
Основные структуры хранения данных (не считая переменных внутри отдельного актера или системы) — это DataTables (в дальнейшем Таблицы) и DataAssets (в дальнейшем Конфиги).
DataTable — как и следует из названия, это таблица, по своей структуре идентичная тем, что мы используем в офисных приложениях (за тем исключением, что DT не поддерживают формулы и прочие операции, и являются лишь инструментом хранения данных в формате таблицы).
Главное преимущество таблиц — возможность видеть сразу все данные во всех столбцах и строках, что позволяет их удобно сравнивать и балансировать друг с другом.
А также возможность импортировать в движок таблицу, сделанную в нужном формате в сторонней офисной системе, что делает таблицы удобным инструментом для интеграции в проект, например, таблицы параметров враждебных игровых персонажей, поскольку гейм-дизайнер может создать и просчитать ее вне движка, а затем легко интегрировать внутрь игрового проекта.
Пример DataTable c параметрами для разных типов Юнитов
Однако, главный минус Таблиц — необходимость написания системы обращения к ней внутри актера, которому нужны хранимые параметры.
Актер должен обратиться к таблице по конкретному имени строки, чтобы получить нужные ему параметры, а затем разбить хранимую внутри структуру и затем уже использовать полученные параметры.
DataAsset — это Шаблон, из которого можно создавать отдельные ассеты, хранящие определенный набор параметров.
Главным плюсом Конфигов является возможность легко указывать актеру, какой именно конфиг ему необходимо использовать, поскольку DA можно легко указать как переменную внутри актера.
Также тот факт, что переменные хранятся в нем по отдельности, а не в рамках одной структуры, как в Таблице, позволяет легче обращаться к этим переменным.
Минусом DA является необходимость создания отдельного ассета в ContentBrowser для каждого конфига, что в случае большого количества сущностей превращается в огромное количество отдельных сущностей.
Пример набора DataAssets с данными для массовки на локациях
Типы хранимых данных
В прошлом блоке мы рассмотрели системы хранения, однако, чтобы разобраться, в каких случаях их применять, необходимо проанализировать типы хранимых данных, и сопоставив их требования с плюсами и минусами той или иной системы, сделать выводы. Я выделяю следующие виды хранимых параметров:
— Параметры, используемые в конкретной системе
Это параметры отдельной игровой сущности. Например, аспекты поведения камеры игрока, параметры передвижения игрового персонажа и т.д.
Главным аспектом здесь является факт, что это данные предназначенные для отдельной сущности и существующие, по сути, в единственном экземпляре.
Для подобных параметров лучше всего подходят именно DataAssets,
Поскольку в данном случае не подразумевается сравнение параметров разных сущностей друг с другом, и данные используются в единственном месте.
Пример неправильной реализации хранения параметров персонажа игрока в рамках DataTable.
— Параметры, используемые в наборе сущностей одного типа
Это параметры, представляющие собой, по сути, пресет для использования сущностями в рамках одного типа.
Например, набор настроек игрового уровня, или параметры, которые использует каждый NPC в игре.
Для подобных параметров релевантной системой хранения может быть как DataAsset, так и DataTable, в зависимости от того, нужно ли разработчикам сопоставлять параметры разных сущностей между собой или нет.
Рассмотрим, для примера, ту же систему способностей персонажа, которую мы затрагивали в блоках про разработку систем. Предположим, нам нужно хранить информацию о том, какие персонажи имеют какие способности.
Если набор способностей каждого персонажа в понимании гейм-дизайнера атомарен, и не подразумевает его сравнения со способностями других персонажей — удобно поместить этот список в Конфиг.
