1. The blank page
Ask a professional game designer where their ideas come from and you won't hear "I sat very still and waited for lightning to strike". You'll hear about a notes app full of half-thoughts, a shelf of games they have taken apart in their head, and a pile of prototypes that went nowhere.
Two things are true at once, and both are good news:
- Ideas are cheap. You can have ten before lunch. Nobody is going to steal yours, and nobody is going to pay you for one on its own.
- Ideas are made, not found. They come from a small number of moves you can practise, the same way you practise a loop or a function.
The rest of this lesson is those moves, then the part everyone skips: shrinking your idea down to something you can actually finish before the end of term.
2. Three ways to find an idea
Nearly every idea you've ever loved came from one of these three moves. None of them is cheating.
Move 1: take a game you already love, and change one thing
Pick a game you know inside out. Now break one rule of it on purpose and ask what would happen:
- What if Mario couldn't jump, only build stairs?
- What if the ghosts were the players, and Pac-Man ran away from you?
- What if Flappy Bird had two birds and you steered both at once?
- What if a racing game scored you on how slowly you could go without stopping?
This isn't copying. Copying is making the same game. This is asking a question the original never asked, which is where new games come from. Change one thing, keep the rest, and play the answer in your head.
Move 2: combine two things that don't belong together
Take a thing and a completely unrelated twist, and force them together. Your brain fills the gap, and the gap is the game. "Football, but the ball is a bomb." "A cooking game where the kitchen is a spaceship in a meteor shower." Half of these are rubbish. The other half are the reason the machine below exists.
Silly is fine. Silly is memorable, and a game about agile turtles running from people is far easier to picture (and to draw) than "a 2D action platformer".
Move 3: be a critic
This is the move most people never make. When you play a game, don't just enjoy it. Notice things:
- What annoyed you? A menu you had to click through every single time. A level you failed for a reason you couldn't see. Fixing an annoyance is a real design idea.
- What was the best five seconds? Not the story, the five seconds. The perfect jump, the slide, the moment everything exploded. A whole small game can be built out of one great five seconds.
- What did they leave out? Every game cuts things. What would you have kept?
Being critical isn't being negative. It's taking games apart to see what makes them tick, which is exactly what a designer does all day.
Check your understanding: You take a racing game and ask "what if the track was made of ice and there were no brakes?". Which move is that?
You kept the whole game and changed exactly one rule, which is move 1. It's not copying: the original never asked what happens when you take the brakes away, and the answer is a different game.
3. Top down or bottom up
Every idea starts at one end of the same triangle. The bottom is mechanics: the rules, the systems, what the player actually does with their fingers. The top is story, theme and experience: what it's about and how it should feel.
Neither end is the correct one, but they fail in different ways. Top down ideas can sound amazing and turn out to be no fun to press buttons in. Bottom up ideas are fun immediately but can end up being about nothing.
For a small game, start at the bottom. A mechanic can be tested in an afternoon: build it, press the keys, see if it feels good. A theme can't be tested until there is a game under it. Work out what the player does first, then decide what they are.
4. The skeleton of most games
Strip most games right back and the same four bones are there. Something you're trying to reach, something that ends the run, the things you do, and the things in your way. Try the last two buttons for the games where some of those bones are simply missing.
- Win state. What counts as doing it. Even an endless game usually has one: "beat your last score". Sandboxes are the exception, see below.
- Fail state. What ends the run. Without one there is no tension, and a game with no tension is a sandbox: a real kind of game, and a different one. Decide which you're making.
- Actions. What the player's fingers actually do. Usually one or two things in a small game. Move, and maybe jump.
- Obstacles. What stands between the two. This is where the fun lives, so make it the interesting part.
You don't need a character. Plenty of games have nobody to be: in Cookie Clicker you aren't the cookie, in Whack-a-Mole you aren't the mole, and Tetris, tower defence and most puzzle games have no hero at all. You act on the world with a mouse instead of steering somebody around it. The four bones are exactly the same, which is the point of having them.
Plenty of games break this diagram on purpose, and they aren't broken games.
- Sandboxes and simulators. RollerCoaster Tycoon in sandbox mode has nothing to win and nothing to lose: you build the park and watch it run. Its scenarios do set targets, which is the interesting bit, the same game plays completely differently once somebody bolts a goal onto it. The Sims, city builders and flight simulators sit in the same place: the fun is the system, not the finish line.
RollerCoaster Tycoon (Chris Sawyer, 2000). Screenshot used by reference. - Games change. Minecraft had no win state at all for its first two and a half years. There was a way to lose, a creeper at 2am, but nothing that counted as finishing. A win condition, beat the Ender Dragon and the credits roll, only arrived on 18 November 2011, with the Java Edition 1.0.0 release announced at Minecon. It was already one of the biggest games in the world without one.
2010, Alpha v1.0.4. Hearts, but no hunger and no way to win. Xbox Mexico, via Wikimedia Commons, CC BY 3.0.
So use the four bones as a tool, not a law. If your idea fills all four, you know it will hold together. If it doesn't, ask the honest question: is this a sandbox on purpose, or is it a game I haven't finished designing?
Either way, test your own idea on the diagram before you write a line of code, and if you're building a sandbox, give version 1 something to aim at anyway while you're testing it. A target is how you find out whether your systems actually work. You can always take it out again.
Check your understanding: A student describes "a peaceful world where you wander around a forest looking at animals". They want it to have some tension. What is missing from the skeleton?
There is an action (wandering) and a rich setting, but nothing to reach and nothing to lose. Add a goal ("photograph all six rare animals") and a way to fail ("the sun sets in three minutes") and the same forest gets its tension. Leave them out and it's a sandbox, which is a perfectly good thing to build on purpose, just not the thing they asked for.
5. Nine 2D games you could actually build
Everything here can be made with the Hallam game library: sprites, keys, collisions and a score. That's genuinely enough for all nine of these. Pick a shape, then pour your own idea into it.
Dodger
Things fall or fly at you. Don't get hit.
Move left and right · things spawn at the top · touches() ends the run.
Twist it: one falling thing is good and must be caught.
Catcher
The opposite of a dodger. Catch the good stuff before it lands.
Move a basket · score(1) on a catch · three misses and you're out.
Twist it: the basket shrinks every ten points.
Chaser
Something hunts you, or you hunt it. The whole game is one clever chase.
The enemy moves a little towards your .x each frame · survive the timer.
Twist it: the chaser copies the move you made one second ago.
Collector
Grab all the things scattered around the screen before the clock runs out.
Move freely · each pickup .hide()s and scores · the timer is the enemy.
Twist it: every coin you take makes you slower.
Aim and click
Targets appear, you click them. Reaction time is the whole skill.
clicked() plus at_mouse() · targets shrink or speed up as you improve.
Twist it: one target type costs you points if you hit it.
Timing
One button, pressed at exactly the right moment. Easy to build, brutal to master.
A bar sweeps back and forth · press space in the green zone · the zone narrows.
Twist it: the bar becomes invisible for the last stretch.
Delivery run
Get something from A to B without wrecking it. A taxi, a pizza, a full cup of tea.
Steer · reach the drop-off marker · the clock or the damage counter ends it.
Twist it: the passenger complains and changes the destination.
Sorter
Things arrive, each belongs somewhere. Send it left or right before the queue backs up.
Arrow keys choose a bin · right bin scores, wrong bin costs a life · the belt speeds up.
Twist it: the rules swap over halfway through.
Climber
Get higher. Platforms, gaps, and a floor of lava that never stops rising.
Jump between boxes · the screen scrolls up · touching the bottom ends it.
Twist it: every platform disappears one second after you land on it.
Notice how small each one is. Not one of them needs a story, a menu, or more than two keys. That isn't a limitation, that's the reason they get finished.
6. Start stupidly small: the MVP
MVP stands for Minimum Viable Product: the smallest version of your idea that someone can actually play. Not a demo of one bit. Not a menu with nothing behind it. The whole loop, tiny.
Here is the shape of a real project. Look where the prototype sits:
The prototype comes before the planning, and that isn't a mistake. You can't plan a game you haven't felt yet. Build the ugly playable version first, in emoji, with no title screen, and find out whether the idea is any fun. If it's not, you've lost an afternoon instead of a term.
Could you actually start this?
Here are six things students have really said they want to make. Some are a good first game. Some are years of work for a whole studio. Flag the ones that are too big to start with, then check.
-
One of the biggest studios in the world spends about five years and hundreds of people on a Grand Theft Auto. It isn't a first game, or a hundredth. Pick one tiny piece of it and build that.
-
Three of the hardest things in games at once: split-second multiplayer, a whole open world, and driving physics. Any one of them is a project on its own, and this asks for all three.
-
A real first game. One sprite, a few keys, an angle to point it. You built almost exactly this in the taxi further up the page.
-
Two players on one keyboard, a couple of keys each: that's a normal first game, and this site has them. It's networked multiplayer, players on different computers, that turns into a nightmare, and nobody asked for that here.
-
One thing to avoid, one thing to move, a screen that fills up. All four bones are there and it fits in one window. Good scope for a first go.
-
Every piece of this is a specialist field on its own: 3D maths and raycasting, writing a renderer, and shaders are things people spend careers on. A brilliant thing to want one day, and a very long way past a first game.
The three to flag need a whole studio and years. The three to keep are one screen, a few keys, and one idea each. A first game isn't a shrunk-down GTA: it's a different, finishable thing.
Three rules for your first version
- One screen. No levels, no scrolling, no menus. If it doesn't fit in one 480 by 360 window, it's version 2.
- One verb. The player does one interesting thing. Move. Or jump. Or click. Two at most, and the second one had better be worth it.
- One reason to fail. Exactly one. A timer, or a collision, or three misses. Not all three.
The thirty second test. Hand your game to someone without saying a word. If they can't work out what to do in thirty seconds, the problem is the game, not them. This is the single most useful thing you can do, and it costs nothing.
Check your understanding: Which of these is the best MVP for "a spooky game where a ghost haunts a mansion"?
Only option a is playable. The other three are pieces of a game that nobody can press a key in yet, so nobody can tell you whether the idea is fun. Build the tiny playable loop first and add the mansion afterwards.
7. The same trick for websites
Stuck for a website idea instead? The three moves work exactly the same way, and so does the MVP rule.
- Steal a page you like. Find a site you enjoy using, and rebuild one page of it about something else entirely.
- Combine. A review site, but for school dinners. A fact file, but about your neighbours' cats.
- Be a critic. The last website that made you cross: what would you have done differently? Build that.
A website MVP is even smaller than a game's. One page. One heading. One list. One picture. That's a complete, finished thing you can show someone. A menu bar linking to four empty pages isn't.
The Idea Machine has a website mode that spins you a kind of site, a topic and a twist, then tells you the smallest version to build. The HTML lesson covers the tags you need.
8. Your one page design doc
Before you code anything, write it down. Professionals call this a design document, and for a small game it fits on one page. It's not homework for its own sake: writing the four answers below is how you find out whether your idea has all its bones.
Answer these about the game you want to make. They save as you type, and your teacher can see them.
Then go and build it. The Sandbox is the fastest place to try a mechanic, and Make Your Own Game is where you turn it into something your class can play.
Module test
Five quick questions on designing a game. Your best score shows on your My Progress page.
1. What does MVP stand for in a project like this?
2. You want your game to have tension. It has actions, obstacles and a win state, but nothing can ever end the run. What is missing?
3. You start with the rule "you stick to any wall you touch", then decide the player is a spider. Which direction is that?
4. Why does the prototype come before the planning?
5. Which of these is the best first version to build in one lesson?
Glossary
- Mechanic
- One rule of a game, and what the player does with it: jumping, stacking, reloading, sticking to walls.
- Theme
- What the game is dressed as. The same mechanic can be a spider, a magnet or chewing gum.
- Win state
- The condition that means the player has done it. Even an endless game usually has one: beat the last score. Sandboxes go without.
- Fail state
- The condition that ends the run. No fail state, no tension, which is exactly what makes a sandbox a sandbox.
- Prototype
- A rough, ugly, playable version built to answer one question: is this fun?
- MVP
- Minimum Viable Product. The smallest complete version of your idea that somebody can actually play.
- Scope
- How big a project is. "Scope creep" is what happens when features keep sneaking in and nothing ever gets finished.
- Sandbox game
- A game with no win state, and often no fail state: the system is the point. Minecraft, The Sims, most city builders.
- Playtesting
- Watching someone else play without helping them, and writing down what confused them.
- Design document
- The written plan for a game: the pitch, the rules, the win and fail states, what is in version 1.