Overhauled IK Combat & Design

After six months of solo development, there’s a lot to cover beyond just the combat system. I’ll go over the various improvements to the combat, code, and designs that have shaped Blade Ballad into a more refined experience.

Combat v2

Procedural inverse kinematics continues to be a defining feature of this combat system, but the movements and controls have improved a lot since the last version.

Comparing inverse kinematics with other procedural systems

But why did I use inverse kinematics? Why not a physics driven combat system, or something with only keyframed animations? Because inverse kinematics serve as a bridge between these two systems: Allowing me to animate some parts but then letting IK figure out the rest.

Upcoming titles like Kinstrife or Half Sword uses a physics driven approach for combat system, and I see several downsides to this. First, computing physics is resource intensive on the CPU: When a physics object moves, it needs to calculate collisions, velocity, angular velocity, drag, mass etc per tick, then you have to apply all those physics calculations on every single bone of your character and suddenly it’s taking up 80% of your processing power just to move. This computation demand makes it prohibitively expensive to scale NPC count, and I saw this in action when playing Half Sword, where just a small scene of 4 NPCs kicked up my computer fan into double time. Another rather ironic issue is that it lowers realism. You would think that something controlled by physics would be more realistic, yet in practice, makes movements appear sluggish and cartoonish. Controlling a physics driven character is like trying to control a drunk: Telling it to go to one direction will result in a delayed response where the character first needs to slow down its momentum, then whiplash into the other direction. Early Kinstrife devlogs had characters which wobbled and flailed around while fighting, which looked pretty realistic if those characters were completely plastered, but I don’t think that was the intention. Ultimately, physics driven characters are simply not responsive, so you spend more time trying to fight against your own character than its opponents. It’s good for simulating movement in a wacky & uncontrolled manner, like Fall Guys or Gang Beasts, but not so much for realistic & precise melee combat.

On the other hand, a keyframed driven approach is boring and repetitive, even with all the special effects and particles in the world (Calling out every single MMO/RPG/MMORPG for this). No one is going to blown away by having the same animation or set of animations replay each time they attack, no matter how flashy. I’d say Dark Souls is an outlier, but their attack animations are not really the focus of the game, but rather the dodging and the timing.

So I chose inverse kinematics not just for its performance advantages over physics, but also because it allows for dynamic, real-time character animation without needing extensive pre-made animation sets, that provides accurate and precise input responses.

Dynamic Panning

The heavy swing mechanic was removed because it required holding down the mouse for a certain period of time, slowing down combat, so it was integrated with the weapon panning mechanic, making swordplay more reactive. Essentially, the further you pan your blade from the center, the more it represents a heavy attack, with increased speed and damage.

In prior versions, the only thing that moved while panning was the weapon position, which looked very stiff and constrained, but panning now influences your IK rig, as well as blade rotation and pitch, which is dynamically calculated based on where you panned your weapon.

Flipped Swings

Another mechanic, which I think was the missing piece for fluid sword combat, is what is referred to as flipped swings. Attacks from the edge of the screen with the tip of the blade pointed inwards make the swing flip around to the other direction along with your chevron crosshair, which you can see demonstrated in the video below.

Weapon Pitch

Weapon pitch also received a change where panning up and down will not pitch the weapon, but you must also look at the angle at which it is panned to. This plays an important role in combat and not just for cosmetic purposes, as pitching the sword up or down allows you to strike at targets at varying elevations.

Target Locking

Target locking is revamped to be a hybrid between the old locking system that was in place, which was a choice between hard lock, which locked you to a target by a key press, and soft lock, which is holding down the right mouse over the target, and unlocked by releasing that mouse. Instead, you would first lock into a target by holding both the lock key (Left Alt) and the right mouse, then unlock by releasing the right mouse. This solved the conflict between wanting to pan your weapon, which is also the right mouse, and not locking to a target.

Angle Based Armor

A new armor system has been implemented for better performance and consistency. Instead of adding a separate collider for each armor piece, the body part’s existing collider now doubles as armor based on the angle of impact. Each bone has a capsule collider, and if it’s protected by armor, that armor is given a specific protection range, providing protection when hit within it. It does this by calculating the dot product of the collision point and the capsule center then its cross product, and that angle will be used to check if its within this range.

