Stress test the complete system. Version 0.3 must loop cleanly for 5 minutes.

You might think playtesting is just "playing your game." It's not. Playtesting is a skill — and real game studios do it with strict protocols. Watch how the pros get useful feedback:

Playtesting: How to Get Good Feedback on Your Game — Extra Credits

Extra Credits explains why most feedback from playtesters is wrong (they tell you solutions, not problems), how to ask the right questions, and why watching silently is more valuable than asking questions during play.

Discussion after watching: Today you'll playtest each other's games. The most important rule: don't explain your game while someone is playing it. If you have to explain something, that means the game didn't communicate it — and that's valuable feedback.

Today is not a building day. Today is a playing day. You play your game silently for 5 minutes. No code changes during play. You observe what works and what doesn't. Write down what you notice. Then fix only critical bugs. Then play again.

This is a structured playtesting session. Follow each phase exactly.

Phase 1: Silent Play (5 min per game)

  1. Swap computers. Each kid plays the OTHER kid's game.
  2. No talking. The game creator must watch silently. No hints, no explanations, no "you're supposed to press B to bank."
  3. The watcher takes notes: where did the player get confused? Where did they smile? Where did they look bored?
  4. Set a timer. Play for exactly 5 minutes, no more.

Phase 2: Written Observations (5 min)

Each person writes answers to these questions — no discussion yet:

For the player (the person who played someone else's game):

  • What was the first thing you tried to do?
  • What moment was the most fun?
  • What moment was the most confusing?
  • Did you understand the core loop without explanation?
  • Did the risk/banking feel meaningful?

For the creator (the person who watched):

  • What did the player try that you didn't expect?
  • Where did they get stuck or confused?
  • Did they discover the banking/debt mechanic on their own?
  • What exploit or shortcut did they find?

Phase 3: Discussion (5 min per game)

  1. The player shares their written observations first.
  2. The creator listens without defending. Write down every point.
  3. Then the creator shares what they noticed from watching.
  4. Together, identify the one most critical fix to make.

Remember from the video: Players tell you solutions ("add a tutorial"). What you need is the underlying problem ("I didn't know I could bank XP"). Always dig for the problem, not the solution. You're the designer — you decide how to fix it.
Ami — Combat Risk Engine

Loop Test: Explore → Encounter → Win/Lose → Risk increases → Bank or Respawn → Repeat.

Requirements:

  • Risk visibly increases over time in the danger zone
  • Loss resets unbanked XP and respawns to Camp
  • Banking feels safe — risk resets, XP is secured
  • Tier system doesn't exist yet (that's Week 4)
Ida — Economic Growth Engine

Loop Test: Accept Job → Buy Materials → Build → Earn Karma → Risk debt → Upgrade → Repeat.

Requirements:

  • Debt pressure is visible and increasing
  • Bankruptcy resets correctly when debt exceeds -50
  • Decision between safe/small vs risky/large jobs is clear
  • Watch the Extra Credits playtesting video and discuss
  • Complete Silent Playtest Phase 1: Play the other kid's game for 5 min
  • Complete Silent Playtest Phase 2: Write observations (no talking)
  • Complete Silent Playtest Phase 3: Share and discuss feedback
  • Identify the one most critical fix for your game
  • Fix only critical bugs found during the playtest (no new features)
  • Play your own game for 5 minutes after fixes — does the loop work?
    •
    Checkpoint

    Does the loop function without explanation? Can someone who hasn't seen it before understand what to do?

    No new features. Only bug fixes from today's play session. Resist the urge to add "just one more thing."

    Fixing bugs during play instead of writing them down — play first, fix later. Observation and coding are separate modes.

    Adding new features instead of fixing existing ones — today is about stability, not novelty. New features break what already works.

    Not playing the full 5 minutes — the whole point is sustained play. Short tests miss the problems that emerge over time.

    Your job during the Silent Playtest is to enforce silence. This is the hardest part. When Ami sees Ida confused by their game, Ami will want to say "press B to bank!" Stop them. The urge to explain is the signal that the game isn't communicating clearly — and that's the most valuable feedback.

    This is a discipline exercise. Watch silently while they play. Do not help. Do not suggest. Write your own notes. After they play, compare notes. The question is not "Is it perfect?" but "Does the loop work?"

    During the Discussion phase: Model good listening. When the player says something critical ("the combat was boring"), don't let the creator get defensive. Say: "Write that down. That's gold. Now — why was it boring? Let's figure out the real problem."

    After the playtest: Allow 15-20 minutes for bug fixes ONLY. Not new features. If they want to add a new animation or sound effect, say: "Write it on the Week 4 wishlist. Today is about making what exists work reliably."

    Celebrate v0.3. This is a real milestone. They have a working game with a 3D world, event triggering, win/lose resolution, risk management, and persistence. Three weeks ago they had nothing. Name what they've accomplished.

    Next week: We add progression — tiers, unlocks, and your signature feature. The core loop works. Now we make it grow. Celebrate: v0.3 shipped!

    Both games have working 3D world, movement, event triggering, win/lose resolution, risk escalation, banking/debt tension, and persistence. The core loop is playable.