Game Development Reference
In-Depth Information
on a modern mobile device is a touch screen. All iOS or Android
devices support varying degrees of multitouch input, meaning they
support a variable number of points being touched on the screen
simultaneously. This is a very different model that we
re used to in
Flash, having relied on a single mouse or keyboard input. It
done a particularly good job of implementing touch input inside of
Flash. There are three different modes in which Flash operates
when reading input from the touch display. These modes are
defined by the MultitouchInputMode class and are as follows:
NONE: Any touches detected by the device are translated as
mouse events. This is the default mode in which all Flash
applications start, making it very easy to translate existing
content into mobile applications without any change in the
input scheme
this is also the mode we used in Chapter 15.
TOUCH_POINT: Touches are translated into a series of new
events, defined by the TouchEvent class. Every touch has a
unique ID (integer) so as to distinguish them when they happen
simultaneously. This is needed when you need to be able to
capture more than one touch at once or to write handlers to
recognize custom gestures. This mode will be used in gameplay
later on in this chapter.
GESTURE: Certain predefined gestures commonly supported by
touch devices (such as swipes, press-and-hold touches,
rotations, and so on) are read in this mode. Any touches that
t fall into a predefined gesture are treated like mouse
events, not unlike
mode. This mode is less relevant in
most games, unless they make specific use of the gestures. We
use it briefly in this chapter just to show how it is implemented.
Flash can only operate in a single touch mode at a time, so you
need to plan for which kind makes the most sense for each part of
your application. Changing modes is as simple as setting the Multi-
touch.inputMode property to one of those three enumerations.
The Finite-State Machine
Up to this point, we
ve not looked at an example with complicated
enough behavior to warrant a full-state machine implementation,
but I would be doing a disservice to not demonstrate it at least
once. The version I
ll make use of in this chapter is essentially the
same model I use on a daily basis at Blockdot. It was written by
Jim Montgomery, one of my teammates, and was simple, straight-
forward, and very flexible. I won
t dig into the code under the
hood (though it is included as part of the source files), but I will
take a moment to describe how it works, which is ultimately more
important. In games in which you need to handle switching
Search Nedrilad ::

Custom Search