Appearance

Newbies tend to believe that the appearance of a virtual world is very important; oldbies are generally more concerned with other features.

Virtual worlds are typically characterized as being either text-based (textual) or graphics-based (graphical). The former use words to describe locations, objects, and other players, whereas the latter use pictures.

There is, however, quite a spectrum between the two extremes. To access a textual virtual world, a player needs some kind of software connection to it. This may be direct—for example, by running the game server from a console and typing at its prompts—or it may be indirect through use of a client. If a client is involved it may be dumb, intelligent, or custom.

Strictly speaking, a dumb client does nothing except input (which it passes to a server), and output (which it does to whatever the server sends back). However, few clients are actually that dumb—even telnet can handle minor editing functions such as backspacing. It’s deliberate that dumb clients don’t do a lot, because that way they can be used for a greater variety of purposes.

Even when dealing with a dumb client—or no client at all—a virtual world need not merely consist of lifeless text. Individual letters, words, sentences, and paragraphs can be colorized by the server (usually using the ANSI standard understood by most PCs) to make the resulting display more attractive and meaningful.

Intelligent clients are intended for use with specific application types; in this particular case, that means textual virtual worlds. Such clients provide additional input functionality (such as macros or triggering) and tools for managing output (such as local logging and word-wrapping). Although these features could still be implemented at the server end and used with a dumb client, most modern server authors don’t bother with this as they know there are now so many ¹ good clients about that people will almost certainly be using one anyway.

Custom clients work only for the small subset of virtual worlds that share its protocol (in practice, this usually means just one). The client sends packets of information to the server describing what has been input. The server sends packets back telling the client what to output. Although the input protocol is usually not all that sophisticated, the output can contain embedded codes that will cause the client to do things, such as switch fonts, play sound effects and music, or display pictures. For a textual virtual world, the pictures will by definition be static affairs, this being more akin to an illustrated book than a movie. However, it serves to show just how far a text-based world can go without being classified as graphical.

As a rule of thumb, first- and second-age virtual worlds used dumb clients, third-age used intelligent clients, and fourth-age used custom clients.

Fifth-age (graphical) virtual worlds also use custom clients, but display the information a different way. The packets received by the client contain information that can be used by the client to render a scene. This will be either 2D (tessellated) or 3D (first-person), although doubtless “true 3D” (using some stereoscopic device to give depth to a scene) leading to full-blown VR isn’t all that far away.

Thus, to a newbie who neither knows nor cares about the underlying mechanisms, the difference between a virtual world that has moving pictures and one that doesn’t is fairly clear; indeed, it’s probably what attracted the newbie to one rather than the other in the first place. To an oldbie, however, who understands that the fundamental machinery for implementing the virtual world itself (embodied by the server) is much the same whatever the client, the distinction between graphical and textual worlds is mainly an interface issue (albeit a not-insignificant one).