Game Development Reference
In-Depth Information
because we need to be able to assign touch events to either one
side or the other. If both players were tapping on the same side
of the screen, we wouldn
between them.
This game will enforce a score limit of three goals to end a session.
That should be about all the setup we need
s dig into
some code!
The XFL File
From the Chapter 16 examples folder, open the AirHockey.xfl file in
the AirHockey directory. Note the differences and similarities to the
file we created for Marble Runner:
The document frame rate is set to 30 fps. Since we
re on an
Android device (and, ideally, on a more powerful tablet rather
than just a phone), we can bump up the frame rate to a
smoother setting.
The main timeline follows the same structure as before, utilizing
frame labels to denote the three main parts of the application.
The library is also laid out in much the same way.
The Classes
There are fewer classes we
ll be working with than the two previous
examples, primarily because we
re using Box2D for all the physics
(which consists of a lot of classes) and the game itself doesn
t need
the logic broken up into a bunch of components. We
ll still follow
the engine/application division of labor, where the engine should
behave as agnostically as possible to the application in which it
resides. However, the engine itself is mostly just there to provide a
communication layer between the application and the physics
simulation. We
ll look at this in depth shortly.
Because this example makes use of the Box2D library, as well as
a generic state machine and the Greensock Tweening library, the
nents we
ll be looking at will be found at:
Below are the classes we
ll examine and their responsibilities:
￿ : As the engine, this manages the physics
simulation and updates the positions of the puck and two-
player paddles in reaction to the physics.
Search Nedrilad ::

Custom Search