[MUD-Dev] Re: DevMUD Objectives?

[Thandor]

On Sat, Oct 31, 1998 at 01:04:50AM -0500, Hal Black wrote:
>   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?

Better diku? *laugh* Nothing could be further from the truth. The only reason
I brought up diku was because I believe that although it is technologically
inferior to many mud systems out there, it is still a great system for one
reason - simplicity. Yes, I understand that making a more capable system is
obviously going to mean that it's going to be more complex. But I'd rather it
not get uneccisarily complex, just because it can be made complex. I think
sometimes settling for something that's a little slower, or that isn't
infinitely flexible is a good thing if that leads to a reduction in
complexity. I'm not saying make it hello world style program simpl,e I'm
saying that I think there is a need for balance.

What do I want from DevMUD? Well, I'd like to hope I can contribute something
to the project, even if it is just questioning why things are being done the
way they are, or some "grunt" coding work. I also think that when finished it
may be a suitable platform for the mud game (as opposed to server) design I'm
working on. So yes, I want DevMUD to suceed, because it saves me from having
to write a server from scratch that will support my game. I'll save the list
the agony of reading through a multi-page waffle of what I envisage my mud as
being like, but suffice to say I have ideas that as far as I nkow haven't been
done before and wont work well with any existing mud system that I can think
of.

> 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!)

OK, maybe it's my personal bias of hating black boxes, and always wanting to
know what is inside that is influencing my opinion. My point is it's useless
to be able to look in side if what is inside is giberish to you. So maybe I'm
advocating go as complex as you like as long as you document it well enough
that everyone can understand. I guess I just don't have much confidence in the
documentation being there - time will tell.

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

*nod* I agree with all this, I do want the framework to be flexible enough so
that someone can do a room-based mud or not do a room-based mud depending on
what they feel will work best for them. I'm not saying we should put
overly restrictive ideas on how the world works like diku does - I don't want
to be stuck with a pulse system (though I do think it should be an option),
likewise with a room-based system, heavy PC/NPC distinction, levels, classes,
etc. All those are pretty central to diku, and stuff that could be changed,
but it's a huge task. I don't want those restrictions either.

In no way, shape or form do I think diku is a good model for DevMUD. I do,
however, think that diku's simplicity has big a big factor in it's enourmous
popularity, and that if the goal is to make something that is useful to a
large number of people, then the simplicity needs to be there.

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

You're not the only dreamer, I'm sure. I don't want to have to code my areas.
Nor do I want to have to make them in any sort of editor, online or otherwise.
My vision is to be able to have semi-randomly generated areas, which integrate
seamlessly with the hand generated areas that I might write, and are
constantly "evolving"/being re-randomised, with their evolution influenced by
player actions, and ongoing subplots within the deeper mud story line. I also
want a system where I wont have to keep the actual areas, only a limited
amount of state from which I can recreate them through the random process,
hence allowing for a huge world without the problems associated with
memory/storage required for it. Since this is rather different to the way muds
traditionally handle areas, I'm not keen on being locked into one view either.
But I'm not advocating locking people in anyway, merely saying that if you
make something so infinitely generic that anything is possible, you're setting
yourself up to fail.

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

So long as bandwidth remains limited, and latency stays above zero, I don't
think there can be a one size fits all network module. At least not what I
consider to be defined as a network module. This is an example of what I'm
talking about - if practical limitations mean that the implementation of one
module inhibits the creation of a certain class of games, is it worth making
allowances for those types of games in other modules? In an ideal world I'd
say yes, but in our non ideal world I question whether it's worth the trouble.

Once again, I have no intention of writing or using a diku module. As I said
in another post - if I wanted a diku I'd build from a diku. I was simply
complementing diku not on it's gameplay but in it's simplicity of
implementation. I'm not a fan of the simplicity of gameplay that this causes
in certain situations. 

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

Sorry if I come off as questioning the ability of the people involved to come
up with something useful, but my natural mode of thinking is as a skeptic. Add
to that the fact that I often find myself addopting the devil's advocate
position almost without intending to, and I guess I can sound like whatever is
put up I'm not happy with. However I think anything this abitious needs people
like that.

Yeah, I guess at some level I do think it will work though - I wouldn't be
spending my time writing email to the list if I didn't.

- Shane King.