All the small things

This week I was running around fixing a bunch of things all at once.


So since the editor let’s us test under less then desirable conditions we’ve started testing what systems break down under lag.

fancy network testing options

Because of this one of the things we found wasn’t reliable was damage, which I think we can all agree is pretty important. If you take a swing at an enemy and they ignore your damage, no one’s gonna be happy.

There were a few things that could be causing this, one of them which I suspected was causing this, is your weapons only count when the server/host sees a hit happen. While this is great for preventing cheating, if feels pretty terrible and isn’t exactly great for performance.

If we continued down this path it would mean the host would need to tick everyone’s animations perfectly otherwise the game feels unresponsive.

So how do we get around this so combat feels fair and it’s still hard to straight up cheat?

Client side hit detection

So I took a look at how the Lyra project was handling similar things, like shooting/melee since its pretty similar.

Turns out they have a nifty way of sending hit data were it can still feel responsive, while still sending it to the host to verify you didn’t just hit someone from across the map.

So I extracted the relevant parts, and now we can send hit data from your client. Yay!

classic target data

Once the server gets the data, it double checks to make sure the hit was even possible, and then applies damage. Nice!

There will be Blood

So up next was handling hit effects. Up till now we’d been using the Lyra defaults which gave us sparks anytime we hit characters.

So Anthony ported our blood emitters from our previous project, and we spawn it anytime characters are hit.

(Positioning was easy thanks to last week’s post)

One of the funny side effects of this was since effects are triggered from damage, destructibles were bleeding as well.

There’s blood in my metal

I recalled something that could help me out with this. As I was reading through the ability system source code, (You know, a thing normal people do) I came across the Gameplay Cue Translator.

Turns out this handy little class can translate gameplay tags from one form to another, in this case letting us mutate the more generic tag to a more specific one.


you (probably)

So the vfx tags we send across the system tend to look something like this


That’s great and all, but like you saw above, that means anything that takes damage will play the blood effects. If we use the translator, I can add rules that depending on what we hit, it’ll update what tags get sent. So now it’ll end up sending either:




Which lets us handle effects differently per object type. Nice!

Back to blood though. The little squibs of blood are cool, but we also want the decals to show what a mess you’re making. I started to add decals directly beneath the enemy that was being hit, and it looked ok, but kinda weird considering the blood was gushing out and appearing –directly- beneath your enemy.

I tried adding some traces to kind of figure out roughly where we should place the blood, but it was kind of a mess. Then it hit me.


Luckily this was actually super easy to add.

behold. cannonball technology

With this we end up nice a nice trace for world geometry that lets us know where the blood would have fallen according to a given velocity.

oh yes.

Now we add a placeholder decal to test that it’s rotated the correct way

The decals are aligned towards the character, which helps the blood to look more aligned. It’s definitely not perfect, but it should get us most of the way there.

So replaced with the actual decals, it looks more convincing

Finally the last thing I worked on this week was tweaking how we handle fire effects. Rod has been handling most of the effects work, but this particular effect was giving him some trouble so I thought I could help a bit here.

Fire effects are going to be a pretty important part of Fia, so I went ahead and tweaked how the fire sprites behave when in motion. The most important thing here was to give it left and right motion, which we can see the beginnings of here.


I think it came out alright.

The last thing I happened upon this week was batch importing animations.

Since we’ve been going through and cleaning up animations, I wanted a way to batch import any animations that we exported from Unreal into Akeytsu (our animation software)

Typically the whole process sucks since Unreal exports animations individually, and Akeytsu accepts one file at a time, so when you’re dealing with 100 animations, going through that many dialogs and having to manually rename each one since Unreal exports the name as “Unreal Take” no matter what, I figured there had to be something I could do to make this smoother.

Turns out Blender let’s you batch import files, which does solve one of the problems, but the naming problem was still there.

I wondered if I could edit how Blender imports .FBX files.
Turns out, the importer is a python script.

How very editable…


So all I had to do was find where it handled the names, and replace it with the name of the actual file.

Who knew I’d be doing this today?

But with that done, I was able to import the animations in minutes instead of hours.


Anyway, that’s all I got for this week. See ya’ll next time.