Build Your First Game in Python

Proof required

Share: (1) your one-page game design document (what the player does, win condition, lose condition, what it looks like), and (2) a short video or GIF showing your character or object moving in response to keyboard or mouse input. The code must be your own — include a link to your repo or Replit project.

What gets checked

• Game design document names a specific win condition and lose condition — 'the player shoots things' is not a win condition; 'the player survives 60 seconds without being hit' is
• Moving object responds to real player input (keyboard or mouse) — a character that only moves automatically with no player control does not meet the standard
• Code is in a linked public repo or Replit project — sharing only a video without code makes it impossible to verify the work is original

Common mistakes

• Skipping the design document and jumping straight to code — a game built without a plan tends to grow in random directions and never feel finished
• Copying a tutorial exactly without understanding each line — when M2 requires you to add your own mechanic, you will not know where to make the change
• Using a game engine that writes most of the code automatically — Scratch is not Python; the outcome requires Python code that you wrote

Resources

What a verifier looks for

• K12 outcome — accepted verifiers: peers, teachers, or parents
• Ask for the repo or Replit link and open it — confirm the code is Python and runs without obvious copy-paste markers (e.g. a single file with 500+ lines of commented-out tutorial code)
• Ask the submitter to explain one specific line of code in the movement section — a student who wrote the code themselves can explain what any line does; a student who copied it cannot

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

Proof required

Share a video of a complete playthrough showing: (1) the score or timer updating on screen during play, (2) the lose condition triggering (with a visible game-over state), and (3) the win condition triggering (or a score target being reached). Include the updated repo or Replit link.

What gets checked

• Video shows both win and lose conditions triggered in the same or separate playthroughs — describing them in a comment is not the same as implementing them
• Score or timer updates visibly on screen during play — a variable that increments in code but is never displayed does not meet the standard
• The game is playable from start to finish with no crashes during the demonstrated playthrough

Common mistakes

• Adding a score variable but never displaying it — display logic is separate from score logic; both are required
• Win condition that is trivially easy (e.g. score 1 point to win) — the game should have enough challenge that a player could lose on a real attempt
• Game crashes when the lose condition fires — test the lose condition at least 5 times before recording the proof video

Resources

What a verifier looks for

• K12 outcome — accepted verifiers: peers, teachers, or parents
• Watch the full proof video and confirm both win and lose conditions are visible in the video — descriptions of what 'would happen' are not sufficient
• Ask the submitter what happens in the code when the player loses — they should be able to describe the code path (e.g. 'I set a game_over variable to True and in the draw loop I show the game over screen')

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

Proof required

Share: (1) the public link to your finished game (Replit, itch.io, or GitHub repo with run instructions), (2) brief notes from 3 people who played it (what they found fun, what was confusing, one piece of feedback each), and (3) one change you made to the game after hearing that feedback.

What gets checked

• Game is accessible via a public link that anyone can open without installing Python — Replit, itch.io, or a browser-playable export; a repo with no run instructions is not accessible to non-programmers
• Feedback from 3 people is documented and specific — 'they liked it' is not feedback; 'my brother couldn't figure out how to restart after losing' is
• One concrete change was made based on the feedback and is described — showing the before and after (or explaining what was added or changed) demonstrates that the feedback was acted on

Common mistakes

• Sharing the repo with no run instructions — most players cannot run a Python file; package the game in a way that works for non-programmers before counting them as playtests
• Getting feedback only from people who already know the game — family members who watched you build it already know how to play; at least one tester should be a genuine first-time player
• Documenting feedback but making no changes — one change shows the feedback was real and was taken seriously

Resources

What a verifier looks for

• K12 outcome — accepted verifiers: peers, teachers, or parents
• Open the public game link and attempt to play it yourself — if it requires Python installation or command-line knowledge, the game is not accessible to non-programmer players
• Ask the submitter to read out one piece of feedback they received — a student who genuinely ran playtests can recall specific moments without looking at notes

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