Lecture 8: Game Project Planning

Game Project Planning Day

From Blade Racer to Your Vision

CSCI 3213 - Game Programming

Spring 2026 ā€” Lecture 8

No code today. Just ideas, patterns, and your imagination.

šŸ“‹ Today is Different

Put the IDE Away

No Unity. No C#. No compiler errors.

Today we slow down, catch our breath, and start thinking about the most important question in game design:

"What game do I want to make?"

The agenda: Review the patterns, look at a real planning example, and start mapping your own game. Take notes ā€” this time counts.

šŸ›‘ Why We're Pausing

1. You've learned a lot

Seven patterns in seven lectures. Let's make sure they're connecting before adding more.

2. Your midterm is coming up

Reviewing patterns through the lens of your own game is the most effective way to internalize them.

3. Your project starts soon

Good architecture takes time. The earlier you start planning, the better your game will be.

4. Patterns don't live in isolation

In Blade Racer we introduced them one at a time. In your game they'll all coexist and interact.

šŸ“ Midterm Preview

šŸ“… Midterm: Tuesday, March 10, 2026

Covers all 13 design patterns and their implementation in Blade Racer.

What to Study

  • Each pattern's intent ā€” what problem does it solve?
  • How Blade Racer used it ā€” specific classes and systems
  • The key participants ā€” e.g. Subject/Observer, Visitor/Visitable
  • The trade-offs ā€” when NOT to use a pattern
Best prep: Can you explain each pattern to a rubber duck? Can you sketch the class diagram? Start there. Today's planning exercise is literally midterm practice.

šŸŽ® The Project Assignment

The Only Requirement

Create a Unity game that uses all but 2 of the 13 design patterns we implemented in Blade Racer.

It doesn't have to use them the same way we did.

āœ… Fair Game

  • Any genre or theme
  • Creative pattern usage
  • Adapted to your game's needs

āš ļø The Expectation

  • Must use 11 of the 13 patterns
  • Usage must be intentional
  • You'll explain your choices

šŸ—ŗļø The 13 Patterns of Blade Racer

Pattern Type Blade Racer Usage
Singleton Creational GameManager ā€” global persistence across scenes
State Behavioral BikeController states (Stop / Start / Turn / Crash)
Event Bus Service RaceEventBus ā€” decoupled game-wide events
Object Pool Creational Drone spawning and recycling
Command Behavioral Bike input recording and replay
Observer Behavioral BikeController ā†’ HUD, Camera, Audio
Visitor Behavioral Power-up system visiting bike components
Strategy Behavioral Enemy drone AI attack behaviors
Decorator Structural Weapon upgrades (Injector, Stabilizer, Cooler)
Spatial Partition Structural Level editor grid, collision optimization
Adapter Structural Third-party inventory integration
Facade Structural Simplified bike engine interface
Service Locator Service Unity services (Analytics, Audio, Logging)

āš”ļø The Challenge

13 patterns learned in Blade Racer

ā†“

Your game must use at least 11 of them

ā†“

You choose which 2 to skip ā€” and you'll justify that choice

Remember: Patterns should serve your game ā€” not the other way around. If a pattern doesn't fit naturally, skipping it is the right call. But make sure you've really thought it through.

šŸƒ Professor's Example

Cards in the Apocalypse

An action card game where you play Go Fish while dodging debris from a nearby planet's destruction.

šŸš€ Space Layer

Navigate your ship through a debris field. Collect supplies. Encounter and intercept enemy ships.

šŸƒ Card Layer

Dock with enemies for a high-stakes card duel. Play Go Fish to earn resources and survive.

Design philosophy: Two completely different gameplay systems sharing the same universe ā€” connected through patterns.

šŸŽØ Design Sketches

Card game UI mockup
Card game UI ā€” hand, opponent screen, debris dodging
Card game concept ā€” go fish
Card game concept ā€” Win Game or Survive / Go Fish mechanic
Ship design sketch
Ship design ā€” Bridge, HAB, game room, thruster
Coding roadmap ā€” all patterns mapped
Coding roadmap ā€” pattern mapping for all systems

šŸŒŒ World Building ā€” Lore Notes

World 1 ā€” The Cage
World 1 ā€” The Cage (chain-link wire, spatial partition zone)
World 2 ā€” Lore
World 2 ā€” How players learned to fight back
World 3 ā€” Origin of Cards in the Apocalypse
World 3 ā€” Origin of "Cards in the Apocalypse"
World 4 ā€” Rules from Lore
World 4 ā€” Rules from Lore

Bonus ā€” If You Want the Full Story

The World of
Cards in the Apocalypse

These are the lore notes sketched out this morning. Not required reading ā€” but it's more fun when you know why everyone is playing cards in space.

World 1 ā€” The Cage

They throw these cages up anywhere.
Any sector around any body.

Assholes.

Design note: The cage is the Spatial Partition zone. The lore explains the mechanic ā€” "they" (the antagonists) impose a bounded area of space. The cage is the game board.

World 2 ā€” Fighting Back

Eventually, we figured out that we could drive into them, shoot them, nuke them...
No dice. They wouldn't hold our ship, but they slowed us down enough to lock us in a local space.

Then came Spurtitch. Ashde. Went crazy after 2 years being trapped ā€” and shot them down.
Everyone...

Design note: Spurtitch is the inciting historical figure ā€” the first person to destroy a cage. The consequences set up the entire world state 200 years later.

World 3 ā€” The Opening

...And the cage opened. Just dissolved. And the moon came back ā€”
as if they just rewound time and their destruction.
Even other destroyed ships came back with no damage...
But no crew.

So. Spurtitch got countless ships and his own terraformed moon planet.
This brought out the worst of people. Of things.

Anyways ā€” that was 200 years ago. Now we are civilized,
and we call our practice:

CARDS IN THE APOCALYPSE

World 4 ā€” Rules from Lore

  1. They cage us and detonate any bodies in the cage.
  2. We connect and play cards in this mess.
  3. If you live, you win. If you lose, your ship detonates.
    (They made cheating impossible.)
    If debris destroys your ship, you die.
  4. Last one alive owns everything.
Design note: These four rules are the entire game loop. Stakes, mechanic, win condition, death condition ā€” all embedded in the world's history. The lore is the design doc.

ā™Ÿļø Singleton USED

Blade Racer ā†’ Cards in the Apocalypse

"No change from Blade Racer."

In Blade Racer

GameManager persisted across scenes and provided global access to game state.

In Cards in the Apocalypse

GameManager persists across both gameplay layers (space + card duel) and manages transitions between them.

Lesson: Some patterns are so foundational you use them the same way in every game. A global GameManager as a Singleton is nearly universal.

šŸ”„ State USED

In Blade Racer

  • BikeController states
  • Stop / Start / Turn / Crash
  • Physical movement behaviors

In Cards in the Apocalypse

  • Card Animations: Idle, Draw, Play, Discard, Win, Lose
  • Ship State: Cruising, Evading, Docked, Damaged, Destroyed
Creative adaptation: State machines aren't just for movement. Anything with distinct behavioral modes ā€” card animations, vehicle status ā€” fits perfectly.

šŸ“” Event Bus USED

In Blade Racer

  • RaceEventBus
  • Race start / end / checkpoint events
  • Decoupled scoring from race logic

In Cards in the Apocalypse

  • Card Game State: CardDrawn, CardPlayed, TurnEnd, DuelStart, DuelEnd
  • Decouples card logic from ship logic
  • Both gameplay layers listen to the same bus
Why this works: With two distinct gameplay layers, the Event Bus is ideal for communicating state changes between them without tight coupling.

šŸ” Object Pool USED

In Blade Racer

  • Drone enemies spawned from pool
  • Recycled when destroyed
  • Reduced garbage collection pressure

In Cards in the Apocalypse

  • šŸŒŸ Particle effects: Explosions, debris hits, engine trails
  • šŸš€ Enemy spawner: Hostile ships recycled from pool
  • šŸ“¦ Supply spawner: Rations, fuel rods, water ice reused
