The virtual world can sometimes be very large. We cannot put the whole world into one SmartFoxServer room when it grows big. Putting a large area into one room means that there are more users inside the room. More users means many more broadcast messages for every player's action and this will cause performance and bandwidth problems.

If all parts of the world belong to the same room, all broadcasted events of the avatar will be accessed by all players. On the other hand, in the partitioned world, the broadcast messages are sent only to those players that are in the same part of the world.

There is a parameter called maxUsers for each room in SmartFoxServer that limits the maximum number of users joining the room. Broadcast messages cost much more bandwidth when there are too many users in the same room. Therefore, we have to break the large world into different rooms, or even different servers to distribute the loading.

When splitting the world, we need to consider the connectivity between different parts of the virtual world. There are two common methods. One is partitioning the rooms as an individual cell. Players cannot see other buildings or players in another cell. The other method is to display the world seamlessly so that the players will not notice the border between different rooms.

The pros and cons of the seamless world

In a seamless world, there is no sharp border between different SmartFoxServer rooms of the virtual world. Users can view the other part of the world when they walk near the hidden border of the room. They can cross the border and walk into the other room without notice. They may even be able to see players in other rooms. The seamless world gives the players a larger vision of the virtual world and better interactivity between players.

The seamless world creates a more attractive large world then partitioning the world and thus it is tempting for the virtual world development team to implement the seamless virtual world. However, there are several difficulties in implementing the seamless world. Most difficulties come from the complex exceptions when handling the hidden border of two SmartFoxServer rooms.

• The complexity of a hidden border

  There is a buffer area between two rooms that can share some critical information. For example, a player inside the buffer area has to be viewable from the other room. If there is no buffer area, other players will suddenly appear when crossing the hidden border of the rooms. The buffer area reduces this strange suddenly appearing effect by preloading the avatars that are inside the buffer.

• Complex synchronization between rooms

  However, this buffer area causes another problem. There is one case that player A is in room A outside the buffer area. Player B is in room B inside the buffer area near room A. In this case, player A can see player B but player B cannot see player A. If this virtual world allows a player-versus-player battle, player A can attack player B while player B will not know that player A is there. This causes the imbalance between players.

There are often unpredictable synchronization problems between the borders of the rooms. Some players may use these bugs to create an imbalance situation. Some seamless virtual worlds use dynamic border instead of static border to prevent players cheating the border synchronization. Players will not know at any time where the border is and this greatly reduces their chance of cheating the border. However, implementing dynamic border makes the code more complex.

The seamless world give a bigger sight view to players and it is often a bit tempting for a new virtual world designer to try implementing it. However, the decision of using seamless world implementation or not should be considered thoughtfully and made at the very beginning of the virtual world development.

My suggestion is not to use the seamless world because it is not worth putting in so much time implementing it. I will only use the seamless world implementation when the game play requires it as core features and I have a big professional development team.

We will use partition-type virtual world implementation because we should avoid implementing seamless world if it is not necessary. Instead of putting so much manpower on the seamless world, it is worth it to enhance the game player and overall design of the virtual world.

We need to prepare the rooms for the virtual world in the SmartFoxServer configuration. As the rooms for virtual world are something static and will not be destroyed, we can set the rooms in config.xml to create the rooms on server start up.

<Rooms>
<Room name="Lobby" maxUsers="50" isPrivate="false" isTemp="false" autoJoin="true" />
<Room name="island1" maxUsers="50" isPrivate="false" isTemp="false" />
<Room name="island2" maxUsers="50" isPrivate="false" isTemp="false" />
<Room name="island3" maxUsers="50" isPrivate="false" isTemp="false" />
</Rooms>

This configuration creates four rooms when the server starts up. More rooms may be needed when the virtual world grows larger.

Some special actions or events happen when the player walks near some specific place. This specific place is called trigger. One feature of the trigger is to connect two places. It may connect two towns of the virtual world or it may let the players enter some houses. Portal is a trigger where avatars teleport to another designed place when stepping on it.

