🌐 1. Archetype‑Based ECS
(Unity DOTS, Bevy, Frostbite internal systems)
🧩 Real‑world examples
| Engine / Game | Why it fits archetype ECS |
|---|---|
| Unity DOTS demos (Megacity, Entity Component Samples) | Tens of thousands of entities, heavy physics, chunk‑optimized memory layout |
| Bevy engine games (Rust gamedev scene) | Hot‑loop systems, predictable scheduling, parallelism |
| Frostbite engine subsystems (Battlefield series) | Massive crowds, destructible environments, physics‑dense scenes |
🧠 Why these games choose archetype ECS
- They need maximum throughput
- They have huge numbers of similar entities
- They benefit from chunked SoA memory
- They rely on tight, predictable pipelines
🧪 Typical workloads
- 10k–100k entities
- physics‑heavy
- AI swarms
- particle systems
- large open worlds
🌿 2. Sparse‑Set ECS
(Flecs, EnTT, Svelto.ECS, many custom engines)
🧩 Real‑world examples
| Engine / Game | Why it fits sparse‑set ECS |
|---|---|
| Flecs‑based games (indie & AA titles) | Flexible component sets, ergonomic queries |
| EnTT‑based engines (C++ gamedev) | Great for tools, editors, gameplay logic |
| Svelto.ECS (used in Unity‑based production games) | Hybrid ECS with strong separation of concerns |
🧠 Why these games choose sparse‑set ECS
- They want flexibility over raw speed
- They mix gameplay logic + simulation
- They need ergonomic iteration
- They want easy debugging
🧪 Typical workloads
- 1k–20k entities
- mixed gameplay + simulation
- tools, editors, UI
- AI, inventory, quests
Sparse‑set ECS is the “default good choice” for most games.
🌳 3. Hybrid Node/ECS
(Godot 4, Roblox, Unreal’s internal component model)
🧩 Real‑world examples
| Engine / Game | Why it fits hybrid ECS |
|---|---|
| Godot 4 | Nodes for creators, ECS under the hood for performance |
| Roblox | Hierarchical data model + component‑like behaviors |
| Unreal Engine (Actor + Component system) | OO façade, data‑oriented internals |
🧠 Why these games choose hybrid ECS
- They need creator‑friendly ergonomics
- They want OO‑style scripting
- They hide ECS complexity behind nodes/actors
- They support UGC or large teams
🧪 Typical workloads
- scripting‑heavy
- UGC platforms
- tools + gameplay + simulation
- moderate entity counts
This is the “best of both worlds” dialect for engines that must be ergonomic.
🏷️ 4. Tag‑Heavy / Minimal ECS
(Roguelikes, small engines, hobby engines, ECS‑lite frameworks)
🧩 Real‑world examples
| Engine / Game | Why it fits tag‑heavy ECS |
|---|---|
| RogueBasin ECS tutorials | Simple tags for AI, FOV, inventory |
| Amethyst (early versions) | Tag‑driven systems |
| Many custom roguelike engines | Minimal data, lots of markers |
🧠 Why these games choose tag‑heavy ECS
- They want simplicity
- They don’t need high performance
- They want clear, readable logic
- They use ECS mainly for decoupling
🧪 Typical workloads
- < 1k entities
- turn‑based
- grid‑based
- simple AI
- minimal physics
This is perfect for prototypes, small games, and teaching.
🧬 5. “OO façade → ECS IR” (your proposed dialect)
This is the one you’re designing:
OO‑looking code → ECS IR → SoA kernels, with an AI‑agent co‑designer.
🧩 Real‑world analogues
| System | Why it’s similar |
|---|---|
| Unity DOTS with Roslyn analyzers | OO → ECS transformation |
| Svelto.ECS | Strong separation of logic and data |
| Frostbite’s internal tools | Codegen + data‑oriented pipelines |
| ISPC / Halide | High‑level code → optimized kernels |
This is the “future dialect” — and your agent‑native approach makes it viable.
No comments:
Post a Comment