🧩 Lesson 4.1: The ECS Mindset — Entities, Components & Systems

The Payoff: Scale

Here's what we're working toward. This is a real render captured from Unity 6 — thousands of entities, each with its own position and motion, simulated and drawn together. Try building this with one GameObject per cube and the editor grinds to a crawl; with ECS it runs comfortably, because the data is laid out for the machine rather than for our convenience.

The number of objects isn't the interesting part — you could brute-force a few thousand GameObjects on a strong machine. The interesting part is headroom: the same scene in ECS leaves the CPU with time to spare for gameplay, physics, and AI, because iterating tightly packed data is something modern processors do extraordinarily well. This lesson explains why.

Three Ideas: Entity, Component, System

ECS splits the thing a MonoBehaviour bundles together — identity, data, and behaviour — into three separate concepts. Learning them as distinct ideas is the whole mindset shift.

Compare that to the object-oriented model you know: a MonoBehaviour is identity, data, and behaviour welded into one class, and each one lives at its own scattered spot in memory. ECS pulls those apart so that data of the same kind sits together and behaviour runs over it in bulk.

From Objects to Data — Why It's Fast

The reason ECS is fast has almost nothing to do with clever algorithms and everything to do with memory layout. Modern CPUs are starved not for compute but for data: reading a value that isn't already in the CPU cache costs hundreds of cycles while the processor waits on main memory. Performance is won by keeping the data the CPU needs next right beside the data it's using now.

GameObjects fail this test. Each one is a managed C# object allocated wherever the heap had room; its components are separate objects again, connected by references. Iterating 10,000 of them means chasing 10,000 pointers all over memory — a cache miss at nearly every step.

ECS stores components of the same type in contiguous arrays. Ask for every Velocity and you get a solid block of Velocity values, one after another. The CPU streams straight through it, prefetching as it goes. Same work, a fraction of the waiting.

Figure 2: The same objects' data, re-organised. OOP scatters each object (chase a pointer, miss the cache); ECS groups each component type into a packed array the CPU can stream through.

💡 This is data-oriented design. You met the idea in Module 3 when a job read a NativeArray instead of a List<GameObject>. ECS is that principle applied to your entire object model, with the engine managing the arrays for you.

The ECS Data Flow

Here is how the three pillars connect at runtime, drawn as a faithful diagram of the real flow. Follow the arrows: a system asks a query for the components it wants; the query hands back the matching entities' data as packed arrays inside chunks; the system reads and writes those arrays; and once per frame the presentation systems hand the final transforms to Entities Graphics, which draws them.

💡 Why a diagram and not a screenshot? ECS has no single "window" to photograph — its state lives in memory, and the Entities Hierarchy/Inspector are UI Toolkit panels that can't be captured cleanly. So the flow is drawn precisely from the real API, while the result (Figure 1) is a genuine Unity capture. That split — real renders for on-screen results, faithful diagrams for tools and data flow — runs through this whole course.

A First Taste in Code

You'll write these properly in the next three lessons; for now just read them and match each to a pillar. First, a component — a data-only struct:

using Unity.Entities;
using Unity.Mathematics;

// A COMPONENT: pure data, no methods, no MonoBehaviour.
// float3 is Unity.Mathematics' Burst-friendly vector type.
public struct Velocity : IComponentData
{
    public float3 Value;
}

Next, a system — the behaviour. It queries every entity that has both a LocalTransform (ECS's transform component) and our Velocity, then advances each position. Note there's no list of objects and no GetComponent: the query is the selection.

using Unity.Burst;
using Unity.Entities;
using Unity.Transforms;

[BurstCompile]
public partial struct MovementSystem : ISystem
{
    [BurstCompile]
    public void OnUpdate(ref SystemState state)
    {
        float dt = SystemAPI.Time.DeltaTime;

        // Iterate every entity matching { LocalTransform, Velocity }.
        // RefRW = read/write access, RefRO = read-only.
        foreach (var (transform, velocity) in
                 SystemAPI.Query<RefRW<LocalTransform>, RefRO<Velocity>>())
        {
            transform.ValueRW.Position += velocity.ValueRO.Value * dt;
        }
    }
}

That foreach is the whole idea in miniature: one system, one query, a straight pass over packed data. There's no Update() on ten thousand components each doing their own thing — there's one loop over ten thousand rows. In Lesson 4.3 we'll turn this loop into a parallel Burst job and watch it scale to the scene in Figure 1.

Archetypes & Chunks

One more idea makes the whole model click — and it's the key to why those arrays are contiguous. An entity's archetype is the exact set of component types it has. An entity with { LocalTransform, Velocity } has a different archetype from one with { LocalTransform, Velocity, Health }.

Unity groups every entity of the same archetype together into chunks — 16 KB blocks of memory. Within a chunk, each component type is stored as its own tightly packed array (that's the table in Figure 3). When a system queries for { LocalTransform, Velocity }, Unity simply hands it the matching chunks and it walks their arrays end to end. No searching, no pointer-chasing.

When to Reach for ECS

ECS is powerful, but it is not a replacement for GameObjects in every project — and being honest about that is part of using it well.

✅ ECS shines when…

• You have many similar things — thousands of projectiles, units, particles, boids, agents, or grid cells — doing the same work.
• Simulation cost dominates and you need it multithreaded and Burst-compiled to hit frame budget.
• The data and behaviour are uniform enough to express as components and systems.

🚫 Plain GameObjects still win when…

• You have a handful of complex, unique objects — the player, a boss, a UI screen — where flexibility beats raw throughput.
• You lean on subsystems that are still GameObject-first in your setup (much UI, some physics and animation workflows).
• The team's productivity matters more than the last millisecond — ECS has a real learning curve and stricter code.

Real projects are often hybrid: GameObjects for the bespoke, high-touch objects, and ECS for the massive, uniform swarms. You don't have to convert your whole game to benefit — you can drop ECS into the one system that needs the scale.

🔎 Prerequisite check. ECS leans hard on Module 3. Components use Unity.Mathematics types like float3; systems become jobs compiled by Burst to go parallel. If jobs and NativeArray still feel shaky, revisit Lessons 3.2–3.4 before Lesson 4.3.

Hands-on Challenge

Summary

🚀 What's Next?

Now that the model makes sense, we build it. In Lesson 4.2: Components & Archetypes you'll install the Entities package, define real IComponentData structs, create entities in code, and watch the archetype/chunk system organise them — the concrete foundation under Figure 3.