This melee system combines elements from systems used in Rune and the Jedi Knight games. It was designed to use custom melee attack animations, combined with custom weapons, to give the user a better sense of melee combat while viewing and playing in the 3rd person mode. It is not a replacement of either the Rune or the JK system, nor is it perfect. It is however a decent system that offers many enhancements to the old melee combat of ChaosUT. 

The melee system can be broken up into basic parts:

Weapons - All weapons have bones place in them along the "edge/end" of the weapon. The code uses these bones to figure out when/what you hit. Bone placement and size of the weapon will effect the area the weapon can strike. All of the work of the weapon code is done in the attachment class. This is were the weapon is drawn and where hits/bock detection is done. All the main weapon file does is spawn the proper weapon attachment and attach it to the players hand. 

Animations - There were no default player animations in UT2003 for melee combat. Thus all had to be custom made. The animations will determine where the weapon is during the swing. We have one handed and two handed animations as well as special animations (for example dual daggers).

Stances/Attack Style - A player will have 3 basic stances or styles of attack. Strong, medium and light. Light will be faster attacks doing less damage. Strong attacks are slower, causing more damage. Medium is in the middle.

Attacks - When a player wants to attack they hit their primary fire button. Then the code looks at the players physics, movement and the player stance. Then based of those factors it will play a certain animations and this will be the attack a player launches. For example a Strong stance, moving forward and jumping in the air would play the massive over the head, two handed, full downward swing. Vrs a light stance, backing up where you do a short thrust to keep the other player away. 

At the start of every cycle (or tracing) the first thing the code does is look for a block. The code looks at your weapon's bones and then compares them to any player that is "close". If a player is close enough, it looks at the player's weapon attachment bones: 

If your weapon attachment bones are close enough to that players weapon attachment bones, then we say that's a block, spawn some sparks for visual effect, and the swing stops with no more cycles/traces. Note you could hit a body during one cycle then on the next get a block so it is possible to get a block at anytime during the swing.  

If your weapon attachment bones are not close enough to that players weapon attachment bones, the swing is not blocked, and it continues to see if you hit anything else during that check. 

In order for a hit to occurr something must cross between the weapon bones so the trace can find it. Note each weapon has its own bone location and trace order that optimizes the trace area so not all weapons are equal (ie the hammer has a different trace pattern that a sword does). When an object does cross the trace the code then looks to see what it is. 

If its a wall we spawn a wall hit effect and then stop. 

If its a projectile then we call that projectiles "processtouch" and let the projectile code deal with it. 

If its a player then we give that player damage in that cycle. Note a player can be hit by again in the next cycle. The code is smart enough to keep track of what it hits during each cycle of the swing. Only pawns are allowed to be hit more than once in any swing.

Alt Fire - This is set to play a blocking animations much like the attack. Here since we only have 5 ATM we only really look at movement and stance. Then all the block animations do is move the weapon. Again all blocking is done by the other weapon that is attacking you - so the basic idea here is to get your weapon in their way! If you do, its usually a block.

There are only 5 things I would consider limitations:

Limited moves. As I said before when we attack the code looks at the players physics, movement and the player stance. We did not look at every combination as that would give us over 36 possible style of attacks per weapon!!! We could have that many attacks but we don't due to lack of animations and complexity. For example the Swords only have 11 unique animations that they play so some combinations give you the same style of attack. Thus don't expect every attack to be unique. We can add more once we have the animations.

Animation rates. For some reason we can only play the animation at a rate of 1.0. Not sure if this is our code or another limiation. but for now all attacks play at the same rate of 1.0

Blocks are not an exact science. The vector math to do all of the exact position in a bear so we went with this simpler method. If the code has a weaker point this is it. The goal is to get the distance the weapon bones are apart to be close enough that it looks to be a block. I think we have a good balance. Make the distance any smaller and you get fewer blocks. Make it any bigger and then you get blocks that don't look to be close to being real.

Bone placement in the weapons is optimized version. The more bones the better we can cover a weapon. However the more work we have to do during each cycle and the worse it impacts our performance. We keep all weapons to under 6 bones. Swords have 2, single axe has 4, bigger axe/hammer/mace has 6. This means that part of the weapon model could impact the player with out it being a hit. However most bones are placed at the edge so it would be very hard to see this. Most of the time this is a non issue.

Replication. We have to use Epic method of replication of the animations. Also Epic does not update bone positions on the server so we do all of the updates at the start of each cycle during the swing. This is not ideal but something we have to live with. Note we do this for both blocking and attacking players.