Ускорение выпуска игрового контента

Проблема

По мере развития LiveOps-проекта требовалось выпускать всё больше контента. При этом недостаточно было просто наращивать объём: новые герои, способности, снаряжение и события должны были оставаться интересными игрокам. Это увеличивало как сложность игровой логики, так и нагрузку на команды, которые готовили, проверяли и выпускали контент.

Задача состояла в том, чтобы ускорить итерации и сохранить управляемость разработки, не сводя качество новых механик к набору однотипных решений.

Мой вклад

Я участвовал в развитии технических подходов и инструментов, которые уменьшали объём повторяющейся ручной работы и позволяли команде сосредоточиться на механиках и их игровом опыте.

Реализация

Ускорение достигалось несколькими взаимодополняющими способами.

Конфигурационный конвейер

Поведение снаряжения и условий боевых эффектов переводилось на универсальные, конфигурируемые механики вместо отдельных скриптов под каждый частный случай. Конвейер связывал данные игровых сущностей, их скрипты и средства визуализации в повторяемый производственный процесс. Расширения Unity Editor и вспомогательная автоматизация на Bash и Python дополнительно снимали ручные операции у VFX-художников, геймдизайнеров и разработчиков.

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

<!-- До: отдельный скрипт под конкретный предмет -->
<equipment id="crystal_of_frost">
  <battle_script>CrystalOfFrostScript</battle_script>
</equipment>

После типовая механика описывалась данными, а общий движковый код интерпретировал эти данные:

<!-- После: общий механизм и параметры из конфига -->
<equipment id="crystal_of_frost" mechanic="apply_effect">
  <effect type="slow" duration="2" />
  <condition type="on_ability_hit" />
</equipment>

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

На видео — пример игроко-видимого результата: экипировка питомца меняет его способность через общую механику снаряжения.

Экипировка питомца изменяет его способность без создания отдельного специализированного боевого сценария.

Скриптовый язык Lua

Я принимал участие в частичном переносе игровой логики на Lua. Это позволило сделать разработку и настройку части контента более гибкой, сохраняя C# для систем, где он был необходим.

Пример ниже — псевдокод с условными именами. Он иллюстрирует перенос логики контентной способности из специализированного C#-класса в скрипт, который исполняется через игровой контекст:

// До: отдельный C#-класс под конкретную способность
sealed class FrostStrikeAbility : AbilityScript
{
    public override void Execute(BattleContext battle, Actor caster, Actor target)
    {
        battle.DealDamage(caster, target, caster.Power * 1.2f);
        battle.ApplyEffect(target, EffectType.Slow, turns: 2);
    }
}

-- После: псевдокод Lua с тем же намерением
function execute(context, caster, target)
    context:deal_damage(caster, target, caster:power() * 1.2)
    context:apply_effect(target, "slow", { turns = 2 })
end

Общие боевые правила и доступ к состоянию остаются на стороне движка, а скрипт описывает конкретное поведение контента через ограниченный набор операций.

AI-инструменты агентской разработки

AI-инструменты использовались для решения рутинных задач, которые можно было формализовать правилами разработки: анализа, подготовки и проверки рабочих материалов. Это помогало быстрее проходить повторяющиеся этапы, оставляя за разработчиком технические решения и контроль результата.

Внутренние форматы, код и конкретные сценарии применения не раскрываются.

Результат

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