Build the smallest thing that can teach you something

Small is not the same as useful

You want to know whether Night Mail’s route choices are interesting. You build a tiny version with one character, a short map, a menu, an inventory, a shop, a save system, and a weather toggle. Everything is smaller than the final plan. Two weeks later, the route decision still feels vague.

The prototype was small compared with the imagined game, but large compared with the question. Most of the work did not help you understand route choices. Worse, the shop and inventory may have introduced confusing side effects before the central decision was clear.

A more useful experiment could be a paper map with two routes, oil tokens, and a deadline. Someone chooses a route, explains their expectation, and sees the consequence. You can change a cost in seconds. If the decision has no interesting tradeoff, you learn that before making a menu.

This is not an argument against building. It is an argument for building deliberately. Sometimes the question requires real movement, sound, animation, or network delay. Then paper is the wrong tool. The question should choose the prototype, rather than your favorite tool choosing the question.

Name the uncertainty before the solution

“I need an inventory system” is a proposed solution. The uncertainty might be “Does carrying a second parcel create an interesting sacrifice?” Those statements lead to different prototypes. The first invites slots, drag-and-drop, item data, tooltips, and persistence. The second may need only a toggle that trades a free hand for one extra parcel.

Write your uncertainty as a question about behavior or experience. Will players notice that the bridge saves time? Will carrying two parcels change their route? Does a long jump feel controllable on a phone? Can players explain why the gate opened? These questions are specific enough to investigate.

Then write what you currently believe. “Players will carry two parcels when the route is familiar, but keep a hand free when exploring.” This prediction helps you choose situations and notice surprises. It is not a target the tester must hit.

Finally, write what would make you change your mind. If everyone carries two parcels because the free hand has no useful purpose, your tradeoff is weak. If nobody notices the choice, the interface may be weak. If they understand the sacrifice but dislike either option, the experience may need a different premise.

Write your experiment before you build it

Use this worksheet to turn your idea into a bounded test. Keep each answer short enough that another person could understand what you are trying to learn. The example is there to show the level of detail, not to choose your game for you.

You can copy the result as plain text. Keep the original plan beside your observations later. It is remarkably easy to remember that you predicted the result after the result has arrived.

# My game prototype experiment

## What do you want to find out?
Will players save oil for a later dark crossing?

## What do you expect, and why?
If the later crossing is visible, players will consider the slower route to preserve oil.

## What is the smallest useful test?
A paper map, two deliveries, route costs, six oil tokens, and a deadline.

## What will you watch?
What players inspect, their explanation of the first route choice, and what they do at the second crossing.

## What result would change your mind?
Players understand the costs but find the choice obvious in every starting situation.

## What will you leave out?
Shop, weather animation, dialogue, and persistent inventory. Keep reset and visible costs.

Play it: answer a feel question with a tiny room

Here is a prototype for a very narrow question: how should this ball respond when it hits something? There is no shop, character creator, or plot twist. You can test the part that needs motion by launching, watching, and comparing.

Set power to 400 so the ball reaches the floor before the tray. Keep a trace, then change bounce retention from soft to springy. After comparing that change, restore the original bounce and try a different gravity. You are changing one cause at a time rather than mixing several promising tweaks.

• Write a prediction before each launch: higher first rebound, shorter flight, or more repeated impacts.
• Look for an observable difference that matters to your proposed game. “More fun” is harder to investigate than “I can predict the second landing.”
• Choose a version for a calm sorting game and another for a lively trick-shot game. Explain why neither setting deserves to be called universally better.

Choose the medium that preserves the question

Paper is good for rules, turn order, resource costs, route choices, and early interface interpretation. You can move tokens and change numbers quickly. It is weaker for timing, physical control, animation readability, sound, and the feel of continuous motion.

A gray-box scene uses simple shapes in an engine. It can test movement, camera behavior, collision, scale, and whether a route is physically playable. It may not tell you whether the finished visual style makes objects readable or whether a character’s performance creates the intended emotion.

A visual mockup can test hierarchy, atmosphere, composition, and what a person thinks is interactive. It cannot prove that the mechanics work. A convincing screenshot of an inventory is still a picture of an inventory.

