Build the question, not the game

Starting the real game the moment the idea feels clear is how months disappear. Final art, music, and systems that are painful to throw away are a terrible place to discover that the verb is boring. A prototype exists to answer one question cheaply enough that a no is a success.

The question might be feel, or whether a rule is legible, or whether two players can communicate. It is rarely whether the menu is pretty. Keep the build ugly on purpose so you are not defending the art when the verb fails. Hand it to someone else as soon as the question can be felt. Your own hands already want the idea to work. A cheap no, early, is the whole point of the exercise. A beautiful prototype that cannot be killed is just production with a shy name.

More on this: Random game idea generator, and what to do the moment after

Starting the real game the moment the idea feels clear is a mistake, because production is where the money and the months go. Final art, shippable code, music, systems, content: all the work that makes a project look serious is also the work that is painful to undo.

Look at what happened before two of the most polished games of the last decade. Cuphead's team drew thousands of hand-animated frames eventually, but first they made a tiny playable version that looked crude. Breath of the Wild ended up an enormous open world, and Nintendo began it as a plain top-down 2D build assembled from old Zelda-style sprites.

Neither of those rough versions was a detour to be embarrassed about. They were prototypes, made small and scrappy on purpose to put the idea under test. Nobody is asking you to build an extra game in front of the real one. The aim is to learn the thing that matters most while being wrong still costs almost nothing.

Strip it back and a prototype is a device for getting a quick answer to a question you cannot answer any other way. Most often the question is whether the thing is actually fun.

You need the build because your head is a bad simulator of your own game. A mechanic described out loud will nearly always sound good. What is missing from the description is everything that decides the outcome: timing, feel, rhythm, friction, the moment of confusion, the stretch of boredom, the surprise you never planned. No document surfaces those. Playing it does.

Nintendo's habit of making something before talking about it points at the same truth. Ink-splatting in Splatoon, vehicle building in Tears of the Kingdom, wonder transformations in Super Mario Bros. Wonder: in each case the useful move is to build a version small enough to try, rather than to argue the full concept into existence.

Here is how that plays out in practice. A designer can be genuinely certain that a one-button shooter will land, because firing an Uzi shoves the character backward and shooting therefore doubles as movement. Build it and the flaw shows up in seconds: being permanently pushed away from your target reads as timid, not powerful. The concept is clean and the sensation is wrong, and only playing the build tells you so.

Fun is the usual question, not the only one. Anything about the game you are genuinely unsure of can be put in front of a prototype.

A strategy game such as Thronefall might use one prototype to check the loop and separate ones for art styles and camera angles. Story-led projects can prototype the narrative first. Pixar routinely assembles a whole film as a rough animatic, temporary drawings and stand-in voices throughout, to find out whether the story holds before anyone starts expensive 3D work.

Viability is another question a prototype answers well. Making a small version is a sample of what production will feel like. If a puzzle game's prototype makes good puzzles easy to author, the design space is probably rich. If each puzzle is a fight, expect that fight to repeat a few hundred times.

Scope shows up the same way. Imagine a small prototype of a game about running a video rental store, restocking shelves and answering customer queries. If even the sample takes weeks, that is a hard number about the full project, and it may be telling you to postpone, shrink, or drop the idea.

The other big question is whether anyone besides you will like it, which is not the same question as whether you like it. Something people can pick up and play says more than any pitch, mood board, or design document.

Sea of Thieves had a premise about being a pirate with your friends, and a rough multiplayer build could show that premise happening: real cooperation, real conversation, real social chaos. Final graphics were beside the point. What mattered was making the behavior visible while people played together.

Tiny prototypes do this too. A roguelike spelling game thrown together in two days at a jam can show you that people grasp it, enjoy it, and want the bigger version. That reaction is often what sustains a developer through the long production that follows.

A flat response is worth just as much. Sometimes a prototype delights its creator and lands with silence, and that is the prototype working exactly as intended. Finding out in a few weeks that nobody cares beats finding out two years in.

A prototype that fails feels bad and is one of the best results you can get, because it delivers the no while the bill is still small.

That is the argument for prototyping early rather than eventually. You can still pivot, tune, or walk away before sunk cost makes honesty uncomfortable. Find out the bridge design is wrong while it is wood, string, and zip ties, not when half the team is standing over the river.

The idea is not what you are defending. You are defending the project, the schedule, and the people on it against a full commitment to something that only ever worked inside someone's head.

Speed is the whole value of a gameplay prototype, so the first rule is to resist making it look and sound finished.

Reach for ugly programmer art, gray boxes, the default engine mannequin, borrowed sprites, free store assets, placeholder sounds, and a rough interface. Skip the extensible architecture when the code is headed for the bin. Do not commission music. Do not polish a menu that may not survive the month.

Disposability is the design. Pouring production-grade effort into work you plan to throw away slows the learning and quietly builds attachment to it. It also muddies feedback: when playtesters spend their time on the story, the art style, or the finish, the question of whether the core mechanic works gets harder to read.

Everything in the prototype should make the question easier to see. Anything else is a cost you chose to pay.

