Feedback Systems and State Machines
Learning Objectives: By the end of this lesson, you will be able to:
- Design feedback systems that communicate clearly with players
- Understand positive and negative feedback loops and their effects on gameplay
- Model games as state machines to clarify game flow
- Balance feedback to create tension without frustration
- Apply state machine concepts to prevent bugs and improve clarity
1. Welcome and Introduction (5 minutes)
Icebreaker Activity
Have you ever played a game where you died and had no idea why? Or won and didn’t feel like you earned it? That’s a feedback problem. Conversely, think of a game where every hit felt powerful, every victory felt earned, and you always knew exactly what was happening. That’s great feedback design.
What separates these experiences?
Lesson Overview
- Duration: 90-120 minutes
- Prerequisites: Lessons 1-2 (MDA Framework, Core Loops)
- Materials Needed: Paper for state diagrams, access to games for analysis
2. Learning Objectives and Session Outline (5 minutes)
What We’ll Cover Today:
- Feedback Fundamentals - What feedback is and why it matters
- Types of Feedback - Immediate, delayed, positive, negative
- Feedback Loops - How feedback creates spiraling effects
- State Machines - Modeling game flow as discrete states
- Practical Application - Designing feedback and states for real systems
Success Criteria:
By the end of this session, you should be able to design feedback for any game system and diagram its states clearly.
3. Foundation Knowledge (15-20 minutes)
Core Concepts
What is Game Feedback?
Feedback is any information the game provides to players about their actions, the game state, or upcoming events. It’s how games communicate.
Real-World Analogy: When you touch a hot stove, pain feedback tells you to remove your hand. When you hear applause, social feedback tells you your performance was good. Games need similar systems to guide player behavior.
Why This Matters:
- Without feedback, games feel unresponsive and confusing
- Good feedback makes games feel “juicy” and satisfying
- Feedback teaches players how the game works
- Feedback creates emotional experiences
Feedback Channels
Games communicate through multiple sensory channels:
| Channel | Examples | Best For |
|---|---|---|
| Visual | Animations, particles, UI changes, colors | Most information; spatial data |
| Audio | Sound effects, music changes, voice | Urgency, mood, confirmation |
| Haptic | Controller vibration, force feedback | Impact, danger, attention |
| UI | Numbers, meters, text, icons | Precise data, status |
Design Principle: Important information should be communicated through multiple channels. If something is critical, show it, play a sound, AND vibrate the controller.
Key Terminology
- Feedback: Information from the game to the player
- Feedforward: Information helping players predict outcomes
- Positive Feedback Loop: Success leads to more success
- Negative Feedback Loop: Success triggers counterbalancing forces
- State Machine: A model where a system can be in one state at a time
- State Transition: Moving from one state to another based on conditions
4. Detailed Explanation and Examples (25-30 minutes)
Types of Feedback
Immediate Feedback
Feedback that occurs instantly when the player acts.
Examples:
- Button press → Jump animation starts
- Gunshot → Muzzle flash, sound, recoil
- Sword swing → Hit marker on enemy
Why It Matters:
- Confirms input was received
- Creates “game feel”
- Makes actions satisfying
- 100ms or less delay is ideal
Design Tips:
- Never delay immediate feedback for “realism”
- Exaggerate important immediate feedback
- Layer multiple feedback types (sound + visual + haptic)
Delayed Feedback
Feedback that appears after time passes or conditions are met.
Examples:
- Plant seed → Crop grows over 3 hours → Harvest notification
- Choose strategy → Battle plays out → Result screen
- Make economic decision → Market changes over turns
Why It Matters:
- Rewards planning and strategy
- Creates anticipation
- Allows complex systems to resolve
Design Tips:
- Make it clear that delayed feedback is coming
- Provide interim feedback while waiting
- Ensure delayed payoffs are proportional to wait time
Positive Feedback (Amplifying)
Success makes future success easier.
Examples:
- Kill streak grants powerful ability → More kills → Longer streak
- Lead in race → Get ahead of item drops → Maintain lead
- Snowball gold advantage → Buy better items → Win more fights
Effects:
- Creates decisive outcomes
- Rewards skilled play
- Can feel unfair to losing side
- Games end faster
When to Use:
- When you want clear winners/losers
- When skill should be highly rewarded
- When game length needs limiting
Negative Feedback (Balancing)
Success triggers forces that help opponents or hinder the leader.
Examples:
- Lead in Mario Kart → Blue shell targets you → Others catch up
- Winning team → Longer respawn times → Other team has chance
- Dominant strategy → Nerfed in patch → Meta shifts
Effects:
- Keeps games close
- Gives everyone a chance
- Can feel unfair to leading player
- Games last longer
When to Use:
- When you want close finishes
- When player enjoyment matters more than skill expression
- When comebacks should be possible
Balancing Feedback Loops
Most games need BOTH positive and negative feedback, carefully tuned:
Pure Positive Pure Negative
↓ ↓
Snowballs quickly Never resolves / Stalemate
←──────── BALANCE ────────→
↓
Tense, fair competition
Case Study: League of Legends
- Positive: Kill gold, dragon buffs, tower advantage
- Negative: Bounty system (kill fed players = more gold), respawn timers scale
- Result: Losing team has comeback potential, but winning team maintains advantage
State Machines
A state machine models something that can be in exactly one state at a time, with defined transitions between states.
Why Use State Machines?
- Clarity: Know exactly what can happen when
- Debugging: Identify impossible states
- Communication: Team shares understanding
- Prevention: Avoid bugs from invalid states
Basic State Machine Structure
┌─────────┐ event ┌─────────┐
│ State A │ ──────────────→ │ State B │
└─────────┘ └─────────┘
│
│ event
▼
┌─────────┐
│ State C │
└─────────┘
Player Character State Machine Example
┌──────────────────────────────────────────┐
│ │
▼ │
┌──────────┐ │
│ IDLE │ │
└────┬─────┘ │
│ │
┌───────────┼───────────┐ │
│ │ │ │
▼ ▼ ▼ │
┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ RUNNING │ │ JUMPING │ │ ATTACKING│ │
└────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ │ │ ┌──────────┐ │
│ │ └────→│ RECOVERY │───────┬──────┘
│ │ └──────────┘ │
│ │ │
│ └───────────────────┐ │
│ │ │
│ ┌──────────┐ │ │
└────────→│ FALLING │←──────────┘ │
└────┬─────┘ │
│ │
│ land │
└───────────────────────────────────┘
│
│ take damage
▼
┌──────────┐
│ HURT │
└────┬─────┘
│
┌───────────────────┴───────────────┐
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ DEAD │ │ IDLE │
└──────────┘ └──────────┘
(health = 0) (health > 0)
Game Flow State Machine Example
┌────────────┐ start ┌────────────┐
│ TITLE │ ──────────────→│ MAIN MENU │
└────────────┘ └─────┬──────┘
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ OPTIONS │ │ PLAY │ │ QUIT │
└────┬─────┘ └────┬─────┘ └──────────┘
│ │
│ back │ start game
│ ▼
│ ┌──────────┐ pause ┌──────────┐
│ │ LOADING │ ─────────────→ │ PAUSED │
│ └────┬─────┘ └────┬─────┘
│ │ │
│ │ loaded │ resume
│ ▼ │
│ ┌──────────┐ ←───────────────────┘
└──────→│ GAMEPLAY │
└────┬─────┘
│
┌──────────┴──────────┐
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ VICTORY │ │ DEFEAT │
└────┬─────┘ └────┬─────┘
│ │
└──────────┬──────────┘
│
▼
┌──────────┐
│ RESULTS │──────→ MAIN MENU
└──────────┘
Common Misconceptions
-
Misconception: “More feedback is always better” Reality: Too much feedback creates noise. Prioritize important information.
-
Misconception: “Negative feedback punishes skill” Reality: Well-designed negative feedback maintains engagement; it doesn’t eliminate skill advantage.
-
Misconception: “State machines are only for programmers” Reality: Designers should define states; programmers implement them.
5. Live Coding Demonstration (20-25 minutes)
Example 1: Designing Hit Feedback
Scenario: Design feedback for a melee hit in an action game
Layers of Feedback:
IMMEDIATE (Frame of impact):
├── Visual:
│ ├── Hit spark particle effect
│ ├── Enemy flash white
│ ├── Screen shake (small)
│ └── Damage number popup
├── Audio:
│ ├── Impact sound (meaty thwack)
│ └── Enemy grunt/reaction
├── Haptic:
│ └── Controller vibration pulse
└── Animation:
├── Hitlag (freeze frames, 3-5 frames)
├── Enemy knockback animation
└── Player weapon recoil
DELAYED (100-500ms after):
├── Visual:
│ ├── Health bar decrease animation
│ └── Status effect icons (if applicable)
└── Audio:
└── Enemy recovery sound
CONTEXTUAL (depends on situation):
├── Kill:
│ ├── Death animation + sound
│ ├── Larger screen shake
│ └── Experience/loot popup
└── Critical Hit:
├── Different color hit spark
├── Special sound effect
└── "CRITICAL!" text
Example 2: Racing Game Feedback Loops
The Problem: Pure positive feedback makes racing boring (leader always wins)
Solution: Layered Feedback Systems
# Positive feedback (skill reward)
def calculate_position_bonus(position):
"""Better positions get speed boost from drafting"""
if position == 1:
return 0 # Leader has no one to draft
else:
return 0.02 * (max_racers - position) # Catch-up drafting
# Negative feedback (catch-up mechanics)
def calculate_rubber_banding(position, leader_distance):
"""Increase speed slightly when far behind"""
if position > 1 and leader_distance > threshold:
return 0.01 * min(leader_distance / 100, 0.05)
return 0
# Item distribution (negative feedback)
def get_item_probability(position, total_racers):
"""Better items more likely when further behind"""
relative_position = position / total_racers
if relative_position < 0.25: # Front runners
return {
'speed_boost': 0.5,
'shell': 0.3,
'banana': 0.2
}
elif relative_position < 0.5: # Middle pack
return {
'speed_boost': 0.3,
'shell': 0.3,
'star': 0.2,
'mushroom': 0.2
}
else: # Back of pack
return {
'bullet_bill': 0.2,
'star': 0.3,
'golden_mushroom': 0.3,
'blue_shell': 0.2 # Targets leader
}
Result: Leaders are threatened, but skill still matters. Close races feel exciting.
Example 3: Combat State Machine
Designing a fighting game character’s states:
States:
- NEUTRAL: Can move, block, or start attacks
- ATTACKING: Executing an attack, vulnerable after
- BLOCKING: Reduced damage, can't attack
- HIT_STUN: Just got hit, can't act
- KNOCKED_DOWN: On the ground, invulnerable
- GETTING_UP: Rising animation, vulnerable at end
Transitions:
NEUTRAL:
- attack button → ATTACKING
- block button → BLOCKING
- get hit → HIT_STUN
ATTACKING:
- attack animation ends → NEUTRAL (recovery)
- get hit during startup → HIT_STUN (counter hit!)
- attack connects → add hitlag, continue animation
BLOCKING:
- release block → NEUTRAL
- get hit while blocking → stay BLOCKING, take chip damage
- block broken → HIT_STUN
HIT_STUN:
- stun timer ends → NEUTRAL
- get hit again → reset stun (combo!)
- health = 0 → KNOCKED_DOWN
KNOCKED_DOWN:
- knockdown timer ends → GETTING_UP
GETTING_UP:
- animation ends → NEUTRAL
- invulnerability ends before animation → vulnerable window
Invalid Transitions (bugs to prevent):
- ATTACKING → BLOCKING (can't cancel attack with block)
- HIT_STUN → ATTACKING (can't attack while stunned)
- KNOCKED_DOWN → ATTACKING (can't attack from ground)
6. Hands-On Practice (30-40 minutes)
Exercise 1: Feedback Audit (10 minutes)
Objective: Identify feedback gaps in an existing game
Instructions:
- Choose a specific action in a game (jumping, attacking, purchasing)
- List ALL feedback that occurs for that action
- Identify the channel (visual/audio/haptic/UI)
- Rate importance (critical/helpful/nice-to-have)
- Identify any missing feedback that would improve the experience
Template:
Game: _______________
Action: _______________
Feedback Audit:
| Feedback | Channel | Timing | Importance | Notes |
|----------|---------|--------|------------|-------|
| | | | | |
Missing Feedback:
1. _______________
2. _______________
Exercise 2: Balance Feedback Loops (15 minutes)
Objective: Design balanced positive/negative feedback
Scenario: You’re designing a territory control game where players capture zones. Currently, whoever captures the most zones early always wins.
Requirements:
- Identify the positive feedback loop causing snowballing
- Design 2-3 negative feedback mechanisms to balance it
- Ensure negative feedback doesn’t eliminate skill advantage
- Explain how your design creates close, exciting matches
Constraints:
- Don’t punish winning players directly
- Maintain clear feedback on who’s winning
- Keep the game simple to understand
Exercise 3: State Machine Design (15 minutes)
Objective: Create a complete state machine
Challenge: Design a state machine for ONE of these:
Option A: Stealth Game Enemy AI States should include: Patrol, Alert, Searching, Combat, Returning
Option B: Shop/Inventory System States should include: Browsing, Inspecting Item, Purchasing, Selling, Inventory Full
Option C: Multiplayer Match Flow States should include: Lobby, Loading, Pre-game, Active Match, Post-game
Deliverables:
- List all states with brief descriptions
- Diagram transitions between states
- List events that trigger each transition
- Identify any invalid transitions to prevent
7. Common Pitfalls and Troubleshooting (10 minutes)
Frequent Mistakes
-
Problem: Feedback is too subtle for important events Cause: Designer knows what to look for; players don’t Solution: Playtest with new players, exaggerate critical feedback
-
Problem: Game feels “floaty” or unresponsive Cause: Missing or delayed immediate feedback Solution: Add hitlag, screen shake, instant visual/audio response
-
Problem: Matches feel predetermined after early game Cause: Too much positive feedback, not enough negative Solution: Add catch-up mechanics, cap advantage growth
-
Problem: Impossible states occur (attacking while stunned) Cause: State transitions not properly validated Solution: Review state machine, add transition guards
Debugging Tips
- Log state transitions: When does the bug occur?
- Test edge cases: What happens at state boundaries?
- Playtest with volume off: Is visual feedback sufficient?
- Playtest with eyes closed: Is audio feedback sufficient?
Warning Signs
| Symptom | Likely Problem | Check This |
|---|---|---|
| “Why did I die?” | Missing damage feedback | Health change, hit direction |
| Game feels “dead” | Insufficient feedback layers | Add particles, sound, screen effects |
| Snowballing wins | Too much positive feedback | Add catch-up mechanics |
| Stalemates | Too much negative feedback | Add decisive mechanics |
| Random bugs | Invalid state transitions | Review state machine diagram |
8. Best Practices and Professional Tips (5 minutes)
Industry Standards
- 60fps minimum: Feedback timing requires smooth framerate
- <100ms input lag: Any more feels unresponsive
- Redundant channels: Important info in 2+ channels
- Consistent language: Same feedback means same thing everywhere
Advanced Techniques
Feedforward: Show players what WILL happen before they commit:
- Trajectory lines for thrown objects
- Danger zones highlighted before attacks
- Preview of item effects before purchase
Contextual Feedback: Vary feedback based on game state:
- Low health: More urgent sounds, visual effects
- Near victory: Heightened music, tension
- Tutorial: Extra explanatory feedback
Implicit Feedback: Information conveyed without explicit UI:
- Enemies limp when low health
- Environment darkens in dangerous areas
- Music changes when enemies are alerted
Next Steps in Your Learning Journey
- Study “game feel” resources (Steve Swink’s book)
- Analyze fighting games’ state machines in detail
- Practice implementing feedback in small prototypes
- Study how competitive games balance feedback loops
9. Summary and Review (5 minutes)
Key Takeaways
- Feedback communicates through multiple channels - use all of them for important information
- Immediate feedback creates game feel - never delay it
- Positive and negative feedback loops must balance - too much of either is problematic
- State machines clarify game flow - use them to prevent bugs and communicate design
Quick Review Questions
- What’s the difference between positive and negative feedback loops?
- Why is immediate feedback crucial for game feel?
- What does a state machine help prevent?
- Name three channels through which games provide feedback.
For Instructors
Teaching Tips
- Use video clips to show feedback done well vs poorly
- Have students play the same game with sound on/off to compare
- Create simple state machines on whiteboard together
- Discuss ethical concerns of excessive positive feedback (addiction)
Assessment Ideas
- Feedback audit of an assigned game section
- State machine diagram for a game concept
- Essay on positive vs negative feedback in a competitive game
- Design document proposing feedback improvements
Adaptation Notes
- For beginners: Focus on immediate feedback and basic states
- For advanced students: Discuss dynamic difficulty, feedback graph analysis
- For programmers: Include implementation patterns for state machines
- For UX designers: Connect to usability heuristics and accessibility