• Paused game - When the game is unpaused, you'll want to pick up where you left off on session time. Otherwise, if you pause the game for 3 seconds, you'll get 3 second's worth of game behavior in the instant you unpause the game! Just keep track of the session time that was in effect when you paused the game, and use it as an adjustment to the conversion constant when you unpause the game again. Multiplayer environments should not allow pausing unless EVERY machine pauses and EVERY machine unpauses in a coordinated fashion.
• Large elapsed time since last tick - Sometimes loading resources or starting up the CD-ROM can cause a game to have a very large amount of time elapsed before the next tick takes place. Some games accommodate this by only allowing a maximum amount of time to pass for each tick as the session time slowly catches up to where it should be. This gives the effect of everything on the screen suddenly moving at increased speed and effect until the session time catches up. This should only be done in extreme circumstances, because it would be very annoying to have this happen all the time in a game where, for example, you need to maneuver ever so delicately to bring an enemy craft into alignment of your machine gun! Alternatively, you could just clip the elapsed time to a given maximum, but be aware that in a multiplayer environment, this would throw off your session time from everyone else's!

Other things to consider to add more functionality to your session time submittal routine include the following:

• Time speed adjustment - Sometimes you may want to allow the time to be sped up or slowed down. A simple multiplication on the elapsed time is all that is necessary to simulate that. If there is a decimal after the multiplication, save that and use it to adjust the next multiplication to maintain accuracy of time. This gives the effect of slow motion (a great effect in Max Payne!) or sped up action to allow faster mission progression (such as that in X-Wing and TIE Fighter). These adjustments should not be allowed in a multiplayer setting because it would severely unsynch everyone's session time as some players speed up and others slow down.
• Once the session time is submitted to the game loop, it becomes the time frame on which everything occurs on that tick. There may be other circumstances, however, that require that the pure system clock be used for certain timing issues that lie outside the realm of game state timing. One circumstance that comes to find is the timing of double clicking a control, noted below.

Ability to Poll Common Input Devices

Naturally, in order for a game to be a game, the player must have a way to interact with what they see on the screen. The most common devices used for this purpose are the keyboard, mouse and joystick. A strong engine will allow all three of these devices to be used.

The DirectInput API is the best used for this purpose. Hide the DirectInput calls from the programmer and provide wrapper functions so that the system object can take care of itself. The programmer should never need to know about the DirectInput API once this object is set up.

Ultimately, the result of the polled controls result in the following:

• Menu effects - Cursor movement, button presses, etc.
• Information entry - Text boxes, etc.
• Game effects - Maneuvering, command activation, etc.

To further complicate matters, some game designs might demand that while a text box is up that you are typing chat messages in, the arrow keys on the keyboard might be needed to maneuver your craft. As a result, it isn't enough to simply tell the System object what kind of operation a particular device is being used for. Rather, a device input map has to be prepared for every case. For example, you may tell the System object that all alphabetic keys and the space bar are to be used only for text entry. All the numeric keys are to be used exclusively to fire off menu controls (for buttons that might be hotkeyed, as an example), and the rest of the keys are to be routed to game effects. Your engine should offer some default possibilities for these maps, and allow the programmer to create their own that can be assigned to the devices. Once the maps are set up, you just tell the System object which map is currently active, and the code you write into the System object does the rest.

You should support clicks (a single "up" to "down" transition), double clicks (two presses in quick succession) and holding (is the control down or up?) of controls as boolean values. Keyboard keys and buttons meet this criteria. Mouse and Joystick axis values can be stored separately as numeric values. Special cases for axis conditions can also be set up, such as "Joystick pressed up" or "Mouse moved left", which would be stored as boolean values. It is important to use the control templates to guide the System object to determine if the given control should even be stored in the given device data. For example, if the 'A' key is pressed, and the template map says that 'A' is a hotkey for a menu control, then it will NOT be submitted into this boolean array. Instead, it will be sent as a message ('A' keydown) to the menu system to be decoded there. Also, the delay for double clicks should be variable, with a default value initialized. The elapsed time between control clicks (NOT adjusted at all for slow motion, fast motion or catchup!) is used to detect the double clicked event. After a game tick is done and all controls are interpreted, all click and double click boolean values should be cleared.

The boolean values are important to detect game events. Once the boolean values are set up, another array that keeps track of exactly which boolean values to look at for game effects is used to determine which game effects are taking place. "Jump" might be keyed to the space bar, so that slot has a pointer that points to the boolean value in the keyboard array that holds whether or not the space bar has been clicked. It is possible that more than one value could throw off the same effect, so you should support multiple slots of boolean pointers and just OR the values together to see if any of the controls are activated for that game event.

It is possible for a single control to have multiple effects with different states. For example, in TIE Fighter, the second joystick button, when clicked, allows you to target the craft straight ahead. When the same button is held, it allow the craft to spin when the joystick is pressed left or right, while up and down affects the throttle. The design I've mentioned supports this feature. One game event, "Target click", is keyed to the boolean value "Second Joystick Button Clicked". Another game event, "Joystick Button 2 Mod", is keyed to the boolean value "Second Joystick Button Held".

The Mouse and Joystick values, along with any other values affected by the game events, can be referred to by the rest of the game engine to throw off other effects, such as the maneuvering of a craft. Only the mouse or joystick axis values should be used, never both - take the greater of the two, store the value in a separate location, and use THAT for your adjustment. Code that logic in the meat of your game engine, not the System object.

If there is a special key combination you want to set up for minimizing the application (such as Ctrl-Esc), check for that first before anything else. It takes precedence no matter what the mapping is.

Finally, there is the matter of making modification of the game event array possible, so that an interface screen for the user can be set up to map the game event keys as they wish. This may require some decoding of the game events, keys and controls into string names for display. Just something more to keep in mind, in case all this wasn't enough already!! The game event keying off a clicked, double clicked or held event should be hard coded into your game event. Only the source control for the event can be modified. That is, the "Run Forward" event could be keyed to 'A', the left mouse button, or the second joystick button if you wish, but it will ALWAYS be a HELD condition, and should not modifiable by the user. It is possible, I suppose to allow the user to configure a control for "clicked" or "double clicked" functionality so they can truly program their own custom set of controls, but the "held" conditions should not be changed to anything else. Your interface will determine what is possible, of course.

Top

Back