MMORPG Protocol Requirements

Functional Requirements

Client to Server

• Ability to transmit complex types
• Complex types can contain primitive types and other complex types (like XML)
• Way of defining messages schemas for validation (like XSD)

• Keepalive
• Account creation, updating and deletion
• Login (hashed passwords) and logout
• Avatar creation, updating and deletion
• Avatar activation and deactivation
• Command and responce messaging:
  • Requesting objects at given area
  • Requesting object
  • Commanding avatar
  • ...
• Efficient object observation channel:
  • State observation
  • State change observation
  • Location observation
  • Movement observation
  • Action observation
  • Interaction observation
• Version-aware media download via HTTP.

Server to Server

• Keepalive
• Handshake
• Spatial neighbour link/unlink
• Transfering objects over spatial boundaries
• Inter server object observation
• Inter server object interaction

Nonfunctional Requirements

Design

• Protocol has to be as simple as possible.
• Protocol has to be easy to implement.
• Protocol has to be divided to compliance levels to lower the initial implementation effort to achieve level 1 compliance.
• Protocol should allow efficient (parsing and size) observation message structures.
• The protocol must be independent of:
  • Application (the application using it, the calling program) for example: backstage, cyphesis, uclient, anvil...
  • Session (management of connections or multiple connections)
  • Transport (the mechanism for transporting the data between processes) for example: TCP or UDP sockets, saving to a file, IPX, and so on.
  • Language (Protocol has be implementable with any sane language.)

Implementation

• Specification
• User guide
• Reference implementations on C++/Java/C#
• Test benches and test sets are required for automatic evaluation of compliance and performance.

Performance

• Performance requirements should be given for several categories so that implementations can be categorized according to performance test results.
• 1000 players per server of which average player is observing 50 players.
• Player observes smooth movement (30 frames per second+)
  • 10 observation rounds per second. (Client is observing each object 10 per second and using interpolation and 200 ms buffer).

These requirements with 50 byte observation message size cause 25 Mbytes/second network load, which roughly corresponds to 200Mbits/second server bandwidth. You can safely assume that protocol and network bandwidth can easily become bottleneck in MMORPG servers. As all community servers can not be expected to be hooked to internet backbone with 200Mbits/second bandwidth it is worth the trouble to minimize the observation message size and required observation rounds per second.

Optimizing Performance

Here's some way we could optimize amount of needed update packets:

• A very simple optimization is to not send any (or only very infrequent) updates if the velocity vector did not change - the client can calculate the position based on the previous known position and velocity and the current time. Much movement is continuous in this way, and many objects don't move very often, so this should already cut down a lot on the required bandwidth.
• Don't send updates when the velocity vector changes very little. If the change is insignificantly small, why bother? We would need to be careful with this, though. A small vector change will make a significant difference in a short amount of time.
• Another way to optimize this is to provide less frequent updates for distant objects. The client can interpolate their position based on the previous known position and velocity, and if it allows a certain error in the position (so that it is continuously being adjusted towards the last known correct position), then the movement should still look smooth, and the distance makes it less important whether it is exactly in the right place. This optimization also has the potential to reduce bandwidth usage, provided objects are relatively evenly distributed.
• Gracefully degrade update frequency if the amount of objects are too high, to stay under some configured amount (this isn't really an optimization approach, just a way to cope with e.g. areas with a lot of people without causing disconnects or such).
• Optimize the world design to avoid 'hot spots' like important, unique shops, auction houses, etc (consider e.g. the packed auction houses in WoW). Some local centers are needed, but as the playerbase grows, essential functions should be spread out and be available in several places. in these kinds of hotspots, a lot of players can see a lot of players move around, creating an amount of traffic that is O(n^2) to the number of players. It could also be possible to reduce the update frequency in these kinds of crowded locations, or use the above approach and send less frequent updates for people on the other side of the crowd.

-- zzorn 2006-11-22

Reliability

• Protocol implementation should minimize network lag effects to the observation functionality which is required to provide smooth movement to the end user.