My game is built on top of an ECS — short for Entity-Component-System architecture. If you’ve never used one before, this post will explain what it is, how it compares to traditional Object-Oriented Programming (OOP), and why it’s such a good fit — especially for a simulation-heavy, modding-friendly game like this one.

What is ECS?

ECS is a way of organizing game data and behavior by separating what something is from what it does.

  • Entities are just IDs. No data. No behavior. Think of them like tags or handles.
  • Components are pure data: Position, Health, Sprite, Needs, Temperature.
  • Systems are pure logic: they run behavior based on which components an entity has.

So for example:

  • If an entity has Position + Velocity, the MovementSystem will move it.
  • If it has Needs + Schedule, the BehaviorSystem might decide what job it should do.
  • If it has Sprite + Position, the RenderSystem will draw it.

Each system doesn’t care what the entity is — it only looks for the components it needs.

How it differs from OOP

In traditional OOP (like Unity’s MonoBehaviour model or plain Java/C# classes), you might have something like:

class Guard : Character {
    void Update() {
        Move();
        CheckNeeds();
        Patrol();
    }
}

This works… until it doesn’t:

  • What happens when you want a Drone that also patrols like a guard?
  • Or a RobotChef that needs food but doesn’t move?
  • You end up with deep class hierarchies, diamond inheritance, or tangled base classes.

With ECS, you skip all that:

  • Want a drone that patrols? Just give it the PatrolComponent.
  • Want a robot chef? Give it Needs and CookingSkill.
  • Want to make a new type of entity? Just add a new bag of components.

No classes, no inheritance, no bloat.

Why I chose ECS for this project

A game like this — tile-based, simulation-driven, highly modular — thrives under ECS:

  • Modding becomes trivial — mods define new components, mix them onto entities, or plug into systems.
  • Walls, doors, AI, fluids, power systems — all become reusable patterns, not hardcoded logic.
  • Performance scales well — ECS lends itself to fast iteration and data-oriented design.
  • Plugins and scripting are easier — you don’t subclass, you attach data and hook into systems.

And perhaps most importantly: ECS scales sideways.

As the simulation grows more complex (needs, moods, schedules, effects), I don’t have to rewrite my core. I just add new components and systems. Mods can do the same.

For modders

If you’re a modder:

  • You’ll be able to define new components in simple data or Lua
  • Write custom systems in Lua or C# plugins
  • Or just mix-and-match existing parts to make new entity types

No inheritance trees. No custom classes. No fragile monkey-patching.

Just composable data and predictable systems.