Position Updates

One of the features of most multiplayer real time games and virtual worlds is updating each user's position on the screen. While there are many ways to do this in an ElectroServer application, some are better than others.

Before choosing which method to use to update position, answer these key questions:

• How often do we need the position updates for each user?
• How many users are in the same game, maximum?

The reason for these questions is that most of the ways to send the position update information go out immediately to everybody in the same room. Since the Flash player tends to break all socket connections if it gets too many socket messages in too short a time, if the product of the two answers to the above questions is 20 per second or more you really need to use queued messages from a plugin.

Immediate Updates

Each of the following ways to send position update messages is sent immediately to each person in the room. That means that if there could be 20 users in the room, each client would be limited to one update per second.

• User variables: store the current position as a user variable, and all users in the room listen for user variable events
• Room variables: store the current position of the user as a room variable named with this user's name. All users in the room listen for room variable events.
• Public messages: Send the current position as an EsObject attached to a public message. Users listen for public message events, and check the EsObject attached. Add a boolean to the EsObject that specifies whether this is a position update or chat message.
• Plugin message: Send the current position to a room plugin attached to this room. Room plugin adds the user's name and sends the message to the room.

Reducing Frequency of Position Update Messages

How do we reduce the number of position update messages we send? The most common way is to send the position every so many frames, and then other clients tween from the current position to the new one, timed so that it lasts approximately that number of frames. Another good solution here is to send a path that will be taken or destination, such as when a user clicks to move to a point.

Best Solution: Queued Plugin Messages

The overall best solution is to use a room plugin to send queued messages. This technique automatically accumulates messages for a given number of milliseconds, then sends them all as a single bundled message. The Flash player considers this one socket message, but the client application thinks that it is getting each message separately. If the queue is set to send every 200ms, then clients would either tween the other players or simply update them immediately which might cause a small amount of jerkiness in the display but not much.

The room plugin can still send immediate messages for events that require immediate notification, such as an end of round or end of game message. The only disadvantage to queued messages is that it does require a room plugin attached to the room.