Unity Game Engine Series Part 10: Data-Oriented Tech Stack (DOTS)

1. Why DOTS?

1.1 OOP Limitations for Games

Traditional Unity code using MonoBehaviour and GameObjects has inherent performance limitations rooted in how object-oriented programming interacts with modern hardware:

1.2 The Data-Oriented Paradigm

Analogy: Imagine you're a librarian who needs to check the publication year of 10,000 books. In the OOP approach, each book is in a different room of a massive building — you walk to room 1, open the book, note the year, walk to room 2, and so on. Each trip takes 100 steps. In the DOTS approach, all the publication years are written on a single continuous scroll — you stand in one place and read them sequentially at the speed your eyes can move. Same data, same result, but 1,000x faster access.

2. Entity Component System (ECS)

2.1 Entities & Components

In ECS, the three concepts have precise, distinct roles:

// ECS Components — pure data structs, no behavior
using Unity.Entities;
using Unity.Mathematics;

// Position data for every entity in the world
public struct Position : IComponentData
{
    public float3 Value;
}

// Velocity for moving entities
public struct Velocity : IComponentData
{
    public float3 Value;
}

// Health for damageable entities
public struct Health : IComponentData
{
    public float Current;
    public float Max;
}

// Tag component — zero-size, used for filtering
// "This entity is an enemy" — no data needed, just the tag
public struct EnemyTag : IComponentData { }

// Shared component — entities with same value share memory
// Good for faction/team grouping
public struct FactionShared : ISharedComponentData
{
    public int FactionId;
}

// Buffer element — variable-length data per entity
// Like a List<T> but ECS-compatible
[InternalBufferCapacity(8)]
public struct DamageBufferElement : IBufferElementData
{
    public float Amount;
    public Entity Source;
}

2.2 Systems & Entity Queries

// ECS System — processes all entities with matching components
using Unity.Entities;
using Unity.Mathematics;
using Unity.Burst;
using Unity.Transforms;

// ISystem (unmanaged, Burst-compatible, preferred)
[BurstCompile]
public partial struct MovementSystem : ISystem
{
    [BurstCompile]
    public void OnCreate(ref SystemState state)
    {
        // Require these components to exist before system runs
        state.RequireForUpdate<Position>();
    }

    [BurstCompile]
    public void OnUpdate(ref SystemState state)
    {
        float deltaTime = SystemAPI.Time.DeltaTime;

        // Process every entity that has both Position and Velocity
        // This is automatically parallelized across CPU cores!
        foreach (var (transform, velocity) in
            SystemAPI.Query<RefRW<LocalTransform>, RefRO<Velocity>>())
        {
            transform.ValueRW.Position += velocity.ValueRO.Value * deltaTime;
        }
    }
}

// System that processes damage buffers
[BurstCompile]
public partial struct DamageProcessingSystem : ISystem
{
    [BurstCompile]
    public void OnUpdate(ref SystemState state)
    {
        // EntityCommandBuffer for deferred structural changes
        var ecb = new EntityCommandBuffer(Unity.Collections.Allocator.Temp);

        foreach (var (health, damageBuffer, entity) in
            SystemAPI.Query<RefRW<Health>, DynamicBuffer<DamageBufferElement>>()
                .WithEntityAccess())
        {
            // Sum all damage this frame
            float totalDamage = 0;
            foreach (var dmg in damageBuffer)
            {
                totalDamage += dmg.Amount;
            }

            // Apply damage
            health.ValueRW.Current -= totalDamage;

            // Clear the buffer for next frame
            damageBuffer.Clear();

            // Destroy entity if dead (deferred — safe during iteration)
            if (health.ValueRO.Current <= 0)
            {
                ecb.DestroyEntity(entity);
            }
        }

        ecb.Playback(state.EntityManager);
        ecb.Dispose();
    }
}

2.3 Archetypes & Chunks — The Memory Model

Understanding archetypes and chunks is key to understanding why ECS is fast:

3. Jobs System

3.1 Job Types & Scheduling

The C# Jobs System enables safe multithreading without the typical dangers of shared memory concurrency (race conditions, deadlocks). Unity's job safety system validates at compile time that no two jobs access the same data simultaneously.

// IJobParallelFor — process a large array across all CPU cores
using Unity.Jobs;
using Unity.Collections;
using Unity.Mathematics;
using Unity.Burst;
using UnityEngine;

public class ParticleSimulation : MonoBehaviour
{
    private NativeArray<float3> positions;
    private NativeArray<float3> velocities;
    private const int PARTICLE_COUNT = 100000;

    private void Start()
    {
        positions = new NativeArray<float3>(PARTICLE_COUNT, Allocator.Persistent);
        velocities = new NativeArray<float3>(PARTICLE_COUNT, Allocator.Persistent);

        // Initialize particles
        var random = new Unity.Mathematics.Random(42);
        for (int i = 0; i < PARTICLE_COUNT; i++)
        {
            positions[i] = random.NextFloat3(-50, 50);
            velocities[i] = random.NextFloat3Direction() * random.NextFloat(1, 5);
        }
    }

