If I were you... I'd make the reactions state dependant, not depending on animation cycles, it gives you too much borders.

The deterministic finite automaton principle.

Just let em check what the other one is doing, I had such a System once, it worked so well, that the to opponents were not able to hit each other.

Depending on how much time was left they used blocking or a vertical hit to slash away a horizontal strinke and the other way round:

Ok this is a screen for a bug, I created an endless loop for creating block-spark-particle-whatever-stuff, but as you can see, the left dummy holds his weapon in defence mode, the right one attacked.
The colors are already set back to normal, a defender should be green, an attacker red:


Here's another one, the red one is the attacking dummy, the blue one reacts with a vertical strike to beat away the horizonal attack slash:



No collision detection at all, just checking states, speed and attack progress.

" it worked so well, that the to opponents were not able to hit each other."

LOOOOOL!
that'd be great... a game where you can't hit each other because your fighting and blocking skills are perfect ... I think those ppl would all turn into pazifist pretty soon, getting tired of fighting ^^

I'd very much like to see a demo of both your projects... if possible...
The approach you're doing, Shore, does not leave as much room for the user's skill though.. if your block is always the right one. What I'd do is combining the two. Checking the state rather than collision detection can be a lot easier but maybe look unrealistic. (you need to stop the animation at exactly the right time, right? and how does it work if the two don't stand exactly infront of each other? That wouldn't work at all)...
For example: if you atttack from behind, and you use attack animation 1, the opponent uses block animation 1 that corresponds to attack animation 1, but he's facing the other way, so your sword stops in mid air because he blocked in the other direction? Maybe checking state to determine the reaction and then preforming collision detection to see if the reaction was any use at all would work together better??

A lot of really good points in these last two posts!

Shore - I have thought about doing something like that, I even have states for the different attacks/blocks already set up. You said that you check attack progress - doesn't that mean the animation percent?

Germanunkol is right though, there's less skill involved this way and it looks less realistic. Right now, I can detect the exact moment that the swords touch, then place the particle effect there and play the block sound. I can put in different swords with different sizes and shapes and it will still work. If the player blocks a second too late and his sword doesn't quite make it in time, he will still get hit...it feels very responsive.

The direction they face is also an issue. In my system, I lock the two combatants in place, but that's because I want to make people use the block moves instead of just running away from the enemy and then running in to attack real quick, and running away again.

@Germanunkol

First of all you have to create a -perfect working AI-.

THEN you can build in skill dependet weakness!

Play Soul Calibur (I or II) in sparing mode and set your opponent to -full block- and you'll see what I'm speaking about.

Zelek this is a good base "system" so far. Unfortunately the animations are incredibly important and the current animations in the models detract from the system. Even though the base system is good, the animations are stilted, which show the obvious "switching out of states" in the entities. But this of course is not as important as the fighting system itself.

Maybe when you are working on the A.I, you can add in more movement. Strafing left and right, backing up and advancing. Right now they are rockem sockem robots staying in place exchanging blows (like a japenese RPG). This movment adds a whole dimension to the sword fight, which can be seen in 3d fighting games where characters can sidestep (totally dodging an incoming attack other than jumping). So instead of just blocking the incoming slash, you can add a simple random to switch to different states:

1. AI sees player swinging his sword
2. AI chooses a random number between 1 and 100:

a.If the number is greater than 50, go to the blocking state
b.If the number is less than 50, go to the sidestep state

This simple setup can produce some pretty decent dynamics even though it is eventually predictable. Whats also cool about it is that you can plugin numbers that define the AI combat personality. For example you can plugin an AI to have a 60 "dodge rating". If the number is lesser than 60 then the AI dodges. Since there is a greater chance for the number to be less than 60 (out of 100), this makes the AI more defensive. Lower the 60 rating and the AI has more chances to choose higher than 60, making him a more offensive character.

I got sidetracked there, but more movement is needed. When you add this, a new avenue of strategy comes into play. Hitting the side of an enemy can produce more damage, attacking after a dodge reduces damage output, having a back to the wall prevents teaming up by multiple enemies, 2 handed weapons impair movement but inflict more damage etc etc.

Sry, ShoreVietnam... I know.
I just imagined two players hitting each other for the rest of eternity, sort of like two paladins in WOW, where they heal themselves and block the other...
just sounded funny^^

man i cant wait for a tutorial from you guys....well actually I'm just getting into gaming development and no pretty much nothing about coding. If you guys could recommend any books for me or other tutorials that are online that would be great.

just wondering, are you going to release a tutorial for this?

please tell me, someone is going to post a tutorial or a code for this, please?

Hey Blink, sorry I never put together a tutorial for this. I really appreciated your interest and comments while I was working on it though. But when I took a step back and looked at the code that I had developed, it wasn't really good enough to be the basis of a tutorial.

I ran into several issues:
1) The responsiveness of the combat is highly dependent on framerate. Basically, I am doing scans from the top of the sword to its handle, and analyzing what I detect - if it's the enemy player model, it means I hit him, if it's his sword, it means he blocked.

Unfortunately, if someone with a slower computer tries to fight, they will notice that sometimes their hits don't register, because of low framerate.

2) The swords are separate models from the players, so that I can distinguish between contact with the sword and contact with the enemy player. This means I have to attach the sword via code. I had a lot of trouble making the sword movement look good, because it doesn't know how to tilt with the player's hand unless I tell it. What I probably should have done is give the sword its own set of animations that correspond to the movement of the player's arm/hand.

3) The combat isn't very flexible. As you can see from the video, it's dependent on the players being in a locked position to simplify the code. That's just lazy, looks terrible, and a lot less fun.

I may very well revisit this in the near future and if it's ever worthy enough to make a tutorial I'll do my best to make it happen. For now, definitely check out some of the already existing combat tutorials. The concepts are easily applied to sword fighting.