ChaosUT2: Melee 101
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.
Hitting/Damage/Blocking Once when code figures out which animation to play (thus your style of attack) it plays that animation. The players animation moves the weapon and the weapon attachment since its attached to the players arm. So were the arm goes, the weapon goes. While its being swung the weapon also starts to trace between the bones in the weapon attachment model. All swings last one second and we trace 20 times during that swing or every .05 second. Thus we have 20 times we could hit possible hit something. We use a timer to track this to make sure server/client is synced. That was the light version, let me break it down to the nitty gritty. Here is what happens during each cycle (remember 20 of them per swing):
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 occur 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.
What does this system gives us (advantages)
– Much more control and realism with no randomness. Other methods for melee just traced out X units in front of you to see if you hit something. We did the same in CUT. Now we can attack a part of the enemy that we want to.
– Better blocking. While not ideal it still takes some skill and timing to get your weapon in a position to block. Other methods were random (like our old CUT).
– Different levels of attack and attack animations. Two handed over the head swings, one handed jab, trust, act all based off player controls.
– Different damage during the attack. We have a glancing blow were the weapon only hits the player once during a swing. Then we could have it were the weapon hits many times during a swing. Thus we can have a nick vs. a fatal blow.
– Different weapons add to different styles of fighting.
– Looks and feels cool! Hey it just does!
Nicely written entirely by Jb
Slightly edited by R.Flagg