    private void Update()
    {
        // Create the job
        var moveJob = new MoveParticlesJob
        {
            Positions = positions,
            Velocities = velocities,
            DeltaTime = Time.deltaTime,
            Bounds = 50f
        };

        // Schedule it — splits 100,000 items across all cores
        // innerLoopBatchCount of 256 = each thread processes 256 particles at a time
        JobHandle handle = moveJob.Schedule(PARTICLE_COUNT, 256);

        // Complete before we read results (or pass handle to dependent job)
        handle.Complete();
    }

    private void OnDestroy()
    {
        if (positions.IsCreated) positions.Dispose();
        if (velocities.IsCreated) velocities.Dispose();
    }
}

[BurstCompile]
struct MoveParticlesJob : IJobParallelFor
{
    public NativeArray<float3> Positions;
    [ReadOnly] public NativeArray<float3> Velocities;
    public float DeltaTime;
    public float Bounds;

    public void Execute(int index)
    {
        float3 pos = Positions[index];
        pos += Velocities[index] * DeltaTime;

        // Wrap around bounds
        pos = math.fmod(pos + Bounds, Bounds * 2) - Bounds;
        Positions[index] = pos;
    }
}

// IJobEntity — ECS + Jobs integration
using Unity.Entities;
using Unity.Transforms;
using Unity.Mathematics;
using Unity.Burst;

[BurstCompile]
public partial struct EnemyMovementJob : IJobEntity
{
    public float DeltaTime;
    public float3 PlayerPosition;

    // Execute runs for each entity matching the query
    // Query is inferred from parameters: needs LocalTransform, Velocity, and EnemyTag
    void Execute(ref LocalTransform transform, in Velocity velocity, in EnemyTag tag)
    {
        // Move toward player
        float3 direction = math.normalize(PlayerPosition - transform.Position);
        transform.Position += direction * math.length(velocity.Value) * DeltaTime;
    }
}

// Schedule the job from a system
[BurstCompile]
public partial struct EnemyMovementSystem : ISystem
{
    [BurstCompile]
    public void OnUpdate(ref SystemState state)
    {
        // Get player position (simplified — assumes single player entity)
        float3 playerPos = float3.zero;
        foreach (var (transform, tag) in
            SystemAPI.Query<RefRO<LocalTransform>, RefRO<PlayerTag>>())
        {
            playerPos = transform.ValueRO.Position;
        }

        var job = new EnemyMovementJob
        {
            DeltaTime = SystemAPI.Time.DeltaTime,
            PlayerPosition = playerPos
        };

        // ScheduleParallel distributes entities across all CPU cores
        job.ScheduleParallel();
    }
}

public struct PlayerTag : IComponentData { }

3.2 NativeContainer Types

NativeContainers are the thread-safe, unmanaged-memory collections that Jobs and ECS use instead of managed C# collections:

4. Burst Compiler

4.1 Burst Basics & Benchmarks

The Burst Compiler translates C# Job code into highly optimized native machine code using LLVM. It's the "secret sauce" that makes DOTS performance possible — without Burst, the Jobs System is merely multithreaded. With Burst, it's multithreaded and running at C/C++ speeds.

// Burst compilation — just add the attribute!
using Unity.Burst;
using Unity.Jobs;
using Unity.Collections;
using Unity.Mathematics;

[BurstCompile(CompileSynchronously = true)] // Compile immediately, not lazy
struct GravitySimulationJob : IJobParallelFor
{
    [ReadOnly] public NativeArray<float3> Positions;
    [ReadOnly] public NativeArray<float> Masses;
    public NativeArray<float3> Forces;
    public float GravitationalConstant;

    public void Execute(int i)
    {
        float3 totalForce = float3.zero;
        float3 posI = Positions[i];
        float massI = Masses[i];

        for (int j = 0; j < Positions.Length; j++)
        {
            if (i == j) continue;

            float3 direction = Positions[j] - posI;
            float distSq = math.max(math.lengthsq(direction), 0.01f);
            float forceMagnitude = GravitationalConstant * massI * Masses[j] / distSq;

            totalForce += math.normalize(direction) * forceMagnitude;
        }

        Forces[i] = totalForce;
    }
}

// Burst restrictions:
// - No managed types (string, class, delegates)
// - No try/catch (exception handling is managed)
// - No virtual method calls
// - No LINQ
// - Must use Unity.Mathematics instead of UnityEngine.Mathf
// In return: 10-100x performance

4.2 Mathematics Library & SIMD

Burst uses the Unity.Mathematics library instead of UnityEngine.Mathf. This library is designed for SIMD (Single Instruction, Multiple Data) vectorization — processing 4 or 8 floats in a single CPU instruction:

// SIMD vectorization example with Burst
using Unity.Burst;
using Unity.Mathematics;

[BurstCompile]
public static class MathHelpers
{
    // Burst will auto-vectorize this to process 4 floats at once (SSE)
    // or 8 floats at once (AVX2) depending on CPU
    [BurstCompile]
    public static void NormalizeArray(ref NativeArray<float3> vectors, int count)
    {
        for (int i = 0; i < count; i++)
        {
            // math.normalize compiles to SIMD rsqrt + multiply
            vectors[i] = math.normalize(vectors[i]);
        }
        // On AVX2: processes 8 components per cycle instead of 1
        // Result: ~8x speedup from vectorization alone, on top of Burst's other optimizations
    }
}

