Paper Before Pixels

Lecture W4T1: MDA, Core Loops, and the Birth of Your Game

Lucas P. Cordova, Ph.D.

lpcordova@willamette.edu

Willamette University

September 15, 2026

Insert Coin

Welcome back

LECTURE W4T1 // PAPER BEFORE PIXELS

Brick pulse (2 minutes): where is your brick breaker?
Solo campaign debrief: naming the two ideas you taught yourself.
A shared language: MDA makes “is it fun?” workable.
The core loop: the smallest circle your player runs.
Your game starts today: teams form; the project begins.
Paper prototyping: your first prototype, built with scissors.

Housekeeping: Lab 2 is due Thursday, September 17, 9:59 PM. Student hours are back this week.

Brick pulse

2 minutes with your neighbor:

Which milestone are you on?
One blocker, if you have one.
One thing from the solo campaign (a tutorial moment, a bug, a discovery) worth sharing.

The Solo Campaign, Debriefed

You gave last week’s lectures yourself

Week 3’s topics were scene composition and signals. There was no lecture, and yet you have already used both, in your own repo, in a game that runs. Today we just put the names on.

Every scene you saved (paddle.tscn, ball.tscn, brick.tscn) is a self-contained object: sprite, shape, script, behavior, all in one reusable package.
Every scene you instanced into main.tscn (or spawned from code) is composition: big games are small scenes, assembled.
And one line in your brick made 48 of them reportable without a single if statement.

Composition, in your own handwriting

From your Lab 2, in main.gd:

const BRICK := preload("res://brick.tscn")

func _ready() -> void:
    for row in range(4):
        for col in range(12):
            var brick := BRICK.instantiate()
            brick.position = Vector2(120 + col * 80, 90 + row * 40)
            brick.modulate = ROW_COLORS[row]
            brick.smashed.connect(_on_brick_smashed)
            add_child(brick)

One scene, defined once, instanced 48 times, each with its own position and tint. That is the whole doctrine of Scene organization: build objects, then compose worlds out of them. Pac-Blitz’s mazes will be born exactly this way.

The doorbell, in your own handwriting

From your Lab 2, in brick.gd:

signal smashed

func take_hit() -> void:
    smashed.emit()
    queue_free()

The brick announces; it does not call anyone. It has no idea the score exists.
main.gd subscribes with brick.smashed.connect(_on_brick_smashed). It has no idea how bricks die.

The pattern has a name

This is the Observer pattern (GPP: Observer): announcers and listeners, decoupled. Forty-eight announcers, one listener, zero entanglement, and neither side changes when the other grows.

Composition builds your game’s body; signals wire its nervous system. You now hold both. Everything after this week is organs.

A Shared Language: MDA

“Is it fun?” is a dead end

A playtester says your game is “boring.” What do you change? The speed? The art? The rules? “Boring” points at everything and nothing.
Doctors do not work from “I feel bad.” They have vocabulary that localizes the problem. Game designers need the same.
The classic answer is a 2004 workshop paper you were asked to skim: MDA (Hunicke, LeBlanc, and Zubek).

MDA splits every game into three layers: Mechanics (the rules and parts as built), Dynamics (the behavior that emerges when players play the rules), and Aesthetics (the emotional experience the player walks away with).

Mechanics: what you build

The layer you can point at in the repo. Rules, numbers, verbs, components.

The paddle moves at 520.0 pixels per second. A brick dies in one hit. The ball’s serve angle is random within a cone.
A fig flips the chase for a few seconds. First-Year Blitz fits through crawlspaces the big kids cannot.
If you can express it as a script, a scene, an @export, or a checkbox, it is a mechanic. This is the only layer you directly control.

Dynamics: what emerges

Nobody codes dynamics. They happen when mechanics meet players.

Nothing in your brick breaker says “trap the ball above the wall and let it massacre a row.” The geometry makes it possible; players discover it; it becomes the moment of the game.
No line of Pac-Blitz says “bait the Wildcat toward a fig, then flip the chase.” The fig mechanic makes that play available; a clever player invents it.
Camping, kiting, rushing, speedrunning: all dynamics. All emergent. All designed indirectly.

