Cross-Engine Design Patterns

A reference for implementing common game patterns across different engines. Use this when deciding on architecture or translating patterns between engines.

Entity-Component-System (ECS)

How game objects are structured varies by engine:

When to use full ECS: Performance-critical systems with thousands of entities (Unity DOTS, custom ECS). For most gameplay, the engine's native component model is sufficient.

State Machines

Every engine needs state machines for entities, game flow, and UI:

Core pattern (all engines):

State {
  enter()    // Called when entering this state
  exit()     // Called when leaving this state
  update(dt) // Called every frame while in this state
}

StateMachine {
  currentState: State
  transition(newState) {
    currentState.exit()
    newState.enter()
    currentState = newState
  }
}

Observer/Event Pattern

Decoupled communication between systems:

Object Pooling

Avoid allocation/deallocation overhead for frequently created objects:

When to pool: Projectiles, particles, enemies, VFX, UI elements - anything created/destroyed frequently during gameplay.

Networking Models

Core multiplayer principles:

1. •Server is authoritative - never trust client state
2. •Client predicts locally for responsiveness
3. •Server reconciles and corrects client state
4. •Use delta compression to minimize bandwidth
5. •Handle disconnection and reconnection gracefully

Save/Load Patterns

Input Abstraction

Best practice: Map physical inputs to semantic actions ("jump", "attack", "interact"), never check raw keys in gameplay code.

Audio Architecture

Physics

UI Architecture

Pattern Selection Guide

For new projects, consider:

• •Start with the engine's native patterns before adding frameworks
• •Only add ECS when you have measurable performance needs
• •Use the engine's built-in networking before rolling your own
• •Prefer data-driven design for anything designers need to tune
• •Keep architecture as simple as possible for the game's actual needs