[MUD-Dev] Forks or Frameworks?

[Tess Snider]

On Mon, 18 Dec 2000, Gavin Doughtie wrote:

> Are there projects afoot to provide a generic framework that can be
> revised independently of the content? I'm thinking specifically of a
> "D-Free" shared engine. The Worldforge project is the only sizeable
> one I've seen so far.
> 
> Is it even advisable to attempt architecting MUDs around the
> traditional IT separation of data store/app logic?

The framework underlying most MUDs is actually *very* generic, and
most of them have an idea of a database or filesystem for storing the
actual world data.  Now, while a MUD is being built, there is a
considerable amount of world-specific code which is generated by the
builders.  In a Diku, this takes the form of actual game source code
that has to be compiled.  In the case of an LP-MUD or DGD, this takes
the form of LPC files. In a MOO, MUSH, or MUCK, this takes the form of
softcode, which resides in the database.  Ultimately, however, you
could, for example, take a MUSH server which was running a Pern world
ten minutes ago, and run a Bladerunner world on it, just by loading a
different database.

Now, WorldForge *is* doing something which was not done in these MUDs,
though that's mostly because they are text MUDs, and WorldForge is
targeting graphical games.  That's *media* agnosticism.  The server's
internal representation of the world is divorced from any notion of
how the client represents it.  Because of this, you can hook up any
kind of client that the artists have provided media for.  You could,
for example, play a game with a first-person 3D client, while your
friend on the computer next to you is playing in sprite-based
isometric, if the artists for the game provide both kinds of media.
In fact, if you use one of the kinds of media that have been provided
for your favourite world, you can even homebrew your own custom
client.

This requires some interesting design discipline for the team:

	1.) The client can't be trusted for anything, ever, period.

	2.) You need to think very carefully about how much
	information you are sending to the client, and how this would
	affect the gameplay if a user is able to view the information.
	You must send *some* extra information to your client, for
	efficiency and clean client-side prediction, but assume from
	the get-go that some sampling of your players will always be
	capable of seeing everything you send to their clients.
	Because of this, things like darkness should be used for
	atmosphere -- not as a challenge to your players.

	3.) Macroing should be a non-issue in your game.  Some of you
	may have read the "I want to bake bread" letter circulating on
	the game boards.  The author said that the number of items you
	can create with a trade skill in a given time period should
	depend on the character's skill, and not on how fast the
	player clicks his mouse.  That's a valid point.  If any aspect
	of your game is so tedious that people want to macro it, you
	need to *seriously* rethink it.

	4.) If people want to write ridiculously complex scripts for
	their characters, well hell, more power to them.  Be ready for
	it.

Anyway, I've totally gotten onto another subject, at this point, so
I'll shut up, now. :)

Tess

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev