Lesson 09

GameStates

This is the furthest stroll away from FUSEE as of yet, gamestates are a design choice not something FUSEE implements. But I don't want to leave you with code that isn't even mentioned.

The concept of gamestates is quite easy, you define a state like "The game is running", give it a simplified name "Running" and thing about what happens in this state: the player character accepts input, the in-game GUI is visible, the game over screen is not shown, and so on. How deep you go with it has to fit your purpose. In this tutorial we only track three states and they are quit broad: "StartScreen", "Running" and "GameOver". One could go as far as defining "OneTargetFound" and "TwoTargetsFound" but that would only limit us, so it wouldn't be a good idea.

I chose not to make this another class but to keep track of this in the GameWorld and make it flexible but still readable, using a public enum. Gamestates habe a lot to do with game logic (if you let them) so if you are going complex it can very well make sense to push this to a class and let the class control what is happening. For this tutorial we keep the gamestates pretty much in the RenderAFrame() method in our GameWorld.

Facts for this tutorial, we need to keep track of the current gamestate as well es the game state the last frame had. This way we can easiely react when the gamestate changes (a makeshift eventhandler). With a switch function we can then, so to speak, initialize our gamestates (e.g. hide the startscreen and switch to the in-game GUI, if the state switches from StartScreen to Running).

Also we have to evaluate our current gamestate. Only if our current gamestate is Running, we want to call _player.Move() and render the Targets. In any other gamestate the camera should rotate at a set position.

Since we mentioned it alot already lets move on wit the GUI.

[> Lesson 10 - GUI](Lesson 10)