Game Development Reference
d. Storing save game data for return play
e. Loading and saving data using remoting services
2. Game design
a. Hazards and risk/reward scenarios
b. Score calculation
c. Laying out a level in the Flash IDE
So, without further ado, let
s dig in!
The XFL File
From the Chapter 15 examples folder, open the MarbleRunner.xfl
file in the directory of the same name. There are some immediate
things to note about this file:
The document frame rate is set to 24 fps. For a game such as this
with some heavier collision detection calculations going on this
strikes a good balance of visual smoothness and load on the CPU.
The main timeline consists of a set of labels and clips, represent-
ing the different screens of the application. We
ll look into these
classes in depth shortly.
The library assets are sorted into folders based on the screen to
which they belong, except for fonts (which are shared by all the
The classes for this game are split into two categories: the core
game logic that is extensible and agnostic for a labyrinth-style
classes) and the custom functionality that is
specific to this Marble Runner implementation (the
classes). As such, they are logically located in two different
packages. The engine set of files can be found in
The application classes are located in
ll start with the core engine and work our way outwards.
The concepts may seem somewhat abstract at first but will take
shape once you see how they are implemented. These files consist
of the following:
LabyrinthEngine.as : This class is pretty self-explanatory
it is the
center of all the logic handling collision detection, ball
movement, and level completion.
LabyrinthLevel.as : The base class for any levels built in the Flash
we use an inheritance model rather than an interface
because levels are more rigidly controlled and we want to be
able to do some validation on them.