Lock It In

Lecture W4R1: Teams, Paper, and Your First Prototype

Lucas P. Cordova, Ph.D.

Willamette University

September 17, 2026

Insert Coin

Today

LECTURE W4R1 // LOCK IT IN

  1. Card check (90 seconds): everyone armed with an idea card.
  2. Speed dating, final rounds: two more, run by the timer.
  3. Lock it in: teams form and file a team card.
  4. Boss fight: your first paper prototype (20 minutes).
  5. Show and tell: one breath per team.
  6. Team kickoff, then studio time for the Lab 2 final push.

Housekeeping: Lab 2 is due TONIGHT, 9:59 PM. Studio time at the end of class is your final push.

Where Tuesday left off

  • You hold a shared vocabulary: Mechanics you build, Dynamics that emerge, Aesthetics the player feels, and eight kinds of fun to aim at.
  • You hold a template: “You ____, then you ____, then you ____, and you do it again because ____.”
  • You hold an idea card with your aesthetics and your loop, and you have pitched it once or twice.
  • Today it pays off: a co-founder, a team card, and a playable paper prototype before you leave this room.

Card check

90 seconds, solo:

  1. Idea card in hand? Reread it. Sharpen one word.
  2. Lost it, or missed Tuesday? Write one now: one or two aesthetics plus your loop sentence.
  3. No idea survives contact anyway. A rough card beats no card.

Final Rounds

The formation

One rule for picking your next conversation:

  • Find someone you have not talked with yet. New ears hear new problems.
  • Already talked with everyone? Stop by someone again and share how your idea has refined since Tuesday: what you cut, what you kept, what their reaction changed.

The exchange stays the same: read your cards to each other, then react.

Round… fight!

Per round:

  1. Read your cards to each other (30 seconds each).
  2. React until the timer ends: what would you add? What is the fun here? On a second visit: what changed, and did it get better?
  3. Timer up? Find your next person. We run two rounds (a third if the room is hot).

One countdown per round. Restarted at each switch.

Lock It In

The team card

Find your co-founder and file the paperwork:

  1. Stand with your partner and claim a table.
  2. Fill out one team card: working title, both names, at most two aesthetics, the team’s loop sentence.
  3. Bring me the card. Card filed means team locked.

Match on taste, not ideas. No partner when the timer ends? Come to the front; I pair the remaining cards on the spot.

Paper Before Pixels, For Real

Why paper?

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

Find the fun before you fund it. Studios with hundred-million-dollar budgets still start here.

How to paper-prototype a video game

  • Verbs first. Your loop is made of verbs (run, aim, dodge, grab, grow), 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 enemies, enforce the rules, keep score.
  • Play in turns, even for a real-time game. One turn is one trip around your loop. If the turn is dull, the seconds will be too.

Boss fight: prototype your game

With your co-founder (20 minutes):

  1. Copy your team card’s loop sentence to the top of a page.
  2. List three mechanics that power it.
  3. Build the loop from paper bits and play it three times. After each run, change exactly one rule and note the effect.

Show and tell

60 seconds per team, standing at your table:

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

Then photograph your prototype and keep it. It is the seed of your Prototype gate, and the habit it stands for (test before you build) is the real deliverable.

Team Kickoff

Sprint zero: before Tuesday

Do these as a team before next class:

  • Create a shared GitHub repo for the project (one of you creates it, adds the other as a collaborator). Commit the prototype photo and your loop sentence in the README.
  • Both of you make itch.io accounts. Your game ships there, publicly, in December.
  • Working titles can change. Loops can change. The team is the locked part.

The road ahead

Gate Date What happens
Proposal Thu 10/8 Your concept, scope, and plan, on paper
Prototype Thu 10/15 Stakeholders play something rough
Alpha Thu 11/5 The core loop is real and playable
Beta Thu 11/19 Content complete; polish remains
Showcase Thu 12/3 The arcade opens; guests invited
Final release Fri 12/11 Public on itch.io, plus your postmortem

Full milestone details and your stakeholder assignments land on Canvas. Stakeholders appear at the gates only; between gates, the game is yours.

Studio: the final push

Rest of class: Lab 2 studio. It is due tonight, 9:59 PM.

  • Push what you have now, not at 9:58.
  • Fill the Your Submission section: screenshot, custom feature, layer map, reflection.
  • Stuck? The Nothing happened? table in GUIDE.md, then me. I am right here.

Game Over Screen

What you know now

  • A team, locked by a card, matched on taste.
  • A paper prototype that survived three plays and three rule changes: cheaper than code, and it already taught you something.
  • The kickoff checklist: shared repo, itch.io accounts, prototype photo committed.
  • The road: proposal, prototype, alpha, beta, showcase, release. Stakeholders at the gates.

Quest log

Lab 2: Brick Breaker is due TONIGHT, 9:59 PM: pushed to main, Your Submission complete.

Team, before Tuesday: shared repo with the prototype photo; itch.io accounts.

Reading for next week (highly recommended): GPP: State.

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

References

Sources

  1. Fullerton, Game Design Workshop (the physical prototyping chapters).
  2. Hunicke, LeBlanc, and Zubek, MDA: A Formal Approach to Game Design and Game Research (2004).
  3. Nystrom, Game Programming Patterns: State (next week’s reading).
  4. The 20 Games Challenge, our scope guardrail.