Killing 96 Birds with 2 stones

I’M BACK

Missed a week, but not because I was slackin. Lets get into it.

Small Feature Update

Last time we talked about all of the jump compression stuff and Alex had done a huge update to it, removing the need for individual animations on each character (yay!) This time we exposed a few more variables that he had that lets us customize it a bit further.

ooo Different Heights and Times. HOW MODULAR!

Now you can have different times that the character stays at their lowest point on a jump, based on whether or not they were walking, jogging or sprinting. Not a huge change, but one that makes all the jumps feel a lot better.

Material Updates

For materials we made a few minor fixes. Fia’s material was ignoring any part of the texture that didn’t have a color from the engine on it. Like her knives and the bottom of her boots. So now those don’t look like untextured shiny pitch black anymore.

This is after it was fixed, I forgot to get the one when it looked bad, and I cant even remember how to mess up the Master Material anymore to even see what it looked like. Trust me, its a lot better

Shold got his scarf back, now that we’re done with his skinning updates. He also had some updates to his physics asset, so he can simulate the scarf a bit better without it going through his arms and torso.

Back in Business Baby

We can now support blood decals on character after hits thanks to Alex. I went in and added the layer to all of our characters which started to push the material complexity a bit too far. Which means that I had to go in and optimize a bit to make sure that our materials don’t become too much of a burden for the engine.

It even splashes on to the attacker!

Which leads us on to…

Optimization Updates

When we make characters, we try to make them as high quality as possible, and leave optimization till later. Overall this is good, because the characters end up looking great, but also comes with that looming threat of optimization in the future that no one wants to think about.

After our last playtest and the several nights we spent rushing to optimize everything in a panic, I figured it was probably a good idea to get ahead of it this time. So Unreal has a handy feature that generates LODs for you.

What’s a LOD?

You, probably

LODs stand for Level of Detail. You’ve seen these in every game before, don’t lie to me.

LODs are those low detail models that pop in the farther you get away from something. They change the detail on the model because it assumes that you’ve gotten far enough that you shouldn’t notice a drop in detail, and it changes back to the higher quality one, the closer you get.

Its about a 70% reduction in triangles

The more levels in between, the smoother the transition.

Having these be lower quality helps the engine run faster because it has less geometry and less bones to animate, so less work overall. In addition we also needed to optimize the textures to save on memory. Memory as it turns out, is a pretty big deal. Most graphics cards don’t have a ton of memory to dish out, which means that we need to make the most out of the memory that we do have.

Most graphics card range anywhere from 2GB to 8BG of VRAM, which is a pretty big range. Meaning we need to plan for the worst and hope for the best. The closer you get to using all of your VRAM the slower your game will run. If you run out, that it slows down to an unplayable crawl and I weep bitter tears.

So, armed with that knowledge, what can we do?

Memory optimizations are a man’s passion

Albert Einstein

So we went in and found out how much memory each character was taking up, and as it turns out, each character was taking up roughly 1.2 -1.5 GB each. So that adds up concerningly quickly. So the answer it turns out is pretty simple. Unreal lets us change the LOD for each texture just like we would for a character. So that way, we don’t have to compress the source texture down. Which means that people with higher end machines would be able to use the textures at a higher resolution.

Wow, how convenient.

The way to do that is to look at each the character overall and reduce every texture down to its smallest size, and bring it back up slowly to see what the lowest resolution we can get away with is.

So doing that we ended up reducing the memory size down to about 80 MB for each enemy, and about double that for each hero at around 150-200MB.

While that doesn’t solve it completely, it does reduce the cost by roughly 80% for very little loss in quality. It can still be reduced further, but it would come at a significant loss in quality. So there’s still a bit more balancing to be done, but I do think we can squeeze out a bit more performance. Possibly with the lower quality modes.

Animation Updates

Now comes everyone’s favorite portion of the blog….

HOW MANY ANIMATIONS DID ANTHONY GET DONE THIS WEEK!

Its 96, Please stop yelling at me

A good third of these is the Sword Knight, since we needed him to test out a bunch of hit reactions.

Ouch

Shold is starting to get back up to speed with his locomotion for His Hammer + Shield and his 2-Handed Axe looking pretty good. Still need to get his Rock Armor finished though. Don’t have much of his melee done, but at least his light attacks are in there.

Hammer Updates! Getting there, slowly but surely
Axe Updates! No attacks ready yet :<