Aesthetics: what the player feels

Not graphics: feelings. The MDA paper names eight kinds of fun, and “fun” stops being one mushy word:

Sensation (sense-pleasure)	Fantasy (make-believe)	Narrative (drama)
Challenge (obstacle course)	Fellowship (social play)	Discovery (uncharted territory)
Expression (self-discovery)	Submission (pastime, flow)

Tetris sells challenge and submission. Minecraft sells discovery and expression. Mario Kart at a party sells fellowship. Same industry, different feelings, different designs. Pick yours on purpose.

Two directions through the machine

You experience your game designer-first: M → D → A. You write rules, watch behavior emerge, and hope a feeling comes out the far end.
Your player experiences it in reverse: A → D → M. Feelings first, behaviors second; they may never consciously see your rules at all.
You cannot type a feeling into a script. You can only reach the player’s end of the machine through the chain: adjust a mechanic, reshape a dynamic, land a different aesthetic.

Diagnose at the right layer. “Boring” (aesthetic) might be “no meaningful choices” (dynamic), which might be “every brick dies in one hit” (mechanic). The fix is always typed into M; the symptom is always felt in A.

MDA, applied to our mascot

Mechanic (built)	Dynamic (emerges)	Aesthetic (felt)
Figs flip the chase briefly	Baiting rivals into a Fig Break	Challenge, and a jolt of power
Four rivals with different pursuit rules	Reading the room: who chases, who cuts you off	Discovery, then mastery
Growth through four class years	Early crawlspace shortcuts stop fitting	Narrative: growing up costs you
Berries all must be eaten to clear a maze	Route planning under pressure	Submission: one more maze

Notice the middle column is the game. Nobody codes the middle column. We earn it, or we do not.

The Core Loop

The smallest circle

The core loop is the shortest cycle of actions your player repeats, the thing they do over and over that the whole game hangs on. If the loop is not satisfying by itself, no amount of content wrapped around it will save it.

Brick breaker: position → ricochet → smash → re-aim. Ten seconds, round and round.
Pac-Blitz: spot berries → plan a route → dodge rivals → eat → repeat, and the maze slowly empties.
Tetris: see piece → rotate → place → clear. Forty years old and still turning.

Loops nest

The moment loop runs in seconds: dodge, eat, ricochet. This is what your hands are doing.
The session loop runs in minutes: clear the maze, clear the wall, lose a life, try again. This is why “one more game” happens.
The progression loop runs across the whole game: Blitz levels up through four class years, mazes get meaner, and the player who started as a First-Year graduates. This is why anyone comes back.

Small games (yours, this semester) live or die on the moment loop. Polish one loop until it sings before you add a second. A tier-1 game is one great loop, not five rough ones.

The 30-second test

Can you say your game’s core loop in one breath? “You ____, then you ____, then you ____, and then you do it again because ____.” If the sentence will not finish, the design is not ready to build.

Keep that template in hand. In a few minutes you will fill it in for the game you want to make, it is what you will pitch when teams form, and it is the first question I will ask at your Prototype gate.

Your Game Starts Today

The semester project, by the numbers

Teams of 2. You build an original game together for the rest of the semester.
It ships publicly on itch.io, and it stars at our arcade showcase in class on Thursday, December 3, guests invited. Real game, real players, real release.
Scope guardrail: aim at 20 Games Challenge tiers 1 and 2. 2D is strongly recommended. Small and polished beats big and broken, every time.
Milestone dates and deliverables land on Canvas; the road runs through three review gates: Prototype, Alpha, Beta.

Stakeholders: your other job

Every project gets two peer stakeholders: classmates from other teams who play your builds and give structured feedback at the three gates. Every student serves as a stakeholder for exactly one project that is not their own.

