'DasFool' said:
One thing I remember having to do when implementing pause was to make sure you stop any timers while the game is paused. Otherwise the timers would continue counting and the player would end up losing.
This could be archieved with the "onPause" "afterPause" methods I suggested.
ok you win, I'll look into it after my shift on Sunday... unfortunately for me I have to get ready for my evening shift soon and then I'm working daytime tomorrow... blah.
I actually thought a bit more about this. Making the pause screen a separate state has other perks as well. It can be easily made into an in-game menu. This is when I thought up, that BaseState should be aware of its engine via a pointer (set with a method "void setEngine(Engine* const engine)"). If the engine then had a method "setPauseable(bool const value)", games could control when they can be paused and when not. Other kind of callbacks could be made, such as moving to a specific state (like main menu) and changing settings.
The actual switching between the pause state and game state would be done by swapping "activeState" and "pausedState" pointers. As the switch is made, "afterPause" is called for the new "activeState" and "onPause" for the new "pausedState".
If this doesn't seem to make sense, ask or do as you please
. I'm not about to hijack this project or anything. B)
Wouldn't it be better for the constructor to be passed the state's engine? That way we know for a fact that it has a pointer to its engine. If it was simply a set method, null pointer exceptions could occur if something is done with the engine before it's set.
Well, it's a matter of convienience. If it was in the constructor, all of its subclasses would have to implement a constructor where they call it. This would result in more copypaste code in the game classes. It would still be possible to get null pointer exceptions (you can get an invalid value for the constructor, or the subclass can implement the constructor wrong), but then you'd several more places where it could occur. At least this way you set the pointer in one engine side spot after which you can be sure its set regardless of the game class code.