Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

BauerGL

Way to choose gamestate?

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

Hi, which way whould be the "best" to switch between different gamestates, to switch between initialize, menu, gameloop, single player game, multiplayer game, etc etc. I need something to split my game up in pieces. I''ve thought of making a variable which changes value (duh), like "Gamestate = Menu, Gamestate = SingleGame" etc, and then use a switch(Gamestate). Although that doesn''t sound too good :]. So if anyone got an idea feel free to post it =). Thanks. /* The only difference between a genius and a madman is the success. */

Share this post


Link to post
Share on other sites
Advertisement
I don't know about the "best" way, but you could try having a function variable (probably not the official name), basically a variable which just stores a pointer to a function. This would be your render function, then each time through the main loop, you use this pointer to call the right function. When you want to change states, change which function the variable points to.
Unfortunately, I don't know how you would do this in C/C++, as I use Delphi, but it should be possible.

John B

Edited by - JohnBSmall on January 30, 2002 4:59:36 PM

Share this post


Link to post
Share on other sites
I''ve done it your way before (making a enum and a variable that can equal render, init, etc.). Probably not the best for performance. Now, I call my Init functions in the beginning of winmain. After the createwindow crap, and the init functions, it enters the message loop, which calls GameMain(). GameMain then calls all in-game functions such as rendering map, rendering models. (thats all I have in my engine).

Share this post


Link to post
Share on other sites
aarrg!! I hate horizontal scroll bars!! BaShildy please don''t post things as wide as that

Share this post


Link to post
Share on other sites
Could people please refrain from posting so much code? If it significantly exceeds a single page, post a link to it.

Furthermore, posting that much code doesn''t usually help as its easier to derive structure from abstractions. Did we really need all the function definitions? This is a pet peeve of mine - ie, I''m pissed!

[ GDNet Start Here | GDNet Search Tool | GDNet FAQ | MS RTFM [MSDN] | SGI STL Docs | Google! ]
Thanks to Kylotan for the idea!

Share this post


Link to post
Share on other sites
I''ve been wrestling with the problem myself for quite some time... What I''ve ended up doing is the whole enum{MENU,INGAME,GAMEOVER} thing. Someone mentioned that it is slow. Why would a switch/case be slow? It''s one If/Then call each frame to call the right function for what state you are in. Would it really slow it down that much? Personally I find it works rather well. For each function I call I will usually have a separate h/cpp file for clean code. Makes very organized. h/cpp file for menu code, startup code, in game code. Only real problem is that I end up with hundreds of global variables... But what is the performance problem with doing this?

Always remember, you''''re unique. Just like everyone else.

Share this post


Link to post
Share on other sites
There''s not really any performance issues (it is just one switch statement per frame after all), but there are tidier ways of doing it.

I usually have something like
  
struct GAMESTATE
{
short stateID;
void (*Draw)();
void (*Update)();
bool (*Init)();
void (*Free)();
void (*Input)();
};


(That''s how you do C function pointers btw)

Then a function that assigns functions to those pointers for
each enumerated game state. Essentially it''s just moving the switch into a one-time function, but I find it encourages a bit more structure in my state-changing code.

Share this post


Link to post
Share on other sites

  • 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!