[MUD-Dev] Containing automation?

[Matthew Mihaly]

<snipped question from Timothy O'Neill Dang on preventing client-side
automation>


We have done a LOT of work to mess with automation, both those stupid
auto-walks that zmud has and your general triggers. We feel that it is not
possible to totally stop it, unless your game was utterly random. Of
course, in that case, a user without triggers would be screwed too. So the
goal has to be defeating most triggers while not making it much more
difficult for the average player to play (I don't know why you are
concerned with people macroing thing. Macros simply equalize the
differences in people's typing speed. They don't affect the
decision-making process at all, unlike triggers.)

While it's probably possible to trigger anything that can be reacted to by
a human, what you have to do is decide which client-side packages you are
concerned with defeating, and then make sure you understand their
capabilities. I, personally, think Zugg is the devil, and should be
crucified for all the annoying triggering stuff he has in Zmud. Zmud is
the major standard mud client, but of course tinyfugue, tintin, mudmaster,
rapscallion, etc all have trigger capabilities.

What we've found is that, contrary to Koster's law (which I believe is
incorrect), it IS possible to stop people from automating all functions of
your game. Someone potentially COULD automate our combat system, but it
would be an undertaking of massive artificial intelligence, and I don't
see anyone bothering to take the time to do it. (I believe Koster's law
says that players WILL automate everything, which clearly is not true.)

The techniques we use to prevent this generally involve forcing the player
to make decisions based upon information contained in previous lines. We
also take advantage of latency to screw with triggers.
Pardon the world-specific examples, but they are the easiest for me to
give.

Example: We have an affliction that will cause about 25-30% of a player's
commands to be executed as another, random command. So, say you have this
affliction (which we call 'stupidity'), and you get hit by the venom
curare, which paralyses. 

Client would see: A prickly stinging overwhelms your body, fading away
into numbness.

Client would then try to trigger "eat bloodroot".

If that command got screwed up by stupidity, then potentailly any feedback
from the server is possible. Because of latency, I see no way of the
client knowing if the command went through properly or not. It could wait,
say, a couple seconds to see if the text it expects in response to eat
bloodroot (something about "Your muscles unlock and you can move again"),
but that means that the trigger doesn't even know whether to try again for
a full 2 seconds, which is a very long time. If it weren't for latency,
then the client could simply check the next piece of output it receives
after eating the bloodroot, but because of latency, there is no way for it
to know if the next output it gets relates to the eating bloodroot or not.

Another example of how to screw with triggers:
Say that someone wants to trigger the paralysis message, as above. He
decides not to worry about the stupidity affliction and count on being
able to manually heal himself with a macro if his trigger doesn't work (a
partial victory for us already). However, the bloodroot may only be eaten
with any effect once per second. So, you give people the ability to "fake"
delivering the curare venom, and THEN deliver the real one. Assuming
latency is low, the person's trigger will kick in, trying to cure the fake
message, and then when the REAL curare hits him, his trigger will try to
eat the bloodroot to cure it, but will fail, due to having just eaten
bloodroot. Anyone NOT using triggers will not be fooled, because he'll see
two messages and only respond to the second one (people can't respond as
fast as a computer can).


I'm not sure how much help this is for defeating triggers in an economic
system, but I want to emphasize that it IS possible to create a system
that players will _not_ automate. Automating our entire combat system
would be far far beyond the scope of 99.9% of our user's capabilities, and
not worth the time,effort, and expense for the .1% that might be able to
manage it (a custom, very powerful client would have to be written, with
fairly sophisticated AI, etc).

The economic system you described sounds pretty basic, and it doesn't
sound as if there is much strategy involved, or much decision-making
involved. If you want to stop people from automating it, I think you have
to force the users to make decisions based on previous output. If there is
just a standard way of doing things, ie a to b to c, then you are going to
be pretty much screwed in terms of stopping automation, I suspect.

--matt





_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev