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.
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.
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.
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
The CPU is hopping to a random memory address where your "transform" component is located before modifying it, over and over.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
So you get cache locality as you're running through your transforms.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.