Complete a Game Jam

Proof required

Submit: (1) a screenshot of your jam registration confirmation (showing the jam name and your username), and (2) your 3-sentence concept note covering: what the player does, the win/fail condition, and the visual style. Include the jam name, platform, and start date.

What gets checked

• Registration is confirmed with a screenshot showing both the jam name and your username — a screenshot of the jam homepage without your registration shown does not pass; most jam platforms (itch.io, Ludum Dare, Global Game Jam) show a 'You're registered' confirmation or similar; that is the proof
• Concept note is specific and scope-limited — 'a platformer with lots of levels and enemies and a boss fight and an inventory system' is not achievable in 48 hours by most solo developers; a passing concept note describes something completable: 'a one-screen puzzle where the player moves blocks to create a path from start to exit; win when the path is clear; minimal pixel art style'
• Game engine is identified in the concept note or accompanying note — the engine choice is part of the preparation, not something decided during the jam; name the engine (Godot, Unity, Pygame, Pico-8, GameMaker, or similar) and confirm it is installed and a test project opens

Common mistakes

• Choosing a concept based on what would be impressive rather than what is buildable in 48 hours — game jams consistently produce better results from smaller, polished ideas than from ambitious ideas that are 80% complete at the deadline; the concept constraint ('3 sentences only') is not a creative limitation but a scope discipline; the best jam games are often one mechanic, done well, with a clear win condition
• Not having the engine installed and running before jam day 1 — engine installation, tutorials, and basic project setup take 2–6 hours even for experienced developers; doing this during the jam wastes the time that should be used building; the preparation milestone exists specifically to prevent this; have a working empty project open before the jam clock starts
• Registering for a jam that is already in progress — some developers discover jams mid-run and try to catch up; the milestone requires pre-jam registration because the concept-first discipline is part of the proof; a jam submission without a pre-jam concept note does not demonstrate the preparation mindset that prevents scope creep

Resources

What a verifier looks for

• Open the registration screenshot and verify the jam name and username are both visible — ask which jam this is if unclear from the screenshot, and check that the jam dates are consistent with the submission in milestone 3
• Read the concept note for scope realism — ask 'how many mechanics does this game have?' and 'have you built something similar in this engine before?'; a concept with 4+ mechanics and no prior engine experience is likely to produce an incomplete submission
• Confirm the engine is installed — ask 'did you open a test project in this engine before writing the concept note?'; a developer who has not confirmed their tools work before the jam starts is at risk of losing hours to setup problems on jam day 1

You'll sign in first, then come straight back here.

Proof required

Submit: a screenshot or short screen recording (under 60 seconds) showing the core gameplay loop in action — the player performing the main action and the game responding, with the win or fail condition triggering at least once. The game does not need to be polished; it needs to work. Include a timestamp note on when during the jam this was captured.

What gets checked

• The core loop is demonstrably functional — a screenshot of a static screen with 'game in progress' text is not a working core loop; the proof must show the player action and the game response: a block being moved and the path completing (puzzle), a character jumping over an obstacle (platformer), a projectile hitting a target and a score incrementing (shooter)
• The proof was captured during the jam, not after — the timestamp note is not optional; a core loop screenshot taken after the jam submission and backdated is not the milestone; the timestamp demonstrates that the core was complete with time remaining, which is the actual skill being demonstrated
• The win or fail condition triggers at least once — a game where the core mechanic works but the win condition has not been tested is not a complete loop; the win condition is what makes it a game rather than a toy; the proof should show the win or fail state appearing at least once

Common mistakes

• Adding visual polish before the core loop is complete — the most common jam failure is spending the first 12 hours making the art look good before the mechanics work; a game with beautiful placeholder art and a broken core loop does not pass the milestone; commit to placeholder graphics (squares and circles) until the loop works, then upgrade visuals with remaining time
• Not testing the win condition during development — many developers build the game system and the player character but only add the win condition in the final 2 hours; if the win condition logic has a bug, it is discovered too late to fix; test the win condition every hour during the jam once the core mechanic exists
• Scope-creep during the core loop phase — when the core loop starts working, the temptation is to add a second mechanic, a shop system, or more levels before solidifying the first loop; scope creep in the core loop phase delays the milestone and risks not having a submittable game; add nothing new until the core loop proof is captured and saved

Resources

What a verifier looks for

• Watch or view the core loop proof — confirm it shows the player action, game response, and win/fail trigger; if the proof is a screenshot of a static game state, ask for a brief description of what is happening in the screenshot
• Check the timestamp — ask 'what time during the jam was this screenshot taken?' and confirm it matches the timestamp note; a core loop screenshot taken in the final hours of a 48-hour jam with a note saying 'captured at hour 12' is a timing inconsistency worth questioning
• Ask about scope during the core loop phase — 'did you add anything to the concept after the core loop was working?' and 'how many mechanics does the submitted game have compared to the concept note?'; scope creep that delayed the core loop is a common jam learning to surface

You'll sign in first, then come straight back here.

Proof required

Submit: (1) the itch.io (or jam platform) submission URL showing your game as a live, submittable entry in the jam, and (2) a 150+ word post-jam reflection covering what you built, what you would cut or change with hindsight, and the single most important lesson from the jam.

What gets checked

• The submission URL opens to a public game page on the jam platform — the page must show the game as part of the jam's submission list (most jam platforms display this on the game's page); a game page that was published after the jam deadline or that is not linked to the jam does not count as an on-time submission
• The game is playable or downloadable — an itch.io page with no playable version and no download is not a submitted game; even a browser-playable version with significant bugs passes if the core loop from milestone 2 is accessible; note any known bugs in the game description so players know what to expect
• Post-jam reflection addresses all three prompts with specificity — 'I built a game and learned a lot' does not pass; 'I built a one-screen block puzzle in Godot; I would cut the second mechanic (conveyor belts) because it was added in the last 4 hours and does not work reliably; the most important lesson was that placeholder art that is consistent (all simple squares) looks better than mixed art where some assets are detailed and some are placeholder' is the kind of reflection that demonstrates genuine learning

Common mistakes

• Submitting an empty or broken build because 'at least something was submitted' — a game page with no playable version and a description saying 'ran out of time' is technically a submission but does not demonstrate the outcome; the milestone requires a working, playable game entry; if the game is not complete at the deadline, submit what works and describe the current state honestly in the game description
• Not writing the post-jam reflection — the reflection is not optional; game jam developers who do not reflect after jams repeat the same mistakes (scope creep, art before mechanics, not testing win conditions) indefinitely; write the reflection within 24 hours of the jam deadline while the experience is fresh
• Using the jam submission as the endpoint rather than the start — a game jam submission is a proof of concept and a learning exercise, not a finished product; the most common jam mistake is treating the submission as 'done' and moving on; the reflection should include a note on whether this concept is worth developing further and what that would require

Resources

What a verifier looks for

• Open the submission URL and confirm the game is accessible — try the browser play or download; if the game page exists but no play/download option is available, ask the submitter to explain the current state of the build
• Check the submission timestamp against the jam deadline — most jam platforms show the submission timestamp on the game page or in the jam results; confirm the game was submitted before the deadline; late submissions are typically disqualified from jam rankings
• Read the post-jam reflection for the three required elements — what was built (specific genre and mechanic), what would be cut or changed (specific feature with a reason), and the most important lesson (specific, not generic); a reflection that only describes what was built without the hindsight and lesson sections is incomplete

You'll sign in first, then come straight back here.