[MUD-Dev] Containing automation?

Greg Miller gmiller at classic-games.com
Mon Jul 19 17:38:54 CEST 1999


Matthew Mihaly wrote:
> 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.

This doesn't really affect clients any worse than humans. Humans don't
know whether their command worked or not until they receive a response.

[snip]

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

Most of the time, they won't be fooled. It's easy to screw up though,
when scanning for relevant messages. It's a pretty good technique,
though.

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

I don't see how it would require a custom client. All of the techniques
you've mentioned can be defeated with combinations of the most basic
triggering mechanisms--it just takes a lot of them.

In any event, creating a system people won't automate is not nearly as
good as creating one people won't want to automate. People use
automation for the parts of the game they don't really enjoy all that
much.

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

Another way to say this is that they should have to make decisions based
on the current state of the game rather than consistently reacting the
same way to the same outputs.
--
http://www.classic-games.com/
Conspiracy theorists mistakenly assume others think before acting.
*** Please limit .sigs to four lines and avoid HTML mail or posts. ***



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




More information about the mud-dev-archive mailing list