Devblog 107

In an ongoing effort to make the players in Rust seem like living, breathing people I've been working on some blendshapes. These blendshapes combine normal maps and morph targets to try and get the realistic feel of skin and muscle moving over bone. Primarily these will be used to indicate the state your player is in: if someone's hungry and cold they'll look depressed, or if they're alone in the dark they might look terrified. There's a lot of scope with this stuff, like the possibility of advanced emoticons or even your avatar displaying emotions of the words you're typing in chat.

This is something that goes hand in hand with the blendshape work I've been doing. It's also not necessarily an indication that beards and hair will be in any time soon, but it's more a case of ensuring anything we do now with the player model will be compatible with hair in the future. These are early tests, mainly for checking that the hair works with motion on the face, specifically combining head variations with emotive blendshapes in an efficient way. We're using a rough mesh that Matt worked on a while ago and it's still subject to performance checks so a lot could change. It's worth noting that this work encompasses all hair, not just beards, so don't worry if you're female: you'll get cool stuff too.

Further to last week's introduction of the water barrel and bucket, I’ve extended the water system significantly. I’ve added Salt Water, which obviously comes from the ocean and is not for drinking. You can still put out fires with it, but taking a swig will damage you and make you spit up some of your water/food.

Fresh water can be found at lakes and streams... basically any place above sea level. It works like the old water did: replenishing your hydration and giving you some health benefits. However, it has been nerfed not to provide any additional health beyond 40hp. I’ve also added a new item, the Water Jug, which is basically a larger version of the water bottle.

Further to the aforementioned changes, I’ve gone through and made some changes to the metabolism, specifically that you will lose a lot more calories by running through the world and using tools. You’ll also use up a lot more water from prolonged high activity levels and from being in the heat. If your hydration level drops too low you won’t be able to sprint anymore until you take a sip of fresh water and beat the heat. I’ve also halved the amount of calories/hydration a player can store on their body. These numbers might be off and may need some rebalancing, but you shouldn’t have too much trouble finding a source of fresh water as you can now drink directly from the world by looking down on any body of water and pressing E (avoid the sea, though).

I’ve gone through and changed the Bota Bag to work similarly to the water bucket. This means you can fill it up at any water source and drink directly from it with left click, you can also pour it out to put out fires. It has a lid so you can store it in your inventory for later! I’ve also reduced the crafting cost to 15 cloth (instead of 100 and 30 animal fat, wow). As a default item it shouldn’t be too difficult to find the resources to craft one and stay hydrated. Swig on!

One of the things I didn’t like about bleeding was how quickly it killed you. Bleeding out in a matter of seconds isn’t really what I was aiming for, so I’ve gone through and nerfed this to do about a quarter the damage it did before. If you’re injured you might have time to actually craft a bandage or find help before you succumb to your injuries. We’ll have to see how this plays up and will probably need some more balance tweaks, I’ll be listening.

With the introduction of the Water Jug and the Bota Bag, I’ve doubled the storage capacity of the water barrel and the bucket to make them more viable for holding/transporting very large amounts of water. This will be more important in the coming weeks when we add a desalination deployable to the game (see Howie’s section).

When we think we make performance better, we don't have any way to prove it. We're blind firing into the dark, hoping we hit something. That's terrible. I've been talking for a long time about how we need to have a benchmark, and we need to run it on the same computers, on every build, over and over again. That way we can compare a changeset to a previous one and have hard evidence that one set of code is faster than another. So this is what we've started doing. We set up a bunch of servers with hardware points we want to target (out of whatever was lying around). So we have a low spec one, a mid-range one, an iMac, and a couple of others all running the benchmark on every version of Rust we build and posting the results to the website. Then we can go on and see if results are consistent across builds. So if we update Unity, we don't need to ask around on reddit if performance is better or worse, we already know if there's any change. Share Your Benchmarks You can get involved too: just open the game, open the console and type in benchmark. It'll run a bunch of tests then open a webpage with your results. You can share the URL with your friends or with us to see what kind of performance you're getting. Here's my work PC. If you keep your results together you'll be able to compare your results across versions, and flag up any performance changes with us. The game's performance has been totally shitty recently, and has gotten worse. This system was important for us to add-- not only because it tracks positive changes--but it should also allow us to identify and rollback changes that make stuff worse. The results of the tests are shown in milliseconds, where lower is almost always better. We'll add more benchmarks over time: when we want to prove something to be slow, when we want to see if an optimization has worked, etc. Here's a quick explanation of the current tests. Player Model Render and animate hundreds of player models. This speed tests our animation code, rig and mesh skinning. PlayerModelRebuild When a player model is shown for the first time, or when a player changes clothes, we have to rebuild the model. This could be a potentially slow process, especially when a bunch of sleepers spawn in, so we want to keep an eye on the performance of this. Procmap.Gen How long it takes to generate the procedural map? This is the huge majority of loadtimes on Rust right now. We want to improve this, we don't want it to get worse. This is also very hardware specific in terms of times, ranging from 30 seconds to 3 minutes. ProcMap.Normal Render the procedural map with grass and decor, but no trees. It's surprising to me how slow this is, because we previously assumed that bad frame-rates were down to the buildings. If it's slow even without buildings, then we have problems. ProcMap.noGrass Lots of people complain that the grass is the cause of performance issues. This test is to prove that right or wrong once and for all. ProcMap.NoDecor Decor is things like bushes, flowers, driftwood. This test is similar to the grass test, we want to see how much these things affect performance, and whether they should be enabled or not. ProcMap.Rain Does the rain lower frame rate? It has historically, is that still the case? This test seems to suggest that having rain on improves the frame rate... which might be because of fog. SkinnedMeshCollider This test shoots a bunch of invisible bullets at a bunch of player models to test the speed of the hitbox generation. This is a potentially slow operation, and the same code is used for a bunch of different things that can potentially be called every frame.

I did some more work on performance this week. I fixed an issue where extreme frame rate drops could occur when looking at or near players in certain situations, which could even happen from far further away than the allowed interaction distance. There’s still some room left for optimization in the skinned mesh collider that’s used by players, but this was certainly the most extreme performance issue. I also eliminated frame rate spikes caused by our player mesh building and collision initialization whenever sleepers or players were being streamed in from the server, which happened pretty much all the time when walking around.

I added a new interaction concept called the 'self interaction menu'. Up until now only networked entities could provide interaction menus, which could be used by pressing or holding down E. For drinking we also needed networkable interactions for static objects like rivers, lakes and oceans and the way I solved this was to add a self interaction menu to the player that can be accessed by pressing E whenever you’re not looking at another interactable entity. The self interaction menu options can be conditional as well, so for drinking we can do things like only showing the option when you’re near water. This is currently only used by the new drinking mechanics, but we may find some other use for it in the future. Maurino’s section has info about the new drinking system.

I fixed some issues with our deployment system. The most annoying one being the fact that certain deployables were extremely difficult to place right, like storage boxes on shelves. I also fixed some exploits that could allow you to place deployables at angles that were far too extreme to make sense.

There was an issue with our looting line of sight check that allowed people to loot through tiny slits between building block colliders. This is now fixed.

I’ve been wanting to add this for a long time now and finally got around to doing it this week. Projectiles now change their path in a fairly realistic way whenever they penetrate objects. How much their path changes depends on the surface and projectile.

I debugged an issue that made client side colliders of certain resource entities slightly offset compared to the server. This was the most noticeable on ore nodes, which occasionally made you rubber band when crouching on top of them, but could have been an issue for some other resource entities as well.

There were a couple of issues with the way we rendered and recycled chat messages. This could cause performance drops when the chat was very busy and on certain modded servers people could exploit it to intentionally fuck up performance for other players or even cause their game to crash. All of that is now fixed.

I’ve made some vomit sounds in case you’re dumb enough to drink salt water. I made a bunch of retching sounds with my mouth and recorded them, and then poured some chunky soup back and forth between a couple bowls and recorded that. I then took those sounds, chopped them up and layered them together. I also added a bit of water being thrown on grass (which I recorded for the water bucket last week) and some extra wet plops from me dropping a mashed up cantaloupe on the floor that I recorded a couple months ago. Working on this made me really glad that I don’t have a weak stomach because they’re pretty disgusting.

I’ve recorded a few more footsteps this week. I’m pretty much done updating the regular shoe footsteps. Barefoot is next. There’s a bit more weight and clarity to them and a lot more consistency between different surfaces. I’m also expanding the number of variations we have for each surface type. We’ve got four per surface right now and I’m aiming to at least double that. I’m working on this alongside the mix changes so you can’t hear these in game quite yet, but here’s a little preview of some of the new ones vs the old ones. They sound a little weird presented this way since the pauses between sounds are a little bit too long, but you can get a feel for them at least. You’ll hear the old dirt footsteps, the new dirt footsteps, old grass, new grass, old sand, and then new sand.

I’ve been chipping away at the mix work again this week. I’m getting pretty happy with how everything is sitting together right now, so there’s a good chance I’ll merge this to the main branch next week and continue refining things as we move forward.

I just completed these buildings today and it feels good! It was representing a huge chunk of the dungeons greyboxed material (that some of you still believed was our final art). Some buildings are left to be done, such as the water tower and a few medium sized structures. Overall this is helping greatly with the look of most dungeons.

I finished converting all of the old player animations over the the new system I started working on last week. The new player animation system uses far less memory and is also much more optimized. This new system also fixes some issues where it wasn’t displaying where the player was actually pointing with 100% accuracy.

I set up the bow/crossbow to display different arrowheads depending on the type of arrow the player has equipped. The arrow heads were modeled by Tom Butters and come in five different flavours. Here’s a sample of what some of them look like.

I went over some of the animations for the horses and bears and made some improvements to their attack animations. The new animations are much smoother and have more weight behind them.

I’ve been working on some concepts for some of the upcoming player structures to handle water.

This week I’ve been working on the water dispenser that Howie concepted. It’s a deployable, so you’ll be able to stock up on as much water as you want. Thanks to Vincent for his awesome textures. You can take it for a spin below too!

I've been working on a primitive solution for attaching tools and weapons to players. We're considering having the player spawn with a simple harness, so right from the get go they can sling spears and hang tools visibly off their body.

Now we have Taylor's kick-ass new female models I thought we should look at adding some more female-styled wearables, starting with low-tier tribal type stuff that can be crafted quickly from hemp cloth. *I made those names up. Well done for scrolling all the way here for clarification.