Mortal Rite News

Last time we covered some of the design decisions on why we swapped to the stance system. Today we’ll focus on Fia and some of the changes this made to her kit. Fia’s two stances are Battlemage and Flameborne. When in Battlemage stance, she primarily focuses on Melee attacks and supplementing those with useful spells, both offensively and defensively.



While she previously used to be able to pick from a pool of abilities, we found that players didn’t really deviate from the main damaging ones, because it wasn’t clear that the other spells had any real advantages.

Splitting them up into 2 separate stances that you can toggle between frees them up to be able to choose when they want to use situational abilities, and when they want to burst their target down.

This also allowed us to expose more of the underlying systems in the form of passive abilities. We’ve developed the poise and focus systems quite a bit between all of the characters, and this lets players be able to have more control over those systems.

For example, Fia used to be able to use her defensive ability to be able to parry anything in the game, but that didn’t feel quite right, when she got hit by a massive attack from a boss, and deflected it with the same ease as Shold, who was made to be able to block anything. So we introduced a threshold where she can still successfully deflect any attack, but if it’s too strong, she still gets knocked down, but takes no damage. Players can now choose to spend a point in increasing the defensive power she has when defending, or optionally just choose to dodge that attack.

[previewyoutube][/previewyoutube]‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ Failing deflect against large enemies

[previewyoutube][/previewyoutube]‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ Now we can deflect

In addition, you can really go all in on defense if you so choose, by adding an ignition effect when defending that will burn anyone you defend against, and significantly increase your focus generation when you successfully deflect an attack, letting you immediately start casting an offensive spell.

We’ve tried to take this kind of approach for all of the passives, where we either expose previously hidden systems or we add extra components to let you really customize how you want to play the character.

Along with the passives, there were new spells that were made for each stance, with the goal of supporting the overall playstyle for that stance.

The Battlemage stance received a new Fire Cone ability that can deal significant close range damage in a wide area. This can be expanded to increase the range or to stun enemies caught in it.

The Flamesword spell is now fully featured as well, offering an option to upgrade from fast kicks to dedicated heavy and charged swings with the sword. These attacks have been designed with enemy groups in mind, so its a good choice to deal with large groups, instead of using the dagger.

[previewyoutube][/previewyoutube]

The Flameborne stance is still under heavy development, but at the moment, you can enter this stance at any time, and begin to burn your focus pool, but your abilities don’t cost anything.

Fia’s Light attacks are replaced with a Fireshard combo and heavy attacks cast a chargeable fireball, significantly increasing damage with each charge level (up to 3.)

[previewyoutube][/previewyoutube]

That’s all for this week. Catch ya later✌️

[h3]Come check out our latest development updates live on Steam![/h3]



Alex Estevan, our community and social media manager will be playing through our latest developer build and showing off the new stance system we are really excited about! It will be the perfect time to discover more about Mortal Rite and get any questions you have about the game answered!

▶️ The live stream session will take place on Steam, Twitch, and Discord at 12 PM CST on Saturday, August 31st.

See you there!

We’ve been cooking up a new way for players to play around with their kits.

Previously we made some design decisions for player abilities that led to quite a few unfortunate circumstances. We wanted players to master their abilities, and one way we thought of doing that was to have a variety of ways to alter how they used their abilities.

Ah, here’s a great way to make sure that happens. We’ll force every ability to have “Hold” functionality. So anytime the player holds down the button for the ability it should change the way you use the ability.

For a while this was more or less okay. We could think of some alternate ways to use abilities that encouraged tapping the button versus holding it down. One example was for Fia. Her Fireshard ability would launch a small fireball, while holding the button down would launch a bigger fireball, and continuing to hold it would charge it further, increasing it’s size and damage.

Hold: Fireball

Tap: FireShard

Which was great until we started running into issues with other abilities.

Taking Fia as an example again. Her Flame Sword ability, she can summon a sword, but what exactly would the hold do?

This came up pretty often, we wanted “transform/shapeshifter” abilities that would alter what weapon you had or what “mode” you were in, which in testing was a lot of fun, but didn’t have a clear answer for how we’d tackle that Tap Vs Hold functionality.

On top of that, the player could add mods to each ability to change them even further.

Old Customization Menu

Each ability had to have at least 4 mods. This would let players customize their playstyle with each character. It also meant that we were in a very weird spot for abilities like the FlameSword. Most of the mods for those types of abilities would wind up being passive components. Things like increased damage, add fire damage, regain additional focus on each hit.

The passives in those cases ended up feeling more of a forced decision rather than a new way to interact with the ability. Together with the tap and hold requirement, player abilities were in an odd spot design-wise and in terms of player customization. On top of that there were other issues of progression were players would could gather ability points in a very short amount of time and get all the ability mods.

Back to the drawing board, Anthony and Jensen spearheaded a new design to combat most of these issues.

The stance concept assumes from the very start that characters will have at bare minimum two “modes or stances”. This right away takes care of the issue that swapping weapons had, and the requirement for Tap vs Hold was removed completely.

So players will start off with a “Stance Swap” ability for free that let’s you swap back and forth between the two modes.

Please ignore my impeccable UI design. 😅

The system still allows abilities to be customized, without the need for specifically 4 mods per ability. It also lets you pump points into different mods so you can focus more power into a specific playstyle.

There’s been a ton of changes since we introduced the system, and we can get into it some more in a future dev log. But that’s all for this week.

See you in the next one.

Hello again everyone! This week was all about adding in Dawksin’s Hunters Charge ability.

While relatively straight-forward there were a few hiccups that were a tad unexpected. The idea of the ability is that Dawksin quickly passes through enemies dealing damage and adding shrapnel to anyone in the path.

We already had the base animation for the attack so step 1 was to add our anim notifies that tell Dawksin how to move.


These are little tags with data we can throw onto an animation, that say “Hey do something at this point in the animation!”

So for example:


So how do we break this down?
Ignore the long green bar, that's just the animation itself.

• Light Green: Prevent additional abilities from activating
  
• Gray: Add some flags on Dawksin.
  
• Ex: 1st one speeds up his rotation in case you want to change your aim.
  
• Ex: 2nd one locks your rotation so you can’t make Dawksin spin in place while moving.
  
• Darker Green? (I made too many things green) : Tells Dawksin to move
  
• Red: Damage windows. One for each blade.
  
• Blue (Beginning): Lets you change your rotation even if you’re locked onto a target.
  
• Blue (End): Ends the animation early if you’re trying to move.
  

We do put a lot of thought into how each ability feels, so all these notifies are there to make sure it feels good to use. This is also how melee attacks are built.

So if we dig into the movement notify, we can see a ton of options for how to make Dawksin move. In this case, we’re making him move 1000 units forward over the length of the notify which is like 0.13 seconds.



So now our move ends up looking like this:
[previewyoutube][/previewyoutube]
But that’s not quite what a blink is-

[h2]ADDING IN THE BLINK[/h2]
The blink needs Dawksin to disappear, which is no problem, we can make him do that.

[previewyoutube][/previewyoutube](It would be pretty swell, if he came back though.)

Lets add his weapons to the mix, and make him re-appear. I think that’d be for the best.

[previewyoutube][/previewyoutube]
With that, we have the basis for ability completed!

[h2]VISUAL FX[/h2]

Here we can add some flair to communicate when Dawksin should be doing damage. In the anim notify windows above, we defined when Dawksin was doing damage with each blade.

That’s fine and all, but we need to – SEE - when he’s doing damage.

