space / ↑ / A jump · 1 2 3 or LB RB feel · J or X juice · esc
to leave
Feedback loops
Positive
Success buys more success. Monopoly: the leader collects
the rent that buys the next street. Risk: the
game is decided long before it ends.
Negative
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.
LIVE DEMO
Race the loops
Balance is key — most good games mix both.
You have a great idea, now what?
AnalyseAdviseDesignRealiseValidate
Why diagrams?
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.
UML class diagrams
Unified Modeling Language — a picture of a game's structure
the shape
ClassName
- attribute1: type - attribute2: type
+ method1() + method2()
for example
Player
- health: int - position: Vector2 - score: int
+ move() + takeDamage() + collectItem()
class = a thing in the game ·
attributes = what it knows ·
methods = what it does ·
- private,
+ public
LIVE DEMO
Pong, running its diagram
controller or mouse: left paddle · first to 5
Paddle
- position: Vector2 - speed: float
+ moveUp() + moveDown()
Ball
- position: Vector2 - velocity: Vector2
+ move() + bounce()
GameManager
- player1Score: int -
player2Score: int
+ updateScore() + checkWinner()
What else might we need?
Design patterns
proven solutions to problems that keep coming back
Singleton
problem: exactly one instance of a class
e.g. GameManager, AudioManager
one manager owns the global game state
Observer
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.
LIVE DEMO
Observer
the Player's code never changes
ACTIVITY
Design your game
Find a partner
Pick a simple game
Write its core loop
Sketch a class diagram on paper
Be ready to share it
structure over notation — it doesn't have to be perfect
pick one
Breakout — paddle, ball, bricks
Space Invaders — player, enemies, bullets
a platformer — player, platforms, enemies
or your own idea
then sketch
3–5 classes
2–3 attributes each
2–3 methods each
$ sleep 720
12:00
12 min
loop · classes · attributes · methods
Good design checklist
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.
