Remove confusion. Complexity hides tension.

The best game designers know a secret: the most powerful thing you can do isn't ADDING features — it's REMOVING confusion. Watch how the creators of Celeste made their game feel incredible by keeping things simple and focused:

Why Does Celeste Feel So Good to Play? — GMTK (11 min)

Look at this video through a different lens today: notice how Celeste uses very FEW mechanics but makes each one feel perfect. Madeline can jump, dash, and climb — that's it. The game's power comes from clarity and polish, not from having more stuff. That's what code cleanup gives you.

Discussion after watching: Celeste has only 3 core abilities. Your game probably has more features than that already. Ask yourself: if you had to remove ONE feature from your game, which one would you cut? Does your game actually need everything you've built? Today is about having the courage to subtract.

Today is a subtraction day. You are not adding anything — you are removing things that create confusion. If the player doesn't know what to do next, the game has a clarity problem, not a feature problem.

Ask yourself these three questions:

  • What action is unclear?
  • When do I not know what to do?
  • What feels cluttered?

Open your game code. Your mission: find and evaluate every console.log statement.

Step 1: Search

Use your code editor's search function (Ctrl+F or Cmd+F) and search for console.log. Write down how many you find: _______

Step 2: Classify each one

For EVERY console.log, ask these two questions:

  • Is it helpful for players? (Almost always: No. Players don't open the console.)
  • Is it helpful for debugging? (Maybe. Mark it with a comment // DEBUG but plan to remove before ship.)

Step 3: Remove

Delete every console.log that isn't actively helping you debug a current problem. Test after each removal — make sure nothing breaks.

Your cleanup scorecard:

  • Total console.log statements found: _______
  • Removed (not needed): _______
  • Kept (active debugging): _______
  • Marked // DEBUG - remove before ship: _______

Clean code = professional code. Every console.log you remove is one less line that could confuse you next week. Professional developers spend MORE time removing code than adding it. Today you're learning a pro skill.
Ami — Combat Clarity
  • Remove unnecessary console logs.
  • Ensure only one active encounter at a time.
  • Confirm banking is clearly restricted to Camp.
  • Remove experimental code that is no longer used.
Ida — Economy Clarity
  • Ensure only one active build at a time (V1 constraint).
  • Clarify debt warning visually.
  • Remove unused variables.
  • Clean up job generation logic.
  • Play and identify 3 confusing moments
  • Remove all unnecessary console.log statements
  • Remove unused variables and functions
  • Ensure one active event at a time
  • Simplify any overly complex logic
  • Verify: codebase is smaller or cleaner than yesterday
    •
    Checkpoint

    The codebase is smaller or cleaner than yesterday. Confusion is reduced.

    No feature expansion disguised as cleanup. "While I'm in here, I'll just add..." — NO.

    Adding features during cleanup — the temptation is real. Today is subtraction only.

    Removing code that's actually needed — test after every removal. If something breaks, undo immediately.

    Not testing after removal — every deletion should be followed by a play test. Verify nothing is broken.

    "Improving" code instead of simplifying it — refactoring is not the goal. Removal is the goal.

    This is the hardest lesson for young developers. Removing code feels like going backward. Ask: "Why is removing code powerful?" Answer: every line of code is a potential bug. Less code = fewer bugs = clearer game.

    The console.log hunt makes cleanup concrete. Instead of vaguely telling kids to "clean up," they have a specific, countable target. The scorecard gives them a sense of accomplishment — "I removed 14 console.logs" feels like progress, not loss.

    Celebrate the removal. This is counterintuitive for kids who measure progress by what they ADD. Reframe it: "Your codebase is lighter and faster now. A shorter file is easier to understand, easier to debug, and easier to show to someone else." Professional developers call this "paying down technical debt."

    Expect resistance. If a child says "but I might need that later" about a piece of code, remind them: if they need it, they can write it again. Code they don't understand is more dangerous than code they don't have.

    Tomorrow: DRESS REHEARSAL — a full playtest before the final push. Your code is clean, your numbers are tuned, your feedback is juicy. Time to see if it all holds together under pressure.