Mortal Rite News

[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

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