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

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

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 just
> 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.

> Well, the way I see it, those are technical prototypes of some important
> aspects of DevMUD. It is quite important to ensure that the technical
> foundation upon which the project rests is a stable one. All major
> projects do this -- it is vital.

Actually, the first thing you do is to narrow in on the technical options,
usergroups, problemspace... Then you do a needsassesment and generally
collect relevant information, including the context the system is going to
operate in. Then you figure out what the real problems are. (maybe no
computersystem is needed at all, maybe management are trying to solve a
social problem with a computersystem)  Then you see what problems and areas
are so uncertain that you need to go for the more expensive prototyping
approach, which doesn't have to involve a computer at all.  After this you
enter the process which aims at design... Not that prototyping early on is a
bad idea if somebody wants to do it for free. It can be a very good idea,
sometimes you won't know until you have tried.
 
> If you've paid attention to current software engineering teachings in this
> area, you may be aware of the concept of 'iterative development'. This
> means that the development process is divided into smaller sub-projects
> (or iterations) in which *all* the phases of analysis, design and
> implementation are present. This is what experienced software
> engineers recommend as the 'best' approach to software development. What
> you are describing is essentially 'waterfall development', where we first
> sit around doing analysis, then we do design, and *then*, when we've
> mapped out every little detail and thought about every little
> complication, we hand it over to the programmers to code. This doesn't
> work very well (at least not for large projects) as per the famous axiom
> of battle plans never surviving for more than a few moments into the
> battle.

Actually it all depends. Waterfall works very well if the domain is
wellknown, or if the schedule is tight (it might not work, but it's the only
way to go).  I don't think waterfall works well when it comes to endproducts
that are going to be used interactivly, but then again it is generally the
strategy used by game companies I think. (Followed by an iterative balancing
cycle).  MUDs have a longer lifecycle so straight waterfall may not be
appropriate. Anyway, waterfall, iterative etc are just FORMAL models. They
don't describe what actually happens.  There is usually a little bit of
everything, it is still valid to use the terms when one discuss the process
though. Just like bottom-up vs top-down.

Anyway, I believe evolutionary/participatory/usercentered were the buzzwords
of the 90's... I've never seen anyone argue that one should skip preanalysis
and avoid defining goals etc.

> design. I am merely saying that it is *not* practical to try to anticipate
> every little problem we might encounter.

Well, it is practical to actually find the major problems instead of jumping
on the first one which looks cool and which is so remote to the final system
that there are no strong opinions about it.  If you avoid discussing the
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.  Bring 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).

> The best approach is to find a
> middle way between these two alternatives and use iterative development. A
> layered system like DevMUD should lend itself rather nicely to this
> method.

DevMUD as discussed isn't layered. Layered means one layer is dependant on
the one below.  Meaning: lower layers are more general, more lowlevel, more
reusable. Higher levels are closer to the domain.  "Plugins" is not a
typical mechanism for implementing layers. (inheritance is).  It could be
done of course, anything that can simulate a turing machine can do
everything. Simulating a turing machine is easy, but not terribly efficient.

> 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 design
> and thinking before you code -- I've been in the situation of not having
> done that and being stuck with the results.

OO as a methodology generally means you have (assume) a domain.  OO is
useless without something to model.  At least by the scandinavian school
(which I assume you cherish?). Americans tends to think in terms of abstract
datatypes, which I don't think OO, as developed, is entirely suitable for.
(other more symbolic approaches look more promising)
 
> 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! Therefore,
> we have quite different design goals than a fully fledged MUD. Our mission
> (at least at this point, other things will follow later) is to make sure
> that we create a powerful-enough server platform to allow for just about
> any feature developers want to add.

Oaahhhhh :'(  You started so nicely with "OUR MISSION IS", sounded like a
vision coming, but then you followed up with "everything" which basically
means "nothing". :(

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.


On the conceptual decisions made:

- Uhm.... unspecified eventmodel?


On the technical decisions "made":

- DevMUD will have dynamic loadable modules because it is cool (and because
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 device
drivers, plug'n'play and that makes it a good idea)

- DevMUD will have a Virtual Machinelanguage because it is cool (everybody
does it)

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

- DevMUD will use 16 bit chars because it is cool (it is an international
effort as well)


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


> Of course, it is certainly useful to try to view DevMUD from the context
> of different game types

It should be mandatory. (but a lot of work)

Anyone who has tried to develop a framework to be used by others (I have)
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 :-)

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