So here we can add weapon tracers, courtesy of Rod.
[previewyoutube][/previewyoutube]
(Um… while that looks kinda cool, the tracers are not really showing the path of his weapons. Let's look into that.)



So it turns out there’s a bug in the stock effect attachment code from the engine.



Here the tracers are being attached to each weapon bone, which is great, however, the code looks at that and says “ah yes, lets attach it, AND let's take the location of the bone, and offset it permanently”

I can’t override the behavior since we’re using a binary install of the engine. So you know what that means.

Not my favorite thing to do. I typically avoid this as much as I can, but in this case, we attach a lot of effects, so this would affect a ton of particle systems.

A few hours later we now have our own attachment code with all the same bells and whistles. In addition, we can now specify our own custom offsets in case things don’t line up perfectly.



[previewyoutube][/previewyoutube] (Hey that looks right)

We’ll tie it all up with the VFX of his cape showing when the blink starts and ends, and some tracers to show the path he traveled.

[previewyoutube][/previewyoutube]

So that’s most of the ability complete.

From here we start taking care of the edge cases. Anthony showed last week how we could have attacks that take into account when Dawksin stows his weapons, so I added a new variation for when his weapon is stowed.

[previewyoutube][/previewyoutube]

And in the end we actually changed the attack animation from a 2 hand slash where Dawksin does a spin to instead have him slash his sword in a x pattern, we felt like it fit the attack better.

[previewyoutube][/previewyoutube]

Anyways that’s all we had time for, see ya’ll next week!

As mentioned in the previous dev log, we use the Level Transition Component to allow us to change anything in the level either at level load time or, if a loading screen is okay, once a level has been loaded. We can add a wall, have a bridge that was standing be destroyed, change weather or theme, or anything that causes the player to have to find a different path through the “same” level. But level transitions don’t replace having parts of a level be destructible… so that’s why today we’re going over our “destructibles”

Destructibles are objects in the game that can be destroyed by walking, sprinting, rolling, or dodging into them, or by attacking them. The goal of destructibles is to make the world feel more alive, solve a few gameplay needs, and to just be fun. We find it fun when, either intentionally or accidentally, you break a destructible and see the chaos unfold.

[previewyoutube][/previewyoutube]

We like the idea of cover that is destructible so that taking cover from the Heavy Archer on the bridge in the playtest is possible, but you can’t camp there for too long

[previewyoutube][/previewyoutube]

We have also used destructibles to delay the player from getting from place to place.

[previewyoutube][/previewyoutube]

[h2]Destructible Implementation[/h2]
In Mortal Rite, destructibles are actors that have one or more static meshes that, based on criteria, can be broken. Upon breaking the destructible a Gameplay Cue is set off and the destructible actor is deleted (deleted here means that the actor is no longer visible and no longer has collision). A Gameplay Cue is a mechanism for easily displaying visual effects for multiple players. The Gameplay Cue knows how to properly display the visual effects for the destructible’s mesh or meshes and can be referenced easily using a Gameplay Tag.



Destructible settings available to a developer:

• Lifespan: Time the destructible lives once it is broken.
  
• Tags Must Have to Break on Overlap: Tags that must exist to break when something overlaps the destructible.
  
• Tags Break on Overlap: Tags that will break the destructible on overlap.
  
• Gameplay Cue Tag: The Gameplay Tag for the Gameplay Cue to use when this destructible is broken.
  
• Lock on by Player: Allows this destructible to be locked on by a player.
  
• Lock on by Ai: Allows this destructible to be locked on by an Ai/Enemy.
  
• Startup Tags: Tags that identify this object in the world. In this case, this is a destructible, and we can query for objects with this tag when we want to find destructibles within an area or in the level.
  

[previewyoutube][/previewyoutube]

[h2]Ways to break destructibles[/h2]

• Overlap: When a character overlaps with the destructible, a check is done to see if the character meets the criteria to break the destructible. The first check is for “Must Have Tags” if they exist. If the character that overlapped with the destructible does not have all of the Must Have Tags set on the destructible, then the destructible cannot be broken on overlap by the character. The second check is to see if the Tags Break on Overlap to see if the character has at least one of those tags. This means that a developer has the ability to determine exactly what can break a destructible. Developers can create destructibles ranging from a destructible that will break if anything overlaps with it, to a destructible that will break only if Shold overlaps it while specifically wearing his Rock Armor and sprinting, to a destructible that will only break if a Boss overlaps with it. Very flexible.
  
  
• Damage: Destructibles are also on a team. Teams is how we control whether or not something is hostile to any entity in Mortal Rite and only hostile entities can do damage to each other directly (e.g.: sometimes AOE damage doesn’t care about teams at all). If some entity is on a different team, we consider those two entities hostile to each other, and this holds true for destructibles as well. Destructibles default to team 69 (for obvious reasons), which is a team that is hostile to players and, even if the enemies are on different teams allowing them to attack each other, is a team that is hostile to enemies. Destructibles can be set up to have any amount of health so that we can control how easy it is to break them with damage. Sometimes you want to delay a character from entering an area by using a high health wall and sometimes you just want a destructible that doesn’t break on overlap, but will if the player attacks it once.
  
  
• Other Use Cases: Shold’s rock abilities use destructibles that have their team set to the owning Shold’s team so that enemies can target them and, after a bit, break them, but friendly players cannot break them or target them.
  

Hope you enjoyed this Dev Log! See you next week!
~Round Toast Studios