Fia had some minor cleanup to make her locomotion more smooth. She now has Light and Heavy In-Air attacks as well. Now she just needs standard heavy attacks to be all done with melee.

Most of the animations are locomotion updates for walking, jogging sprinting, etc, but I like to sprinkle in attacks just to keep it fresh.

Effects Updates

Lastly, we started porting over all of the impact effects from the last project. All of the effects were enhanced a bit to be more visible. The impact effects are all based of the type of surface you’re hitting, and the current list we support is:

  • Sand
  • Stone
  • Ice
  • Wood
  • Snow
  • Flesh (Characters)
  • Grass
  • Metal
  • Water
  • Dirt
Behold, PARTICLES

Each one spawns its own different impact effect, and its also based on your weapon type. Currently we only support, sharp and blunt weapon types, BUT we’re going to be adding more as we go.

For example, we cant use blunt or sharp effects, if you’re using a spell like a fireball. We’d need to add fire effects to any impact as well. This also lets us bundle sounds with the effect, but we’re not quite there yet.

See ya’ll next week.

Piece by Piece

Been a bit since I’ve been able to take the time to put out a blog and so much has happened.

First, our Kickstarter Campaign was successful! Super nervous about the Kickstarter not being funded because everyone on the team put in so much work to make the content shown on the Kickstarter. Rod spent a ton of time getting the Kickstarter Trailer just right even though he had to use the old build of Mortal Rite (0.5.3) with the newer content in it and that build had bad framerate issues. But that’s expected, right? Sill in development and we haven’t been able to optimize yet.

Let’s dive in to what I’ve been up to on the game itself.

Editor Time Persistence

Placer with Sword Knight, which now behaves properly.

Ran into an issue where our placers weren’t persisting our settings between edits. What would happen – sometimes – is that an edit would be made (such as rotating an enemy via placer or changing a spawn setting on the enemy via placer) and then (at runtime in editor or when the level was reloaded) the change wouldn’t take effect. So, I tracked this down to the edits not marking the placer or the enemy dirty so that the changes are persisted, figured out how to mark the needed bits as dirty, and now that all works as intended. This is one of those things that isn’t exciting and it took a while to figure out, but was necessary and now things that were already supposed to be done are now done – kind of. There is more Placer and Ai settings changes coming soon to support new gameplay that we need in the new build.

Damage Calculations

Maths

Part of our damage calculations takes target armor into account as most people would expect. The placeholder armor contribution to the damage calculations was a flat damage reduction that didn’t scale well. Example of flat damage reduction is 100 incoming damage and 20 armor would yield 80 damage. Literally Damage In – Armor = Damage Out. This doesn’t scale well because you can outpace incoming damage with armor fairly easily. There is a place for flat damage reduction, but I don’t think armor is it.

After doing some research, we now have armor calculations that can scale infinitely, takes armor penetration into account, which we didn’t have before, and scales well with target level. No specifics on how this works to keep things hush, hush for now.

Generic Ai Ability Traces

People are often curious how the Ai makes decisions. As soon as I gather my thoughts about how our Ai decides what to do to try to explain it, I kind of give up on explaining it because there is so much going on at an implementation level. So, it roughly comes down to:

  • Ai can run abilities. Abilities range from an advance ability that moves the Ai into melee range to use a melee attack to a special attack that is only used when it makes sense to be used.
  • Ai will, basically, run the ability with the highest score. Filtered abilities have a 0 score and are rejected.
  • Ai collect information from their environment about targets: range, LOS, various statuses, etc.
  • Some abilities have cooldowns.
  • Ai have a Tag Relationship Mapping between target statuses and abilities that determines which abilities it can use from a pool of abilities each time it evaluates what ability it should be using.
  • Ai can – now – also use generic traces to determine which abilities to use.

In the previous project, Ai would do a base pass on each ability to determine a if it could run an ability. It would reject abilities based on settings, such as if a target was not in line of sight and the ability needed the target to be in line of sight, the Ai would reject the ability immediately.

Old Project: Ability Logic snippet.

Old Project (Mortal Rite 0.3.x through Mortal Rite 0.5.x): Evaluate base score and filter abilities based on ability criteria in C++. If this filtration passed and there is a Blueprint implementation for the scoring function, run the Blueprint Scoring Function to get the final score of the ability. If this filtration passed and there is no Blueprint Scoring Function, use the base score as the final score.

