Foundations
Architecture
Performance
Frameworks
Implementations
Foundations of ECS
This section introduces the core principles of the Entity Component System (ECS) architecture.
We’ll explore the fundamental building blocks—Entities, Components, and Systems—and understand
the paradigm shift from traditional Object-Oriented Programming (OOP) towards a more flexible,
data-oriented design. This foundation is key to grasping the performance and modularity benefits
of ECS.
🆔
Entity
A simple ID. It has no logic—just a handle for attaching components.
📦
Component
Pure data (e.g., Position, Health). No methods—just state.
🧠
System
Pure logic—code that operates on entities with specific components.
Architectural Design
Effective ECS architecture hinges on thoughtful design of its core parts. This section explores
crucial design considerations for components and systems, including how to manage their scope,
ensure data purity, and facilitate communication between them. We also cover strategies for
handling global data that doesn’t naturally fit within individual entities.
Component Design
- Granularity: Components should be small and focused. Too large, and you lose composition benefits; too small, and you create unnecessary complexity.
- Data Purity: Components must contain only data, no logic or methods. This separation is key to the entire ECS pattern.
- Reusability: Design components to be general-purpose so they can be combined in novel ways to create new entity types.
System Design
- Single Responsibility: Each system should perform one specific task (e.g., MovementSystem, DamageSystem).
- Execution Order: The order systems run in is critical. A PhysicsSystem must run before a MovementSystem. Manage this with explicit ordering or dependency graphs.
- Communication: Systems communicate indirectly by modifying component data. For discrete events (e.g., ‘PlayerDied’), an Event System is often used to maintain decoupling.
One of the primary reasons to adopt ECS is for performance. Here, we compare two memory layouts:
AoS (Array of Structures) vs. SoA (Structure of Arrays). You’ll see why SoA is far more cache-friendly.
Memory Layout: AoS vs. SoA
Array of Structures (AoS) – Inefficient
Entity 1: [Position, Velocity, Health]
Entity 2: [Position, Velocity, Health]
Entity 3: [Position, Velocity, Health]
A system updating only “Position” must load and then discard all other component data for each entity.
Structure of Arrays (SoA) – Efficient
Positions: [Pos 1, Pos 2, Pos 3]
Velocities: [Vel 1, Vel 2, Vel 3]
Healths: [Health 1, Health 2, Health 3]
A system updating positions reads only the “Positions” array sequentially—maximizing cache usage.
Framework Comparison
The ECS landscape is rich with open-source frameworks in C#, C++, and Rust. Below is a static table showing
relative scores (out of 10) for key criteria. Hover effects and radar charts aren’t possible here, but
this table gives you the same data at a glance.
| Framework |
Performance |
API Ergonomics |
Feature Set |
Ecosystem |
Parallelism |
Debug Tools |
| Unity DOTS (C#) |
9 |
6 |
8 |
9 |
10 |
8 |
| EnTT (C++) |
10 |
7 |
9 |
7 |
7 |
5 |
| Flecs (C++) |
9 |
8 |
10 |
8 |
8 |
9 |
| Bevy ECS (Rust) |
8 |
9 |
8 |
8 |
9 |
7 |
Practical Implementations
Theory is one thing—how does ECS apply to real-world game systems? Below are examples of Movement/Combat,
AI/Behavior, Player/UI, Inventory/Crafting, and Networking. Each “card” shows which components and systems
you might define in an ECS for that feature.
Core Gameplay: Movement & Combat
Movement/Physics System
Components:
- TransformComponent (pos, rot, scale)
- VelocityComponent (linear, angular)
- CollisionComponent (shape, material)
- RigidBodyComponent (mass, drag)
Systems:
PhysicsSystem: Detects and resolves collisions.MovementSystem: Applies velocity to transform.
Combat/Health System
Components:
- HealthComponent (current, max)
- WeaponComponent (damage, range)
- ArmorComponent (defense)
- AttackActionComponent (tag)
Systems:
CombatSystem: Resolves attacks, calculates damage.HealthSystem: Applies damage/healing, checks for death.
AI & Behavior: Decision Making & Pathfinding
Decision Making (Behavior Tree)
Components:
- AIComponent (personality)
- PerceptionComponent (sensed entities)
- BehaviorTreeComponent (runtime state)
- GoalComponent (current objective)
Systems:
PerceptionSystem: Updates what the AI sees/hears.BehaviorTreeSystem: Executes the BT logic.
Pathfinding System
Components:
- PathRequestComponent (target pos)
- PathResultComponent (waypoints)
- MovementComponent (to follow path)
Systems:
PathRequestSystem: Initiates path calculations.PathFollowingSystem: Moves the entity along the path.
Player & UI: Input & Inventory
Input & UI Systems
Components:
- PlayerInputComponent (moveVector, actions)
- (Hybrid) UI is managed by traditional OOP code, not ECS components.
Systems:
InputSystem: Reads hardware and updates PlayerInputComponent.UISystem: Reads ECS data (e.g., Health) and updates traditional UI elements.
Inventory & Crafting Systems
Components:
- InventoryComponent (item list, capacity)
- ItemComponent (itemID, stackSize)
- CraftingRecipeComponent (ingredients, output)
Systems:
InventorySystem: Adds/removes items from inventory.CraftingSystem: Checks recipes and inventory, then crafts items.
Networking: Synchronization & Prediction
Synchronization System
Components:
- NetworkIDComponent (unique across network)
- SynchronizedComponent (tags data to be sent)
Systems:
StateSnapshotSystem (Server): Captures state of synced entities.StateApplySystem (Client): Applies snapshots to remote entities (with interpolation).
Client Prediction & Reconciliation
Components:
- InputHistoryComponent (client-side buffer)
- PredictedGhostComponent (for predicted entities)
Systems:
ClientPredictionSystem: Runs player logic immediately on the client.ServerReconciliationSystem: Corrects local state once the server’s authoritative update arrives.
Roaming Wild Gaming Blog 