The end result is some pretty realistic combat scenarios, at least in behavior. Metal plate armor won’t just reduce damage but completely deflect it, requiring you to strike precisely at unarmored areas.

Continous Damage

Damage is calculated based on the OnCollisionStay() rather than OnCollisionEnter(). This means that as long as your blade swing is within a body part, it will cause damage for every few frames that it is in. A small cut to the side of your torso wouldn’t do the same amount of damage as when you are sliced across your entire upper body.

Modeling

Character

Finally moved away from the blocky looking character design in the last version, which I had intended as the model was only to serve as a visual reference for the humanoid rig. Now the character model has a face with eyes, mouths, fingers and toes, fully rigged and animated. The armature can also be fitted with various historically themed apparel items such as a tunic, braccae or caligae, which can unrender covered body parts to save memory.

Environment

I am still inexperienced with writing shader code. However, Unity offers a solution called Shader Graphs, which converts all these shaders into nodes that you can connect together to achieve various visual effects. It’s effectively how blender handles its procedural materials, which made it much easier to pick up.

This was extensively used in my triplanar shader materials for buildings and foundational structures. A major immersion breaker in graphics occurs when an object sticking out of the ground has a clean surface despite being placed on dirt or mud. There should be a soft transition between the two surfaces, such as sediments collecting at the base of the wall and slowly fading off as it gets higher. In the image below, you can see how the bottom of the object shares the ground material, then gradually transitions to its original material. This, along with some noising, helps break up the tiling pattern.

Coding

I have integrated many cool free and open source unity assets from the Unity Asset Store and GitHub, though I did make one purchase from MicroSplat. All of them are listed in the credits panel, but I want to delve into some particularly interesting ones.

BehaviourTreeEditor

Before discovering this asset, I hard-coded every NPC behavior, meaning I had everything in a giant class defined by enums to track current NPC behavior all running in an update method spanning over 500+ lines. While it worked, the hard-coded behavior was buggy, oversized and inflexible, so I needed a different approach.

Behavior trees (British English spells it as behaviour) are a common and robust approach on designing AI (in the context of NPC behavior, not machine learning GPTs; I had to clear up this confusion with the copyright office). I found one made by TheKiwiCoder, who you might recognize because he did a bunch of Unity programming tutorials on YouTube. It was one out of many that I experimented with, and I settled with this one because it was the only that actually worked.

As soon as you get familiar with the basic concepts of behavior trees (conditionals, compositions, decorators, and actions), you can reuse these or create your own inside of behavior tree graphs, and you can even create graphs serving as sub-graphs and use that in another behavior tree graph. The ability of NPCs to strafe and lunge is thanks to the way behavior tree nodes are organized by inherited classes rather than by enum, which has its own override methods that you can define to set your own logic and conditions on what it does and what it should return.

Polity-Manager

Polity Manager is another free Unity asset which I put together & open sourced on GitHub. It was created as an adjacent tool to use alongside the BehaviourTreeEditor. Since Blade Ballad is going to be something akin to Kenshi, with various warring and allied factions dotted throughout an open world map, I’d want NPCs to be a part of those various political factions who would react to their enemies/allies by determining their alliances through the behavior tree.

command_terminal

An older, yet very robust MIT licensed command terminal asset that lets you set the terminal style and arguments for console commands. I made some modifications to it so it always open the full terminal. Here you can create a command via a static method, and the command name would be derived from that method.

To open it, press the ` key and enter help to get a list of available commands to call.

The ‘additem’ command needs an extra string for the item’s ID, which is found in this csv.

Design

Dialogue

I am experimenting with a dialogue UI that looks more like a chatbox than a typical per response display that uses a single panel for the current dialogue then clears it for the next one as the conversation progresses, common in MMOs and RPGs. A scroll window beside the character saves every response, allowing you to review past dialogue as the conversation progresses. However, I find that this takes up too much of screen space as the dialogue becomes longer, so it’s subject to change.

Inventory

The idea behind inventory is still the same as last time: A grid based apparel linked system. I took the idea of a typical inventory grid slot approach in something like Minecraft, and combined it with an apparel linked inventory in something like DayZ. In effect, the clothing you wear determines how many things you can carry, and if you take off that piece of clothing, all the items inside it is taken off you as well.

It’s much less buggy now, since I’ve redone the entire inventory system to be serializable, and now you press R over an inventory slot to drop an item.