We live in a communications world. The number of software solutions that can provide communication between users grows every day. In the future it's likely that applications unable to provide this ability will be known as "traditional applications," shunned because of their lack of openness and communication ability. A simple example of this can be seen in the game industry. Gamers are addicted to multiplayer games with others and to the pleasure that such games bring because of the interactions in the player-base: without the option of multiplayer mode, Director-based games will be in the minority.

Fortunately, Macromedia has not left developers alone in this pioneer technology and has provided the Flash Communication Server (the heir of Multi-User-Server in my view). Macromedia wants FlashCom to supersede MUS. So, although the MUS is powerful enough to create amazing applications with Director such as we see on the web today, following the MX version of Director, Macromedia suggests using FlashCom Server instead. FlashCom is known as a revolution in Macromedia history and this is mainly because of its integration across several products. FlashCom is so "open" that a running joke on a few of the forums I see has Macromedia changing its name to the "Macromedia Communication Server." What follows is an example of combining Director and the FlashCom Server to provide a backbone for multi-user applications, in a more modern way than traditional MUS applications.

What Is FlashCom?
Flash Communication Server is a server technology that provides the connections between Flash 6+ players. The Flash Communication Server is a hub. Users connect to the hub using Macromedia's communication protocol called Real-Time Messaging Protocol (RTMP). FlashCom makes it possible to communicate with other users through Flash files (and, with some conversions, in Director files) in web pages or standalone applications. It does this with several types of communication streams, such as sending video, audio, and text between users in real time. End users experience these applications as video-audio conferences, chat rooms, and so on.

In addition to these types, FlashCom has a "remote shared object" that is the heart of its flexibility. It lets us make an object like a 2D sprite or 3D object exist in a way that is shared between users so that they can manipulate its properties - such as position, rotation, and so on in real time together. You can think of it as 3D ball in a football game that users can pass it to each other.

Flash Object in Director
Director has supported Flash objects for a number of years, with each ve rsion of Director supporting the latest available version of Flash. With this ability we can work with FlashCom in Director as a Flash object. We can manipulate and work with the Flash object in several ways. We can get or set all variables and objects in Flash files and access all properties of those variables and objects. If you have used FlashCom in Flash before, you're familiar with the "Developing Communication Applications" document provided by Macromedia (www.macromedia.com/support/flashcom/documentation.html). In that document there are six sample projects that illustrate the basic capabilities of FlashCom very smoothly. I think the best solution is to learn how to use FlashCom in Director would be to re-code those samples in Director one by one. Thanks to John Taylor and Jay Armstrong for their articles in Macromedia Developer Center, we have the torch to light the dark road of starting this kind of implementation.

But there are several situations in which the best way to implement these types of applications in Director is not immediately apparent. By starting with simpler, more contained, projects and gradually growing into more advanced applications, one can learn FlashCom more efficiently.

For this article, I have chosen two samples from the initial FlashCom documents that I think have good features and could be as a guideline for other projects, one on sharing text between users, and one on sharing a sprite object. FlashCom applications generally have a client side-script written in a .fla file (which we will either replace or encapsulate inside the .dir) and may have server-side script written in an external file in the ActionScript language with the same name as application name, or "main" with a ".acs" extension. In this article I focus on samples that don't need any server-side scripting, but if you see these files in other examples, that is likely their intended use.

Sample One - (Shared Text)
The first sample I present is a "Shared Text" project. The goal of this project is to have a textbox shared between any users that visit our Shockwave page. They could write any message to any other user. While a user is typing, other users can see the characters typed one by one.

The first step is to create the Flash object. We can do this dynamically with Lingo or by importing a Flash file into the cast window. I use this later in the sample. Since you don't want to use any built-in Flash embedded video or pre-provided FlashCom components in your project, you don't need to do anything in your Flash movie. You need only to create an empty 10 by 10 pixels Flash file and publish it to ".swf". When you import this .swf file to Director and drag it to the stage, you have all you need to work with FlashCom. Keep in mind that Shockwave file must contain the swf in its stage boundaries. You can drag it to the left down corner of the stage and set the ink property to "Background Transparent." When you publish your project, save your ".dcr" and ".htm" files to a directory named "myProjectDirectory" (or anything else you want) in your FlashCom applications directory (for example C:\inetpub\wwwroot\flashcom\applications\).

TIP: try to write all your FlashCom scripts and functions in one "behavior script" and assign it to your flash sprite; then call those functions from other sprite or frame "behavior scripts" if needed. try to write all your FlashCom scripts and functions in one "behavior script" and assign it to your flash sprite; then call those functions from other sprite or frame "behavior scripts" if needed.

Step #1:
To provide any FlashCom capability to your applications you need to establish a connection to "Flash Communication Server". Do this by creating a new NetConnection object.

If we were programming in Flash we would use the line:

client_nc = new NetConnection();

In Director, we first assign a variable to our flash sprite and then use this variable to create flash objects and manipulate them, like this:

pSprie = sprite("myFlashSprieName")
pNetConn = pSprite.newObject
   ("NetConnection")

Step #2:
Any NetConnection object has an "onStatus" event raised when a connection is established. We use this event to test our connection status. It has a parameter defined according to the status message. The message is stored in the code property of this parameter. In some situations we can use it as a guide to alert the user if the connection was a success, closed, failed, rejected, etc. In Flash, this is implemented through a "function literal" or "anonymous function" method but we can't do it in Director.

In Flash:

client_nc.onStatus = function(info) {
		trace ("Level: " + info.level +
    "Code: " + info.code);
		if (info.code = "NetConnection.
    Connect.Success") {
		// Continue
		}else if (info.code = "NetConnection.
    Connect.Closed") {
		{
		// Alert Message
		}
};

We must implement this code in Director with the help of the setCallBack command. setCallBack is a Flash command that can be used as a sprite or a global method to define a Lingo callback handler for a particular event generated by the specified object. When ActionScript triggers the event in the object, that event is redirected to the given Lingo handler, including all arguments that are passed with the event.

In Director:

pSprite.setCallBack(pNetConn,
   "onStatus", #myOnStatus, me)
on myOnStatus (me, this, aInfo)
		put "Level: " && aInfo.level && 
   "Code:" && aInfo.code
		if (aInfo.code = "NetConnection.
   Connect.Success") then]
   		-- Continue
		else
		-- Alert Message
		end if
end

The parameters of setCallBack are an Actionscript object (NetConnection), the Actionscript event that occures (onStatus), the Lingo handler that handles the Actionscript event (myOnStatus) and the Lingo object that contains the corresponding handler (me). Thus any time NetConnection tries to connect, onStatus handler is triggered and myOnStatus handler triggers with all onStatus arguments in Director. Keep in mind that third argument of myOnStatus handler (aInfo) is according to the "info" parameter.

• Source Code