Devblog 99.1

Helk has done a first pass on the tech tree this week. This is the order, and the chain in which stuff unlocks as you level up. This is just a first pass, and at this point just shows intention. We'll need to do a lot more playtesting to balance it out. I had to go through an refactor a bunch of code this week. I wanted to add a stats system so we could trace when people were getting XP and how, and what they were spending it on. This helps balance out the system. I spent a bit of time working on the UI too. I added a tool-tip system, which is proving to be useful. There's still a lot of work to be done, but it's getting to where I want it to be. Crafting is on its own window now instead of being crammed on the right of the inventory. Timeline wise, we're looking at 1-2 months to being able to ship this to the main branch. We're determined not to push it until it's done, we're happy with it, and it's polished. There was talk in the week about the skills system, and a worry that people are going to level up and have 1000 health and 500 jump height. We've actually talked ourselves out of the three-pronged skills system as mentioned in the roadmap. We want something a bit more bespoke, that we can get real specific about.

You know what sucks? When you open your door but you accidentally look at the lock and unlock it. Then you forget to lock it. And people get in your house. And then you email us about all the hackers that fly into your house and there was no way they could have gotten in without hacks. So now when you look at a lock the default action is to control the door, to open or close it. If you hold down USE it'll show menu options to change the code.

A lot of people are confused about the websocket RCON stuff I mentioned last week. They're under the impression it's a new UI for people to control their servers. It's not. It's a new way to talk to servers, a way that can be done in the browser. This week I put a repository up on github with the source of a test client I'm making. This isn't anything special right now: I'm mainly using it as a tool to visualize data from the XP system to easily spot problems, or just to query where someone got all their XP from. Feel free to get involved and make pull requests. Especially if you're a web developer and can make it not look like shit.

I’ve added some new pickup/drop sounds to items in the inventory screen. Loot is one of the biggest parts of the game, so I wanted to make handling your loot a little more fun and physical, and add another distinguishing layer to items. Right now these sounds are all material based and not actually specific to individual items yet, although I may do individual sounds for weapons. I’ll be continuing this by adding sounds where this first pass doesn’t feel right yet (we only have a high-pitched metal sound right now, which feels wrong with things like the rocket launcher, for example).

I spent the end of last week reworking train yard and water treatment plant level design. To me, they suffered the same issues as powerplant (that I have reworked too) if not more: unbroken long line of sight with hardly any cover. Trust me, it won’t be perfect in this iteration as there's still fairly long line of sight without cover on the WTP, but I have tried to put more thought into how I offer cover when transitioning from one side of dungeon to another. Most of it came through creating pockets in which you will feel more safe/self contained, until you decide to transition to the next one. There’s still a big advantage in all dungeons to the players who can reach vantage points. I’ll be observing these and if they do need a nerf I’ll balance them out. I also finished for good my first pass on sewers, after last week I still had two big rooms to finish, they were a bit more unique than the rest of the kit, so I kept them for the end.

There were a few bugs with explosive rounds that have been fixed. Firstly, they were doing double damage to some objects, namely the double doors. Secondly, they were not dealing splash damage to the target they directly hit, which meant you had to sort of aim away from something to deal explosive damage to it. Both of these issues have been resolved.

Let me explain how decay works (for objects it applies to): basically there is a Decay Duration and Decay Delay. Let's say something has a Decay Delay of 8 hours, and a Decay Duration of 24 hours. This means that after 8 hours, it’ll start decaying and over the course of the next 24 hours be reduced to 0 health. Opening or closing doors resets the Decay Delay in a radius of 40m around them. This way a base that is frequently used won’t have things decay around it. Unfortunately this isn’t enough, and decay really needs to be redone soon, but for now I’ve also added it so when you repair an object it resets its Decay Delay just like doors do. This should help with maintaining external walls.

