Devblog 108

Andre did a bit of profiling at the end of last week and noticed that ambience performance was slowly getting worse while playing, so I found and fixed the bug that was causing that. This won’t really give you more FPS but it’ll keep the game from slowing down as much after you’ve been playing for a couple hours.

I’ve continued working on the mix this week. I was hoping to have it done for the patch today but I kept finding little things I wanted to tweak, so it should go live next week now. This week I’ve mainly been working on polish and consistency for all of the weapon foley. Right now we’ve got some gear/cloth movement in the background of a lot of the weapon sounds, but it’s really nasal and kind of sounds like shit, so I recorded a bunch of cloth and leather movement and replaced all that. I’ve also been going over reload sounds and gun cocks and all that. Localized tree/bush ambience got some love too and sounds way less hissy and more detailed now.

Since food and water are more important now I figured it was time for eating and drinking sounds to get some love. I recorded myself eating some chips and swallowing some water and stuck those in game. These sound a lot cleaner than the old ones and we have multiple variations for each action now. I thought the water swallowing might be hard to pick up well because I was assuming a lot of it came from vibration traveling through your head internally (fun fact: your voice sounds weird when you hear a recording of it played back because you’re used to hearing your voice with the internal resonances of your skull), so I tried recording it with a contact mic first. A contact mic picks up sound by picking up vibrations from an object that it’s touching directly instead of picking up vibrations in the air like a regular mic. That didn’t work at all, which makes sense in hindsight since skin is a bit too floppy to conduct vibrations very well. I ended up just sticking a regular mic an inch or two away from my throat, and that picked the sound up a lot more cleanly than I expected.

I’ve finished up sounds for the flamethrower, and those are in game now.

I’ve also recorded some barefoot footsteps this week on concrete, dirt, sand, grass, and wood.

Since we’ve added more usage for water, the demand for water has increased! So with that, i’ve been working on the water pump deployable. Which as the name suggests will allow you to deploy and draw water for your collection! There is a working arm that you would have to use to activate the pump - so there’s some level of manual labour involved :) Take a spin below!

One thing that really caught my attention when working on the expressive blendshapes last week was just how versatile a blendshape system could be. Changing the structure of the face with blendshapes is commonly used in character creation systems to affect single features (like the size of the nose for example) but indiscriminately randomizing this can lead to some unpredictable results because it's difficult for an algorithm to know the "rules" or patterns that a human face should be constrained to. I took some time this week to prototype a system where each player's head takes influence from a random selection of handmade blendshapes, meaning that the structure of the face will always stay within the same constraints that a regular human face should be bound to. With only a small selection of variations I'm already seeing some recognizable faces being generated:

I've spent a lot of time working on the character stuff, so to mix things up I made a start on some of Paul's female clothing concepts.

Before you read this section let me say that we’re at a point in development where no single change will suddenly improve performance by 50%, so if you expect this to happen you’ll be disappointed. We do have several smaller areas of improvement that can add up to huge gains when addressed, but it will be a long process to work through all of those. Late last week I was able to track down the performance degradation issues we’ve had and we released an update over the weekend to address those. The root causes were a pretty old particle emission script that could leak coroutines and more importantly a sound emitter leak in the ambience manager. See Alex’s section on ambience performance for more details on the second one. The update also included another optimization for the building block despawns which helped reduce frame rate drops when moving around. I started off the new week by fixing another issue that could cause frame rate drops when looking at or near players - testing indicates we finally caught all of those now. Next on my list was to look into rendering and culling itself, which is a bit more complex than finding performance issues caused by our scripts. I found that the vast majority of our culling time was eaten up by trees, or their culling event callbacks to be exact. Turns out this was caused by the way Unity handles SpeedTree wind. Removing those wind animation handlers gave me a performance boost of around 7%, which is pretty decent for a single change. With this we ended up removing the last one of the SpeedTree features, so we’re pretty much at the same spot we were with Unity 4 trees now, just with a bunch of time wasted. It’s somewhat disheartening to see how horrible these things perform in Unity, especially considering that so many SpeedTree features are still missing from the engine entirely. We’re thinking it’ll be best to write most of these things ourselves, so in the case of wind we’ll add a custom wind solution to our tree shaders with no overhead on the CPU side. To finish up the week I optimized some UI code. We have a system in place that lets us easily display any variable with any kind of formatting in a completely generic way, no scripting required. This is pretty nice to have from a usability perspective and is used excessively by all the player metabolism and health info. The downside was that the code to get and format the variables was fairly unoptimized, which made all of those variables combined take something in the order of 1ms per frame. This is now fixed and we can continue to profit from the usability without making performance suffer.

