[MUD-Dev] Re: Designgoals for CoolComponentCore (Was Re: MUD-Dev's...)

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

Niklas Elmqvist wrote:
>=20
> On Sun, 1 Nov 1998, Ola Fosheim Gr=F8stad wrote:
> > Niklas Elmqvist wrote:
> > > Secondly, I can easily see a quite large portion of the members of =
this
> > > list becoming involved in the project since it *should* cater to ju=
st
> > > about any kind of MUD developer/designer.
> >
> > Which IMHO is a bad idea (I guess I have said that a couple of times =
now)
> > from a system development point of view, especially if you are going =
to
> > break new ground.
>=20
> I hear what you're saying. However, I am not sure that we *cannot* make
> this distinction like you are saying. The way I see it, DevCore (I like
> that name, btw) should be able to raise the abstraction level of MUD
> development from OS-level to a common-ground platform level. That there
> later will be modules built on top of this by DevMUD members for people=
 to
> use and look at is almost a secondary goal to me (at least at the momen=
t).

What you have gotten to so far is not far from UNIX with shared memory...
That's silly.

> Well, as stated by other list members (Chris, methinks), the participan=
ts
> of this list are quite experienced MUD developers which can be expected=
 to
> already *know* the key abstractions of a MUD server. We should of cours=
e
> take advantage of this. Then again, it is still imperative that we
> rigourously define these so that it is clear what we all want.

Well. The reason for me jumping in and wasting a lot of your and mine tim=
e
is the same reason for why a carpenter probably have trouble not telling =
you
that you could risk ruining your house when you try to do it all by
yourself. :(  Although I am sure that the list members have a lot of
experience, I am also quite sure that that experience is quite different!=
=20
And what people think is a good idea is also quite different...  If you
don't get a grip on this early on, then you risk some unpleasant problems
later.  Agreeing on a discussion which relates everything to a common
reference end-system could make some of these problems surface.

This is probably not enough, but it is at least a start. Studying systems
development might not teach me what you should do, but it does at least g=
ive
me some ideas about what is risky and how to somewhat reduce that risk. (=
You
don't want to end up like Multics, do you?)

> I couldn't answer which school I cherish since I'm self-taught as of ye=
t!
> :)

Ok, I don't think you are alone there.  Anyway, I'm sure you'll get enoug=
h
of that stuff at Chalmers.

> > Oaahhhhh :'(  You started so nicely with "OUR MISSION IS", sounded li=
ke a
> > vision coming, but then you followed up with "everything" which basic=
ally
> > means "nothing". :(
>=20
> Right. I'll rephrase to one I *think* has meaning: "Our mission is to m=
ake
> sure that we create a powerful-enough game server platform to allow gam=
e
> developers to implement just about any game feature in it." Happy? (I
> presume not, of course.)

No, but I guess I could be somewhat happy if you tell me how you are goin=
g
to make sure that this happens...

> > So, the current context and goals are thus (combining various input,
> > avoiding technical implementation):
> >
> > - DevMUD will do everything
> > - DevMUD requires no programming skills
> > - DevMUD allows developers to replace things they don't like on all
> >          levels with no external sideeffect
> > - DevMUD should cater for commercial needs
> > - DevMUD is developed for recreational reasons only
> > - DevMUD is fully public domain
> > - DevMUD assumes nothing about I/O
> > - DevMUD assumes nothing about lag
> > - DevMUD supports janpanese (and arab? (right to left)) users
> > - DevMUD supports graphical clients
> > - DevMUD supports text clients
> > - DevMUD does not assume any entities (not even connection, user,
> >          avatar, item?)
> > - DevMUD does not optimize for anything
> > - DevMUD will support both spatial and room models
> > - DevMUD is built using components provided by a wide variety of
> >         collaborators who don't assume anything beyond their own work.
>=20
> Again you seem to be lost in the distinction between DevMUD and DevCore
> (this might be because of the earlier name confusion, of course). We ar=
e
> *not* speaking about a MUD server! DevMUD (actually, DevCore -- sorry
> about this) is a MUD server platform (or, even better, a game server
> platform).

No, I have never lost that distinction.  However I don't think it is a go=
od
idea to make that distinction hard and forget about the context.  Why?=20
Because then you'll never be able to make rational decisions.  Everybody
want something without limitations, but ah, there are only a few cases wh=
ere
"less is more". Typically, not imposing constraints and avoiding decision=
s
leads to a huge machinery which does almost nothing... IMO

Making a framework is the most difficult thing you could do... A plugin
approach for a world where you basically WANT lots of interdependencies a=
nd
interaction is ahh... a challenge. Plugins for Netscape or a raytracer is=
 a
lot easier.

> Okay, I'll have a shot at defining the high-level assumptions. Not much=
 in
> the way of a formal analysis, but it's a start!

Analysis doesn't have to be rigid and formal.  In fact, the most popular
techniques seems to be quite informal. (drawing pictures with entities an=
d
conflicts for instance)  The output from the preliminary analysis should =
of
course be somewhat structured...

[a good start snipped]

> > > Of course, it is certainly useful to try to view DevMUD from the co=
ntext
> > > of different game types
> >
> > It should be mandatory. (but a lot of work)
>=20
> Agreed. We need to look into this.

May I propose that you find an existing MUD which is typical for the kind=
 of
MUDs that DevCore should support?  You probably want a system which almos=
t
everybody "knows".  Then see how this fits in the "plugin" approach.

1. Try to pinpoint the most important objects and their relation.
2. Sketch plugins. (combat,rooms,connections etc)
3. Identify where objects will be born and where they die.
4. Identify which plugins needs what info, and who changes what object.
5. Figure out where the bottlenecks will be.
6. Think about what you need to make the plugin approach work for this
particular system

Even though I think Bruce's survey would be even better, this approach do=
es
at least help you identify some fundamental problems which you otherwise
could miss out on. (assuming that throwing out "plugins" is not an otptio=
n)
 =20
> > I am honestly not sure if the generic approach is worth it. Perhaps a=
 good
> > shiny surface which slight modifications on would look good and have =
a real
> > impact on the world is better for the muddingcommunity... *shrug*
>=20
> Well... There problem is that there *are* already a lot of that kind of
> servers around. I would like to think of DevMUD as the "next generation=
"
> of MUD servers.

Good, something which belongs in the formulated vision. I am sure there i=
s a
lot of intuition around about what is wrong with the current generation
(beyond plugins), getting that down on paper (err) should be worthwhile.

--
Ola