Video summary

This Problem Changes Your Perspective On Game Dev

Main summary

Key takeaways

Educational

Main Ideas / Concepts

  • Game development can be reframed as a “search algorithm.”

    • You’re always searching for the “best game” possible.
    • The “lake” metaphor represents the design/search space—you’re trying to find the deepest spot (the best design) efficiently.
    • The order of experiments, direction of first attempts, and how results are measured are crucial.

  • How to search (“captain” metaphors)

    • Captain 1 (basic): Measures occasionally, moves around, then locks in the best result.
      • Often misses the true optimum because exploration is too unguided.
    • Captain 2 (educated): Continues regular measurements and makes informed turns based on data.
      • Typically finds better results than Captain 1.
    • Captain 3 (“gigabrain” best): Starts with broad exploration (all directions via “teleport”), then concentrates around the most promising areas.
      • Best balance of exploration and focus.

  • Core guiding principle: you can’t just optimize—you must keep searching

    • Don’t stop exploration completely.
    • Continue occasional measurements and playtests to correct course if you’re wrong.

Seven Common Problems (and How to Solve Them)

1) Speed vs. Accuracy Trade-off

  • You must balance:
    • Fast but inaccurate search vs.
    • Slow but accurate search.

Method / instruction

  • Start with slow but accurate exploration in all directions.
  • Transition into faster but less accurate search as you narrow down.

Indie-phase framing (example: Thronefall)

  • Exploration phase (early): many prototypes to test directions (each prototype is a measurement).
  • Pre-production: active search within a smaller radius; prototype core systems and art direction.
  • Production: shift toward speed (accept lower “search accuracy” because you must ship), e.g., rebuilding systems and polishing.

2) Local Minimum (“illusion of having found the deepest spot”)

  • You may think you found the best point because small moves get worse, but a deeper solution exists farther away.

Method / instruction

  • Occasionally make bigger “jumps” in the search tree (cross the hill).
  • Take these jumps when they’re cheap to discover deeper regions.

Example

  • Fortnite began as a base-building tower defense concept, but the team made a big jump to a different mode—and it became massively successful.

3) Infinite Search Space Problem (“how do you search endlessly many games?”)

  • You can’t brute force everything; you need to use knowledge.

Method / instruction

  • Guess a promising direction using measurements from your database, not blindly.
  • Use:
    • Past successful/failing games (public knowledge about outcomes)
    • Your own project history (personal database)
  • Use an Innovation-scale sweet spot:
    • Not “fully unique,” and not a copy—aim near proven successes with enough differentiation.

4) Chasing the Wrong Objective (“deepest spot for the wrong boat”)

  • Different players/teams optimize for different goals (joy, portfolio, commercial success).

Instruction

  • Be explicit about what you measure and optimize for—what gets measured gets improved.

Example metaphor

  • Wanting “viral” when you only want recognition/joy leads to misguided optimization.

5) Noisy Measurements

  • Results can look great due to tester bias/noise (e.g., only one playtester).

Method / instruction (“be a scientist”)

  • Measure twice where it matters
  • Let time pass
  • Cool down excitement (“poop particles” metaphor)
  • Use additional testers if possible, but still expect noise and inaccuracy.

6) Exploration Cost (fear of spending time)

  • Avoiding exploration creates slow, invisible failure: you circle and only discover problems too late.

Method / instruction

  • Don’t eliminate exploration—minimize exploration cost, not exploration itself.

Cheapest exploration = prototypes

  • Prototype as scouting boats:
    • Fast, scrappy, “good enough” for measurement.
    • Don’t write perfect production code.

Parallelize scouting

  • Use multiple small prototypes rather than one large, slow one.
  • Send idle teammates into separate scouting tasks.

Prototype art and gameplay separately

  • If you build them together, you stop “searching” and start “making the game,” losing speed.
  • Separate prototypes for faster iteration and cleaner measurements.

Additional note

  • Prototype systems early when they’re relevant to search.
  • Don’t start a full new production project just to try an idea.

7) Multiple Captains Problem (endless debate / emotional lock-in)

  • Teams can get stuck arguing because both sides invested time (sunk cost fallacy).
  • Naive “compromise” solutions (e.g., “do both”) often cause scope creep and dissatisfaction.

Main solution (switch places / teleport ability)

  • Have the two captains swap branches and continue searching from each other’s position for a while.
    • Removes emotional asymmetry (equalizes investment)
    • Creates more rational argumentation

Secondary method (reduce conflict)

  • Split responsibilities:
    • One captain has final authority on art
    • Another has final authority on gameplay
  • Limit decision makers to reduce friction.
  • “Crew members” can act like mini-captains inside defined domains, while top steering stays centralized.

