Global Game State FSM

[jasonmirk]

Hi,
I have been using playmaker for a while and was wondering if it should be used for game scope states. I don't see examples of people using it for this just for FSM attached to objects to perform simple things. I was wondering if it would be good for a game scope FSM that would survive load levels and would load menus, play states, win states, lost states etc.

thanks.

[jeanfabre]

Hi,

 Of course. I do that ALL the time It's actually a very important pattern to master to get anywhere in large projects.

 I even use xml as the data back end, so in your typically cut the rope game, all the user data, progress, score etc etc is stored in an xml in the app resources. and access at runtime when needed. and I write back to the xml when the user data has changed ( new score, new progress, new unlocks etc etc).

and that is ALL done via gameobject that persists throughout level loading and the user navigation.

the main reason is to prevent redundant data access, once you have your user data, it's not cool to get it again ang again on each level load isn't it...

the second very important reason is that you can better edit and work on your games and levels, coupled with "singleton" approach, you can have a prefab sitting on EACH level, but at runtime, only one will be there at any time and on each level load, redundant prefabs are destroyed.


bye,

 Jean

[jasonmirk]

Thanks Jean. Will look further into this. Was afraid that people didn't use it for performance issues or something like that.

[Broken Stylus]

Hi,

 Of course. I do that ALL the time It's actually a very important pattern to master to get anywhere in large projects.

 I even use xml as the data back end, so in your typically cut the rope game, all the user data, progress, score etc etc is stored in an xml in the app resources. and access at runtime when needed. and I write back to the xml when the user data has changed ( new score, new progress, new unlocks etc etc).

and that is ALL done via gameobject that persists throughout level loading and the user navigation.

the main reason is to prevent redundant data access, once you have your user data, it's not cool to get it again ang again on each level load isn't it...

the second very important reason is that you can better edit and work on your games and levels, coupled with "singleton" approach, you can have a prefab sitting on EACH level, but at runtime, only one will be there at any time and on each level load, redundant prefabs are destroyed.

That's going to be a huge necro but I think it would be useful to provide more information on this process, notably on the overseer FSM (likely part of your Main) that sits apart from all the other loaded and unloaded scenes.