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

[clawrenc at cup.hp.com]

In <199709260444.3287300 at bedford.net>, on 09/26/97 
   at 12:15 AM, "Brian Price" <blprice at bedford.net> said:

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

#1 is actually not a problem for a scripter and can be trivially
defeated by almost any scriptable MUD client out there.  You just need
to intersperse the scripted commands with other no-op commands to
break the pattern, or to insert timed pauses between commands.  #2
just raises the ante.  Scripting is more difficult, but not impossible
or unprofitable.  

The net result of #1 and #2 in general are to impede scripting, not to
reduce its profitability.

#3 is where the real gold lies -- design a game which cannot be
profitably scripted, or (more likely) for which scripting is not
sufficiently profitable over non-scripting to make the difference
worth while.

Caliban touched on this recently in commenting that he likes to script
rote actions which don't add to game-play.  This of course begs the
question on why those actions are required if they don't add value to
the actual game play?

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

This would annoy the crap out of me as a player.  The classical case
is speed walking.  If I'm at point A and wish to get to point B, and
know the exact sequence of commands to get from A to B (very likely if
I've played more than a day or two), then I want to be able to sit
there and bang out commands as fast as my KB will take them.  The game
can catch up later.

Note: A key value here is the ability to interrupt such a stack of
entered commands.  Consider the case:

  > n,n,n,n,n,e,e,s,s,w,w,u,u,e,u,w,w,w,s,e
  Room 1.
  Room 2.
  Room 3.
  There is a huge pile of gold here.
  Room 4.
  Room 5
  Room 6
  Room 7
  ...etc.

Better would be:

  > n,n,n,n,n,e,e,s,s,w,w,u,u,e,u,w,w,w,s,e
  Room 1.
  Room 2.
  Room 3.
  There is a huge pile of gold here.
  Room 4.
  Room 5
  > !stop
  Room 5
  >back,back
  Room 3.
  There is a huge pile of gold here.
  > get gold
  ...etc.

This is of course an extension of the more general Panama Canal
scenario.

>The second area of attack, confusing and complicating triggers could 
>be a lot of fun.  (Yes I have a warped view of fun)   

Agreed.  This ups the ante, adds flavour, and increases apparent
complexity for little to no cost.  It also encourages mistakes of the
form Nathan has commented taking advantage of (emoting the last
character exit to lead the follower into a DT or similar).

>Therefore the best attack against scripting 
>attempts is to design the game such that scripting has a marginal 
>return on investment.  

Bingo.  This is my main interest.

>Randomness is the enemy of scripters and 
>random events can also spice up a mud.  

Care needs to be taken with the definition of "randomness" here.  

Back when I wrote many scripts to automate logging on to a BBS,
getting a mail packet, grabbing new files, and logging back off again. 
Of course Sysops tended to add new menus, or news screens to confuse
scripts.  The temptation was to write increasing complex scripts in
attempt to handle all the variations.  I abandoned that approach for
the inanely successful:

  Script:
    logon stuff
    Look for XXX prompt
    Send 20 [ENTER] keys
    Look for XXX prompt
    Not there? Send more [ENTER] keys.
    issue command to get mail
    Look for XXX prompt
    Send 20 [ENTER] keys
    Look for XXX prompt
    Not there? Send more [ENTER] keys.
    get new files
    Look for XXX prompt
    Send 20 [ENTER] keys
    Look for XXX prompt
    Not there? Send more [ENTER] keys.
    etc.    

Absolutely minimal intelligence.  Instead it was an application of
least required stupidity.  Similar can be done with most other forms
of randomity if the expense of getting the desired trigger is low
enough.  

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

Nope, you've just trivialised it a different way:

  Endless loop:
    Go to woods/city/whereever
    Kill frodo's
    Kill beggars
    Get money.
    Go to trainer
    Get trained.
    Anything weird happens, logoff.
  Repeat.

I could easily see working out such a script for most any hack'n'slash
in a couple minutes and leaving it running overnight.  

For those interested, I once wrote such a script to automate SHADES. 
It looked for empty games (no players), and then did a very simple
sweep of the game, cleaning out all the obvious and common treasure. 
It would then log off that game, log on to game #9 (intended for
newbies, but there were backdoors into it), clean out that game, reset
the game, do it again on game #1, then game #9, and repeated the whole
set ad infinitum.  Leave that puppy running a couple nights and anyone
could make Wiz without ever learning anything about the game.

