Entity Component System (ECS)

A software architectural pattern for representing game-world objects: entities are bare ids, components are plain data attached to them, and systems are functions that run over every entity carrying the components they care about. An entity is defined by the components it has, not by a class it belongs to. Grounded here in the Wikipedia article the source arrived as (encyclopedic, T2), which traces the term to Scott Bilas's 2002 GDC talk contrasting a C++ object system with a custom component system.

It earns a node because the spoke has been talking about ECS without one. Bevy is paged as the corpus's ECS exemplar ("Components are Rust structs, Systems are Rust functions... Massively Parallel and Cache-Friendly"), and synthesis's open questions name ECS / data-oriented architecture as one of the axes Bevy opened against the standalone engines. This page is the axis itself.

The choice it stands against

ECS is the pattern on the far side of the spoke's oldest architectural fault line: composition over inheritance. The alternative, and the incumbent, is the scene tree / object model: Godot's nodes, Unity's classic GameObject + MonoBehaviour, Unreal's Actor hierarchy, where an object is a node in a type tree and carries its behaviour with it. ECS refuses the tree. A "player that can be poisoned" is not a Player subclass; it is an entity that happens to hold a Poisoned component, and the poison system finds it precisely because it holds that component and ignores everything that does not.

Two consequences the game-engine literature actually cares about follow from that:

• Behaviour is added by data, not by subclassing. New combinations (a poisonable piece of terrain, a flying pickup) need no new type; attach the components. This is the flexibility half of the pitch.
• Memory layout is the real payoff. Because components are homogeneous data, an ECS can store all instances of a component contiguously and let a system stream over them, which is the "cache-friendly" claim on bevy's page. This is where ECS meets data-oriented design, and it is the reason ECS became a performance argument rather than only a modelling one, because the type hierarchy scatters an object's data across the heap where the component array does not.

Where it sits in this spoke

It is a genuine engine-level commitment, not a library detail. Bevy is ECS-native and built the engine around it; Unity added an ECS stack (DOTS) beside its GameObject model rather than replacing it, which is itself the tell that the two models coexist uneasily inside one engine. The pattern is "most associated with video game development" (which is why it routes here), but the Wikipedia source notes it turns up in robotics simulators such as Gazebo too, the same way a game engine's other architecture ideas leak into simulation.

One-source caveat: this node rests on an encyclopedic overview plus the spoke's existing Bevy page. The corpus holds no engine's own ECS design document and no measurement of the cache-locality claim, so the performance argument is recorded as the pattern's stated rationale, not as something this wiki has seen demonstrated.

Related

bevy · procedural-generation · netcode · godot-engine · unity-engine · synthesis