5. Migration from MonoBehaviour to DOTS

5.1 Hybrid Approach & SubScenes

You don't have to rewrite your entire game in ECS. The hybrid approach lets MonoBehaviour and ECS coexist in the same project:

SubScenes are the bridge between the two worlds. A SubScene converts GameObjects (with authoring components) into ECS entities at build time or load time:

// SubScene workflow: Author in GameObjects, run in ECS
// 1. Create a SubScene (right-click in Hierarchy > New Sub Scene)
// 2. Place GameObjects inside the SubScene
// 3. Attach Baker components that convert to ECS at bake time

// Step 1: Define your ECS component
public struct EnemyData : IComponentData
{
    public float Speed;
    public float DetectionRange;
    public int FactionId;
}

// Step 2: Create an authoring component (MonoBehaviour, for editor)
public class EnemyAuthoring : MonoBehaviour
{
    public float Speed = 5f;
    public float DetectionRange = 20f;
    public int FactionId = 1;
}

// Step 3: Create a Baker that converts authoring to ECS
public class EnemyBaker : Baker<EnemyAuthoring>
{
    public override void Bake(EnemyAuthoring authoring)
    {
        var entity = GetEntity(TransformUsageFlags.Dynamic);

        AddComponent(entity, new EnemyData
        {
            Speed = authoring.Speed,
            DetectionRange = authoring.DetectionRange,
            FactionId = authoring.FactionId
        });

        AddComponent(entity, new EnemyTag());
    }
}

// Now: Place EnemyAuthoring on GameObjects in a SubScene.
// At bake time, Unity converts them to ECS entities with EnemyData + EnemyTag.
// Systems process them with full DOTS performance.

5.2 Baking: Authoring to Runtime

6. Real-World Performance

6.1 Handling 100K+ Entities

DOTS enables entity counts that are impossible with MonoBehaviour. Here's a practical comparison:

6.2 Spatial Partitioning & LOD with DOTS

// Spatial hashing for efficient neighbor queries in DOTS
using Unity.Entities;
using Unity.Mathematics;
using Unity.Collections;
using Unity.Burst;

[BurstCompile]
public partial struct SpatialHashingSystem : ISystem
{
    [BurstCompile]
    public void OnUpdate(ref SystemState state)
    {
        int entityCount = SystemAPI.QueryBuilder()
            .WithAll<LocalTransform, EnemyTag>().Build().CalculateEntityCount();

        // Create spatial hash map: cell -> entities in that cell
        var spatialMap = new NativeMultiHashMap<int2, Entity>(
            entityCount, Allocator.TempJob);

        float cellSize = 10f; // 10 unit grid cells

        // Phase 1: Build spatial hash (parallel)
        var buildJob = new BuildSpatialHashJob
        {
            SpatialMap = spatialMap.AsParallelWriter(),
            CellSize = cellSize
        };
        buildJob.ScheduleParallel(state.Dependency).Complete();

        // Phase 2: Query neighbors for each entity
        // Example: find all enemies within 15 units of the player
        // Hash the player position, check surrounding cells (3x3 grid)
        // This turns O(n^2) distance checks into O(n) lookups!

        spatialMap.Dispose();
    }
}

[BurstCompile]
partial struct BuildSpatialHashJob : IJobEntity
{
    public NativeMultiHashMap<int2, Entity>.ParallelWriter SpatialMap;
    public float CellSize;

    void Execute(Entity entity, in LocalTransform transform, in EnemyTag tag)
    {
        int2 cell = new int2(
            (int)math.floor(transform.Position.x / CellSize),
            (int)math.floor(transform.Position.z / CellSize)
        );
        SpatialMap.Add(cell, entity);
    }
}

7. History: DOTS Preview to ECS 1.0

Exercises & Self-Assessment

Conclusion & Next Steps

You now understand Unity's most powerful performance framework. Here are the key takeaways from Part 10:

• DOTS solves fundamental hardware problems — cache locality, multithreading, and native code compilation. These aren't theoretical benefits; they deliver 10-100x real-world speedups
• ECS separates data from behavior — entities are IDs, components are pure data structs, systems process matching entities. This layout maximizes cache coherence
• The Jobs System provides safe multithreading — schedule work across all CPU cores without race conditions or deadlocks. The safety system catches errors at compile time
• Burst Compiler is the performance multiplier — it compiles C# to native code with SIMD vectorization. Always add [BurstCompile] to Jobs and Systems
• Use NativeContainers (NativeArray, NativeList, NativeHashMap) instead of managed collections for zero-GC, thread-safe data access
• Hybrid approach is practical — use MonoBehaviour for player, UI, and game flow. Use DOTS for performance-critical mass-entity systems
• Baking (SubScenes) bridges editor authoring and runtime performance — design with GameObjects, run with entities