Building Games with Flex: Tic-Tac-Toe V1 Code Explained Pt 1

Part of my goals with these posts is teaching Flex for those just getting started.  What better way to learn Flex than by building a game of Tic-Tac-Toe.  Code is code and lessons can be learned/shared despite the final output.  You’ll (hopefully) learn tricks and methodologies for helping you code non-game projects via the code that I share and explain in this series.

There are  3 files that make up the complete game (right click to view/download the source) :

1. Main.mxml – This has the Application tag
2. GamePiece.mxml – This is the X/O game piece
3. GameBoard.mxml – This is the tic-tac-toe gameboard

I’ll go over the 3 files, explaining logic on why/what from both the Flex and gaming perspective.

Main.mxml

The Flex logic is pretty simple.  It contains the Application tag, so my app can be built.  It also houses the GameBoard class.

Why not make GameBoard the Application Class?

There are two reasons why I didn’t do this.

1. I wanted to be able to swap out the gameboards.  What if I get to the point where I have 10 different types of the Tic-Tac-Toe boards?  If I built it this way, I can just remove the GameBoard.mxml child from the Main.mxml and add some new, fandangled game board class in its stead.
2. I also wanted to be able to swap out the main tag.  I haven’t done much AIR programming, but I remember it using WindowedApplication as it’s root tag.  Again, I’d have to transport any business/game logic to this second root application class if I didn’t do this separation up front.

GamePiece.mxml

The brains behind this part of the game app is actually states.  I wanted to use states for a few reasons:

1. I was using Flex and states are an integral part or Flex.  Why not take advantage of this powerful, built-in mechanism?
2. I didn’t want to code much.  States can be whipped up very quickly inside of Flex Builder using the design view. It took a few clicks and little typing to create the 4 states (5 if you count the blank one).
3. I was forward thinking to when I was gonna style my class.  One of the things I think is very underused is the Flex Component Kit for Flash.  Therefore, when I go to skin the game piece, I’m going to use Flash to hopefully create some wild game pieces.  If I code my Components in Flash correctly, I won’t need to change any logic.  They’ll just work auto-magically in my game.

Let’s take a look at the states.  They’re incredibly simple, but worth going over.

<mx:State name="X">
     <mx:AddChild position="lastChild">
          <mx:Label x="10" y="10" text="X" fontWeight="bold"
            fontSize="72" width="98" id="label1" height="98"
            textAlign="center" />
     </mx:AddChild>
</mx:State>


In the first state above, we see that I add a Label to the component.  This is the same label that I’ll use for each of the other states.  I give it some styling options and a default value of “X”.

<mx:State name="O" basedOn="X">
     <mx:SetProperty target="{label1}" name="text" value="O"/>
</mx:State>

Next, I base the “O” state on the previous one.  The only thing I do is change the text propety of the label to “O” instead of “X”.  Otherwise, a game of all Xs would be pretty boring!  🙂

<mx:State name="OWinner" basedOn="O">
     <mx:SetStyle name="backgroundColor" value="#42E303"/>
</mx:State>

Next, I needed a way to alert the players that a winner had been found.  The quickest way to do this I figured was by modifying the background color.  I figured green was a good color because it’s the color of money ( “You won!” ) and of envy ( “Sorry, loser. Aren’t you envious of my skills?” ).  I made a winning state for the “O” piece.

<mx:State name="XWinner" basedOn="X">
     <mx:SetStyle name="backgroundColor" value="#42E303"/>
</mx:State>

And for the “X” as well.

The Script tag for the game piece is pretty small.  I was suprised by how little AS code I needed to add.

public var used:Boolean = false;

I created the used property, because I would need to know its value during 2 scenarios:

1. Has someone already played this piece?  If so, then ignore when someone picks it again.  If not, then let the game engine work its magic.
2. Have all the pieces been played?  Is it a “cat’s game” ?  If so, then let the game engine know.

Someone has already commented to me that instead of a used property, I could have just checked the currentState.  If it was it was not the base state, then it was available.  While that might be true, I wanted to leave the possibility of toggling through various states before the user chooses.  Something that would have been tougher without the used flag.

public function reset():void
{
     used = false;
     currentState = "";
}

The reset function is the only method I added.  Upon further review, I probably didn’t even need it as the used property could have been reset in the state.

I’ll explain the GameBoard code in other post as this one is getting pretty long. Most of the game logic takes place there, so it’ll take a bit to explain.

Feel free to comment or ask any questions if I didn’t make certain parts/decisions clear.