Автор разбирает, как прототип ритм‑платформера Meowsic (кот на цифровой аудиостанции, где платформы — аудиопетли), сделанный за 4 дня для GMTK Game Jam, не масштабировался до коммерной версии с несколькими уровнями и десятками вариантов платформ.
Изначально каждая платформа была отдельным актором в Blueprint, вручную настраиваемым и управляемым центральным координатором. Для одного уровня это работало, но при росте проекта возникли проблемы:
- любое изменение свойства требовало правки десятков акторов;
- итерации становились медленными, дизайнерам было трудно экспериментировать;
- много дублированной логики и ручной поддержки консистентности.
Целью стало разделить данные и поведение, чтобы изменения конфигурации мгновенно распространялись на все инстансы и уменьшали трение в продакшене.
Layered Gameplay Systems Model
Автор предлагает модель из пяти слоёв для любых геймплейных систем с данными, правилами и множеством инстансов.
1. Representation — где живёт конфигурация
UPlatformDataDefinition (кастомный DataAsset) — единый источник правды для платформ. Данные переиспользуемы, подхватываются на лету (hotloadable), не дублируются по акторам.
2. Transformation — как превратить данные в рантайм‑значения
PlatformSubsystem читает DataAsset и рассчитывает значения для рантайма: клампит диапазоны, делает вычисления, комбинирует свойства. Вся логика преобразования сосредоточена в одном месте.
3. Validation — какие правила соблюдают платформы
Тот же PlatformSubsystem отвечает за валидацию: проверяет мин/макс позиции, ограничения по видимости, коллизии и другие инварианты. Правила не размазаны по акторам.
4. Orchestration — кто всем управляет
PlatformSubsystem — единый авторитет: отслеживает инстансы платформ, применяет логику, поддерживает синхронизацию, реагирует на события и обеспечивает выполнение правил. Оркестрация сосредоточена в одном системном объекте.
5. Interface — как с этим работают дизайнеры
Для дизайнеров создана Blueprint Function Library (Platform API). Она предоставляет чистые функции, не раскрывая деталей Subsystem и валидации. Дизайнеры работают с простым API вместо сложной внутренней архитектуры.
Слои независимы: можно менять представление данных, не ломая интерфейс, или обновлять правила валидации, не трогая акторы. Информация поднимается снизу вверх (данные → трансформация → валидация), а управление спускается сверху вниз (оркестрация → инстансы).
Реализация и эффект
Platform Actor превращён в «тонкую обёртку»: он лишь хранит ссылку на DataDefinition, регистрируется в Subsystem и получает от него состояние. В нём больше нет дублированных свойств и конфигурационной логики.
Результаты:
- класс платформы уменьшился с >300 до ~100 строк (−67%), логика централизована;
- массовое обновление свойств платформ по проекту сократилось с >30 минут до 2–3 минут;
- создание нового типа платформы — с >20 минут до 3–5 минут;
- консистентностные баги, на поиск которых уходило 1–2 часа, устранены за счёт автоматизации;
- время загрузки уровня снизилось с 5–10 секунд до ~0,5 секунды.
Ключевой эффект — рост скорости итераций и креативности дизайнеров. Раньше идея «а если платформы будут выше?» требовала ~45 минут подготовки и часто отклонялась. Теперь это: создать Gameplay Tag, связать с Platform Data Struct, настроить, протестировать и быстро перебрать десяток вариаций.
Выводы
- Разделение на слои (данные, трансформация, валидация, оркестрация, интерфейс) делает геймплейные системы масштабируемыми.
- Data Assets как единый источник правды устраняют дублирование и ускоряют массовые правки.
- Subsystem как центральный оркестратор концентрирует правила и управление инстансами.
- «Тонкие» акторы и чистое Blueprint‑API упрощают жизнь дизайнерам и уменьшают технический долг.
- Data‑driven подход напрямую ускоряет итерации, снижает баги и улучшает производительность уровней.