A technical spike investigates a technical risk: can a device load the scene, can an export run, can two clients synchronize an action? These are valuable questions. A successful spike does not establish that the game is enjoyable, just as a fun paper test does not establish that the target phone can run it.

Sometimes you need a hybrid. Print a map for route planning, then use a tiny playable scene for one crossing. Tell participants which parts are simulated and which are real. If you silently improvise outcomes to keep the session moving, you may accidentally test your ability to entertain rather than the proposed rules.

Keep the minimum evidence, not the minimum features

A route-choice test needs a reason to care about the costs. If you remove the deadline and the later need for oil, you may remove the tradeoff itself. The prototype becomes smaller but stops testing the intended question.

For Night Mail, keep two deliveries rather than one. The second gives saved oil a purpose. You can omit the shop, dialogue, character animation, and persistent inventory. You probably cannot omit the information that tells the player what oil is for.

List each proposed feature and ask what evidence it enables. “A second delivery reveals whether players plan ahead.” “A visible oil counter lets them judge the cost.” “A title screen makes it feel finished.” The last item may be useful later, but it is not necessary for this experiment.

Do not confuse an ugly prototype with a clear one. Placeholder art still needs readable shapes, legible text, and distinguishable states. If every object is an identical gray cube, your test may measure confusion that the intended game would never create. Cheap should mean inexpensive to revise, not deliberately incomprehensible.

Likewise, a prototype can be polished in the one dimension that matters. If you are testing a character’s emotional appeal, a careful animation may be the core of the experiment. You can leave the surrounding world crude. The right amount of polish follows the question.

Make the experiment repeatable

A playable prototype needs a short path from starting state to result and back again. If a tester must reload the whole project or navigate several menus after each attempt, you are spending their attention on setup.

Give the experiment a clear starting state. In Night Mail, everyone begins with the same map, oil, and deadline. If you want to compare two versions, keep those conditions stable while changing the rule under investigation. Random variation can be useful later, but it makes a first comparison harder to interpret.

Include a reset you have tried yourself. Check that it restores the relevant resources, object positions, counters, and timers. A reset that leaves one hidden value behind can make later attempts incomparable, and the resulting behavior may look like an interesting design discovery.

Decide what happens at the end. A simple delivery confirmation is enough. It should make success, failure, or completion observable. Without an ending, a participant may stop because they are bored, because they think they finished, or because they do not know what to do. Those are different outcomes.

The loop can take thirty seconds. A short, resettable experiment gives you more opportunities to compare attempts than a sprawling prototype that only works when you perform the setup exactly right.

Give yourself a cut rule

A time limit helps only if you know what to cut when the work expands. “Finish a prototype this weekend” can become a weekend spent building infrastructure. Instead, define the question, the minimum scene, and the first things you will remove.

For example: “By Sunday, someone can choose between two routes and complete two deliveries. If time runs short, remove the moving water and represent the flood with a blocked path. Keep visible route costs and reset.” The cut preserves the decision while replacing an expensive presentation detail.

Write a separate parking list for ideas you like. New parcel types, a weather forecast, a companion bird, a nicer bag. You are not rejecting them forever. You are preventing them from silently changing the experiment halfway through.

Be especially suspicious of features that promise to make future work easier while delaying the first playable moment. A reusable quest framework may eventually be valuable. It may also be an elegant way to avoid discovering that your one quest is not interesting. Let a real need earn the abstraction.

If you use an AI coding assistant, give it the same cut rule. Ask for a small revision with explicit observable behavior. Review the result in the project, not only the explanation. Generating more code quickly does not reduce the cost of understanding a larger design.

Decide what you will watch

An experiment needs evidence you can observe. “The player enjoys route planning” is an interpretation. “The player compares both route costs before choosing” is a behavior. “The player says they felt clever after using a shortcut” is a report. Both can be useful, but they are not the same kind of evidence.

Choose a few observations that would inform your question. For the route prototype: whether the player notices both paths, whether they can explain the costs, whether their second choice responds to the remaining oil, and what they say they expected at the junction.

Do not turn the session into a surveillance project. A notebook with a handful of timestamps and actions can be enough for an early test. If you record a person, ask first. If you do not need a detail to answer the question, you probably do not need to collect it.

