They describe a "sparse set" designed for sequential identifiers -- how does that compare to something like an in memory b+ tree?
But, it's easy to think of data for a component system as a table where each row is associated with an entity so I can see why you draw the similarity.
How would you implement ECS, a system for tracking the state of game entities, in a stateless manner? Can you expand on that?
Stateful way: your Inventory Manager component iterates through its private array of item entities to mark their model components as shown or hidden, then calls the dependency injected character's avatar component to update its animation state.
Stateless way: you flip an integer in character's struct, and the rendering function does something different.
Case in point: rustc:
https://gamedevelopment.tutsplus.com/articles/what-is-data-o...
Instead of treating each object as a collection of components, you can operate on bags of components
So say in you're modeling space invaders:
every frame:
for enemy in enemies
enemy.transform.y += 10
Data oriented would be something like:
each frame:
for transform in transforms
if transform is enemy
transform.y += 10
if transform is player
transform += input
Now imagine if instead of space invaders we're trying to model say blades of grass. Suddenly we go from a very cache unfriendly method to something that's cache friendly, branch prediction friendly, and easy to parallelize.
If you want to experiment with it Unity has some great examples under their new DOTS system
https://github.com/Unity-Technologies/EntityComponentSystemS...
APIs can make data oriented more ergonomic than my contrived example implies, but it's still not nearly as intuitive as ECS imo.
To me data oriented subsystems are fine, but not as a core concept for your game's architecture.
The latter is an anti-pattern, and you can do either with ECS.
With ECS nothing prevents you from just having the "physical" game state as the single source of truth, and having the render function for the player inventories look at it.
A physics system might change the position components while a decoupled rendering system might read that position components and the rendering details components to add draw commands.
This is probably the best explanation that I can imagine -- that they're not fundamentally different, just that ECS tends to make a sufficiently different set of design choices that it warrants some of it's own terminology.
I can't help but wonder what a more generalized take on ECS might look like, if it were to continue drawing from relational databases. For example, support for multiple indices to assist with different query patterns. Or triggers to abstract away cascading updates. Or perhaps materialized views to keep query patterns simple.
I've never had the opportunity to use an ECS system, especially in a performance sensitive context, so I don't have a good sense of where any pain points are in practice versus what my imagination can conjure up.
I also wonder what it might look like to use SQL to generate an optimal C++ representation while keeping the data definition high level.
Just idle musings - maybe one day I'll take the time to experiment.
Triggers might be counter productive. Games usually have a fundamental concept of a game loop. Changes can be processed in the loop and side effects can be processed in the following iteration. Triggers would cause this processing to be unpredictable (or at least harder to predict). ECS provides a clean way to define the order in which systems are processed each loop. Triggers might disrupt this ordering.
Maybe that's still desired, maybe not. I just thought it would be interesting to mention.
say translating all positions, then calling all of the triggers for the positions component.
that'd keep everything in tight single purpose loops and preserve cache lines.
fair enough that it'd probably make execution order harder to predict, but also in theory it would be in the realm of possibility to generate a plan and print out the order that things would happen in.
(I'm not positing that this is actually worth doing or that the pros out weigh the cons -- just toying with the idea)
The thing with the actual gameplay layer is your often processing mainly heterogeneous elements rather than homogeneous so all the worry and focus on cache is largely academic for most kinds of game.