The Beginning



Statement of Purpose



Network Structuring


Telnet<-->Server

Client<-->Server


Muds and Graphics

Graphics

MUDs with graphics- the dream of many a coder/implementor. How can we get a graphics-oriented MUD while maintaining the flexibility inherent in current MUDs?

Graphical Multi-User games have existed for years, but they are not designed to be altered. Sure, you can play Quake over the net, but all graphics are predefined and impossible to change. This is due to the fact that the bandwidth on the net is insufficient to transmit images as fast as it can transmit text. Therefore, all graphical games, up to this point, have had to have all images pre-loaded into the game before it can be played.

This is incompatible with the style of most MUDs. In a MUD, the environment is plastic. We expect to be able to change old objects and create new ones easily. Furthermore, we expect that sending these alterations to players is as rapid as the updates. "Graphical MUDs are impossible!" we wail.

But what if we could transmit 90K pictures without sending more than 1K over the network? It turns out that we can! Not with compression, but with client rendering.

POVray is just one kind of renderer. Actually, it's a ray-tracer, since it operates by tracing the paths that light would take from a light source to a camera, but that is irrelevant to this discussion. It reads in a file which contains information about what kinds of things those light rays bounce off of. The best thing about it is that a complex object, like a castle, need only be described in detail once. It can then be used any number of times, with nothing more than a line saying "object {Castle (co-ordinates)}".

I'm sure that you can already see the advantage of sending this kind of file rather than an actual image, but there's more to come. After the file is recieved, the world can be viewed from any viewpoint as easily as three numbers can be changed. This means that we can download the world-file at login, and be able to view the world from literally any viewpoint with no further communication from the MUD server. Don't believe me? See my example here.

But why stop there? Any MUD is a nothing more than a collection of virtual objects, each with a specific position, and each with specific qualities. What if we didn't download a rendering file, but simply the definitions of each type of object, along with the positions of those objects? The server can keep the client updated as to the location of each object, and when we want to see a picture of our surroundings, we have the client create a rendering file, and call the image renderer. This way, we can continuously alter our environment as we play.

The only problem is that rendering takes time, depending upon the complexity of the image to be rendered. If a player wanted to see his surroundings, he would have to wait perhaps 10 seconds or more to view the whole picture. So although graphics have been incorporated, MUDs will remain primarily text-based games.

Still, the possibilities opened up with graphics are too tempting to ignore. For the first time in MUD history, players could see where they are in relation to everything else in spacial terms. Now players can look down from the high mountaintops and see the land below them. Suddenly exploring becomes more interesting. Players can look off to the west, and catch glimpses of what awaits them there. Heck, a player-run "Photographer's Guild" may form, dedicated to exploration in the search of the perfect view.

This is the future of MUDs, and the future is now.


This site and all pages within © 1997 Michael Hohensee
But the ideas are free!
Space for this site provided by Geocities