For the longest time, when someone’s connection was interrupted (perhaps on purpose, perhaps just from a CPU hang) and then re-established, the server would go ahead and process all sorts of data in one go. This means you may have seen someone running and shooting, stop for a second, and then all of a sudden a shotgun-like blast of bullets comes out of them when their connection is re-established. I put an end to this today! We’re now tracking weapon re-fire rates on the server properly, and if you try and fire faster than you should we reject those packets.

One of the biggest issues with the current character is no-one really feels like a living, breathing person. A big step towards that is having some believable facial animation, even just having some subtle eye movement can go a long way. I had to make some amendments to all the heads this week to account for the new teeth meshes, so I took the opportunity to throw in some eyelid bones and properly align the old eye bones. The result of this means the eyelids will follow any eye movement in a realistic manner. I'm no animator, but some quick tests already look quite convincing, and give some indication of what a more fleshed out facial rig could achieve.

I reduced the default world size from 16km2 to 9km2. Server owners can of course still set the world size on their end and go back to the bigger maps if they prefer those. The reason for this change is that we ran a few official servers with 4km2 maps and quite liked the gameplay they offered. I think with the old map size most people never actually got to see all parts of the server they played on within one wipe cycle, and the smaller maps feel a lot more engaging due to the higher frequency of player encounters. Anyhow, this isn’t set in stone and will probably be tweaked some more in the future, but let’s give it a shot and see shall we?

I fixed a decent amount of bugs in the procedural maps.

• Fixed floaty arid/beach trees
• Fixed rocks sometimes spawning on warehouse
• Fixed rivers sometimes intersecting warehouse
• Fixed occasional sawtooth terrain glitch around monuments
• Fixed rivers sometimes starting at insane slopes
• Fixed a number of rock formation prefab issues
• Fixed missing icebergs
• Fixed small static rocks occasionally spawning midair

I took another stab at our procedural rock group spawns. They’re now more clustered and spawn small clutter rocks around the bigger ones.

We had some reports of people being able to take out the helicopter by staying in the dips and valleys at the dungeons without taking fire. Turns out the trigger that is used to let players go beneath the terrain was on the wrong layer and was blocking all server projectiles. This also meant that rockets would not pass through these layers. This is now fixed.

We've had some issues related with ocean tessellation for over sometime now: fog mismatch with the rest of the environment, lack of wave displacement further away and z-fighting. To support all kinds of hardware our mesh tessellation had to be static, which is fine for what we need. The problem is that we weren't getting the most of it due to our simplified model. To address those issues I decided to switch to a better mesh distribution that uses camera as reference. All detail is now concentrated within the visible area and better laid out across the frustum so we can now get displacement all the way from beginning to the end of the camera view. I also toned down the simulation to reduce single direction waves. Unfortunately, it didn't do as much for z-fighting as I hoped for and we'll have to take more drastic measures to solve this problem.

Tom’s begun work on sculpting up the rad boar. This week I took his starting base model and painted over it, developing the idea a bit further as to how the skin should look and overall anatomy of the thing. We don't want these looking like cartoony MMO mobs; we want realistic tumours/skin diseases and warped skeletons/bones. I like the idea of creepy, expressionless eyes. We'll probably bounce back and forth on this solving problems until we get an awesome (disgusting) end result.

You might not see much from us next week. We've decided to start doing 20% time studio wide. We're starting this with a week-long break from our main projects to experiment on anything we want. This will probably turn into a day every week in the future. Some people are using this to make prototype games they've had idea debt over for a while, some of them are using it to sharpen their tools by learning new skills. These are previously things that people have been doing secretly at night or on weekends, to avoid the guilt of abandoning their main project. Which is bullshit. Either way this shouldn't be seen by the community as something that is done to the detriment of Rust, as I'm sure it will be regardless of what I say here. This is us making ourselves better. Oh also, the week after we're all going to GDC, so we probably won't get anything done in that week either. But don't worry: I'll post about why you shouldn't freak out about that in next week's otherwise empty devblog.