[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.