   Game States
  EDIT: Please look for the last post of mine about the 22 errors for more info.Hello,I have been learning C++ for a while and have decided to start using C++ to make games. I am using the DirectX SDK and Visual C++ 2008. So, I have been reading all over on how to use DirectX to help me make games and now i'm building a game engine and I think I'm ready to start building the game I have had in mind for a while...but I’m stuck...I read somewhere about using Game States, so what exactly are Game States and how to you incorporate them into a game? This is what I understand from what I remember (if I am not remembering correct/wrong please let me know):Game States are things such as Main Menu, Main World, Cave, Pause Menu, Game Over, etc...And using game states as what I know so far help you manage what is going on and what should be going on at times a lot better. So what are these like in actual code? Are these functions like void MainMenu(params), void PauseMenu(params) or what?Also one thing that keeps making me think is how exactly to you go about moving from one state to another (graphic wise) for example from the title screen to the main game? Do you just load the graphics for the title screen once the user selects Play Game it deletes all those graphics from the title screen and loads the graphics for the Main Game?Thanks,Progames25[Edited by - Progames25 on September 4, 2008 6:11:48 PM]
  I guess the basic idea is to have a system which allows you to increase the complexity of your game without ending up with a gameloop 2^13 lines in code. One approach could be to have a abstract class Gamestate that would define a necesarry interface for required functionality. getUserInput(); applyPhysics(); renderGui(); renderScene(); playerSound(); etc. pp. Now you could implement a ton of different behaviors of your game depending on the situation the game is currently in and it would act exactly as you wanted without loosing the overview of what steps and actions are executed. Now just exchange the active Gamestate with any Gamestate you want to happen and your game will just react how you designed it to be.There's a nice article somewhere, mayb here on GD about this issue, but after looking for it for a few minutes i couldn't find it, sorry.P.S: There are a lot of approaches how to implement Gamestates, it's more like a design patter, not a fixed part of code.P.P.S: I'm not that experienced with this topic either, that's just how i did it once and also read somewhere a while back.   ;  implement a abstract class with methods like main(), onkeydown(), onkeyup(), onmousemove(), onmouseclick(), ..., and implement some game states classes,TMenuState, TGameState, ...,   ;  Thanks,I will try that out, although I have never heard of an Abstract class before, ill have to look that up.Thanks,Progames25   ;For the longest time, when I heard about game states I thoughtwhile(state != Finish){  switch(state)  {  case Intro:    displayIntroImage();    if(userPressesSpace()) state = Running;    break;  case Running:    animateObjects();    displayScene();    if(userIsDead()) state = GameOver;    break;  case GameOver:displayGameOverImage();    if(userPressesEscape()) state = Finish;    break;  }}This is probably not far from what they used back in the Commodore 64 days.An code example of what GrayHound is taking about can be seen here.You probably wont grasp much of it until you are comfortable with inheritance, polymorphism and virtual functions. Notice the first class called GameState. That is the base class for all the game states in the game. Basically it doesn't do anything except declaring the functions that its descendants will be allowed to implement. Further down you see the actual game state classes. IntroState, GameState and so on. They implement the functions given by the base class with actual content.When you have all these game state objects ready to go, what you basically do is to push them onto a stack, and the game loop just keeps executing the functions from the object at the top of the stack.Now if the player in the middle of the game presses [TAB] in order to see the current score, all you need to do isGameStack.Push(ScoreState);and to get back to the running gameGameStack.Pop();One benefit of having the game state classes descend from a base class is that they will all fit into the same stack, with no casting or ugliness required.And the beauty of using virtual functions is that the game loop doesn't have to care what kind of object it is working with, whether it be a IntroState, GameState or whatever. It will just pick it off the top off the stack and execute its virtual functions.I guess all this stuff is still over your head so I won't go into more detail.It all becomes crystal clear in the end :D   ;  Alright i'm beginning to understand this much better now, thanks for that link too. Well I think I understand what you were saying. I read about inheritance, polymorphism and virtual functions (Still reading about Polymorphism) in my C++ book (Sams Teach Yourself C++ in 21 days 5th edition) but I have never used them in any of my stuff. So when you switch out of a state you usually clean up the graphics from the last state before it shows the new graphics, correct?   ;Quote:Original post by pulpfistFor the longest time, when I heard about game states I thought*** Source Snippet Removed ***That's the usual approach, at least as far as I've seen in commercial game development. Indie game developers, at least the ones around here, seem to tend to prefer to throw a lot more scaffolding at the "problem".   ;  Wait, are you saying that game states using a while switch statement is a normal approch in commercial games?   ;  Yeh, it's pretty common in the codebases I've seen. Now, that doesn't by itself indicate that that's the Right Way -- uptake of OO has been slow in game development, and there's a lot of legacy code -- but FWIW I think it's the right approach. Tossing in State objects because that's the OO alternative to switch statements, and dealing with the data sharing problems this engenders, can result in some pretty ugly and confusing code compared to the alternative (though it doesn't have to). Go with whichever method makes you happy, but remember the KISS principle.   ;  Alright,Well all of this has helped me a lot. Now I just have to decide if I want to use a OO approach or a while switch statement approach (I can always add functions to help keep it readable)... I think for starts a while switch statement way will be better until I can get used to making games then I will know more about what kinda things to expect and what I will need in an OO approach in the future then as I discover these things I can try making classes to help with controlling states...Thanks for all the help,Progames25   