Devblog 99

More music this week. I’ve been looking at screenshots of sunrises in Rust while writing this one. I’d still like to add another melodic element that can switch off with the main lead sound, spice the drums up a bit more, and expand the higher intensity sections, but I’m pretty happy with where it’s headed so far!

By default we use an RCON system that works a bit like the Source Engine protocol. This was done this way so we could use existing tools. It's a well-used, well-documented protocol, and everyone knows how to talk to it. Websocket RCON is the future. It works pretty much the same, except any browser can communicate directly with it. The benefits of this are pretty self explanatory. You can make a comprehensive RCON tool in your browser with a single html file. No need for a server back-end. This new system doesn't sit side-by-side with the old one, but replaces it, so it's disabled by default. To start your server with websocket RCON add "rcon.web 1" to the command line. My hope is to have a simple, open source web app on githubpages that the community can contribute to, which anyone will be able to use from their browser on any device or OS within the next couple of weeks.

The reactive target deployable is in. It’s not a game changer or anything, but it should be a fun addition for those who want to set up killhouses or target ranges. It has the added bonus of needing to receive the same damage as a player to be knocked down, and the bullseye does headshot equivalent damage and has a special particle effect to notify you. After it’s been knocked down simply press E on it to raise it back up and use it again.

I've made the XP system live on the pre-release branch. It's a bag of shit right now, so don't bother trying it yet. It's running on Unity 5.4 beta, so it's particularly crashy. My guess is that they're looking to release 5.4 in time for GDC next month, so it should hopefully stable up by then. Having Rust running on it and highlighting the crash problems should also make both products better. One thing I want to address this week is the fear that you won't have to loot anymore. Players are concerned that they'll no longer have to explore and loot because they can learn blueprints by gaining XP. This is true for the most part. Our intention is to make loot more relevant in other ways. Right now a lot of the stuff in Rust is crafted out of raw resources like wood, metal etc. We want to make that more logical. Say you want to craft the Tuna Can Wall Lamp: you'll need to find a fork and a tuna can. You can't just magic those up, you need to find them in loot. This would serve to make the sophisticated late game items more precious, because you'll have to find rarer components.

The guys in Slack got the Linux server working, and I applied their changes to main. You should now be able to download the Linux server and get it working right out of the box. We've had one of our official servers running for a week on Linux now, and it seems just as stable as Windows. I can't confirm any other memory or CPU benefits to running the server on Linux, since it was a fresh server it's hard to compare. The biggest benefit to running a Linux server is that it's free, which can be a significant saving depending on how many servers you're running, and where you're hosting them.

Ready for more progress on the dungeons? This week I have sewers for you (see the header image, too): Some aspects in these screenshots still require more work: the decals in particular. We need to write a decal shader that can read shadowing information from the scene to avoid the odd lighting showing on them. Such a shader should also help with reducing the Zfight that the decal meshes currently produce (when the picture depth buffer lacks precision surfaces start to flicker). We also need to work out some kind of vis-area volumes soon in order to cull the exterior meshes when we are in tunnels because direct light goes through the terrain into tunnels and it looks like horseshit. Once we get all that sorted out, we’ll be able to lay some more interesting atmospheres in interiors.

I also completed the pipeline set art this week:

In Rust we use a load balancer on the client to do any work that can be delayed in a way that it doesn’t take too much time per frame and instead tries to distribute the workload over multiple seconds. Over time more and more stuff was thrown at this system and we ran into problems where the backlog queues would grow too massive on old hardware, especially when flying around in admin mode. To fix this I made the load balancer a bit smarter this week. It now takes more time per frame the longer the work item queues are getting, which should make huge backlogs a thing of the past.

I pulled the trigger on completely retiring the stability warmup on server start. If you remember I added stability serialization a couple of weeks ago which made the server startup a fair bit faster, but we kept an initial stability check around to make sure everything was working correctly and allow people to load up old savegames that haven’t stored any serialized stability values yet. With this check now being gone the server restart time should improve quite a bit.

This one really got Twitter excited. The idea behind making the kill command injure you the first time you enter it and kill you the second time was to disencourage people from using it all the time. However, it really didn’t change people’s behaviour at all and was simply annoying. From now on when you enter kill in the console your character dies immediately. To those of you who now think it’s the end of the world as we know it because they liked to enter the wounded state to annoy people: There’s been a command to enter the wounded state for a while, it’s called injure. While I was at it I also fixed the issue that your active item didn’t drop when you died without entering the wounded state first, which has been bothering me because it meant you sometimes had to look for a weapon on the ground and sometimes you didn’t.

I finished a female Asian head variation. I might make a few tweaks in the texture, and I'd like to take a look at how I handle the eyebrows across all of the heads eventually, but it's close to being ready for now.

The new player model’s got a new set of teeth. Should have them finished and in game by the end of the day.

I made some changes to the way screen-space ambient occlusion works to integrate it better with Unity's physical-based lighting and avoid overshadowing in direct lit surfaces. Screen-space AO is now merged with texture-based AO in the appropriate stage of lighting since they represent essential the same effect just at different frequencies. A nice upside is the elimination of that persistent grass darkening we've had for a while:

Garry implemented the female clothing system, so female players have their own sets of certain clothing items. It's only a subtle change but it can make a lot of difference recognising player silhouettes, plus it won't look like they're wearing body armour under their t-shirts.

If we take food preservation in a more realistic direction I think some form of keeping your food cold will be necessary, so I did a few concepts for an icebox.

Players are creative and often create their own games inside Rust that were never intended. This idea is meant to act as a tool to facilitate that. I’ve imagined a few ways I could see players using a paintable wall spinner, but I’m sure people will come up with many more creative uses for it.

This week I was thinking about types of creatures that might be cool in Rust--apart from animals--and thought that stuff based around urban myths. So I worked up an idea for Bigfoot, but with a bit of a different spin from the usual ape look. He is more of a humanoid mutated to be larger and hairless from radiation and toxic chemicals, maybe even a science experiment gone awry. I like the idea of these irradiated creatures having some kind of inner glow visible only at night that shows the weakpoints needed to take them down.

If you’re not a programmer you can probably skip this section or read it when you’re having difficulty falling asleep. Something most people find weird when they get started with Unity is the way you tell the engine to destroy stuff. There’s one destroy method for everything, no matter if it’s a game object, component, script or in some cases even a prefab or asset. You can call it directly in any MonoBehaviour or ScriptableObject or, since it’s a static method, on any of the Unity component classes. The problem with this is that you really have no way of getting any sort of errors when doing things you shouldn’t do. You can call Texture.Destroy(gameObject) and nobody will complain, because what you’re really doing is Object.Destroy(gameObject), you just might not be aware of it. You can also do GameObject.Destroy(this), which won’t actually destroy the game object but the current script component. And then one day you’ll write a huge project with networking and custom script events instead of the built-in Unity ones, and at that point you might need to do some cleanup before OnDestroy() is called so you add your own Kill() method. Everything’s awesome until someone, somewhere calls Destroy() instead of Kill() on one of those entities. Even if you detect this in OnDestroy(), you won’t have the stack trace to check where the error originated from since OnDestroy() is actually delayed until after all frame updates have been executed. This is pretty much what we ran into last week and debugging it wasn’t exactly the most fun we ever had. To make this easier in the future and most of all get some sort of error the second we commit incorrect code to the dev servers I added our own destruction methods that can tell us when we’re doing silly things. Let’s hope this will save us some time in the long run, and if you’re a game developer working with Unity seriously consider doing this sooner rather than later.