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?
Changing Gamestates
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
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
Last edited by area51 on Tue Feb 22, 2011 1:18 pm, edited 1 time in total.
Re: Changing Gamestates
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.AshmenGlue wrote: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?
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.
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]
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]
-
- Posts: 29
- Joined: Wed Oct 12, 2005 9:09 am
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.Anonymous wrote: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.
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
You do a lot of programming? Really? I try to get some in, but the debugging keeps me pretty busy.
Crucible of Stars
Crucible of Stars