Adding and Removing Features Both Matter

Previous: How Battle Mechanics Go Beyond Bigger Numbers

As Kibble Street TD's combat, balance work, and mechanics progressed, it was tempting to assume that adding more features would make the game more complete.

AI made that temptation stronger. An idea could quickly become page structures, rules, tasks, and working code. The scarce decision was increasingly whether it belonged in this version at all.

The first release candidate needed a focused, verifiable main path. This historical work established a FORMATION foundation without inventing candidates, added eight one-time starter items, set a playable stage limit, reused settings for pause, and removed a completed reward-draw feature. Each decision asked whether the current version would become more focused and reliable.

FORMATION: build the entrance before filling every slot

The battle lineup used tank, melee, ranged, and siege roles. FORMATION could display the current lineup, read each role's unit, find candidates, save a selection, and notify other systems.

At the August 2, 2026 cutoff, each role had only one production unit. The page therefore did not offer an apparently selectable replacement without real content. Candidate positions showed empty state, without invented statistics or a save action. A future unit needed a matching role, unique identity, and complete idle, run, attack, death, victory, and stun atlases for both factions.

The deliverable was a contract for adding units. It could reveal data and asset gaps immediately while candidate design and production remained future work. Holding a feature at that boundary was more honest than filling the page with portraits that could not be used.

Small features still need a lifecycle

Eight starter items could enter the version with a narrow scope: five for battle and three for preparation. The first faction choice granted one of each so players could try them early.

Initial KIBBLE and CANS remained zero. The grant belonged to the first-choice operation, without daily refills or another sign-in or beginner-reward page. If saving failed, the faction and inventory returned together to the state before the choice, avoiding a partial save with the identity set but the items missing.

This created an opportunity to try the items without adding another long-term reward loop to operate and maintain.

A release limit is a feature too

Scope had to be enforced by the game. The recorded version capped playable progression at Stage 100. Home could not enter another stage at the cap, battle startup rejected out-of-range or skipped stages, settlement rejected invalid progress, and Stage 100 victory replaced NEXT with a centered HOME action.

Hiding one button would not stop an old save, invalid route, or test entry from crossing the boundary. Checking presentation, entry, and settlement against the same limit defined where the release actually ended.

That preserved room for later content while keeping the promised verification scope explicit. It also made it easier to decide whether new content belonged in this candidate or a later update.

Pause reuses a page but must stop the whole experience

Pause involved two timelines. Opening battle settings paused the simulation, froze character animation and effects, and blocked battle input. A separate pause page was unnecessary.

Closing settings resumed only a battle that had been running. Restart and Home did not briefly resume it first. Restart recorded abandonment and reloaded the same stage. Returning Home persisted consumed battle items before leaving.

The useful simplification was reusing an existing entry while completing its state handling. Players received predictable pause, resume, restart, and exit behavior without another standalone system.

A completed feature can still be removed

A reward-draw page had already included a circular reward display, single and ten draws, daily free attempts, ad attempts, paid spending, multiplied rewards, and animation. It was a working branch spanning screens, rules, assets, and saved state.

Against the first release's goal, it created another economic loop alongside battle, results, upgrades, and the next challenge. It also added daily state, advertising triggers, probability explanations, and verification work. Being functional did not establish that it served an essential purpose in this version.

Removal covered the route, page, draw rules, reward configuration, save fields, ad placement, analytics events, images, and dedicated checks. Hiding the entrance would have left the maintenance burden in place.

Incomplete removal leaves ghosts: saved fields after the entrance disappears, preloads for deleted images, or analytics expecting events from an abandoned ad placement. Deletion needs acceptance criteria and an understanding of dependencies as much as a new feature does.

Four decisions are more useful than yes or no

The work separated four outcomes: finish a small feature that solves a current problem; establish a reliable foundation where future content is missing; enforce a release boundary; or remove a branch without a necessary role in the main experience.

The questions were practical. Which player action changed? Did the feature create another resource or state loop? Could failure recover? How many entries needed checking? Would the main path remain complete without it? Appearing richer was not sufficient on its own.

What do the human and AI each do?

AI can expand states, failure paths, and checks when adding a feature, or trace routes, configuration, saves, assets, ads, and analytics when removing it. For an extension foundation, it can make missing integration conditions fail visibly today.

The human decides the version's purpose, whether a side branch weakens it, and when sunk cost must be accepted. AI can help establish that a removal is complete. It cannot alone establish that the product is better without the feature.

Where to start

Classify active work as required now, extension foundation, release boundary, or complete removal. Write acceptance conditions for the latter two as well: where out-of-scope access is blocked, and which entries and data must disappear.

Then examine a feature you are reluctant to remove without considering the time already invested. Ask whether it strengthens this version's central loop. That question is often more useful than asking what else can be added.