Mortal Rite News

As we say in the business, another day another dev log… anyways let’s jump right into it!

“Level transitions” refers to the unloading and loading of assets for a specific level. “Level Transition System” is what we are calling the system that replaces most of the previous systems and logic used to determine what gets loaded dynamically for a level. The “Level Transition System” lives in a component that is globally accessible called a Level Transition Component (LTC).

The LTC manages Data Layers that are part of Unreal Engine 5’s World Partition system. LTC allows level designers to set up configurations for each map that define the following Data Layers.

Each configuration contains:

• Display Title: To tell the player what level this is.
  
• Allowed Floor Minimum: Minimum floor this configuration can be played on, meaning the earliest into a run you would be allowed to play this level configuration.
  
• Allowed Floor Maximum: Maximum floor this configuration can be played on, conversely meaning the latest into a run you would be allowed to play this level configuration.
  
• Configured Player Starts: Specific spawn locations for this configuration.
  
• Progress Player Starts: Specific spawn locations that the player can unlock in this configuration.
  
• Layout: Data Layer for the Basic Level Layout.
  
• Dynamic 1: Data Layer that provides level changes specifically needed to support 1-2 players.
  
• Dynamic 3: Data Layer that provides level changes specifically needed to support 3-4 players.
  
• Dynamic 5: Data Layer that provides level changes specifically needed to support 5 players.
  

[previewyoutube][/previewyoutube](Data layer transitions)

Above is a clip from a test level of the data layers transitioning between unloaded, loading and activated.
(BASE)

When a level is loaded, the LTC shows the loading screen and then it determines which configurations are valid for the level and the number of players. The LTC then uses a seeded stream to determine which configurations to load as needed. Once the configuration is chosen, the LTC replicates the needed information to any attached clients (for multiplayer) and waits for the clients to report that they have loaded the Data Layers needed for the chosen configuration. It’s necessary to know when all clients have loaded the configured data layers so that all clients can have their loading screen hidden at the same time.
(Living Trees)

LTC has other helper functions such as a function to load the next configuration and a function to reload the current configuration and Reload Current Configuration that are exposed to Blueprints.

(Dead Trees)

Below is a video showing the Nanite Lumen Test level in a very unfinished form. For this clip the NLT level was set up with 3 themes (Cloudy, Thunderstorm, and Dust Storm), and 3 level layers (blank, dead trees, and living trees). Using those layers the following configurations were made: Cloudy/Blank, Thunderstorm/Living Trees, and Dust Storm/Dead Trees. The clip shows Dawksin in a configuration that has a wall blocking him until he uses a trigger to cause LTC to load the next configuration. By the end of the short clip, Dawksin has gone through all 3 test configurations.

[previewyoutube][/previewyoutube]

The clip is kind of a quick test of the LTC using real assets and it might not look very impressive, but it has helped iron out a lot of bugs.

While we have the technology to load and unload data layers during gameplay, because loading and unloading assets takes time, all level transitions for Mortal Rite will happen during a loading screen when the players are traveling to a location. Once the level has loaded and the game is playable, there should be no level transitions until the players travel to a new level.

Dynamic changes to levels are handled outside of the LTC, but can be persisted via Progress Items, which are used to save progress within levels and throughout Mortal Rite.

Anyways see you in the next one!

~Round Toast Studios

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!