There are some additional properties you can attach to controls, mostly to give the player a more flexible and informative interface.
An excellent property to attach to any control is a hotkey. As players become more familiar with the game they'll want to ditch the mouse control in favor of pressing a single key on the keyboard. It's faster, which makes hardcore players really happy. You can distinguish between a hotkey command and a normal keyboard input by checking the keyboard focus. The focus is something your screen class keeps track of itself, since it is an object that moves from control to control. Let's assume you have a bunch of button controls on a game screen, as well as a chat window. Normally, every key down and up event will get sent to the controls to see if any of their hotkeys match. If they do match, the OnControl() method of the screen will get called. The only way to get enable the chat window is to click on it with the mouse or provide a hotkey for it that will set the keyboard focus for the screen.
As long as the keyboard focus points to the chat control, every keyboard event will be sent there, hotkeys are essentially disabled. Usually the focus is released when the edit control decides it's done with keyboard input, such as when the Enter key is pressed. The focus can also be taken away by the screen, such as if a different control were to be activated by the mouse.
Tooltips are usually controlled by the containing screen, since it has to be aware of moving the tooltip around as different controls are highlighted. Tooltips are trickier than you'd think, because there's much more to enabling them than creating a bit of text on your screen for each control.
For one thing, every tooltip needs to have a good position relative to the control it describes. You can't just assume that every tooltip will look right if you place them in the same relative position to every control. If you decide that every tooltip will be placed in the upper right area of every control, what happens when a control is already at the upper right border of the screen? Also, you'll want to make sure tooltips don't cover other important information on the screen when they appear. You don't want to annoy the heck out of your users.
|Best Practice|| |
Even if you provide a placement hint, such as above or beside a control, you'll still need to tweak the placement of the tooltip to make sure it doesn't clip on the screen edge. Also, make sure that screens can erase tooltips prematurely, such as when a dialog box appears or when a drag begins.
Context sensitive help is useful if you have a complicated game with lots of controls. If the player presses a hotkey to launch the help window when a control is highlighted, the help system can bring up help text that describes what the control will do. An easy way to do this is to associate an identifier with each control that has context sensitive help. In one game this identifier was the name of the HTML file associated with that control. When the screen gets the hot key event for help, it first finds any highlighted control and asks it if it has an associated help file.
Controls can initiate a drag event or accept drag events. Drag initiation is simply a boolean value that is used to indicate if a drag event can start on top of the control or not. Drag acceptance is a little more complicated. Most drag events have a source type, as discussed at the beginning of this chapter. Some controls might accept drags of different types given only particular game states. An example of this might be dragging items around in a fantasy role playing game. A character in the game might not be able to accept a dragged object because he's already carrying too much, and thus not be a legal target for the drag event.
Most controls have a sound effect that launches when the button changes state. Some games associate a single sound effect for every button, but it's not crazy to give each control their own sound effect. Animation frames for buttons and other controls are usually associated with the highlighted state. Instead of a single bitmap, you should use a bitmap series that loops while the control is highlighted. You'll find out more about animations and animating processes in this book. (For more information see Chapter 6 and Chapter 8.)