New progress this week / week and a half (I know I posted a little while ago).
We need some more blood my friend.
Abraham Lincoln
So to kick things off, as Anthony mentioned last week, we did have enemies spilling their contents on the floor, but boy oh boy, wouldn’t it be neat if 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 voila, blooooood.
Yay it works! So basically what’s happening here is we find where you’re 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 wounds stick around for like 30 seconds, whereas the splatter would stick around for like 5 seconds. The only problem was the plugin didn’t differentiate.
So I took a peek under the hood to figure out how it worked. Turns you can specify one image per mesh, which then gets drawn to a RenderTextureTarget.
This just means you can draw something to a texture real-time and do something with it. (In this case, projecting it 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 its…
HLSL
Hey a manual way of specifying how shaders are rendered.
I’ve never worked with this before!
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 how long the total fade time is.
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 a different timings for when the fade started.’
And so with that done, here’s a sped up version of the blood drying quickly
And so with that we move onto…
Defense
In the last demo we only had two defense types. Block or Parry.
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.
Next up is Parry, this is similar to what Dawksin had in the demo. If he successfully parries, he will ignore damage and perform a counter-attack.
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
And finally Evade, this will most likely end up being Fia’s defense type. Successful timing will result in you repositioning behind your attacker.
(Thanks to Jensen for helping me work through this)
It’s using some of Dawksin’s vfx at the moment, but hey it works!
Now I could wrap it up there, but what about the part of the week where I hit road blocks with fundamental systems? Systems so vital, when they don’t work it ruins your whole experience? That’s right baby we’re talking about
Animation locks are what determine if you’re locked into an animation or if you can break out of it and do something else. This is what lets things like chaining of melee attacks be possible, and having abilities not be interrupted mid-cast.
Version 1 of this system was in our last demo, and was notorious in multiplayer for failing when using Dawksin’s grappling hook, causing players to get stuck in a cast animation until they got hit by an enemy.
So we took another look at animation locks and implemented a pretty big change. Apart from reworking the whole thing into an ability so we could debug it better, we also made it so that locks ALWAYS have an expiry time.
This makes it to where even if the network hitches, or some ability flies off the rails in some crazy edge case, the lock WILL release.
Ultimately this ends up with us not needing to worry so much about getting stuck and some fancy new nodes for controlling when you can and can’t break out of animations.
That last node also has some fancier functionality, to automatically read animations and find lock releases.
Now I know what you’re thinking, wow Alex that’s a lot of stuff, we should end it here ri-
WRONG
I also went ahead and:
- Updated Dawksin’s Reticle size so you could see more clearly
- Fix a bug where anytime you got hit ALL OF YOUR PASSIVE ABILITIES GOT CANCELED
- Fixed an issue where AI would cancel it’s own animation lock ability, making it get stuck forever.
- Added in more entries to the Gameplay Cue Translator to allow different hit impacts which Anthony detailed in his blog post last week.
- Fixed a bug where due to the new animation lock system dodge was no longer allowing dodge attacks, so a new “Dodge – Cancelled” ability was added that keeps your dodge state active for a little longer so you can chain an attack.
- Fixed an issue where when blocking while locked onto an enemy with Shold his torso would kinda split in half.
Okay. Catch y’all next week