[MUD-Dev] Re: My vision for DevMUD
thandor at donut.dhis.org
Tue Nov 3 20:25:53 New Zealand Daylight Time 1998
On Tue, Nov 03, 1998 at 12:20:57AM -0800, Jon Leonard wrote:
> I'm interested in building a MUD server which is well suited to development
> of experimental MUD features. Support for commercial use, optimized
> implementations, etc. are secondary.
Ah, finally someone has said what they want DevMUD to do and some sort of
priority oirdering. And reasonable goals to boot.
> 2) The licence should by default be public domain. This provides the least
> impediments to using the code for experimentation. Allowing some modules
> with different licenses is useful for reusing existing code.
Hmm, I would argue that a LGPL style license where people are "forced" to
contribute back should they make changes would be of more benefit if the
goal is to learn from this experiment. I say LGPL because this leave no
barriers to someone using the modules and linking them with their own to
make a commercial product. That seems to me to be a more logical way of
doing things, but I could be wrong. :)
> 3) The code should be well documented, and where possible easy to understand.
> This is also for ease of making expirimental modifications.
Ah yes, glad that this is a key point. How do you plan on enforcing that it
be well documented though? Human (or at least programmer :P ) nature seems
to be only do documentation when there's some external force. ;)
> 4) There should be more than one example collection of modules, as not all
> expiriments would use the same starting point.
Good idea, although I think it's more important to finish one set of
example modules before worrying about a second.
> There are a few other decisions that affect modules in a project of this
> type. In particular, I prefer:
All sounds pretty reasonable here. And at least some decisions being made
rather than complete generica.
> General DevMUD structure:
> There should be a generic bootstrap loader, whose responsibility is to
> provide module loading facilties and little else. It is responsible
> for loading a more specialized config module, which has responsibility
> for loading and configuring the rest of the modules in the system. A
> typical config module will probably qickly delegate control to a script
> in an in-mud language.
If the bootstrap module is always going to be loading a config module no
matter what, is there really any point in them being seperate modules? Even
if you want the possibility of different config modules, why not make the
bootstrap code a library which can be linked into any config module someone
decides to build? I just see no reason in having a seperate module that we
know is going to be loaded anyway.
> I envision at least two demo MUDs:
Since both demo muds are non graphical, may I suggest that a graphical demo
mud might be a good idea at some stage?
> I have more thoughts, of course, but that's generally where I'm coming from.
> I'm volunteering to be project maintainer for such a project (including
> hosting on my server), including writing some usable collections of modules
> if necessary to jumpstart the project.
Well, since you're the only one who's volunteered so far, you've got my
support at this stage. ;)
Seriously though, I'm liking what you've writen as it seems to at least be
more of a vision than a game server which does everything, it actually
states some more specific goals - though I would like to see them clarified
further. Even skeptical little me can see some hope of a useful system
coming from this.
- Shane King.
More information about the MUD-Dev