Multiplayer Technology Today

I don't want to spend much time discussing the current approaches, but I'll include something about them if only for completeness. I expect pragmatism and games companies desiring to get games out by Christmas 'this year' rather than 'five years hence' are the essential reasons why massive multiplayer games are not yet really with us. And why sell a hundred player game if a ten player game sells just as well?

General Techniques. All multiplayer games based on networked computers will adopt an approach that is either about communicating input, or communicating the game model. A combination of these two can also be used where with some effort the 'need to know' relationships between players have been computed, typically based on their proximity with each other in the game world.

Note that in the following lists 'user input' can be communicated in its raw form or can be processed into higher level forms (possibly within the context of the game model).

Peer to Peer. This approach is where each computer runs the game model, but communicates with its peers in order to synchronise and ensure consistency. Three variations I can think of off the cuff:

• Each computer publishes its user's input to all others
  
  
• User input is collected by a central point and then republished to subscribers
  
  
• A master model collects input and publishes model deltas

Most early multiplayer games adopt one of these approaches.

Client/Server. This approach is where only a single server runs the game model and all user input is fed into this. Each client performs only enough computation to present the user's view of the scene. However, it may be that there is little difference between the client software that models the local scene and the server software that models the entire game model, i.e. it's only the nature of the data that's different. Another selection of flavors that this approach may come in:

• Clients download compressed frames (MPEG say) or scene graph deltas (high bandwidth)
  
  
• Clients running scene modellers download scene changes
  
  
• Clients running scene modellers periodically download whole scene states followed by regular updates

Multi-Server. Multiple servers run the game model, replication being co-ordinated by a super server. Sometimes replication is not performed, instead each server runs an independent portion of the game model and services only those players currently located in that portion.

More recent games such as the RPGs, namely: Ultima Online, EverQuest, Meridian 59, Asheron's Call, and Diablo, will probably be using client/server or multi-server approaches.

Distributed System. The distributed systems approach is where a system of replication is used which doesn't make any distinction between participating computers. In effect, all computers are simultaneously behaving as peer, client, and server, depending upon their relationship with each other. Furthermore these relationships may be continuously changing, and the proportion of the model that each computer stores and processes will also change according to its need and capacity.

There is not necessarily any particular computer that needs to be ultimate control or in full possession of the entire game model at any one moment. A true distributed system is a fully collaborative effort, shared among all. However, it's still important that at some point, this system presents itself to the game application as though it existed upon a single computer - this is termed 'transparency'.

Names to plug into your search engines are: InVerse (Sandeep Singhal), Bamboo (Kent Watsen), and HLA - High Level Architecture (Judith Dahmann). Don't think that these are all similar, or even paragons of distributed systems, rather just take them as a tiny sample of the variety of approaches that can be adopted, including assorted elements of brute force, pragmatism, and elegance.

I'll not be exploring these or any other particular approaches. I'll examine the essential tasks of any distributed system that is to form the basis of a massive multiplayer games engine. If you want real-world facts in the meantime, checking out the above might be somewhere to start.

Scalable Today - Here Tomorrow

What people are only just beginning to appreciate, is how differently one has to approach the design and implementation of global scale systems. The Web is one of the best known and, along with e-mail, represent effective systems. This is due in large part to the fact that they work whatever the size of the network and number of users that they must support (OK, with a bit of tweaking over the years). Global scale systems are unlikely to succeed if they are designed for a specific level of demand or resource availability. This is despite the attraction of developing a system optimised for a specific environment and usage, given it will tend to outperform a system that can adapt to any environment. The point to note is that the latter only needs to be written once.

When a system has to reach a global scale, you don't want to rewrite it each time it has to cope with another order of magnitude in scale. The system has to look after itself.

The Internet, being a high-speed, natural selection environment (for companies if nothing else) will tend to select systems that get adopted most rapidly. A system that works as well for a million as well as for a hundred players and doesn't require another 100 database specialists on the development team, or investment in individual servers all over the planet, will leapfrog one that does.

If you develop a system that grinds to a halt once 10,000 players participate, then while you're fixing the problem, you'll be overtaken by one that grinds to a halt at 100,000. Both will be overtaken by a system that scales to any number. And any system that requires significant expenditure upon infrastructure in linear proportion to its scale will become unaffordable.

For example, imagine having to cough up a few grand for a new server every time you sell another thousand copies of your game. No, don't bother, plenty of companies think this is reasonable, so I'm wasting bytes trying to convince you otherwise. I'll just leave it that you have to start designing systems like viruses or worms, i.e. totally autonomous and self-organizing. You want to write a game and that's it. No hosting deals with ISPs, or administrating a load of servers. Beware the vested interests that will try to maintain the multi-server approach - there's a lot of money in it.

From another perspective, if your game engine isn't scalable it will be as future-proof as storing a year in two digits. Yup, 'Scalable Systems' is the next paradigm shift after 'Object Orientation', and funnily enough it's also alliterative.