<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: MURKLE: Wot it is -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Thu, 14 May 1998 13:13:32 -0700 -->
<!--X-Message-Id: 199805142013.NAA06349#under,engr.sgi.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199805090054.RAA07915#under,engr.sgi.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: MURKLE: Wot it is</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:claw#under,engr.sgi.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00584.html">Previous</a>
| <a href="msg00588.html">Next</a>
]
Thread:
[ <a href="msg00479.html">Previous</a>
| <a href="msg00588.html">Next</a>
]
Index:
[ <A HREF="author.html#00587">Author</A>
| <A HREF="#00587">Date</A>
| <A HREF="thread.html#00587">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: MURKLE: Wot it is</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: MURKLE: Wot it is </LI>
<LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI>
<LI><em>Date</em>: Thu, 14 May 1998 13:13:15 -0700</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: "Petidomo List Agent -- Kanga.Nu version" <<A HREF="mailto:petidomo#kanga,nu">petidomo#kanga,nu</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On Fri, 08 May 1998 17:54:27 -0700
J C Lawrence<claw#under,engr.sgi.com> wrote:
<<Hi me!>>
> A preface on MUD game design:
> The largest failure of MUDs is that they have generally never, and
> never stably, been able to assemble large simultaneous populations.
> What is "large" in this context? I would start at 500 as still
> being on the verges of small.
> Raph, Sellers: Can you provide context from UOL and M59 here?
I would be interested in a genetic comparison here in particular.
What is the minimum population required to supply sufficient genetic
diversity to be considered "viable"? Yes, I know that this is highly
dependant on the range of genetic diversity in the subject species, as
well as its rate of internal divergence and other factors, however the
same principle seems to underlie.
> Project name: MURKLE
Now to expand on my earlier, tired-outta-my-gourd exposition.
The world is, of course, persistant. There are no resets. There are
no re-pops. There are no little figures in white coats putting things
back the way they were (cf MirrorWorld).
For those of you that recall the White Oak Tree, Cheese Factory,
Fortress Fract, Blue Grass Path, Castle Krak, Mud Village, Beer
stream, the Human Powered Catapult, the Elephant Driven Elevator,
Mobius Row, and other areas I've done for other games previously, yes,
they form the initial core of the game world. The White Oak Tree in
particular in threatening to assume truly enourmous proportions. The
blue grass path of course is always large, and has become dynamic.
> What does it mean to create a reality? Free user programming where
> users can create and program objects, castles, worlds, animals,
> magic etc, but all limited by base physical model restrictions of
> the game world. The server and the base game world working together
> as *system* preserves data security and logical consistency (of a
> very perverse form) of the resultant presented game world.
Note also that the presence of free user programming does not restrict
the games or worlds offered from being goal based. This is
accomplished by using an inter-object security system based on
CoolMUD. In essence, every object and method individually determines
(well, there is inheritance) what other objects it will accept and
refuse messages from. A new user programmed objects don't have the
appropriate signatures, they can't interact with more ratified objects
to create effects bypassing problem solutions.
eg You can't quickly program up a super-duper nega-whop sword that
delivers 50,000hp damage per idle swing to get past the mongo red
dragon. Well, actually you could -- the sword would just have
absolutely no effect on the dragon, or not any more than a similarly
sized lump of benign wood would.
> Yes, the players are truly gods of near infinitely varied and
> ranging power -- only bound by chains and restrictions which even
> they cannot shift.
See?
> Other interesting aspects of the game world:
Currently slated is to attempt a graphical interface. I'm not a
graphics person, either from the artistry or the DP sides. Dunno how
I'm going to approach this. My preference would be for a very very
cheap dynamic rendering system. (AlphaWorlds? Are they still a going
proposition?)
First preference: 1st person, single frame 360 degree spherical view
(possible cropping at each pole). See the mast head graphics for most
of the MUD-Dev archives for an idea of what it would look like. Yes,
distortion and the curious catenaries of straight lines will be
significant. I don't see this as an interface problem per se (tho I
expect many reports of faux motion sickness), but a strength of the
the interface form. You are not only a stranger in a strange land,
your mental/visual models are also strange and being challenged
__without__ requiring you to adopt new or different physical or
logical models. Yes, everything looks different to an Anableps (a
fish with four eyes, two for above the water's surface, and two for
under (split iris actually)), just as everything looks different to a
fly with its compound eyes. I like this concept, especially as it
doesn't affect anything but the visual translation model.
Second preference: overhead isometric variation. The dynamic
transparency of blocking overhead object is a standard and forgivable
approach (eg as you walk into the building the roof and upper stories
disappear to show you on the ground floor). The business of being
able to see through/past opaque objects because of the overhead view
is annoying and unpleasant -- I'd much prefer a radar/Moria-style
overhead view where only what the character can directly see is show
at full res, with what he *has* seen is shown sans-colour and without
state updates. This view also handles layers very badly (the paper is
taped to the underside of the desk) I'd *really* also like to avoid a
tile based game (they don't handle convex hulls well for instance --
and I *really* want to handle reasonably complex surface forms (yes,
incl klein bottles and your standard Escher art re-mocks)). This is
going to be a heavily puzzle-oriented and allusory game world. Visual
puzzles and tricks are fun. I want them.
Third preference: 3rd person over the shoulder cam. Nothing
terribly unusual here, tho its my least favourite. Main complaints
against it are that I find the site of the character waving things
about in front of his face, and thus my view (cf M59) expressly
irritating. 1st person view is merely a variation on this irritation,
especially given the problems of peripheral view and awareness as
discussed earlier (stand in place and spin like a top?).
<shrug>
> Body stealing, multi-body characters: This has been discussed here
> at length, so I won't re-cap much. Briefly, a single character can
> control multiple bodies ("character" is almost equal to "soul", but
> without much of the connotative baggage). Some bodies are swarm
> bodies (like a swarm of bees). Additionally characters can steal
> bodies from mobiles and other characters, adding to the total set of
> bodies controlled by that character and gaining the advantages
> imbued in that body.
I expect to have a lot of fun with swarm bodies. I also expect
(demand?) that they will also be the most difficult to play, as well
as the most difficult to play against. To limit the effect of
bandwidth swamping from the multiple viewpoints (visual and
otherwise), a standard handling already is:
1) multiple component bodies in proximity form one meta-body with a
single viewpoint at its geometric center and centralised IO
processing.
2) Each individual component body has a very limited angle of view
(tunnel vision). Only assemblies of many bodies can cover broad
sweeps of vision.
It is not expected that characters will routinely run more than one
body. It will be physically difficult from an interface standpoint,
as well as taxing to the character (schizophrenia?).
> High magic: The world runs on a zero-sum particle based economy,
> where magic (mana) is one of the particle types, and (loosely)
> operates on the faucet-drain principle. Any creation results in two
> products, each identical except for sign. Such matching pairs are
> mutually attractive and self-destruct when they do. The cost of
> creation is proportional to the square of the current resources'
> deviation from zero.
> Additionally there are mana particle faucets and drains in the
> world, with a careful mechanical model applied (like particles of
> opposite sign attract inversely proportional to the square of the
> separating distance, like particles of similar sig repell when at
> rest, but attract proportional the square of their absolute velocity
> and the distance separating. As such mana particles tend to move in
> packs and waves, and at speed).
> l
Bubba stands on the ley line, waiting patiently.
Godzilla, thirty stories tall and covered with teeth, claws, and
the remnants of past munchies charges down the valley towards you.
The air starts to feel sharp, almost charged, not electric but
potential in some odd twisting way. Electric orange sparks start
to dance across Bubba's features; you feel your own hair rise and
crackle. Mana is coming, and lots of it. WHOOSH! The ground
suddenly looks like burnt toast and rushes towards you like a
bullet! The mana is here! Yow!
Bubba twitches one finger. A fireball the size of Manhattan engulfs
Godzilla. Sizzle!
Godzilla is cooked.
Lunch is served.
Life is good.
Timing is everything.
> Outside of this the magic system (at the user presentation
> level) attempts to be an ambitious mutation of Mage2Mage with a bit
> of Bartle's Waving Hands thrown in (Mage2Mage to add the aggregate
> and scripting ability, WavingHands for the algebra, with the
> Mage2Mage resultant spell names being the main public face).
I just threw out my last design. Not orthogonal and full of holes --
mostly possible cheats and short-circuits which allowed large effects
to be created without due expense.
I'm now thinking of largely dropping Waving Hands. I love the idea,
but don't think it meshes well as an algebra with M2M. The main
problem is that much of the value of Waving Hands is based on the
unprediction of what the possible expansions of the current finger
stack state of your opponent is (read the doc for sample cases). That
particular aspect has no value when wedded with M2M. M2M offers
crafted magic. Waving Hands offers insta-magic. M2M offers scripting
and control. Waving hands offers accumulated package delivery. Its
shell scripts vs tarballs.
> Object destruction: Objects (generally, and especially magical
> objects) consume resources during their life. If they are unable to
> satisfy their hungers they self-destruct.
<grumble> Raph raised some very valid playability points associated
with using object wear as a darin on the economy. For one it tends to
bug the crap out of players. <grumble> Its about as popular as
"rent" on DIKUs, and i can see why. Players like to be able to keep
what they gain. THey also come up with all sorts of interesting
tricks to manage that (holder character etc).
Gonna have to think about this. I don't want to lose dynamic object
decay, especially how it relates to magical items and the mana supply
(see UggUgg's fight). I probably will lose almost all of the normal
wear-and-tear object decay stuff however.
> Private namespaces: There are no global namespaces. There is no
> WHO list or command. There is no seeing other's names floating
> above their heads when first meeting them. Names are assigned by
> the individual character, private to that characters, and bear no
> relation to the preferred or requested name of the object or
> character in question.
There are obvious problems with social contexts. By default you know
nobody, can't recognise anybody, _and_ can't distinguish between other
player characters and NPC. Its gets worse in that any particular body
in the game may be an NPC one instant, controlled by another player
the next, and back to an NCP or a different player character the
third.
Its hoped that the presence of global channel equivalents and the more
generic and fluid communication abilities of the spirit world (think
unlimited tells, pages, whispers, etc) will offer and end route around
some of the social context problems.
SPAM and other noise deluges in the spirit world is part of the idea.
A hubbub of conflicting thought impulses. However background noise
will decrease with seperation, with seperation accomlished by
selective grouping (I wanna be with XXX), and the game dynamically
moves character locations in attempt to satisfy the requested affinity
rules (yes, I realise the order of this problem, and why it is
inherently non-solvable).
> Universe seperation: The game-world is fractured into three:
> physical, spiritual, and character. All exist in parallel, and any
> character has a presence in all simultaneously. While the character
> level is strictly for OOC concerns (it has no relevance to the other
> universes, only to the human player), attacks, conversations,
> coordination, etc can occur seperately or in concert across the
> physical or spiritual worlds.
Stats similarly divide across the three. Physical stats are tied to
their bodies, and as such have no place in the other worlds. However,
extended use of physically accomplished bodies build "expectation"
stats in the spirit side which accellerates later body aquisitions to
also be similarly accomplished (eg strong).
Additionally many stats reflect across the universe divides (typically
in the physical->spiritual->character order, but occassionally in the
other) in echo forms. This is something of a reputation/notoriety
model, except that the stats are not revealed to other players, but
are used to cause reflective effects. Thus, for instance, a
successfull mass PK'er will gain various violence related echo-stats
defined on his character. These in turn will cause the "finer"
characteristics of any new bodies he acquires to decay rapidly as the
body re-morphs to a more physical and brutish form. They will also
affect his probability fields encouraging the physical game world to
respond violently to him.
The idea is that the stats will tend to diffuse across the character's
realm, almost osmosis-like, attempting to make all instances of the
characters presence similar.
eg Bubba is a particularly loutish and crude fellow, but manages to
gain control of a "fine" elven body. Over time that elven body will
become increasingly coarse, even troll-like, as Bubba's stats begin to
show thru.
> Combat: Yes, I have perma-death. Combat is intended to be fatal,
> messy, and highly risky even to the experts. The underdog is
> expected to win or do serious damage an appreciable percentage of
> the time. Currently I have no working satisfactory design for the
> combat model. Whatever combat model I end up with must be able to
> commonly support fights ala:
Base rule:
Death only occurs when the character has no more bodies, either a
controlling or partial interest.
Passive death caused by the world (eg fell down a cliff and died,
walked along and a tree fell on you) is not __always__ permanently
fatal. Death caused by other players or NPCs (eg combat), or overt
acts of the game world is __usually__ permanent. The rules will be
deliberately foggy and vague. Its not intended to be fair. It is
intended to be capricious, but with known tendencies.
> Unstable feedback systems: I'm a fan of unstable positive feedback
> systems for internal game systems and ecology simulators. I'm also
> conviced that very complex and interesting systems can be built from
> the interactions between very simple and internally unstable
> systems. I use this model a lot. The result is an often chaotic
> and volatile world. Good examples are the Trash Collectors and the
> Orc Breeder/Fighter/Nobles:
Note: In essence these are micro-economies. Often they are
faucet-drain style (eg Orcs above), but I'm currently attempting to
think of player-incitied forms.
> Note: The above TC model is far too unstable. The currently
> implemented version is considerably moderated.
Translation: It took about 30 minutes for the first TC population
explosion to occur. 20 minutes later they all died of starvation.
Within a couple days the entire world was knee deep in TC spores.
TC's need an effective predator which has its own cyclic population
behaviour (needs to be dependant on TC population, but enough
out-of-step to prevent steady-states from occuring).
> Rank system: This is mostly a variation of the influence trees
> concept, but with my Rank Points idea mixed in:
I don't intend to create political systems or much anything else
here. Just resources that others can do with what they want.
--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
--
MUD-Dev: Advancing an unrealised future.
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00606" HREF="msg00606.html">[MUD-Dev] Re: MURKLE: Wot it is</A></strong>
<ul compact><li><em>From:</em> Mike Sellers <mike#bignetwork,com></li></ul>
<li><strong><A NAME="00588" HREF="msg00588.html">[MUD-Dev] Re: MURKLE: Wot it is</A></strong>
<ul compact><li><em>From:</em> Raph Koster <rkoster#origin,ea.com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00479" HREF="msg00479.html">[MUD-Dev] MURKLE: Wot it is</A></STRONG>
<UL><LI><EM>From:</EM> J C Lawrence <claw#under,engr.sgi.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00584.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00588.html">[MUD-Dev] Re: MURKLE: Wot it is</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00479.html">[MUD-Dev] MURKLE: Wot it is</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00588.html">[MUD-Dev] Re: MURKLE: Wot it is</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00587"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00587"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: CGDC, a summary</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<LI><strong><A NAME="00892" HREF="msg00892.html">[MUD-Dev] Re: CGDC, a summary</A></strong>,
Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Sat 06 Jun 1998, 01:29 GMT
</LI>
</ul>
<LI><strong><A NAME="00599" HREF="msg00599.html">[MUD-Dev] Re: CGDC, a summary</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Fri 15 May 1998, 03:27 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00485" HREF="msg00485.html">[MUD-Dev] META: Search features of the MUD-Dev archive</A></strong>,
J C Lawrence <a href="mailto:claw#greek,kanga.nu">claw#greek,kanga.nu</a>, Sun 10 May 1998, 05:48 GMT
<LI><strong><A NAME="00479" HREF="msg00479.html">[MUD-Dev] MURKLE: Wot it is</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Sat 09 May 1998, 00:56 GMT
<UL>
<LI><strong><A NAME="00587" HREF="msg00587.html">[MUD-Dev] Re: MURKLE: Wot it is</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 14 May 1998, 20:13 GMT
<UL>
<LI><strong><A NAME="00588" HREF="msg00588.html">[MUD-Dev] Re: MURKLE: Wot it is</A></strong>,
Raph Koster <a href="mailto:rkoster#origin,ea.com">rkoster#origin,ea.com</a>, Thu 14 May 1998, 22:35 GMT
<UL>
<LI><strong><A NAME="00621" HREF="msg00621.html">[MUD-Dev] Re: MURKLE: Wot it is</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Sat 16 May 1998, 01:48 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00606" HREF="msg00606.html">[MUD-Dev] Re: MURKLE: Wot it is</A></strong>,
Mike Sellers <a href="mailto:mike#bignetwork,com">mike#bignetwork,com</a>, Fri 15 May 1998, 15:28 GMT
<UL>
<LI><strong><A NAME="00635" HREF="msg00635.html">[MUD-Dev] Re: MURKLE: Wot it is</A></strong>,
Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Sat 16 May 1998, 21:07 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
