Mortal Rite News

‘’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

It's been a very long time since we posted something here, but those who backed us on Kickstarter will know that we are working tirelessly on the game and are going above and beyond to polish it and get ready for the Early Access release!

Yes... You heard it right, we are getting close to releasing Mortal Rite!

In light of this, you will start to notice some changes on the Steam page and our Discord server, good changes, of course. We want to share the latest features and development progress so you guys are all caught up on everything. In addition, we want to give you a glimpse of what the Mortal Rite has to offer!

Finally, we want to send our heartfelt thanks to everyone who has backed us on Kickstarter or has been with us since the beginning!

Now let's jump into today's Dev Log…

One of the first things that comes to mind when designing a soulslike game is enemies, how they are going to react to you, what their abilities are, how difficult they can be, how they look, and so much more. So today, we want to share with you two of the cool things that we added to our enemies to make them more engaging.

[h2]The first one is AI Vision.[/h2]
When we started working on Mortal Rite, we discovered very quickly that making enemies that work well and meet or exceed the “AI'' in other established games was an order of magnitude taller than Shold (our tallest character).

So, to begin with, what is AI vision?
Enemy vision is what determines whether an enemy can see a target or not, and it’s trickier than we initially thought.

What does AI Vision do exactly?
Enemies need to be fair and predictable so that players have a good gaming experience. This means that a player should expect an enemy to acquire their character as an attackable target when it is in line of sight (LOS) and within a certain range.

Easy enough, the AI just needs to do a line trace to see if a target is visible (e.g.: Not blocked by something that should block sight). Trace from the location of the enemy’s eyes to the location of the potential target. Record whether the target is in line of sight, and that helps determine if the enemy should attack that target or not.
With a lot of attackable and destructible things in the game, including players and walls, a question came up to solve this issue: what is hostile to what?

We used the team's system built on Unreal Engine to control what is hostile to what. Entities on the same team are friendly. Entities on different teams are hostile. There are roughly two types of targets that an AI should worry about:

• Characters – Other enemies that are hostile or players that are hostile.
  
• Destructibles – Objects in the world that can be destroyed (such as barrels, obstacles (walls potentially)) that are hostile.

By default, all destructibles are hostile to all characters.
Characters are fairly easy because we maintain a list of the characters in the world that the enemy’s “AI” can iterate through and choose the hostile characters. EZ.
Destructibles are fairly easy to get as well. I chose to use a sphere trace so that each enemy only needs to worry about destructibles within its attack range. Originally, we used a sphere trace for Characters as well, but that’s silly when we have a curated list of characters at our disposal.

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎
‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎(A chart to give a simple explanation of the whole process)

[h2]One of the things that is related and has to go alongside the Enemy vision is Multiple Target Point Evaluation.[/h2]
We determined that it was necessary to have multiple target points for larger targets such as the Constructor Boss. It was bad that players could only lock on to a single point on the Constructor Boss because it caused bad camera interaction. The solution was to add multiple Target Points, and Alex updated player lock-on logic to allow smooth cycling through those Target Points. It sounded like a good solution, but honestly, it wasn’t something that I (Jensen) thought I would like. But I do like multiple target points, and I am happy that we have them.

What it means for the enemies is that their “AI” can also have access to multiple target points for targets that are large. Since everything is modular and target points are defined by the Lock On Interface, it’s really simple to add N Target Points as needed.

