| name | game-design-patterns |
| version | 0.1.0 |
| description | Use this skill when implementing game programming patterns - state machines for character/AI behavior, object pooling for performance-critical spawning, event systems for decoupled game communication, or the command pattern for input handling, undo/redo, and replays. Triggers on game architecture, game loop design, entity management, finite state machines, object pools, observer/event bus, command queues, and gameplay programming patterns.
|
| tags | ["game-dev","design-patterns","state-machine","object-pool","event-system","command-pattern","experimental-design","performance"] |
| category | engineering |
| recommended_skills | ["unity-development","game-balancing","clean-architecture"] |
| platforms | ["claude-code","gemini-cli","openai-codex","mcp"] |
| license | MIT |
| maintainers | [{"github":"maddhruv"}] |
Key principles
-
Frame budget is law - Every pattern choice must respect the ~16ms frame budget.
Allocations during gameplay cause GC spikes. Indirection has cache costs. Always
profile before adding abstraction.
-
Decouple, but not infinitely - Game systems should communicate through events
and commands rather than direct references, but over-decoupling creates debugging
nightmares. One level of indirection is usually enough.
-
State is explicit - Implicit state (nested boolean flags, mode integers) leads
to impossible combinations and subtle bugs. Make every valid state a first-class
object with defined transitions.
-
Pool what you spawn - Any entity created and destroyed more than once per
second should be pooled. The cost of allocation is not the constructor - it is the
garbage collector pause 3 seconds later.
-
Commands are data - When input actions are objects rather than direct method
calls, you get undo, replay, networking, and AI "for free." The command pattern
is the single highest-leverage pattern in gameplay code.
Core concepts
State machines model entities that have distinct behavioral modes. A character
can be Idle, Running, Jumping, or Attacking - but never Jumping and Idle at the same
time. Each state encapsulates its own update logic, entry/exit behavior, and valid
transitions. Hierarchical state machines (HFSM) add nested sub-states for complex AI.
Object pooling pre-allocates a fixed set of objects and recycles them instead of
creating and destroying instances at runtime. The pool maintains an "available" list
and hands out pre-initialized objects on request, reclaiming them when they are
"killed." This eliminates allocation pressure during gameplay.
Event systems (also called observer, pub/sub, or message bus) let game systems
communicate without direct references. When a player takes damage, the health system
fires a DamageTaken event. The UI, audio, camera shake, and analytics systems each
subscribe independently. Adding a new reaction requires zero changes to the damage code.
The command pattern encapsulates an action as an object with execute() and
optionally undo(). Player input becomes a stream of command objects. This enables
input rebinding, replay recording, undo/redo in editors, and sending commands over
the network for multiplayer.
Common tasks
Implement a finite state machine for character behavior
Each state is a class with enter(), , , and a transition check.
The machine holds the current state and delegates to it.
