Game Development Reference
In-Depth Information
Input
The user will surely want to interact with our game in some way. That's where the input module
comes in. On most operating systems, input events such as touching the screen or pressing a
key are dispatched to the currently focused window. The window will then further dispatch the
event to the UI component that has the focus. The dispatching process is usually transparent to
us; our only concern is getting the events from the focused UI component. The UI APIs of the
operating system provide a mechanism to hook into the event-dispatching system so that we
can easily register and record the events. This hooking into and recording of events is the main
task of the input module.
What can we do with the recorded information? There are two modi operandi:
Polling
: With polling, we only check the current state of the input devices. Any
states between the current check and the last check will be lost. This way of
input handling is suitable for checking things like whether a user touches a
specific button, for example. It is not suitable for tracking text input, as the order
of key events is lost.
Event-based handling
: This gives us a full chronological history of the events
that have occurred since we last checked. It is a suitable mechanism to perform
text input or any other task that relies on the order of events. It's also useful to
detect when a finger first touched the screen or when the finger was lifted.
What input devices do we want to handle? On Android, we have three main input methods:
touchscreen, keyboard/trackball, and accelerometer. The first two are suitable for both polling
and event-based handling. The accelerometer is usually just polled. The touchscreen can
generate three events:
Touch down
: This happens when a finger is touched to the screen.
Touch drag
: This occurs when a finger is dragged across the screen. Before a
drag, there's always a down event.
Touch up
: This happens when a finger is lifted from the screen.
Each touch event has additional information: the position relative to the UI component origin,
and a pointer index used in multitouch environments to identify and track separate fingers.
The keyboard can generate two types of events:
Key down
: This happens when a key is pressed down.
Key up
: This happens when a key is lifted. This event is always preceded by a
key-down event.
Key events also carry additional information. Key-down events store the pressed key's code.
Key-up events store the key's code and an actual Unicode character. There's a difference
between a key's code and the Unicode character generated by a key-up event. In the latter case,
the state of other keys is also taken into account, such as the Shift key. This way, we can get
uppercase and lowercase letters in a key-up event, for example. With a key-down event, we only
know that a certain key was pressed; we have no information on which character that keypress
would actually generate.
