Home   Info   DevZone   Wiki   UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ JavaMud ] [ not logged in ] [ Web: Imported ] goto:  options [ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

JavaMud is a MUD written in Java. Technically speaking a MUD can be written on most of languages, Java being among those. However, using Java represents an unique chance to make a MUD truly object oriented to it's roots.

I am wery interested to discuss this object and/or share the ideas with you.

FenixBird :O)

Definition of a Mud

This is a small introduction intended to shortly describe to newcomers of how a mud is built and what it has to do with Jos.

A simplified technical definition of a mud is that it is an object oriented interpreter.

Each room, item, person etc. is an object in a mud. The objects are in a class hierarchy, e.g. a room has a sword. This sword is a subclass object of the object room. Room resides in a house. House resides in a country. Country resides in a planet. Planet resides in an universe. So according this, the sword object with whole classa path would be universe.country.room.sword.

Each object may have attributes. E.g. sword could be magical, magicality could have level of power. Rooms have names, exits etc. The list goes on an on.

Each user of a mud is an object that intracts with the system. An user object may have a race and profession, e.g. a troll fighter.

Architecture

A mud consists of two parts. Client and a server. Server has the interpreter and stores the objects, whereas the client takes care of the presentation and user interaction.

When the server is started, it reads the initial state of the objects and starts to listen for the client requests. Clients open telnet sessions and start to interact with the server.

Programming a mud game

The most difficult thing in a mud is to define the class hierarchy. That is, it needs a good planning and ideas to build the game. But the programming part is easy once you get the grab of it.

A programmer is called a wizard. Wizard creates objects and defines the contents. In some mud's you do not have to shut the server process down in order to make modifications.

All mud objects are programmed with an object oriented c++ derivative.

Traditional Mud's

An example of freeware one is called lpmud. It also comes with Linux. Clients use a telnet session. On lpmud the server is called a driver. An example of commercial one is called ultima online and uses a windows client.

How does the traditional mud differ from JavaMud

Not much.

If you think about it, mud objects are programmed with c++ derivative. This language is similar to Java, so you might as wll use Java directly, if the server would support it.

So the real challence here is the server, not the client or building the mud game itself.

Architecture of a Mud server

A mud server program is basically an implementation of a kernel and an interpreter. If you look at the source code's of for example lpmud, you find the familiar elements of a kernel. Only real difference is that a mud server is ran as a process on top of a multipurpose operating system and the interpreter is linked into the mud server.

Server object store is similar to an object database.

If the Java Interpreter would be used instead of the Mud language, the size and complexity of a mud server would significantly decrease. If an object database would be used instead of server object store, the object management could be left out.

In fact, most of the java server could be written with Java.

So what's this got to do with Jos ?

Jos is a single purpose operating system and it is intended to run a single program, e.g. Java Interpreter. This itself makes it an ideal base for a Mud.

But Java is designed for clients, not for servers. A mud must have a master that would do the bookkeeping of the objects. In theory any client could be a master, but as soon as the number of users starts to grow, the trafic between clients would increase and slow down the system. Remember, all clients need to have a single view of chancing field of play.

Mud server would require services from Jos that could be part of the Jos itself. These parts would be beneficial not only for Mud, but also for the Jos.

Mud server requirements for Jos

This is a list of requirements that comes to my mind. These can already be part of the microkernel or I may have forgotten something.

Mud needs the following core facilities to get and set the following :

1. A heartbeat. A server needs to know if the user left the system and
save the state of objects. A mechanism to know who is using the system and who has left.
1. Object versioning. A wizard needs to be able to change or load new objects
to the game without rebooting the system. Jos needs to contain a register of objects and to know whether a new object needs to be loaded. On a mud objects are loaded dynamically, e.g. when a player enters a room, it is loaded from the object store or cache.

This could be used also for hot plugin device drivers.

1. Security. In order to replace an object Jos needs to know whether an object
is allowed to change. This would prevent the modification of vital parts of the Jos or mud.
1. Certify. A new object to be loaded needs to be loaded from an author defined
certificated site. This prevents an unauthorized person of overriting part of the game or Jos.
1. Encrypting. When an object is stored, it should be possible to encrypt it.
This would prevent the players to hack their characters by modifying the object's source.
1. Local filesystem. The object states need to be saved when stopping the
process and loaded when started.
1. Super user commands like kill session in the situations of error.
1. Message communication between objects. This is needed when user objects
interact.
1. Method of packaging network trafic. All of us cannot afford to stay on-line
all of time. On this era of ISDN services, the server could connect/reconnect the line only when an user requires an update of the objects. Objects could be passed on compressed format like zip. It is possible to do this totally in Java, but the performance might be too poor.
1. Backup or copy to another device.
1. Monitor processes or network trafic hooks to see the reason for performance
decration and user load. It is possible to do this totally in Java, but the performance might be too poor.
1. Anything else ? Please comment :O)

I would suggest to really write it entirely in Java since that's what JOS is all about, isn't it?

--CarstenEckelmann 29-MAY-98

Content of these pages are owned and copyrighted by the poster.
Hosted by: