Mortal Rite News

Howdy, over the past week we got a bunch of small fixes done! White this won’t be the most flashy dev log you’ve ever seen, a lot of these changes are important so we will do our best to explain them clearly!

[h2]GENERAL UPDATES[/h2]

[h3]DODGING[/h3]
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 bad idea, because most of our characters are vastly different sizes. So, uh, let's change that.


Now each character can have their own distances for rolling while not locked on and dashing while locked on, regardless of whether it's 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 afterward.

[h3]JUMP COMPRESSION[/h3]
We had a whole thing written two dev logs ago 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.
[previewyoutube][/previewyoutube]
(Now their feet hover instead, which is slightly better, but we’re going to go back to the drawing board on this one.)

[h3]ANIMATION BLENDING[/h3]
There was a small problem that we weren’t able to figure out for a while, where if you started or stopped walking, your character's legs would fly out in front of them for a split second.

[previewyoutube][/previewyoutube]

This seemed really weird until we started looking into the jump compression stuff. Lo and behold, by default, the characters 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 start sprinting for a moment.

It's not a huge bug, but it is one that did have us stumped for a while.

[h3]ORIENTATION BLENDING[/h3]
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. It's mainly visible if you’re locked on and moving around an enemy. As we should do, because the enemies are tall and imposing.

[previewyoutube][/previewyoutube] (When you’re walking left and right and then moving forwards and backward, you now have a new animation to blend with. It's not perfect, but it looks a lot better than before)

So the solution here was to add two more animations (two for walking and two for jogging), 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.

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

[h2]SHOLD UPDATES[/h2]
Shold got a new IK Rig that let us begin porting over all of his old animations from the UE4 version of the game. This gets us 90% of the way with his animations, except that it didn’t quite fix up everything it should have.



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

[h2]FIA UPDATES[/h2]

[h3]MODEL UPDATES[/h3]
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.


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.


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

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

[h3]ANIMATION UPDATES[/h3]
Oh baby, we finally have some custom animations for Fia. Started things off with new locomotion animations for walks, jogs, sprints, jumps, and turns in place. She finally animates differently than the initiate.
[previewyoutube][/previewyoutube]
(Behold, she no longer slouches like that bandaged weirdo

In addition, we 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.
[previewyoutube][/previewyoutube]
(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.

Look, the important thing here is that we 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 we think it came out pretty neat, and it helped sell her persona.

We still need to work on her heavy attacks and such, but that should be done pretty quickly.

See ya’ll next week.

This week was all about adding some finishing touches to Dawksin.

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

• 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 toward the beginning of the move, and as you get closer to your destination, you get less control.

[previewyoutube][/previewyoutube] - (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 it, making it so you kick off the wall automatically.

[previewyoutube][/previewyoutube]

[h2]Reticles[/h2]

Next up was tackling the reticle for the grappling hook.

When the grappling hook hits something (either an enemy or terrain) you’ll automatically start moving towards the hook. I wanted the reticle to show what’ll be hit, and still be readable when you have other abilities like Pierce that also have a reticle.

I’ve increased 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 is highlighted in yellow
  
• And as you get closer, you can see they are within Pierce’s distance

[previewyoutube][/previewyoutube]

[h2]Icons[/h2]
I also started updating icons with more final art, and updated them to show what state the ability is in.

[previewyoutube][/previewyoutube]

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.

[h2]Stowing/Sheathing[/h2]
Since we gave Dawksin a new state where he could sheathe his weapons, we started experimenting around how this would work.

Initially, we tried something like this: 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 using 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 not only feels 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 gets a little more upfront damage since his overall damage is low because he has so much power packed into his Recall ability.

[previewyoutube][/previewyoutube] - (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 look up what kind of damage boost you get.



That’s about all we had time for this week.

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!

Today, we’ve got some new updates we personally find very interesting and hopefully you will too, so let’s jump right into it!

[h2]Jump Compression[/h2]

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

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

[previewyoutube][/previewyoutube]

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.

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.



[previewyoutube][/previewyoutube]

[h2]Grappling[/h2]

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 them.

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-Canceling when you let go

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 that 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 we ended up repurposing. It looks a little imposing, but it has all the knobs and levers we need to adjust the hook.



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.

[previewyoutube][/previewyoutube]

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!

Here we are with another Dev Log, Take a ride with us on what we have worked on and are working on.



[h2]Material Updates[/h2]

• 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.
  
  
  
  
• 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 clipping through his arms and torso.
  [previewyoutube][/previewyoutube]
  
• We can now support blood decals on character after hits thanks to Alex. So we 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 we 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.
  [previewyoutube][/previewyoutube]

This leads us to…

[h2]Optimization Updates[/h2]
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 are LODs??
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 higher quality the closer you get.
[previewyoutube][/previewyoutube]
Having these be lower quality helps the engine run faster because it has less geometry and fewer 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’s range anywhere from 2GB to 24GB 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, it slows down to an unplayable crawl, and we weep bitter tears.

So, armed with that knowledge, what can we do?
We went in and found out how much memory each character was taking up, and as it turns out, they were taking up roughly 1.2 -1.5 GB each... so that adds up concerningly quick. However 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 we don’t have to compress the source texture, people with higher-end machines would be able to use the textures at a higher resolution.

• (The way to do that is to look at each character overall, 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, we ended up reducing the memory size 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.

[h2]Animation Updates[/h2]
Now comes everyone’s favorite portion of the blog…

“HOW MANY ANIMATIONS DID ANTHONY GET DONE THIS WEEK!” - It's 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.
  [previewyoutube][/previewyoutube]
  
  
• Shold is starting to get back up to speed with his locomotion for His Hammer + Shield, and his 2-Handed Axe is looking pretty good. Still needs to get his Rock Armor finished, though. Don’t have much of his melee done, but at least his light attacks are in there.
  [previewyoutube][/previewyoutube]
  [previewyoutube][/previewyoutube]
  
• 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.
  [previewyoutube][/previewyoutube]
  

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

[h2]Effects Updates[/h2]
Lastly, we started porting over all the impact effects from the last project. The effects were enhanced a bit to be more visible. They’re all based on 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

[previewyoutube][/previewyoutube]

Each one spawns its own different impact effect, and it's 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 can't use blunt or sharp effects if we’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!

‘’We need some more blood, my friend.’’ - Abraham Lincoln

So, to kick things off, we did have enemies spilling their contents on the floor, but boy, oh boy, wouldn’t it be neat if we also hit their meshes? We think so.

We had dabbled a little with a plugin that would let us do this in the last project, but we couldn’t get it working last time, but with a fresh set of eyes, we implemented it again, and voilà, blooooood.



Yay, it works! So basically, what’s happening here is we find where your weapon hit, and we tell the system, “Please spawn a decal at this location on this mesh.”

But it would be a lot cooler if it also splashed onto you. So we added one for the player’s mesh as well and said hey, let’s do a trace to figure out kinda where the blood would end up if it splashed from the hit location. Back to you!



So that’s pretty cool, BUT we didn’t want it to look like you were heavily bleeding from dealing damage to someone. So we figured we could differentiate a splatter, from a wound (for lack of better terminology).

The way we’d do this is by having the blood from wounds stick around for longer, whereas the blood from splatter would stick around for a shorter amount of time. That way if you were covered in blood for a long time, that would likely mean that you took damage and be an extra little indicator that you should heal. However the only problem was the plugin didn’t differentiate.

So we took a peek under the hood to figure out how it worked. It turns out you can specify one image per mesh, which then gets drawn to a RenderTextureTarget. This just means you can draw something to a texture in real-time and do something with it. (In this case, it is projected to the mesh).

Since there wasn’t support for multiple textures, there also wasn’t support for different timings, which is what I wanted for the splatter vs the wound.



So I took a look at the guts of that node and found out it's…

[h2]HLSL (High-Level Shader Language)[/h2]

A manual way of specifying how shaders are rendered.🤔 We’ve never worked with this before! After pulling in Anthony, we took a deeper look into this code and found that if you want to fade out the blood, it fades right away, and you can only specify the total fade time.

So, doing some quick math, we figured out how to add not only an initial delay (so it wouldn’t start fading right away) but also a switch for whether it was a wound or a splatter, so we’d have different timings for when the fade started.


(We’re reading texture data. How Fancy!.... 😉)

And so, with that done, here’s a sped-up version of the blood drying quickly


(Focus on his arm. It dries up like a desert)

And so, with that, we move onto

[h2]Defense[/h2]

We were talking about it and figured we could give more options depending on what character you choose. So what does that look like?

• Block
  
• Deflect
  
• Parry
  
• Perfect Block
  
• Evade

So “Block” is what enemies typically have and for the most part it’ll stay that way, so not much is new there.
“Deflect”, the main goal for this is to avoid attacks if timed perfectly. This works well for smaller weapons where it wouldn’t make much sense to block.


(Deflect in action)

Next up is “Parry”. This is similar to what Dawksin had before. If he successfully parries, he will ignore damage and perform a counter-attack.

(Parry in action)

“Perfect Block”, this is what Shold had in the demo. Arguably one of the strongest defense types, since successfully timed blocks cause enemies to stagger. Useful for protecting your teammates


(Perfect Block in action)

And finally “Evade”, where successful timing will result in you repositioning behind your attacker. None of the current cast of characters use evade, but we will likely implement it in a future character soon!
(Thanks to Jensen for helping me work through this)


(Evade in action)

Okay. catch yall later!✌️ ~ Round Toast Studios