There is a real exception to the ugliness rule, because feel is sometimes part of what you are testing. Strip a visceral action game down to nothing and you may under-test it, since impact, feedback, particles, sound, and response are half of why the mechanic satisfies.

Fruit Ninja makes the case. The prototype could stay simple, but it still needed enough splatter and response to prove that slicing fruit was pleasurable. Without that layer, the core pleasure may never show up at all.

The trap is juice covering for a weak center. It is easy to believe the game gets fun after twenty more effects, a bit more camera shake, better art, more sound, and a month of polish. Occasionally that is true. Often those additions are a dressing over an interaction that is not compelling yet.

So ask yourself honestly which one you are doing: adding the minimum feedback the idea needs to be judged fairly, or adding polish to postpone the verdict.

Nothing says a prototype has to be built in the engine you will ship in, or in an engine at all. Pick whatever medium reaches the answer soonest.

Journey was prototyped in Flash long before anything had to run on PlayStation 3. Storyteller tested its puzzles as cardboard mock-ups. Scrabble tiles and handmade cards are enough to explore a word game. A detective game can run over Discord, where you post a sketch of what the player sees and ask what they do next, much like refereeing a tabletop campaign.

Metal Gear Solid levels were laid out in Lego and shot with a tiny camera. A heavy simulation can start life as a spreadsheet or a board game. A movement system can start as animation clips. Limbo used a cinematic concept video to convey mood, pull in collaborators, and raise money.

None of these is the game. Each answers something: whether the puzzle logic holds, whether the level reads, whether the loop makes sense, whether the motion looks good, whether the concept survives being explained. Let the question choose the medium instead of the other way around.

A prototype is a small sample of one thing, not a bad copy of everything. That one thing might be a mechanic, a feature, a system, an art direction, an interface, a level idea, or a technical risk.

Scope it around a single question you can state in a sentence. Does the main verb feel good? Do players work out the puzzle rule unaided? Is the camera angle readable? Does the AI behavior produce the tension you want? Does this art style hold up at the scale the gameplay runs at?

Keeping prototypes apart helps as well. Gameplay, art, technical, and audio experiments can live in separate project files. Fuse them early and every question gets harder to isolate and every change gets heavier to make.

Small also means more shots on goal. Mini Motorways ran through nearly 20 versions before production, each answering something different and shaving off a bit more risk. More prototypes means more decisions already made when the expensive phase starts.

Prototyping filters the ideas you already have and produces ideas you did not, which is the half people forget.

Brainstorming has its place, but making something changes what there is to talk about. Write throwaway code, push numbers around, drag objects into odd arrangements, try the variant that sounds silly, and the prototype's own behavior starts handing you material.

Fast iteration is what unlocks that. Test a version, spot an interaction nobody designed, build the next version around the accident, and you can arrive somewhere better than the pitch ever was. Plenty of games are partly designed by chasing what the prototype turned up.

The cheaper and quicker the build, the more of those accidents you get to have. Expensive prototypes make a team careful. Cheap ones make it curious.

A prototype cannot answer everything, and it is not supposed to. It tells you the ground is fertile. It does not tell you what to plant, how each feature will work, or what the production details become.

Jetpack Joyride shows the split clearly. The early prototype was little more than the machine-gun jetpack dropped into an existing runner framework, with the level stripped back, a roof put on, and obstacles added. That was enough to establish that the core movement had something in it.

Challenges, missions, vehicles, and most of what made the finished game distinctive arrived later, in production. The prototype never had to hold the whole game. It only had to answer the riskiest question: is this movement entertaining enough to build on?

Being clear about that matters, because prototyping is habit-forming. New experiments are pure upside: no production debt, no asset pipeline, no obligation to finish. There is always a voice suggesting the next prototype might be the good one.

Prototyping forever means shipping nothing, so recognizing the moment to move into production is part of the skill.

The opening phase is there to clear the biggest and riskiest questions. Is the core fun? Can it realistically be made? Does anyone outside the team care? Is there enough confidence here to commit real money and time?

You will still have hundreds of smaller design questions open, and that is fine. Production is not the phase with no uncertainty left. It is the phase where what remains is small enough to live with, because the large risks have already been cut down.

Certainty is not the standard. A good prototype gives you enough evidence to commit, to change course, or to stop.

Prototyping is not a stage you graduate from. It is a cheap way to test an idea or answer a question, and that stays useful for as long as the project has questions in it.

Adding a feature? Prototype it. Designing a boss fight? Prototype it. Not sure a level route reads? Prototype it. Torn between a double jump and a dash? Make quick versions of each, get them in front of playtesters, and go where the evidence points.

Treated that way, prototyping is simply how you keep risk down. The build does not need to be impressive, finished, or permanent. It needs to turn the next real uncertainty into something you can run and judge for yourself.

That is what prototyping is for. Not stalling the game, but confirming the game is worth making before the costly work starts, and continuing to answer the hard questions while they are still cheap to get wrong.

In the Flockbay app, write the question at the top of the brief and ask for the smallest room that can answer it. No extra content. Play it, or hand it over. If you are talking about the art, you asked the wrong question. Ask again, smaller.

An AI game maker for game jams and a start-here template are biased toward finishing. Use that bias on the question, not on a vertical slice of a dream.