Devblog 168

The loot at the launch site is really good, a little too good. I think we need something to guard it, so I've taken this opportunity to grab some low-ish hanging fruit and work on the Bradley APC we had modeled a while ago. It's not ready yet, but I've got all the physics set up properly and I'm just about to begin implementing the rudimentary AI it requires. I hope to have it patrol the launch site and blast anyone trying to get into it. Check it out: With thanks to Rustafied for the header.

Navmesh has been the topic of this week. I've looked at ways to achieve zero navmesh generation time on server startup, to only have navmesh generated where there are actual NPCs, to only generate it when players are close enough, and to render NPCs dormant when players are too far away to interact with them. I've also looked at giving monuments hand-crafted navmesh that can work together with the generated terrain navmesh. The monuments have much more tricky geometry to traverse, and could benefit from more hand-crafted navigation data How much of this makes it into the actual game remains to be decided, but the overall result should be better performance and lower memory consumption. I will continue with navmesh into next week, but hopefully find some time to dabble in NPC behaviours as well. In the screen below, the pink stuff in my screenshot is hand-crafted while the blue is generated.

We've received a number of complaints about the game taking an extremely long time to load into the main menu on certain machines, particularly when it's not on an SSD. I traced the cause for this back to loading the asset bundle manifest file a couple of weeks back, but the fix was a bit more involving and due to the higher workload leading up to last week's wipe I haven't found time to implement it until now. To fix it I dramatically reduced the amount of data that has to be loaded when reading the manifest file, which makes this step nearly instantaneous.

The inaccurate colliders used by stairs and foundation steps must have been one of the most annoying things in the game. Vince made new, more detailed colliders for them all and I made sure to integrate them in a way that doesn't sacrifice the smooth movement when walking on them. This means projectiles and physics objects now collide with a very accurate representation that has all the individual steps modelled out, so you can shoot through the gaps. A cool side effect of this is that you can deploy small objects like lamps on the individual steps and they will correctly face upwards. I replaced the shadow casting proxy meshes as well, so light can now finally also correctly go through the slits between the individual steps.

While Pål was working on optimizing the navmesh baking process he noticed that the terrain collider was a major bottleneck in the navmesh generation procedure. We tracked this down to Unity having to generate the full terrain mesh whenever the navmesh was refreshed, which could take a very long time and made the baking process much slower than it had to be. I implemented a custom way to create those terrain meshes in a way that they can be cached for any future navmesh refreshes, which essentially eliminates this overhead and comes with the advantage that we can split up the terrain into smaller patches to make the baking process even faster. This will tie in quite nicely with some of the stuff Pål is working on. It also means we can now exclude parts of the terrain that are underwater so they never even have to be processed by the baking routines and we can correctly carve out cave entrances, tunnels and sewer systems to allow AI to move in and out of those areas. This not only fixes some bugs with the AI navigation, but is practically required in order to support more advanced AI around monuments. All of these changes should go live with Pål's navmesh improvements, which will hopefully be quite soon.

With more and more assets being added to the game we were once again starting to get close to the maxmimum size that Unity supports per asset bundle. This was mainly down to some old item skins being forced into the main content asset bundle instead of the texture bundles due to a loading order conflict. This is now fixed, which cleared up some much needed space in the main content bundle, and should set us up for the forseeable future.

You may have noticed that the launch site, which was introduced last week, may end up with a small portion of the scene under water. It was never our intention, of course, but we lacked a way to clip water surfaces in order to avoid these situations. This week I implemented a solution and you will now get a smooth, waterless, transition into the clip zone, instead of having to watch the water magically pop out of sight: This trick will work for dynamic objects as well. For example, to clip the interior area of a raft or a boat floating on water.

Work continues on the skin texture updates, with this week’s focus on more varied face types. What’s neat about having interchangeable materials is that each new base I make can spawn a couple additional variations by blending between several meshes. I’m getting good mileage out of just a few bases at the moment, and with the addition of hair on the horizon I think we’ll have a system that offers the kind of variation we’re after, a big improvement on what’s currently in the game. And yup, not all of you are gonna be pretty!

As part of my project backend shit, I've updated the feedback system. We've got a lot of projects happening at Facepunch, and they all need a decent way to get bug reports and feedback too. In the old system you pressed F7 and a bug reporting screen popped up in game, you filled all that shit out and sent it off. This one works the same way, except you press F7 and it opens a webpage and you can report the bug. It sends some information to us so the feedback page can show a list of players you might want to report for cheating and stuff. Functionally it's exactly the same. The benefits are that it opens in a browser, can be used outside of the game and works for all of our future products. Being in a browser means there's some low hanging fruit that we haven't picked yet, but it's easily improvable over time.

This week I focused my efforts with Damian on improving performance on distant objects, and a variety of close distance assets. A lot of environment art was using the same heavy materials you see up close on distant LODs. So we simplified the hell out of those, and most of the time it's so far away you wont notice the change. We also disabled shadow casting on a wide range of assets, be it their distant LODs, or small props you actually do not need shadows cast from. It might not seem like much, but a huge portion of our static art has been combed. We're talking hundreds of prefabs. Some of the player deployables also received the same treatment. Note that if your server is a week into the wipe cycle you need to take these improvements with a pinch of salt as player owned structures are quite the drain on performance, and while I saw better framerates on an empty server compared to last week, on a busy server the gain could be masked by the player owned clutter.

I ended up doing some additional profiling and optimization on the music system this week. Nothing huge but I made some small gains and streamlined a few things a little bit more :) Everything's ready to go out, but our version control system has taken me for a ride for the past 5-6 hours and I haven't been able to successfully get my branch merged in to main for some reason. Because of that I haven't gotten a chance to do a smoke test on our staging build yet, which means you guys are going to have to wait until next week for this unless I get it sorted early tomorrow morning :(

This week I've finished up new barrel impact and gib sounds, made some minor level adjustments to a handful of sounds, and continued working on sounds for the scientist NPCs.

I've been experimenting with player hair with Diogo and I'm in the process of getting pieces in to test. There's still quite a lot that needs to be done before any kind of hair makes it in-game, but a lot of progress has been made. So far I have a short style on the male model and a slightly longer style on the female to test out how different hair lengths looks, as well as facial hair. I've also created pubic and armpit hair, which was an interesting week in development... Hair is skinned to the body which means that facial hair will move with the jaw and all hair can be set to a variety of colours and tones. The next task is to get lots of other hair and facial hair styles in and working correctly on all head and body types. The latter is going to need a fancy solution, but hopefully it should tie-in to some features in the works.