Game Design Core

Game Design Core

Triggers

• game design
• core loop
• game feel
• player motivation
• game mechanics
• meaningful choice
• progression system
• game economy
• game balance
• playtesting
• GDD
• game document
• fun factor
• engagement
• flow state
• risk reward
• player agency
• juice
• game polish
• 8 kinds of fun
• bartle types
• MDA framework

Patterns

The 30/30/30 Loop Design

Design three nested loops that create engagement at second, minute, and hour timescales

Starting any game design, evaluating if core loop is solid

# Every game needs three interlocking loops:

## 30-SECOND LOOP (Micro)
The second-to-second experience. Must be inherently satisfying.
- Doom: shoot-kill-move
- Mario: run-jump-land
- Tetris: rotate-place-clear
- Hades: attack-dash-attack

TEST: Is this action fun with no goals, no progression, no rewards?
If not, no amount of meta-game will save it.

## 30-MINUTE LOOP (Meso)
The session structure. Creates rhythm and natural break points.
- Roguelikes: run-death-restart
- Match-3: level-reward-next
- Shooters: mission-loadout-mission
- MOBAs: match-results-queue

TEST: Do players naturally pause here? Is there a "just one more" hook?

## 30-HOUR LOOP (Macro)
The long-term progression. Creates goals and mastery.
- Unlocks, upgrades, new abilities
- Narrative progression
- Skill development and rankings
- Collection and completion

TEST: Is there always something to work toward? Does mastery feel earned?

# The magic happens when loops reinforce each other:
- Micro success -> Meso progress -> Macro advancement
- Macro goals -> Meso structure -> Micro motivation

Meaningful Decisions Framework

Structure choices so every decision matters and has interesting trade-offs

Designing any player choice, from combat to character building

# Sid Meier: "A game is a series of interesting decisions"

## What makes a decision meaningful:

1. NO DOMINANT STRATEGY
   Bad: Sword does 10 damage, Axe does 5
   Good: Sword is fast but weak, Axe is slow but breaks armor

2. INCOMPLETE INFORMATION
   Bad: You know exactly what happens
   Good: You're gambling on outcomes, weighing probabilities

3. SITUATIONAL VALUE
   Bad: One choice is always optimal
   Good: Best choice depends on context, changes throughout game

4. PERMANENT CONSEQUENCES
   Bad: Can be undone instantly
   Good: Live with your choices (or at least for a while)

5. TRADE-OFFS, NOT PUZZLES
   Bad: One right answer to discover
   Good: Multiple valid approaches with different costs/benefits

## The Decision Checklist:
For every player decision, ask:
- Can players reasonably argue for different choices?
- Do experienced players make different choices in different situations?
- Does the choice reflect player personality/playstyle?
- Is there genuine uncertainty about the outcome?

If the answer is "no" to most of these, it's not a decision - it's a puzzle or a trap.

Vlambeer Juice Philosophy

Make every action feel incredible through layered feedback

Polish phase, making actions feel impactful, fixing "floaty" feel

# Jan Willem Nijman's GDC "Art of Screenshake" talk in action

## A Simple Attack - Before Juice:
- Player presses attack button
- Attack animation plays
- Damage number appears

## The Same Attack - After Juice:
TIMING:
- Hitstop (freeze 2-4 frames on impact)
- Hitlag (slow-motion micro-moment)

CAMERA:
- Screen shake (intensity based on impact)
- Camera kick (slight push in direction)
- Zoom pulse (subtle 2% zoom on impact)

VISUAL:
- Impact particles
- Hit flash on enemy
- Damage number with weight (bounces, fades)
- Motion blur on attack
- Trail effect on weapon

AUDIO:
- Impact sound (pitch-randomized)
- Crunch/meat sound for damage
- Enemy pain vocalization
- Environmental response

