GM Riscvul here! Another week another post! Before I dive into the topic for today, lets give a brief update on progress...

GM Riscvul: Buried in vicious homework assigned by his Algorithms and Complexity Class, recently has dived into documentation for the Lidgren Networking Library in order to implement LAN gaming and the networking screens.

Corndog: Too embarrassed about the lack of sprites to show off his rapidly developing character objects. Currently implementing camera movement.

Now on to Game State Management. This has been my department since the beginning of the project. State management is not unique to games as it is based off the idea of a state machine which has existed from the beginning of computer engineering. I will spare the wordy definition and call a state machine a collection of states with a starting state and at least one final state. Each state itself is related functionality which loops unless a transition occurs.

Okay so that was boring, now lets apply this to games. A game is easily defined as a state machine or collection of states. What states you ask? Well lets look at the average game... When the game starts we see a start screen waiting for us to push start to continue. Once we push start we move into a menu where it waits for us to select an option. From the menu we move into the game and play around for a bit. We push pause and transition into the pause menu. The pause menu waits for us to push buttons and so on... Each one of those screens is a separate state which loops and waits for specific inputs to transition to a new screen (state). A key aspect in game design is managing these states and making them play nice with each other. The picture below known as a flow chart illustrates relationships between game states.

How is this done in Gunslingers? Well I started out with some help. The XNA site has downloadable code for game state management. This provides a great starting point as it is easily expanded to contain more screens and functionality.

Three classes make up the management in this code: InputState, GameScreen, and ScreenManager. InputState handles all cross-screen input or input required to access other screens and trigger transitions (i.e. the escape key). GameScreen provides an inheritable bunch of essential functions for any screen in the game. ScreenManager does the hard work. It shifts screens around, triggers transitions, closes screens that should no longer be up, and in short helps the programmer out alot. Any new screens you wish to add simply need to inherit from GameScreen and be added to the ScreenManager's screenList.

Adding functionality is also easy. Editing ScreenManager allows one to change tranistions and timing. Editing InputState allows you to add new cross-screen inputs. I implemented mouse movement and picking as well as a console command.

Another nice thing about the GameStateManagement code is it gives you a menuScreen class that makes it easy to build menus. Simply inherit from MenuScreen instead of GameScreen and add menuEntries to the screen. InputState takes care of menu navigation.

Once the network screens are ready I will present a video tour of the menu system to give a visual idea of how state management works. Anyways so much more networking and homework to tackle.