GameState manager SO

Hi.
I am looking into this task: Codecks

I’ve found GameState SO, and decided to expand it a bit.
What I’ve done:
I renamed the GameStateSO to GameStateManagerSO, because it will now have a bit more logic.
I made a scriptable object for every game state and named it GameStateInstanceSO
I marked GameState enum with flags attribute and made property drawer.
GameStateInstanceSO looks like this:

And GameStateManagerSO look like this:

The idea is that we can now assign which states we can transfer to and from (basic state machine, we can mark with enum flags in editor) and call some logic (e.g. SO Events that are already implemented) on enter and exit state.

What do you think about it?

I need to check this more thoroughly, but I’m not sure we need an OnStateEnter and OnStateExit at the moment.
The Game state is a way to know if the player is able to interact with a character, Start cooking, combat or Is in cinematic mode.
Some game states can’t be active at the same time. The GameStateSO contains the information on the Current State, and following that information we decide if we can transition to the next one.
Your improved logic might help with that, while at the same time adding a level of complexity by introducing new SOs.

The real problem we’re facing with the current logic is : When an enemy enters Alert state, the pig chef shouldn’t be able to talk to a character. That said: if two enemies enter Alert state and only one of them exits that state, the current logic doesn’t acknowledge that we’re still in the second Alert state.
Do you think that your solution can take care of that?

Ah, I see. The example of the problem made it more clear.
First idea is to keep count of “state users”, eg enemies sends events to increase count of combat state when they enter their alert state, and decrease when they exit. So we can change game state only if there are no users.
You mentioned that some states can’t be active at the same time. Does it mean, that some states can?
And about SO for every state: I think we can get rid of them and just use serializable class

The idea of having a combat state count is the one we were thinking about as well.

Dialogue and Cutscene can be active at the same time if I remember correctly.

My question is : Why do we need serializable class? Why not only enums? Do we have any additional information we need to keep for the State ?

I was thinking about serialized class to keep canTransferTo and canTransferFrom settings. I added them because found
If not cutscene
Change to dialogue
And decided to move that and any other such ckecks to game state manager.
But now I’m starting to think that dialogue and cutscene have some special relationships if they can be active at the same time

Rectification : I discussed with the team and there are only one active Game State at a given point.
Disregard what I said in the last post