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

[Brian Price]

> From:          clawrenc at cup.hp.com
>    at 12:15 AM, "Brian Price" <blprice at bedford.net> said:
> >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.

Agreed, it's kind of like a lock on your door, it helps keep honest 
people honest.  It does very little to stop the determined burglar. 

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

Yes, indeed on the system I'm envisioning, scripting would be very 
hazardous to a character's health.  (some details below)
 
> 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?

Nod, eliminating these actions where possible should be part of the 
game design.
 
> >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.

I'm guilty of a few assumptions here, in the mud I'm working on, 
speed-walking is a hazardous endeavor.  Features such as full pk, 
random events (stepping out in front of a speeding vehicle or into a 
crossfire complete with grenades landing short is not a bright idea), 
vehicle use, spaceflight, etc make moving from point A to point B 
an integral part of game play and definately a non-trivial 
sequence of events.

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

Given the mud system I'm assuming, this capability would, I believe, 
encourage scripting.  When you combine multi-room events, random 
events, 'fall-out' from ranged weapons combat, etc, any public area 
is a dangerous place.  Helping players to speedwalk through areas 
would in general shortcut game-play.  I will admit however that it 
could make sense for 'safe' areas although those areas would be the 
exception rather than the rule for my system. 

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

I'd better define what I mean by random events.  Some modified Diku 
descendants have random mob resets, I'm taking this concept further 
by using the idea from paper rpgs of random encounter tables.  With 
such a system, most mobs have no set load location, rather, when an 
area is observed by a player (or a player henchman/pet NPC), a check 
is made to see if anything is there, if something is, then a number 
is generated and used as a lookup into a table of mobs (not 
necessarily a table of even distributions however).  The net result 
of this is that you could pass thru an area hundreds of times and 
then on pass 203 run into a mob or event which you didn't even know 
was a possiblity.  This type of randomness not only is _very_ 
difficult to script, but also (imo) adds much to game play.

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

I don't believe the system I described briefly above is subject to 
this type of attack, at least, not unless you have access to the 
area's design and encounter tables.  I'd also note that I'd like to 
make the system such that encounter tables can and will be changed 
occasionally by the admin.
 
> >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.  

This makes a number of assumptions (namely that you're dealing with a 
hack'n'slash with a diku-like mob loading mechanism).  While I 
probably will allow a small amount of xp to be derived from killing 
mobs, I'd like to make most xp come from performing quest-like 
activities (ala Traveller's patron system with a mechanism to make 
complex quests re-usable).  Also, I'm aiming more at a quick-start 
char gen game without char levels.  While some skill advancing is 
necessary, it shouldn't been the main focus of the game.  The whole 
system is further complicated for the scripter by being a perma-death 
possible, full pk game system.  In my opinion, the smarter the mud 
(with human pk adversaries being the smartest, sort of), the less 
payoff for scripting.  

My assumed goal in all of this is to develop a mud which is aimed at 
both the programmer and non-programmer alike.  I'm also aiming for a 
character startup cost (in player time and effort) about one-quarter 
of the way between doom and a leveling diku.  If I'm successful, the 
end result will focus more on game play than character development.

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

Depends on how ranged weapons are implemented, what messages are 
given, what countermeasures are availble, etc.  
 
> 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.

Nod, agree entirely, I'm attempting to make the game design such that 
automation is penalized, unless you invent true AI (or close to it) 
at which point I'll quit developing muds althogether and rest happy 
with a small footnote in the history of AI research :)

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

Yes, most systems I've seen implemented in present muds are very 
vulnerable to these kinds of attacks.  As you note, the trick to 
preventing it is to make the game apparently non-predictable.

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

The biggest injector of randomness into a mud is other players (esp 
in pk).  Good mob-AI also injects a degree of randomness that can be 
sufficiently complex to mask or hide some permutations from a single 
observer for quite a long time.  Likewise the mechanism of non-linear 
probability encounter tables can effectively hide all possible 
permutations from the would-be scripter.  While defeating each one of 
these seperately might be possible, defeating the synergetic effects 
could be well-nigh impossible depending upon the richness of the 
system.
 
> 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.

   Or XXX mutates into an essentially unrecognizable configuration.
 
> #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.  

   The effect of #1a might be achieved through a sufficiently 
inter-dependant set of activities.  Thus an activity B might only be 
profitable if A has been done and no one has done C.  The badly named 
plot element node theorem I posted points towards one way to 
interconnect events in this manner.
 
> 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)

This is the general approach I'm aiming for although I'm attempting 
to implment it with a combination of simple mechanisms.  Especially 
if I can ever find a realistic way to implment the aforementioned pnel 
theory in a buildable and useable manner.

Brian Price
                   Brian Price
               <blprice at bedford.net>