On Architecture on Designing Virtual Worlds

Overall Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Actual architectures differ from developer to developer, but they can almost all be regarded as variations of a single generic approach that emphasizes reliability, scalability, and maintainability. Figure 2.1 illustrates this overall architecture.

Figure 2.1 Overall architecture.

Here’s how it works.

Central to the system is the user database. This is a powerful piece of software running on its own, fast machine with lots of storage. It contains records for all the players registered for the virtual world. Before anyone can access content, they must first log in; this means checking with the user database. Other parts of the complete system (not shown in Figure 2.1) for billing, customer service management, and patching also have access to the user database. It’s a very important, industrial-strength system, and is therefore usually bought in rather than programmed in-house.

Server Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Server clusters implement instances of the virtual world. There may be programmed differences between them (attacking other players might be allowed on one but not on another, for example), but these are generally minimal in form if not effect. The number of servers present in a cluster varies from implementation to implementation, but it’s usually around half a dozen or so. The number of clusters also varies, with more clusters being added as a product’s popularity increases (EverQuest hit 40 server clusters in 2000, averaging around 1,500 players simultaneously on each one at peak time).

Load Balancing

Mon, 01 Jan 0001 00:00:00 +0000

Fortunately, the arcane subject of load balancing is not something with which designers need concern themselves directly. However, they do need to be aware of the consequences of whatever solution is adopted by the technical experts, especially because they are likely to be consulted on the matter.

Ideally, a virtual world would run on a single, very powerful computer. For textual worlds, this is already the case ¹. Graphical worlds may go the same way ², but for the moment there are still plenty of things on which newly available computational resources could be spent at the server side:

Other Things Happen

Mon, 01 Jan 0001 00:00:00 +0000

Although players are the main source of the load on virtual worlds’ supporting hardware, they are not the only one. Things can happen whether or not players are present. Some of it is mechanistic: The virtual world’s sun rises and sets, its weather comes and goes, all irrespective of whether there are players around. For a highly detailed world, this could amount to considerable work (a breeze rustles individual leaves on a tree, one of which falls off to land in a stream that carries it lazily to a river and thence to the sea). Virtual worlds of this complexity are some way off at the moment, though.

The Client/Server Model

Mon, 01 Jan 0001 00:00:00 +0000

The server embodies the virtual world; the client translates it into a form the player can comprehend. Because the client is the player’s window on the virtual world, designers have a lot to say about its look and feel. Much of this is a matter of taste and convention, though, and will therefore not be discussed here. Clearly, it does make a difference if your proposed spell-casting system is too complicated to be implemented for mouse and keyboard ¹, but if this kind of thing isn’t obvious to you, then you’ve no business being a designer anyway.

Synchronization

Mon, 01 Jan 0001 00:00:00 +0000

It takes time for information to travel between the client and the server. It takes time for the server to execute commands. During this time, the client has to maintain its display of the virtual world. What it shows may not, therefore, be a true representation of what the server defines to be the current world state: The two aren’t synchronized. In the real world, the sun might have spontaneously exploded 19 seconds ago, but you’re not going to find out for another eight minutes. In a virtual world, someone may have quit four seconds before you loosed an arrow at him.

Security

Mon, 01 Jan 0001 00:00:00 +0000

Your client software will be hacked. For some virtual worlds (such as those with no game aspect to them), this won’t necessarily matter. For the rest, it matters a great deal.

At the very least, it means that all packets sent from the client to the server have to be checked to see if they make sense. Error-correction at the hardware and transport layers should ensure that what arrives at the server is what was sent by the client, so why waste time checking for nonsense that isn’t going to come? Well, the fact is that the server may not be talking to a bona fide client. It could be talking to a piece of code a player has written to masquerade as a client or to insert data into the client’s packet stream. If the server receives nonsense but has no way of handling it, what happens then? Has someone acquired an ability to crash the server?