Game Development Reference
In-Depth Information
instance records its type, the key's code, and its Unicode character in case the event's type
is
KEY_UP
.
The
TouchEvent
code is similar, and it holds the
TouchEvent
is type, the position of the finger
relative to the UI component's origin, and the pointer ID that was given to the finger by the
touchscreen driver. The pointer ID for a finger will stay the same for as long as that finger is on
the screen. If two fingers are down and finger 0 is lifted, then finger 1 keeps its ID for as long as
it is touching the screen. A new finger will get the first free ID, which would be 0 in this example.
Pointer IDs are often assigned sequentially, but it is not guaranteed to happen that way. For
example, a Sony Xperia Play uses 15 IDs and assigns them to touches in a round-robin manner.
Do not ever make assumptions in your code about the ID of a new pointer—you can only read
the ID of a pointer using the index and reference it until the pointer has been lifted.
Next are the polling methods of the
Input
interface, which should be pretty self-explanatory.
Input.isKeyPressed()
takes a
keyCode
and returns whether the corresponding key is currently
pressed or not.
Input.isTouchDown()
,
Input.getTouchX()
, and
Input.getTouchY()
return whether
a given pointer is down, as well as its current x and y coordinates. Note that the coordinates will
be undefined if the corresponding pointer is not actually touching the screen.
Input.getAccelX()
,
Input.getAccelY()
, and
Input.getAccelZ()
return the respective
acceleration values of each accelerometer axis.
The last two methods are used for event-based handling. They return the
KeyEvent
and
TouchEvent
instances that got recorded since the last time we called these methods. The events
are ordered according to when they occurred, with the newest event being at the end of the list.
With this simple interface and these helper classes, we have all our input needs covered. Let's
move on to handling files.
Note
While mutable classes with public members are an abomination, we can get away with
them in this case for two reasons: Dalvik is still slow when calling methods (getters in this case),
and the mutability of the event classes does not have an impact on the inner workings of an
Input
implementation. Just take note that this is bad style in general, but that we will resort to this
shortcut every once in a while for performance reasons.
File I/O
Reading and writing files is quite essential for our game development endeavor. Given that
we are in Java land, we are mostly concerned with creating
InputStream
and
OutputStream
instances, the standard Java mechanisms for reading and writing data from and to a specific file.
In our case, we are mostly concerned with reading files that we package with our game, such as
level files, images, and audio files. Writing files is something we'll do a lot less often. Usually, we
only write files if we want to maintain high scores or game settings, or save a game state so that
users can pick up from where they left off.
We want the easiest possible file-accessing mechanism. Listing 3-2 shows our proposal for a
simple interface.
