How to Structure a Two-Day Prototype Sprint

A two-day prototype sprint works when it answers exactly one question with a playable build. The scope is one mechanic, one level, placeholder art, no menus, and no progression. The schedule is hour-by-hour because two days leave no room for unstructured exploration.

Why two days and not seven

A seven-day sprint, like the one in Seven-Day Prototype Process, has room for art, polish, and a second pass at the mechanic. Two days have room for none of that.

The two-day format exists for a specific situation: you have several concepts competing for a test slot, and you need a playable build of each to decide which one earns it. Building three two-day prototypes in a week costs the same as one seven-day prototype, and the information is different. Breadth instead of depth.

It also works when a publisher wants to see gameplay before committing a test. A two-day build is not test-ready, but it proves the core interaction exists and the concept is not just a pitch.

The one question

Write it down before hour one. Tape it to the monitor. Every decision for the next two days serves this question.

Good questions for a two-day sprint.

• Does this core mechanic feel interesting for sixty seconds?
• Does the concept produce a clear, watchable moment for a test video?
• Is this interaction distinct from the three games it is most similar to?

Bad questions.

• Is this game fun? Too broad. Two days cannot answer it.
• Will this retain? Requires progression, which a two-day build does not have.
• Can we monetize this? Irrelevant until the loop is proven.

The question determines what you build and, critically, what you do not build. Everything that does not serve the question is cut.

A two-day prototype that answers its question is more valuable than a two-week build that half-answers five.

Day one: build the interaction

Eight hours. Every hour has a job.

Hours one and two: setup and core mechanic skeleton. Create the project, set the target resolution and frame rate, and build the absolute minimum version of the core interaction. A placeholder object doing the core action with programmer art.

Hours three and four: the feedback loop. Add the response to the player's action. If the player taps to shoot, the target reacts. If the player swipes to sort, the item moves. The feedback makes the mechanic legible and testable.

Hours five and six: one level. Build exactly one playable situation. Not a tutorial. Not a designed level. A space where the mechanic can be exercised for sixty seconds. Difficulty does not matter. Variety does not matter. The question is whether the action is interesting, and one level is enough to check.

Hours seven and eight: playtest and fix. Hand the phone to two people who have not seen the game. Watch silently. Fix the things that prevent them from understanding the mechanic. Do not fix anything else.

At the end of day one you have a playable interaction with feedback in one level. It looks terrible and that is correct.

Day two: make it testable

Eight hours. Focus shifts from building to presenting.

Hours one and two: feel pass. Add the minimum juice that makes the interaction satisfying. Screen shake, particle burst, sound effect, snap animation. Three to five additions, not more. The candidates are in Game Feel and Juice.

Hours three and four: visual clarity. Replace the placeholder art with simple, clear visuals. Not final art. Readable silhouettes and high-contrast colours that communicate what everything is. Simple art outperforms complex art at this stage, per Simple Art Outperforms in UA.

Hours five and six: record the test video. Play the game several times and record the best run. Edit it to thirty seconds showing the core action, a success moment, and a hint of variation. This video is the deliverable alongside the build.

Hours seven and eight: stabilise and package. Fix any crashes. Remove debug tools. Build for the target device. Run through once on a physical phone to confirm it launches and plays.

At the end of day two you have a playable build and a thirty-second video. Both answer the one question.

What to cut

A two-day sprint requires aggressive cuts. These are not shortcuts, they are the format.

• Menus. The game starts on the gameplay screen. No title, no settings, no options.
• Progression. No levels beyond the one you built. No scoring. No unlocks.
• Save system. The game resets on every launch. This is fine.
• Sound design. One or two sound effects for feedback. No music. No ambient audio.
• Monetization. Nothing. Not even placeholders.
• Analytics. Not yet. The build is for internal evaluation, not a live test.

Every item on this list is essential for a shippable game and irrelevant for a two-day prototype. Adding any of them takes hours that come directly out of the mechanic or the feel pass.

What to fake

Three things are worth faking because they make the prototype more representative without costing much time.

Faking is not cheating. It is building the cheapest possible version of something that needs to exist for the question to be answered.

Evaluating the result

At the end of day two, four people should play the build for one minute each while someone watches.

Three outcomes.

The mechanic is interesting. People lean in, try variations, ask to play again. Promote this concept to a full seven-day prototype.

The mechanic is unclear. People do not understand what to do without explanation. The concept might work with a different presentation, but the current interaction does not communicate.

The mechanic is flat. People understand it and are not engaged. This is the most useful outcome, because it saves the most time. A flat mechanic in two days is a flat mechanic in two months.

Be honest about outcome three. The sunk cost is two days, which is the smallest amount of time you can spend to learn something this important.

What we would do

Run three two-day sprints in a week, one concept per sprint, and compare the results before committing a test slot. The comparison is clearer when all three are at the same fidelity level and the same age.

Record the test video on a physical device, not the editor. The video needs to represent what a player would actually see, and editor playback often looks smoother than the real thing.

Write the one question on a sticky note and put it on the monitor on day one, hour one. Every time scope creep tempts, read the note. If the proposed addition does not serve the question, the answer is no.

The short version

• A two-day sprint answers one question with a playable build and a thirty-second video.
• Day one builds the core interaction with feedback in one level using placeholder art.
• Day two adds minimal juice, readable visuals, the test video, and a stable build.
• Cut menus, progression, saves, full sound, monetization, and analytics.
• Fake enemy behaviour, level variety, and difficulty steps cheaply.
• Evaluate with four one-minute playtests and be honest about a flat result.

Write your one question and block two days this week. If you want a studio that prototypes fast and tests honestly, get in touch.

Related reading: Seven-Day Prototype Process, A Prototype Answers One Question, and Prototypes Fail in the First Ten Seconds.