Stakeholders show up at the gates only (Prototype, Alpha, Beta). No mid-sprint check-ins; teams keep their momentum between gates.
You are graded on the feedback you give: specific, kind, actionable, MDA-literate. “It’s boring” is now beneath you; “the moment loop has no decision in it” is the standard.
Stakeholder assignments happen after teams settle. Today is about the teams themselves.

Idea forge

Solo, in silence (3 minutes). The idea you brought becomes an index card:

Pick one or two aesthetics (of the eight) your game should deliver.
Fill in the loop: “You ____, then you ____, then you ____, and you do it again because ____.”
Blank card? Steal and twist: take a classic you love and change one rule until it is yours.

Forming teams: speed dating

Card in hand, find your co-founder:

Pair up and read your cards to each other (30 seconds each), then react: what would you add?
Timer up? Rotate and pitch again. Three rounds.
After round three, claim a table together. Unpaired? You get drafted by me (a promise, not a threat).

One countdown per round; I restart it at each rotate. You are matching on compatible taste, not identical ideas. The idea will change; the taste will not.

Paper Before Pixels

Why paper?

In code, a rule change costs an evening. On paper, it costs an eraser. Early on, you want to make dozens of rule changes, so go where changes are cheap.
Paper answers the questions that matter first: is the loop engaging? are the choices real? is it brutally unfair? You can find and fix a broken loop before writing a line of GDScript.
What paper cannot judge: game feel, timing, juice, physics. (You have a physics engine for that. It charges by the evening.)

Find the fun before you fund it. Every hour on paper is ten in the editor. The industry name for this is paper prototyping, and studios with hundred-million-dollar budgets still start here.

How to paper-prototype a video game

Verbs first. List what the player does: run, aim, dodge, grab, grow. Your loop is made of verbs, so prototype the verbs.
Make it playable with bits. Grid on paper, coins for characters, dice for uncertainty, sticky notes for state. Ugly is correct.
One human plays “the computer.” They move the rivals, enforce the rules, and keep score. (Congratulations: whoever plays the computer is speed-running the design doc.)
Play in turns, even for a real-time game. A turn is one trip around your moment loop. If the turn is dull, the seconds will be too.

Boss fight: prototype your game

With your new teammate (20 minutes):

Merge your index cards: at most two aesthetics, and the team’s core loop in one sentence.
List three mechanics that power the loop.
Build the loop out of paper bits and play it three times. After each run, change exactly one rule and note what the change did.

Show and tell

60 seconds per team, standing at your table:

Your core loop, in one breath.
The one rule change that taught you the most, and what it did to the play.

Then photograph your paper prototype and keep it. This page is the seed of your semester project and the first artifact your stakeholders will see at the Prototype gate. Teams and concepts can still change; the habit of testing before building cannot.

Game Over Screen

What you know now

Week 3, absorbed: scenes compose into games; signals (Observer) wire announcers to listeners.
MDA: you build Mechanics, players feel Aesthetics, and the game lives in the Dynamics between. Diagnose feedback at the right layer.
The core loop is the smallest repeated circle of verbs; a small game is one polished loop.
Paper prototypes buy dozens of cheap rule changes before code makes changes expensive.
And you have a team and the first draft of a game. The semester project is alive.

Quest log

Lab 2: Brick Breaker is due Thursday, September 17, 9:59 PM: game pushed to main, Your Submission section filled: screenshot, custom feature, layer map, reflection.

Reading for Thursday (highly recommended): GPP: State. And if you skimmed the MDA paper before class, tonight is a fine night to read it properly; it is eight pages.

Thursday: state machines, the brains behind every player controller and, eventually, our four rivals. Lab 3 (a platformer with a state machine) goes out the same day.

References

Sources

Hunicke, LeBlanc, and Zubek, MDA: A Formal Approach to Game Design and Game Research (2004).
Nystrom, Game Programming Patterns: Observer.
Fullerton, Game Design Workshop (the physical prototyping chapters are the canonical treatment of paper prototypes).
The 20 Games Challenge, our scope guardrail.
Godot Engine documentation: Scene organization.