Devblog 197

Rust is leaving Early Access today. If you're wondering what this means for you, check out this blog post with all the info. This also means all existing customer reviews on Steam will show Early Access on them, so now is a good time to update yours.

I've spent essentially the entire week merging the work Vince and Damian have been doing into a complete and stable package that can be shipped in time for the big update today. This included fixes to the procedural world generation, so harbors are now spawning correctly again, and the new hilltop rocks and cliffs don't interfere with monuments and blend nicer with the terrain. Next I optimized and improved our procedural foliage placement and batching system so all the new vegetation Vince has added works nicely without impacting performance. To top it off, I went over various procedural spawn rules with some input from Vince and made adjustments wherever needed such that rivers, forests, rocks, vegetation and monuments come together to a more beautiful world. There are a lot of things we have planned for the future, but I hope everyone likes what we were able to get done in time for today.

This isn’t the first time we’ve worked on a large touch-up of Rust’s graphics. This time it's going to be a bit different: I started from the ground up, combing over almost every aspect of the game, striving for consistency.

Developing a game in a small team for years

Let me explain why it was even necessary at all. In the three years and more that we’ve been developing Rust, there’s been a large number of weekly changes to the game. One of the symptoms of our flexible development process has been a lack of consistency in our graphics, and to another extent in our gameplay. As developers in a small team, we would want these things to be perfect at any time, but we have to wear so many hats that we find ourselves moving from task to task, sometimes unable to bring them to a level of quality we want. This week for me has been about fixing this when it comes to our visuals. The big picture: undoing what it has become and starting afresh.

Why it was needed

Our visuals were a lot more neutral years ago when the reboot occurred. Visually duller, but neutral. It looked like a game built from asset store content. Then we moved away from that, replacing more and more Legacy art with our own work. We also developed tools, post processes, ocean shaders, etc. The problem was not the content created, but how all these parts of the game communicated together. There was noise. This time when reworking all of it I tried to achieve a picture that draws you into the game. I tried to avoid things that do not make sense in the real world, things that would break your immersion. And all the while doing this, I tried to understand what Rust is in your eyes, and to be mindful of how the community sees the game VS where I want to take it.

Is it complete?

Initially I worked on this as post Early Access patch, and would have released next month. But overall the response has been such that we felt we had to pack it in this current patch. What this does mean though is that Damian, Andre and I have a lot more in the bag in terms of improving the picture and pushing procedural generation. We're all incredibly happy to see your positivity towards these changes and look forward to bringing you more in our next updates.

The new trees are finally in. It took us some time to polish everything up, but the wait is over. The new meshes are fully optimized, which allowed us to increase the tree density by a good margin. There might be some small bugs present, so if you notice any please report them. Going forward, I plan on adding additional species to increase the variety. On the technical end, we're still working on improving the billboard rendering, so next month the performance should be even better. Here are some screenshots of the new trees with Vince's graphics revamp.

A few minor changes lead to some major impacts on recoil this week. First of all, the Semi Automatic Rifle was playing its idle animation while aiming down the sight! This is now fixed. I've also changed how 'aim sway' works. This was the effect that would cause your aim to sway around randomly every few seconds while aiming. I've changed it so it only is active if you've been aiming for several seconds without firing. Because it used to always be active, this meant your muscle memory was compromised when following a target with tap firing. You would know exactly how much to move the mouse, but wouldn't be able to compensate for this random motion leading to a lot more missed shots. I'm excited and scared to see how this plays out now that you'll always be able to move your sights exactly where you want them to be. This is hugely noticeable on the SAR and Bolt Action Rifle after the first shot. Also I've modified the AK47 recoil so that the horizontal pattern kicks in a bit sooner. I didn't want to go off the deep end and totally change it, but you can no longer simply pull straight down now for a 5 round dead accurate burst.

Scientists now suffer from the same thing everyone used to bitch at on reddit: aimcone. They'll no longer have insta-headshotting laserbeam assault rifles while they are just three pixels tall on your screen.

Loot Barrels now produce two Scrap instead of just one. Fire arrows cost two cloth instead of 10 (wtf), and the most used item in the game - Netting - now costs one rope instead of three. Big whoop.

Because we didn't want people to uncover single bullets from looting crates, I excluded ammunition types from the workbench tier loot tables. This same table was used to randomly pick what to reveal during a workbench experiment. Due to this you were unable to find new ammunition types via experimentation. I have fixed this.

I've completed the final set of tutorials. This includes a few tutorials for exploring and visiting a road, making a workbench and a nailgun, and creating a research table and using it. In addition to this, I've named each tutorial section which will display in the upper left, instead of simply "task list", to give players a better idea why they are doing this. I also fixed a bug where the game and menu tips were always in English, so they can now be translated to other languages.

Upkeep resource management has been extremely counter-intuitive to use. Entities were sometimes paying for upkeep far into the future, which could make the remaining upkeep time that was displayed on the tool cupboard incorrect. One example where this was especially visible was High Quality Metal. If you had a base with a lot of armored doors they were all taking one HQM out of the tool cupboard to pay upkeep for hours in advance. To the player this looked as if their metal had disappeared, while in reality it was just invisible to them as it had been converted into upkeep time that was saved on the doors. The tool cupboard then showed the upkeep time for the resources that were left without taking the upkeep times that had been purchased by the entities into account, which didn't help the confusion. This has now been changed so when one high quality metal is used to pay for upkeep it is distributed across all entities that need it without paying more than 10 minutes into the future. This means the remaining upkeep time on the tool cupboard is much more accurate and makes everything much easier to understand. Another issue that wasn't helping the situation was that doors were immune to decay as their protection properties absorbed all decay damage. This is now fixed and doors will correctly decay if their upkeep isn't paid for.

