[MUD-Dev] UI Issues: Anti-scripting techniques

[Travis Casey]

Brian Price <blprice at bedford.net> wrote:

>The first area of attack, preventing multiple commands and repetitive
>sequences of commands, is simple, even trivial.  Multiple commands
>can be defeated easily in five steps:
>    1.  Only allow one command line entry per period of time t.
>    2.  Only allow x command line entries per period of time t * y.
>    3.  Discard any commands which fall outside 1 or 2 (do not
>         enqueue them).
>    4.  If more than z commands are recieved in a period of time
>         greater than t*y, flush the input queue and break the
>         connection, logging appropriate information.
>    5.  Include random events which cause random time delays in
>         character actions.  One good candidate is weather
>         conditions. (ie muddy road taking an extra tick to
>         traverse).

We've done something like this on SWmud -- specifically, we made
a running total of commands entered in the last four seconds.  If
that total exceeds a threshold, commands are rejected with an error
message.  If it exceeds a second, higher threshold, the character is
logged off from the mud.

Before implementing it, we did a bit of testing to find a good rate --
one that wouldn't bother fast typers too often.  If I remember right,
we wound up choosing 10 command/four seconds for the first threshold,
and 20/four seconds for the second.  Those might not be right (I haven't
gone and looked at the code to be sure), but whatever the rates were,
we were rarely able to even get a warning issuing a one-letter command
as fast as we could manually.

>Repetitive sequences of commands to a certain depth could be detected
>using a command history buffer together with a simple counter
>and flag a wizard or a wizard-bot.  A wizard-bot would simply halt
>the player's input (perhaps moving them to a temporary safe zone)
>until the player answered one of a number of randomly selected
>questions.  If it was a false detection, no (or little) harm
>comes to the player, if a correct detection, an unattended script is
helpless
>to respond.  All detections, true and false, should be logged.

That depends to some extent on how the mud's set up... I've heard people
discussing the idea of a mud where the player would have to manually issue
a command to attack a monster each round of combat (yes, I think they're
insane too).  If someone actually implemented a system like that, then
a history-checker would often get false positives on it.

>The second area of attack, confusing and complicating triggers could
>be a lot of fun.  (Yes I have a warped view of fun)   Take the common
>case of a pk script which has a tracking attack trigger.  Instead of
>always having the mud display the text:
>  " Boffo flees and leaves to the east."
>Use a randomly selected phrase such as:
>   "Panicing, Boffo runs to the east in terror."
>or  "Boffo quickly retreats eastward."
>
>In combination with multiple phrases, add random events that
>duplicate much of the likely trigger text, such as:
>   "Paniced by the fight, a cat leaves to the east."
>
>Cleverly selected random event phrases could easily make the use of
>triggers disasterous, or at least counter-productive, for the user.

I like these ideas... not only do they make triggers harder to use,
but they also add variety to the mud.  The only down side I see is that
someone has to come up with the various alternative phrasings and program
the random events.

>One of the biggest and juiciest targets for casual scripters has to
>be the (IMO) absolutely moronic skill percentages which rise slowly
>with use.  I cannot begin to count the number of times I have seen
>such systems result in players spamming commands to improve the skill
>percentage or use timers to automate skill improvement.  This type of
>game construct practically begs to be scripted.  Compare it to its
>alternative however, what if you had skill ratings for those same
>skills say from 0 to 9 which were trained at a cost of xp and money
>at a trainer somewhere?  Bingo, the incentive and opportunity for
>scripting that construct has been removed in one fell swoop.

As someone who has often championed such systems, and who has helped
to implement several of them, I have to take exception to this
comment.  :-)  The basic idea behind such a system is that a character
should be able to get better at a skill by practicing it.  This is
quite realistic, and, ideally, should lead to players being better
able to define their characters and should encourage roleplaying.
Quite simply, a warrior *should* get better at fighting by fighting,
a thief *should* get better at stealing by stealing, and a chef *should*
get better at cooking by cooking.

The problem, IMHO, is not in the concept, but in the implementation.
I think Brian's talking about the implementation of this idea that he's
seen on SWmud, so I'm going to talk specifically about that implementation
and its problems.  Hopefully some of this will still be helpful to others
implementing such systems -- sort of a warning about what I'd change if
I could do it over.

