« first day (3586 days earlier)      last day (1437 days later) » 

user92578
4:08 PM
Has anyone figured out a superior pattern for game state management? My current implementation I ported directly from my old code base, uses an IState interface & an enum for the state type matching, but I feel like this is very unsafe as I'd have check against the enum followed by casts to the (hopefully) correct state instance type
 
user92578
The enum I could perhaps replace with std::variant, however this creates a cyclical dependency, as a StateManager is formed from a set of states, but those states are owned by the StateManager & need a reference it to be able to change the current state.
 
user92578
I also used the Enter/Exit pattern, which I feel like should be RAII instead -> but this brings me to whether or not the whole state management should be a stack instead of a variant? Stack would flow into pause menus nicely, and while popping a single state to continue gameplay is nice and easy, jumping back to main menu N states back in the stack might not be as nice?
 
user92578
I know what I have works, but I really also feel like it could be improved a bunch in terms of type safety
 
genaray
genaray
11:24 PM
@Tyyppi_77 What exactly is game state management ? Just curious...
I also ran into a new problem... this time its about saving, loading and updating "ECS"-Entities to the database... The SQL stuff is no problem, the architecture is... I could simply attach a "Save" or "Update" Component to the entities depending on their state... but due to performance i need to batch the sql statements and if a entity is not able to get saved yet... it would break the whole sql query
Any ideas we could save entities in a ecs in a dynamic way ?
 

« first day (3586 days earlier)      last day (1437 days later) »