Before implementing the portal functions, we need to modify several codes for preparation.

We used to load the mapdata.xml file when initializing the world. As there are different XMLs now to define different maps, we will dynamically load the map data from the room name.

loader.load(new URLRequest('data/'+SmartFox.sfs.getActiveRoom().getName()+'.xml'));

The portal XML node is similar to the building XML node; it lists all portals in this room and which room the portal will direct to.

<portals>
<portal id='1'>
<x>29</x>
<y>16</y>
<connectedRoom>island2</connectedRoom>
<connectedPortal>1</connectedPortal>
</portal>
...
</portals>

There are five fields for each portal entry. They are the portal ID, x/y position in map, room name that connected, and the portal ID that connected in that room. We will also define an object called PortalObject to store the information of each entry.

The list is loaded after loading the building list in the onMapDataLoaded function in IsometricMapData.as.

for(i=0; i<_xml.portals.portal.length(); i++) {
var portalXML:XML = _xml.portals.portal[i];
var portalObj:PortalObject = new PortalObject();
portalObj.id = int(portalXML.attribute('id'));
portalObj.x = int(portalXML.x);
portalObj.y = int(portalXML.y);
portalObj.connectedRoom = portalXML.connectedRoom;
portalObj.connectedPortal = portalXML.connectedPortal;
portalList.push(portalObj);
}

We need to check if the avatar stepped on a portal. The checking is executed after the avatar stops walking. The avatar dispatches the myAvatarStopWalk custom event to let the World class handle.

this.addEventListener("myAvatarStopWalk",checkPortal);

The checkPortal function is located in World.as. It loops through the list of portals to see if current stepped tile matches any portals. If they match, it will join the connected room.

private function checkPortal(e:Event):void {
for(var i:int =0;i<_map.portalList.length;i++){
var portalObj:PortalObject = _map.portalList[i];
if (portalObj.x == Myself.instance.isoPosX
&& portalObj.y == Myself.instance.isoPosY){
Myself.instance.nextRoomPortal = int(portalObj.connectedPortal);
SmartFox.sfs.joinRoom(portalObj.connectedRoom);
}
}
}

We also need to teleport the avatars to the connected portal of the new room, so we set the target portal ID before joining the new room and initialize the avatar to the portal position when initializing the new room.

public function initWorld(e:Event):void {
this.x = (stage.stageWidth)/2;
this.y = (stage.stageHeight-this.height)/2;
/* if crossing portal */
if (Myself.instance.nextRoomPortal != -1){
var portalId:int = Myself.instance.nextRoomPortal;
var portalObj:PortalObject = _map.portalList[portalId];
_myAvatar = drawAvatarInIsometric(
_sfs.myUserName,
int(portalObj.x),
int(portalObj.y)
);
}else
...
}

One last thing to do is to clear the old world and map resources before creating the new graphics of the new room.

private function onExtensionResponse(e:SFSEvent):void
{
var data:Object = e.params.dataObj;
if (data.posx != undefined){
Myself.instance.isoPosX = data.posx;
Myself.instance.isoPosY = data.posy;
}
if (_world != null){
removeChild(_world);
_world = null;
}
_world = new World();
addChild(_world);
}

We have created some rooms and connected them. What we have not done is check any failure when joining the new room. Joining room is not always successful. A common error is that the room is full. We can track these errors by handling the onJoinRoomError event.

Besides connecting places, we can also use triggers for some special events. They can discover new items, discover new places, or trigger some mechanism tricks. Adding different types of triggers can enhance the fun of the virtual world — for example, a trigger that switches on or off the streetlight and makes the whole room bright or dark. It provides some fun Easter eggs when the players walk on the street.

Another example from the 51Mole (http://www.51mole.com/), a Flash virtual world that targets Chinese children — when four players sit on the chairs in a room, some fireworks may appear on the screen. These types of triggers are just for fun to enhance the interactivity between players and sometime give them surprises.