[MUD-Dev] Component Design (was: Extensibility)

[Scion Altera]

Sunday, May 05, 2002, 1:42:10 PM, 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?

Of course. Many Java applications use a plugin model where you can
dynamically load classes written for the program's standard API
while the program is running in order to have additional
functionality. One of my favorite examples is jEdit, a free text
editor available on Sourceforge. Support for a mouse wheel isn't
standard with the program, but Java 1.4 has an API for mouse
wheels. Somebody wrote a plugin for jEdit that makes the mouse wheel
work. You download the plugin from inside the program, restart it,
and poof... the mouse wheel works.

The major limitation for dynamic classloading is that you can only
load one version of a class. You're supposed to be able to get rid
of dynamically loaded classes by getting rid of their classloader
and instantiating a new one, but I've never had any success with
that myself. So, if you have a plugin model for your game and you
modify one of your plugin classes and recompile it, you must reboot
your game in order to reload the class.

A plugin works using the API of the program it is written for: your
MUD server would have to provide a set of objects a plugin
programmer could use to effect change within the game from the
plugin's object(s). This does of course mean that a plugin written
for my custom written Java MUD probably won't work with a plugin
written for your custom written Java MUD, but that a plugin for copy
A of my Java MUD would "plug in" to copy B of my Java MUD without
any problem.

Concerns to think about when implementing plugins: the game engine
would have to call some kind of update method on the plugin on a
regular basis, or perhaps pass events to the plugins that they can
respond to. Otherwise they'd just sit there doing nothing all the
time. Unreal Tournament uses a scripting language you can write
"mutators" for, which are basically the same idea as these
plugins. UT calls the first mutator and the implicit contract when
writing mutators is that the last thing you do is call the next
mutator that needs to be updated. I prefer to have the game engine
explicitly maintain a list of all objects which need to be updating
and not rely on the plugin authors, but I think by now you probably
get the idea.

Hope I've done more than confuse the issue :)

-- Scion

"If you don't find it in the index, look very carefully through the
entire catalogue." -- Sears, Roebuck, and Co., Consumer's Guide,
1897
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev