[MUD-Dev] Re: Fallacy Watch and DevMUD Vision (was Re: ... CoolComponentCore)

[Hal Black]

Ola,
   I think you made some good points about the statically linked model, a=
nd
some even better points about doing a lot of hard thinking and design ahe=
ad
of time.  However, setting up all these straw men to burn down does not d=
o
justice to your otherwise good comments.

On Sun, Nov 01, 1998 at 01:54:13PM +0100, Ola Fosheim Gr=F8stad wrote:
> On the technical decisions "made":
>=20
> - DevMUD will have dynamic loadable modules because it is cool (and bec=
ause
> it is used in mainframes, it looks like Java, it is used in Windows as =
a
> replacement for a sucking memory model, because it is used for OS devic=
e
> drivers, plug'n'play and that makes it a good idea)

A nice straw man, but you neglected to mention any of the reasons that pe=
ople
have posted that they want dynamically loaded modules.  Please allow me t=
o
reiterate.

1. Dynamically loading a module is one way to avoid a huge cache miss (bo=
th
writing and reading) for all the state in all other modules which would b=
e
caused by shutting down and restarting the whole mud (unless you have som=
e hack
to make your data stay there while you reload).  This could cost a substa=
ntial
amount of time depending on the mud (not all muds have a small memory foo=
tprint
and loading time) and the frequency at which it is used (some coders will
reload modules in their test server more than once a month - maybe 20 tim=
es an
hour if they were changing a lot of different modules).  Maybe none of th=
is is
worth dynamic loading to YOU.  That doesn't mean that it isn't valuable t=
o ME.
Or that it is a viewpoint worth scorn as a "cool feature".

2. If a suitably large toolkit of modules existed, people less of the com=
puter
geeky and more of the creative variety would be able to download modules =
and
put them together without a compiler (linker).

3. You could also use this to take care of something that several people =
have
mentioned about keeping the client connections alive between reboots, ins=
tead
of having a seperate program.  There's at least two ways to do it, dynami=
c
loading is one of them.

Now, dynamic loading might not be the only way to do these things, but it=
 seems
to me to be a straightforward way, and that is at least worth considerati=
on.

> - DevMUD will have a Virtual Machinelanguage because it is cool (everyb=
ody
> does it)

If there's going to be some in-game programming language (which a lot of
people seem to think would be a good thing to have), there is going to be
something like a virtual machine, even if it's a simple interpreter.

> - DevMUD will use the eventmodel because it is cool (scalability is
> paramount)

I'd like to use an event-based execution model, because it maps well to M=
UD
execution (as opposed to that of, say linear algebra or bovine cracking)

> - DevMUD will use 16 bit chars because it is cool (it is an internation=
al
> effort as well)

I guess I can't disagree with that assesment.  Some people think it is co=
ol
to have slashes and dots through and around their vowels.  I am not one o=
f
them, but I guess some people have use for it.  And apparently the folks =
from
UO think it is cool to put a babelfish in everyone's ear so that people f=
rom
all around the world can play and talk with one-another.  I think that's =
cool.
I'm not going to do it for my mud, so I don't particularly want any more =
than 8
bits for a text character.  I can see how, for instance, Korean people mi=
ght
like it, to see all of the beautiful oriental characters of their native
language in the game.

> Maybe you should consider renaming the project CoolComponentCore?  (or
> GeekCore?)  Ah well, I think I'll stick to PhotonCore (fast'n'light ;-)

Hmm, name calling, and a slightly veiled ad hominem.

Additionally, we have an underlying contradiction here.  On one hand, you=
 argue
that one can't design the core without first having a plan for what the m=
ud
should do, and on the other, you say that static is better than dynamic.

I do agree, however, that some planning needs to be done.  Perhaps we nee=
d
a problem statement, or a statement of purpose for DevMUD.

> Anyone who has tried to develop a framework to be used by others (I hav=
e)
> will probably discover that it is extremely hard, and once it is done, =
even
> if you do document it, almost all users will give up understanding the
> underlying foundation and settle for some slight modifications of the
> surface instead. DevMUD does have a better chance than most frameworks,=
 but
> only if it involves potential users throughout the process... :-/ Which
> suggests: involve as many developers as possible, at least in reviews, =
don't
> push them away, but set up a huge todo-list instead :-)

Agreed, a great idea.  We need a big TODO file in CVS that everyone can a=
dd
to.  Or perhaps a family of TODO files for better organization (TODO.feat=
ures
TODO.modules, plus individual TODO files in each module's home for that m=
odule)

> I am honestly not sure if the generic approach is worth it. Perhaps a g=
ood
> shiny surface which slight modifications on would look good and have a =
real
> impact on the world is better for the muddingcommunity... *shrug*

What generic issues would you remove?  Bind it to text-only clients?
Room-based only?  No virtual machine?  (not rhetorical, I'd really like t=
o
know)

But this does come back to a VERY important point that you made, which ha=
s
not yet been satisfactorily answered:  What ARE the design goals of DevMU=
D??
No one wants to pin it down and say what it should do and what it should =
not.
I think that the core design is very important, but perhaps it would help
to have the purpose pinned down so we can discuss the merits of the core
architecture in the context of the purpose of DevMUD.

I'll make an attempt.  I humbly submit my vision (feel free to revise):

                        -------------------------
DevMUD is a toolbox of modules that one can use to develop a new MUD, or
combine to run a complete MUD.

The modules that compose the DevMUD Toolbox would be modules that relate =
to
MUD operation.  The goal of these objects is to produce an abstract inter=
face
to functionality useful to a MUD.  Some examples of low-level functionali=
ty
would be: a peristent database storage module, a client communication mod=
ule,
spatial models, code interpreter/virtual machine, an event handler, etc.
Higher level modules would depend on these lower level modules for
functionality.

The DevMUD Toolbox will also contain these high level modules to illustra=
te
how modules can be put together to form a complete, fully functional MUD.

The DevMUD specification will dictate the module interface and protocol f=
or
module dependency.

The goal of DevMUD is to provide a springboard for MUD developers to desi=
gn
new MUD engines, without becoming mired down in the details of individual
components.  Because the DevMUD toolkit supplies usable low-level modules=
, the
MUD designer can simply use these modules, then concentrate on MUD design=
,
rather than become an expert in databases, networking protocols, compiler=
s,
and any other area already implemented in a module.  The motivation for w=
riting
DevMUD is to advance an unrealized future in MUD development as inspired =
by
the MUD-Dev mailing list.

The success of DevMUD will be judged not only by the quantity and variety=
 of
MUDs developed which use at least one module from the DevMUD toolkit, but
also by how many modules from the toolkit are used by these endeavors.

In Summary, DevMUD is composed of three parts:
1. The Specification: A specification for an interface of DevMUD modules.
2. The Glue: A means for linking such modules together while honoring the
   specification.
3. The Toolbox: A set of modules conforming to this interface specificati=
on,
   at least one subset of which will be a fully-functional MUD.
                        -------------------------

I've consciously tried to leave out implementation details, so that the
implementation is driven by the design goals, not visa-versa.  These are =
my
goals for DevMUD, I'm interested in what other people envision.  Hopefull=
y
I have made this specific enough so that Ola won't say I am asking for
"everything"  (I was careful not to mention world peace in the vision=20
statement).
  Once we settle on the goals for DevMUD, we can offer some more details.

     Hal