[MUD-Dev] Containing automation?

Matthew Mihaly diablo at best.com
Tue Jul 20 13:04:18 New Zealand Standard Time 1999


On Tue, 20 Jul 1999, Charles Hughes wrote:

> At 05:38 PM 7/19/99 -0700, Matthew Mihaly wrote:
> [snip]
> >What we try to do is limit
> >the advantages that automation can give. We're never going to fully
> >eliminate it. For instance, during some combat tournaments, I may ban
> >triggers. It's fairly easy to tell if someone is using a trigger during a
> >fight, and the threat of extremely dire punishment (possibly deletion) for
> >breaking those sorts of rules usually keeps people in line.
> 
> I'd have to see it to believe it. Assuming the standard escalation 
> routine between scripters and anti-scripters I doubt you could tell
> that a good player was using a trigger. When playing muds I can't tell 
> the difference between a trigger and a single-keystroke that generates 
> a series of commands. (Unless I'm setting off the trigger of course,
> and even then I've personally pretended to have a trigger set so it
> isn't possible to be 100% accurate in determining whether a trigger
> was used or not. I wouldn't even believe 50% accuracy when dealing 
> with an experienced player.)

It is, actually, extremely easy to tell if someone is using triggers. Our
combat system, as I have described here before, is very fast and furious,
and it is easy to tell when some idiot is using triggers. His responses to
healing will be very fast, very consistent, and out of proportion with his
overall combat ability (offence cannot reasonably be automated).

> You can't spam someone with trigger text if the trigger is linked to beginning
> of lines UNLESS you are allowing users to mimic game output. This is a much
> more
> serious problem than bots will ever be. If you do allow users to mimic game 
> output, then how can a user ever know that something he sees is real?

We just use illusion spells. They are configured to work on conjunction
with certain abilities that are too easy to trigger otherwise. And yes,
illusions allow you to mimic game output.


> 
> > If
> >they bitch about tactics like that, I just ask them why they don't stop
> >using up the magical item, or using up the elixir. Should be OBVIOUS,
> >after all, if you see the same text over and over, that it's fake. Not my
> >fault you keep responding to it predictably.
> 
> The solution to your anti-bot tactic is simply delaying execution of trigger 
> commands. A non-trivial task but not a problem for script-kiddies, and the
> delayed execution script only needs to be written once. After that it is
> merely
> a matter of relatively simple modifications which anyone can handle.

What sort of delay are you going to put on it? You could put half a
second, but that's definitely too much to compete at the highest levels.
You could vary it randomly, perhaps even having your triggers purposefully
not go off, but someone who depends on triggers isn't going to be good
enough or paying close enough attention to compensate manually when the
triggers do not go off. In the end, there are no players that can
consistently beat myself and one other God (we play mortals to fight,
obviously), and neither of us use any automation at all. Some people use
tons, and we can still cane them. 



> 
> I don't think trying to limit script use by attacking the user is the
> proper or best solution. The best solution is to make the scripts unnecessary.

I'm not going to down my combat just because most people can't fight
properly and compensate with triggers. We have little problem spotting and
regulating people who depend on them, and it's no surprise that as people
increase their combat ability, they tend to start doing away with
automation, either as a practical measure (nothing is more deadly in
combat than the sort of predictability that triggers entail), or as a
measure to gain some honour and stop being cheesy.

--matt




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




More information about the MUD-Dev mailing list