The First Complete Playable Version

Previous: Why a Finished Battle Is Not a Finished Game

The first five articles covered the idea, collaboration, battle rules, visual presentation, and the flow outside battle. This installment adds no new system. Instead, it follows what was already built in the order a player would actually experience it.

Open the game, load, choose a faction, enter Home, prepare for battle, win or lose, receive rewards, buy upgrades, and reach the next level. If that path holds together—and closing the game does not lose the state needed to continue—Kibble Street TD has its first complete playable version.

Fully playable means more than being able to open every screen

A project can have a Home screen, a shop, upgrades, and a battlefield without being complete. Screens are entry points. What matters is whether a player's actions have lasting consequences.

For Kibble Street TD, this meant at least four things: the game could start without an existing save; players could make choices that persisted; battle results could change resources and progress; and reopening the game could restore a state consistent with those results.

If any one of those connections was missing, the experience broke apart. Entering a battlefield was enough for a battle prototype. Moving between screens was enough for an interface prototype. Winning without being able to use the reward afterward was still a demonstration with no continuing consequences.

The first launch establishes the player's starting point

A new player saw loading followed by faction selection. At this stage, the game did not choose cats or dogs on the player's behalf, or leave the decision as a button's selected appearance. After confirmation, it saved the faction together with the initial state, then prepared the matching Home screen.

A new save started at Stage 1 with zero KIBBLE and zero CANS. It granted one of each of the eight enabled battle items. Players could try preparing items before their first battle, but did not begin with currency already available to spend on upgrades.

Home showed the selected faction, resources, units, and the Stage 1 entry. It became interactive only after its entrance animation finished and the input block was removed. A screen being visible and a player being able to click safely were two separate completion conditions.

The first battle connects the previous five articles

After pressing GO, players entered preparation and chose which items to bring. Once the battle started, replenishing energy let them summon units with different roles. Units moved, found targets, and attacked buildings until one side's base was destroyed.

What looked like a sequence of screens depended on everything covered so far. The original cat-versus-dog idea supplied the theme. Battle rules determined who could attack whom. Presentation translated state into characters, animation, and feedback. Navigation delivered the player to the battlefield. Saving carried the changes out of it.

Once the outcome was known, the game recorded item consumption, resolved level progress, KIBBLE, and any applicable chest rewards, and saved the changes before showing the results panel. CANS came from chest rewards; they were not a fixed currency reward for every victory. When players saw VICTORY, the outcome was already more than an animation: it was updated state that Home and the upgrade screen could read.

A reward completes the loop when it changes the next decision

After winning Stage 1, players could continue or return Home. Back at Home, the next-battle entry reflected their progress. Once they had enough KIBBLE, they could spend it on lasting improvements to buildings, units, energy, or reward abilities.

That gave the first battle consequences. Players were not returning to an identical starting point. They made another decision with new resources and progress. Purchased upgrade levels were saved and used in later battle configurations. The next outcome could then provide more resources, advance progress, or send the player back to prepare again.

The complete loop was therefore more than three screens connected as Home, battle, and Home. The earlier result had to change the later choice.

A complete version needs branches, not just one successful run

Real players do not all follow the same path. Some arrive for the first time; others return with a save. Some choose dogs, others cats. A battle can end in victory or defeat. Afterward, players may continue, go Home, or retry.

Those branches could not maintain unrelated versions of the player. Victory needed to advance progress; defeat still needed to resolve what actually happened in the battle. Home needed the latest resource changes. Closing and reopening could not grant the starter items again or ask a player with a saved faction to repeat the original choice.

A recording of one uninterrupted route to victory proves that the route worked on that occasion. Checking the necessary combinations of starting state, faction, outcome, and return action helps establish that the game is more than a single path assembled for a demonstration.

It must also be able to leave the editor

Editor previews are useful for quick changes and visual checks. Players ultimately encounter a built application. In the development records through August 2, 2026, Kibble Street TD had completed the path from the game project to an iOS project, archive, and exported app package. That was evidence that the scripts, configuration, and assets could leave the development environment together.

Successful building, complete playability, and readiness for release remained different conclusions. An exported package only proved that its particular snapshot had built successfully. Later changes to code, configuration, or assets needed fresh checks and a fresh build. An old artifact could not stand in for the current version.

When the first six articles' records were assembled on August 2, 2026, some automated checks still stopped because asset formats and later rule changes had fallen out of sync. The evidence at that point supported two conclusions: the complete play loop had been established, and the iOS build pipeline had worked. It did not establish that the current version had passed every release check or that iOS was already on the store. The release update at the top of this article gives the current store status.

The first version is a baseline, not the end of the project

These six articles began with cats and dogs fighting across a neighborhood. They now reached a version that could launch, accept a choice, run a battle, resolve its result, support growth, and continue. Taken together, they described a working baseline that could be played, checked, and changed repeatedly.

The value was not limited to finally having something to show. Later changes now had a reference point. Reworking the UI had to preserve navigation. Replacing animation had to preserve battle state. Balance changes required checking the whole play loop again. Platform features had to fit without blocking the existing experience.

A playable version still left plenty of rework ahead. Consistent interfaces, assets suited to real screens, stable animation, and engaging balance were not the problems these first six articles set out to finish. They were where the next phase began.

Who is responsible for this part?

The human defines what counts as a complete version, which paths must work, and the boundaries between playable, buildable, and ready to release.

AI helps trace state through the actual flow, organize the necessary test paths, and check whether code, configuration, screenshots, and build artifacts support the same conclusion. When evidence is incomplete, the claim needs to be narrower.

The engine runs scenes, loads assets, and generates the target platform project. It does not automatically prove that the game flow is complete, or decide whether an older build represents the latest version.

Where to start

Do not measure the first version by how many screens are finished. Write down the shortest path a player can actually complete: start with no save, make the first choice, enter the core gameplay, produce a result, save it, and use that result to make another decision.

Then add the few branches that are necessary: returning to the game, losing, retrying, going back, and making the other core choice. For each path, identify the starting state, the player's action, the resulting state change, and where the player ends up.

Finally, record three conclusions separately: whether the play loop is complete, whether the target platform build succeeds, and whether the current candidate has passed release validation. They can be achieved at different times. None substitutes for the others.