Jump to content
  • Advertisement
Sign in to follow this  
darknebula42

GameState mangement

This topic is 3712 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a game state class like this:
class GameState {
public:
   GameState(Window&);
   virtual void update();
private:
   Window& window; // window holds input events and states
};


I have my window class holding a GameState pointer to the current game state. Should I couple my GameState pointer with a Window, or is this bad design considering a Window doesn't really have anything to do with a GameState. Should I decouple them? It does however make it easy to switch game states while maintaining the Window instance...

void TheGame::update()
{
   // ... change game state
   delete window.gameState;
   window.gameState = new MainMenu(window); // back to main menu
   return;
   // ...
}


Is it safe to delete an object while still in one of its member functions, but quickly returning afterwords? I also have an issue with the whole: window.gameState = new GameState(window); It feels redundant to me, having to specify window twice, a pointer could solve this by having a method from window set the pointer, but it doesn't make sense from a design standpoint (to me) to have a gameState who can change it's own Window, hence the reference? Any comments are greatly appreciated. Especially any insight of the quality of the design. Thank you.

Share this post


Link to post
Share on other sites
Advertisement
To decouple the Window from the GameState you can create an interface for InputEvents and make the Window class implement that interface. Then the GameState can take a reference to the InputEvent interface and it will only get the information it needs from the window instance.

I'll leave the design questions for someone who knows more about it ;)

Share this post


Link to post
Share on other sites
Personally I wouldn't hold a reference to the window
I'm guessing you have your game state's and you have some form of state machine to manage your states.

Why not put the window in your state machine, and the game state simply holds a pointer to the state machine.

I would only put state specific data in to the state class.

so you would have something like:


class Game
{
public:

GameState** gameStates;

// variables common to all states
Window window;
};

class GameState
{
public:
GameState(Game*)

protected:
Game* stateMachine;
};

Share this post


Link to post
Share on other sites
I would define the communication as follows.

Base Layer <--> State Machine <--> State

Event (such as window events, keyboard input, networking etc) are passed from your base layer to the state machine. Each State can define which events it listens to from the State Machine. The state machine can also go up and down the state stack.

I have a stack of gamestates like this:

Options menu (player is reconfiguring their keys)
Gameworld (the game being player)
Multiplayer instance (a data layer to synchronise across clients)
Main menu (where the player started when they opened the game)

1. Keyboard event (used presses 't')

a. Base layer reads event
b. Base layer sends message to state machine with event information
c. State machine passes event on to top state that has told the state machine that it would like to handle keyboard events.

2. Network event (new packet of data)

a. Base layer reads event
b. Base layer sends message to state machine with event information
c. State machine passes event on to top state that replies saying I'm not handling that.
d. State machine passes event to next state in state stack to ask if it will handle it.
e. Eventually state machine talks to networking state layer and the event is handled.

Window is part of the base layer as it's just a source of events you want to handle.

Going the other way (say you want to draw to the window or send a network event)
you use an interface on the State Machine to pass messages back to the base layer. You can let lower states in the stack call the methods first if the state above them allows it so you can draw your game screen then option screen on top of that.

Share this post


Link to post
Share on other sites
Metorical, that is exactly what I want! Very nice design. I wish I could of come up with it... I think that it's what I wanted but I couldn't design it. Thanks again.

Share this post


Link to post
Share on other sites
The way I have it implemented is by using both a TaskManager and a GameStack. Using this system I can decouple everything, and just provide the window to what is really important for reading input: The InputManager, a derived class from Task.

This is how I have it done:
The Engine has a TaskManager object, which is basically a 'scheduler' holding all sorts of important tasks. These tasks are a NetworkTask, InputTask, but also Timers, etc. Basically everything that should be run every frame, but I can't be arsed with managing around, but what should be around most of the time.

Next, I have a GameStack, which is basically a stack holding GameStates. When I create a new gamestate, I push it onto the state and my engine automatically deactives the previous state and activates the new one. And when my current state is done with whatever it's doing, it just does an engine.GameStack.Pop(this); and the game re-actives the previous state(or exits when the stack is empty).

The advantage of a stack-based approach is that you don't need to remember what the next state will be, the game just remembers it.

Try to de-couple as much as possible, as this will turn into a fairly re-useable base framework for next games. I have a basic Engine class with all these components, and starting a new game is nothing more than creating a new GameState, initializing my favourite graphics API and add stuffs to the gamestates.

Toolmaker

Share this post


Link to post
Share on other sites
So... how about this A game has a "Core" class that is a singleton that holds delegate interfaces to core game components, which can implement specific implementation based strategies for input and rendering. It just feels strange to me, because that design almost feels like I just made all my resource managers global variables...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!