Game Programming Patterns

Engine-agnostic pattern reference for game systems. Synthesized from Nystrom's Game Programming Patterns (gameprogrammingpatterns.com).

Relationship to engine skills: This skill provides the why and when. Your engine skill (e.g., godot, love2d, odin-gamedev) provides the idiomatic how. When both fire, the engine skill takes precedence on implementation details — use this skill to understand which pattern to reach for, then let the engine skill guide the concrete code.

Pattern Selection by Problem

"I need to decouple things"

Disambiguation: Observer vs Event Queue is the most common confusion. Use Observer when the response must happen now (UI updating a health bar on damage). Use Event Queue when the response can happen later (audio playing a sound next frame) or when you need to aggregate events (10 "footstep" events → 1 sound).

Jonathan Blow's counterpoint: An event queue is trivial to implement and often overrated. For scripted sequences, plain sequential code is clearer — put it on a thread if it must span frames. For "run a function when a variable changes," decide deliberately whether per-frame polling is acceptable and exactly when in the frame the reaction fires; code that reacts at an arbitrary time will crash in ways that are hard to reproduce.

"I need to structure entity behavior"

"I need to handle input or actions"

"I need performance"

Disambiguation: If your game has <100 entities and no measurable performance issue, skip this section. Profile first, pattern second.

"I need scripting or data-driven behavior"

"I need to manage time and sequencing"

Core Patterns — Start Here

For indie and hobbyist games, these five patterns solve the majority of architecture problems. Reach for these first before exploring the full catalog:

The remaining 18 patterns are situational — reach for them when you hit the specific problem they solve, not preemptively.

Pattern Combinations

Patterns rarely appear alone. These are the most common compositions:

When the agent recommends a pattern, consider whether a complementary pattern strengthens the design.

All 23 Patterns — Quick Reference

Design Patterns Revisited

Command — Encapsulates a request as an object. Enables rebindable input, undo/redo stacks, replay systems, and AI-driven actors. Reach for it whenever you need to parameterize, queue, or reverse actions. See references/design-patterns-revisited.md.

Flyweight — Shares a single copy of immutable data across many instances. Use when thousands of objects (trees, tiles, bullets) share identical intrinsic state. The shared object is stateless; per-instance data stays separate. See references/design-patterns-revisited.md.

Observer — Subject maintains a list of listeners and notifies them on events. Decouples producers (physics, gameplay) from consumers (UI, achievements, audio). Watch for the lapsed-listener problem in GC languages. See references/design-patterns-revisited.md.

Prototype — Clone an existing object to create new ones. In games, most useful as a data-driven archetype pattern: a JSON "template" object that instances copy from. Less useful as a pure OOP pattern. See references/design-patterns-revisited.md.

Singleton — Ensures one instance with global access. Widely overused in games. Prefer Service Locator or dependency injection. Use Singleton only when the single-instance constraint is a genuine invariant, not just convenience. See references/design-patterns-revisited.md.

State — Finite state machine where each state is an object that owns its behavior and transitions. Eliminates sprawling if/switch chains in entity update logic. Hierarchical and pushdown variants handle nested states and modal UIs. See references/design-patterns-revisited.md.

Sequencing Patterns

Double Buffer — Maintains two buffers; one is written while the other is read. Prevents tearing in rendering and physics. Engine note: your engine almost certainly implements this — understand it for debugging, don't implement it from scratch. See references/sequencing.md.

Game Loop — The heartbeat of every game: process input → update → render, decoupled from hardware speed. Fixed-update with variable render is the gold standard. Engine note: your engine owns this loop — understand it to use _process vs _physics_process correctly. See references/sequencing.md.

Update Method — Each entity owns an update(dt) method called once per frame. Simple, universal, but watch for order-of-update dependencies and the cost of virtual dispatch on thousands of objects. See references/sequencing.md.

Behavioral Patterns

Bytecode — Compiles behavior into instructions for a simple virtual machine. Use when designers need to author behavior without recompiling, or when sandboxing untrusted scripts. High implementation cost — only justified for moddable games or complex scripting needs. See references/behavioral.md.