Downsides here were having to kick out to a Blueprint function to get a final score. This was actually used quite a bit in order to get final scores. It was convenient because Blueprints are convenient, but Blueprints have a higher overhead compared to C++, and it was generally hard to maintain. Each ability ended up having its own Blueprint Scoring Function implementation and while there were some that were similar to each other so you could copy and paste between abilities, most were unique implementations with completely unique logic.

One of the most important things done in the Blueprint Score Function in the old project was tracing to determine if an ability should be used (not LOS. LOS is part of an earlier check). A lot of the Ai use abilities that can damage a specific area or need to know if it will be able to damage one or more targets if used. Example of this is you have an ability like the Sword Knight Explode Ability where if the Sword Knight felt overwhelmed he would use explosion to push everyone back and recover. One of the deciding factors to use this ability is if one or more targets is within the range of his explosion. If there is nothing within range, he should not use the ability even if he feels overwhelmed. Intelligent.

Ai Ability Trace Configuration UI

New Project (Mortal Rite 0.6.x+): Filter using Tag Relationship Mapping, score based on criteria, if there are traces configured run the traces. If a trace fails the ability cannot be run. If all traces succeed, the ability score is returned so that this ability can be sorted.

New Project: Ability Logic snippet – Failure during one of the configured traces.
New Project: Ability Logic Snippet – Traces succeeded.

Currently, I have 100% of all Ai ability decision making in C++.

The goal is to allow everything that was being done in Blueprints in a non-reusable way to be done in C++ via configuration in a reusable way.

So, what happens when this is all put together? Let’s find out.

Test Scenario

Explode Ability – Test Scenario Trace Configuration

Sword Knight that is setup to acquire targets and then can only use his Explode Ability. The Explode ability is setup to be used whenever a sphere trace in front of the Sword Knight (X: 200, Y: 0, Z: 0 relative to the Sword Knight’s forward vector) is triggered with a hostile Pawn (in this case it’s me as Dawksin).

Sword Knight – Ability Trace Test with Debugging

Rounding out Dawksin

This week was all about adding some finishing touches to Dawksin

Some of the not-so-exciting things were some general bugfixes:

  • Pierce projectiles sometimes lingered around forever.
  • When leaving your grapple state, Dawksin would play a jump start animation instead of falling.

On the slightly more exciting side, we continued iterating on the grappling hook to make it feel better to use.

You can control your direction while grappling more towards the beginning of the move, and as you get closer to your destination you get less control.

He also tilts in the direction he’s moving

With the new addition of him tilting to match his velocity we figured his animation could look a little better, so we went ahead and updated that, and made it so you kick off the wall automatically.

so smooth!

Reticles

Next up was tackling the reticle for the grappling hook.

If you tap to activate grapple, you can target enemies, whereas if you hold to activate grapple, you grapple to terrain.

Since these are two different abilities smashed into one, we needed to communicate when you can activate either one, so we updated the HUD to accept multiples reticles per ability.

This let’s us do some fancy stuff. 😀

I’ve increase the size of the reticle so we can see what’s happening.

  • So now as you move over enemies you can see that they are within grapple distance.
  • If you move over terrain it highlights in yellow
  • And as you get closer, you can see they are within Pierce’s distance
oh my!, clarity.

Icons

I also started updating icons with more final art, and updated them to show how what state the ability is in.

Now during an ability we can say things like: This ability is ACTIVE! or you can RE-CAST this ability! or This ability is unavailable, or on cooldown, etc.


Stowing/Sheathing

Since we gave Dawksin a new state where he can sheathe his weapons, we started experimenting around with how this would work.

Initially we tried something like this where he would periodically sheathe his blades, and this little indicator would let you know when it was going to happen.

This wasn’t great though since it ended up being pretty distracting. It would also prevent you from doing any abilities while this was happening which didn’t feel very good.

So the next approach was to have him automatically stow his weapons when he performs an ability, which ended up not only feeling less intrusive, it also gives the player a chance to control when this happens.

The whole point of this anyway was to give Dawksin a damage boost when his weapons are sheathed so he get’s a little more upfront damage since his overall damage is low because he has so much power packed into his Recall ability.

Ability -> Sheathe -> Damage Boost

And finally to support this, I added a simple way to mark certain frames in our animations as either charge attacks, or empowered attacks, and they’ll reference a handy little table to lookup what kind of damage boost you get.

And that’s about all I had time for this week.

Oh also this week was the end of our kickstarter, and we made the goal!

We can’t thank everyone enough for helping us out, and we’ll keep doing our best to make sure y’all get a cool game :>

See y’all next week

A grapple a day

Since the last time I posted, we had a bunch of little small things fixed.

This time I got to finish working on pierce. Since the last time I talked about pierce, I noticed that there were some issues with it when it came to networking.

Because the game is going to be peer to peer, we need to make sure you’re projectiles still fly nice even while someone is ripping out your ethernet cord, or carefully constructing a faraday cage around your WiFi receiver.

The main thing that prompted this review of Pierce was some errors I was getting when testing networked.

That really handy target data I talked about before, didn’t like being replicated and was causing memory issues.

oh no

So I did what I normally do in these situations:

Let’s re-write the part of the engine that’s giving me trouble!

Me (with too much enthusiasm)

So just like melee, we ask the client for where they want to throw the projectile (and have the server validate that they don’t want to actually start the projectile in Antarctica), and then figure out where it needs to go on the server.

From there I made a handy little struct that acts like the TargetData that was misbehaving, and I tell it where it needs to travel to.

(but since this one is mine, and not Epic’s, I’m not allowing it to misbehave)
Nice

To wrap that up we are also re-using the projectiles so it’s only a little expensive the first time you use Pierce. Any other casts will re-use the projectile you already spawned and the response will be buttery smooth.

I then went ahead and finished part 2 of Pierce, the Hold version.
This one didn’t take as long as the main part was figuring out how to stagger the spawning, and re-use the projectiles, but yeah!


Jump Compression

Up next there was some weirdness happening anytime characters jumped, their feet would go through the floor, which was giving Anthony some headaches.

I figured I could tackle this in a procedural way.

We’re already using an IK Control Rig to adjust characters feet so they don’t clip through the environment, so instead of what we were doing (applying an additive compression animation) I figured we could just push up and down on their pelvis control which should mimic a little bounce from landing.

Kinda like that

So after setting up a little event detection in the animation blueprint, we can control how much each character recovers from a landing whether they’re walking, jogging, or sprinting.

the logic. Very hush hush.
In action

Grappling

Now for the main event, grappling.

In our last public build we had quite a few networking issues with Dawksin’s grappling hook, and this was the time to address it.

The ability logic was supposed to keep track of:

  • Launching the hook
  • Detect the hook landing
  • Reeling you in
  • Allow detaching mid-air
  • Allow Some control while moving

and the movement logic itself was also handling keeping track of:

  • Your location
  • Where the hook location was
  • How much control you get while moving
  • Self-Cancelling when you let go
the old functionality was um…. large.

It was fairly complex, and not easy to debug.

So this time we started fresh and said, ok let’s revisit what tools the engine has to do this. Turns out if we flip a few flags with our movement component, and tweak some of their movement tasks, we could make the hook a little easier to debug, and perform better under bad network conditions.

This is the big ol’ task I ended up repurposing. It looks a little imposing, but it has all the knobs and levers we need to adjust the hook.

oh, that’s a big function

If we take a look here, you can see the positions being calculated and interpolated to get you the control you want, while still moving towards the hook.

The nice thing about this is we should be able to hook onto moving targets!
But that’s for later.

And that about wraps up this week. See y’all in the next one

You Simply Can’t Rush Art

Howdy, its been a little bit. Over the past two weeks we got a bunch of small fixes done, but there wasn’t really anything significant to show or if there were a ton of small things done, there weren’t really good ways to show it.

Progress Report


GENERAL UPDATES

Dodging

The dodge ability was updated to allow each character to have their own dodge distance and duration. Before we thought it would be great to have a single dodge ability, and have everyone be equal for distance and time.

So then it turns out that was a really bad idea, because most of our characters are vastly different sizes. So uh, lets change that.

Behold, I present to thee… Settings!

So now each character can have their own distances for rolling while not locked on, and dashing while locked on. Regardless of whether its a dash or a roll , you can customize the distance of the initial burst of speed for the dodge, and then the sliding to a stop that they do afterwards.

Jump Compression

I had a whole thing written here about how we fixed the jump compression that was really wonky and having people’s feet go through the floor anytime they landed, BUT it turns out what we thought was going to work, ended up making them do the opposite.

Avert thine eyes

Now their feet hover instead, which is slightly better, but we’re gonna go back to the drawing board on this one.

