State based games
So, I'm starting my first real video game project with a friend of mine. He has much more experience in video game design then I do, but due to time zone differences we aren't allowed to communicate but once a day. Anyway, I've been designing the game and writing up a class diagram, and state machine for the game. I have states that are as follows:
Splash intro, main menu, high scores, options, gameplay, and game over.
Now, I'm not sure how these would be implemented. I know that the benefit of using a state based game is that you can split up all the drawing and rendering into separate classes and just use each class for it's corresponding state. But what all would go into these classes?
Thanks,
-Biscuit
Splash intro, main menu, high scores, options, gameplay, and game over.
Now, I'm not sure how these would be implemented. I know that the benefit of using a state based game is that you can split up all the drawing and rendering into separate classes and just use each class for it's corresponding state. But what all would go into these classes?
Thanks,
-Biscuit
I would think each class would just load the resources necessary and then let the main loop run as normal. In the case of the splash screen, you'd probably also want to disable user input (or set different handler functions so that the user can skip it).
Well, each game state needs to treat input differently anyways, so that shouldn't be the problem.
I personally suggest using a class (referred to as CScene, for now) which controls game flow and initialization of a scene. It would manage resources loaded for that scene (that is to say, game objects reference the active scene for whatever they might need) so that these resources may be automatically unloaded when transitioning from one scene to the next.
I'm going to apply the use of the CScene class to my own method of controlling game logic (which appears to be common anyway) which would be inheritance and overriding of a base class containing virtual Process and Render methods, keeping a list of these objects, and then iterating through the list and calling each respective method when appropriate.
Each instance of CScene would contain its own Instance List, where it would personally process and maintain all of the necessary game objects. This further assists in the cleanup process, as a CScene object can clear all game objects upon its completion. Persistent objects wouldn't be maintained by a CScene instance.
The initialization portion of CScene would require some mechanism for customization. You could do this via a level editor, where the CScene class would parse a pre-generated level file and allocate the appropriate instances. You could also design an initialization mechanism around function pointers and manually code the creation of objects in a dedicated, scene-specific function, passing the pointer to the CScene instance as a parameter. I'm hesitant to suggest creating an inheritable base class because, in my opinion, this just adds to the class hierarchy and muddles the architecture conceptually. But there's no real reason than that, so it's really just personal preference. Just have a virtual Initialize method to be overridden, if that's the route you want to go.
The paradigm as a whole helps with the design process, as you're no longer thinking in terms of step to step, but entire scenario to entire scenario. With state changes, conceptually, you have to alter an existing world to transition to the next one. With CScenes, you're just trashing the old one and starting anew. It's like rebooting the game. (Ignoring persistent objects, such as the rendering mechanism, settings, inventory, etc.)
I'm going to apply the use of the CScene class to my own method of controlling game logic (which appears to be common anyway) which would be inheritance and overriding of a base class containing virtual Process and Render methods, keeping a list of these objects, and then iterating through the list and calling each respective method when appropriate.
Each instance of CScene would contain its own Instance List, where it would personally process and maintain all of the necessary game objects. This further assists in the cleanup process, as a CScene object can clear all game objects upon its completion. Persistent objects wouldn't be maintained by a CScene instance.
The initialization portion of CScene would require some mechanism for customization. You could do this via a level editor, where the CScene class would parse a pre-generated level file and allocate the appropriate instances. You could also design an initialization mechanism around function pointers and manually code the creation of objects in a dedicated, scene-specific function, passing the pointer to the CScene instance as a parameter. I'm hesitant to suggest creating an inheritable base class because, in my opinion, this just adds to the class hierarchy and muddles the architecture conceptually. But there's no real reason than that, so it's really just personal preference. Just have a virtual Initialize method to be overridden, if that's the route you want to go.
The paradigm as a whole helps with the design process, as you're no longer thinking in terms of step to step, but entire scenario to entire scenario. With state changes, conceptually, you have to alter an existing world to transition to the next one. With CScenes, you're just trashing the old one and starting anew. It's like rebooting the game. (Ignoring persistent objects, such as the rendering mechanism, settings, inventory, etc.)
Last edited on
If you want a simple and clean implementation for this, you can check out the Director and the State class in my engine.
http://code.google.com/p/sfgengine/
http://code.google.com/p/sfgengine/
Topic archived. No new replies allowed.