[davedx]

Yeah fully agree, ECS is the microservices of gamedev these days.

I've worked on AAA games that used it, and shipped games as a solo dev without it. If you don't know why you need it, then chances are you don't need it. Just keep it in mind as one possible architecture pattern for when your code base starts to experience growing pains is my advice.

[throwaway894345]

I don’t have any intention of writing a game, but my lay understanding of ECS is that it sort of treats your world as an in-memory columnar database for better cache locality: if you’re updating the positions of a collection of entities, you only need to loop over a collection of contiguous `position` structs—you can get a lot more of these in a cache line than you would if the entire entity was a struct containing a position field among many other fields which are irrelevant to the updatePosition operation. How far off am I?

[ajmmertens]

Pretty close, but there's a bit more to it. This post goes over one way an ECS can store data: https://ajmmertens.medium.com/building-an-ecs-2-archetypes-a...

[ajmmertens]

I'm definitely not going to argue that you need ECS to do much of anything, but ECS has come long way in the past 4 years from a tool that lets you have lots of entities in a game, to a more generic system for entity management.

Things like entity relationships (https://ajmmertens.medium.com/building-games-in-ecs-with-ent...) introduced features that were already common in existing entity management systems, such as entity hierarchies.

An ECS can also come with a bunch of tools for inspecting entities, monitoring performance or changing components in realtime (https://www.flecs.dev/explorer/). Definitely not something you need to complete a game, but very handy.