Создание масштабируемой архитектуры игрового процесса на основе данных в UE5 с использованием C++

Введение

Вы когда-нибудь выпускали прототип для игрового джем-фестиваля и понимали, что он не масштабируется? Так было с нами в Meowsic.

Во время игрового джем-фестиваля GMTK 2025 мы создали ритм-игру-головоломку, где вы играете за кота на цифровой аудиостанции. Это Meowsic. Платформенный ритм-платформер, в котором платформы — это ваши аудио-петли. Четыре дня, один уровень, успешно выпущен. Сообщество понравилось. Но потом мы решили сделать из него полноценную коммерческую игру для Steam с 2–5+ уровнями и десятками вариаций платформ. Вот тогда наша архитектура для джем-фестиваля развалилась.

Наш первоначальный подход был прост: отдельные платформенные акторы, настроенные вручную, управляемые центральным координатором. Для прототипа игры в формате джем-фестиваля это работало идеально. Но когда мы планировали несколько уровней с вариантами платформ, итерации стали мучительно медленными. Дизайнеры не могли экспериментировать. Я тратил часы на обеспечение согласованности вместо создания функций. Изменение одного свойства платформы означало обновление более 40 акторов.

Мне нужен был принципиально другой подход: тот, который отделял бы данные от поведения, позволял бы мгновенно распространять изменения конфигурации на все экземпляры и уменьшал бы производственные трудности вместо того, чтобы усиливать их.

Решение — модель многоуровневых игровых систем, архитектурный шаблон, который разбивает любую игровую систему на пять отдельных слоёв, каждый из которых выполняет определённые функции. Она не привязана к платформам или Meowsic. Любая система с данными, правилами и несколькими экземплярами может выиграть от такого подхода.

Проблема: почему всё сломалось

Проблема согласованности

Представьте себе 40 платформенных акторов, разделённых на 7 вариантов. У каждого есть свойства для поведения при движении, аудио, материалов, типа сетки и многое другое. Вы понимаете, что максимальная высота Z неправильная, она равна 500, когда должна быть 800. Вы обновляете одного актора, тестируете его, и всё в порядке.

Но как насчёт остальных шести? Вы их обновили? Как вы узнаете, что они согласованы? В ручном рабочем процессе вы этого не сделаете. Вы либо обновляете каждого актора по одному (утомительно и чревато ошибками), либо надеетесь, что поймали их всех (плохая идея), либо создаёте визуальные несоответствия, которые нарушают ожидания игроков (ещё хуже).

Проблема итераций

Дизайнеры хотели экспериментировать. «Что, если платформы поднимутся выше? Что, если они меняют цвет при наступлении? Что, если аудио воспроизводится на разных высотах?»

Каждый эксперимент означал:

1. Создать новое свойство в PlatformActor;
2. Разместить 7 копий платформы на тестовом уровне;
3. Настроить каждую по отдельности;
4. Протестировать поведение;
5. Если оно не сработало, удалить все 7 и начать сначала.

Один цикл итераций занимал более 30 минут. Дизайнеры перестали экспериментировать. Скорость итераций упала.

Проблема производительности и дублирования

Каждая платформа была полноценным AActor в памяти. Для 2–5 уровней с 50 платформами на уровне это 100–250+ экземпляров. Каждый нёс идентичные свойства и логику, одинаковую скорость движения, аудиосигналы и правила, хранящиеся 250 раз.

Время загрузки уровня увеличилось до 5–10 секунд. И у нас было огромное дублирование кода с небольшой гибкостью. Основная проблема: конфигурация и поведение были тесно связаны. Каждое изменение означало изменение во многих местах.

Решение: отделение данных от поведения

Основная идея

Что, если мы перевернём архитектуру?

Вместо:

Актёр [Конфигурация + поведение]... × 250

Мы могли бы иметь:

DataAsset [Конфигурация]
    ↓ ссылки
Актёр [Только поведение]... × 250

Теперь все 250 актёров ссылаются на одну и ту же конфигурацию. Измените данные один раз, и каждый актёр обновится мгновенно. Нет дублирования. Нет несогласованности. Нет рутинной работы.

Модель многоуровневых игровых систем

Чтобы реализовать это аккуратно, я разработал шаблон: пять отдельных слоёв, каждый из которых выполняет определённые функции.

Уровень 1: Представление — где живёт конфигурация?

Ответ: UPlatformDataDefinition (пользовательский DataAsset). Единый источник правды, возможность повторного использования, горячая загрузка.

Уровень 2: Трансформация — как мы преобразуем сохранённые данные в значения времени выполнения?

Ответ: PlatformSubsystem считывает DataAsset и вычисляет значения, специфичные для времени выполнения. Ограничивает диапазоны, выполняет вычисления и объединяет свойства.

Уровень 3: Валидация — каким правилам следуют платформы?

