Graphics Reference
In-Depth Information
Table 13.2 MemoryGame Constructor Parameters
Parameter
Explanation
cards (Array)
The Array of BitmapData objects (images) that will be used as the cards for the game
cardBack (String)
A String that represents a BitmapData object to use as the back of each card; if null, a gray
box is drawn to show the card (optional, default is null)
spread (int)
The number of pixels between each card that is placed on the stage (optional, default is 10)
Table 13.3 The Deal Method Parameters
Parameter
Explanation
layoutType (String)
A String representing the pattern in which the cards will be presented on the
stage (optional, default is GRID_LAYOUT)
customCoordinates (Array)
An Array of Points or Objects with x and y values for each card (optional,
default is null)
rows (int)
The number of rows to use when laying out the cards in a grid-style pattern
(optional, default is 2)
to any number you might want to user to match. Now that we
'
ve got
all the duplicated cards in our deck, we
ll call the
shuffle
method
from the DeckArray and then assign values to
_numberOfCards,
_cardPadding
, and
_tempCardBack
(if one if available).
The next item in this engine is the
deal
method. This one has
three optional parameters (Table 13.3) and is essentially just a
switch statement that can be added for different card patterns on
the
'
This is where the
GRID_LAYOUT
and
CUSTOM_LAYOUT
vari-
ables I mentioned earlier come into play. Depending on which one
of these (or any others you may choose to add later) you pass in to
the
deal
method, the cards will be dealt and arranged on the
screen accordingly. To do this, you
“
table.
”
re calling the
buildCard
method as we loop our way through the deck.
The
buildCard
method is where the cards actually get created and
placed on the stage, and it does this with the use of three parameters.
Those three parameters are
cardName
,
cardX
,and
cardY
. I didn
'
ll notice we
'
t
include a table for these parameters because I think they do a good
job of explaining themselves with their names. The first thing that
happens here is that we create a new temporary card (
_tempCard
)
based on the
cardName
, which was passed in from the
_memoryCards
DeckArray earlier (this will make more sense when we get to the .fla
'
