One solution might benefit this or that game, other solutions may hinder it. The truth is that most state machines are probably going to need to be tailored to the project at hand. Virtual functions rather than function pointers may alleviate that somewhat.Īnother solution to transitions and other such things is to provide the destination and source state, along with the state machine, which could be linked to the "engine", whatever that may be. State-sets instead of state-stacks does not really help this, but you should be aware of it. The GSM also, as function pointers and non-local behavior tend to do, made debugging things more difficult, though debugging those kind of large state transitions wasn't very fun before we had it either. Fundamentally, state in a game is not a stack, and states in a game are not all related. On a side project, I have had better luck with a state set rather than a stack, not being afraid to make multiple machines for unrelated systems, and refusing to let myself fall into the trap of having a "global state", which is really just a complicated way to synchronize things through global variables - Sure, you're going to end up doing it near some deadline, but don't design with that as your goal.
#Stack the states games code#
What it was good for was isolating tasks for integrating code from infrastructure programmers who didn't know how the game flow was actually structured, so you could tell the guy writing the patcher "put your code in Client_Patch_Update", and the guy writing the graphics loading "put your code in Client_MapTransfer_OnEnter", and we could swap certain logic flows around without much trouble. UI state is not a stack, it's really a DAG, and trying to force any other structure on it is only going to make UIs that are frustrating to use.)
(I would especially caution against the system for UI states. the UI system, could use it but only to copy state into their own local state systems. Most internal game systems did not use it to track their internal states, because they didn't want their states mucking about with other systems.
#Stack the states games windows#
We had several functions like "if in character creator go to gameplay if in gameplay go to character select if in character select go back to login", because we wanted to show the same interface windows in different states but make the Back/Forward buttons still work.ĭespite the name, it was not very "global".the LoadingGameplay state, so you had Base/Loading, and Base/Gameplay/LoadingGameplay for loading within the Gameplay state, which had to repeat much of the code in the normal loading state (but not all, and add some more). Loading/MainMenu, depending on if you got the main menu up before or after the loading screen (the game is asynchronous and loading is mostly server-driven).Īs two examples of things this made ugly:
My biggest problem with our Global State Machine was that it was a stack of states, and not a set of states. Probably too complicated to do anything practical with. I don't know what a stack of FSMs would look like. :)įirst, we did not have a stack of FSMs - we had a stack of states. I worked on the same engine as coderanger.
0 kommentar(er)
