Game Development Reference
In-Depth Information
public function dispose():void
{
removeEventListener( Event.ENTER_FRAME, onEnterFrame );
clipTouchController1.dispose();
clipTouchController2.dispose();
mStateMachine.dispose();
mEngine.dispose();
}
The first chunk of functionality in the class is all about initializa-
tion and disposal. When the clip is added to the stage, it performs
three main tasks. It creates an AirHockeyEngineConfig instance,
which as I mentioned earlier is just a structure for passing relevant
data to the engine. Although it is taking things a bit out of order,
here is the main content of that configuration class, for context.
public var mClipReference:Sprite;
public var mBoundaryList:Vector.
<
DisplayObject
>
;
public var mPlayer1:Sprite;
public var mPlayer2:Sprite;
public var mPlayer1Goal:DisplayObject;
public var mPlayer2Goal:DisplayObject;
public var mPuck:DisplayObject
public var mPlayer1ScoreCallback:Function;
public var mPlayer2ScoreCallback:Function;
Most of these should be self-explanatory, but I will call out a
couple of them for clarity. The clip reference member exists so the
engine has a context for the game that is using it. The boundary
list Vector is an easy way of pre-encapsulating all of the walls for
processing later since we don
t need to know about them individu-
ally. The two callback variables are for tying functionality from the
engine back to the Game class, by allowing the engine to trigger
events without knowing their context. We could use events for this
same purpose, but in the spirit of being efficient for mobile, call-
backs will work just fine.
Getting back to the initialization of the Game class, once all the
values for the config object have been assigned, a new instance of an
engine is created and passed this object. Next, the state manager is
created. For each of the four states we
'
ve already defined, we must
add that state to the manager. The FSM addState method expects a
numeric ID (the values we defined first in the class), a string descrip-
tion, and then up to three methods to call for that state. In the case
of this game, we
'
re not really interested in when a state is exited in
favor of another one. Instead, we want to know when a state is
entered and an update method to call every frame. We
'
ll look at all
of these methods shortly. Once the states are added, we tell the
machine to go to the PRE_GAME state, which will automatically start
the game.
'
Search Nedrilad ::




Custom Search