[MUD-Dev] The grass is always greener in the other field
efindel at io.com
Mon Dec 20 21:53:12 New Zealand Daylight Time 1999
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.
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.
(Of course, there are also some other factors -- e.g., on some locks,
it's possible for the pins to fall into the cylinder when the lock is
turned 180 degrees, which may cause the mechanism to jam and require
disassembling the lock to make it work properly again. Nonetheless,
barring such problems, any standard lock can be picked given
Ideally, each attempt to open the lock should take some time. In a
traditional paper RPG, this is easily done -- the attempt to pick a
lock is stated to take a certain amount of time. The game can either
be "fast-forwarded" that amount of time, or the other players can
state what they are doing during that time.
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
> 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. These two factors make it much, much easier for players to
figure out their formulas.
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. We can speculate either way, but
we won't know what would happen until someone tries it.
> Further, you often
> cannot assume that a complex behaviour cannot be approximated by a
> very simple behaviour sufficiently well to give good game rewards.
> Your formulae may be complex to all hell and gone as an attempt a
> obscurity and obtuseness -- and be totally useless if a simple
> quadratic approximates it well enough to satisfy 90% of the common
You can't assume that -- but you can plan for it, by trying to make
sure that there are no simple approximations.
You can also fight scripting in other ways, if you want to -- e.g.,
limiting the rate at which commands can be entered, and possibly
queuing "extra" commands to be processed later.
|\ _,,,---,,_ 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
More information about the MUD-Dev