Devblog 117

We’re on track for merging prerelease into Main and launching the XP system on the 7th. This doesn’t mean it’s going to be perfect, it just means it’s good enough to be part of the main game while we improve it. When we merge prerelease into Main, we’re going to fork the existing version of Rust off into a separate branch, so you can opt into it and continue playing that version of Rust “as is” in case you want to. It will not be maintained or improved upon similar to Legacy, but should be fun to revisit and play in the future. Regarding progress, I finally merged “Item Ownership” into prerelease and so far it’s been a blast. There were, however, many bugs and crashes that have since been resolved. I’ll spend the next few days writing code that takes advantage of the system a little more than it currently does. Such as earning XP from using up resources, when you drink water you 'created', using your deployables (furnace/repair) etc. I’ve also got to solve a few annoying problems, such as implanting items on downed players and reviving, and giving ownership to you when looting a dead person (it was really annoying to kill someone and then not want to use their tools because you didn’t want to earn them XP). I’ll be watching and listening for more exploits and fixing them as we go. If you can’t wait until next Thursday you can always opt in to the prerelease beta and give it a try.

There's a big space free on the right of the inventory menu since we moved the crafting stuff to its own menu. I filled it slightly with the quick craft menu. This shows only items that you can craft, based on what you have in your inventory and what you've unlocked. It still needs a bit of love--to give feedback when you've actually clicked on it--because right now all the crafting stuff is hidden behind the spawnmenu, so it's not that clear.

Previously, when you shot a bullet it came out of your gun and traveled at a certain rate, had gravity and drag applied to it, then slowed down. It's as you would expect in real life, except in Rust the bullets travel a lot slower than in real life to emphasise this effect This felt like shit at short range, but it worked over long range. The shitty feeling was made worse by the fact that the bullet doesn't move until the frame after it has been fired, which means firefights were client side frame rate dependent. Which is terrible, really. So now when you shoot your gun, the bullet immediately travels a set number of meters (this is ammo dependent), and then it carries on as normal. The end result is that close quarters gunplay is effectively hitscan, but long range retains the effects of gravity that we originally implemented.

I wasted a day-and-a-half trying to get our build times to not suck. At the moment it takes just under an hour from us committing to the build uploading on Steam and playable by millions of people. A few years ago this would have been a pipe dream, but now it's not good enough. It is feasible for this to come down to about 5-10 minutes, if we compile Linux, Mac, win32, win64 and asset bundles in parallel. The issue with this is that multiple Unity instances can't compile from the same project file at the same time. So we need to mirror the project file. Which is fine, it's 20gb a project file, so we're talking 100gb for all the platforms, double it for debug and release mode, so 200gb. Except that's bullshit, because when you open a project Unity likes to mirror the contents of it to its own bloaty Library folder, so we're talking 40gb a project, so 400gb. Which is okay if you can spare it, and didn't spend a ton of money on super fast but super small PCIE SSD hard drives. But then it turns out, after a day of programming, that Unity 5.4 hates running in parallel anyway, so it was all a big waste of time and effort. For some reason, when multiple instances are compiling it keeps losing its license, so I have to manually log in and activate it. Then there's some port conflicts when compiling shaders, so it just hangs indefinitely. It would have been nice to get it working, to make us more agile, but fuck it for now - I've already wasted too much time on it.

We're entering a fix and polish stage of the prerelease branch at the moment. The basics of it are done, so it's about going back over stuff now and improving. The pie menu got some performance enhancements. I also updated the animation to make it a bit more fluid, so when it closes you can move your view immediately instead of waiting for the animation to finish. I went through the UI fixing the scroll speeds of various panels that were scrolling too slow when you moved the mouse wheel. I improved the look of the crafting queue, and made it more obvious that clicking cancels.

There wasn't any feedback on levelling up, beyond the level number increasing. It should be a song and dance. I added a new HUD system for notices, so we can queue shit up there. Now when you level up it pop up a notice and play a sound. It'll then list all the new shit you just unlocked. The sounds are hilarious and placeholder. I'm sure Alex will find his way to making it some eagle sound or something... just as soon as he catches one.

We do listen to you guys, and I know we were a bit dismissive and rude about lone wolfs last week, so I wanted to surprise you guys and prove that we really do pay attention to what you want. So from now on all of the wolves in the game do 10 times more bite damage. This doesn't affect bears. Hopefully this will put an end to this "lone wolf vs group of wolf" discussion we've been having a lot lately.

Sentries aren’t used as much as they should be and because we wanted them earlier than the AK47. I’ve changed their crafting recipe to only require 75HQM instead of 50HQM + Ak47. Hopefully we’ll see them used a little bit more.

This week's been about getting all throwable weapon work onto prerelease, as well as some balancing. Have a play and let me know what you think:

I have been working on the go for the past week and managed to get stuff done at a decent pace between trips and flights. Progress on the airfield is good: I do not have many close ups shots to offer as some buildings are still work in progress, but I took some overall shots for you guys, though they're from my laptop and a not at the highest quality settings. It’s getting there and most of the buildings fell into place like I wanted.

