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:
| Engine |
Model |
Entity |
Component |
System |
| Unity |
Component-Based |
GameObject |
MonoBehaviour |
Manager scripts or DOTS Systems |
| Unreal |
Actor-Component |
AActor |
UActorComponent |
Tick functions or Subsystems |
| Godot |
Node Tree |
Node |
Child Nodes |
_process/_physics_process |
| Three.js |
Scene Graph |
Object3D |
userData / custom classes |
Game loop update functions |
| Orleans |
Virtual Actor |
Grain |
Grain State / Interfaces |
Grain methods + Timers |
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:
| Engine |
Implementation |
| Unity |
ScriptableObject-based states, or Animator for simple cases |
| Unreal |
Gameplay Ability System, or custom UObject state classes |
| Godot |
Node-based states as children of StateMachine node |
| Three.js |
TypeScript classes with enter/exit/update methods |
| Orleans |
Grain state + explicit transitions in grain methods |
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:
| Engine |
Mechanism |
| Unity |
C# events, UnityEvent, ScriptableObject event channels |
| Unreal |
Delegates (DECLARE_DELEGATE), BlueprintAssignable events |
| Godot |
Signals (built-in, first-class) |
| Three.js |
EventDispatcher, custom EventEmitter, or RxJS |
| Orleans |
Orleans Streams, IGrainObserver |
Object Pooling
Avoid allocation/deallocation overhead for frequently created objects:
| Engine |
Strategy |
| Unity |
Queue, SetActive(true/false) |
| Unreal |
FActorPoolingSystem or custom TArray<AActor*> pool |
| Godot |
Array of nodes, set visible/process_mode |
| Three.js |
Array of Object3D, toggle visible property |
| Orleans |
Not applicable (grains are virtual, always "exist") |
When to pool: Projectiles, particles, enemies, VFX, UI elements - anything created/destroyed frequently during gameplay.
Networking Models
| Engine |
Built-in |
Model |
| Unity |
Netcode for GameObjects, Mirror, FishNet |
Server-authoritative, client prediction |
| Unreal |
Built-in replication |
Server-authoritative, property replication, RPCs |
| Godot |
MultiplayerPeer, MultiplayerSynchronizer |
Server-authoritative or peer-to-peer |
| Three.js |
None (use WebSocket/WebRTC) |
Custom, typically server-authoritative |
| Orleans |
Built-in (virtual actors) |
Server-authoritative by design |
Core multiplayer principles:
- Server is authoritative - never trust client state
- Client predicts locally for responsiveness
- Server reconciles and corrects client state
- Use delta compression to minimize bandwidth
- Handle disconnection and reconnection gracefully
Save/Load Patterns
| Engine |
Strategy |
| Unity |
JsonUtility or custom serialization to PlayerPrefs/files |
| Unreal |
USaveGame with UGameplayStatics::SaveGameToSlot |
| Godot |
ConfigFile or custom JSON/Resource serialization |
| Three.js |
JSON serialization to localStorage or server API |
| Orleans |
Built-in grain persistence (automatic with IPersistentState) |
Input Abstraction
| Engine |
System |
| Unity |
New Input System (InputAction) or legacy Input class |
| Unreal |
Enhanced Input System (UInputAction, UInputMappingContext) |
| Godot |
InputMap with named actions, Input.is_action_pressed() |
| Three.js |
Custom abstraction over DOM events (keyboard, mouse, gamepad API) |
Best practice: Map physical inputs to semantic actions ("jump", "attack", "interact"), never check raw keys in gameplay code.
Audio Architecture
| Engine |
System |
| Unity |
AudioSource + AudioListener, FMOD/Wwise for complex projects |
| Unreal |
Sound Cues, MetaSounds (UE5), Wwise integration |
| Godot |
AudioStreamPlayer2D/3D, AudioBus system |
| Three.js |
Three.js AudioListener + PositionalAudio, or Howler.js |
Physics
| Engine |
System |
2D |
3D |
| Unity |
PhysX (3D), Box2D (2D) |
Rigidbody2D, Collider2D |
Rigidbody, Collider |
| Unreal |
Chaos Physics |
N/A (use Paper2D) |
UPrimitiveComponent physics |
| Godot |
GodotPhysics, Jolt |
RigidBody2D, Area2D |
RigidBody3D, Area3D |
| Three.js |
None built-in |
cannon-es, rapier2d |
rapier3d, ammo.js |
UI Architecture
| Engine |
System |
Technology |
| Unity |
UGUI (Canvas) or UI Toolkit |
C# + XML (UI Toolkit) or Inspector-based |
| Unreal |
UMG (Unreal Motion Graphics) |
Blueprints + Slate (C++) |
| Godot |
Control nodes (built-in) |
Theme resources + GDScript |
| Three.js |
HTML/CSS overlay or drei/Html |
React components or DOM |
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
1---2name: engine-patterns3description: Cross-engine design pattern comparison for game development including ECS, state machines, networking, and common architectures4---5
6# Cross-Engine Design Patterns
7
8A reference for implementing common game patterns across different engines. Use this when deciding on architecture or translating patterns between engines.
9
10## Entity-Component-System (ECS)
11
12How game objects are structured varies by engine:
13
14| Engine | Model | Entity | Component | System |
15|--------|-------|--------|-----------|--------|
16| Unity | Component-Based | GameObject | MonoBehaviour | Manager scripts or DOTS Systems |
17| Unreal | Actor-Component | AActor | UActorComponent | Tick functions or Subsystems |
18| Godot | Node Tree | Node | Child Nodes | _process/_physics_process |
19| Three.js | Scene Graph | Object3D | userData / custom classes | Game loop update functions |
20| Orleans | Virtual Actor | Grain | Grain State / Interfaces | Grain methods + Timers |
21
22**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.
23
24## State Machines
25
26Every engine needs state machines for entities, game flow, and UI:
27
28| Engine | Implementation |
29|--------|---------------|
30| Unity | ScriptableObject-based states, or Animator for simple cases |
31| Unreal | Gameplay Ability System, or custom UObject state classes |
32| Godot | Node-based states as children of StateMachine node |
33| Three.js | TypeScript classes with enter/exit/update methods |
34| Orleans | Grain state + explicit transitions in grain methods |
35
36**Core pattern** (all engines):
37```
38State {
39 enter() // Called when entering this state
40 exit() // Called when leaving this state
41 update(dt) // Called every frame while in this state
42}
43
44StateMachine {
45 currentState: State
46 transition(newState) {
47 currentState.exit()
48 newState.enter()
49 currentState = newState
50 }
51}
52```
53
54## Observer/Event Pattern
55
56Decoupled communication between systems:
57
58| Engine | Mechanism |
59|--------|-----------|
60| Unity | C# events, UnityEvent, ScriptableObject event channels |
61| Unreal | Delegates (DECLARE_DELEGATE), BlueprintAssignable events |
62| Godot | Signals (built-in, first-class) |
63| Three.js | EventDispatcher, custom EventEmitter, or RxJS |
64| Orleans | Orleans Streams, IGrainObserver |
65
66## Object Pooling
67
68Avoid allocation/deallocation overhead for frequently created objects:
69
70| Engine | Strategy |
71|--------|----------|
72| Unity | Queue<GameObject>, SetActive(true/false) |
73| Unreal | FActorPoolingSystem or custom TArray<AActor*> pool |
74| Godot | Array of nodes, set visible/process_mode |
75| Three.js | Array of Object3D, toggle visible property |
76| Orleans | Not applicable (grains are virtual, always "exist") |
77
78**When to pool**: Projectiles, particles, enemies, VFX, UI elements - anything created/destroyed frequently during gameplay.
79
80## Networking Models
81
82| Engine | Built-in | Model |
83|--------|----------|-------|
84| Unity | Netcode for GameObjects, Mirror, FishNet | Server-authoritative, client prediction |
85| Unreal | Built-in replication | Server-authoritative, property replication, RPCs |
86| Godot | MultiplayerPeer, MultiplayerSynchronizer | Server-authoritative or peer-to-peer |
87| Three.js | None (use WebSocket/WebRTC) | Custom, typically server-authoritative |
88| Orleans | Built-in (virtual actors) | Server-authoritative by design |
89
90**Core multiplayer principles**:
911. Server is authoritative - never trust client state
922. Client predicts locally for responsiveness
933. Server reconciles and corrects client state
944. Use delta compression to minimize bandwidth
955. Handle disconnection and reconnection gracefully
96
97## Save/Load Patterns
98
99| Engine | Strategy |
100|--------|----------|
101| Unity | JsonUtility or custom serialization to PlayerPrefs/files |
102| Unreal | USaveGame with UGameplayStatics::SaveGameToSlot |
103| Godot | ConfigFile or custom JSON/Resource serialization |
104| Three.js | JSON serialization to localStorage or server API |
105| Orleans | Built-in grain persistence (automatic with IPersistentState) |
106
107## Input Abstraction
108
109| Engine | System |
110|--------|--------|
111| Unity | New Input System (InputAction) or legacy Input class |
112| Unreal | Enhanced Input System (UInputAction, UInputMappingContext) |
113| Godot | InputMap with named actions, Input.is_action_pressed() |
114| Three.js | Custom abstraction over DOM events (keyboard, mouse, gamepad API) |
115
116**Best practice**: Map physical inputs to semantic actions ("jump", "attack", "interact"), never check raw keys in gameplay code.
117
118## Audio Architecture
119
120| Engine | System |
121|--------|--------|
122| Unity | AudioSource + AudioListener, FMOD/Wwise for complex projects |
123| Unreal | Sound Cues, MetaSounds (UE5), Wwise integration |
124| Godot | AudioStreamPlayer2D/3D, AudioBus system |
125| Three.js | Three.js AudioListener + PositionalAudio, or Howler.js |
126
127## Physics
128
129| Engine | System | 2D | 3D |
130|--------|--------|----|----|
131| Unity | PhysX (3D), Box2D (2D) | Rigidbody2D, Collider2D | Rigidbody, Collider |
132| Unreal | Chaos Physics | N/A (use Paper2D) | UPrimitiveComponent physics |
133| Godot | GodotPhysics, Jolt | RigidBody2D, Area2D | RigidBody3D, Area3D |
134| Three.js | None built-in | cannon-es, rapier2d | rapier3d, ammo.js |
135
136## UI Architecture
137
138| Engine | System | Technology |
139|--------|--------|-----------|
140| Unity | UGUI (Canvas) or UI Toolkit | C# + XML (UI Toolkit) or Inspector-based |
141| Unreal | UMG (Unreal Motion Graphics) | Blueprints + Slate (C++) |
142| Godot | Control nodes (built-in) | Theme resources + GDScript |
143| Three.js | HTML/CSS overlay or drei/Html | React components or DOM |
144
145## Pattern Selection Guide
146
147**For new projects, consider**:
148- Start with the engine's native patterns before adding frameworks
149- Only add ECS when you have measurable performance needs
150- Use the engine's built-in networking before rolling your own
151- Prefer data-driven design for anything designers need to tune
152- Keep architecture as simple as possible for the game's actual needs
monumentalsystems