Game Development Community

Pause/inventory screen, state handling

by Rich Wilson · in Torque X 2D · 01/25/2007 (11:58 am) · 3 replies

How does Torque handle different game states like pause or inventory screens? Is there some sort of state stack so I can just pop the current state off when I unpause?

How do I detect gamewide input to change states like this?

#1
01/25/2007 (2:16 pm)
I'm not sure I follow by what you mean when you say game states as you're comparing the calls to the update events (ticks) with inventory (GUIs) which are completely different. GUIs are handled by creating a class that inherits from IGUIScreen. (or GUIControl if you are doing it within another class like a HUD, but an inventory probably should be it's own class IMHO).

As far as pausing, this should do the trick:

Game.Instance.Engine.GameTimeScale = 0f;

To unpause:

Game.Instance.Engine.GameTimeScale = 1f;


What 'gamewide input' do you mean? Do you want to have user input determine when the inventory shows or the game pauses? If so, just bind the keys/buttons/etc. to a method which will trigger these events to happen.




www.linkedin.com/img/webpromo/btn_viewmy_160x25.gif
#2
01/29/2007 (11:41 am)
I'm not sure how it's handled in TorqueX, but I'm used to changing states (essentially changing the pointer to the frame update function) whenever the player goes from main menu to in game to pause menu, etc. My question probably should have been more along the lines of "how does torque X handle this".

As far as the binding goes, where do I put those bindings and methods at? I've seen components I can tie to objects I drop in the editor, but where do game-wide bindings go? Also, how do I tie these input commands to the correct actions based on state (in a menu, controlling a character) or does the UI system take care of this?
#3
01/29/2007 (12:04 pm)
I think I understand now. Check out the TorqueCombat template. It uses GUI state which tells it which gui state it's in and the next one and previous one, etc. This includes any levels that exist as well.

As far as bindings. Wherever you setup the bindings dictates what is bound to what. If you set the bindings in the Game.cs (or equivelant) than it's game-wide at the game level. The GUI screens have their own commands and by binding them within the GUI class, they are local only to that GUI and it's elements.

Make sense?




www.linkedin.com/img/webpromo/btn_viewmy_160x25.gif