I’ve made some good progress on the Double-Barreled Shotgun. The change from the concept to include the screwdriver handle seems to have really added to the makeshift look. Take a spin and see for yourself! I have a couple of materials to create, like the pin trigger for the springs, but that should be done in no time at all. Then onto the LODs. This weapon, like the SMG, will be customisable. If you notice on the concept Paul drew, there’s two versions: one with a longer barrel plus sights and an actual stock, so I’ll work on those when I can.

I've finished up baking down the lower half of the heavy armour. It still needs skinning and lodding, and I'd like to dull the metal a little - I think it's looking way too shiny for rust at the moment. It's nice to see it looking suitably bulky though, especially when you see its component parts.

There’s been a lot of talk about the current state of gunplay in Rust, and we mostly agree with the common opinion on this: it feels random, unsatisfying and sluggish. This week I sat down with Helk and discussed what has to be changed to make things better. It all seems to boil down to this:

• Predictability
• Precision
• Feel

To me, personally, the lack of consistency is probably the biggest issue right now. Things simply feel far too random to be enjoyable. This is caused by a number of things, so let me explain what I’ve been working on this week and our reasoning behind it all. Everything in this section is still under active development, but I’m hoping to get it onto the prerelease branch either next week or the week after. It all starts with the damage and hitbox system Rust has been using ever since the reboot. We’ve tried various variations of this but none of them seemed to work out the way we wanted, so it’s time to let go. At the moment hitboxes use the exact player model and clothing meshes as their colliders - if you hit a piece of metal you’ll do far less damage than when you hit skin or cloth. This is neat in theory, but it completely breaks down in hectic firefights since nobody intentionally aims for the tiny vulnerable spots between clothing items, essentially leading to completely random damage multipliers being chosen. I’ve replaced this with a much simpler hit area system. Clothing now specifies the body parts it protects and damage is reduced based on which body part has been hit rather than the exact visual mesh. This means projectiles never randomly bypass protective gear. It also means that gloves can add to the overall body protection instead of only protecting the hands, which makes them far more useful. The second issue caused by using clothing meshes as colliders was that clothing affected the size and shape of player hitboxes. Things like the bucket helmet, and to some degree even the metal facemask, made the head hitbox so huge that they were essentially useless. I threw this out the window so now the body part that was hit is determined by a player collision mesh that doesn’t change with clothing. We still have the option to apply reduced damage when hitting the bigger clothing hitbox and not the player hitbox, but I won’t add it solely based on guessing. We’ll see how it all works out first. Next I added the option to use per-weapon damage multipliers for certain body parts. This can for example be used to increase the headshot multiplier of a weapon type that’s very precise (sniper rifles) or reduce it for weapons where they occur more randomly (shotguns). We’re not entirely sure in which direction to take this yet, but it made sense to add support for it while reworking the underlying systems. Lastly I started working on best-fit hit detection for projectile weapons - similar to what I added for melee weapons a couple of months ago. The thinking behind this is that hitting a hand that’s directly in front of a head should really count as a headshot since players cannot control their exact animation state. I still need to figure some stuff out, but this should make things feel less random and more predictable once it’s done. Overall the changes I’ve been working on this week should help us get some much needed predictability and precision back into the gunplay of Rust. Next on the list will be weapon feel, but Helk might be better suited to tackle that.

Some of our armors definitely suck at the moment, and you see this stuff a lot so they deserve some more attention and refinement. We hate the Bone Armor the most: it's goofy and janky, mainly because it was originally designed to fit over existing stuff and protect practical areas, which made the aesthetics suffer. Now we're just making something that looks way cooler and not worrying about it fitting over other things. We will explore light/medium/heavy types of armor, so for the bone were gonna go with something that fits a light armor type, and has a more primitive feel with a mix of hide/leather and bone. Shoutout to da9L88 for his awesome bone helmet concepts the other week, I couldn't help but take some inspiration from those!

The beta version of Unity we’re using right now has been crashing a TON on OSX so I’ve been spending a lot of time working on a different FP game this week, but I’ve made some progress on the music system and finished chopping up the rest of the existing songs. I ended up ditching one of them that just wasn’t feeling right in game, and will continue to write more as we move forward. Since we’ve only got a handful of songs right now they’ll all play in any environment/time of day but as I write more we’ll start separating them out more too. I added the ability to allow/disallow individual clips fading in and out in the middle of a section of music on a per clip basis. Previously we would only fade clips in if the intensity was increasing, or fade them out if the intensity rose above their max intensity. This worked pretty well but I wanted more fine-grained control. This is really nice for things like preventing a melodic line from starting in the middle of a phrase or making sure a drum part will always play in full once it starts and won’t fade out. I did a bit more cleanup and made some final tweaks to prep the music system for launch. It’s disabled by a convar by default right now. Tomorrow (or I guess today once you’re reading this) I’ll be giving everything a final once over and then merging into prerelease so I can test this stuff out in a live server, and assuming that testing goes well this will all go live when the XP system is released.