Game Development Reference
In-Depth Information
Chapter 10
After exploring input devices in the previous chapter, we
re ready to move a little
deeper and see what happens when the raw input messages are passed from the
application layer to your game.
Games usually have a small set of user interface components, and they are almost
always custom coded. Games don
'
t use the operating system
'
s native user interface
API, like Windows GDI, to create their menus, dialogs, or radar screens. These spe-
cial controls are almost always home grown. Sure, the number of controls you can
attach to dialog boxes and screens is overwhelming, but most games don
'
t need rich
text editors, grid controls, tree controls, property pages, and so on. Rather, the lack of
control over position, animation, and sounds usually compels game programmers to
roll their own simple user interface or perhaps layer on a Flash-based one.
If you roll your own, a simple interface breaks the job into two parts: controls and
containers for controls. Some user interface designs, such as Windows, don
'
t distin-
guish between controls and control containers. Everything in the Win32 GDI has an
HWND
, which is a handle for a window. This might seem a little weird because it
would be unlikely that a button in your game would have other little buttons
attached to it, but it does standardize how these structures are referenced.
Instead of proposing any specific design, it
'
s best to discuss some of the implementa-
tion issues and features any game will need in a user interface. I
'
ll talk about the
human game view, screens, and dialog boxes and end up with a discussion about
controls.
'
269
