Entity-Component-System

The data-oriented backbone of the Antares Simulation Engine

Overview

The {{ECS}} pattern separates data (Components) from logic (Systems). Entities are just IDs — lightweight handles into the {{Hub}} data layer.

See [[feat/net|Multiplayer]] for how ECS state is replicated.

Components = Data Only

struct PositionComponent {
    float x = 0.0f;
    float y = 0.0f;
    float z = 0.0f;
};

Systems = Logic Only

void MovementSystem::tick(Registry& r, float dt) {
    for (auto [e, pos, vel] :
         r.view<Position, Velocity>().each()) {
        pos.x += vel.dx * dt;
    }
}

Key Principles

Components are plain structs. No methods, no inheritance.

EnTT stores components in contiguous memory for optimal iteration.

Entities gain behavior by attaching components. No class hierarchies.

The Golden Rule

Everything is E, C, or S. Strict separation of data and logic. Systems must NEVER communicate directly — only through Components.

Cache-friendly iteration
Data-oriented design
Composable entities
Steeper learning curve

Cache-unfriendly
Deep inheritance trees
Tight coupling
Familiar to most developers

Scheduling

ASE uses a custom tiered scheduling system with 66 schedules across 21 tiers.

Mathematical Foundation

The simulation uses continuous integration:

$\vec{p}(t + \Delta t) = \vec{p}(t) + \vec{v}(t) \cdot \Delta t + \frac{1}{2} \vec{a}(t) \cdot \Delta t^2$

All math functions come from ase-math (Layer 0). Never use std::min/max/clamp.

This page documents version {version} of the ECS architecture.

::badge{text="Stable" color="green"} ::badge{text="v2.1.0" color="cyan"}