Animation Blending

There was a small problem that we weren’t able to figure out for a while, where if you started or stopped walking, your characters legs would fly out in front of them for a split second.

I actually don’t have a video of it being horrible, so instead enjoy this smooth walk cycle that doesn’t do anything weird. HOW RELAXING!

This seemed really weird until we started looking into the jump compression stuff. Lo and behold, by default the character thought they were always sprinting. So anytime we start or stop walking, when they’re trying to figure out if they should blend into their idle animation, they started sprinting for a moment.

Not a huge bug, but one that did have us stumped for a while.

Orientation Blending

When you lock on to an enemy, your character plays new locomotion sets for walks and jogs. Typically we just had to make Forward, Left, Right, and Back. The animation system would blend these together to let you walk in the in-betweens, so diagonally in any direction.

The animations ended up not being able to blend very well if you switched your overall direction from forward to backwards. This would only happen if you’re walking forwards-right/left and switch to backwards-right/left. Going from forwards straight to backwards was fine. Its mainly visible if you’re locked on and moving around an enemy. As we should do, because the enemies are tall and imposing.

When you’re walking left and right and then moving forwards and backwards, you now have a new animation to blend with. Its not perfect, but it looks a lot better than before

So the solution here was to add two more animations ( two for walk and two for jog), that are front-facing. The standard Left and Right animations basically assumed that you were walking backwards before, so that made it impossible to blend nicely from the front.

Its more animations for each character, but it does help them look a bit less jarring when changing directions.

SHOLD UPDATES

Shold got a new IK Rig that let us begin porting over all of his old animations.
This gets us 90% of the way with his animations, except that it didn’t quite fix up everything it should have.

His Sholderpad (get it? SHOLDerpad) is down to his thigh and his weapon is hovering ominously below his hand.
Truly a tribute to the strength of his sheer will to destroy his enemies.

This means we get to go ahead and fix this manually for 290 animations. Yay.

FIA UPDATES

Model Updates

Fia had some skinning issues where her shirt was clipping through the decorative neck brace and the brace wasn’t staying intact when her head moved.

Ignore the ugly colors, focus on the immaculate skinning corrections

That was stopping us from moving her head and neck at all during any animation, so it was a good time to fix it.

Added in Fia’s dagger as well, so she can stop using the default ritual dagger.

How Fancy

That Dagger looks as long as a sword

Shhhhhh

Completely ignoring the fact that I like to oversize all weapons, its important for weapons to be a bit longer than you’d typically expect, to make sure they they actually have a chance to hit the enemies.

Even the hitboxes for them are oversized to an extent, to make sure that it hits when you expect it to, instead of missing by an inch or two and feeling like you got cheated.

Animation Updates

Oh baby, we finally have some custom animations for Fia. Started things off with new locomotion animations for walks, jogs, sprints, jumps, and turn in place. She finally animates differently than the initiate.

Behold she no longer slouches like that bandaged weirdo

In addition, got her melee attacks finished as well. Typically characters have somewhere between 3-4 attacks for their melee combo, but Fia is all about attacking as much as she can to lower the cast time on her spells. More hits = faster spell casts, so uh, I gave her 11 attacks.

The more you flip your knife, the deadlier you are

The Initiate has 4 attacks, Dawksin has 7, and now Fia has the most. Still might need to play around with this number, and possibly the timings, but it feels pretty good at the moment.

Wait, can you even chain that many hits in a row without getting interrupted?

I highly doubt it, but wouldn’t it be cool?

Look, the important thing here, is that I got excited about making attacks and they’re already done. Relax.

Also since she’s meant to be really flashy in combat, she does knife flips all the time. This was actually a bit challenging , since each animation had to know the orientation of the knife from the previous one, but I think it came out pretty neat and it helps sell her persona.

Still have to work on her heavy attacks and whatnot, but that should be done pretty quick. Next update shouldn’t be delayed.

See ya’ll next week.

They have six eyes, bro.

During the SparkInSpace interview (starting at 2:03:00 in the VOD), Spark reminisced about experiencing how good the Ai is during the Mortal Rite Playtest and Demo.

Clip with sound from the SparkInSpace interview.

In Mortal Rite, we have Ai that ranges from fodder enemies that are only difficult when in large number to Ai that, one on one, are supposed to be as challenging as fighting against another player.

