Developing and Deploying Virtual World Environment for Flash Multiplayer


August 2010

(For more resources on Flash, see here.)

Comparing SmartFoxServer Lite, Basic, and Pro

SmartFoxServer is a commercial product by gotoAndPlay(). There are three package options of SmartFoxServer. They are Lite version, Basic version, and Pro version. The demo license of the SmartFoxServer provides full features with 20 concurrent users maximum without time limitation. We will use the demo license to build the entire virtual world throughout the article.

SmartFoxServer Lite

The Lite version was the original SmartFoxServer since 2004. The maximum concurrent connection is limited to 50. It supports some core features like message passing, server-side user/room variables, and dynamic room creation.

However, the lack of ActionScript 3.0greatly limits the performance and functionality. Moreover, it is being updated slowly so that many new features from Basic and Pro version are missing in Lite version. When we compare the version number of the three options, we will know that Lite version is developing at a slow pace. The version of SmartFoxServer Pro is 1.6.6 at the time of writing. The Basic version is 1.5.9 and the Lite version is only 0.9.1.

Because of the slow update, not supporting ActionScript 3 and lack of features, it is not recommended to use Lite version in production.

SmartFoxServer Basic

SmartFoxServer Basic supports ActionScript 3 and a bunch of advanced features such as administration panel, game room spectators, and moderators. The administration panel lets moderators configure the zones, rooms, and users when the server is running. However, the lack of server-side extension support limits the customizability of the socket server. It also means that all logic must reside on the client side. This raises a security issue that the client may alter the logic to cheat.

The Basic version provides enough features to build a Flash virtual world in small scale that does not require high security. If you need a specific server logic and room management or want to put logic in server side to prevent client-side cheating, Pro version is the choice.

SmartFoxServer Pro

There is a long list of features that are supported in Pro version. There are three features amongst all that distinguish the Pro version, they are:

  • Server-side extension that modifies the server behavior
  • JSON/Raw data protocol message passing
  • Direct database connection

Modifying the behavior of server

Server-side extension is some server logic that developers can program to modify the default behavior of the internal event handler and add server-side functions to extend the server for specific usage.

For example, we may want to override the "user lost" event so that we can save the user properties, telling others that someone is disconnected and something else. In this case, we can write a function in server-side extension to handle all these things when the user lost, instead of running the default behavior that was provided by SmartFoxServer.

The SmartFoxServer is written in Java. Therefore the native support language of server-side extension is Java. In order to reduce the development difficulties, SmartFoxServer supports Python and ActionScript as a server-side extension. The support of ActionScript makes it much more convenient for most Flash developers to develop the server-side extension without even knowing Java.

Please note that the version of ActionScript supported in server-side extension is ActionScript 1, instead of ActionScript 3.

Take a look at the following code snippet on a server-side extension. The functions in server-side extensions are often similar to this one. It comes with arguments to know which user is calling this command at which room. In this snippet there is a command called getSomething and it will use the provided command parameters to get the result and return the result to the corresponding user.