Subclass Sandbox — Base class exposes a rich set of protected operations; subclasses implement behavior by composing them. Keeps subclasses from reaching into engine internals directly. Good for spell/ability systems with many variants. See references/behavioral.md.

Type Object — Separates "what kind of thing" from "this specific thing." A Monster instance holds a pointer to a MonsterType that defines stats, AI, and sprites. Enables data-driven entity definitions without a class per type. See references/behavioral.md.

Decoupling Patterns

Component — Splits a monolithic entity class into isolated domain components (physics, rendering, AI, input). Each component knows its domain; the entity is a thin container. Foundation of ECS architectures. Engine note: Unity's GetComponent, Godot's node tree implement this; Bevy implements full ECS (see below). See references/decoupling.md. Full ECS differs — see references/ecs-architecture.md.

Event Queue — Decouples event producers from consumers in time, not just structure. Events are buffered; consumers process them at their own pace. Solves the "slow observer" problem and enables cross-thread communication. See references/decoupling.md.

Service Locator — A registry that maps service interfaces to concrete implementations. Provides global access without hard-coding dependencies. Better than Singleton because the implementation is swappable (useful for null/test services). See references/decoupling.md.

ECS Architecture

ECS Architecture — Full Entity Component System: entities are bare integer IDs, components are plain data structs attached to entity IDs, and systems query and iterate component sets in bulk. Achieves cache-friendly performance (contiguous component arrays) and data-driven content scale (entity types defined in data files, no code change per new type). Use when you have profiled cache misses as a bottleneck in entity loops, OR when content breadth is large (100+ types) AND designers need to iterate without code changes AND your engine has no built-in component model. For most games, the simpler Component pattern suffices. See references/ecs-architecture.md.

Optimization Patterns

Data Locality — Restructures data for cache-friendly sequential access. Array-of-Structs → Struct-of-Arrays. Critical in hot loops (particle updates, physics ticks). Engine note: ECS engines (Bevy, Unity DOTS) enforce this automatically. See references/optimization.md.

Dirty Flag — Tracks whether derived data is stale. Recomputes only when the source data has changed and the derived value is actually needed. Use for world transforms, pathfinding caches, UI layout. See references/optimization.md.

Object Pool — Pre-allocates a fixed array of objects; "allocates" by marking one active, "frees" by marking it inactive. Eliminates heap churn for short-lived objects. Essential for bullets, particles, audio sources. See references/optimization.md.

Spatial Partition — Divides space into a structure (grid, quadtree, BSP, k-d tree) to reduce collision/query candidates from O(n²) to O(n log n) or better. Choose based on object density and movement frequency. See references/optimization.md.

Additional Patterns

Factory — Centralizes object construction. Decouples callers from concrete types; enables construction from data (string → class). Use when construction logic is complex or needs to vary. See references/additional-patterns.md.

Strategy — Swaps algorithm implementations behind a common interface. Use for pluggable AI behaviors, pathfinding algorithms, or serialization formats. Lighter than full inheritance hierarchies. See references/additional-patterns.md.

Decorator — Wraps an object to add behavior without subclassing. Use for composable item enchantments, status effects, or logging wrappers. Watch for deep wrapper chains becoming hard to debug. See references/additional-patterns.md.

Engine-Handles-This Flags

These patterns are worth understanding conceptually, but you should not implement them from scratch when using a game engine:

• Game Loop — Godot: _process/_physics_process. Unity: Update/FixedUpdate. Love2d: love.update.
• Double Buffer — Handled by the renderer. Understand it to debug vsync/tearing issues.
• Component — Godot nodes, Unity components (MonoBehaviour). Use the engine's system; don't roll your own.
• ECS — Bevy ECS, Unity DOTS implement full ECS. Use their built-in query/system APIs directly.
• Data Locality — Unity DOTS/ECS, Bevy ECS enforce this. In other engines, be aware of cache effects in hot loops.

References