Following on from last week, I spent a bit of time creating some detail maps for the viewmodel clothing. Some of the materials already had some detail maps, but it was way too vague and didn't hold up this close to the camera, so I've created a couple of variations for some of the common material types. It's still impossible to disguise the fact the textures are way smaller than they should be, but at least it goes some way to creating a parity between the high-res weapon models and the clothing. I was able to use a secondary UV channel for the maps, which means I'm able to create a nice flow for the fabric, and also hide some of the seams which are commonly placed on the inside of the arm, where no one should be able to see them! Unfortunately these didn't make it in for this release, but I'm confident you'll see them in the next patch.

A couple of the skinnable items were missing mesh downloads, and I imagine it's pretty tricky making a skin for something without the mesh to reference. Over time, as files are moved around or updated, I guess the references on some of the skinnables broke, so I went through all the items that were skinnable and double-checked their mesh references were correct. I think seven were broken in total, but let us know if you spot any more!

I started working on sounds for the Frog Boots this week. Helk wanted them to feel squishy and squeaky and like they were saying "lol" and "kek" with each step. Getting most of this right was pretty fun and easy, but holy shit I think getting "lol" out of squishy mud sounds and a boot footstep might be the hardest sound design thing I've ever done. There's not much "L" or "aw" sound to the components I wanted to build this from, so I tried layering in some recordings of myself saying "lol". That worked great for "kek" because it blended in with the higher frequency bits in the squishy sounds, but the "lol" still sounded way too vocal. I ended up doing some really weird processing on the "lol" vocal bits to combine them with some mud recordings (kind of like a vocoder) and that got me to a spot that I'm mostly happy with. I tried building these from sounds I already had, since I started them on Wednesday and wanted to get them done in time for the patch, but I think I need to make and record some mud to get to what I'm hearing in my head. Sadly I had some computer issues and a little bug-chasing to do today that kept me from getting these in game in time for the patch, but that just means I get to play in mud and make them even better before you guys hear them.

I've continued work on the sound finalization and mix/master pass I was working on last week. I'm making good progress so far. On the individual sound front, I only need to go over weapon sounds, item UI sounds, and deployable sounds. After that I go over the entire mix at a higher level, which should be fairly quick. I really wanted to get this stuff done before we left early access, but I probably have another week or two of work left if I don't rush it, and I'd rather do it right.

We noticed some weird audio related spikes in the profiler in Unity this week, so I poked around and discovered that it went away if I set our ambient loops to play from RAM instead of streaming from disk. I'm thinking this is a bug with Unity because I'm running an SSD and was seeing 4-6 ms spikes in the profiler with only a few sounds streaming at once, which seems excessive. I'm going to dig a bit more next week and see if we started doing something dumb recently that might have caused this too, but at least the spikes should be gone for now.

From time to time the speed of animations need to be changed for gameplay reasons. The easiest way to find the result you want is to increase the animation speed via Unity's animator. The problem is that you can end up with animations set to 200%, for example, and parts of them looking like you've hit fast forward. So I've edited some this week by setting them back to 100%, but reducing the actual anim length so the duration stays the same. You're probably thinking: "Isn't that going to look exactly the same?" Well no, and this is down to a principle of animation called spacing. When you change the spacing of an animation, you're not changing its overall length, but the way an object moves over that same duration. Both of these spheres take one second to complete their animation, but the way in which they get to their destination are different. In a nutshell this is spacing. Old grenade animations at 200%: Updated grenade animations:

I've been working with Diogo for the past few weeks on getting hair visuals looking better, especially for people who opt to use non-TSSAA, or even no anti-aliasing at all. Without TSSAA, transparency is pretty much either opaque or transparent, so when not using TSSAA the hair can look very solid and not light well. This is especially apparent when looking at the finer detail towards the scalp, and on body hair etc. The current system has a "hair cap" that is basically painted hair on some geometry floating very slightly over the skin to give fake volume and subtle details, whilst being easily swappable amongst styles. However, when not using AA, you lose all of the subtlety of this map, making the head, facial and body hair look pretty bad. I've tried several methods, mostly around getting rid of transparency on the hair cap and blending it first to a modified skin layer and then later to the skin itself. This looks way better on non TSSAA and saves polygons, but it has meant that I have had to remake all the hair from the ground up to cater for the void between the floating hair planes and the skin beneath. This also means that we can do stubble, shaved bits and fades/ Stuff that I've wanted to implement but wouldn't work if you weren't using TSSAA. Rebuilding the hair has also meant that colouring will look a lot better and more natural, as well as hair having more variation in strands, rather than being one block of colour. I need to move facial hair over to this new system before it replaces the old but its nearly there.

I finished the first working version this week, just in time for the release. Going forward, the plan is to expand imposter baking to include several different directions as well as being applicable to objects other than trees. Please note the following samples are not in-game quality, and the ones on the right only show up far away: As expected, the geometry reduction is dramatic, allowing us to show a lot more of them: The quality of the baked imposter will determine how soon we can swap it in without the player noticing. Going forward, as we add more features, we should be able to slowly fade them in way sooner.

Preparing for this week's release, it was important to tackle rendering stability and polishing. Some of the low hanging fruit were addressed and a lot of the work went to ocean shore shaders, where a lot of flickering was happening with and without temporal anti-aliasing (TSSAA) enabled. Unfortunately, one of the problems was caused by water caustics shadowing which had to be disabled until we are able to upgrade Unity again. A few materials were also fixed, including military tunnel floors which were showing pitch black in low quality settings.