Hello and welcome back to our Developer Blog. This weeks blog has once again been slightly delayed due to some technical difficulties. In this blog we are going to talk about the melee system in BCoF. By the way, we have just created a new Discord Server
! You can now talk to us directly about the game there.
Before we go into more detail we would like to note that our melee system is currently still in its infant stages and that we will continue work on it until and after release of the game.
That being said the melee system in Battle Cry of Freedom is designed to closely resemble that of our previous game, while still applying its own touch and features. The core controls are still the same. The player can choose from 1 of 4 swing/block directions, attack with the left mouse button and block incoming strikes with the right.
We have tried to give additional feedback to players about the actions they perform. For example, all animations have been designed to look as distinct from one another as possible. This is not always the most realistic, but it will help players to react faster. Additionally, instead of simply continuing the strike animation and playing a sound, we have coded a system that “bounces” the attackers weapon back when blocked by an opponent. A successful block will also spawn a clearly distinguishable sound and particle effect, based on what weapon types collided.
Talking about bouncing, melee weapons can not strike through objects or several players at once. If a player hits a object, he will bounce off it. When bouncing, the weapon will not deal damage to anyone behind the object. This goes for the ground as well as any other object in the game including other weapons.
However, just like our bullet system, some objects are thin enough/soft enough for weapons to strike through and hit the opponent hiding behind. For example bushes and windows will not protect the player from a melee attack.
All melee weapons can deal damage to objects and will eventually destroy them. We have a built in modifier that can control which weapons deal more or less damage, per object. For example, swords deal much less damage to wooden fences than axes.
Some objects, like large windows, will allow the player to vault through after destruction. And yes, we have to fix that fists can break windows and the player does a flip when vaulting… But it looked so funny.
You might wonder what that animation above is. We have added a “Push” action, that replaces the kick in Napoleonic Wars. It can be countered by counter-pushing at the same time. Pushing will stun the opponent for a short time and deal a little bit of blunt damage. Players that are in shooting-mode and get pushed will fall over and have to recover. We have not yet decided whether or not we want pushing to be aimable.
Melee for muskets has changed slightly. We added the ability to fix and unfix bayonets as seen in our previous Blog
about the shooting mechanics and bullet system.
A bayoneted musket has 2 swing directions, but a musket without bayonet has 4. If the player unfixes a bayonet, the bayonet will appear in the players inventory and can be used like a sword or knife. To fix bayonets, the player will need the right bayonet in his inventory. Obviously a musket without bayonet fixed will only deal blunt damage.
We have programmed a chambering system just like the one in Napoleonic Wars. Obviously timings are currently slightly different so players used to Napoleonic Wars will have to get used to the new timings. Chambers work just like you would expect, they allow the defending player to counter the attackers strike with a counter swing of the same attack direction.
Feinting is making a comeback in Battle Cry of Freedom too. However, we made feinting look much smoother and react better. In Napoleonic Wars, when feinting the player would start playing the blocking animation for a very short time, which would look very strange. In BCoF, this is all smooth. An attack that has been released can only be canceled in the first 0.15 seconds of the swing animation. After that, the swing has reached a to great velocity to stop it.
We have programmed our own advanced inverse kinematic system that allow players to aim up and down with their melee weapons. Once an attack is released, the player can continue aiming it. In many cases, this can be very useful. For example, the player can start an up-swing at an 85 degree angle, but end up stabbing the floor.
And lastly, we have limited the turning speed of the player to a fairly low level to avoid extreme spin-stabbing. However, it is not completely impossible to spin-stab. It just requires slightly more skill.
Our damage system in the game is shared by the bullet and melee weapons. It applies to both players and objects on the map. As such, we have the exact same set of features available on both. The damage dealt by weapons is based on a weapon multiplier. By default each weapon can do different amount of damage. A weapon multiplier is then applied on an per object basis. For example, we can make Object 1 take +200% damage from axes and -20% from Swords.
Additionally, swing speeds and distance to the target can modify the damage dealt. If a player is to close to his opponent he might not deal much or any damage at all. Pushing works at any distance and this is where it will come in handy…
Weapons will also do more/less damage depending on what region of the body the weapon has struck. The player is currently divided into several “damage-zones” each with their own multiplier. Zones are: Leg (Left, Right) Foot (Left, Right) Arm (Left, Right), Head, Upper Body (Left, Right, Front, Back), Lower Body (Left, Right, Front, Back).
We can modify these multipliers per player. So if for example, a player is wearing a thick backpack, we can change the damage multiplier of the upper body backside from 1 to 0.7 and therefore deal less damage when hit in this specific body part.
Technical stuff and modifying the melee system
One of the main reasons it has taken so long to get the game in a playable state are animations. Unlike many other games out there, we can not simply go on the Unity Asset Store and buy animations that fit our game. There simply are none available. Pretty much every single animation has to be done by hand, which is extremely expensive and time consuming, especially for such a small indie studio as us. We also had to design an animation controller that is versatile and sturdy enough to handle all the different stances our players can be in. Below is a picture of the controller of just one of the 4 layers of just one of the weapons.
We wanted our controller to be able to handle both upper and lower body animations at the same time, and blend between them seamlessly. However, this is not as easy as it seems, as Unity is not the best engine for such a task. In the beginning it would bug out and fling weapons around like crazy, face the upper body of the player in the wrong direction etc.
An easy solution to that problem would be to “simply” make animations for each combined upper/lower body animation. For example we would create an animation for aiming while standing still, but also one for aiming while moving forward, one for aiming while moving sideways etc.
Other games in our genre have done exactly that and have had success with it. But sadly this was not a solution for us because we wanted to be able to control the speed/timing of our melee animations independently from their walking animations.
To solve this problem we have spent a lot of time creating our own custom Inverse Kinematics solution that takes almost no performance, works with any animation, any animation speed and on both server and client seamlessly. The new system allows us to change the timing of an animation in less than 15 minutes and will come in very handy once we start testing the game with more experienced players than ourselves. In theory we could even make it adjustable from the server settings…
Our intent is to extensively use this system during the testing phase of our game. We are sure that melee will need A LOT of little tweaks and that we will go through dozens of iterations of melee combat. This is the reason we need such a system in the first place. Without it, creating a great melee system would take much longer and would be much more difficult.
Thank you for reading this weeks Blog. With the holiday season coming up, we will not post the next Developer Blog for a few weeks. In the meantime, have a Merry Christmas and a great start in to the New Year. We will see you then!
Flying Squirrel Entertainment
Join the discussion of this blog here.