In previous talks with Spark, he pointed out that fighting against the Sword Knight is like fighting against a real player in PVP. The Sword Knight will parry, dodge, retreat, do combos, etc. Spark didn’t realize how deep the Sword Knight Ai went until he spent a while fighting it in the arena.

Sword Knight

In the future, I will take the time to go deep into how the Ai works because we’ve put a lot of work in it and it would be cool to do that. But today I am going to go through making the Sword Knight Dodge work in the new project.

One of the rules for the new project is that anytime we can make an ability (everything is an ability: jump, dodge, attacks, etc.) work for both the player and an enemy, we should. This keeps everything simpler than it would have been and means that if there is a problem with an ability not working, and we fix it for the player, it would also be fixed for the enemies. In the previous Mortal Rite project, we had specific Ai Abilities that players could not use and we ran into issues where we’d have to fix issues in both places. Not great.

The Goal

  1. Allow the Ai to determine which way to dodge based on obstacles in the world including other enemies, players and structures.
  2. Be able to control which way a specific Ai can dodge. The Sword Knight specifically wants to dodge away from its target (backwards, back left, or back right) while the Axe Knight wants to dash towards its target (forward left, forward right).
  3. Build this functionality into the dodge ability that the player uses so that we can use the same dodge functionality and systems for both the player and the Ai.

#1 – Which direction to dodge

Translate dodge direction and current location into cardinal direction.

The player uses current acceleration in order to determine which way to dodge. The player’s current acceleration is provided by the controller input(s) that the player is making. We don’t have that from the Ai. The dodge ability uses GetCardinalDirectionFromTransformAndDirection() to translates the player’s current location and current acceleration (in the form of Dodge Direction) into a cardinal direction: North, Northeast, East, Southeast, South, Southwest, West, Northwest. Basically, 8 directions. The player will need to choose which way they dodge using their controller input and then the dodge ability picks up on that while the Ai needs to choose a direction, translate that into the same cardinal direction, and then use the same player dodge logic.

The way we chose to implement this for the Ai is to have the same dodge ability run an Environmental Query via Unreal Engine’s Environmental Query System.

EQS_Q_Dodge Query


The EQS_Q_Dodge query simply does the following:

  1. Generate a circle with 8 points (one for each of the cardinal directions) evenly spaced around the Ai with a radius equal to the distance that the Ai can dodge.
  2. Test for the points being pathable so that the Ai can reach it. If a point is not pathable, reject it.
  3. Test for the points being in line of sight. If a point is not in line of sight, reject it.

The results from this EQS Query are the locations that the Ai should consider dodging towards.

EQS Dodge Query results: Yellow: Locations that passed the EQS Query Tests.

#2 – Control which way the Ai can dodge

Once we have an array of unobstructed, in line of sight locations that the Ai can dodge to, we translate these locations into directions. Then we use location of the Ai and those directions in place of the current acceleration that the player used to generate the cardinal directions.

Iterate through the returned locations, create the directions, use the directions to get the cardinal directions.

At this point we have an opportunity to filter out the undesired directions. By defining a whitelist of cardinal directions for each Ai it allows us to only accept the desired directions.

Dodge ability settings for the Ai
Only accept the directions that are in the ‘Ai Allowed Directions’ list.

Accepting all directions allows all directions to be randomly selected.

EQS Dodge Query results – Blue: possible dodge locations; Green: Chosen Dodge Direction (south in this case)

Changing the allowed directions list to only allow South (back), Southwest (back left) and Southeast (back right) results in the Ai only being able to dodge in those directions.

Sword Knight’s proper dodge settings
Yellow: EQS Locations; Blue: Possible dodge locations

The EQS Query takes care of obstacles so that if a location is obstructed or not in line of sight then that location is rejected.

Wall causes potential points to be rejected.

Putting everything together and playing as the Sword Knight with debugging on we can see everything working together to give the functionality that we desire.

Note: animations, timings… pretty much everything is still being worked on for the Sword Knight’s dodges so that it’s nice and smooth, but this illustrates the functionality.

Playing as the Sword Knight to test dodge functionality.

#3 – Put everything into the base dodge ability

Combining everything into the base dodge ability and adding in a check for playing as a player so that we only use the Ai logic when an Ai uses the ability ends up looking like this:

Player Dodge ability with the addition of the Ai Logic necessary to support use by both Players and Ai

So, there it is. The rest of the story is having the Ai recognize when it should use a dodge ability, which is a bit more complicated and something that will have to be covered later.