FEEL:
- Controller rumble (if available)
- Knockback on enemy
- Slight player push-back (Newton's 3rd law)

## The Rule: Actions should feel MORE powerful than they are
Players can't feel damage numbers. They feel feedback.

Flow Channel Design

Keep players in the optimal challenge zone between boredom and frustration

Designing difficulty, progression pacing, adaptive systems

# Jenova Chen's Flow Theory in Games

     ANXIETY
     /         \
    /           \     <- Stay in this channel
   /    FLOW     \
  /     ZONE      \
 /                 \
BOREDOM

## Keeping Players in Flow:

1. DYNAMIC DIFFICULTY
   - Track player performance silently
   - Adjust parameters without breaking immersion
   - "Rubber band" systems (enemies miss more when player is low health)

2. SKILL-GATED PROGRESSION
   - New challenges unlock only when ready
   - "Invisible walls" that open when mastery demonstrated
   - Optional hard content for advanced players

3. MASTERY REVEALS DEPTH
   - Surface layer accessible to beginners
   - Hidden complexity rewards investment
   - Advanced techniques discoverable but not required

4. FAILURE IS FAST
   - Quick restart, minimal punishment
   - Learn through iteration, not reading
   - Death teaches, not punishes

## The Difficulty Truth:
Players don't want "easy" or "hard"
Players want to feel "skilled"

The best difficulty is the one where players believe
they succeeded through their own competence.

Friction vs. Flow Design

Know when to add friction (meaningful resistance) vs remove it (frustrating obstacles)

Evaluating any mechanic that slows players down

# Not all friction is bad. Not all smoothness is good.

## GOOD FRICTION (Meaningful Resistance)

Design Intent: Creates tension, makes success feel earned

Examples:
- Reload times in shooters (creates vulnerability windows)
- Stamina systems (prevents button mashing)
- Resource scarcity (forces meaningful choices)
- Travel time (makes world feel vast)
- Crafting requirements (makes gear feel earned)

## BAD FRICTION (Frustrating Obstacles)

Design Intent: None - just annoys players

Examples:
- Long, unskippable cutscenes
- Inventory management tedium
- Excessive menu navigation
- Grinding for grinding's sake
- Wait timers not tied to gameplay

## The Friction Test:
1. Does this friction create interesting decisions?
2. Does overcoming it feel satisfying?
3. Does it serve the game's core fantasy?
4. Would players choose to keep it if given an option?

If no to most: it's not friction, it's annoyance.

Player Motivation Frameworks

Design for intrinsic motivation, understand what different players want

Understanding your audience, designing reward systems, retention analysis

## SELF-DETERMINATION THEORY (SDT)

Three universal human needs games can fulfill:

AUTONOMY - "I'm in control"
- Meaningful choices
- Multiple valid paths
- Player-driven goals

COMPETENCE - "I'm getting better"
- Clear skill progression
- Fair challenges
- Mastery visible

RELATEDNESS - "I belong"
- Community
- Shared experiences
- Competition/cooperation

## BARTLE'S PLAYER TYPES

KILLERS (15%) - Acting on players
- Want to dominate, compete, win
- Need: Leaderboards, PvP, visible rankings

ACHIEVERS (10%) - Acting on world
- Want to complete, collect, master
- Need: Achievements, unlocks, 100% markers

SOCIALIZERS (50%) - Interacting with players
- Want to connect, share, belong
- Need: Chat, guilds, shared experiences

EXPLORERS (25%) - Interacting with world
- Want to discover, understand, find
- Need: Hidden secrets, lore, easter eggs

## LAZZARO'S 8 KINDS OF FUN

1. Sensation - Game as sense pleasure
2. Fantasy - Game as make-believe
3. Narrative - Game as drama
4. Challenge - Game as obstacle course
5. Fellowship - Game as social framework
6. Discovery - Game as uncharted territory
7. Expression - Game as self-discovery
8. Submission - Game as pastime

DESIGN IMPLICATION: Know which types of fun your game provides.
Don't try to serve all of them. Master 2-3.

MDA Framework Application

Design from aesthetics backward through dynamics to mechanics

Starting design, debugging why game doesn't "feel right"

# Mechanics -> Dynamics -> Aesthetics
# (But design in reverse)

## AESTHETICS (What players feel)
The emotional experience. What you're actually selling.
- Tension, triumph, wonder, humor, fear
- "How do we want players to feel?"

## DYNAMICS (What players do)
Emergent behavior from mechanics interaction.
- Risk-taking, cooperation, exploration
- "What behaviors will create those feelings?"

## MECHANICS (What the rules are)
The verbs, systems, and numbers.
- Jump height, damage values, resource rates
- "What rules will encourage those behaviors?"

## Example: Horror Game

AESTHETIC GOAL: Fear, vulnerability, relief

DYNAMICS NEEDED:
- Resource hoarding
- Avoidance over confrontation
- High-stakes decision making

MECHANICS THAT CREATE THIS:
- Scarce ammunition
- Strong, unkillable enemies
- One-hit deaths
- Limited saves

## Common Mistake:
Designing mechanics first, hoping aesthetics emerge.

## Better Approach:
Define the feeling. Work backward to the rules.

Onboarding Without Tutorials

Teach through play, not popups - communicate through design

Designing first-time user experience, any teaching moment

# Miyamoto: "The player should understand the game just by playing it"

## THE NINTENDO APPROACH:

1. SAFE INTRODUCTION
   - First enemy can't kill you
   - First gap can be walked over
   - First puzzle has only one solution

2. ESCALATING CHALLENGE
   - Add one element at a time
   - Master before complicating
   - Combine after individual mastery

3. ENVIRONMENTAL TEACHING
   - Level design guides attention
   - Collectibles mark the path
   - Environmental storytelling for mechanics

## CONCRETE TECHNIQUES:

GATING:
- Can't leave first area until jump is used
- Door requires newly learned ability
- Hidden but findable progression gates

REPETITION:
- Same obstacle 3 times, increasing difficulty
- Safe practice → low stakes → high stakes

NEGATIVE SPACE:
- What you don't do teaches too
- Closed paths guide toward open ones

JUST-IN-TIME:
- Teach when needed, not before
- Context makes lessons memorable

## The Tutorial Test:
Play with no text, no popups.
If players can't figure it out, the design failed - not the player.

Risk-Reward Calibration

Design gambling without the lawsuit - make risk feel worth taking

Designing combat, exploration incentives, player choices

# Players crave risk when stakes feel fair

## THE RISK-REWARD SPECTRUM:

LOW RISK / LOW REWARD (Safe Path)
- Always available, always viable
- Slow but steady progress
- For cautious players or recovery

MEDIUM RISK / MEDIUM REWARD (Normal Play)
- Some chance of failure
- Faster progress when successful
- Where most play happens

HIGH RISK / HIGH REWARD (Big Plays)
- High chance of failure
- Massive payoff on success
- Creates memorable moments

## DESIGN PRINCIPLES:

1. RISK MUST BE OPT-IN
   Forced risk isn't exciting, it's frustrating.
   "I chose this" vs "I had no choice"

2. INFORMATION BEFORE DECISION
   Player must understand the stakes.
   Surprise difficulty spikes feel cheap.

3. NEAR-MISSES ARE POWERFUL
   Barely failing is more engaging than easy success.
   "I almost had it" creates retry motivation.

4. STREAKS CREATE DRAMA
   Consecutive successes/failures feel meaningful.
   Gambling psychology: hot/cold streaks feel real.

## Example: Healing System

SAFE: Heal at save points (no cost, no risk)
RISKY: Heal items drop from combat (risk for reward)
HIGH RISK: Heal by attacking enemies (aggressive play rewarded)

Best design: All options available, player chooses style.

Emergence vs. Authored Design

Balance between designed experiences and systemic surprises

Deciding game structure, understanding player stories

# The Spectrum of Player Experience

FULLY AUTHORED                    FULLY EMERGENT
|<-------------------------------->|
Linear       Open       Sandbox    Simulation
Story        World

## AUTHORED EXPERIENCES
- Designer controls the moment
- Guaranteed quality
- "Best bits" carefully crafted
- Everyone sees the same thing

Games: Uncharted, Portal, Last of Us

Strengths:
- Emotional beats land
- Pacing is perfect
- Quality control

Weaknesses:
- Low replayability
- No player ownership
- "Theme park" feel

## EMERGENT EXPERIENCES
- Systems create stories
- Player-driven narratives
- Unique playthroughs
- Unpredictable moments

Games: Dwarf Fortress, RimWorld, Breath of the Wild

Strengths:
- Infinite replayability
- Player ownership
- Community stories

Weaknesses:
- No guaranteed quality
- Players can miss "good parts"
- Harder to balance

## THE HYBRID APPROACH:
Most great games mix both.

- Authored: Main story, set pieces, tutorials
- Emergent: Combat, exploration, player expression

The art is knowing when to let go.

Skill Ceiling vs. Skill Floor

Design for both newcomers and experts simultaneously

Designing mechanics, considering accessibility, competitive viability

# Every mechanic has two metrics:

SKILL FLOOR: How hard to use at all?
- Can a new player execute this?
- How many inputs required?
- How punishing is failure?

SKILL CEILING: How much room to improve?
- Can experts still optimize?
- Is there a mastery curve?
- Does practice reward?

## QUADRANT ANALYSIS:

HIGH FLOOR / LOW CEILING (Avoid)
- Hard to learn, nothing to master
- Frustrating, unrewarding

LOW FLOOR / LOW CEILING (Casual)
- Easy to learn, easy to master
- Accessible but shallow

HIGH FLOOR / HIGH CEILING (Hardcore)
- Hard to learn, lots to master
- For dedicated audiences

LOW FLOOR / HIGH CEILING (Ideal)
- Easy to learn, hard to master
- Satisfies everyone

## ACHIEVING LOW FLOOR / HIGH CEILING:

SIMPLE INPUTS, COMPLEX OUTPUTS
- One button does something cool
- Timing/spacing creates depth

OPTIONAL COMPLEXITY
- Basic play is viable
- Advanced techniques for experts

EMERGENT MASTERY
- Systems interact in complex ways
- Experts discover combinations

## Examples:

Chess: Easy rules, infinite depth
Rocket League: Drive, boost, jump -> infinite aerials
Hades: Attack, dash -> animation cancels, boss patterns

Feedback Loop Design

Create self-balancing and reinforcing systems that maintain engagement

Designing progression, difficulty, multiplayer balance

# Two types of feedback loops:

## POSITIVE FEEDBACK (Reinforcing)
Success makes future success easier.
Winner gets stronger.

EFFECT: Snowballing, decisive endings

Good for:
- Creating power fantasy
- Ending matches decisively
- Short sessions

Risks:
- Runaway leaders
- Early game decides outcome
- Frustrating for losers

Examples:
- Mario Kart: Lead gives time for power-ups
- MOBAs: Kills give XP advantage
- Board games: Territory = income = more territory

## NEGATIVE FEEDBACK (Balancing)
Success makes future success harder.
Winner faces new challenges.

EFFECT: Comebacks, prolonged tension

Good for:
- Competitive fairness
- Dramatic reversals
- Long sessions

Risks:
- Skill feels unrewarded
- "Rubberbanding" feels cheap
- Can extend losing games

Examples:
- Mario Kart: Blue shell targets leader
- Golf handicaps
- Dynamic difficulty

## THE ART: Combine both loops

EARLY GAME: Positive feedback (build advantage)
LATE GAME: Negative feedback (keep it close)
END GAME: Positive feedback (decisive finish)

Anti-Patterns

Designing for Yourself

Why: Building the game you want, not the game your audience wants

Feature Before Core

Why: Adding features before the core loop is proven fun

Complexity as Depth

Why: Adding more systems thinking it adds strategic depth

Tutorial As Band-Aid

Why: Using tutorials to fix unintuitive design

Balanced = Fair

Why: Assuming perfect mathematical balance creates fun gameplay

Punishing Failure, Not Teaching

Why: Making failure painful instead of instructive

Engagement Through Obligation

Why: Using daily rewards, FOMO, and artificial friction to retain players

Designing for 100% Completion

Why: Expecting all players to see all content

Ignoring Playtest Data

Why: Dismissing player feedback because "they're playing wrong"

Sharp Edges

[CRITICAL] Building systems before proving the core loop is fun

Adding progression, economy, story, or polish to a game whose moment-to-moment gameplay hasn't been validated

Why: The core loop is the foundation. If shooting isn't fun, no amount of unlockable guns will save it. If matching isn't satisfying, progression won't matter. Every hour spent on meta-systems for a broken core is wasted. You cannot polish a rock into a diamond. Most cancelled games die here: the team builds outward from a core that was never proven.

Symptoms:

• It'll be fun once we add progression

• Core loop not playtested standalone

• Adding features to hide core problems

• Designer knows the game isn't fun but is "waiting for it to come together"

Solution: The Gray Box Test:

1. Build the core mechanic with programmer art
2. No progression, no rewards, no story
3. Play it for 10 minutes
4. Is it fun yet?

If no: iterate on the core If yes: now add one layer

Valve's approach:

• Orange Box prototype
• Playtest daily
• Core loop locked before production

Ask: "Would I play this with no rewards?" If the answer is no, the core is broken.

[CRITICAL] Adding features without cutting scope

Every idea becomes a feature, no ideas are killed, scope only grows

Why: Every feature has hidden costs:

• Implementation time
• Testing time
• Balancing time
• Tutorial/teaching time
• Maintenance time
• Interaction with other features

A game with 20 half-finished features is worse than one with 5 polished features. Players don't count features - they feel quality. The game that ships beats the game that doesn't.

Sid Meier's rule: "Take out what doesn't work, not what you like."

Symptoms:

• Feature list only grows, never shrinks

• We'll add that too

• No features cut in months

• Team afraid to say no to ideas

• Release date keeps slipping

Solution: The Feature Test (for every proposed feature):

1. Does this improve the core loop?
2. What do we cut to make time for this?
3. Would players miss it if we shipped without it?

If you can't answer #2, you can't add the feature.

Scope Management:

• Kill features publicly and celebrate cuts
• "Feature graveyard" document
• Every addition needs a subtraction
• Playable builds at every stage

The Three-Feature Rule: What are the three things players will remember? Everything else is negotiable.

[CRITICAL] Building the game you want, not the game your audience wants

Designer preferences override playtest data, target audience not defined

Why: You are the worst possible playtester for your own game:

• You know every secret
• You understand every system
• You have hundreds of hours of practice
• You know the designer intent

Fresh players have none of this. What's obvious to you is invisible to them. Your muscle memory is their learning curve. Your "easy" is their "impossible."

Symptoms:

• They're playing it wrong

• They just need to read the tutorial

• No external playtests

• Designer is their own primary tester

• Target audience is "gamers"

Solution: The Stranger Test:

1. Find someone who's never seen the game
2. Sit them in front of it
3. Say nothing
4. Take notes on everything they struggle with

Golden rules of playtest observation:

• Never explain anything
• Never defend any choice
• "Why did you do that?" not "You should have..."
• Watch hands and face, not screen

Target Audience Definition:

• Write a player persona
• Name them, give them a life
• Design for them, not you

If you have to explain why something is fun, it isn't.

[HIGH] Adding more systems thinking it creates strategic depth

Game has many interconnected systems but decisions still feel obvious

Why: Complexity != Depth

Complexity: How many things can I do? Depth: How many interesting decisions emerge?

Chess has 6 piece types. Go has 1 stone type. Both have infinite depth.

More systems create:

• Cognitive overload
• Spreadsheet gameplay
• Analysis paralysis
• "I'll just do what worked last time"

Depth comes from interesting interactions between simple systems, not from system count.

Symptoms:

• Players use guides to understand basic play

• New players overwhelmed

• No emergent strategies

• Dominant strategies exist despite complexity

• Adding more to solve "it feels shallow"

Solution: The Simplification Test:

1. Remove one system entirely
2. Does the game get worse?
3. If not, it was complexity, not depth

Signs of true depth:

• Experts play differently than beginners
• Debates exist about "best" strategy
• Meta evolves over time
• High-level play looks different

Design for elegant interactions:

• Few rules, many outcomes
• Mechanics that combine interestingly
• Emergent complexity from simple parts

Mark Rosewater's lesson from Magic: "Restrictions breed creativity."

[HIGH] Using tutorials to fix unintuitive design

Adding more tutorial text because players don't understand a mechanic

Why: Tutorials are a tax on player patience. Every tutorial popup is an admission that the design failed to communicate. Players skip tutorials. Players forget tutorials. Players resent tutorials.

If your design needs explaining, the design is the problem.

Miyamoto's observation: "Players should understand the game just by playing it."

Symptoms:

• Tutorial text growing longer

• We'll explain it in the tutorial

• Players skip tutorial and fail

• Multiple tutorials added over development

• Tutorials for every system

Solution: The No-Tutorial Test:

• Remove all tutorial text
• Can a player figure out the basics?
• If not, redesign, don't re-explain

Environmental Teaching:

• Level design guides attention
• Gating requires demonstrated understanding
• Safe spaces to experiment

Just-In-Time Over Just-In-Case:

• Teach when relevant, not before
• Show, don't tell
• Let players discover

Nintendo's Approach (Super Mario):

1. First goomba can't kill you
2. First pit can be walked around
3. First mystery block is obvious
4. Complexity builds on mastered basics

If players need the tutorial, your first level failed.

[HIGH] Pursuing perfect balance at the expense of fun

All options are equally viable, no option feels powerful

Why: Perfect balance means no decisions matter. If all weapons are equal, picking one is meaningless. If all characters are the same power level, character selection is cosmetic.

Players want to find "the good stuff." Discovery is fun. Power spikes are memorable. "Broken" combos become stories.

Blizzard's philosophy: "Everything is overpowered, so nothing is."

Symptoms:

• All options perform identically

• No discussions about "meta"

• No discovery moments

• Purely skill matchups (options irrelevant)

• Constant nerfs, never buffs

Solution: Strategic Imbalance:

• Intentional power differences
• Rock-paper-scissors relationships
• Contextual strength (situationally powerful)

Meta Management:

• Rotate balance patches
• Let players discover before nerfing
• "Flavor of the month" keeps game fresh

The Fun Imbalance:

• Early game: Obvious best options (help new players)
• Mid game: Situational choices emerge
• Late game: Everything viable at high skill

Fighting Game Wisdom:

• Tier lists create metagame
• Low-tier heroes are for showing off
• Perfect balance = dead scene

[HIGH] Making failure painful instead of instructive

Large penalties for death/failure, long setbacks, frustrating loss loops

Why: Punishment doesn't teach - it discourages.

When failure hurts too much:

• Players stop experimenting
• Risk-taking dies
• Frustration builds
• Players quit

The goal is learning, not suffering. Dead players should know WHY they died and be EXCITED to try again.

Dark Souls works not because it's hard, but because death is fast and teaching is clear.

Symptoms:

• Long reload/respawn times

• Large progress loss on death

• Players save-scumming

• Rage quits at specific points

• Unfair death complaints

Solution: Failure as Information:

• Clear cause of death
• Quick restart
• Minimal lost progress
• Visible improvement path

The Roguelike Model:

• Death resets run, not learning
• Each attempt teaches something
• Progression happens despite death
• "I almost had it" feeling

Punishment Budget:

• 10 seconds of pain, max
• Quick feedback loop
• Try again in < 30 seconds

Celeste's Approach:

• Instant respawn
• Room-by-room checkpoints
• Death is expected
• Assist mode available

[HIGH] Using FOMO, dailies, and artificial friction to retain players

Daily rewards that disappear, limited-time events, wait timers

Why: There's a difference between:

• Players wanting to play
• Players afraid to miss out

Obligation creates resentment. Players feel trapped, not engaged. When they finally quit, they quit forever. You've traded short-term retention for long-term hatred.

These games are remembered as manipulative, not fun.

Symptoms:

• Streak mechanics

• Disappearing rewards

• FOMO-driven events

• Players complaining about "having to" play

• High churn after streak breaks

Solution: Desire Over Duty:

• Make returning feel good, not missing feel bad
• Rewards for playing, not penalties for absence
• Respect player time

Sustainable Engagement:

• Players should want to play, not feel forced
• "I want to play" > "I have to play"
• Leave players wanting more, not dreading less

The Breath of Fresh Air Test: Would players miss this if they took a week off? If they'd feel RELIEVED to skip, you've built a prison.

Exception: Games explicitly designed as habits (fitness apps, language learning) Even then, gentle encouragement > punishment.

[CRITICAL] Dismissing player feedback because it conflicts with designer vision

Playtests show problems, designer argues players are wrong

Why: There is no "wrong" way to play. If players consistently:

• Fail at the same point
• Misunderstand the same mechanic
• Skip the same content
• Get frustrated at the same moment

That's not a player problem. That's a design problem.

Players are always right about their experience. They might be wrong about solutions, but they're never wrong about their feelings.

Symptoms:

• Explaining away negative feedback

• They just need to learn

• Same issues in multiple playtests

• Designer defends during feedback

• Changes not made after playtests

Solution: The Observation Rule:

• Watch, don't explain
• Note patterns, not individuals
• Three players same problem = design problem

Data Over Opinion:

• Heatmaps > hunches
• Completion rates > intentions
• Time-in-section > designer estimates

Designer Humility:

• "Why do players do this?" not "Players shouldn't do this"
• Design for actual behavior, not ideal behavior
• Your intent is invisible to players

Post-Playtest Process:

1. What did they struggle with?
2. Where did they quit?
3. What did they skip?
4. What made them laugh/smile?
5. What would they change?

Actions speak louder than feedback forms.

[HIGH] Writing detailed design documents for unvalidated ideas

Spending weeks on GDD before any playable prototype exists

Why: Design documents are fiction until validated by play.

You cannot design fun on paper. Fun emerges from play. The game in your head and the game on screen are different games. Every hour spent documenting unproven ideas is an hour not spent discovering what works.

The industry graveyard is full of beautiful GDDs for games that were never fun.

Symptoms:

• 100-page GDD, no prototype

• Weeks of design before code

• Detailed systems for unproven core

• Design docs not updated after playtests

• It's all in the document

Solution: Prototype First:

• Ugly but playable > Beautiful but theoretical
• One week prototype > One month document
• Find the fun, then document it

Living Documentation:

• Documents evolve with the game
• Prototypes prove, documents record
• Update docs after discoveries

The Jonathan Blow Approach:

• Write code, not docs
• Play every day
• Design emerges from play

Minimum Viable Document:

• Core loop (one paragraph)
• Target experience (one sentence)
• Three features that matter
• Everything else discovered through play

[MEDIUM] Designing late-game content as if most players will see it

Spending equal effort on early and late game content

Why: The harsh truth of player behavior:

• 90% start your game
• 50% finish the tutorial
• 25% reach the midpoint
• 10% see the credits
• 5% do everything

Every hour spent on 100% completion content is seen by almost no one. Your best content should be in the first 30 minutes, not the last.

Symptoms:

• Equal time on early/late content

• Best set pieces at the end

• Early game rushed for "the good part"

• Retention drops at tutorial

• It gets good after 10 hours

Solution: Front-Load Quality:

• First impression is everything
• Best content early
• Diminishing returns on late-game polish

Content Investment Strategy:

• First hour: Maximum quality
• Main path: High quality
• Side content: Good quality
• Completion content: Volume over quality

The Netflix Principle: Viewers decide in 5 minutes. Players in 5 seconds. Your "skip" is their "uninstall."

Completionist Content:

• Quantity > polish
• Reuse systems creatively
• Let dedicated fans forgive rough edges

[MEDIUM] Relying on unlocks and numbers going up to create engagement

Players only engaged during unlock moments, bored between

Why: Progression systems can't make a boring game fun. They can only:

• Extend engagement with an already-fun game
• Provide goals to work toward
• Create anticipation and pacing

If the core loop isn't fun, players are just clicking through animations waiting for the next unlock. That's not engagement, that's sunk cost.

The test: Would players still play with all content unlocked?

Symptoms:

• Excitement only at unlocks

• Boredom between milestones

• Players grinding, not playing

• When do I get to the good stuff?

• Progression skip purchases

Solution: Progression as Enhancement:

• Core loop must be fun at minute 1
• Unlocks add variety, not fun
• New content changes HOW you play, not WHETHER it's fun

Roguelike Wisdom:

• Run is fun independent of progression
• Unlocks add variety, not viability
• New players can still win

The Core Loop Test:

• Give a player all unlocks
• Remove all progression
• Is it still fun?

If no: fix the core loop, not the progression.

[HIGH] Adding every mechanic that might be fun

Game tries to do everything, masters nothing

Why: Every mechanic you add:

• Competes for player attention
• Needs teaching
• Interacts with other mechanics
• Can break or be broken

A game that does 3 things exceptionally beats a game that does 20 things adequately. Players remember what you do best, not what you also do.

Pokemon is about catching creatures. The battles are simple. Breath of the Wild is about exploration. Combat is secondary. Celeste is about jumping. Story is minimal.

Symptoms:

• It's like X meets Y meets Z meets...

• Features compete for tutorials

• Players confused about the point

• Equal time on all systems

• Can't describe in one sentence

Solution: The Focus Test: What is this game ABOUT? (One sentence) Everything supports this or gets cut.

The Three-Feature Rule: Name three features players will remember. Those get 80% of your attention.

System Justification: For every system, ask:

• Does this make the core better?
• Could the game ship without it?
• What are we NOT doing because of this?

Subtraction Design: Remove systems until removing one more would hurt. What remains is the game.

Validation Checklist

• [CRITICAL] GDD Missing Core Loop Definition

  • Game design document without core loop definition. The core loop must be defined before any other systems.
  • Fix: Add a Core Loop section that answers:

• What does the player do second-to-second?

• What does the player do minute-to-minute?

• What keeps players coming back hour after hour?

• [ERROR] GDD Missing Target Audience

  • No target audience defined. You must know who you're designing for.
  • Fix: Add a Target Audience section including:

• Player persona with name and description

• Gaming habits and preferences

• Skill level expectations

• Time investment expectations

• [WARNING] GDD Missing Design Risks

  • No design risks or assumptions documented. Every design has unknowns that should be tested.
  • Fix: Add a Design Risks section:

• What assumptions are we making?

• What needs to be validated through playtesting?

• What could go wrong with this design?

• [WARNING] GDD Missing Success Criteria

  • No success metrics defined. How will you know if the design works?
  • Fix: Add measurable success criteria:

• Session length targets

• Retention metrics

• Player behavior goals

• Playtesting benchmarks

• [WARNING] Mechanic Without Trade-off

  • Design describes an option with no downsides. Meaningful choices require trade-offs.
  • Fix: Add trade-offs:

• What does the player give up by choosing this?

• In what situations is this NOT the best choice?

• How does this interact with other choices?

• [WARNING] Mechanic With Obvious Solution

  • Design suggests a dominant strategy. If there's always a right answer, there's no real choice.
  • Fix: Create situational value:

• When would the opposite choice be correct?

• What information changes the best choice?

• How do different playstyles affect the choice?

• [ERROR] Progression Designed Before Core Loop

  • Progression system designed without core loop validation. Progression can't make a boring game fun.
  • Fix: Before designing progression:

1. Document the core loop
2. Prototype the core loop
3. Validate through playtesting
4. THEN design progression

• [WARNING] Infinite Progression Without Cap

  • Infinite progression can break game balance. Consider caps and diminishing returns.
  • Fix: Add progression boundaries:

• Soft caps with diminishing returns

• Hard caps for balance

• Horizontal progression alternatives

• Prestige/reset systems

• [WARNING] Difficulty Without Skill Floor Consideration

  • Difficulty discussed without new player consideration. Design for skill floor AND ceiling.
  • Fix: Address accessibility:

• How do new players learn?

• What's the minimum skill required?

• Are there assist options?

• Is failure instructive?

• [WARNING] Punitive Death Design

  • Punitive death system detected. Ensure failure teaches, not just punishes.
  • Fix: Balance punishment with learning:

• Is the cause of death clear?

• Is restart time fast (<30 seconds)?

• Does the player know how to improve?

• Consider roguelike meta-progression

• [INFO] Single Currency Economy

  • Single currency economy may lack depth. Consider if multiple currencies would add meaningful choices.
  • Fix: Evaluate currency complexity:

• Does adding currency add decisions?

• Would it just add math?

• Consider soft vs. hard currency

• Free-to-play implications

• [WARNING] Economy Without Sink

  • Currency earning without spending mechanisms leads to inflation.
  • Fix: Add currency sinks:

• Consumables

• Maintenance costs

• Upgrade costs that scale

• Cosmetic purchases

• [WARNING] FOMO-Based Retention

  • FOMO-based retention detected. Consider if this respects player time.
  • Fix: Evaluate retention ethics:

• Is this creating desire or obligation?

• Would players feel relieved to miss it?

• Consider catch-up mechanics

• Respect player autonomy

• [WARNING] Playtest Without Research Questions

  • Playtest planned without specific questions. Know what you're testing.
  • Fix: Define playtest goals:

• What specific question are we answering?

• What behavior would confirm/deny our hypothesis?

• What metrics will we track?

• [WARNING] Playtest Without Metrics

  • Playtest without defined metrics. Measure behavior, not just feedback.
  • Fix: Add measurable observations:

• Time to complete sections

• Number of deaths/failures

• Time spent in menus vs. gameplay

• Quit points and retry rates

• [WARNING] Text-Heavy Tutorial

  • Text-based tutorial approach. Players skip text. Design for learning through play.
  • Fix: Replace text with design:

• Gating that requires mechanic use

• Safe spaces to experiment

• Environmental guidance

• Show, don't tell

• [WARNING] Front-Loaded Tutorial

  • Tutorial teaches everything upfront. Players forget what they don't use immediately.
  • Fix: Implement just-in-time teaching:

• Teach when the mechanic becomes relevant

• Space learning over time

• Let players discover advanced techniques

• [INFO] Perfect Balance as Goal

  • Perfect balance may reduce interesting decisions. Consider strategic imbalance.
  • Fix: Evaluate balance philosophy:

• Does imbalance create discovery?

• Are there situational advantages?

• Can meta evolve over time?

• [WARNING] Balance Through Numbers Only

  • Balance changes focused on numbers. Consider if the design needs reworking instead.
  • Fix: Consider design changes:

• Is the mechanic working as intended?

• Would a redesign work better than number changes?

• Are we treating symptoms or causes?

Handoffs

• level layout or spatial design or map design → level-design — User needs spatial/environmental design expertise
• story or character or dialogue or narrative → narrative-design — User needs story/character development
• monetization or IAP or free-to-play or gacha → game-monetization — User needs business model design
• AI behavior or enemy patterns or NPC logic → game-ai-behavior — User needs game AI/behavior tree design
• worldbuilding or lore or setting → worldbuilding — User needs world/setting development
• user experience or UX or usability → ux-design — User needs UX/usability expertise
• implementation or code or engine → game-design — User needs technical game development