game design — fundamentals & frameworks
$ while true; do play; done
thank you for coming to my ted talk
| Tetris | rotate, drop |
| Pac-Man | eat, run away |
| Super Mario | jump |
| Minecraft | mine, craft, build |
| Among Us | do tasks, accuse |
| Clash Royale | place a card, wait for elixir |
What you do most, over and over, is the core loop.
e.g. Pac-Man
| action | move, eat dots |
| feedback | waka-waka, the score goes up |
| reward | power pill, level cleared |
| repeat | next maze, faster ghosts |
Super Mario
| seconds | run, jump, stomp, grab a coin |
| minutes | reach the flag, clear the level |
| hours | beat the world, save the princess |
$ your turn: Minecraft?
mechanics, dynamics, aesthetics — Hunicke, LeBlanc & Zubek, 2004
The rules and systems.
jump button, health points, enemy AI
How mechanics become play.
timing jumps, strategic decisions
What the player feels.
excitement, challenge, discovery
designer M → D → A builds the rules
player A → D → M starts from the feeling
the A in MDA — which ones is your game about?
game as sense-pleasure
Beat Saber
game as make-believe
Skyrim
game as drama
The Last of Us
game as obstacle course
Celeste
game as social framework
Among Us
game as uncharted territory
Zelda: BotW
game as self-discovery
Minecraft
game as pastime
Stardew Valley
space / ↑ / A jump · 1 2 3 or LB RB feel · J or X juice · esc to leave
Success buys more success. Monopoly: the leader collects the rent that buys the next street. Risk: the game is decided long before it ends.
Falling behind helps you catch up. Mario Kart: the further back you are, the better your items — Bullet Bill, and a blue shell for whoever's in first. Benefit: everyone stays in it.
Balance is key — most good games mix both.
| communication | share ideas clearly with the team |
| planning | think the structure through before coding |
| documentation | a reference for later |
| problem-solving | find issues early, when they're cheap |
| collaboration | everyone sees the same blueprint |
An architect draws blueprints before building a house.
We draw diagrams before building a game.
Unified Modeling Language — a picture of a game's structure
the shape
for example
class = a thing in the game ·
attributes = what it knows ·
methods = what it does ·
- private,
+ public
controller or mouse: left paddle · first to 5
proven solutions to problems that keep coming back
problem: exactly one instance of a class
e.g. GameManager, AudioManager
one manager owns the global game state
problem: objects need to know when something changes
e.g. the UI updates when health changes
decouples the UI from game logic
Don't implement these yet — just know they exist.
the Player's code never changes
structure over notation — it doesn't have to be perfect
pick one
then sketch
$ sleep 720
12:00
12 min
loop · classes · attributes · methods
| core loop | can you name the thing players do over and over? |
| agency | do players make meaningful choices? |
| feedback | does the game respond clearly to the player? |
| challenge | neither too easy nor too hard? |
| structure | are responsibilities clearly separated? |
| scalability | can you add features easily? |
Good design makes development easier and games more fun.