The Client/Server Model

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.

There are, however, engineering considerations specific to the implementation of virtual worlds that impact directly on the virtual world itself. These are unavoidable, and designers must be aware of them.

To illustrate: In theory, the same virtual world could be presented using different skins, so whereas one player might see a defense robot discharging an energy weapon, another might see a wizard wielding a wand. This is something that players would find novel, but it presents a major challenge to designers. Few genres map onto each other to this extent, so compromises would have to be made.

As it happens, this particular example is a red herring because the amount of artwork necessary to support just one, let alone two, genre is considerable. The benefits aren’t worth the cost. Textual worlds are easier to reskin than graphical ones in this respect, of course, but have less reason to want to do it ². In practice, using skins for graphical clients means altering the look and layout of the client’s interface, not the look of what it displays of the virtual world. Hanging different curtains doesn’t change the view through the window.

It turns out that there are only two issues relating to the client/server relationship that have concrete effects on the design of virtual worlds, but both of them are very important: synchronization and security.