Advice on game architecture and GameStates

So, I've been 'stalking' the forum for a few weeks now, familiarizing myself with the examples and tests while I developed my game's design doc a bit more thoroughly. I've got to the point where I'm ready to take the dive into my own game's development and hoped to get some feedback on preferred methods of architecting a game using GameStates. The TestGameStateSystem app really sparks my interest, and I've been playing around with it for a while.



I guess the thing which I'm pretty vague on is when to and when not to use GameStates and how the scene structure should be organized. I understand how to use game states (at least the mechanics), just not sure as to when a GameState should be used. Based on the info in the wiki and posts I've read, my thoughts were to use a GameStates for parts of the scene that should be easily turned on/off, (i.e., debug info, overlayed ingame menus, etc).



Should my entire ingame scene be contained within one GameState, or should I break it down more granularly. What I'm looking for is just high-level examples of what you've found to be the best use of GameSates.



Any/all advice and suggestions are greatly appreciated. Thanks!

This depends on the game you are trying to create… In theory you can put all your game scene in one GameState, but I would suggest having many areas in your game which load independently, and have each be a GameState. In this way, your loading time should improve. There are many in-game ways to achieve this.



Some games use a corridor with two doors, the corridor itself is in both areas (or none), and then depending on where the player is, you load either of the two states, and when the user opens the door, then you just activate it. (I think this is called a portal).



Also you could have small areas and do a room per GameState, much in the style of ResidentEvil in which each room is a GameState. If you have a racing game, you could stream the areas in a more intelligent way since the order is inherently sequential, and thus you could use a queue of states, etc.



As you can see, this problem depends on what you want to achieve.

Ah, I'm glad you say this. What I'm working on is an online RPG, and I was thinking about splitting zones/maps into a GameState.

Haibijon said:

Ah, I'm glad you say this. What I'm working on is an online RPG, and I was thinking about splitting zones/maps into a GameState.


i dont agree with splitting ur maps or zones into different game states. they are all the same game state namelly "world scene", its just u r loading different models in a particular scene. this should really just be one game state.

since u r working on a MMO, one reasonable way would be splitting different game states into different game states lol.  :D
such as login state, world state, and ect...
neakor said:

Haibijon said:

Ah, I'm glad you say this. What I'm working on is an online RPG, and I was thinking about splitting zones/maps into a GameState.


i dont agree with splitting ur maps or zones into different game states. they are all the same game state namelly "world scene", its just u r loading different models in a particular scene. this should really just be one game state.

since u r working on a MMO, one reasonable way would be splitting different game states into different game states lol.  :D
such as login state, world state, and ect...
I think you meant RPG instead of MMO.
Anyways gamestates as neakor said would be the best way like that, I am designing my a bit the same way.

Teaster

Yeah, I'm not really jumping on the MMO bandwagon :wink: I'm really just working on my own little proof-of-concept game that is really just an RPG with some online elements, user interaction, etc.



Would it make more sense, then, to simply have a single GameState for each state (a state for the start menu, a state for ingame, etc) and then just have the Zones themselves exist as Nodes which live within the GameState? I'm looking for a way to easily swap maps/zones, while keeping the scene graph as tidy as possible, so I'm trying to find the most efficient way to achieve this. By having the ingame state persist across zones and maps I could, in theory, maintain the same camera and other global across all maps, or am I missing something…? I've currently based my in-game scenes off of the CameraGameState.

Yes, in that case, (unless you could have different environments like dungeons, towns, castles, etc. that are only accessible through portals) your world should be one GameState.