Sign in to follow this  
  • entries
    33
  • comments
    51
  • views
    12552

Another unexciting update

Sign in to follow this  
Metorical

28 views

Unfortunately I'm in work at 7.30am to make sure the changes I made on the servers last night don't break everything. It's in one of the most important processes so even 10 minutes of downtime would cost tens of thousands of pounds. It all works though unsurpisingly (I did only change one line of code)

I thought I'd take this oppurtunity to update my journal but yet again I don't really have anything to add. I've been doing a lot of thinking about how the game should be structured in terms of data and no great solution springs to mind. Let me take you through my current thinking

Game States
If you've hung about in the GameDev.Net forums for any length of time you've probably heard someone suggest using Game States and a State Manager. I agree with the general sentiment and think it's a great idea however I'm trying to work out some of the finer details.

First let's paint a picture. Here's some example states and how they should work.

(1). Game Menu.
(2). Gameplay
(3). In-Game Menu i.e. Options.

Now the Game starts in State 1, that's fine. When you switch to state (2) by popping it on the Game State stack then it should take all responsibility and nothing should be passed down the stack to state (1). When the player hits the In-Game Menu key however we want to draw that on top of the Gameplay and still have the Gameplay state update. I'm toying with something like this, please ignore the silly long names as I've just made them up now for the example.


class InGameMenu : public GameState
{
void Render();
void Update();
...
}

void InGameMenu::Render()
{
PropagateRender();
MenuRender();
}

void InGameMenu::Update()
{
PropagateUpdate();
MenuUpdate();
}



Now the Propagate functions will be part of the State Manager and will pass the Update/Render message down the State Stack so effectively doing a PropagateUpdate(); in the InGameMenu State will call the Update() in the Gameplay State. Therefore I can have a menu up with the game still going on in the background.

My questions are:

How should the States know about their Manager? Do I store a pointer in to the manager in every state, like a Registered With Pointer? Do I globalise the State Manager (ick)...

Each State will have it's render specific code but should it use a generic renderer task which you pass in to the state Render function?

I think I know what I'll do but if anyone has any suggestions I'd appreciate them greatly.

The Bigger Picture

So I have States... now my tasks love states. Main Loop.


GameState * pState = StateManager->CurrentState();
pState->Update(pLocalClock);
pState->Render(pLocalRenderer);
pState->ProcessEvents(pEventInfo);



Now if I change State then my state just has to push the new one on the state.


//Init the State and then Push it
PushState(pNewState);

...

//State finished
PopState(this);



But what if I want a state to persist? Perhaps I should be using named states with a persitent variable? So many questions :-)

Also the Main Update Loop is also a state! My main program just needs to initialise the StateManager and pop on the Main State. Then I can have the local data contain all the tasks like updating, rendering, time keeping, logging etc.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now