How the First Battle Came to Life

In part 2, we looked at how one person and AI could share the work of making a game. This time, we turn to the first playable battle: the rules that let it begin, respond to the player, and reach an outcome.

Putting two groups of characters in a scene and playing their running and attack animations does not complete a battle. The screen can be busy, but if player actions cannot keep changing the situation, or the system cannot decide who won, it is still a demonstration.

The first battle in Kibble Street TD had a more basic problem to solve: how could a set of rules keep advancing and eventually produce a result, without the developer manually changing its internal state?

The smallest complete loop had six steps: energy regenerates, the player summons a unit, units advance, a target enters attack range, damage changes its health, and one side's base is destroyed. Character animation, backgrounds, items, buffs, sound, and rewards would all matter later. They needed this loop to work first.

Define the battlefield first

The first version established four fixed anchors: the player's base and tower, and the enemy's tower and base. Units entered from their own side and advanced toward the opposition. The simulation needed just one horizontal lane. Small vertical offsets in the visuals kept characters from overlapping completely.

This structure was deliberately simple. Bases determined the final outcome. Towers added pressure at intermediate points. Units were the changing element that both sides kept introducing. Once the four buildings had positions, factions, and health, the system had a battle line it could calculate.

By the development stage covered here, the battlefield had grown into a long, draggable scene. The underlying relationship remained the same: the player built an offensive from the left, while enemies arrived from the right on the level's schedule. Each side passed a tower before approaching the opposing base. Layered backgrounds and visual offsets added depth, but horizontal position and attack range still determined when combat happened.

Let one unit complete its lifecycle

The number of characters was not the first priority. One unit needed to complete its whole lifecycle: be summoned, enter the battlefield, look for a target, move forward, get within attack range, deal damage, and then continue or die.

Each unit needed a few values the system could work with: its side, position, health, movement speed, attack power, attack range, and attack interval. Every time the simulation advanced, these values determined whether the unit should move or attack next.

With no valid target in range, it moved toward the enemy. Once a target was in range, it stopped and attacked. The attack interval controlled when damage could occur. When a target was no longer valid, the unit looked again. Running up to an enemy and hitting it became the visible result of rules, rather than a sequence arranged in advance.

During the period recorded here, Kibble Street TD had four unit roles: tank, melee, ranged, and siege. Their health, speed, range, and attack rhythms served different purposes. The first implementation did not need perfectly balanced values. It needed all four roles to follow the same state rules. Stable shared rules made it possible to adjust their differences without maintaining four incompatible implementations.

Energy turns a click into a choice

If summoning costs nothing, players can keep pressing whichever button produces the fastest or strongest unit. The battle can quickly become repetitive clicking. Energy gives each click an opportunity cost.

Energy regenerated during battle, up to a cap. Each unit role had its own energy cost and summon cooldown. This gave the player a decision: send a cheaper unit now, or wait until a more expensive unit became affordable.

That decision also gave the enemy schedule a purpose. Enemies did not wait for the player to trigger them. They entered according to the level's timeline. Resources recovered while enemy pressure continued to build, creating a rhythm in which both sides kept acting.

Here too, the working rule came before balance. The energy cap, recovery rate, costs, and cooldowns could be adjusted later. First, the relationship between regeneration, payment, and cooldown had to run from beginning to end. Later balancing work could change those parameters without having to invent a new way to deploy units.

Distance gives combat a place to happen

With only health and attack power, a battle can remain two tables subtracting numbers from each other. Distance makes position matter. Melee units must get closer, ranged units can fire from farther away, towers cover nearby areas, and movement speed affects when a unit joins the fight.

In the rules covered by this article, a unit first looked for enemy units within attack range, then a tower, and finally a base. With no target, it kept advancing. This priority made enemies in front of it an obstacle and gave towers a clear role on the way to the base.

Target selection was revised several times during development. Attacks also developed from immediate damage into separate timings for melee hits and projectile arrivals. Those details could change because the chain from position to range, target, and damage existed independently of a particular animation or button.

The system must end the battle

A battle needs a stopping condition. At the stage described here, the main decision was straightforward: destroy the enemy base to win; lose the player's base to lose. Destroying a tower changed the battle line but did not end the battle. A countdown did not replace the base condition.

This simple decision determined where much of the later work belonged. The results screen, rewards, level progress, retry, and return-home flow could begin only after the battle system produced one final outcome. Otherwise, the screen might already show a victory while an attack still in flight applied damage, or two screens might both consider themselves in control.

Ending a battle therefore required more than displaying a results panel. The system also had to stop accepting summons, clear attacks that had not yet resolved, and hand the battlefield state over to the results flow. That completed the loop.

Calculate first, then show the result

Kibble Street TD began with a battle simulation separated from its presentation. The frame update, battlefield rendering, buttons, and HUD were connected afterward. Configuration supplied the levels, units, buildings, and rules. The simulation advanced their state. A snapshot passed the current energy, units, buildings, and outcome to the presentation layer, which rendered them.

This boundary avoided expensive kinds of rework. Changing character animations should not change who takes damage first. Moving interface elements should not change whether a unit can be summoned. As hit timing, target priorities, buffs, and battle items grew more detailed, the smallest complete loop remained a shared foundation.

The first battle mattered because it gave the project a center that could keep growing. Summoning brought units into the battle line. The battle line produced damage. Damage led to an outcome. Further content now had a clear place to connect.

Who was responsible for this stage?

The person defined the core experience and acceptance criteria: why the player needed to make choices, what counted as winning or losing, which rules had to come first, which visuals could wait, and whether the rhythm held up during play.

AI helped turn those rules into executable state, trace the existing calls, complete the configuration and simulation, and create ways to check them. Repeated runs could help expose conflicting states and check that the rules kept advancing under fixed configurations and inputs, with random seeds controlled where applicable. They could not decide whether the battle felt tense or the unit differences were meaningful.

Visuals, game feel, and balance still needed human playtesting. The rule loop needed repeatable checks wherever they could provide useful evidence.

Starting your own first battle

Five things are enough to define a starting point: the battlefield boundaries and spawn positions; the inputs available to the player; the state each unit must keep; how movement, attacks, and damage happen; and the condition that makes the system stop with one final result.

Start with one unit, one kind of building, and one stopping condition. Use them to establish the loop before expanding the character roster, effects, or interface. That version can look rough. It must still be able to run from beginning to end without the developer having to repair its state along the way.