1 - There are many cases where it's possible to attempt to use a skill,
    and thereby advance it, when the character simply shouldn't be able
    to.  The best example of this is hiding -- on SWmud, any character who
    can hide can try to hide at any time, and gets advancement in the
    hiding skill for it.  A more logical implementation would only test
    the skill, and therefore allow for advancement, when there was a chance
    that someone would notice you -- after all, it's hard to improve a skill
    with no feedback about whether you're doing it right!

    In some cases, this is due to a lack of reality in other parts of the
    game.  For example, a player who wants his/her character to get better
    at lockpicking can simply find a lock and try to pick it over and over,
    locking it after each success.  In many places, this would be prevented
    if there were patrols in the area or alarms attached to the lock --
    realistically, one shouldn't be able to simply sit in the middle of a
    military base and work on picking a lock without having to worry about
    being discovered.  This leads into the next point...

2.  One shouldn't be allowed to indefinitely repeat the exact same attempt
    and keep learning from it.  In the example with the lock, there's only
    so much one can learn about lockpicking from one lock -- after one or
    two successful attempts, the character should have to move on to another
    lock to learn more.

    The Arduin paper RPG has a wonderful concept which is related to this.
    In it, once a character has succeeded or failed at a particular task,
    that character doesn't need to roll for it again unless circumstances
    change in a way that will lower or raise (respectively) his/her chance
    of success.  For example, if a thief fails to pick a lock, he/she will
    fail on any subsequent attempt to pick that lock until circumstances
    change in his/her favor (e.g., the thief gets better at picking locks,
    obtains a better set of lockpicks, or can spend significantly more time
    trying).  In general, this only applies to long-term actions, not to
    "instant" actions -- for example, it doesn't apply to hit rolls in
    combat.

3.  Difficulty should play a role -- if something is so easy that it can
    be done automatically, or nearly so, the character shouldn't learn
    anything by doing it.  To give a few examples, a skilled programmer
    won't learn anything by writing yet another implementation of a
    bubble sort, calculus teacher isn't going to learn anything about
    math while balancing a checkbook, and Bobby Fischer isn't going to
    learn anything about chess by playing me.  :-)

4.  Lastly, characters should start out reasonably competent in their
    skills and the players should know that.  There's much less
    incentive for a player to raise a skill which has a 40% chance of
    success than one that has a 1% chance of success, and the time spent
    also seems less rewarding -- moving from 1% to 10% seems like a huge
    difference, but 40% to 49% is less exciting.

    On SWmud, we made a mistake that relates to this -- we show character's
    skill levels as a percentage of how much they can learn, as opposed to
    a chance of success.  Several things factor into chance of success on
    SWmud -- a base chance of success, score in a related ability, whether
    the guild which gets the skill is your primary guild, and, lastly, a
    learned ability with the skill.  Hence, a character with "0%" listed
    for a skill may actually have a 40% chance of success -- and a character
    with "100%" listed might only have an 80% chance of success.  "0%" means
    only that the character has no learned ability with the skill, and
"100%"
    means only that the character has reached the maximum score in the
    learned portion of the skill.

    All this information is in an FAQ for the players, but many never bother
    to read it, and are thus left with the impression that their skill
    percentage either is their chance of success, or that it adds directly
    to their chance of success.  (Yes, one would think that they'd quickly
    notice that this isn't true, but for some reason they don't.)

>I believe that by carefully examining the game constructs used in a
>mud design, one can eliminate much, if not all, of the incentive and
>opportunity for scripting.  In my opinion, this results in a better
>game.  After all, ask yourself this question: "Why is the player
>scripting this process?".  In many cases the answer is exceedingly
>obvious: "Because it is mind-numbingly boring and adds nothing to
>gameplay."   Granted, pk/combat scripting is another issue and will
>likely still require solutions such as presented in the first and
>second attack discussions.

I'd submit that something can add to the *game* without adding to
*gameplay*.
Also, boredom doesn't seem to be a part of it, from my point of view -- I
think it would be much more interesting to actually *play* the game instead
of mindlessly focusing on simply raising one or two skills as fast as one
can.  IMHO, many scripters are simply looking for an advantage -- a way to
advance more quickly than the other players can by "playing" either faster
or more often.
--
      |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
     |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
    '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html