“Red Flags” the Search Algorithm Isn’t Working

  1. You never scrap any work

    • Means no real exploration branches; you follow your nose into a poor local minimum.
    • Examples:
      • Will You Snail: no experimentation on the character controller; built a large project quickly without testing fundamentals.
      • Thronefall economy: only 1–2 economy balancing attempts; extreme snowballing; later changes became too risky/awkward.

  2. You constantly scrap work

    • Indicates commitment/decision issues or a flawed database; exploration may be nonsensical.

  3. You scrap too late

    • Often caused by lack of earlier exploration or noisy/poor measurements.
    • Example: spending two months on a card game then scrapping it.

  4. Your game “failed” (no fish)

    • The takeaway shouldn’t be “oh crap my game failed,” but:
      • “My search algorithm failed.”
    • Improve the search methodology for the next project.

Final Takeaway: What to Optimize for Revenue

If optimizing for revenue, prioritize:

  • Fun (player retention)
  • Appeal (player acquisition/marketability)
  • Scope (ability to finish the game)

Fun frameworks mentioned

  • Flow (Mihaly “Mii” Csikszentmihalyi)
    • Fun = balance between challenge and skill; flow is the “channel” between boredom and frustration.
  • Octalysis (Yu-kai Chou)
    • Eight motivation factors; includes intrinsic/extrinsic and creative/logical sides.

Appeal framework (Jonas original formula)

  • Appeal = presentation + fantasy + (multiplay by readability)

    • Presentation: art, sounds, VFX, polish/“juiciness”
      • Examples: Baldur’s Gate, Islanders, One Finger Death Punch
    • Fantasy: the experience players crave (often roleplay fantasies grounded in reality)
      • Examples: Superflight (dangerous/impractical wingsuit), PowerWash Simulator (“remove negatives, keep positives”)
    • Readability: how quickly players understand the game from a screenshot/gameplay
      • Bridge between presentation/fantasy and actual gameplay
      • Examples: climbing game “a difficult game about climbing” (Ponty pant), Snakebird puzzle readability, Thronefall sometimes misread as classical RTS

Key warning

  • Too little fantasy can still work only if presentation/readability are excellent (e.g., abstract games).

Scope / keeping it small

  • Smaller/tin games can succeed; prioritize quality over quantity.

How priorities are operationalized

  • Fun measured via playtests (“what gets measured gets improved”).
  • Appeal measured indirectly via marketing/positioning performance (e.g., screenshot comparison).

Methodology / Instruction Lists

A) Search Strategy Structure (general)

  • Treat every prototype as a measurement in the design search space.
  • Use phased search:
    • Exploration phase (early): wide probing of directions.
    • Pre-production: narrow focus; active search in a smaller radius.
    • Production: prioritize speed and shipping; still do occasional checks/playtests.

B) Speed vs. Accuracy (Problem #1)

  • Start with slow/accurate exploration in all directions.
  • Then transition to faster/less accurate search in promising areas.
  • Keep exploration alive later:
    • Occasional measurements and playtests to correct errors.

C) Escaping Local Minima (Problem #2)

  • Don’t rely only on small incremental steps.
  • Occasionally make bigger jumps to cross the “hill.”
  • Use times when jumps are cheap (new modes, rebalancing).

D) Navigating an Infinite Search Space (Problem #3)

  • Use database-guided guessing, including:
    • Public game record (success/failure)
    • Your own historical outcomes
  • Use an innovation sweet spot:
    • Avoid being too similar (overlap/copying) and too uniquely weird (unrecognizable/unmarketable).

E) Fixing Noisy Measurements (Problem #5)

  • When evaluation matters:
    • Measure twice
    • Wait for impressions to cool
    • Reduce bias (especially if relying only on yourself)

F) Minimizing Exploration Cost (Problem #6)

  • Use prototypes as cheap scouting boats:
    • Optimize for speed and approximate accuracy; don’t write perfect production code.
  • Prototype art and gameplay separately for faster iteration.
  • Parallelize scouting using multiple small prototypes.
  • Prototype systems early; don’t start full production just to test an idea.

G) Reducing Team Lock-in (“Multiple captains,” Problem #7)

  • Main procedure:
    • Two decision-makers swap branches/perspectives (“teleport”) and continue from the other’s position.
  • Additional:
    • Split authority by domain (e.g., art vs gameplay).
    • Centralize steering to reduce friction.

H) Revenue Optimization (“three things”)

  • Optimize for:
    • Fun (retention)
    • Appeal (acquisition/marketability)
    • Scope (finish-ability)

I) Fun Measurement / Motivation Frameworks

  • Use Flow:
    • Keep difficulty and skill aligned to reduce boredom/frustration.
  • Use Octalysis:
    • Design around intrinsic/extrinsic and creative/logical motivation sources.

J) Appeal Formula (Jonas original)

  • Appeal = (Presentation + Fantasy) × Readability
    • Presentation: polish, visuals, audio, VFX, “juiciness”
    • Fantasy: roleplay/experience grounded in reality
    • Readability: instant understanding from screenshots/gameplay

Original video