Aside: Wiggins has recently commented here on Artic's approach to
skill improvement which seems considerably more attractive (and an
interesting variation on travel points)

>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 seperate scripting into two camps:  Triggers, and Automation.  There
is some bleed-over between the two, but it seems to be minimal.

Triggers are simple reactive things.  They look for certain inputs and
react with canned predicted outputs.  Classic triggers enclude such
things as eating when hungry, following other players or NPC's,
automatic responses when attacked, etc.  I'm aware of the abuses and
problems (eg trigger wars).  I *despise* them as a player as I feel
they needlessly weaken the game.  I'm not terribly worried by them as
an Admin or Imm, most especially since they can be fairly easily
de-emphasized (eg fight reaction triggers aren't much use when ranged
weapons are common).

Automation is a different kettle of fish.  This covers longer term
actions where an entire process is automated.  The problem is systemic
in character rather than behavioural.  The example above of killing
the frodos and beggars and training is a classic example.  Other
similar scripts abound.  These I feel are actively and massively
destructive to the games and the playability of the games.  The mere
fact of their presence suggests to me that the game is inherently and
fatally flawed.

The challenge is to identify the systemic short circuits which can be
spun on by a script profitably.  

The problem is that this is a short sighted solution.  Almost any game
system can be profitably automated if you make the time period of the
script long enough.  Sure, its easy to script the training as above. 
Its also easy to script getting your character up thru the first
couple levels on a Diku.  Put enough work into it and you could also
script a character all the way up to Wiz.  The base principle is that
a game is made of predictable, mechanical systems, and as such can be
handled by a mechanical automator.  

  Consider:  Most of us got a feel for where the balance points were
in SimCity.  The result was that we could with a fairly minimal amount
of effort get an infinite treasury.  Just build a set of nicely
profitable cities and keep them there, wobbling slightly (tear
down/build back) to keep your populace busy/happy.

Even randomness isn't a saving grace if it is known (and it is) that
the injected randomity can be from a defined and known small set of
permutations.  Once you know the possible permutations that can be
injected, it is simple to work around them.  

Asie: Speedwalking is a variation on automation, tho not one I decry.

My major attack on this area has been:  

  1) To make many activities one-time-only.  

  1a) As a variation on #1, to make many actions only profitable 
      for players of a narrow range.

  1a1) As a variation on #1a, to make many actions heavily 
       penalising for players outside of that narrow range.

  2) To make many processes require indeterminate state transforms.

#1 is tricky.  It mostly maps out to variations on the quest concept
-- once a certain character has done XXX, either XXX never occurs
again (see #2), or there is no profit (penalty?) in doing XXX again.

#1a is a bitch, and I'm moving away from this approach heavily in the
general case.  My main problem is making the limitation "reasonable"
within the game context.  cf the current r.g.m.diku thread on level
limited equipment.  Aside from the facts that I don't have levels, I
don't have level limited equipment, and I'm not running a monty haul,
most of the concerns there apply to me.  

About my only hold-over for #1a are puzzles which require certain
weight limits (eg the previously described White Oak Tree and Human
Catapult), or other narrow band physical stat requirements.  I've also
been toying with a mobiles collections (cf earlier discussion on
combat intelligence by mobiles) which are sensitive to the rate at
which their bodies are stolen (speed is assumed proportional to
attacker's level for this context).  Too fast and the mobile squeals
to its master who then attacks in force, too slow and it takes time to
summon reinforcements, just right and you have the chance to win. 
This also allows the possibility for a character to deliberately tone
his attack to hit the middle zone, tone it up to get the master, or go
very low to get the crowd.  

<<I'm also playing with ideas of decoy attacks here, say to distract
NPC forces.  Tthe concept of automating generalship in an NPC
population is fascinating.  See earlier discussions of seargent
mobiles coordinating the operations of small bands for loose
coverage>>

#1a1 really is a minor variation, just noted for compleatness.  The
human catapult is fatal of course if your weight is outside of a
fairly broad band (perma-death (reason for running multiple bodies)). 
Lesser tolerances merely put you in more or less
intractable/impossible positions.

#2 is the the more general approach of removing resets and
predetermined state machines for various randomly interacting systems
(typically feedback loops operating on shared resoureces) which
mutually conspire to tear down some desired state, or to create some
very undesirable state.  (cf Orcs/breeders/fighters/nobles,
Princess/orcs/kidnap, mobile population migration, mobile royalty
systems, mobile inheritance thru children, scenarios etc)

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...