Speeding Up Game Content Delivery

Challenge

As the LiveOps project grew, it had to ship more heroes, abilities, equipment, and events without making the content repetitive or the production process unmanageable.

My contribution

I helped develop technical approaches and tools that reduced repetitive manual work, letting the team focus on gameplay mechanics and player experience.

Implementation

Several complementary approaches contributed to faster delivery.

Configuration pipeline

Equipment behaviour and battle-effect conditions moved to reusable, configurable mechanics instead of a separate script for every individual case. The pipeline connected game-entity data, their scripts, and visualisation tools into a repeatable production process. Unity Editor extensions and supporting Bash and Python automation further removed manual steps for VFX artists, game designers, and developers.

The following is a simplified illustrative example, not an extract from the project’s internal configuration. Previously, special behaviour could be hard-wired to a dedicated script in an entity definition:

<!-- Before: a dedicated script for one item -->
<equipment id="crystal_of_frost">
  <battle_script>CrystalOfFrostScript</battle_script>
</equipment>

Afterward, a standard mechanic was described by data and interpreted by shared engine code:

<!-- After: a shared mechanism with configuration parameters -->
<equipment id="crystal_of_frost" mechanic="apply_effect">
  <effect type="slow" duration="2" />
  <condition type="on_ability_hit" />
</equipment>

This approach does not eliminate code: it moves recurring differences out of specialised classes and into verifiable configuration parameters. A new item or effect variant can be composed from existing primitives while the shared implementation evolves in one place.

The video shows a player-visible result: pet equipment changes an ability through the shared equipment mechanic.

Pet equipment changes an ability without requiring a separate, specialised battle scenario.

Lua scripting language

I contributed to a partial move of game logic to Lua. This made development and configuration of some content more flexible while retaining C# for systems that required it.

The following pseudocode uses fictional names. It illustrates moving a content-specific ability from a specialised C# class into a script executed through the game context:

// Before: a dedicated C# class for one ability
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);
    }
}

-- After: Lua pseudocode with the same intent
function execute(context, caster, target)
    context:deal_damage(caster, target, caster:power() * 1.2)
    context:apply_effect(target, "slow", { turns = 2 })
end

Shared battle rules and access to state remain in the engine, while a script describes content-specific behaviour through a constrained set of operations.

AI tools for agentic development

AI tools were used for routine tasks that could be formalised through development rules: analysing, preparing, and checking working materials. They helped complete repetitive stages faster while technical decisions and result review remained with the developer.

Internal formats, code, and specific use cases are not disclosed.

Result

These approaches helped halve the time needed to deliver new content. One effect-property change could be applied across configurations for all heroes and actors in a set of 377 files, without manually changing each character’s logic.