Whilst looking into game-oriented applications of programming patterns I discovered a question on this site which suggests that a 'set of states' is superior to a 'stack of states' but does not clarify how a 'set of states' would be applied.

A stack of states is simple enough to comprehend - the state on the top is the active state.

But what exactly is a set of states? A set as I understand it is merely a collection of unique objects (i.e. there are no duplicates). Presumably all the states in the set are currently active. But sets are unordered, so how does one maintain order in an unordered collection? An ordered set could be used, but that then brings the question of why use a sorted set and not a list - what benefit does the uniqueness bring? I'm just not sure I can imagine how such a thing would be implemented or what benefits it would bring. (Presumably the former issue is causing the latter).

So what exactly is a 'set of states'? (In the context of game design/programming).


1 Answer 1


From user744's answer:

e.g., .../MainMenu/Loading was different than .../Loading/MainMenu,

In the second case, when Loading completes, it will pop MainMenu and, presumably, push GamePlay to replace it. The resulting stack would, then, be Loading/GamePlay. MainMenu has disappeared and the Loading screen never goes away.

After Loading completes and GamePlay starts, the user may load again:


The second Loading actually needs to, first, cancel GamePlay, destroy the world and unload any unused resources. Without peeking, Loading doesn't know what precedes it in the stack and that is the reason he had to add the LoadingGamePlay state (Re: "ugly #1"). This would presumably re-load the world without destroying a bunch of resources just to turn around and recreate them.

It sounds like he was forced to add a large number of band-aids for many similar issues he encountered along the way and they eventually outweighed the benefits he envisioned from using a stack.

As a set of states:

if (currentState & 0x01) MainMenu;
//Not elseif because User744 allowed simultaneous MainMenu and Loading
if (currentState & 0x02) Loading;
else GamePlay;

The set is still serviced in a stack-like manner but, now, Loading, can be specifically disabled by any state, at any time; you don't need to know where in the stack it is or what's in-between it and the top.

currentState &= ~0x02; //Disable Loading (from anywhere)
currentState |= 0x01; //Show MainMenu (from anywhere)

The function pointers can point to sub-sets and/or sub-stacks:

if (currentState & 0x01) Menu;

Where Menu privately tracks which menu(s) are enabled/visible/active with its' own set/stack.

if (currentMenuState & 0x01) MainMenu;            //Only one
else if (currentMenuState & 0x02) Options;        //of these
else if (currentMenuState & 0x04) KeyBinds;       //three
if (currentMenuState & 0x08) SaveOrDiscardDialog; //and possibly this one

Options or KeyBinds can invoke SaveOrDiscardDialog.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .