Flappy Bird-Style Game Jam Scope Checklist

A polished weekend tap-to-fly game should be deliberately small: one input, one repeatable obstacle rule, one score, one failure state, one fast restart, and enough feedback to make success and failure understandable. The goal is not to recreate Flappy Bird. It is to finish an original one-button game with its own character, obstacle language, colors, sound, and title.

Use this scope as a constraint, not a promise that every team will finish in the same number of hours. Engine familiarity, art direction, accessibility needs, and platform testing can all change the schedule.

The minimum playable loop

Freeze the core loop before adding themes or progression. The player can start a run, press one supported control to change vertical motion, read an approaching opening, pass through it to score, collide to fail, and restart into a clean state.

Your first build needs only:

• one original player shape with a clear collision silhouette;
• gravity plus a single impulse or velocity-change rule;
• one obstacle prefab with a configurable gap;
• predictable spawning or recycling;
• one score event per obstacle;
• explicit READY, PLAYING, and FAILED states;
• a restart that resets velocity, score, obstacles, timers, and transient effects.

Do not add shops, accounts, achievements, multiplayer, daily challenges, procedural worlds, or several playable characters during the jam. Those systems multiply testing and integration work without proving the central rhythm.

A two-day build order

On the first block, create placeholder geometry and make the motion stable across the target frame rates. Confirm that one press always has a legible effect and that generated obstacle sequences are reachable. Add visible collider debugging before spending time on final art.

Next, implement scoring, failure, and restart. Test repeated runs, not only a single successful pass. Common defects include duplicate scoring, a restart press also triggering movement, recycled obstacles keeping stale state, and frame-dependent physics.

Only after the loop survives those checks should you replace placeholders with original visuals and audio. Keep the art budget narrow: one character treatment, one obstacle family, one background layer, one score style, and a few short sounds. Reserve the final block for device testing, accessibility, bug fixes, export, and a short description. A reliable build with modest art is more complete than a beautiful build that cannot restart.

Definition of done for Sunday

Call the game complete only when a new player can discover the control, score, understand a collision, and restart without coaching. Verify all of these:

1. keyboard, touch, mouse, or controller input works on every platform you claim to support;
2. essential cues do not depend only on color or audio;
3. the player cannot score twice on one obstacle;
4. every generated opening is reachable under the tested motion envelope;
5. collision matches the visible shapes closely enough to feel fair;
6. pause, focus loss, and restart cannot leave the simulation in a mixed state;
7. audio levels are controlled and nonessential motion can be reduced where practical;
8. the exported build loads from a clean device or browser session;
9. the title, art, audio, and presentation are original and do not use Flappy Bird branding or assets.

Record the exact build you tested. A last-minute change to gravity, gap size, or scroll speed invalidates earlier difficulty checks.

Cut features before cutting validation

If time runs short, remove cosmetic variation, menus, particles, lore, extra modes, and online services. Do not remove the collision review, restart test, input test, or clean-build check. Those checks protect the playable loop.

A useful stretch goal must be isolated and reversible. Examples include a second visual theme, a practice speed, or one clearly cued obstacle variation. Add only one after the baseline build is packaged. If it creates ambiguous failures or delays submission, revert it rather than repairing the architecture during the final hour.

Validate the loop before polish

Treat the prototype as a small system with a few measurable contracts. Make a test sheet that lists the starting velocity, gravity, impulse, obstacle speed, gap range, spawn interval, score trigger, and reset rules. You do not need a sophisticated analytics stack: a screen recording and a short repeatable checklist are enough to catch whether a fresh run behaves differently from the previous one.

Run the same sequence several times: begin a run, make a few early corrections, pass one opening, collide, restart immediately, then repeat after tab focus changes or a pause. Watch for motion that changes with frame rate, an obstacle spawning inside the player’s path, score state surviving a reset, or a button press being counted twice. If the skill range is too narrow, change one parameter at a time—usually gap size, scroll speed, or impulse—not all three. This preserves a clear reason for the next test result.

Ask one person who has not watched the build to try it without instructions. If they cannot tell what input starts the run, why a collision happened, or how to restart, the problem is feedback, not a missing feature. A short visual cue, a clear start state, or better collision alignment usually earns more than an extra menu.

Package an honest jam submission

Before upload, test the exact exported build rather than only the editor preview. Open it in a clean browser profile or on a second device, confirm the first input works, and check that audio starts only when the platform permits it. Keep a copy of the version you tested and write down any known limitation. Avoid calling the entry a Flappy Bird remake: a one-button timing genre is not a license to reuse another game’s name, art, audio, level patterns, or presentation.

For the submission page, describe the player’s goal, supported input, and restart behavior in plain language. Credit any permitted third-party tools or assets according to their terms, and keep the title and visual identity original. A compact, transparent submission makes judging easier and leaves you with a playable foundation you can improve after the jam.

The smallest complete weekend scope is therefore not “a Flappy Bird clone.” It is an original, testable one-input game whose full run—from ready state to score, failure, and restart—works consistently and communicates its rules.