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

J C Lawrence claw at cp.net
Wed Dec 22 15:02:37 New Zealand Daylight Time 1999


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.

Consider:

  You are told Fortress Fract contains good stuff.

  You logon at <whenever> (02:00hrs?) and go the Fortress Fract.
  Understandably very few other players are logged on due to the
  hour

  You set your macro spinner running and go to bed.  Three hours
  later it breaks in to the fortress and plays a nice loud MP3 to
  wake you.

  You make hay.

Timing, or rate of success is part of the manifest problem, but I
don't see it as either causal or inherently part of the solution.

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

> On a mud, however, you're generally locked into some sort of
> "real-time".  Thus, making picking a lock take X minutes in game
> time will require preventing that character from taking any other
> action for some period of time.

> This is the same problem as with long-distance travel, just on a
> smaller scale.

Very good point.

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

>> YOu cannot assume that just because something is difficult or
>> complex, that it won't be figured out, __or__ that it won't be
>> automated.  This has been proven time and again.

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

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

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

<<Can you tell I've been charting the narrow arguably technically
correct line in the middle of an inter-corporate dispute today?>>

> We can speculate either way, but we won't know what would happen
> until someone tries it.

Sooth.

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


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



More information about the MUD-Dev mailing list