Ответ: подсистема обеспечивает соблюдение ограничений. Минимальные/максимальные позиции, манипуляции на основе вида и проверки столкновений.

Уровень 4: Оркестрация — кто всем управляет?

Ответ: PlatformSubsystem — единственный орган власти. Отслеживает экземпляры, применяет логику, обеспечивает соблюдение правил, реагирует на события и синхронизирует всё.

Уровень 5: Интерфейс — Как взаимодействуют дизайнеры?

Ответ: Библиотека функций Blueprint (Platform API). Дизайнеры вызывают чистые функции, не понимая подсистемы или логики проверки.

Каждый уровень независим. Измените один, не нарушая работу других. Информация течёт вверх; координация — вниз.

Реализация

Прелесть этого подхода — в простоте.

Platform Actor становится тонкой оболочкой: вот и всё. Актёр ссылается на DataDefinition, регистрируется в подсистеме и получает от неё состояние. Никаких дублирующихся свойств в 250 экземплярах. Никакой логики конфигурации. Просто тонкая оболочка.

Platform Data Definition определяет, как данные представлены в Data Assets, и управляет этим.

PlatformSubsystem становится сердцем:

• Отслеживает все экземпляры платформы;
• Вычисляет состояние платформы на основе DataAssets;
• Проверяет взаимодействия;
• Читает DataAsset и вычисляет значения, специфичные для времени выполнения;
• Отвечает на игровые события;
• Синхронизирует всё.

PlatformLibrary предоставляет API:

• "Получить все платформы";
• "Получить подвижные платформы";
• "Установить данные платформы";
• "Зарегистрировать платформу".

Дизайнеры используют эти функции в Blueprints, не касаясь C++.

Результаты

Основной класс платформы был сокращён с более чем 300 строк до чуть более 100 строк, что представляет собой уменьшение размера на 67%. Логика, специфичная для платформы, которая ранее дублировалась, была централизована в единой системе.

Этот переход к рабочему процессу, управляемому данными, также оказал существенное влияние на эффективность производства. Задачи, которые ранее требовали более 30 минут, например обновление свойств платформы во всём проекте, теперь могут быть выполнены всего за 2–3 минуты. Создание нового типа платформы, которое когда-то занимало более 20 минут, теперь занимает всего 3–5 минут. Проблемы согласованности, которые ранее требовали 1–2 часов отладки, были устранены с помощью автоматизации. Кроме того, время загрузки уровня значительно улучшилось, сократившись с 5–10 секунд до примерно половины секунды.

Опыт дизайнеров

До: «Что, если платформы поднимутся выше?» — 45 минут на настройку — «Давайте не будем пробовать».

После: «Что, если платформы поднимутся выше?» — Создать тег геймплея, связать со структурой данных платформы, настроить, протестировать — «Давайте попробуем 10 вариантов и выберем лучший».

Скорость итераций изменилась. Творчество возросло. Вот настоящая победа.

Когда использовать этот шаблон

Этот шаблон работает для любой системы геймплея с:

• Данными (конфигурацией, управляющей поведением);
• Правилами (проверка и ограничения);
• Экземплярами (множественные копии одного и того же).

Примеры:

• Выпадение лута: частота выпадения, редкость, количество в тысячах экземпляров;
• Типы врагов: характеристики, поведение ИИ, правила балансировки для более чем 50 врагов на уровне;
• Деревья диалогов: логика ветвления для сотен узлов;
• Аудиосистемы: параметры и сигналы для тысяч источников звука.

Задайте себе вопрос: есть ли у меня 10+ экземпляров, использующих одну конфигурацию? Итерация идёт медленно? Ошибки согласованности встречаются часто? Если да на 3+, используйте этот шаблон.

Заключительные мысли

Лучшая архитектура — это не та, в которой больше всего абстракций. Это та, которая устраняет трения между намерением и исполнением.

Когда дизайнер думает: «Я хочу, чтобы платформы поднялись на 4 шага выше», и может выполнить это за 10 минут вместо 2 часов, что-то фундаментально изменилось. Они больше не ограничены деталями реализации. Они свободны творить.

Эта свобода накапливается. Итерация строится на итерации. Эксперименты приводят к открытиям. Открытия приводят к уникальному геймплею, который могла создать только ваша команда.

Для Meowsic эта архитектура помогла мне найти удовольствие в данных. И затем продолжать находить его.

Начните с малого — с одной проблемной системы. Создайте одну подсистему, следуя этим пяти слоям. Измерьте результаты. Расширяйте, когда увидите, что это работает. Шаблон масштабируется от одной системы до десятков. Выгода заключается не только в более чистом коде или более быстрых итерациях. Это возможность бесстрашно экспериментировать, продолжать пробовать вариации, пока не найдёте что-то волшебное. Ради этого и стоит строить.

Чуквуйенум Опон, программист геймплея