Question Thomas

thomas wrote: How would you prevent client side triggers from handling the parry correct every time?

Fake outs. Harder the enemies gets the more often they will fake attack. IE do another attack right at 2.8 seconds.

how does this prevent triggers? Remember, modern clients can add a delay, too.

As soon as your gameplay is dependent on some kind of response, it can be the basis for a trigger.

In muds I have played, I've automated lots and lots of tedious tasks - enything from filling a waterskin when I enter a room with a specific room description to particular attack patterns (kick, another trigger from the kick description, based on whether it succeeded or not, same thing with bash, backstab, circle (somewhat like an in-fight backstab?!), disarm, and practically every other skill.
In some cases, I had complete scripts for some bosses, with different kinds of bail-outs if some of my skills misfired.

Consider this situation: You'd end up not hitting anything on a player well versed in scripting his client. And you wouldn't necessarily know it was scripting, either, because the responses can be delayed and sent one character at a time, just like a real persons response.

What about adding some sort of decision making that would affect combat, that could not be effectively automated.

Eg: a 'Riddle of Steel' style pool of action points to spend on the attacks, maybe they power up the attack for extra bonuses (damage, stun, ...) the decision making would be to guess how much power to spend/gamble per action versus how many your opponent used.

Or could you have a combat round work in three stages (arbitrary number picked here)
Stage 1 (3 secs): players simultaneously pick their strategy (low sweep, thomas smash, wait, etc)
Stage 2: MUD outputs the messages simultaneously (Liko prepares a low sweep, Thomas prepares a cup of tea)
Stage 3 (2 secs): Players have a chance to adjust their action depending on what they are currently doing (Liko can adjust a low sweep to become a mid kick, Thomas can adjust his teacup to block low (thinking its a low sweep coming in))
Resolution of round: Thomas blocks low but gets kicked in the tummy (mid), spilling his tea!

thomas wrote: how does this prevent triggers? Remember, modern clients can add a delay, too.

As soon as your gameplay is dependent on some kind of response, it can be the basis for a trigger.

In muds I have played, I've automated lots and lots of tedious tasks - enything from filling a waterskin when I enter a room with a specific room description to particular attack patterns (kick, another trigger from the kick description, based on whether it succeeded or not, same thing with bash, backstab, circle (somewhat like an in-fight backstab?!), disarm, and practically every other skill.
In some cases, I had complete scripts for some bosses, with different kinds of bail-outs if some of my skills misfired.

Consider this situation:

Code:

time: 0.00s: Liko begins a low motion sweep. 0.01s: > parry low << triggered by the line above 0.01s: You parry the low sweep 0.02s: > punch body << triggered by the success message. Sends message like "Thomas begins a body punch" to the target. 1.23s: Liko parries the body punch. (or something - perhaps the hit succeeded?) 1.54s: Liko prepares a Fung-ya head strike. << cannot be blocked, but evaded by going low 1.55s: > sweep low << triggered by the line above. ...

You'd end up not hitting anything on a player well versed in scripting his client. And you wouldn't necessarily know it was scripting, either, because the responses can be delayed and sent one character at a time, just like a real persons response.

Not all the attacks will go thru.

Some will go like this:

* Liko begins a low motion sweep....
then maybe 2 seconds later or even at 2.9
* Liko begins a right handed punch..

If they trigger triggers on the low there is a 2 second delay before they can parry/block again.

If I, as a player, react to the low motion sweep (manually), I too will be screwed over by that two-second rule on the next attack.

Anything you can do (as a player), the client can do for you. Quicker, too. But you cannot design your combat system around responses unless you also acknowledge that both human and scripted players will be reacting.

thomas wrote: If I, as a player, react to the low motion sweep (manually), I too will be screwed over by that two-second rule on the next attack.

Anything you can do (as a player), the client can do for you. Quicker, too. But you cannot design your combat system around responses unless you also acknowledge that both human and scripted players will be reacting.

And if there is no delay, players can just spam parry low(or whatever the block is)