[MUD-Dev] The grass is always greener in the other field

[Travis Casey]

On Wednesday, December 22, 1999, J C Lawrence wrote:
> On Mon, 20 Dec 1999 21:53:12 -0500 Travis Casey <efindel at io.com> wrote:
>> On Saturday, December 18, 1999, J C Lawrence wrote:
>>> On Sat, 18 Dec 1999, Ian Macintosh <iman at issystems.co.nz> wrote:

>>>> I would suspect that you would just keep track of the last one
>>>> attempted per player (ie, player.last_picked_lock or whatever).
>>>> That'll stuff the macro's up.  And that's all you really want,
>>>> isn't it?

>>> No go.  All that happens is that the macro people change the
>>> macro to be:

>>> Go to house X and pick lock Go to house Y and pick lock Repeat
>>> until success.

>> Which may be enough, if you simply don't want someone to spam the
>> lock to quickly pick it.  The real problem here is not the ability
>> to keep trying to pick a lock until you succeed -- it's the fact
>> that each attempt takes so little time.

> Disagreed.  All that really means is that my macro spinner takes
> longer to pick the lock it doesn't change the fact that despite the
> probability of any one pick being successful being tiny, when
> repeated ad-infinitum they approximate 1.

Is that a disagreement?  I didn't say that it solves that problem -- I
only said that it may be enough if you simply don't want someone to
spam the lock to quickly pick it.  My "the real problem" note should
be taken in that context.

If that's not the problem you have, then it may not be enough -- but
that doesn't change the fact that it may be enough if your problem is
simply people spamming locks.

>> In the real world, lockpicking is a variable activity -- sometimes
>> picking a particular lock takes me just a few seconds, sometimes
>> it takes me a few minutes.  Almost any key-type lock can be picked
>> by someone who knows how to pick locks, given sufficient time --
>> it's that time that's important, though.  The longer it takes to
>> pick a lock, the greater the chance is that you will be noticed.

> Conversely, the problem with a game is that "notice" is a much more
> manipulable fact than IRL.  There are social structures and routines 
> built into RL that deal with "suspicious activities" that don't
> exist or particularly pertain to MUDdom.  

Of course, one could go on from that, and wonder why people are using
defenses that rely on such things for their true effectiveness if they
do not have such things in their muds.  The fact that a solution does
not work for problem X doesn't mean that it's useless for all problems
-- only that it's useless for that problem.

>>> The lengths players will go to to automate and chart their game
>>> worlds are extreme.  Look at the lengths players have gone to to
>>> empirically determine what UOL's base formulae are by carefully
>>> graphing the observed behaviours, and then tweaking the forumlae
>>> until they match the graph for damn near all the skill growth
>>> curves, combat curves etc.

>> Has it?  You keep bringing up UOL as an example of this, but their
>> formulas are rather simple, and they expose many numbers to the
>> players.  

> I quote UOL as one of the better documented examples.  Additionally, 
> for some of the tables that have been derived (and this can be
> extrapolated all the way down to the reverse engineering of the UOL
> client protocols and data structures) considerable empiracle work
> was required to go as far as they did.  Yes, UOL provided an easy
> initial start, but I don't see that this minimises the the magnitude 
> of the actual work done.

> Heck, at one point I graphed and derived most of the base curves for
> SimCity after I got sick of trying to ghost-feel for the sweet
> spots...

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".

>> These two factors make it much, much easier for players to figure
>> out their formulas.

> While I can't give an example, I also recall seeing traffic in RGM*
> reverse engineering the apparent base formulae for MUDs which hid
> the numbers behind cute phrases.

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.

>> To my knowledge, no mud has yet tried hidden numbers and
>> deliberately obscured formulas -- and while it makes no sense to
>> assume that such an attempt would be 100% successful, it also
>> makes no sense to assume that it would be 100% unsuccessful.  

> True.  However given a successful game (commercially, or of a player
> base size sufficient to represent a commercially successful game),
> it appears reasonable to assume that such an attempt would be
> successful.

However, not everyone wants to have a game of such magnitude.  For
those interested in smaller playerbases, and especially those more
focused on roleplaying (who are less likely to attract large numbers
of players, and whose players are arguably less likely to be
interested in such number-crunching), such solutions might still be
attractive.

I'm not saying that it *will* work, or that it would be some sort of
panacea -- all I really want to say is that I think there are useful
techniques that could be discussed, but that repeatedly bringing up
UOL as a "counterexample" may be having a stifling effect on such
discussion.

A few ideas on techniques:

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.

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".

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.

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.

Use multistage processes, with the interior stages hidden.  For
example, the paper RPG _Fantasy Wargaming_ divides casting a spell
into two or three stages:

 Stage 1 - caster creates a magical link to the target
 Stage 2 - the target, if magically active and aware of the link, can
           try to resist by sending a magical command to "desist" back
           down the link
 Stage 3 - the character sends the spell down the link, and the
           spell's success or failure is determined

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.
           
This could turn out to be a case where it's possible to create a
simpler equation that will match most cases -- but it also might not.
Testing would be necessary to ensure that it isn't.

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.)

The inputs for a particular calculation might vary -- to take a simple
example, the system might take the best or worst two of several
possible inputs.  If you're being truly nasty, the inputs might vary
randomly or on some sort of bizarre pattern.

Outputs may vary as well -- for example, an equation might produce one
output, which is then "split" through another calculation (possibly
involving random inputs) to produce multiple dimensions of an output.
To bring this back to lockpicking, one might split a result into how
long the attempt takes, whether or not it succeeds, how much noise is
made, and whether any visible evidence of the lockpicking is left
(e.g., scratches on the lock).

This is just a sampling of ideas -- there are many more possibilities,
I'm sure.  The point is that if you want to obscure how the system
works from players, there are many ways to do it.  Whether the effort
is worth it, but in terms of effort and likely player annoyance, is
something that different mud designers will have to answer for
themselves.

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)





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