[MUD-Dev] Containing automation?

[Koster]

> -----Original Message-----
> From: Matthew Mihaly [mailto:diablo at best.com]
> Sent: Monday, July 19, 1999 5:07 PM
> To: mud-dev at kanga.nu
> Subject: Re: [MUD-Dev] Containing 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.)

I think he's using it in the sense of "repeated automated activity." Not a
literal keystroke-saving macro, but ongoing botlike processes. In the
specific case he's talking about, 

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

Picky, picky. :) I of course meant that they have the capability. There is a
threshold where it becomes not worth it.

It's also worth noting that stuff that the general user may not be capable
of automating, like say, speedwalk, might be interesting for one person to
automate, who then releases a nice GUI front end to his automation, like
say, a mud client. In other words, the wider your audience, the more likely
someone will find something worth automating, and then can distribute the
software to many people. In most muds this stops at standard mudclient
features, but in some muds it goes further, into mud-specific botting
scripts. And in commercial games it goes to the extent of custom
packet-altering software for maximum possible speed and efficiency.

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

There aren't many muds where there is an economic system at all, so they all
tend to be fairly basic, based on simple a + b = c types of things.
Eminently dull to actually manufacture things, and extremely automatable.

-Raph


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