UI Issues: Anti-scripting techniques

[Brian Price]

I've been lurking about on the list lately but have been following 
the UI threads with interest.  One topic that was touched upon 
briefly was the issue of player scripting, assuming that this is a 
BAD thing the immediate question that arose to me was "With or 
without, preferably without, the use of a custom client, how might a 
mud be designed to discourage would be scripters?".  

Having done a bit of scripting and 'pseudo-scripting' with zMud, I 
immediately saw three seperate 'areas of attack' to greatly reduce 
the payoff for scripting.  The first area of attack is to prevent 
multiple commands and repetitive sequences of commands.  The second 
is to confuse and complicate the scripting of triggers.   The third 
is to design the game itself so that scripting is a marginal 
enterprise.

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

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.


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.


While both the first and second anti-scripting attacks can defeat 
most casual scripters with only a moderate one-time effort on the 
part of the mud developer, sophisticated scripters and fellow 
programmers will no doubt find ways around both attacks if the game 
is such that they see a reward in putting in the extra script 
development time.  Therefore the best attack against scripting 
attempts is to design the game such that scripting has a marginal 
return on investment.  Randomness is the enemy of scripters and 
random events can also spice up a mud.  Even a relatively standard 
diku-like design could profit from random mob resets.  

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.

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.

Brian Price