Timeline for Game state management techniques?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 5, 2020 at 12:06 | comment | added | fionbio | Excellent write up here: gameprogrammingpatterns.com/… | |
| Jun 7, 2011 at 7:00 | comment | added | vargonian | This is really great, thank you. A key point you made was in your latest comment: "using a FSM does not need to be a hassle." I had erroneously imagined that using a FSM would involve using switch statements, which isn't necessarily true. Another key confirmation is that each state needs a reference to the game engine; I wondered how this would work otherwise. | |
| Jun 7, 2011 at 6:54 | vote | accept | vargonian | ||
| Jun 6, 2011 at 19:38 | comment | added | ghost | I would think this greatly depends on how the code coupled together. I can imagine a clean separation between selecting a piece and a destination (mainly UI indicators and input handling), and an animation of the chess piece towards that destination (a whole board animation where other pieces move out of their way, interact with the moving piece etc), making the states far from identical. This separates responsibility, allowing for easy maintenance and even reusability (intro demo, replay mode). I think this also answers the question in showing that using a FSM does not need to be a hassle. | |
| Jun 6, 2011 at 17:59 | comment | added | Kylotan | From what I can gather, this is the sort of thing that the question is explicitly -not- asking about. That's not to say you couldn't handle it this way, as you certainly could, but if all you wanted to do was disable the input temporarily I think it's both overkill and bad for maintenance to derive a new subclass of CGameState which is going to be 99% identical to another subclass. | |
| Jun 6, 2011 at 14:53 | comment | added | PrettyPrincessKitty FS | C for Class? Ew. However, that is a good article - +1. | |
| Jun 6, 2011 at 8:02 | history | answered | ghost | CC BY-SA 3.0 |