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

[Niklas Elmqvist]

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 th=
is
> > list becoming involved in the project since it *should* cater to just
> > about any kind of MUD developer/designer.
>=20
> Which IMHO is a bad idea (I guess I have said that a couple of times no=
w)
> from a system development point of view, especially if you are going to
> break new ground.

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 t=
o
use and look at is almost a secondary goal to me (at least at the moment).

> Anyway, I believe evolutionary/participatory/usercentered were the buzz=
words
> of the 90's... I've never seen anyone argue that one should skip preana=
lysis
> and avoid defining goals etc.

Right. It's probably been too little of that.=20

> Well, it is practical to actually find the major problems instead of ju=
mping
> on the first one which looks cool and which is so remote to the final s=
ystem
> that there are no strong opinions about it.  If you avoid discussing th=
e
> conceptual "objectsystem" only because it will lead to a heated debate =
then
> the project is already off tracks.  Actually, recovering from a heated
> situation early in the project can be very good in the long term.  Brin=
g up
> all the conflicts you can early on. It's good for the group to confirm =
that
> it can handle such situations. (Besides, it is a good idea to resolve
> conflicting views before members have invested too much pride in them).

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

> > Whoa! Grumpy today, are we? You are being more than a little unfair, =
I
> > would say. I, for one, am *very* interested in design and analysis,
> > especially in the context of OO, and I am sure that other DevMUD
> > supporters are as well. Trust me, I *know* the importance of good des=
ign
> > and thinking before you code -- I've been in the situation of not hav=
ing
> > done that and being stuck with the results.
>=20
> OO as a methodology generally means you have (assume) a domain.  OO is
> useless without something to model.  At least by the scandinavian schoo=
l
> (which I assume you cherish?). Americans tends to think in terms of abs=
tract
> datatypes, which I don't think OO, as developed, is entirely suitable f=
or.
> (other more symbolic approaches look more promising)

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

> > The way I see it, DevMUD is a sort of kernel or development platform =
for
> > MUDs. It is *NOT* a MUD in itself! It is not even a codebase! Therefo=
re,
> > we have quite different design goals than a fully fledged MUD. Our mi=
ssion
> > (at least at this point, other things will follow later) is to make s=
ure
> > that we create a powerful-enough server platform to allow for just ab=
out
> > any feature developers want to add.
>=20
> Oaahhhhh :'(  You started so nicely with "OUR MISSION IS", sounded like=
 a
> vision coming, but then you followed up with "everything" which basical=
ly
> means "nothing". :(

Right. I'll rephrase to one I *think* has meaning: "Our mission is to mak=
e
sure that we create a powerful-enough game server platform to allow game
developers to implement just about any game feature in it." Happy? (I
presume not, of course.)=20

> So, the current context and goals are thus (combining various input,
> avoiding technical implementation):
>=20
> - 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.

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 are
*not* speaking about a MUD server! DevMUD (actually, DevCore -- sorry
about this) is a MUD server platform (or, even better, a game server
platform).=20

Nevertheless, this is good. While I don't agree with many of your
conclusions here on the basis that I would say that we have touched upon
them, it uncovers a lot of our blind spots. You are also right in saying
that we may have been a bit too generic. Thank you.=20

Okay, I'll have a shot at defining the high-level assumptions. Not much i=
n
the way of a formal analysis, but it's a start! Please fill in (or
remove?) more items here, keeping in mind that we're trying to do
conceptual analysis. And remember, these apply to DevCore, not necessaril=
y
to DevMUD...

DevCore high-level goals:
 - create a state-of-the-art game server platform (advance an unrealised
	future...)
 - provide fertile soil for building internet games
 - efficiency

Design philosophy:
  Lean and mean.

Target audience:
 - MUD developers
 - commercial game developers

Main functionality:
 - game logic is dynamically loaded in native code modules
 - the core is like an API for modules
 - the core provides ways of inter-module communication, probably using
	plain C bindings (function pointers), which can be used to
	negotiate higher-level protocols
 - multi-threading (modules request threads from core)
 - event manager (modules pass their events here in the safe knowledge
	they eventually will be executed)
 - module manager/bootstrapper (takes care of the loading and unloading o=
f
	modules)

Technical decisions:
 - Dynamic loading of modules
	- easy replacement of game logic (avoid downtime, important for
		commercial developers at least)
	- effortless extension and/or modification
 - C bindings will be used as the "glue" between modules

> > Of course, it is certainly useful to try to view DevMUD from the cont=
ext
> > of different game types
>=20
> It should be mandatory. (but a lot of work)

Agreed. We need to look into this.

> 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*

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.=20

> Ola

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "The trouble with being a god is that you've got no one to=20
   pray to."
		-- Terry Pratchett, Small Gods