Jump to content
  • Advertisement
Sign in to follow this  

Managing Game States

This topic is 2238 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

Hello All!
I have recently completed Pong and Snake in Java from scratch. These were meant to be warm ups for bigger games.
They taught me how programming games works, and a lot about graphics.
One thing I did in both that I feel that there must be a better way of doing is keeping track of what part of the game the player is in.
For example, in both games, I simply created an integer variable called state.
0 = main menu
1 = in game
2 = game over
It's a pretty simple system. Both my run() and paintComponent() method checked it every frame and performed accordingly.

I was just wondering if there was a more effective way of doing this? I've been thinking for a while about it but I can't think of anything.
Any ideas?

Thanks,
Peter

Share this post


Link to post
Share on other sites
Advertisement
yes, there is :] The state pattern - http://en.wikipedia.org/wiki/State_pattern. it's a pretty common one and it's used almost everywhere :) and I strongly suggest you check out enginuity - http://www.gamedev.net/page/resources/_/technical/game-programming/enginuity-part-i-r1947. They're a series of fantastic articles written by richard fine that covers everything you need to write a game engine :)

Have fun!
P.S - can we have the enginuity articles and a link to the state pattern stickied or something? a lot of people ask questions about this :)

Share this post


Link to post
Share on other sites
Make a base class of the States, let's say class BaseState. then inherit every state in it. for example: class MainMenuState : public BaseState. then make a class that handles the state, i.e. class StateManager. This class will just have a pointer to a BaseState. Register your real states to this manager then act accordingly. Heres a sample code.

class BaseState
{
public:
virtual void Update() = 0;
};

class MainMenuState : BaseState
{
public:
void Update();
};

class StateManager
{
private:
BaseState* current_state;
public:
void SetState(BaseState* state)
{
current_state = state;
}

void UpdateCurrentState()
{
current_state->Update();
}
};


Something like that smile.png I hope it helped you smile.png
Good day! Edited by marcjoel

Share this post


Link to post
Share on other sites
Great article YogurtEmperror..

I got something similar, but changing abit now with some new ideas from reading.. But where do you have your renderer? Do you store that in the base Game class so the Draw() can use it?

I think I might seperate it abit and have a Engine* where I store the engine resources and managers.. and a Game* for more game specific stuff.. that way I can use the Engine* in tools and have access to the resources without including game stuff..

Share this post


Link to post
Share on other sites
The best way to explain it is probably via a screenshot.
[attachment=7930:EngineOrg.png]
This screenshot has not been “posed” in any way. I simply started up my project and took a screenshot as it last appeared.
The file names across the top each begin with a prefix. LSG, LSI, etc. LSG = L. Spiro Graphics. LSI = L. Spiro Image, etc. The non-intuitive one is LSD, which stands for L. Spiro Models, since LSM (L. Spiro Math) was already taken.

On the right you see every module (library) that is compiled in order to build the actual engine. There are 15.

The Image library (LSI) handles images in a generic way. It doesn’t know what DirectX is or what OpenGL is. But it knows how to read a lot of formats and convert between formats. And resample, resize, etc.

This is an important separation because it allows tools to not know or care about DirectX or OpenGL etc.

LSE stands for L. Spiro Engine, and LSG stands for L. Spiro Graphics.
These are separate entities, each knowing about their own field of study.
LSE uses LSG, as does anything that needs to render itself (terrain and models only, basically).


So no, I do not store the renderer in the game class.
And CGame (from my post) is held within the “lse” namespace. It is part of the engine. Part of what binds all of the other modules together.

This acts as a better way to allow tools access to only what they need instead of having them rely on the entire engine for only a small engine feature.


L. Spiro

Share this post


Link to post
Share on other sites
I think your on the right track Nanook, FWIW, my code is built much like L.Spiro's, and that kind of separation has taken me a while to really get to where i'm liking it(though still hating some parts). My games/demos themselves usually contain a main menu state, an options state, and a gamestate, everything else is either data or part of the engine itself.

Share this post


Link to post
Share on other sites
Ah yes I also have it seperated like that.. I dont have that many though.. I have a core library, graphics library, physics library and engine library.. but I also have it devided into sections by namespaces.. I used to have lots of libraries too but I found it got pretty hard to maintain them all.. I also have low level renderers (OpenGL, DirectX) and a high level one..

Still abit confused from your reply though.. I mean.. where do you set up the scene for each state? Atm. I'm doing that in the Init of my states(Or actualy in my editor, but I load it from file in the Init).. I pass a Engine* to all the functions of the state (Init, Draw, ...) .. then when I call Draw on the state I do engine->GetRenderer()->Draw(m_scene); ..

So I store an instance of my renderer in the Engine class..

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!