[MUD-Dev] Next gen MUD wishlist

[Bryce Harrington]

On Sat, 19 Feb 2000, Bruce wrote:
> One problem that I have is that many people equate the above to being a
> server under the GPL.  Since I'm approaching this with a highly
> commercial bent (and plan to announce our open source project
> real-soon-now), that really doesn't work well for me.  I much prefer a
> highly modular system with well defined APIs, licensed under either the
> LPGL or the Mozilla Public License (with the appropriate modifications
> to the boilerplate).

Okay, so, say the underlying libraries (including especially the network
layer) should be LGPL'd, allowing the remainder to be licensed as
desired by the implementors of the server itself?  I admit I am indeed
thinking of GPL, but no reason there couldnt be multiple implementations
of the design, some of which may be GPL, others something else.  So I
agree with you: If the important modules are sharable, that should be
enough.

While I was involved with the MPL development I really prefer the LGPL;
it was IMHO better thought out.  The MPL was done in kind of a rush...

> > Server
> >    * Should support on the order of 100-500 simultaneous players
> >      (Is this a realistic number?)
> 
> This is easily doable with any of a number of servers around today.  My
> goal is to scale well past that.  My base requirements are to be able to
> support at least 5000 users in a single world.  I'd be happy to support
> ten times that.

*Nod* Okay...  I guess I'm thinking that with the coordinate-based
physics the bandwidth per connection could be higher.  

Would it be better to specify this in terms of bandwidth per person?
How many players should a server on a T1 be able to serve?  On a OC3?
A cablemodem?  A 56k modem?

> >    * Should permit scripting in easy to learn, existing language
> 
> There are some other options here.  Customization (not extension) need
> not involve scripting.  Rules-based authoring systems can provide for
> customization in an even easier way than scripting.

Ah, good point.  Mind elaborating?

> >    * (Desired) should allow use of any arbitrary scripting language(?)
> 
> I'd rather have one well done, consistent system.  I want a single clean
> object model that fits the requirements of my system, not a hodge-podge
> that was jury-rigged to make it work with any given scripting language. 
> But, I might be odd in that I don't mind learning new languages and new
> object models to get a job done.

Hmm, okay.  I specified this mostly because I know everyone has their
own favorite scripting language, and that deciding on a single language
can be hard.  For instance,  I might perfer Python, but someone else
want Mercury, Guile or Perl (or worse!)

What if it was a compile-time option?  So, a given compiled instance of
a server might only support a single scripting language (or even none,
if one wishes to really squeeze out every bit of performance), but
people are still permitted the ability to choose.

> >    * Should abstract rules in a way that allow modular replacement
> >    * Should be genre-generic, and even game-generic, at the core
> >    * A stock world/rules should be provided, as a basis to work from.
> >      Further, it should include all graphics, music, and text media to
> >      characterize that world.
> 
> This shouldn't be seen as an excuse to avoid documenting the server
> though as happens all too often. :)

Ah, decidely not!  ;-)

My plan is to first assemble a fairly extensive wishlist, and then
extract it into a more proper (and complete) requirements list.  Then a
design document would be drawn up, and only then would implementation be
allowed to go forth.  Separate docs would be want to be written, but if
worse came to worse, at least there would be the design docs to fall
back on.  

I think once the design docs exist, pretty much any decent programmer
could code it up, assuming of course that the design was good and had a
solid basis in reality.  ;-)

> >    * In general, the server should be easily customizable by the admin,
> >      so that new wannabe admins can take a stock world and immediately
> >      and quickly turn it into something interesting and unique.
> 
> (A topic to avoid, but what are the odds that this will happen or that
> it will be within the capabilities of the average newbie admin?)

If suitable GUI editor tools exist (ideally, extrapolated or extended
off of the regular play clients), then customizing a world may be fairly
straightforward even to a newbie admin.  But point taken.

> >    * As much as possible, customization and editing should be doable
> >      while the game is still running.
> 
> Of course.  To do otherwise would be to ignore the fine heritage of MOO,
> Cold and LPC.
> 
> >    * Allows "building" and "inventing"
> >    * Free market, player-driven economic system
> >    * Allows for creation/optimization of sophisticated AI's
> >    * Dialectization - Modify player speech to suit the race/nationality
> >      they're playing (orcs speak orcish, etc.)
> >    * Coordinate-based rather than room-based.
> >    * Able to make large scale world changes (meteorites, massive weather
> >      changes, etc.)
> >    ? Server distribution?  Should it be possible to link several
> >      different people's servers together?
> 
> There's a lot of fun technical issues here, but what does it really add
> to a game?

I'll split up the technical requirements from the more proper wishlist
items.  (I must be getting ahead of myself) ;-)

> > Client Interface
> >    * Should support graphics (to compete with UO/EQ/etc.)
> >    * Cross platform playable
> >    * Don't forget about importance of text and text interfaces
> 
> Don't forget that the availability of a text interface doesn't excuse
> the lack of a good graphical interface for most things.  Widespread
> consumer acceptance doesn't typically involve a command line.

Ah, I was thinking more of a secondary client application that ran only
in text mode.  This could be used by people who for one reason or
another could not use the graphical one.  

> >    * Can't trust client (treat it as already hacked; it _will_ be)
> >    * Configurable dynamic music (music changes to suit the scene,
> >      and can download new tunes between play sessions as they become
> >      available)
> 
> Some of the new stuff in DirectX (some of which is still forthcoming)
> looks really useful for this type of thing.  Of course, there goes your
> portability.

Hmm, well while selection of graphical libraries and such is a design /
implementation decision, I'd hope that some of the various cross
platform graphics libs (Crystal Space, OpenGL, SDL, wxWindows, etc.)
would fit the bill.  I know some (like CS) are still developmental...

> >    * Semi-dynamic graphics:  can upload your character portrait or
> >      animation to a central server, for others to (auto?)download.
> >      (This encourages the players to generate the hardest artwork -
> >      character animations - themselves.)
> 
> If all of this is to be the 'Next generation' of MUDs, then we (the mud
> world) are largely already there.  MOO and Cold have been here at this
> level for some time, or had the capabilities of being at this level at
> the core architecture level.  They've had graphical clients.  Some of
> them have had coordinate based systems.  They've been able to handle
> 100-500 users.  That said, I've moved on from those systems for reasons
> explained in the list archives.
> 
> Isn't it time to really move on to the next generation?

Hmm, did not know that...  So you're right, we ought to shoot for a
little more aggressivity.  What would you suggest as good challenges to
undertake?

(Thanks to everyone who emailed me with suggestions privately; I'll
incorporate them and repost the wishlist tomorrow.)

--
Bryce Harrington
bryce @ neptune.net




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev