[MUD-Dev] Re: DevMUD Objectives?

[Hal Black]

On Fri, Oct 30, 1998 at 07:47:01PM +1100, Thandor wrote:

> Which brings me to the whole modularity and flexibility concept. Some people
> have been advocating a very pure sort of approach, with very generic modules.
> While I agree in theory that is a good thing, but in practice I think it's
> counter productive to be too generic. At least, don't go to the extent that
> some people have been talking about - I don't think you should be able to use
> a module from DevMUD in a thoroughly unrelated system. A mud has some
> specialised requirements, and I think it would be better off keeping those in
> mind when designing the modules, rather than just making generic
> parser/telnet/bootstrap/config/etc modules and putting all the mud specific
> burdon in the game module(s). Yes, it's probably not as pure an approach, but
> I think it would keep things simpler and more usable in the context we expect
> them to be used - running a mud.

  The problem here is many of us have different views of what constitutes a
mud.  For instance, avid MUSH players don't have the same taste in muds as avid
Diku players, yet most of us agree that they are both muds.  We had a
discussion earlier about how more online games are like traditional MUDS in
many ways.
  Forgive me if I misunderstand, but your goal for DevMUD seems like it is "to
make a better Diku".  (I even think some list members - Holly? - have added LPC
programming to a Diku base) I think this is a good goal for the project; I
think a straightforward game like Diku could benefit from some of the features
proposed for DevMUD.  However, for what I see in DevMUD, it is not this at all.
What if I want to make something that's not at all like a traditional MUD, Diku
style or other?  What if I want to make a huge multiplayer version of the game
Tradewars, Planetbusters, or even Pyroto Mountain from the days of BBS's?  What
if I want to make something styled like Ultima Online?  What if I want to make
a realtime Civilization-style game?  How about one like Sim-City?  Or
Syndicate?  Populous?  Lemmings?  Or even something entirely different?

  Now, back to reality, and away from wild ideas...  What am *I* planning to
do with DevMUD???  A mud that I have in mind is quite similar in user interface
to LP or Diku.  But, I want the physics behind the scenes to be totally 
different.  I, Hal Black, am interested in neither the innards of the socket
interface, nor the guts of the telnet protocol implementation, nor garbage
collection yada yada, nor the specifics of persistent database storage.  I just
want to make a game, and I want it to run fast enough so that I can do
interesting things with it witout driving the machine to its knees (if it had
joints at all).  Because I want some of those features, I am going reach into
the DevMUD toolbox and grab out what I want and leave the rest.  Hmm, here's
a telnet module, yes...  Graphical client server module, no..  Ooh, this
database storage thing looks useful, yes...  DevMUD aims to empower
game designers by delivering black-box modules they can use without
understanding the details of what's inside.  (but they can look in if they
want!)
  I think a lot of the DevMUD design is based on allowing design of *Engines*
and *Universes* rather than just *Scenarios* or *Environments*.  I would say
that most of the modifications done to Diku of are the latter variety.  If I
code a new guild into diku, or add some mob AI, I would call that mostly a
change in scenario.  But say I took all the rooms out of Diku, changed the
world to a 3-d coordinate space, and gave everyone 3 floating point values to
represent where they were in the universe.  Then in that space I put some solid
objects and called them walls.  This would certainly be different than any Diku
I've ever come across, in fact, it wouldn't be much like Diku at all, even if
it was based on the Diku codebase.  Say I had a good reason for making such a
change.  I've basically taken something that was well suited to all of Diku's
great features (OLC, etc) and made them useless by modifying the Universe
model.  So why start from Diku in the first place?  I hope DevMUD will be a
better place to start for radically new designs of Engines and Universes. 

  Going back to the idea of the online language...  The game language module
doesn't have to be techincal.  I think code is a horrible way of making rooms.
The Diku authors agree with me, and then someone came along and improved it all
to make OLC.  Maybe I want to take it a step further.  Maybe I want to have not
a text interface at all for world-builders, but instead a SimCity2000-style
interface, where you paint various regions with roads or forests or residences
as you like.  To accomplish this, hopefully I could write a paint program
interface module to map my world to the mud geography module.  And what if I
want to have a client for my builders to draw the geography without sending
all that graphical data over the network while they draw?  Simple, I require
the client to work independently of the server until the "send" button is
pressed.  Then the client-server module would take over, uploading the code to
the server and integrating it into the world, without worrying about all the
details of impelementing the network or client-server protocol.
  Within that painted world, perhaps some areas would require some special logic
because of the interesting things going on there.  So then I'd have the
online coding module to insert bits of code to go off at various places in
the mud geography.
  And the list goes on...  Maybe I'm a dreamer, but I have great goals for
what a project like DevMUD could realize by virtue of not being tied to one
platform or style.

> again keep things simpler, especially given that most muds will probably only
> want one or the other. I guess this comes back to flexibility - making DevMUD
> all encompasing sounds great, but is that an achievable or even desirable
> goal?

I think it is certainly achievable.  Any network game has a network module.
It may not be an explicit *module* like DevMUD aims to have, but it is one
nonetheless.  It may even be tied in tightly with the game code, who knows?
What it seems to me what the DevMUD project aims for is to provide some of the
common building blocks that all multiplayer network games/environments use
(network, database) in a manner that specific modules (DevDiku, DevLPC, DevMOO,
DevSyndicate, DevWhatHaveYou) can plug into and use, and the module interface
itself so that things fit together.  Every network game has a network module,
why not have a set of games which use the same network module?  Certainly a
Quake-stle game will have a different network module than a telnet game (telnet
is TCP-only, and Quake uses UDP and TCP) but at least there will be some
common way to plug them in.
  I've also heard some talk of modules less common and closer to actual
MUDs, like a MUD Geography Data Structure package.  It would have efficient
implementations of MUD Geography models that you or I could use if we want.
Perhaps one module you might like would be a (Swedish?) Diku extender, to add
programming to Diku muds without taking away all the good features that give it
popularity through accessibility.

> Maybe I'm missing something, but DevMUD is sounding more like a cool geektoy
> filled with as many neat coding tricks as possible than something that anyone
> is going to be able to use. The number of times people on this list who seem
> to be very knowledgable when it comes to mud design have replied that they've
> been unable to understand something, even at the very sketchy design level
> being worked on at the moment sounds like a warning to me.

  There is certainly a lot of Voodoo and Black Magic in discussion going on
about the interface stuff going about, but like you said before, it's a tough
problem that some don't think will be achievable.  Perhaps some Black Magic is
in order.  It seems to be an inevitable part of design discussions - especially
for projects with lofty goals and enthusiastic developers - for the members to
present all known means of design and implementation, no matter how arcane, in
the event that some gold nugget of buzzword alchemy manifests itself.  (one for
Koster's Laws?)
  I have faith that when the dust settles, the interface design will be
approachable and documented.  Hopefully, some truly useful and easy-to-use
modules will follow.  It's what we make of it - only time will tell.