Devblog 157

This week I have went back to working on the rocket factory building. I have focused on finalizing the floor layout and creating a jumping puzzle inside the building. The puzzle requires some tricky jumps alongside cranes and broken beams in order to access the higher levels of the area, where we plan on placing some higher quality loot. In addition, I’ve been working on finishing the interior geometry and textures, as well as general polish.

For a while now, I've wanted to try out what movement would look like with some more reactive animations in first person. By that I mean having a separate animation for running, anticipation for directional changes, overlap and settle on jumps, etc. Whether this ends up going anywhere or not it's been an interesting test. At the very least, changing the pose when running seems to make the movement feel more urgent, IMO.

I went over some of the player animations and noticed we were missing lateral climb animations. I added couple of climb animations for when the player is climbing to his left/right, so climbing rope walls should look much more natural now. I also fixed some slight glitches with the walk/run animations.

Music was my focus this week. The new system is capable of everything the previous music system was now, and we gained some immediate benefits & flexibility from the timeline based approach we’re taking over the rigid sections we had previously. The new editor UI is finished and a lot nicer to work with now. I added multi-selection and the ability to copy intensity restriction/fade settings from clip to clip this week, which is a huge improvement over the old UI. Not super exciting for you guys, but it helps my workflow a lot. I started working on a couple new features this week now that the foundation is nice and solid. First I’m adding the ability to place special clips in the timeline that can give me precise control over when intensity reduces. Right now music intensity holds for a few bars when it’s raised and then starts to slowly drop, which doesn’t always feel as snappy and responsive as we want. Adding these control clips will allow us to drop intensity more drastically in spots that make sense musically (under a main drum hit so that the tail of the drum rings out over a low intensity melody that just started, for example). Second is the ability to specify fade in points on a clip by clip basis. Right now clips can fade in and out as they’re playing, which keeps us from having to wait 8 bars to bring a more intense track in, or to drop out a melody. We can also prevent certain clips from fading in or out, and can specify fade in and fade out times for individual clips. This works alright, but it can sound really awkward if a drum track fades in when a long drum tail is ringing out after the initial hit has already played, or when a recurring melody fades in half way through a musical phrase. With the ability to specify fade in points I’ll be able to drop a fade in point just before every drum hit on a drum clip and always have the drum track enter on a hit, or to place fade in points at the start of important phrases in a melody so we know the sections of a melody will always play in full. After those two are sorted I’m going to experiment with a few more ideas for special control clips to allow us to do things like loop x bars while intensity is above a certain level or skip the next x bars unless intensity is below a certain point, and randomly jump to one of a handful of playback positions. I’d like to add the ability to randomize regular clip playback a bit more too. I may also change the way intensity works so that we can drive music changes with more than one parameter (turn sadness up when you die, turn wolfiness up when a wolf is chasing you, etc). I’m still trying to decide if I want to drive sad/happy type mood changes within each song or just handle it by switching songs though, so I’m not sure if I’ll implement this part yet.

I made a few minor tweaks to sounds this week as well. This was mostly bringing levels down on a few sounds that felt a little too loud after I dropped levels on most super loud stuff last week.

Setting up early on a wiped server last week, I managed to scrape together some tin cans, gunpowder and junk from the caves to produce an Eoka with a few rounds of ammo. Some asshole was chasing me and I blasted him point blank--thinking it would be a clutch move--and he wasn’t even phased. Eoka needed a buff. To that end, I’ve drastically decreased its aimcone so that more pellets will actually hit the target you’re aiming at.

I guess the Muzzle Brake was a little OP after all! I spent some time testing it in a controlled environment and its TTK was nearly the same with and without, except you didn’t have to control recoil with it. This was unintended. It really was only supposed to be good up close and quickly have its effectiveness fall off with distance. To that end, I’ve made the following changes to bring it back in line with its original specifications.

• Projectile velocity decreased 20%
• Projectile distance decreased 25%
• Aimcone drastically increased

What this means is the bullets take longer to reach their targets, their damage falls off sooner, and it’s even more inaccurate due to aimcone than before. Hopefully this will bring it to a place where it is advantageous to use in close range, but terrible at long distance.

Work continued on Animal AI this week. It’s still not perfect, but I did fix a few issues. Animals will bump up and down less often, and some animals have a bit of a blind spot behind them so you can sneak up on them. Wolves and bears will flee less often, and most animals have increased health. They’ll also figure out when they’re stuck and attempt to flee. There is still a tonne of work to be done here, and things are going to keep on changing as I get better at using Apex AI, so stay tuned.

I was messing around with the navmesh settings and I reduced its resolution for the time being, which seems to have no affect on how the animals behave, but it does reduce load times to a quarter of what they used to be. In addition, CPU and memory usage seems to have dropped as well. I’ll keep on tweaking these settings moving forward and try and find the perfect balance.

We’ve been experimenting with the parameters of the anti hack system over the course of the week and improved any parts of it that were causing false positives when the detection was configured to be stricter. I think we made some good progress on most of the server side hack prevention systems this week, improving the detection rate while simultaneously lowering the amount of false positives. This is of course still an ongoing process since we have to do these improvements one step at a time so we can verify the changes on the live servers.

I added pooling support to a bunch of fairly common entities that were still missing it. This reduces the overhead when their objects load in and out of the world, eliminating frame rate drops in the process. The affected entities are as follows:

• Animals
• Locker
• Search light
• Water catchers
• Recycler
• Repair bench
• Turrets
• Hidden stashes
• Wildlife traps

I added a feature this week that allows you to name your shops! When people mouse over the icon on the map they’ll see the name. It’s limited to 32 characters right now, but it should help shopkeepers differentiate themselves from all the other little green dots on the map.

One of the major issues with community hack reporting were cheaters that either scrambled their name or changed it to the name of other players on their server. This made it difficult for people to find the person they want to report as a hacker. Given that we allow a massive set of unicode characters in player names simply disallowing exact duplicates of other people’s names really doesn’t address the core issue. So what I ended up doing was to change the death screen to show the name the other person currently has on Steam rather than the name that’s cached on the server. In addition to that I changed the F7 player selection such that the last person to kill you will appear at the top of the list. This should help make community hack reports easier for you to submit, more reliable and easier for us to process.