[MUD-Dev] Containing automation?

[Matthew Mihaly]

Greg Miller wrote:
> 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.

That's not the point. Humans can easily categorize all the text they see,
and they know whether it 'belongs' or not. A client doesn't, unless it
contains a database of all the text and what produces it, etc.


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

Right. Sometimes they'll be fooled. That's their mistake though, so they
should get punished for it.

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

That's because I gave very simplistic examples, involving only defensive
manouvers. The idea of someone automating offence is fairly amusing, and
we've never had any reason to try and stop people from automating it, as
the only people who have tried have failed miserably, and predictably. In
any case, if you are convined you are right, then I welcome you to try and
automate combat in Achaea. If you can create an automated character (FULLY
automated) that can beat me (using absolutely no automation) in a fight,
I'll pay you $3000 plus however much you spent on your character.




 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.

People use automation for two things, in my experience. 1) doing things
they don't like doing due to being repetitive and 2) automating things
that they aren't good enough to do without automation. Our combat system
falls under the second part. Most people can't think quickly enough to
keep up with those who can fight properly, so they get cheesy and use
automation.

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

Yeah, exactly. It can still be automated of course, but it becomes a LOT
harder, if you have a game of any complexity. Well beyond the capabilities
of almost every user, and if done properly, well beyond the feasibility
threshold for every user (though thinking about what Raph said in terms of
large games spawning more software, I'll not rule out that in a game the
size of UO, someone could have a rl economic incentive to make and then
sell this sort of automation to other users).

--matt




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