Question about GameSystemsState [SiO2]


So far I have been using “BaseAppState” for all my client side “view” systems/states that are watching for entities.

I am curious what are some example use cases of “client-specific” game systems mentioned below that one might want to use “GameSystem” instead of “BaseAppState” on the client.

For my game logic stuff, I often prefer game systems. I can run them anywhere and they don’t have the extra “rendering specific” methods that app state drags along with it.

Also, SimTime is far superior to tpf.

Even without all of that, if you choose to write a multiplayer game that can also be single player (without loop back self-hosting) then game systems are super convenient.

On the client, app states have a few distinct features: hooks for rendering, easy access to application (thus asset manager), and… no, that’s it. If the job of the “thing” is not to mediate visuals then it might be better implemented as a system. Then you can run it anywhere and don’t have a bunch of empty methods being called every frame.

Note: in Mythruna, I have a GameSystemManager on both the client and the server. There is a game system that I use to manage time-based stuff and it is convenient to have some client-side only stuff (like sky colors, etc.) controlls by the client-side system. Also, I plan to have a client-side-only ES and PhysicsSpace for some special effects that don’t really make sense as full client-server entities (think falling rubble from breaking a block and stuff like that… maybe things swinging in the wind or whatever.)

Edit: also from a “glue” perspective, I find it convenient that I can register anything as a game system even if it doesn’t implement the interface. Then it is free to look up from other systems. EntityData, World, etc. are all easily grabbable by my systems even though those things don’t implement GameSystem.


On my games I usually have a CharacterDriverSystem that manages/steers physical entities and also some pathfinding logic that goes into gamesystems.

I follow the rule: if the output/purpose of the appstate doesn’t edit/interact with the scenegraph I usually put it in a gamesystem.