Milestone map
Milestone map
3 milestones
Design your game and build a moving character on screen
1–2 weeks
Before writing a full game, you need a clear plan and a working foundation. Write a one-page game design document describing what the player does, what the win and lose conditions are, and what the game looks like. Then write the code to get a character or object moving on screen in response to player input. This proves you can control movement — which is the core mechanic everything else builds on.
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
Foundationstart here
Depthgo deeper
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
Add a win condition, lose condition, and score or timer
1–2 weeks
A moving character is a demo, not a game. A game has stakes: a way to win, a way to lose, and a way to track progress. Add all three to your game. The win and lose conditions should match your M1 design document — if they have changed, update the document and explain why. Implement a visible score counter or timer that updates in real time during play.
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
Foundationstart here
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')
Share the finished game and get 3 people to play it
1 week
A finished game should be played by people other than the person who made it. Share your completed game with at least 3 other people — classmates, family members, or online — and document their experience. Note one thing each person found confusing or hard, and make at least one change to the game based on that feedback. This milestone closes the loop between making something and making something that works for others.
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
Foundationstart here
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