The client side
Now it's time to open the Director movie called fish.dir.
Almost all of the code on the client side is written in
Lingo. The first thing you'll notice on the Stage
is a field that contains the following URI:
rtmp://www.your_fcs_domain.com/fish
Change this address to match the domain
name of your Flash Communication Server.
Rooms and application instances
Note the word "fish" at the end of the URI above.
This tells Macromedia Flash Communication Server MX that
you want to run the Fish application and you want to join
the default instance for this application.
In classic multiuser environments, an instance is sometimes
called a "room." Users often meet in a "lobby" and then pair off into rooms to meet with a smaller subset
of users.
This is another area where Macromedia Flash Communication Server MX has evolved a bit from the
previous Shockwave Multiuser Server architecture. To make a room with Macromedia Flash Communication Server MX, you
don't have to create groups and send different "joinGroup"
messages to different users. Instead, you just add a word
to the end of the application URI.
In other words, this room:
…fish/PacificOcean
would be a different instance of the Fish application
than this room:
…fish/AtlanticOcean
Both rooms will launch a new instance of the same server-side
script (main.asc) and all variables in the script will be
specific to their instance. This simplifies the process
of setting up rooms and partitioning users into different
groups.
Tip about URIs: Some administrators
set up Macromedia Flash Communication Server MX to deny
connections from addresses that don't
match the domain of the server. This is for security reasons
and it's a common practice with hosting companies. Unfortunately,
it makes development and debugging more difficult because
you have to upload the movie to the server to test it.
If
you find that you can't connect to Macromedia Flash Communication
Server MX from your local machine, ask the administrator
to add your IP address to
the "allow" section of Macromedia Flash Communication Server
MX setup.
Creating a connection
Whereas all Shockwave Multiuser Server calls are piped
through the Multiuser Xtra, Macromedia Flash Communication
Server MX uses Macromedia Flash Player as the conduit
for calls
between the client and the server. You can create the connection
by using a Macromedia Flash sprite or by creating a
global
Macromedia Flash object. In this sample application, you'll
be using a Macromedia Flash sprite.
Note: Be sure that the Macromedia Flash
sprite is within the visible boundaries of the Director
Stage or else the sprite won't get the servicing required
to receive callbacks from the server. This Macromedia
Flash sprite doesn't contain any graphics so I've
hidden it from the user by setting the ink to background
transparent.
Most of Macromedia Flash Communication Server MX Lingo
for Fish is in a script member called "Flashcom behavior."
The first step in Macromedia Flash Communication Server
MX (as in Shockwave Multiuser Server) is to create a connection. This happens
in the method called "connectToServer":
on connectToServer (me, aUri, aUsername)
-- [snip: some init code].
pConnection = pSprite.newObject("NetConnection")
pSprite.setCallback(pConnection,
"onStatus", #connectionStatusHandler, me)
pSprite.setCallback(pConnection,
"setUserNumber", #setUserNumber, me)
pConnection.connect(aUri, aUsername)
end
Here you're using your Macromedia Flash sprite, pSprite,
to create a connection object. Then you set two callbacks—a
process that is very similar to setting netMessageHandlers
using Shockwave Multiuser Server.
The first callback defines which method the server should
call with any status messages about the connection itself.
This will come in handy right away when the server calls
back to tell you whether the connection has been accepted
or rejected.
The second callback in this method is for setUserNumber.
You may remember that the server-side script made a call
to the client to send back a user ID. Now, you're using
setCallback to route that
message to the appropriate method on the client.
With this callback in place, you have a complete and simple
example of sending messages from the server to the client.
Making calls the other way is just as easy. I won't
go into great detail here, but here's the basic syntax:
Lingo on the client:
pConnection.call("someMethod", "someArgument")
ActionScript on the server:
Client.prototype.someMethod = function(someArgument)
{
// Do something here.
}
You have created a connection and received your user ID
from the server. Now you're ready to use this connection
to pass data between all of the users in your application
instance.
Subscribing to a SharedObject
You could use messages to pass data back and forth. This
would be a familiar strategy if you were using Shockwave
Multiuser Server.
But for this example you'll use SharedObjects instead.
Your "Flashcom behavior" includes a method
called newUser. This
is where you subscribe to the SharedObject that represents
each user (or each fish).
Subscribing to a SharedObject is a simple process. First
you get the object and then connect to it:
tUserSO = tSharedObject.getRemote(("u"
& tUserNumber), pConnection.uri, FALSE)
tUserSO.connect(pConnection)
The first SharedObject that you subscribe to holds the
data for each user's own fish. After that, you subscribe
to a new SharedObject every time a new user becomes
known. This usually happens when the list of users
changes. You can find the code for monitoring the user
list in the method called syncUsers.
Using a SharedObject to receive data
When another user's fish changes (for example, when
the fish increases its speed) your client movie is notified
or "synced." You have used setCallback
to direct these changes to the sprite that displays the
corresponding fish for that user.
Open the script member called "User sprite."
Inside you'll find a method called syncUserObject.
This is where you process changes to the user's SharedObject.
When a SharedObject changes state, the event can be one
of several code types. Let's look at the events with the
code type "change." Look for this code type in the following
lines, get the name of the data slot that has changed,
and get the new value
of that slot:
case tCode of
"change", "success":
tSlotName
= symbol(tNextInList.name)
tSlotValue
= value("tData." & tSlotName)
Then use the new value to change the fish for that user.
For example, if tSlotName is "speed"
and tSlotValue is "10," tell
the user's fish sprite to set its speed to 10.
When a slot changes, only the data for that slot is sent,
rather than the entire SharedObject. If you're concerned
about performance and bandwidth usage, you might want to
keep this in mind when designing the structure of your
data.
Using a SharedObject to send data
Now you'd also like to send data in the opposite direction
so you can tell other users about changes that you
make to your own
fish. To do this, just change the appropriate
slot on our SharedObject.
In the "Flashcom behavior," find this method:
on setUserProperty(me, aSharedObject, aSlotName,
aSlotValue)
tSOsetter = pSprite.getVariable("gSOsetter",
FALSE)
tSOsetter.setDataSlot(aSharedObject,
aSlotName, aSlotValue)
end
SetDataSlot is a function
in your Macromedia Flash sprite that can change any SharedObject
that you pass
to it. For example, you can flip the rotation of your fish
by passing the fish's SharedObject to this method
and including a slot name of "rotation" and
a slot value of "180."
That's all you need to do to send new data. All
of the other clients will receive the event on their end
and change the rotation of your fish on their screen.
To see these events in action, open the message window
and watch the "put" messages as they come in.
You can also roll the mouse over any of the fish to see
the name of the user that owns that fish.
Of course, there is more to Flash Communication Server
than a school of fish avatars. But hopefully this article
helps with some of the basic elements that you need
to use Macromedia Flash Communication Server MX in Director
MX.
Additional resources
- Debugging and admin tools: Macromedia
Flash Communication Server MX includes some excellent
admin and
debugging tools. The Communication
App Inspector is the best place to start. You'll find
it on the "Getting Started" page installed with
the server:
|