There’s been a long-standing issue that occasionally doors could randomly fail to fully close on some clients, which allowed those clients to fire at things behind those doors. This was a pain to track down, but I found a fairly significant entity slot networking issue in the process that could have led to all sorts of strange behaviour down the road, so I guess it was worth it in the end.

It was felt we could do better with the current idle pose, so I've updated it. Here's a before & after: Whilst looking at the idle, I also looked at an idea I wanted to try. I think it would be cool if the preview wasn't just an idle, but an indication of your current state. To give you more of heads up on what your priorities should be. This could be to show you're cold, hungry, hurt....... Here's a mockup of a few idles: It's just an idea. If you like/don't like it, or think it can be expanded upon then by all means make some noise about it. Alongside the blendshape work Taylor is working on, we can link these to states & get the player to start showing some real emotion. Finally, here's a line of cold naked people:

A couple of weeks ago I started experimenting with an ambient occlusion technique that can be computed and applied over a very large area (e.g. 1km x 1km) and doesn't depend on the camera direction. This particular technique is very cheap and has been field tested in other pc and console games. It supports dynamic surfaces so it can update as we build our structures or relocate large dynamic elements. These are the results so far: This will help darken our building interiors, caves, tunnels, forests, and allow us to crank up the reflections to normal, realistic values. It would work as an optional world-space, low frequency addition to our current ambient occlusion. I don't have a solid ETA yet, but I'm hoping for next week.

This week I took a break from the large scale occlusion to experiment with what's called a logarithmic z-buffer. It involves patching our shaders to take better advantage of the z-buffer/depth precision at our disposal. Artifacts caused by our poor use of the z-buffer can be especially visible on ocean water (mostly flat) against the terrain, causing intermittent flicker between both surfaces especially at far: For similar reasons, using a very wide screen aspect ratio will also trigger all kinds of z-buffer artifacts, including also see-through walls at far, because we're pulling back the camera's near plane to prevent cheating. In our implementation of logarithmic depth, we don't even have a near plane: Zooming in on a dense building structure may also cause see-through, but this effect is limited by gameplay. These are all issues I'm expecting to fix with this solution and while it's still early to confirm with absolute certainty, the results have been very promising so far. Unfortunately, however, this process involves patching all our shaders, which might take a while and introduce a ton of new visual bugs. I hope do be done modifying the shaders this weekend to get a solid week of heavy multi-platform testing on the staging branch before next week's deployment.

So this week i worked up some ideas for two different armors, one being a crafted heavy steel armor set that would basically turn the wearer into a ned kelly type juggernaut at the cost of slower mobility, might be interesting to see how this could be utilised in defense and offense. The second being Cardboard armor that could be created from trash/scrap and provide no real defense at all but allow the players to drawn on it and see what ideas they come up with to utilise it.

Just a few bugfixes relating to last weeks water additions

• Fixed water barrels not blocking building
• Fixed water bucket having drink as default option (impossible to deselect)
• Fixed being able to transfer water into an unheld bucket
li>Fixed not being able to drink the last 50ml from bota bag

The metabolism balance changes last week were generally very well received and for the most part seems to be pretty decently balanced (atleast for a first pass) The one change I made this week was to increase your starting calories from between 75-100 to 100-125, this gives you an extra 10-15 minute to find some food and should help out the completely new players. I’ll keep watching and make more adjustments as time goes on. You should probably lose water and die quicker from lack of water than from food, for example.

Currently, our fire system is simply a “Fireball” entity which can spawn other fireballs and moves around like a physics object, every second it deals radial damage to objects nearby; nothing is actually ‘catching fire’. Well I started working on this this week. Unfortunately it’s not ready for prime time but take a peek : I’m excited to get this finished so I can add fire arrows to the game that ignite people or animals on impact, with the added benefit of pre-cooking the harvested meat!