Client<-->Server Systems

We're all familiar with this kind of system. Even if we haven't used a MUD client like tintin++ or Zmud, we've certainly used telnet.

Clients like tintin++ and Zmud are designed to alter the data flowing to and from the MUD server. They can do interesting things like aliasing, and automatic reflex actions to take upon recipt of a certain trigger phrase. They can alter our perception of the data sent by the MUD, and can save information to files. Zmud even gives you a specially designed window to operate in, with little buttons for each command.

But such clients are limited due to the fact that they are designed around the telnet-tailored data that the MUD server transmits and recieves. They can do nothing to cut down use of network bandwidth, and ultimately cannot give you any more information than can be communicated in simple text. A well designed Client/Server system can go beyond these limitations.

A good example of what can be done with clients is netrek. Netrek is a multiplayer graphical combat game loosely based on Star Trek and played in realtime. The server sends a large amount of information to the client at login, and then sends perpetual updates in whatever changes take place. This allows a player to fly his starship about with virtually no lag-time between command and action.

The only difference between netrek and MUDs is that netrek needs to send more information at a higher rate than a MUD does! If we adopt a similar system, we'll have extra bandwidth coming out our ears!

The fundamental principle is: "Let the client do as much work as possible with as little data as possible". That is, store and maintain information recieved from the MUD, and only use the network to ask for more information, send commands, or to recieve updates.

We might even want to have the client program establish two connections to the server. That way, the client can send and receive background data continually, while leaving the player's command and odd message channel open.

The possibilities are endless. The client can download information about your surroundings before you enter them, cutting lag down to effectively nothing. With the knowlege that everything the MUD sends the player goes through the client, we could send all sorts of data, like .pov files for three dimensional picture rendering.

The client could even manage its own calculations for various actions taken by the player. The MUD need merely generate the random number for the client program to use, and need not bother sending any more than that, if the client has copies of the data structures involved.

To allow for future growth, the client could also have a simple "programming language." If the MUD server knows a skill that the client doesn't know, it could send over the steps that the client needs to take to determine the results of using the skill itself. Of course, this might be limited to simple programs at first, but with enough people tinkering, it will probably become quie sophisticated.

There you have it folks. My thoughts on the possibilities of this kind of system. If you have any other ideas you'd like to share, please send them in!