[MUD-Dev] Tilting at the SimWindmill - was UO
Jon A. Lambert
jlsysinc at ix.netcom.com
Thu Jul 31 12:44:48 CEST 1997
> From: Koster, Raph <rkoster at origin.ea.com>
> Subject: [MUD-Dev] Graphic MUDS/Ultima Online
>
----snip----
>
> You've missed two very important ones that are intrinsic to UO as a
> world, and to my mind are intrinsic to future mud development into
> virtual realities (which is, btw, where I think this genre is headed
> in the future).
>
> UO has an economic system that goes from raw materials to finished
> goods, and players can make any step of it.
>
> UO also has an ecological system that handles creature repopulation,
> behaviors, etc.
>
> Both of these are intrinsic to the game, far more so than combat or
> spells or guilds. They are the simulation layer under that, and
> despite repeated calls for "mud evolution" not many take up the
> gauntlet to work on this sort of thing further. Yet I remain convinced
> that adding a simulation layer to muds is where the genre needs to
> go.
>
------
I strongly agree with this.
Actually much of the technical traffic on this list has been indirectly
addressing these issues. Implementation and design issues relating to
events, messaging, multi-tasking, object storage and retrieval,
transaction rollback and recovery, etc. are not just "wouldn't that be
technically slick" ideas. They are attempts to address Concurrency and
Persistence (at least that's my take). Objects in the "real" world are
concurrent and persistent, this is rarely true on most muds. I also
believe that if these complexities are kept within the server and are
implicit not explicit features of a mud building language, one will be
left with an ideal tool to build the simulation layer. Basically, I hope
my "end product" of my server design to be, not a mud, but a simulation
building tool.
Much of the discussion here has also revolved around realism, mechanics
and/or representing things to the player in an immersive believable
manner. I think this falls into the general category of observed behavior.
There is also a wide range of opinion as to how much of this is really
important, especially if it is not actually directly observable. I
believe that concentration on just the surface aspects of behavior are
primarily what muds "do now".
Determining the abstract processes that underlie this observed behavior
(answering the why's) and building simple machines to represent aspects
of this behavior will result in richer and more flexible systems. I
think Nathan has attempted to hit this area rather directly with his
attempts to implement the "basic laws of physics" and build up from that.
I see Matt and some others drilling down from the top with Virtual
Alchemy and a whole host of other observable aspects.
There is this area somewhere in the middle of player observable behavior
and the basic laws of objects . I think you hit the nail on the head.
It's a land full of SimPeeps, SimEcology, SimGenetics, SimAlchemy,
SimEconomics, SimCritters, SimMagic, SimPolitics and many others. I
think many of the people on this list are indeed tilting at same windmill
but from different angles and perspectives whether they realize it or not.
Thanks Raph for an altogether excellent and well-thought out post. =)
JL
A side note: Thanks for pointing out that special feature of Dikus.
and their derivatives. Templates. I have been unable to come up with
satisfactory terminology to describe this concept of building worlds.
Lay this concept on top of a good architecture and a supporting language
and you'll increase the speed/ease of world building a hundred-fold and
at the same time make it accessible to the non-programmer. ID's Doom
and Quake are good examples of this at work. Has anyone noted the
thousands, if not tens of thousands of worlds built using these tools?
Imagine if the sets of objects and the sets of blackboxed systems were
richer and more properties accessible to the non-programmer. Couple these
tools to a good OO mud language and you've got something big IMO.
MakeZonesFast and Spam are the types of building tools I refer to. The
are very similar to DoomEdit, QuakeEdit, and the host of Doom editors
if you make the leap that text:=graphics.
More information about the mud-dev-archive
mailing list