Changing Gamestates

[AshmenGlue]

How exactly do you change game states with Irrlicht (for example, main menu, game itself blahblah)?

Do I have to declare new Irrlichtdevices for every state? Or do I just add functions under the same device to switch between states? What about the EventReceiver then, surely it must be able to have different functions for the same key?

[area51]

Irrlicht doesnt nativly support the idea of a 'gamestate', as it is a rendering, not game engine.

You can however try using one of the frameworks below that support this.

http://www.technomagicum.net/projects/IrrLicht/ICE/

http://www.gameputty.com/IrrWizard/
________
Corvette c6

[Guest]

How exactly do you change game states with Irrlicht (for example, main menu, game itself blahblah)?

Do I have to declare new Irrlichtdevices for every state? Or do I just add functions under the same device to switch between states? What about the EventReceiver then, surely it must be able to have different functions for the same key?

This is a general game programming question and nothing explicitly to do with irrlicht I'm afraid. You can do this many ways though, having a "gameclass" or using a procedural approach.

A quick answer is no you do not need to have a new device for gamestates (of course) you just write your code/flow that you have whatever you need when you need it. Try global irrlicht* instances if you don't want to class everything up.

[Guest]

Consider using Function Pointers to manipulate your gamestate (there's a good article at GameDev here with an example of using them for game states at the bottom.)

Makes things nice & tidy, only one function to call no matter what state you're in, and no if statements during the game loop to choose the state.[/u]

[AshmenGlue]

Thanks. I used IrrWizard partially to work out a structure.

[hybrid]

Consider using Function Pointers to manipulate your gamestate (there's a good article at GameDev here with an example of using them for game states at the bottom.)

Makes things nice & tidy, only one function to call no matter what state you're in, and no if statements during the game loop to choose the state.

Since Irrlicht uses C++ you should use virtual methods instead. Function pointers are usually C constructs which provide the same functionality like virtual methods, but require the user to maintain the correct setup each time the state changes.

[Electron]

They don't require extra classes to use, and you can change the function pointer to point to different functions in the same object, while for a similar system with virtual functions you must create several different classes overriding the virtual function differently and create an object of each. Certainly using virtual functions is often cleaner than function pointers, but they have their place too. Some of it is a matter of preference