[MUD-Dev] RE: Output Classification Notes, version 061098

[CJones at aagis.com]

> -----Original Message-----
> From: Mike L Kesl [mailto:mlkesl at cpinternet.com]
> Sent: Friday, July 10, 1998 12:08 AM
> To: mud-dev at kanga.nu
> Subject: [MUD-Dev] Output Classification Notes, version 061098
> 
> 
> . o O ( Output Classification ) O o .
> (mlkesl 061098)
> 
> Problem: The server needs to send different types of output 
> in different ways
> Goals: Provide client support beyond the standard 'dumb' 
> telnet client.
> 
> In order to be able to provide multiple clients in the most 
> efficient way
> I suggest we classify the server's output. In other words 
> different types
> of output will be sent in different ways, using the same 
> method names of
> course, but that is irrelevant for the non coders.

---->8 snip 8<----

I've been working on similar designs. (Gee, isn't everyone who 
knows Java and MUDded before writing a Java MUD?) Some of my design
ideas might be helpful, though they aren't in a nice document form.

Warning: these are somewhat highly Java-centric and may have limited
applicability to servers in other languages.

To summarize:

(1) I've defined a number of packages that provide MUD functionality.

Like you, I've tried to avoid genre-specific coding, at least in this
first code. My MUD packages are based around the idea of service 
objects (which allow the MUD to accept connections, run event queues,
serialize/deserialize objects from a database, etc.) and game objects 
(which incorporate the game rules).

(2) I designed a method to allow multiple player interfaces.

To do this, I have a Java interface called "Agent" which defines the
common methods for all player connections. A Listener object is 
assigned a port number and an Agent to give new connections. The Agent 
is then responsible for validating the log in and interpreting the 
player commands, converting them into MUD events, and interpreting 
MUD events and propagating them to the player.

In practice, imagine that I have three defined player interfaces:  
telnet (traditional), an Applet running from a web page on the MUD 
server, and an application that serious players can download. The 
telnet Agent takes the text descriptions from the MUD events and 
passes them directly to the player, then parses the player commands 
and converts them into events for the MUD. The Applet is not 
dissimilar, except that it provides bells and whistles like 
clicking to walk to your destination, graphical inventories and 
combat, etc. The application is the serious choice because it lets 
you have have a better window on the MUD, plus it will cache 
graphic elements between sessions, speeding up your apparent 
gameplay.

(3) I have locations defined in graphs.

This allows me to rip out sections of the world, do "cool" things like
teleport traps or matter-mitters, and change the appearance of my
world by changing how the graph understands itself. One early option
was to use a hex-based world instead of a gridded world. Another 
option is to use the graph like traditional MUD rooms that float in a 
void and can connect in any way. Currently, I'm defining locations in 
the grid to be small spaces, about one meter in size, and are 
orthogonal in presentation (with well defined north, south, east, and 
west).

This does lead to some issues in movement, perception, etc., that room
based MUDs don't have, which leads to...

(4) I have broadcast events with hop-count limits.

Events are broadcast from one location and propagate for a specified
lifetime. If you are talking to someone, you broadcast for five
locations. Whispering broadcasts for two locations (yourself, and all
the neighboring locations).

This gets interesting with things like a fireball, or even lighting
a torch. The fireball explosion will tend to be guided along corridors 
and spread out like ripples into open areas. Light will do the same 
thing.

Now, of course, I still need to define look methods which *can't* see
around corners. :-) This will also be the basis for ranged,
non-bouncing weapons (bullets, arrows, etc).

This can get expensive, of course, and events do not travel to the
same location twice. Events can also be passed directly to another
object (do not go through the intervening objects) via a method
call (message passing) or through the event queue (see below).

Events are thrown into an event queue by the generator and are
handled FIFO. High priority events are assumed to be handled by
message passing.

And if you're curious, the event objects are a bastardization between
the AWT 1.0 and 1.1 event models. Ick!

(5) I use an object registry.

Objects in the game will not have the same reference between loads.
I have arbitrary object references stored in a Vector (should probably
move to a different Collection in Java 1.2) and a hashtable. The
references are good for the current instance only, and serve to let
the MUD know what objects are in memory, and what needs to be loaded.

Though I wasn't planning on using this in the short term, I do plan on
serializing objects to a database. The serialization and reloading of
each object is defined based on the database, and is based on the
Java 1.1 Serializable interface. Note that Events are not serializable.


I started desiging this before I got on the MUD-DEV list, and have
learned a lot since then to help this. Among other things, I'm placing
the design on temporary hold until I've studied other MUD server
designs more closely. At present, I'm converting portions of the 
LambdaMOO server to Java in order to understand better how that system 
works.

I decided to design my MUD server in Java because (1) I haven't seen
a Java MUD completed to my level of satisfaction yet, (2) everyone
says Java has great language support for MUDs and I want to see how
well that pans out, and (3) I program in Java for a living.

In many ways I believe that C++ may have been a better choice, 
especially after examining the LambdaMOO source and noting some 
of the more flexible ways of defining data in C, but I'm dedicated 
to my choice--until I'm sure that it can't be done.

I chose not to try to get into another design effort (like White Orb)
because I'm fond of my design. I believe that I have a decent
architecture laid out, one that will allow strong additions to be
made later (like a full blown scripting language).


Mike, keep us posted about your MUD development. I'm always interested
in hearing about any technical or program hurdled you've come across,
and how you've taken care of them.

Chris Jones