[MUD-Dev] Re: PDMud, Gamora and Casbah

[Darrin Hyrup]

At 12:31 PM 10/24/98 -0700, Jon Leonard wrote:
>On Sat, Oct 24, 1998 at 07:19:46AM +0200, Niklas Elmqvist wrote:
>> On Fri, 23 Oct 1998, Bruce Mitchener, Jr. wrote:
>>> Has anyone looked at Gamora, http://php.indiana.edu/~scgmille/gamora.html
>>> or possibly Casbah, http://www.ntlug.org/casbah/ ?  Both of them have some
>>> ideas or features that may be interesting for those working on PDMud.
>>
>> Took a quick look at it, and at least Gamora looks *very* close to what
>> *I* envision for PDMud. It uses a Bus architecture for passing messages
>> around and plugin objects which are handled by different threads, one for
>> each plugin. Still, what I personally envision for PDMud seems to be
>> different from what most people want from it. Fair enough; I am not going
>> to play difficult :) 
>> 
>> (Small voice: I still want to do it O-O. Wanto! Wanto!!! :)
>
>Those look like reasonable architectures, albiet ones that are fairly far
>from the design I envisioned.  It may be that we can't all agree on an
>architecture (or implementation language, or mudlib, or...) and the
>project will have to fragment at some point.

Granted, we can't make the ultimate mud, but we can provide the ultimate
base for the mud itself, and the tools to use it, from which the ultimate
mud (whatever that means to you) could potentially be created.

>Some amount of fragmentation is good:  We certainly don't want all MUDs to
>be identical.  The real question is where does DevMUD development fragment:
>
>Implementation language?
>Module format?
>Module connection architecture?
>Modules used?
>In-game language?
>Mudlib?
>Only in gameworld details after install?

As long as we adopt the plug in module approach, we only need to agree on:

Driver kernel architecture
Driver implementation language
Minimum supported feature base in the driver
Plug-in module format
Plug-in module connection architecture

Once we have that, most of the rest of the items on your list could be
tailored to the individual mud developer, based on what they want/need.

>What I'm trying to find is an architecture acceptable to a reasonably large
>number of developers (including me!), so that we can more quickly build our
>ideal MUDs.  If there are people who don't like that design, and they form 
>an alternate development team, that's great.  We'd wind up with more good
>examples of MUDs, and it's still less total effort expended than without
>collaboration.

True... but I think we can find some common ground through which we can all
express our individual requirements and build towards our eventual goal.
We should also keep in mind that (at least for me) part of the purpose
behind this is to help educate current and future members of the list.  All
of us are talented developers in our right, some of us overlap in skills
and degree of talent, but I'm sure we will all learn more from doing a
project like this than we'd ever learn doing it on our own... not to
mention we have more diversity of resources to call upon.

>I'd be shocked if we all used the same collection of modules, and if we
>fragment before that, at least we can still port code back and forth.

That's the point... once we have the low-level driver, and the format for
how expansion should work, we can chose to break up into sub-teams to
develop the features we share in common for the modules and internal
language interface.  What I'd like to see happen is that the team develops
a "DevMud" of our own, something fairly generic, primarily used just to
test the code base, and show an example of the project taken to its
conclusion.  (Sort of like a distributed mud code/mudlib for the other muds
out there.)  So, newbies could take that base and modify it to create their
own varients of the GenericMUD core, and those with more creativity can
create their own mud cores from scratch, using the example (and our
development history documentation) to guide them.

>So by all means, describe your ideal design.  You may yet convince a design
>team, and the rest of us probably want to see it anyway.

In the end, I'm sure that will happen anyway... but I think for now we
should just focus on getting this project going, develop a simple mud using
this system, show it can be done, and then we can break up into groups and
make our own projects come to life!

Best,

Darrin