<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: Re[4]: [MUD-Dev] The grass is always greener in the other field -->
<!--X-From-R13: Oqnz Ivttvaf <nqnzNnatry.pbz> -->
<!--X-Date: Thu, 23 Dec 1999 15:44:51 -0800 -->
<!--X-Message-Id: Pine.SGI.3.96.991223115516.7852A-100000@zazu.angel.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 67.991223@io.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: Re[4]: [MUD-Dev] The grass is always greener in the other </title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:adam@angel.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="msg00778.html">Previous</a>
| <a href="msg00780.html">Next</a>
]
Thread:
[ <a href="msg00775.html">Previous</a>
| <a href="msg00786.html">Next</a>
]
Index:
[ <A HREF="author.html#00779">Author</A>
| <A HREF="#00779">Date</A>
| <A HREF="thread.html#00779">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: Re[4]: [MUD-Dev] The grass is always greener in the other field</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>: Re: Re[4]: [MUD-Dev] The grass is always greener in the other field</LI>
<LI><em>From</em>: Adam Wiggins <<A HREF="mailto:adam#angel,com">adam#angel,com</A>></LI>
<LI><em>Date</em>: Thu, 23 Dec 1999 14:24:04 -0800 (PST)</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#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 Thu, 23 Dec 1999, Travis Casey wrote:
> I think the thing that tweaks me isn't your raising UOL as an example,
> but the way in which you raise it (or, I should say, the way that it
> seems to me). It seems to me that you raise it not as a "think
> carefully about how much work you want to put into this -- it may take
> much more than you think" warning, but as a "this won't work".
I agree with this, and in reference to more than just the subject at hand.
The thing that best can be learned from prior art is just what the work/payoff
ratio of any particular method or feature is.
For example, Raph often mentions the difficulties they had with doing an
organic ecosystem vs. the traditional facet/drain. I don't take this
lesson to mean that the organic system is impossible, but rather that
it requires a huge amount of effort to get right with the result of a fairly
minimal payoff from the player point of view.
> If they're doing a one-to-one mapping of numbers to phrases, like the
> paper RPGs FUDGE and MSH (the original, not advanced MSH), then it
> wouldn't be too hard. I'm thinking more in terms of many-to-one
> mappings of "real" numbers to displayed values.
Especially if they include multiple variables. For example, if the
player can use an evaluation command to get a general wieldability factor
for a given weapon, and the text output of this command is based off
of the weight of the weapon, the character's strength, the character's
skill with that weapon, the quality of the weapon, and the character's
perception (ability to evaluate all of this data), then the command is
useful for determining what is the best weapon for your character, but
uncovering any actual numbers is next to impossible.
One interesting idea that some friends of mine were experimenting with
for their mud had to do with hiding the details of the numbers while still
presenting numbers. As GoP types, they liked seeing numbers, but they didn't
want *everything* revealed. So what they did was show the players most
of the game stats divided by 10 and rounded to the nearest integer.
The main example, as I recall, was character hitpoints. Hitpoints were
computed in the typical D&D method. However, characters were shown
their hitpoints divided by 10, so a character with 392 hitpoints would see
"39" in their prompt. Incoming attacks were multplied by some value
(the character's damroll, I believe?): a 1d6 sword that rolled a 4 would
actually do more like 40 points of damage for a well-equiped warrior.
Finally, the incoming blow would have the victim's constitution subtracted
from it - so if you had a 16 con, the blow would go from 40 points to 24.
Finally, this would be subtracted from the character's current hitpoints
(392), leaving 368. The character's prompt would now read "36": to them
it was a 3 point hit. This makes every point of constitution count,
but not in a way that made it easy for players to see the formulas.
And of course, IMO good formulas should not have breakpoints or cutoffs
(eg, "I need a 16 strength to wield this weapon in one hand..."). If
everything is a smooth gradient, then players only ever know that "more
is better", and that's that. Naturally there will always be sweet spots
in the graph where the tradeoff between multiple variables that affect
one another is ideal for a given type of character, but in my experience
actually plotting the graph in order to get those values dead-on is not
too much more effective than just doing it by "feel", so to speak.
> Use multiple random variables, with them changing at different
> times. E.g., one could have a random "biorhythm" for each character
> -- when a character is logged in, the system generates random numbers
> for its mental/physical/spiritual/etc. potency, then uses them in
> further calculations. These only change between logins, so any series
> of tests run in a single login will be skewed.
I like this. It makes me think of a few similar ideas we've had here:
- The nethack luck system. When you enter the game you get messages about
"It's a full moon, you feel lucky tonight" or "It's friday the 13th,
you feel unlucky" based on the system time and date. This affects your
entire game in many mysterious ways.
- JC's luck system, where your luck wanes and waxes accord to your actions
and some random fluctuations. A player might figure out that for their
character, attempting to thread a needle when their luck is low is
impossible, but not the exact details of the needle-threading formula.
- Seeded randoms. This doesn't rely on a number that changes for every
session, but rather a number that is unique for each character. You
may well plot out the formulas for *your* character, but putting it
on a website is useful only in order to help other players compute
their own numbers, rather than a sure-fire table that they can simply
look up and know an exact value that is consistent across all characters
in all locations.
> Combine multiple values in levels displayed to players. E.g., a mud
> might internally use a linear system in which attributes average 50
> and range up to 200 for some attributes, but range up to 500 for
> others -- but remap all of them to show 5 as "average" to players and
> 10 as "maximum".
This seems more confusing to the implementors than anything else.
I don't see the point in obfuscating things at the implementation level.
> Another way of doing this might be to display compound attributes --
> e.g., the old Star Frontiers roleplaying game had pairs of related
> abilities: Strength/Stamina, Dexterity/Reaction Speed,
> Intuition/Logic, and one other pair I can't recall. The two abilities
> within a pair had to initially be within a certain distance of each
> other. A mud might use such pairs internally, but show each pair to
> players as being a single ability.
Very nice. I'm not too sure why something like this isn't standard
in RPG stat systems.
> The system might either lie about attribute values or might "scale"
> them differently for different characters. For example, a mud using
> textual descriptions might describe a human's strength as being
> "excellent" -- but that might be weaker than an ogre with "fair"
> strength, because the descriptions are scaled by race.
We've discussed this before: I believe JC gave an interesting example
where a character based their perceptions of their own stats entirely
upon what other character they have seen recently. Thus, if they witness
a great feat of strength, their strength display drops from (say) "good"
to (say) "average".
Although this makes sense both from a realism and from a number-hiding
viewpoint, as a player I dislike it. Whether I'm a roleplayer trying
to see how my character fits into the world or whether I'm a GoPer
trying to get the best character stats, I find it unsatisfying as a player
to have the stat display so "soft". Players need a frame of reference,
and I think this denies it to them.
> This could all be presented to players as being a single action -- the
> casting of a spell. Since multiple die rolls are involved, skills and
> attributes are used multiple times, different environmental factors
> affect the different stages, and stage 2 may or may not come into
> play, this could be a difficult knot to untangle.
*nod* Well, look back at my formulas in the lockpicking thread.
I simply make it practice to take into account four or five different
variables on both the person commiting the action as well as the victim
(person, object, or location). Formula obscurity is only a pleasant
side-effect of this practice; I do it because I like the complexity.
In fact, when I first began mudding, I assumed that that is the way that
it *did* work. I worried about my mage's dexterity (since I assumed
that it helped spellcasting), or the types of armor worn by my thief
(since I assumed that anything with metal or brightly colored would
adversely affect sneaking and hiding), or my wariror's charisma (since
I assumed it would affect how well I could lead a large group).
Naturally I was pretty disappointed when I looked in the code and
discovered that most dice rolls looked about like so:
if (dice(10, 10) < character->GetSkill(SKILL_BACKSTAB))
character->Message("You stab so-and-so in the back");
else
character->Message("You fail to stab so-and-so in the back");
> This could turn out to be a case where it's possible to create a
> simpler equation that will match most cases
Like Newtonian physics managed to explain an Einsteinien universe?
If this is the effect you get, I'd say that you're on the right track. :)
> There could be nonobvious inputs -- using _Fantasy Wargaming_ as an
> example again, its magic system is based on the medieval astrological
> System of Correspondences -- and thus, a spell that is governed by
> Taurus will be more effective during the hours governed by Taurus, or
> more effective when cast in a field full of cattle. (Of course, one
> can argue that if this is so, it should be known -- mages should have
> figured it out generations ago. However, there are world setups in
> which such factors might logically not be known.)
I like this kind of stuff because you can give players semi-accurate
information and then let their own rumors and mistaken perceptions
obfuscate things for you. In effect you've created player superstition.
For example, the Taurus spellmaster could tell your fledling mage that
the spells work best during the hours of Taurus, or when near bovines, but
work less well than normal when the caster is wearing anything made of
cowhide. Early players will, of course, test all of this out, but if
your formulas are difficult enough to discern, then I guarentee that
it won't be long before all Taurus mages feverently believe that coming
in contact with cowhide stunts their spell ability, whether you coded
it this way or not.
You can get even trickier; for example, come up with a spell system which
requires a great amount of chanting, waving about of fetishes, pots of
boiling water, minor fireworks, and other trappings. The teachers will
give your character instructions for spellcasting, which might look like
this:
Take a freshly boiled root of mandrake and eat it during the full moon.
Chant "uggawuggayug" twice, or three times for a more powerful effect.
Face the east and pull out a lock of your hair; face the west and throw
it into the fire. Chant "murgayurgachurg" while doing the dance of
witchcraft, and then shred a piece of paper holding your victim's name
over the fire. Finally, throw powdered rhino horn into the air and
chant "miwayagabaga" for as many times as you would like the effect invoked
upon your victim.
On top of this, have the teachers tell the players that their spellcasting
is always improved by wearing certain fetishes or charms favored by the
gods, done during a certain time of night or during certain days of the week,
etc. In fact, only about 30% of all of this data is true (that is, actually
coded into the system) - perhaps all the chanting list above is totally
superfluous. But the players don't know that...
Adam
_______________________________________________
MUD-Dev maillist - MUD-Dev#kanga,nu
<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>
</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="00786" HREF="msg00786.html">Re[6]: [MUD-Dev] The grass is always greener in the other field</A></strong>
<ul compact><li><em>From:</em> Travis Casey <efindel@io.com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00754" HREF="msg00754.html">Re[4]: [MUD-Dev] The grass is always greener in the other field</A></STRONG>
<UL><LI><EM>From:</EM> Travis Casey <efindel@io.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00778.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00780.html">Re: [MUD-Dev] Collecting ideas for a MUD server... (fwd)</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00775.html">Re: Re[4]: [MUD-Dev] The grass is always greener in the other field</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00786.html">Re[6]: [MUD-Dev] The grass is always greener in the other field</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00779"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00779"><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>RE: Re[2]: [MUD-Dev] The grass is always greener in the other field</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00744" HREF="msg00744.html">RE: Re[2]: [MUD-Dev] The grass is always greener in the other field</A></strong>,
Joe Andrieu <a href="mailto:joe@andrieu.net">joe@andrieu.net</a>, Thu 23 Dec 1999, 00:45 GMT
</LI>
<LI><strong><A NAME="00754" HREF="msg00754.html">Re[4]: [MUD-Dev] The grass is always greener in the other field</A></strong>,
Travis Casey <a href="mailto:efindel@io.com">efindel@io.com</a>, Thu 23 Dec 1999, 05:39 GMT
<UL>
<LI><strong><A NAME="00759" HREF="msg00759.html">Re: Re[4]: [MUD-Dev] The grass is always greener in the other field</A></strong>,
J C Lawrence <a href="mailto:claw@kanga.nu">claw@kanga.nu</a>, Thu 23 Dec 1999, 07:56 GMT
<UL>
<LI><strong><A NAME="00775" HREF="msg00775.html">Re: Re[4]: [MUD-Dev] The grass is always greener in the other field</A></strong>,
J C Lawrence <a href="mailto:claw@kanga.nu">claw@kanga.nu</a>, Thu 23 Dec 1999, 20:09 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00779" HREF="msg00779.html">Re: Re[4]: [MUD-Dev] The grass is always greener in the other field</A></strong>,
Adam Wiggins <a href="mailto:adam@angel.com">adam@angel.com</a>, Thu 23 Dec 1999, 23:44 GMT
<UL>
<LI><strong><A NAME="00786" HREF="msg00786.html">Re[6]: [MUD-Dev] The grass is always greener in the other field</A></strong>,
Travis Casey <a href="mailto:efindel@io.com">efindel@io.com</a>, Tue 28 Dec 1999, 05:36 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</ul>
</ul>
<LI><strong><A NAME="00671" HREF="msg00671.html">Re: [MUD-Dev] The grass is always greener in the other field</A></strong>,
Raph & Kristen Koster <a href="mailto:koster@eden.com">koster@eden.com</a>, Sat 18 Dec 1999, 17:52 GMT
</LI>
</ul>
</ul>
<LI><strong><A NAME="00648" HREF="msg00648.html">RE: [MUD-Dev] The grass is always greener in the other field</A></strong>,
Sellers, Michael <a href="mailto:MSellers@maxis.com">MSellers@maxis.com</a>, Fri 17 Dec 1999, 23:00 GMT
<UL>
<LI><strong><A NAME="00653" HREF="msg00653.html">Re: [MUD-Dev] The grass is always greener in the other field</A></strong>,
J C Lawrence <a href="mailto:claw@cp.net">claw@cp.net</a>, Fri 17 Dec 1999, 23:58 GMT
</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>