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.

I use multiple render loops, which you have already pointed out.
Not sure how everyone else does it but it works fine for me.

Dreddnafious Maelstrom

"If i saw farther, it was because I stood on the shoulders of giants."

Sir Isaac Newton

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]

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?

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.

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