Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 07:05:20 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Managing Game States
Pages: [1]
Print
Author Topic: Managing Game States  (Read 1255 times)
badrobit
Level 0
**



View Profile
« on: September 23, 2016, 09:49:45 AM »

I am currently working on a simulation game engine and I am looking for input on how people manage game states. My first thought is to use state machines but I am not sure if this is the right approach and how exactly one might implement this. Any reading or resources you could point me towards would be much appreciated.
Logged
motorherp
Level 3
***



View Profile
« Reply #1 on: September 23, 2016, 10:54:54 AM »

I generally just go for a really simple state machine, something along these lines:

Code:
class State
{
public:
virtual void Initialise() = 0;
virtual void Update(float deltaTime) = 0;
virtual void Shutdown() = 0;
};


class StateMachine
{
public:
StateMachine(State* pStartState)
: m_pCurrentState(nullptr)
, m_pNextState(pStartState)
{
}

void SetNextState(State* pState)
{
m_pNextState = pState;
}

void Update(float deltaTime)
{
// change state if one is queued
if(m_pNextState)
{
if(m_pCurrentState)
m_pCurrentState->Shutdown();

m_pCurrentState = m_pNextState;
m_pNextState = nullptr;

if(m_pCurrentState)
m_pCurrentState->Initialise();
}

// update current state
if(m_pCurrentState)
m_pCurrentState->Update(deltaTime);
}

private:
State* m_pCurrentState;
State* m_pNextState;
};

I queue the next state until the next frame so that I don't end up potentially shutting a state down part way through an update which can cause headaches.  Obviously you'll need to manage the memory on your states but if you don't want them to be persistent then you could delete them after the shutdown.
« Last Edit: September 23, 2016, 11:00:24 AM by motorherp » Logged
Cheezmeister
Level 3
***



View Profile
« Reply #2 on: September 23, 2016, 04:04:32 PM »

Really depends on the rest of your infra and what your game is like.

Ask yourself how many states you need to manage, and how deeply. If it's just a handful, state machine is probably overkill. If it's dozens with complex transitions, it might be worth it.

Ask yourself whether you want your states to draw themselves, or have some sort of master renderer that knows how to interpret each state.

I had decent success in Chromathud with a simple stack of states that knew when to switch to other states and how to draw themselves. Had a splash screen, start/options menu, several game modes and a pause menu, with fade animations. Found it easy to add new states as needed, no unwanted crosstalk. C#/XNA but same ideas apply. I think if I had needed any more complexity, for example, switching directly between game modes, this would have gotten hairy.

https://github.com/Cheezmeister/Chromathud/blob/master/Chromathud/Chromathud/FacetManager.cs
Logged

෴Me෴ @chzmstr | www.luchenlabs.com ቒMadeቓ RA | Nextris | Chromathud   ᙍMakingᙌCheezus II (Devlog)
badrobit
Level 0
**



View Profile
« Reply #3 on: September 23, 2016, 07:56:53 PM »

Thank you guys so much! I think this is just the thing I need to get started! I think there will be enough different core screens within the engine to warrant a state machine and that any games using it will definitely cause this system to be required. Thanks for the awesome starting point!
Logged
pturecki
Level 0
***



View Profile WWW
« Reply #4 on: October 03, 2016, 02:42:30 PM »

Quote from: motorherp
I queue the next state until the next frame so that I don't end up potentially shutting a state down part way through an update which can cause headaches.
This is great advice! In our game I don't queue state changes to the next frame and it really caused a lot of headaches and 'stupid' errors Wink At the moment everything is working well but I'm thinking now about rewritting this to avoid future headaches ;P
Logged

rozza
Level 0
**



View Profile WWW
« Reply #5 on: October 07, 2016, 09:13:16 PM »

I wrote a state machine system for C# a while back that you can check out if you like - https://github.com/Real-Serious-Games/Fluent-State-Machine. Obviously it won't work for C++ but a lot of the design would carry over pretty well if you're making your own system.

Basically, it's a hierarchical finite state machine so each state can have children and you can push and pop from the state stack. Each state has functions for when it's updated as well as when it starts and ends, and the ability to respond to custom events so you can send an event with an ID without knowing what state is active and it'll be picked up by whatever is the current state.

I've found this system pretty robust for managing overall game state or player state, as well as being useful for things like simple AI.
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic