[MUD-Dev] Extensibility

[Ammon Lauritzen]

On Sun, 5 May 2002, Ben Chambers wrote:

> Is it possible to use the ability of Java to dynamically load
> classes to make it easier to add new features to your MUD without
> recompiling?  I was thinking that instead of having code snippet
> archives it would be cool if there was some source of expandable
> Java classes.  You know, if you want this new feature, simply
> download this .class file and load it into the server using the
> graphical front end.  Then simply reboot the server (this might
> not be necessary) and without recompiling or anything you have
> updated your server.

Sounds a lot like lpc to me, just with a common mudlib. LP muds have
been modifiable w/o rebooting the server since the
beginning. However, the biggest problem is that there are too many
different libs to choose from, so files still have to be
'ported'. Some times the porting is easy.

Some times it is... more difficult. We have ported a few things from
other libs into our own, but with problems ranging from major issues
like different combat systems and class/guild/race structures down
to simple things like different messaging systems, it gets very
complicated very quickly.

> I don't know if this were possible, but if it is I would probably
> attempt to implement it in my MUD which I am about to start
> writing any day now :)

It would be possible if a lot of people used the exact same code
base (lib, same driver would help as well) and didn't modify the
underlying code. However, people like to tinker when able, and
things tend to drift apart fairly rapidly.

Certain things could be fairly easily ported if the programmers took
the time to make things as platform-neutral as possible (and
comment, heh).  Mobs, areas, and equipment are easy to port if you
know what all of the numbers are supposed to mean in the first
place, and if your combat and inventory systems are similar enough.

Even basic player commands could be made to be very modular, and
could be inserted into the system with minimal edits (probably
mainly for messaging purposes) as long as they were very strict to
avoid using features exclusive to their own lib.

The problem is that I would have a hard time actually writing code
like this, however, since I have become addicted to certain features
of my lib. I am sure that I am not alone in this sort of thing. Our
messaging commands parse grammar for the different listeners and use
names/pronouns where appropriate. I would be hard pressed to write
three messages for every one that I am writing now. There are lots
of other examples.

Certain libs have a large amount of damage types and use arrays to
store weapon and armour classes in these types. We use an integer
base and a mapping to modify that integer in special
circumstances. There are countless little tweaks that can be made to
a lib that suddenly render it incompatable with its friends and
neighbors.

--
Ammon Lauritzen
http://www.simud.org/

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev