Archived

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

switching game modes

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

What is a good way to change game modes? By "mode" I mean a state in the program such as the title screen or in-game or weapon selection etc. Some ideas that come to mind are writing a different renderScene() and processEvents() function for each mode and then call the appropriate function depending on the mode (with, say, a switch statement or maybe function pointers). Instead, maybe have a separate thread or process for each mode and terminate the running thread or process and activate the new thread or process to change modes. This seems like it would be the most intuitive way, but I don''t know how well libraries like OpenGL or SDL respond to calls from different threads. Is this even an issue or do I have the whole idea wrong? If I''m on the right track, what are some common ways used in commercial apps? What is your preferred way and why? Thanks for your help.

Share this post


Link to post
Share on other sites
Google for the "state design pattern". There are a couple of good references out there (maybe OOTips, I think?).

In short, you represent a finite state machine as a set of classes. Each state class has virtual "create", "destroy", and "update" functions. You can switch between the states whenever you want to change modes, destroying the old state and creating the new state in the process.

If you know Delphi (or Pascal) then you can have a look at the post I wrote over at Softbeat''s forums.

Share this post


Link to post
Share on other sites
If you really want to get spiffy, you can set up a form-based system with a rectangular control that represents a scene and point it to the object that holds the rendering function used for that scene.

Then your mode is determined by which form you have open.

I went hog wild trying to write a very generalized game engine a couple years back. The scene methodology worked quite well. It's an easy way to incorporate a radar screen and other smaller scenes on top of larger scenes (multiple scene controls on a single form).

It takes a lot of work to set it up, but I only had to program it once. After that, it's just setting up the forms and control shapes on initialization. Along with all the functions to parse for control events and writing the individual render routines, of course.


[edited by - Waverider on August 30, 2002 4:47:40 PM]

Share this post


Link to post
Share on other sites
hmmm, I have a very n00b way I think, but...
I make a Enum gamemode { pause , ingame , startmenu }
then I have in the gameloop the checking that calls different functions

while(1){
....
switch(gamemode){
case pause:
pause_render();
break;
....
}


somthing like this

Share this post


Link to post
Share on other sites
quote:
Original post by Alimonster
Google for the "state design pattern". There are a couple of good references out there (maybe OOTips, I think?).

In short, you represent a finite state machine as a set of classes. Each state class has virtual "create", "destroy", and "update" functions. You can switch between the states whenever you want to change modes, destroying the old state and creating the new state in the process.

If you know Delphi (or Pascal) then you can have a look at the post I wrote over at Softbeat''s forums.



I don''t know Delphi or Pascal, but I like your post. It was rather informative. Is it possible to implement that singletom pattern with c++ classes?

Share this post


Link to post
Share on other sites
quote:
Original post by Pipo DeClown
hmmm, I have a very n00b way I think, but...
I make a Enum gamemode { pause , ingame , startmenu }
then I have in the gameloop the checking that calls different functions

while(1){
....
switch(gamemode){
case pause:
pause_render();
break;
....
}


somthing like this


This looks like my first (and current ) attempt, but this can get messy quickly. I was hoping there would be some kind of proven methodology for this kind of situation (since it is so common) that is a bit more elegant.

Share this post


Link to post
Share on other sites
Hi!

I have a class called GEGameState, my game levels and other screens are derived from it.

Then i use a stack to push the current game state onto it, i create the new game state, init it,.... and if the new game state finished i destroy it and take the last from the stack.
Its also possible to free the resources needed by the game states on the stacks and reinit the game states and their resources when coming back (like application deactivation/activation pressing alt-tab).

McMc

Share this post


Link to post
Share on other sites