Production

Scoping a Small Game So That It Actually Ships

Most unfinished games were not too hard to make; they were too big. Scope is a design skill, and it can be practised like any other.

Why projects grow

Scope creep is the continuous or uncontrolled growth of a project's scope after work has begun. In games it rarely arrives as one big decision. It arrives as a hundred reasonable ones: a second weapon, a crafting screen, a day and night cycle. Each seems small, and each multiplies the testing, art and interface work of everything already built.

Begin with the constraint, not the dream

Before listing features, write down what you truly have: how many hours per week, how many months before your patience or savings run out, and which skills the team lacks. A design that fits those limits will feel modest on paper. That is the correct feeling.

The one-page plan

One sentence. What the player does and why it is enjoyable.
Three pillars. Qualities every feature must serve, for example "tense", "readable", "short sessions".
A must-have list of five items or fewer.
A clearly labelled "not in this game" list. Writing down what you are refusing is what makes the plan real.

Build a vertical slice

A vertical slice is a portion of a project that demonstrates progress across all of its components at once. For a game, that means a few minutes of play at close to final quality: one level, one enemy type, real art, real sound, a working menu. It tells you two things nothing else can: whether the game is good, and how long one unit of finished content costs. Multiply that cost by the amount of content planned and compare it with the time you have. Then cut.

Smallest thing that can teach you something

The idea of a minimum viable product, a version with just enough features to be usable by early customers who can then give feedback, translates well to games. A free demo, a jam build or a small early release puts the core loop in front of strangers while there is still time to change it.

Cutting without regret

Cut whole features, not quality. Three polished levels beat ten rough ones.
Cut what multiplies. Anything that has to work with everything else, such as multiplayer, a second playable character or a physics system, costs more than it appears.
Keep a "sequel" file. Ideas placed there are not dead, only postponed, which makes them easier to let go.
Reuse. New rules for existing art are cheaper than new art for existing rules.

Warning signs

You have worked on systems for months and there is still nothing to play.
The task list grows faster than it shrinks.
You avoid showing the game to anyone.
You are rebuilding something that already worked.

Finish something tiny first

A game jam is an event where participants try to make a game from scratch in a short span of time. Taking part in one is the fastest way to practise the whole arc from idea to release, including the unglamorous last tenth: menus, saving, a build that runs on someone else's machine. Finishing is a skill separate from making, and it is only learned by finishing.

// Kit Farrowdale // revised 2026-11-12