‎ ‎ ‎ ‎ ‎ ‎‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ (Random Wall Destructible with multiple Target Points (yellow hand-drawn XS)

[h3]Half of this game is 90% mental[/h3]
LOS is only half of the “Can the AI attack a target” equation. The real question is, “Can the AI see a target, and can that AI get to a location that allows it to attack that target?”. The AI has two types of attacks at a really high level: Melee attacks and Ranged attacks. When an AI decides what it can do, it needs to know if it can use a melee attack or a ranged attack against a target. Part of AI Vision Logic is determining if a target is Melee Reachable or Ranged Reachable.

Melee Reachable: True if there is a pathable location that is within the AI’s attack range to a target.
Ranged Reachable: True if the target is in LOS and within the Missile Range.

It might be becoming clear that all of the above AI Vision logic talk was really just scratching the surface of what the AI is actually doing, but I felt I needed to cover all that to set up a foundation for the real problems that I’ve solved recently.

A problem caused by needing to be within range of a target in order to attack it is that for large targets that have one target point, the AI may or may not be able to get within range of the target point, but it can get in range of the target’s location. This looks like the AI should be able to attack the target, but the AI, trying to be smart, is overthinking the situation and rejecting the target because it can’t reach the target point.


‎ ‎ ‎ ‎ ‎‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ (Multiple Target Points are being evaluated by Sword Knight)

[h3]Better Reachable Evaluation[/h3]
Multiple Target Points allow for the AI to better see targets that it could not see before due to a single target point being obstructed and also partially address the reachability issue because multiple target points increase the chance that a target point will be in range for the AI (optimization for static targets would be to place fewer target points in better places than to just have a bunch of target points. Don’t worry: we’re not going to be stupid about the number of target points we use because performance is important).

It was because everything was working better that a new problem appeared: there can be obstacles on the ground that make a target partially unreachable for melee attacks.

In a setting where there is debris on the ground or anything that blocks a direct path to a target that is reachable in other ways, the AI would still decide not to attack that target, which is bad and makes the AI look dumb. And we don’t want dumb AI.

(Nav blockers do not block LOS to Target, but do prevent the finding of a reachable location within range of the target)

The solution that I’ve put in place for this is to test a half circle of reachable locations from the chosen target point. This means that in the above case additional reachable locations would be tested to the sides of the red location.


‎ ‎ ‎‎ ‎ ‎‎ ‎ ‎‎ ‎‎ ‎ ‎‎ ‎ ‎‎ ‎ ‎‎ ‎ ‎ ‎‎ ‎ ‎‎ ‎ ‎(The Ai can now reach the target due to the extra testable locations. As expected)

[h2]Conclusion. Finally.[/h2]
This has become a long post, but hopefully interesting. Now for the system in action and potentially the TLDR of the whole post.
[previewyoutube][/previewyoutube]

One more thing to add before we say, see you in the next Dev log.😉

[h2]DESTRUCTIBLE ENEMIES? KIND OF[/h2]
When you hit an enemy, it’s fun to see that you really smacked that enemy.

• Hit Reactions: Done.✅
  
• Blood splattering: Done.✅
  
• Effects when you hit the environment: Done.✅
  
• Removing armor is also good. Let’s do that.

All characters have the concept of Health Thresholds that can be set up to trigger things happening. In the case of Sword Knights, Health Thresholds are used to trigger when their armor comes off.


‎ ‎ ‎ ‎‎‎ ‎ ‎ ‎ ‎ ‎ (Health Threshold Configuration. There are more than just one for the Sword Knight.)

We can choose to set up any enemy to lose armor or anything visual based on their current health, but today, I am focusing on The Sword Knight.

The Sword Knight’s armor has been set up with different material sections so that we can hide each section whenever we want, and we’ve chosen to do this when the Sword Knight’s health reaches certain thresholds. At the same time that the armor is hidden, we also set off a Niagara effect that shows his armor flying off and landing nearby.
[previewyoutube][/previewyoutube]

Now it's time to say see you in the next Dev Log, wishlist Mortal Rite if you haven’t already, and make sure to follow us on socials; we release content there quite frequently.

Thank you, and see you next time. ~Round Toast Team

We are excited to announce the Development Road Map for Mortal Rite! We've shifted around our plans for the future of the game taking the Kickstarter campaign's success, and stretch goals into account.

Each time a new milestone on the Development Road Map is reached, we'll let everyone know. Also, as soon as we have solid dates for any milestone on the Development Road Map we will update the roadmap with that information.

For anyone that is interested to see how Mortal Rite is made and/or what progress is being made, we have a developer blog with new posts once a week from each developer. Check it out here: Mortal Rite Blog.

[h3]Thank you for all the support, the past couple of days have been absolutely insane![/h3]

Thanks to you guys, all this content will be added to Mortal Rite!

New Character: Fia - All her abilities & upgrades!
New Level: Ghoul Grotto
New Enemy: Great Ghoul Monster

[h3]STRETCH GOAL UNLOCKED FOR THE LAST 48 HOURS![/h3]
If we hit $55,000 by the end of the campaign, we will be able add another enemy, the Caster Monster! (Working Name)

The Caster Monster is a back line mage that prefers to stay away from players. Focuses on hurling spells and will only engage in melee combat if cornered. Comes from the same family as the Knights, so shares a similar art style. Strong threat when left alone, but fragile when the gap is closed quickly.

If your looking to still support our Kickstarter, there's only about 48 hours left to do so!

[previewyoutube][/previewyoutube]

We are Round Toast Studios, a new indie studio making our first game. With just a team of 5 people, we are working very hard to make an indie game that all of us wish we could play. As a group, we initially raised enough money to start working on Mortal Rite by designing and selling different custom A.I. and robotics software programs. Now, 3 years later and with over 120,000,000 views across our social media and tons of hype to fully build out Mortal Rite, we are turning to our community for help to get us across the finish line! With this extra amount of funding we can turn this great idea into an even more amazing game with 3 more characters, 23 more enemies, 9 more levels, and tons of more items and game modes!