Three pools, one pattern: Splitting responsibilities by category keeps things organized while sharing the same pooling mechanism.

ā­ļø Command SKIPPED

Design Decision: Skipping Command

Command in Blade Racer handled input recording and replay ā€” a great fit for a racing game with a defined track. Cards in the Apocalypse has no replay system.

Why Skip It?

  • No replay or undo system needed in this game
  • Card input is event-driven ā€” Observer handles it cleanly
  • Forcing Command here would add complexity with no benefit
Lesson: Choosing NOT to use a pattern is a valid architectural decision. Forcing patterns into places they don't fit produces worse code than skipping them.

šŸ‘€ Observer USED

In Blade Racer

  • BikeController = Subject
  • HUDController, AudioController = Observers
  • State changes trigger UI + audio reactions

In Cards in the Apocalypse

  • HUD: Ship health, card count, fuel levels update via Observer
  • Audio: Music transitions between space combat and card duel based on game state
Like Blade Racer: HUD and audio systems should never be tightly coupled to game logic. Observer keeps them clean, decoupled, and swappable.

šŸ›ø Visitor USED

In Blade Racer

  • PowerUp visits bike components
  • Visits Engine, Shield, Weapon
  • Adds stat boosts without modifying classes

In Cards in the Apocalypse

Supplies collected during the space phase visit ship components before the card duel:

  • šŸ– Rations ā†’ visit crew health
  • āš” Fuel Rods ā†’ visit engine efficiency
  • šŸ’§ Water Ice ā†’ visit life support systems
Clean analogy: The supply collection phase directly mirrors the power-up system ā€” different supply types visiting different ship subsystems.

šŸ§  Strategy USED

In Blade Racer

  • Enemy drone AI behaviors
  • Aggressive / Defensive / Flanking
  • Swappable algorithms at runtime

In Cards in the Apocalypse

  • Enemy Ship AI: Intercept, Ambush, Retreat strategies during space phase
  • Enemy Card AI: Aggressive (ask early), Conservative (hoard sets), Bluff strategies during card duel
Double use: Strategy appears in both gameplay layers ā€” different algorithms for space combat AI and card game AI. Same pattern, two completely different contexts. Elegant.

šŸŽ“ Decorator USED

In Blade Racer

  • Weapon upgrades (Injector, Stabilizer, Cooler)
  • Each decorator wraps the base weapon
  • Stack multiple upgrades dynamically

In Cards in the Apocalypse

  • Card upgrades ā€” decorate base cards with effects
  • A "Go Fish" card wrapped with a +1 Draw decorator
  • Cards wrapped with: Stealth, Double Value, Shield Break
  • Upgrade stacking mirrors the weapon system exactly
Perfect fit: Card games love stackable modifiers. Decorator is a natural choice ā€” wrap a base card with any number of effects without changing the card class itself.

šŸ—ŗļø Spatial Partition USED

In Blade Racer

  • Level editor grid
  • Efficient collision detection
  • Stack-based segment loading

In Cards in the Apocalypse

  • Cage Builder: The debris field is divided into spatial zones
  • Each zone tracks its debris objects
  • Only check collisions within the player's current zone(s)
  • Escape the "cage" of nearby danger ā€” survive long enough to reach an enemy ship
Scaling insight: A debris field could have hundreds of objects. Without spatial partitioning, collision checks are O(nĀ²). With it, you only check what's nearby.

šŸ”Œ Adapter USED

In Blade Racer

  • Third-party inventory integration
  • Wrapped incompatible API in our interface
  • Game code talks to the adapter, not the library

In Cards in the Apocalypse

  • Inventory system: Supplies collected in space (rations, fuel rods, water ice) are stored in inventory
  • Adapter wraps whatever inventory library we use
  • Game systems interact through our own clean interface
Future-proof: By wrapping inventory behind an adapter, you can swap the underlying system without touching any other game code.

