[teamonkey]

Same here. I still find it a bit misleading too.

The game didn’t make it to AC:Valhalla, a texture-packing library that was made during its creation did[1] (not wanting to downplay that achievement, it’s worthy of a post in its own right, IMO).

It’s also a bit of a stretch to claim it was the source of the ECS system used in Unity. I was using a game engine which used ECS prior to 2010. In the game engine world it seems to originate with Operation Flashpoint[2] (post from 2007).

[1] https://github.com/TeamHypersomnia/rectpack2D

[2] https://t-machine.org/index.php/2007/09/03/entity-systems-ar...

[geneotech]

Hey there, a little clarification - I don't claim that I came up with ECS itself, only a particular implementation of it that is very memory efficient, and Unity's patent concerns a specific implementation as well - sorry if that was a bit misleading. As for the title, I just couldn't resist making the pun, maybe you're right though that the packer should be talked about separately.

[lionkor]

Am I crazy or is your approach to ECS similar to a data oriented ECS?

In a fully, brutally data-oriented ECS, you would allocate all components of the same type in the same memory block, so you'd effectively end up with a std::vector<TransformComponent> and a std::vector<PhysicsComponent>, etc. Each entity then holds ids, such as a pair of `what` component and `index` into the respective vector. This ensures that, like your approach, the cache is used well, and that memory fragmentation is minimal.

I find your project(s) very, very inspiring as I love working on similar problems among others (github.com/lionkor), thank you for sharing!

[geneotech]

Thank you! The approach you describe is indeed the "final form" of a brutally data-oriented ECS, but my method is a bit simpler - e.g. if the game has:

struct player { components::transform transform; components::health health; };

struct box { components::transform transform; components::physics physics; };

Then my ECS simply holds a std::vector<player> and a std::vector<box> rather than having a vector per each type of component. I also use the integer identifiers like you describe but with a twist - there is one more indirection involved so that deleting from the vectors does not invalidate existing indices pointing to vector elements. It's still exactly O(1). See the section on the Memory pool in the game repo's README.

[meheleventyone]

This is pretty much how games outside of general purpose engines have always done it. With some exciting variations like having one monster struct that has every property for every entity in the game so you just have a single array of entities. Or having each struct contain an ID field so you can pass around pointers and cast them based on the ID value.

[geneotech]

Indeed, such a rigid struct-based "ECS" is basically how most non-ECS games do it, but using components to compose game objects, if you say put them into std::tuple, makes it easy to to later call e.g. a generic lambda only on vectors of objects that contain given components. This makes for an excellent statically polymorphic code that doesn't care about what particular type the game object might have (is it a character? is it a tree?) as long as it has e.g. physics + health. In my 2013 article I also describe how to apply the same concept if we don't hardcode a specific collection of "structs of components", but add/remove components to entities at runtime.

[meheleventyone]

Yeah this is the nice thing about writing a game without a general purpose game engine, you only need to go as deep into these things as the game needs. Spend a lot of time with general purpose engines and it’s always a bit of a pain when their world representation is a little bit ‘wrong’ for your game.

[DiabloD3]

Columnar stores were in use in games since at least the mid-90s.

Very common way of optimizing for CPU caches.

[lionkor]

you can avoid invalidating indices by using a sparse array (like a flat_map) instead of a vector

[meheleventyone]

This isn’t as ‘brutal’ as you can go because the point of data oriented programming is to organise data coherently in memory based on how it’s accessed. Linear arrays as blobs of data are fine if you have strictly linear access, but you can go further by considering how systems access data. So you end up with ideas like archetypes as ways to structure memory to minimise cache misses.