The related source file for
this article is found in the "Examples/smartFoxTris/"
folder under the name of "smartFoxTris.fla"
SmartFoxTris is our a complete mutiplayer version
of the famous "Tic-Tac-Toe" game.
Here's a list of features that we're going to achieve:
» users will log in and join a room called "The Entrance"
» users will be able to create a game room where 2 clients
can play the tic-tac-toe game
» as soon as the user creates the game he/she will enter the
new game room and wait for the second player
» when the 2nd player joins the game starts.
» the application will alternatively set the player's turn
and after every move it will check if there's a winner
» the game ends when no more moves are available or one of
the player makes a row of three.
» at the end of a game the user will be able to either start
a new game or to go back in the main chat room.
[ THE APPLICATION ZONE ]
In the source FLA file you will notice that we have added a new
frame label called "game": that's the
frame where we will send the
movie clip playhead when we join a game room.
Now bring the playhead on the "connect"
label and open the Actionscript panel (F9).
We didn't change much of the code here, however the zone name is
We wanted our game application to have one main room, called "The
entrance", users will enter by default: in this room
be able to chat and create or join new games.
If you open the config.xml file in the SmartFoxServer
Lite folder you can better see how this zone is configured:
<Room name="The Entrance" maxUsers="50" isPrivate="false" isTemp="false" autoJoin="false" />
The zone is setup to contain only one room at start. Then clients
will be able to dynamically create as many game rooms as they want
from the smartFoxTris interface.
[ JOIN AND CHAT ]
Let's move on to the next label and open the Actionscript panel
As usual we will use the same application logic adopted so far,
and you will notice that most of the code here is almost
identical to the previous examples.
The following line of code setup a flags that will tell us if the
user is currently playing a game:
- // Setup global vars
- inGame =
false // flag
to see if we're currently playing a game
The "inGame" flag will not be changed
until we move to the "game" label so we'll talk about
Next we have a look a the onJoinRoom event handler:
- if (roomObj.isGame())
- if (_global.myID
- // let's move in the "game" label
- var roomId
- var userList
- // Clear current list
- for (var
- var user
- var uName
- var uId
- // Sort names
color='#cc0000'>>> Room [ " +
+ " ] joined</font>";
The first thing that we have to do is checking if the client has joined
a game room.
Why this? Because this time we're dealing with two type of rooms:
"regular" ones and "game"
ones, so each time a room is joined we have to check what type of
room the user joined and take the appropriate action.
The isGame() method returns true if the current
room is a game room.
The code used to handle the non-game room is always the same used
before so we can analyze the part used
when a game room is detected.
The playerId variable is a new client API property
that we haven't met before. It represent our unique player
in the room. This way we will be able to check which user is the
client that is currently using the application and take the proper
In this sample application every game room will have a capacity
of 2 users so the playerId will only be assigned
values: 1 or 2, depending on the room state.
Back to the code: we save the playerId in a _global
variable and then, based on its value, we assign a player color
and a player name. If playerId is 1 we'll be player 1 and we'll
play with the green colored balls otherwise we will impersonate
player 2 and
we'll use red balls.
Then the playhead is stopped on the "game"
Before we analyze the Actionscript in the game section we need
to take a look at the new createRoom function:
- function createRoom(name,
- gameRoom =
As usual the "create game" dialog is closed and then
we proceed creating the object representing the room that we are
create. This time the isGame flag is set to true:
this will tell the server that the room will hold a game.
What's the difference between a "regular" room and a
"game" one? Almost no difference, however there is a slight
difference in the behaviour when the room is empty.
If you remember from the "Advanced
Chat" tutorial we said that "regular" rooms are
removed only when the last user exits
and the room creator is not connected anymore in the zone. If the
creator is still around the room will not be destroyed.
A game room behaves a little differently because it will be removed
as soon as the last user leaves it. This is the ony difference.
Also it is important that game rooms are recongizable from the
others so that you can group them together for example
in a different list box. This is exactly what we've done in this
Also the sendChatMsg function was slightly modified:
- function sendChatMsg()
- if (ingame)
- if (_global.gameStarted
- else if
In a moment we will see that that the game area also contains a
small chat window where players can keep chatting while playing.
The chat dynamic text field instance was named just like the one
in the main chat to keep things simple.
However we have added some more checks to prevent text from being
submitted if the game is not started yet.
[ THE GAME BOARD ]
It's time to dive into the fun stuff ;-) Move the playehead one
the "game" label and inspect the game
We've added three new dynamic text fields that will show the names
of the players and the one in the middle will show whose turn is.
As mentioned before there's a new multiline text field with scrollbar
for chatting and the most important movie clip is the game board
The board movie is made up of nine square clips each one called
according its grid position: the top-left one is called sq_1_1
and the bottom right one is called sq_3_3
Now open the library (F11) and examine the item called "gridSquare",
you will find it under the _GUI/_gameBoard folder.
The symbol is made up of a colored square, a button and an instance
of the "ballElement" movieclip that can
be found in the _Balls
Now open this symbol and you will notice that it has three states
corresponding to name of the labels: "off",
We'll be able to control each of these clips inside the game board
to show the right item when a user clicks on of the
[ ROOM VARIABLES ]
Now that we have inspected the game GUI a little we could analyze
the game logic code... but there's still one thing
we need to know before diving into the Actionscript.
You need to learn a little about "Room Variables"
and the differences between the already known "User Variables"
The one and only big difference between the two is that Room
Variables are values stored in the room object opposed
of the user object.
Why do we need to save variables in the Room?
Here's how the game works: when a user enter the game room
he/she will save a variable called "player1"
or "player2" based on which player he
In order to start the game we need that both variables (player1,
player2) exist in the room otherwise the game will
be "paused" until both values are present.
By having a "central" place to save our server values
it is very simple to keep track of the status of the game room.
Summing it up the "User variables" are
great when you need to save user specific preferences regardless
of which room the client is currently in. On the other hand "Room
variables" are the right tool when you need to keep
track of the status of the Room and this is always an important
aspect in game Rooms.
Creating a "Room Variable" is similar
to what we've seen so far
- vObj =
You create an array of objects with two properties each, called
"name" and "value" and then call the setRoomVariables()
API method to set one or more "Room Variables" in one
As with the "User Variables" every change in the room
variables will be notified to all the clients in that room and you
will need to implement a function to handle the "onRoomVariablesUpdate"
event, which we'll encounter in a moment.
That's all for this fist part: we have introduced
a number of new features that we will use in the application.
In the next chapter we'll analyze the gameplay and we'll finish
our first "turn-based" game! :-)