šŸ›ļø Facade USED

In Blade Racer

  • Simplified bike engine interface
  • One method hides complex subsystem calls
  • Client code stays clean

In Cards in the Apocalypse

  • Ship Hab (habitat module) ā€” masks the complexity of systems affecting crew performance
  • ShipHab.GetCrewPerformance() hides: oxygen, temperature, radiation, morale, nutrition
  • Card AI and game logic use one clean, usable value
Elegant complexity: Five different systems affect crew performance. The Facade collapses this into a single interface without exposing the internals to everything that needs it.

šŸ“ Service Locator USED

In Blade Racer

  • Unity services integration
  • Analytics, Audio, Logging registered as services
  • Game retrieves services without direct dependency

In Cards in the Apocalypse

  • Platform achievements ā€” unlock on any platform
  • šŸ–„ļø Steam Achievements on PC ā†’ one service
  • šŸŽ® PlayStation Trophies on PS5 ā†’ different service, same interface
  • AchievementService.Unlock("FirstDuel") ā€” write once, run anywhere
Platform flexibility: Service Locator is perfect here ā€” same achievement calls, different platform services registered at startup. True write-once, run-on-Steam-and-PlayStation.

šŸ“Š Cards in the Apocalypse ā€” Full Pattern Map

Pattern Status Usage in Cards in the Apocalypse
Singleton USED GameManager ā€” same as Blade Racer
State USED Card animations + ship state machine
Event Bus USED Card game state events between gameplay layers
Object Pool USED Particle effects, enemy ships, supply objects
Command SKIPPED No replay system ā€” not a natural fit
Observer USED HUD updates + audio transitions
Visitor USED Supply items (rations, fuel, water ice) visit ship systems
Strategy USED Enemy ship AI + enemy card game AI
Decorator USED Card upgrades ā€” stackable effect wrapping
Spatial Partition USED Debris field zone management (Cage Builder)
Adapter USED Inventory system abstraction
Facade USED Ship Hab ā€” crew performance interface
Service Locator USED Steam Achievements / PlayStation Trophies
Result: 12 of 13 patterns used. 1 intentionally skipped (Command). Exceeds the "all but 2" requirement.

āœļø Now It's Your Turn

Planning Exercise ā€” Take Notes Now

Use the professor's example as a template. Answer these questions for your own game.

šŸŽ® Your Game Concept

  • Genre and theme?
  • What's the core mechanic?
  • 2-sentence pitch

ā­ļø Which 2 Are You Skipping?

  • Which 2 don't fit naturally?
  • Can you justify each skip?
  • Is this the right call?

šŸ—ļø Major Systems

  • What are your main game systems?
  • How do they communicate?
  • Where are the boundaries?

šŸ§© Pattern Mapping

  • List all 11+ patterns you'll use
  • One sentence each:
    "I'll use X for Y because Z"

šŸ“š Midterm Prep Tips

1. Know the "why," not just the "what"

What problem does each pattern solve? That's more important than memorizing a class diagram.

2. Know the Blade Racer implementation

Be able to name the key classes (e.g. "Observer: BikeController as Subject, HUDController and AudioController as Observers").

3. Know the trade-offs

Every pattern has costs. When should you NOT use it? What's the alternative? These show up on exams.

4. Practice applying patterns to new contexts

The midterm may ask: "How would you use pattern X in [hypothetical game]?" Today's exercise is exactly this.

Best study method: Use your own game plan as study material. Explain each pattern you're using ā€” why that pattern, for that system, in your game.

šŸ‘‹ See You Next Class

We return to coding with the Visitor Pattern

Implementing supply pickups in Blade Racer using the Visitor pattern ā€” a direct preview of how it works in Cards in the Apocalypse.

Before Next Class

  • Review Observer Pattern slides
  • Read Chapter 10 (Visitor) in the textbook
  • Keep working on your game concept notes

Midterm Countdown

  • šŸ“… Midterm: March 10, 2026
  • 6 more patterns still to cover
  • Use your planning doc as a study guide