When 100 Enemies Brought My Game to Its Knees (And How Entity Component System C# Saved It)

Here's the thing—I spent a couple of days once trying to optimize a simple bullet-hell prototype. I had barely 100 enemies on screen, and the frame rate was already tanking. Every enemy was its own MonoBehaviour, each calling Update() independently, and Unity was choking on the overhead. That's when I realized traditional object-oriented programming (OOP) wasn't going to cut it for performance-critical gameplay systems.

The solution? Entity Component System C#. This architectural pattern completely changed how I think about game code. Instead of thousands of objects with tangled inheritance hierarchies, you get pure data arrays and systems that process them in bulk. The same scene that struggled at 100 enemies? After implementing ECS Unity principles, it handled thousands with barely a hiccup. If you've ever hit performance walls with MonoBehaviour, this is the paradigm shift you need to understand.

What Is ECS and Why Should You Care?

Let me break down ECS architecture the way I explain it to students at Outscal. The Entity Component System is a software architectural pattern that solves the deep-rooted problems of complex inheritance hierarchies and tangled logic common in traditional object-oriented programming, especially in game development.

Here's what makes it powerful: instead of creating classes that inherit from each other (like Enemy inheriting from Character inheriting from GameObject), ECS lets you build incredibly high-performance and scalable gameplay by focusing on data composition rather than class inheritance.

Think of it like a massive spreadsheet. Entities are the row numbers (unique IDs), Components are the data in the cells (like "Position" or "Health"), and Systems are the macros that run calculations on entire columns at once. A "Movement" macro updates all "Position" cells based on their corresponding "Velocity" cells—all at once, in one efficient sweep.

By separating data (Components) from logic (Systems), you can create games that handle thousands of dynamic objects—like bullets, enemies, or asteroids—with minimal performance impact. This is data-oriented design in action, and it's the foundation of modern high-performance game engines.

The Building Blocks That Make ECS Work

Before we dive into code, let me walk you through the fundamental concepts. I remember being completely confused by these when I first encountered ECS at CMU, so let me save you that struggle.

• Entity: An Entity is not a traditional object; it is merely a unique integer ID. It acts as a "key" or a "handle" that groups a set of components together to represent a single "thing" in your game, but it contains no data or logic itself. Think of it as just a number—like employee ID 1042—that ties together different pieces of information.
• Component: A Component is a plain C# struct or class that contains only data, with no methods or logic. Each component represents a single aspect or property of an entity, such as its Position, Velocity, Health, or Color. This is the "composition" part of component-based architecture—you build complex objects by combining simple data components.
• System: A System is a class that contains all the logic for a specific feature, such as a MovementSystem or a CollisionSystem. Systems operate on collections of Unity entities that have a specific set of required components, transforming their component data from one state to another each frame. All your game logic lives here.
• World: The World is the central container that manages everything. It holds all the entities, the component data stores, and all the systems, and it is responsible for orchestrating the main game loop by telling each system to execute its update logic.
• Archetype: An Archetype is a unique combination of component types. For example, all entities that have a Position and a Velocity component belong to the same archetype. ECS frameworks use archetypes to store all component data of the same type together in contiguous memory blocks, which is the key to their high performance.
• Data-Oriented Design: This is the programming paradigm that underpins ECS. Instead of focusing on objects and their behaviors (Object-Oriented Programming), it focuses on the data itself and how it is laid out in memory to be transformed efficiently, leading to massive game performance optimization by making optimal use of the CPU cache.

How ECS Actually Works Under the Hood (With Code)

Actually, wait—let me show you the simplest possible implementation first, because this is where it all clicks.

Entities Are Just IDs

An entity is nothing more than a unique identifier. In a simple ECS implementation, it can be a simple integer that acts as an index into our data arrays. (Verified: Unity Docs - Entity)

// In its simplest form, an Entity is just an integer.
public readonly struct Entity
{
    public readonly int Id;

    public Entity(int id)
    {
        Id = id;
    }
}

That's it. Seriously. No inheritance, no complex class hierarchies. Just a number that uniquely identifies a game object.

Components Are Pure Data

(Verified: Unity Docs - Unmanaged Components)

// A component for an entity's position in the world.
public struct PositionComponent
{
    public float X;
    public float Y;
}

// A component for an entity's velocity.
public struct VelocityComponent
{
    public float dX;
    public float dY;
}

Notice there are no methods, no Update() calls, no logic at all. Just pure data. This is radically different from traditional Unity MonoBehaviour scripts.

Systems Contain All the Logic

A system queries the World for all entities that have a specific set of components and then iterates over them to perform its logic. (Verified: Unity Docs - ISystem)

// A system that moves any entity with both a Position and Velocity component.
public class MovementSystem
{
    public void Update(World world, float deltaTime)
    {
        // In a real ECS, this query would be much more efficient.
        foreach (var entity in world.GetEntitiesWith<PositionComponent, VelocityComponent>())
        {
            // Get the component data for the entity.
            ref var pos = ref world.GetComponent<PositionComponent>(entity);
            var vel = world.GetComponent<VelocityComponent>(entity);

            // Update the position data.
            pos.X += vel.dX * deltaTime;
            pos.Y += vel.dY * deltaTime;
        }
    }
}

This is where the magic happens. Instead of each entity updating itself independently, one system updates ALL entities with the required components in a single, efficient loop.

The World Holds Everything Together

The World class is the main entry point for Unity systems programming. It's responsible for creating entities and running the systems in the correct order. (Verified: Unity Docs - World)

public class World
{
    private List<Entity> _entities = new List<Entity>();
    // In a real ECS, component storage would be much more complex and optimized.
    private Dictionary<int, PositionComponent> _positions = new Dictionary<int, PositionComponent>();
    private Dictionary<int, VelocityComponent> _velocities = new Dictionary<int, VelocityComponent>();

    private MovementSystem _movementSystem = new MovementSystem();

    public void Update(float deltaTime)
    {
        _movementSystem.Update(this, deltaTime);
    }

    // Helper methods for creating entities, adding components, etc. would go here.
}

MonoBehaviour vs ECS: The Performance Showdown

Been there—I've built complex gameplay systems both ways, and the difference is night and day. Let me show you the real comparison.

From my experience at KIXEYE, we used ECS-like patterns for our large-scale strategy games. When you're simulating hundreds of units in real-time combat, traditional OOP just doesn't cut it.

Why This Is a Game-Changer for Your Projects

I've seen Unity DOTS (Data-Oriented Technology Stack) transform workflows at multiple studios. Here's why this matters for your projects:

Massive Performance Gains

By organizing component data into tight, linear arrays, ECS makes optimal use of modern CPU caches. This avoids the performance penalty of "cache misses" that plague traditional OOP approaches, allowing you to simulate tens of thousands of objects smoothly. In my bullet-hell prototype, I went from struggling with 100 enemies to handling 5,000+ without breaking a sweat.

Emergent Behavior and Flexibility

Because game features are defined by the composition of components on an entity, you can create new types of objects simply by mixing and matching components, without writing any new code. An entity becomes a "bouncing, flaming projectile" just by adding BouncyComponent, BurningComponent, and ProjectileComponent. No new class definitions, no inheritance chains—just composition.

Cleaner, Decoupled Codebase

ECS forces a clean separation between data (Components) and logic (Systems). This makes your code far easier to understand, debug, and maintain, as the logic for any given feature is located in one place (the System) instead of being scattered across many different object classes. Trust me, your future self will thank you.

Implicit Parallelism

The design of systems, which perform a single operation on large sets of data, is naturally suited for multi-threading. Modern ECS frameworks like Unity's DOTS can automatically schedule systems to run on multiple CPU cores, further boosting performance without requiring complex manual threading code.

The Rules That Keep Your ECS Clean and Fast

After working with ECS systems for years, here are the practices that'll save you from the mistakes I made.

Components Should Be Structs

To get the full performance benefit of ECS, your components should be structs (value types) instead of classes. This ensures the data is stored directly in the contiguous arrays (archetype chunks) for maximum cache efficiency. (Verified: Unity Docs - Unmanaged Components)

// GOOD: A struct is a value type, stored efficiently.
public struct Position : IComponentData
{
    public float X;
    public float Y;
}

// BAD: A class is a reference type, adding an extra layer of indirection.
public class PositionClass : IComponentData
{
    public float X;
    public float Y;
}

This one tripped me up early on. I was using classes out of habit, and couldn't figure out why my performance wasn't improving. Switching to structs made all the difference.

Systems Should Be Stateless

A system's job is to transform data, not to store it. All the state a system needs should be contained within the components it queries for. This makes systems reusable, predictable, and safe to run in parallel. (Verified: Unity Blog - Writing Good Systems)

// GOOD: The system has no fields and operates only on the component data passed to it.
public partial struct MovementSystem : ISystem
{
    public void OnUpdate(ref SystemState state)
    {
        float deltaTime = SystemAPI.Time.DeltaTime;
        foreach (var (transform, velocity) in SystemAPI.Query<RefRW<LocalTransform>, RefRO<Velocity>>())
        {
            transform.ValueRW.Position += velocity.ValueRO.Value * deltaTime;
        }
    }
}

This is a hard mental shift if you're coming from OOP. In traditional programming, you'd store state in class fields. In ECS, all state lives in components—systems are just processing functions.

Use Tag Components for State and Filtering

A "tag" is an empty component used to mark an entity. This is a highly efficient way to add or remove a state or to select specific entities for a system to process. (Verified: Unity Docs - Tag Components)

// An empty struct used to tag an entity as the "Player".
public struct PlayerTag : IComponentData { }

// A system can then query for this tag to find the player.
public partial struct PlayerCameraSystem : ISystem
{
    public void OnUpdate(ref SystemState state)
    {
        // This query will only find the single entity with the PlayerTag.
        foreach (var playerTransform in SystemAPI.Query<RefRO<LocalTransform>>().WithAll<PlayerTag>())
        {
            // ... update camera logic
        }
    }
}

Tags are incredibly powerful. Instead of checking booleans or enums, you just add or remove a tag component. The archetype system automatically groups entities by their tag combinations for ultra-fast queries.

Real Games Using ECS (And How They Pull It Off)

One of my favorite things about teaching Unity ECS tutorial content at Outscal is showing students how AAA and indie games use these techniques. Let me share examples that really drive home why this architecture matters.

Total War Series: Commanding Thousands of Soldiers

The Mechanic: Thousands of individual soldiers clash on a massive battlefield, each with its own health, position, and current action (e.g., fighting, running, reloading).

The Implementation: ECS is the perfect architecture for this. Each soldier is an entity. Their data is stored in components like HealthComponent, PositionComponent, and StateComponent. Systems like MeleeCombatSystem and MovementSystem iterate through thousands of soldiers each frame, updating their data in a highly performant, cache-friendly way.

The Player Experience: The player gets to command epic, large-scale armies in real-time, an experience that would be impossible to render smoothly using a traditional object-oriented approach for every single soldier.

// Simplified pseudo-code demonstrating the concept.
public class MeleeCombatSystem : SystemBase
{
    protected override void OnUpdate()
    {
        // Find all soldiers that are in melee range of an enemy.
        Entities.ForEach((ref HealthComponent health, in MeleeTargetComponent target) =>
        {
            // Apply damage to the target entity.
        }).Schedule();
    }
}

What I find fascinating about this approach is how it scales. Total War games have been pushing the boundaries of real-time strategy for years, and their ability to simulate massive battles smoothly is a direct result of data-oriented design.

Vampire Survivors: Bullet Hell Performance

The Mechanic: The screen is filled with hundreds, sometimes thousands, of moving projectiles and enemies, each requiring position updates and collision checks every frame.

The Implementation: Every projectile is an entity with PositionComponent, VelocityComponent, and DamageComponent. A single ProjectileMovementSystem updates the positions of all projectiles at once. A CollisionSystem then checks for overlaps between projectile entities and enemy entities.

The Player Experience: The game delivers a satisfying and chaotic "bullet hell" experience that runs smoothly even on low-end hardware. The sheer number of objects on screen is a direct result of the performance benefits of ECS.

// Simplified pseudo-code demonstrating the concept.
public class ProjectileMovementSystem : SystemBase
{
    protected override void OnUpdate()
    {
        float dt = Time.DeltaTime;
        // Update all entities that have both Position and Velocity.
        Entities.ForEach((ref PositionComponent pos, in VelocityComponent vel) =>
        {
            pos.Value += vel.Value * dt;
        }).ScheduleParallel(); // This can often be run on multiple threads!
    }
}

I always tell my students to look at Vampire Survivors when they ask "Can ECS really make that big a difference?" This game is proof that proper architecture can make previously impossible gameplay feel effortless.

Cities: Skylines: Simulating a Living City

The Mechanic: The game simulates a massive city with thousands of individual citizens ("cims"), cars, and goods, each following its own path and logic.

The Implementation: Each citizen is an entity. Their data is stored in components like HomeLocation, WorkLocation, CurrentTransportMode, and Age. Systems like TrafficSystem, GoToWorkSystem, and AgingSystem process all citizens simultaneously to create the emergent behavior of a living city.

The Player Experience: The player can build and manage a detailed, sprawling metropolis that feels alive. The simulation's depth and scale are made possible by the efficiency of the underlying data-oriented architecture.

// Simplified pseudo-code demonstrating the concept.
public class GoToWorkSystem : SystemBase
{
    protected override void OnUpdate()
    {
        // Find all citizens who are at home and need to go to work.
        Entities.WithAll<AtHomeTag, HasWorkplaceComponent>()
            .ForEach((Entity entity, ref PathfindingComponent path) =>
        {
            // Calculate a path from their home to their workplace.
        }).Schedule();
    }
}

From a developer's perspective, what makes this brilliant is how the complexity emerges from simple systems. You're not hand-coding the behavior of each citizen—you're defining rules, and the simulation generates realistic city life.

Blueprint 1: Building Your Own Minimal ECS Framework from Scratch

Let me walk you through creating the fundamental building blocks of an ECS system from scratch in pure C#. Here's the exact method I use when teaching this concept.

Unity Editor Setup

This blueprint requires no Unity setup. You can write and test this code in any C# environment. Create separate C# files for each class (Entity.cs, World.cs, etc.). When I'm working on learning projects, I always start this way—understanding the core concepts before diving into Unity's DOTS.

Step-by-Step Implementation

1. The Component and System Interfaces:

First, create a simple marker interface for our components and a contract for our systems.

// IComponent.cs
public interface IComponent { }

// ISystem.cs
public interface ISystem
{
    void Update(World world, float deltaTime);
}

2. The World Class:

Next, create the World class. This will manage entities, components, and systems. The code below is a complete, working implementation that fixes the issues from the original version, including adding the required helper methods (EntityCount, HasComponent, UpdateComponent) and providing a more robust way to handle component storage and type registration.

// World.cs
using System;
using System.Collections.Generic;

public class World
{
    private int _nextEntityId = 0;
    private readonly List<IComponent>[] _components = new List<IComponent>[1024]; // Max 1024 component types
    private readonly List<ISystem> _systems = new List<ISystem>();

    public int EntityCount => _nextEntityId;

    public World()
    {
        for (int i = 0; i < _components.Length; i++)
        {
            _components[i] = new List<IComponent>();
        }
    }

    public int CreateEntity() => _nextEntityId++;

    private void EnsureCapacity<T>(int entityId) where T : IComponent
    {
        int typeId = ComponentType<T>.Id;
        while (entityId >= _components[typeId].Count)
        {
            _components[typeId].Add(default);
        }
    }

    public void AddComponent<T>(int entityId, T component) where T : IComponent
    {
        EnsureCapacity<T>(entityId);
        _components[ComponentType<T>.Id][entityId] = component;
    }

    public T GetComponent<T>(int entityId) where T : IComponent
    {
        int typeId = ComponentType<T>.Id;
        if (entityId >= _components[typeId].Count)
        {
            return default;
        }
        return (T)_components[typeId][entityId];
    }

    public bool HasComponent<T>(int entityId) where T : IComponent
    {
        int typeId = ComponentType<T>.Id;
        return entityId < _components[typeId].Count && _components[typeId][entityId] != null;
    }

    public void UpdateComponent<T>(int entityId, T component) where T : IComponent
    {
        int typeId = ComponentType<T>.Id;
        if (entityId < _components[typeId].Count)
        {
            _components[typeId][entityId] = component;
        }
    }

    public void RegisterSystem(ISystem system)
    {
        _systems.Add(system);
    }

    public void Update(float deltaTime)
    {
        foreach (var system in _systems)
        {
            system.Update(this, deltaTime);
        }
    }
}

// Static class to get a unique ID for each component type.
public static class ComponentType<T> where T : IComponent
{
    public static readonly int Id;
    private static int _nextId = -1;
    
    static ComponentType()
    {
        Id = System.Threading.Interlocked.Increment(ref _nextId);
    }
}

Now you have a complete, minimal ECS framework. It's not optimized for production, but it teaches the fundamental concepts perfectly and is fully functional for the following blueprints.

Blueprint 2: Creating a Movement System That Actually Works

Here's how to use our minimal ECS framework to create entities that move based on their Position and Velocity components. In my projects, I always start with movement because it's simple but demonstrates all the key ECS patterns.

Unity Editor Setup

When I'm working on Unity projects integrating custom ECS, here's my process:

• Create an empty GameObject named "GameLoop" and attach a GameLoop.cs script to it.
• Create the other C# script files from Blueprint 1 (World.cs, IComponent.cs, etc.) in your project.

Step-by-Step Implementation

1. Define Components:

Create the data components for position and velocity.

// PositionComponent.cs
public struct PositionComponent : IComponent
{
    public float X, Y;
}

// VelocityComponent.cs
public struct VelocityComponent : IComponent
{
    public float dX, dY;
}

2. Create the Movement System:

This system will contain the logic to update positions.

// MovementSystem.cs
public class MovementSystem : ISystem
{
    public void Update(World world, float deltaTime)
    {
        // This is a simplified query. A real ECS would have a more efficient way to get these entities.
        for (int entityId = 0; entityId < world.EntityCount; entityId++)
        {
            if (world.HasComponent<PositionComponent>(entityId) && world.HasComponent<VelocityComponent>(entityId))
            {
                var pos = world.GetComponent<PositionComponent>(entityId);
                var vel = world.GetComponent<VelocityComponent>(entityId);

                pos.X += vel.dX * deltaTime;
                pos.Y += vel.dY * deltaTime;

                world.UpdateComponent(entityId, pos); // Write the data back
            }
        }
    }
}

3. The Unity Game Loop:

Create a MonoBehaviour to host the World and drive its Update loop.

// GameLoop.cs
using UnityEngine;

public class GameLoop : MonoBehaviour
{
    private World _world;

    void Start()
    {
        _world = new World();
        _world.RegisterSystem(new MovementSystem());

        // Create a moving entity.
        int playerEntity = _world.CreateEntity();
        _world.AddComponent(playerEntity, new PositionComponent { X = 0, Y = 0 });
        _world.AddComponent(playerEntity, new VelocityComponent { dX = 10, dY = 5 });
    }

    void Update()
    {
        _world.Update(Time.deltaTime);

        // You would have a RenderSystem to visualize this (see Blueprint 3).
    }
}

This is the pattern I use in every ECS project: pure data components, systems that process them, and a game loop that ties everything together.

Blueprint 3: Connecting Your ECS to Unity's Visual Layer

Let's tackle the bridge between pure C# ECS and Unity's visual representation. We're going to visualize the entities from our ECS by creating and moving GameObjects in the Unity scene.

Unity Editor Setup

Here's my setup approach for bridging ECS and Unity:

• Continue from Blueprint 2.
• Create a simple Sprite or 3D Cube Prefab and place it in a "Resources" folder.

I've configured this dozens of times, and this approach gives you the best of both worlds: ECS performance with Unity's visual tools.

Step-by-Step Implementation

1. Define a "View" Component:

This component will link our ECS entity to a Unity GameObject.

// ViewComponent.cs
using UnityEngine;

public class ViewComponent : IComponent
{
    public GameObject GameObject;
}

2. Create the Render System:

This system's job is to find all entities with a Position and a View, and then update the GameObject's transform to match the Position data.

// RenderSystem.cs
using UnityEngine;

public class RenderSystem : ISystem
{
    public void Update(World world, float deltaTime)
    {
        for (int entityId = 0; entityId < world.EntityCount; entityId++)
        {
            if (world.HasComponent<ViewComponent>(entityId) && world.HasComponent<PositionComponent>(entityId))
            {
                var view = world.GetComponent<ViewComponent>(entityId);
                var pos = world.GetComponent<PositionComponent>(entityId);

                // Update the GameObject's transform from the component data.
                view.GameObject.transform.position = new Vector3(pos.X, pos.Y, 0);
            }
        }
    }
}

3. Update the Game Loop:

Modify the GameLoop to register the RenderSystem and to add the ViewComponent when creating entities.

// GameLoop.cs (Updated)
public class GameLoop : MonoBehaviour
{
    private World _world;
    public GameObject entityPrefab; // Drag your prefab here in the Inspector.

    void Start()
    {
        _world = new World();
        _world.RegisterSystem(new MovementSystem());
        _world.RegisterSystem(new RenderSystem()); // Register the new system.

        // Create a moving entity.
        int playerEntity = _world.CreateEntity();
        _world.AddComponent(playerEntity, new PositionComponent { X = 0, Y = 0 });
        _world.AddComponent(playerEntity, new VelocityComponent { dX = 10, dY = 5 });

        // Create the GameObject and link it with the ViewComponent.
        GameObject playerObject = Instantiate(entityPrefab);
        _world.AddComponent(playerEntity, new ViewComponent { GameObject = playerObject });
    }

    void Update()
    {
        _world.Update(Time.deltaTime);
    }
}

Now, when you run the scene, the MovementSystem will update the data in your pure C# ECS, and the RenderSystem will read that data to move the GameObject on the screen, effectively bridging the two worlds.

Trust me, you'll thank me later for this pattern. It keeps your high-performance ECS logic completely separate from Unity's rendering, giving you the best performance characteristics while still leveraging Unity's visual tools.

Wrapping Up: ECS Changes How You Think About Code

Here's what we've covered today: Entity Component System C# is a radical departure from traditional object-oriented programming, organizing your game around data composition and transformation rather than object hierarchies. You learned the core concepts—Entities as IDs, Components as pure data, Systems as logic processors, and the World as the orchestrator—and you built a complete minimal ECS framework from scratch.

The practical benefits for your projects are massive. You get performance that scales to thousands of objects, emergent behavior from simple component combinations, clean separation of data and logic, and code that's naturally ready for multi-threading. Most importantly, you understand the data-oriented design paradigm that's becoming the standard for high-performance game development.

From my time at KIXEYE building large-scale multiplayer games, and now teaching at Outscal, I've seen this knowledge transform how students approach game architecture. Once you internalize ECS thinking, you'll never go back to scattering logic across hundreds of MonoBehaviour scripts.

Ready to Start Building Your First Game?

If you're serious about game development and want to go from understanding these concepts to actually building complete games, I built something specifically for students like you.

The Mr. Blocks - Unity Game Development Course takes you from the absolute basics to creating a professional 2D game experience. You'll learn Unity fundamentals, C# programming, physics systems, and—yes—performance optimization techniques including when to use traditional approaches versus ECS Unity patterns. It's the exact curriculum I wish I had when I was making the transition into game development.

Stop watching tutorials and start building games that actually work.

Key Takeaways

• Entity Component System C# separates game objects into three parts: Entities (unique IDs), Components (pure data structs), and Systems (logic that transforms data), creating a fundamentally different architecture from traditional OOP.
• Data-oriented design organizes component data into contiguous memory arrays, making optimal use of CPU cache and enabling massive performance gains when handling thousands of game objects simultaneously.
• Components should always be structs (value types) rather than classes to ensure data is stored efficiently in archetype chunks without extra indirection overhead.
• Systems should be completely stateless, operating only on component data passed to them, making them naturally reusable, predictable, and safe for parallel execution.
• Archetypes—unique combinations of component types—are the secret to ECS performance, grouping entities with identical component sets for ultra-efficient batch processing.
• Tag components (empty structs) provide a highly efficient way to mark entities for filtering and state management without storing actual data.
• Traditional MonoBehaviour approaches excel for unique, complex objects with intricate logic, while ECS dominates for large-scale simulations, particle systems, and any scenario requiring thousands of similar entities.
• Modern Unity DOTS systems can automatically parallelize work across multiple CPU cores, turning single-threaded bottlenecks into multi-threaded performance powerhouses without manual threading code.