Since the last time I posted, we had a bunch of little small things fixed.
This time I got to finish working on pierce. Since the last time I talked about pierce, I noticed that there were some issues with it when it came to networking.
Because the game is going to be peer to peer, we need to make sure you’re projectiles still fly nice even while someone is ripping out your ethernet cord, or carefully constructing a faraday cage around your WiFi receiver.
The main thing that prompted this review of Pierce was some errors I was getting when testing networked.
That really handy target data I talked about before, didn’t like being replicated and was causing memory issues.
So I did what I normally do in these situations:
Let’s re-write the part of the engine that’s giving me trouble!
Me (with too much enthusiasm)
So just like melee, we ask the client for where they want to throw the projectile (and have the server validate that they don’t want to actually start the projectile in Antarctica), and then figure out where it needs to go on the server.
From there I made a handy little struct that acts like the TargetData that was misbehaving, and I tell it where it needs to travel to.
To wrap that up we are also re-using the projectiles so it’s only a little expensive the first time you use Pierce. Any other casts will re-use the projectile you already spawned and the response will be buttery smooth.
I then went ahead and finished part 2 of Pierce, the Hold version.
This one didn’t take as long as the main part was figuring out how to stagger the spawning, and re-use the projectiles, but yeah!
Jump Compression
Up next there was some weirdness happening anytime characters jumped, their feet would go through the floor, which was giving Anthony some headaches.
I figured I could tackle this in a procedural way.
We’re already using an IK Control Rig to adjust characters feet so they don’t clip through the environment, so instead of what we were doing (applying an additive compression animation) I figured we could just push up and down on their pelvis control which should mimic a little bounce from landing.
So after setting up a little event detection in the animation blueprint, we can control how much each character recovers from a landing whether they’re walking, jogging, or sprinting.
Grappling
Now for the main event, grappling.
In our last public build we had quite a few networking issues with Dawksin’s grappling hook, and this was the time to address it.
The ability logic was supposed to keep track of:
- Launching the hook
- Detect the hook landing
- Reeling you in
- Allow detaching mid-air
- Allow Some control while moving
and the movement logic itself was also handling keeping track of:
- Your location
- Where the hook location was
- How much control you get while moving
- Self-Cancelling when you let go
It was fairly complex, and not easy to debug.
So this time we started fresh and said, ok let’s revisit what tools the engine has to do this. Turns out if we flip a few flags with our movement component, and tweak some of their movement tasks, we could make the hook a little easier to debug, and perform better under bad network conditions.
This is the big ol’ task I ended up repurposing. It looks a little imposing, but it has all the knobs and levers we need to adjust the hook.
If we take a look here, you can see the positions being calculated and interpolated to get you the control you want, while still moving towards the hook.
The nice thing about this is we should be able to hook onto moving targets!
But that’s for later.
And that about wraps up this week. See y’all in the next one