digital factory / year 9 · unit 04 · 3 weeks / 9 lessons
arrows or a / d to move · space to jump
collect four coins, then reach the door
one
screen.
thirty seconds.
you get a platformer that already works. it is deliberately unfinished — no sound, no art, one plain level, and a jump that doesn't feel like much. over three weeks you make it into something worth playing, and you keep a record of every decision you make along the way.
what you're starting with
already working
- a player that runs, falls and jumps
- solid platforms with proper collision
- a hazard that resets the level
- coins that can be collected and counted
- a door that only opens once you have them all
- a timer
missing on purpose
- any sound at all
- art that isn't a rectangle
- a second level, or any sense of progress
- a title screen or a win screen
- a jump that feels satisfying to press
flip the game feel switch
the level does not change when you flip it. same platforms, same gaps, same jump height, same gravity. what changes is everything around the jump — the game forgives you for a few frames after you walk off an edge, it remembers a jump you pressed slightly too early, the player squashes on landing, dust kicks up. play both versions and try the jump from the top-left platform across to the right. the version that feels fairer is not the easier one. it is the same one, with better feedback.
section 01
three rules you cannot break
these limits are not a punishment — they are the reason this unit is finishable. a level that fits on one screen can be redesigned in ten minutes. a thirty-second level can be playtested eight times in a lesson. every year someone tries to build a scrolling adventure in three weeks and hands in a title screen. you are building a few small rooms that are genuinely good instead.
the shape of the unit
nine lessons. the highlighted ones have a section of their own — click through.
play and pull apartthree short platformers, dissected. sketch your level against the three rules.
act on it and finishfix what the playtest found. title screen, win screen, final log entry.
arcadeeveryone plays everyone's. submit game and log.
section 02 · lesson 2
build the skeleton yourself
everyone builds this together, exactly the same way. no creative choices yet. by the end of the lesson your game runs.
make the project
open editor.gdevelop.io in Chrome and sign in with your school account. create a new project, choose the empty template, and name it
surname-onescreen. set the game resolution to 800 × 600 and leave the camera alone — not moving it is what makes rule 01 work.add six objects
add sprites called Player, Spike, Coin and Door, a tiled sprite called Platform, and a text object called HUD. plain coloured rectangles are fine — you replace the art in tier 2.
add the two behaviours
give Player the platformer character behaviour and give Platform the platform behaviour. that is the entire physics engine — gravity, running, jumping and collision all come from those two behaviours, and every number inside them is something you will tune in lesson 3.
build one room
lay out a floor and four or five platforms that all fit on the one screen. put the Door on the highest platform, four Coins in places that need a jump to reach, and a Spike strip on the floor so standing still is not an option. this is a first draft — you will redesign it properly in lesson 4.
set up the counters
open the events sheet. two scene variables track everything the game needs to know.
condition at the beginning of the scene action change scene variable Coins → set to 0 action reset the timer "run"collect the coins
one event. deleting the coin is what stops it being collected twice.
condition Player is in collision with Coin action delete Coin action add 1 to scene variable Coinsmake the spikes hurt
restarting the whole scene is the simplest possible death. you can make it kinder in tier 5 with a checkpoint.
condition Player is in collision with Spike action change the scene → restart current sceneopen the door
two conditions on one event — the door does nothing until every coin is gone.
condition Player is in collision with Door condition scene variable Coins ≥ 4 action change the scene → go to scene "Win"show the player what's going on
one last event with no condition, so it runs every frame. press preview — you have a working platformer.
condition (no condition — runs every frame) action HUD → set text to "coins " + ToString(Variable(Coins)) + " / 4 " + ToString(round(TimerElapsedTime("run"))) + "s"
save it properly, every lesson
at the end of every lesson, download your project and save it to your OneDrive as
surname-onescreen-L3.zip, -L4, and so on. keeping a numbered
copy from each lesson means a broken project costs you one lesson, not the whole unit.
this is the single most common way people lose their work.
section 03 · lesson 3
the jump is the game
in a platformer the player presses jump hundreds of times. if the jump feels wrong, nothing you build on top of it will save the game. spend a whole lesson on five numbers.
gravity
low gravity feels floaty and forgiving. high gravity feels snappy and punishing. this single number sets the personality of your game more than any other.
jump speed
how hard the player launches. change this and every gap in your level changes with it — which is why you tune the jump before you design the level, not after.
max speed
how fast running gets. also decides how far a jump carries horizontally, so it quietly controls how wide your gaps can be.
acceleration
how quickly the player reaches full speed. instant acceleration feels arcade-like. slow acceleration feels weighty, and makes precise landings harder.
deceleration
how quickly they stop. this is the number responsible for sliding off the edge of a platform and dying, so test it on your narrowest ledge.
how to actually do it
change one number, then play for thirty seconds before changing anything else. write down what it felt like. changing four numbers at once tells you nothing about which one made the difference.
section 04 · lesson 4
teach, test, twist
good platformer levels are lessons. they introduce an idea somewhere safe, check that you learned it, then combine it with something else. use this pattern for every mechanic you add.
teach
the first time the player meets a moving platform, put it somewhere they cannot die. let them stand on it, ride it, and work out what it does with nothing at stake.
test
now put spikes underneath. same mechanic, real consequences. this is where the player finds out whether they actually understood it.
twist
combine it with something they already know — a moving platform that carries them toward a gap they have to time a jump across. this is the memorable bit.
a few rules that always help
- the player should be able to see where they are going before they jump
- never kill someone with something they had no way to know about
- put the hardest jump in the middle, not at the very end
- a coin in a dangerous place is a decision — a coin on the path is furniture
- if you have to explain the route, redesign the route
redraw it on paper first
sketch the room as a rectangle and mark the route the player takes with a line. if the line crosses itself repeatedly or wanders, the level is confusing. if it goes straight from start to door, the level is boring. you are looking for a shape that doubles back once or twice and passes near a risk. paper is a hundred times faster than the editor for this.
section 05 · lessons 5–6, main task
the task menu
choose your own combination. you need at least 8 points, and at least one item from tier 3 or higher.
eight points of careful, tested, well-documented work beats twenty points of features that half-work. every item you claim needs a dev log entry showing what you changed and why — an item with no entry does not count.
tier 1 — tune it
changing numbers is real design work. every change needs a reason in your log, and a note on how it felt.
- gravity, until falling feels right
- jump speed, tested against your narrowest gap
- max running speed
- acceleration and deceleration
- resize a platform or gap so a jump is tight rather than trivial
tier 2 — reskin it
use the asset tools below. check the licence on anything you did not make yourself and record it in your log.
- replace all sprites with real art
- a tileset for the platforms, so the level reads as a place
- a background with a deliberately chosen palette
- a title screen with the game's name
- a win screen showing coins and time
- an idle, run and jump animation for the player
tier 3 — make it feel good
this is the tier that separates a school project from a game. do this before you add features.
- coyote time — the player can still jump for a few frames after leaving an edge
- jump buffering — a jump pressed just before landing still counts
- variable jump height — tapping jumps lower than holding
- squash and stretch on the player when jumping and landing
- dust particles on landing, sparkle on coin pickup
- sound on jump, land, coin and death
- screen shake, used sparingly, on death only
tier 4 — add a mechanic
remember rule 02 — anything beyond run and jump has to be earned, limited or temporary. and it must be taught, tested and twisted somewhere in your level.
- a moving platform
- a one-way platform you can jump up through
- a crumbling platform that falls a moment after you stand on it
- a double jump — but only after collecting something
- a wall jump
- a key that unlocks the door, hidden away from the main route
- an enemy that patrols a fixed path
tier 5 — add a system
a system is several events working together, and it needs testing rather than just building.
- three connected levels with a proper progression of difficulty
- a checkpoint, so death costs seconds rather than the whole run
- a best time per level that survives a restart
- a level select screen that unlocks as you go
- a death counter, and a level tuned using what it tells you
tier 6 — rebuild it
for anyone who wants the hard version. talk to me before you start one of these.
- replace an event with a JavaScript code block that does the same job
- turn a repeated mechanic into a custom behaviour you can drop onto any object
- build a level from data — an array or tilemap — instead of placing every object by hand
- write your own extension and use it in the game
where to get things
all free. no account needed unless noted.
GDevelop
the game engine. runs in the browser. sign in with your school account so your project saves.
editor.gdevelop.io →Kenney
free platformer tilesets, character sprites and sound effects. public domain, so you can use anything here without asking.
kenney.nl/assets →Piskel
draw your own pixel art and animations in the browser. good for run cycles. exports straight into GDevelop.
piskelapp.com →jsfxr
retro sound effects. press "jump" or "pickup" until one sounds right, then download it.
sfxr.me →Freesound
recorded sounds and music. licences vary here — record which licence each file uses in your dev log.
freesound.org →Coolors
build a colour palette before you start on art, and stick to it. three or four colours is plenty.
coolors.co →section 06 · lesson 7
watch someone else play it
you will swap games and play a partner's for five minutes. you are not allowed to explain your level while they play it. if it needs explaining, that is the finding.
write down what happened
- where did you think you were supposed to go first?
- which jump did you fail the most, and how many times?
- did you find all the coins? which one did you miss?
- was there a death that felt unfair, and what made it feel that way?
- how long did your first successful run take?
not what you thought of it
"it's good" and "it's too hard" are useless to the person fixing the game. "i died six times on the gap to the top-right platform because i couldn't see the spikes underneath until i was already falling" is something they can act on. describe what happened to you, not your rating of it.
then write your response — assessed
list the three most useful things your tester said. for each one, say what you changed in response — or explain why you deliberately left it alone. a jump that everyone fails eleven times might be your best jump, or your worst; you have to decide which and argue for it. this response is worth more marks than any single feature you build.
section 07
the dev log and the rubric
one log entry per lesson, in a single document. this is how i can see the thinking behind the game, and it is where most of your marks live.
write it in the last five minutes of the lesson while you still remember. an entry saying "raised jump speed to clear the top gap, but then the player overshot every platform, so i put jump speed back and moved the platform 30px closer instead" is worth more than a paragraph saying the lesson went well.
how it's marked
| criterion | developing | consolidating | extending |
|---|---|---|---|
| level design | the level is completable and follows the three rules. mostly a straight route from start to door. | the route doubles back and passes near risk. gaps have been sized against the tuned jump. mechanics are taught before they are tested. | the level teaches, tests and twists its ideas deliberately. a player would learn how to play it without being told anything. |
| implementation | reaches 8 points, with some items partly working or untested. | reaches 8+ points, all working, including at least one tier 3 item. events are tidy and named sensibly. | 15+ points, or genuine tier 5–6 work. the project is organised well enough that someone else could open it and follow it. |
| response to playtesting | records the feedback received. | identifies the three most useful findings and changes the game in response to them. | distinguishes between what a tester said and what actually went wrong, and justifies anything deliberately left unchanged. |
| dev log | entries for most lessons, mainly describing what was done. | an entry for every lesson, with reasons for the changes and problems recorded honestly. | the log shows a line of thinking across the unit — ideas tested, abandoned, and revised, with evidence. |
note that three of the four criteria are about thinking and process rather than features. a small, carefully tuned level that has been tested and honestly documented will mark higher than an ambitious one that was built once and never revisited.