Game Development Reference
In-Depth Information
Asset SWFs
To keep the game as modular as possible, and load times low, the
various art assets for the game will be stored in external SWFs and
loaded in at runtime. This will provide a few benefits:
Assets will only be loaded when needed, meaning the main game
SWF will not be weighted down with a ton of art in its initial load,
should an implementation of this game have many levels.
Multiple developers and artists are capable of working on
specific assets in tandem without needing access to the core
FLA file.
￿ Adding new character and scenery art will be as simple as
dropping in new SWFs and referencing them in the level XML.
This structure is similar to how many commercial games work;
the EXE or main application file is the
and is accompa-
nied by one or more resource files (pak, was, and rsc are some
common extensions).
The asset files will have no active timeline. Each will consist
merely of library items with class linkages. Once the assets are
loaded into the game, they will be stored in memory and then
accessed by instantiating new copies the assets. When a level is
complete, the assets will be purged from memory, but if they need
to be loaded again they should already be cached in the user
browser, preventing a repeat download.
The Game Outline
Before we dig into the code behind this game, I
ll outline all the
classes that will come into play. The classes are divided into three
categories, each with a specific purpose:
Engine code: These files are at the heart of the game mechanic
and are where the core feature set of the engine is implemented;
in addition to classes, this code also contains interfaces for
creating the different game components. These files are all within
the com.flashgamebook.engines.platformer package.
Game code: These classes control how this specific instance of
the engine looks and behaves, and other logic like switching
between levels and creation of all the engine instances.
Asset classes: For each of the asset SWFs in use, we
ll specify
unique class names for each individual asset, but we won
actually create AS files for any of them
more on this will be
discussed, shortly.
ll now look at all the classes involved, in the aforementioned
order. It
s important to note that unlike the MixUp game in
Chapter 13, this example does not include multiple screens with navi-
we will focus on the game only. There is already enough
code at work here and I did not want to bog you down with informa-
tion not directly pertinent to the tasks at hand. I
Search Nedrilad ::

Custom Search