A Game Begins with One Sentence

Game projects rarely lack ideas. The difficult part is deciding whether an idea contains a structure that can sustain repeated play.

A theme, a world, and a list of features can all grow quickly. None of them, by itself, proves that a game works. For Kibble Street TD, the first design hypothesis was concrete:

Choose the cat or dog faction, spend regenerating energy on four unit roles, gain a local advantage along a horizontal battle line, and ultimately destroy the opposing base.

That sentence does not describe a complete product. It does identify the player's position, the core resource, the main decisions, the relationships on the battlefield, and the condition that ends a battle. The first task was to see whether those relationships could stand on their own, without the surrounding systems.

From a theme to a design hypothesis

Cats versus dogs gives the game two recognizable sides and an immediately understandable visual premise. The theme is an entry point. The gameplay comes from the decisions the player makes repeatedly.

Energy regenerates during a battle. At different moments, the player decides which role to summon. Tank absorbs damage, Melee fights up close, Ranged attacks from a distance, and Siege costs more energy but delivers stronger individual hits. Units advance automatically. The player does not direct every attack, so deployment timing and the mix of roles become the main actions.

Those relationships form a loop:

Choosing a faction establishes a side. Limited resources create constraints. Different units make the available choices distinct. Changes in the battle line provide immediate feedback, and the destruction of a base produces a clear result. The player enters the next battle with judgments formed in the previous one.

A core loop earns its place by continually asking the player to make decisions and making their consequences observable.

The core loop tells us whether to continue

At the prototype stage, four questions matter more than the number of screens:

1. Does the player make decisions at a useful frequency?
2. Do different choices have clear costs?
3. Can a choice change the battle line, the resource balance, or the likely outcome?
4. Can the player understand why things changed from the visuals and feedback?

If energy is always abundant, unit costs stop mattering. If the four roles differ only in appearance, choosing between them becomes arbitrary. If the battle line changes without clear feedback, the player cannot use the result to make a better decision next time.

The first version should expose those structural problems early. A prototype has done its most important job when it lets actual play test the design hypothesis.

A prototype only needs the necessary constraints

Six constraints were enough to define the first version:

Both sides need a base and a defensive tower. The battlefield stretches across four horizontal screens. Energy regenerates, but the player cannot summon without limits. Four unit roles perform different jobs. Destroying a base determines the winner. Cats and dogs each have a recognizable entry into the game.

Together, those constraints answer who is fighting, how the player intervenes, how the battlefield changes, and when the battle ends. Upgrades, a shop, events, advertising, and other surrounding systems can wait. They cannot substitute for the core battle.

The numbers do not have to be final on day one. A prototype first tests whether the relationships work. Balancing then adjusts pace, pressure, and strategic room within that structure. Keeping those questions separate helps prevent endless numerical changes from concealing a flaw in the game itself.

Turning a description into a runnable prototype

The journey from a sentence to a functioning battle contains several explicit steps:

First, rewrite the theme as a design hypothesis and identify the decisions the player will repeat. Then establish the differences between units and the relationships among units, bases, and defensive towers. Complete the win and loss conditions and the feedback around the result. Meaningful playtesting can then begin.

The goal is to make a vague discussion observable. Do the four roles actually perform different jobs? Does energy regenerate so quickly that decisions become frantic, or so slowly that the player spends too much time waiting? Does the battle line stall? Can the player recognize whether a battle is going well?

Those questions need a running game.

A prototype is a tool for testing ideas. It turns abstract assumptions into concrete behavior, allowing weak assumptions to be discovered early.

Testing relationships, then improving their presentation

When examining the battle structure, much of the interface can temporarily be removed. Bases, moving units, and the places where they meet are enough to inspect the underlying relationships.

Once those relationships settle, the information, controls, and feedback the player needs can be added in layers.

At this stage, the battle interface included faction information, speed controls, chests, battle items, four unit cards, and a segmented energy display. These additions improved the information hierarchy and made actions easier to perform. The core question remained the same: how should the player spend limited energy on timing and unit composition to move the battle toward the desired outcome?

Product development makes an established set of relationships easier to understand, easier to use, and more practical to extend.

From the core loop to a first version

As development continued, the original battle loop expanded into faction selection, a home screen, and the full battle interface.

The version at this stage was organized around 100 playable levels, and work was moving toward preparation for version submission. The home screen, upgrades, shop, battle items, results, saves, and other systems had grown around the original core loop.

Later versions could continue changing content, mechanics, and presentation. Every addition still needed to answer a consistent question: does it improve the player's decisions, feedback, or longer-term goals? Keeping that criterion stable allows a project to evolve without having to rediscover its direction with every new feature.

What humans and AI each contribute

During the concept stage, the human defines the problem: the player's position, the important constraints, the goals that must remain fixed, and the criteria for evaluating a prototype. After the prototype runs, actual play informs the judgment about whether the design works and what should be kept, changed, or removed.

AI is useful for translating the description into working material and covering the implementation work: organizing natural language into rules, data structures, and program skeletons; checking for gaps among resources, units, and outcome conditions; and producing an initial version that can be tested.

These responsibilities are different. AI can shorten the distance from description to prototype, but design decisions still require human judgment. A human also needs to define the goal clearly instead of letting the generated result decide it.

A useful working sequence is:

Design hypothesis → runnable prototype → playtest observations → revised constraints → another test.

If you want to start a project

Before production begins, write a one-page model that answers five questions:

1. Who is the player, and what situation are they in?
2. What main decision will they make repeatedly?
3. Which limited resource or rule constrains that decision?
4. How will the system show the consequences?
5. What ends one complete loop?

One or two sentences for each answer is enough. Then make only what is needed to test those five relationships. The shop, progression, events, and commercial systems can follow.

The useful result of this first stage is a core loop that can be run, observed, and disproved. If it holds up, the project has a reason to grow. If it does not, discovering that early protects the time and effort that would otherwise go into expanding it.