Write down surprises in the player’s words when possible, but distinguish a quote from your summary. “I thought the blue road was locked” tells you something specific. “Player confused” hides the useful part. The next lesson develops this into a practical playtesting method.

Know what a useful stopping point looks like

A prototype does not have to become the production game. Its job may be finished when it exposes the tradeoff, identifies a control problem, or shows that the central idea needs rethinking. Throwing away the code does not throw away the learning.

At the end, choose among a few concrete next steps. Keep the idea and test a harder situation. Revise one rule and repeat. Investigate a different uncertainty. Or stop because the result does not support the experience you want. “Keep polishing until it feels right” is sometimes necessary, but it should not be the only available decision.

Separate an inconclusive test from a negative result. If nobody understood the controls, you have not yet learned much about the route tradeoff. If they understood the tradeoff and consistently found it dull, you have stronger evidence about that design. Fixing the test and changing the idea are different actions.

Keep a small record: question, version, conditions, observations, interpretation, next step. A screenshot or short clip can help reconnect the notes to the actual version. This record is useful when you return after a week and cannot remember why the bridge costs four oil.

Give two ideas a fair audition

Tracy Fullerton’s Game Design Workshop teaches a playcentric practice built around prototyping, playtesting, and revision. A useful application for our small project is to compare alternative answers before polishing one of them.

Suppose Night Mail’s dark crossing feels like a dull fuel payment. Version A makes the player choose when to light the lantern. Version B lets them place a temporary lamp, then cross within its light. Both use the same oil budget and the same room. Which creates the experience you want? You cannot decide that from the feature names.

Make two rough paper versions. In A, mark the lit turns on a strip of paper. In B, place a coin representing the lamp on the map. Each version needs a way to spend oil, cross, fail, and reset. Neither needs an inventory screen or a finished character.

Before testing, write a reason each version might fail. A may become an obvious on/off routine. B may become fiddly placement with little judgment. This protects you from spending the whole session collecting compliments about your favorite idea.

Let players try both, and vary the order when you can. A second version can benefit from familiarity with the room, or suffer because the first version taught a different habit. Ask for an account of a decision in each version before asking which they prefer. A preference matters, but an explanation helps you decide what to keep.

Your result may be “neither.” That is a good result if it arrives before you make forty lantern animations. You could remove oil from this scene and make the crossing about timing a moving light instead. The prototype has saved you from an expensive commitment, even though it produced no shippable asset.

Make a tiny design record your future self can use

A prototype without a decision record becomes mysterious surprisingly quickly. A week later, you may remember that the lamp version was “better” without remembering who tried it, what went wrong, or which part mattered.

Keep a short record with the question, the two versions, the conditions, what happened, and the next decision. Attach a photo or sketch of the actual layout. Label uncertainty directly: “Two players found lamp placement easier to explain; we have not tested touch placement.”

Separate a promising design from a production commitment. A paper lamp can slide anywhere because your hand moves it. A phone interface needs a way to select it without covering the destination. The next prototype should answer that newly exposed question before you build a full item system.

For the course project, your handoff is one page: the experience promise, the most important choice, a simple map, one test record, and the next uncertainty. Someone else should be able to run the experiment from it. If they need you to explain three secret rules, improve the page.

A worked plan for Night Mail

Question: Will players preserve oil when they can see a later dark crossing? Prediction: they will choose the slower first route if the second delivery visibly requires light. Prototype: two junctions on a paper map, six oil tokens, a visible deadline, and a written resolution for each route.

Keep: both deliveries, visible costs, the later crossing, a clear starting state, and reset. Cut: weather animation, shop, character movement, and dialogue. Observe: what players inspect before choosing, their explanation of the first choice, and whether the remaining oil changes the second choice.

A result that would change our mind: players understand every cost but say the decision is obvious and make it instantly in all starting situations. A result that would require a clearer test: players think the lantern icon is only decoration and never notice oil.

Next step after the paper test: if the tradeoff has promise, put it into a small playable route and test whether movement and camera framing preserve the information. Do not jump straight to a whole evening’s delivery campaign. You have answered one question and earned the next.

Your own worksheet is the practical output of this lesson. Once it names a question you can actually investigate, you are ready to put the prototype in front of someone. The next lesson is about listening to what happens without accidentally teaching the tester to agree with you.