function handleRequest(cmd, params, user, fromRoom)
var response = {};
switch (cmd)
case "getSomething":
var cpu = params['cpuType’];
response.something = "A Powerful Computer with CPU "+cpu;
// send the response back to the client.

JSON/Raw data protocol

JSON ( is a light-weight text-based data-interchange format. It is designed for both humans and machines to read and write the data easily. For example, we can format a list of users and their information with the following JSON code.

{"users": [
"name" : "Steve",
"level" : 12,
"position" : {
"x" : 6,
"y" : 7
"name" : "John",
"level" : 5,
"position" : {
"x" : 26,
"y" : 12

The default data protocol supported by SmartFoxServer Lite and Basic is XML. The Pro version added support of JSON and raw data protocol make it possible to compress the transfer of data between clients and server. The length of messages between clients and server is much shorter and it means the transmission speed is much faster.

Take an example of a client sending data to a server with different protocols.

We are now trying to fetch some data from the server, and this is what it looks like when sending a command to the server via different protocol.

  • XML:

    <dataObj><var n=’name’ t=’s’>extension</var><var n=’cmd’
    t=’s’>getSomething</var><obj t=’o’ o=’param’><var n=’cpuType’

    The length of this command is 148 bytes.

  • JSON:


    The length of this command is 75 bytes.

  • Raw Data:


    The length of this command is 29 bytes.

When comparing with the bytes used to send a command over the network, XML is two times the JSON and five times the raw protocol. We are talking about several byte differences that may not be considered in a broadband Internet. However, it is a must to consider every byte that was sent to the network because we are not talking about 29 bytes versus 148 bytes in the real applications. Imagine there are 2000 players in the virtual world, sending similar commands every second. We are now talking about 2.4Mbit/s versus 500Kbit/s, and this rough statistic already ignores those commands that fetch a long list of results, for example, a long list of items that are owned by the player.

The raw protocol format takes less bytes to represent the command because it does not contain the field name of the data. All parameters are position-dependent. In the preceding command, the first parameter stands for an extension message and the second stands for the command name. Other command-specific parameters follow these two parameters.

Raw protocol is position-dependent on the passing parameters while JSON is not. It is recommended to use JSON protocol in most case and use the raw data protocol in real-time interaction parts. Also, we should state clearly in comments code what each parameters stands for because others cannot get the field information from the raw data.

Accessing the database directly

Flash does not provide any database access functions. Flash applications always connect to database via server-side technique. The Pro version of SmartFoxServer provides direct database connectivity in server-side extension. The Flash virtual world will call a function in sever-side extension and it will handle the database connection for the Flash.

As the database connectivity is handled in server-side extension, Basic and Lite version does not contain this handy feature. We have to wrap the database access in other server-side technique, such as PHP, to connect database in Basic and Lite version.

The two graphs compare the architecture of the database access in SmartFoxServer Pro, Basic, and Lite.

(For more resources on Flash, see here.)

Comparing different package options

Core features Lite Basic Pro
Chat message Support Support Support
Server-side variables Support Support Support
ActionScript 2.0 Support Support Support
ActionScript 3.0 No Support Support
Administration panel No Support Support
Red5 integrated No No Support
Clustering No No Support
Server-side extension No No Support
JSON/Raw protocol No No Support
Direct database connectivity No No Support>
Firewall traversal No No Support by BlueBox plug-in

Developing and deploying virtual world environment

SmartFoxServer works excellently as a socket server in connecting clients and provides multiplayer features to virtual world. However, we also need a web server and database set up in practical use.

It may be disorienting at the beginning that we are using three types of servers at the same time. The following graph shows how these servers are responsible for different roles. We need a web server to host the virtual world website and Flash SWF. We also need a database server to store all user information permanently.

SmartFoxServer comes with an embedded HTTP server (Jetty), which can handle web pages and a light-weight database engine (H2). Using the embedded HTTP server and database can enable a rapid prototype development because we can start coding the Flash prototype of the ideas in mind without handling any server setup issues.

SmartFoxServer is also able to work together with third-party web servers and databases, for example, Apache and MySQL.

There are different situations on setting up the servers of Flash virtual world such as sometimes using SmartFoxServer with its embedded HTTP server and database while sometimes it is more beneficial to use SmartFoxServer with third-party servers.

Setting up a suitable sever environment before coding, on the other hand, enables us to have a plan and design of the whole architecture of the virtual world. It is a good practice to make a detailed plan before developing software, especially big scale software such as Flash virtual world.

We are going to compare the development environment and deployment environment, with different sever settings that may be applied.

Adjusting server setting for the deployment environment

In deployment of the virtual world, we have to choose the SmartFoxServer to fit the platform of the server instead of your own development machine. The SmartFoxServer may be a host in a standalone dedicated machine or a host within the same machine of the web server. There are many different combinations of setting up the servers and we will compare the common solutions.

Hosting SmartFoxServer, web server, and database in one server

For hosting a small-scale or mid-scale virtual world, hosting all severs in the same machine will be a good choice. In this case, there is not much difference between using the embedded web and database server, or using a third-party one. The following figure shows host SmartFoxServer, web server, and database in one machine:

Hosting SmartFoxServer in dedicated standalone server

For hosting a big scale virtual world, it is good to host the SmartFoxServer in a standalone machine. This machine can virtually be a Virtual Private Server or physically a dedicated machine. More SmartFoxServer performance and scaling information can be found in the official SmartFoxServer documentation ( The following figure shows host SmartFoxServer in standalone:

As the web server and database are not in the same machine of the SmartFoxServer, the choice of the web server and database is open. The web server can be Jetty, Apache, or others. The database server can be MySQL, Oracle, or any other available database server.

Benefiting from setting up SmartFoxServer, web server, and database in different machines

These servers are targeting different purposes and tasks. Each of them has a different requirement for server specification. Therefore, they are often put into different machines so that each machine can have the performance tuned to fit each server's purposes best.

Another benefit of putting them into different machines is that it enables centralized managed database storage. It is common in game industry that you log in to different online games or virtual worlds with one user account. After your virtual world has grown, you will probably have more than one server instance running the virtual world server. You may even have grown into to hosting several virtual worlds in several servers. The players will then query and authenticate from a standalone centralized database and then use that information to join different virtual worlds. The following diagram shows a host multi-virtual world server with the same database:


In this article we covered different sever settings that may be applied to SmartFoxServer. In ths next article we will see the running of SmartFoxServer Using Embedded Web Server and Database.

Further resources on this subject:

You've been reading an excerpt of:

Flash Multiplayer Virtual Worlds

Explore Title