It was mostly all about building this week.
The building system was ready for art this week. So we started giving it some attention.
I made some documentation on the building prefab system to let the artists know what’s going on. It’s important to me that artists can not only make their art but they can also go into the game and implement it. This way you don’t end up with a chain of 3 people working on different things having to continually get in sync to push a bit of the project through. The programmer can put a placeholder in, the artist can make a model and iterate on it in game.. without having anyone else involved. You don’t end up with the situation where the artist is guessing things like proportions or colours, getting it wrong then the programmer sending it back to be re-done.
Bill really kicked ass on skinning the existing components. It’s looking a bit like “The Forest” right now, so apologies to them if they think we’re copying them.. we really didn’t set out to, it’s just where we landed.
We came up with a conditional skins for the building system. One of the original thoughts was that we’d get you placing corners manually.. and if you make a mess it’s your own fault. But thinking further down the line the amount of these edge case components we’d need would have been massive.
Instead we came up with a system that looks at the placed building components, and if two edges are intersecting at 90 degrees it decides that it must be a corner – so places a model. A good example of this is the foundations. If you place one foundation it looks like this.
The stones around the four sides are all conditional models. They only show if there’s not a connecting model.
These simple rules are pretty easy for an artist to set up themselves, but it’s completely modular so we can add our own custom checks. This makes me really excited for the future of the build system. It’s a new toy for us to explore the possibilities of.
Because it was getting a pain in the ass to keep starting a game and building something to test changes I made a test level for checking buildings. This works because in the editor you can host your own game and then save it.. and then rejoin. The test level is set up to load a saved game I made. When the other guys play it they see my body asleep.
This is also good for testing performance without having to join a server then trying to find a fully built building. It will be expanded over time to make sure we can support big towns of buildings.
Sleeping bag is now craftable! I’d implemented it but not made a blueprint.. oops!
Footstep sounds are back. The sounds are dependant on which surface you stand on.. but we haven’t implemented each surface yet. So if you get a concrete sound it probably hasn’t been implemented.
Unlike legacy Rust the new footstep effects are synced with the animation.. so they play when players put their foot on the ground. They also play make particles.. so dust will be kicked up if the surface you’re walking on is dusty etc. The particles are all still very much work in progress.
There was a bug where you’d get killed by someone, then respawn, then die again from the damage you’d got in your last life. This is now fixed.
We opened the experimental server up to the public last week.
The server has a linux version. It isn’t tested or supported but it’s there if the linux guys want to grab it and try to make it work. At the moment there seems to be issues with the Steam libraries. Also there’s probably no console output or input in Linux.. this command line stuff isn’t totally built into Unity.. it’s something we had to hack together for Windows.
As promised I threw up some documentation for those that want to host their own servers. This should get you started on the basics.. for anything more feel free to drop by our forums and ask the guys there.
I re-added the find command. This should help server owners figure out what convars/concommands exist.
RCon wasn’t working, but now it is. You can’t use RCon from the game anymore, it doesn’t work like that. You need an external client to interface with it. It uses the same protocol as the Source Engine’s RCon interface, with a few exceptions. Unlike Source Engine’s RCon it also feeds the console output back continually using SERVERDATA_CONSOLE_LOG.
It shouldn’t be too much of a task to write a tool to talk to it, and Boback who made Rusty is working at making it compatible.
In legacy you pretty much set a rcon password and anyone with that password can administrate your server. This seems a bit yucky. In the new version we’re having two groups that you can add people to, owner and moderator. The owner will be the server owner, they can add other owners/moderators, close the server etc. The moderators are your day to day admins.
This system is in early days but you can add your owners by running “ownerid <64bit steamid>
Since we have more than two servers now, it’s probably a good idea to make the serverlist work properly.
Servers are now by default ordered by ping. The other ordering buttons are functional too.
Official servers are back. Severs run by us will show up in official. This is to ensure we always have a healthy number of players to test with.
Double Servers on refresh
There was a bug that made servers appear twice when you refreshed. This is now fixed.
Andre has been doing more work on the terrain generation. The previous version of the terrain generator tended to have the issue of generating a world with one mountain in the middle of the island and further away was flatter and less interesting. This became more and more of an issue when we started adding biomes since especially the northern biome could really use some cliffs towards the ocean and massive mountains.
I think he’s fixed that problem. Everywhere you go now has an interesting landscape that begs to be explored.
There are still issues that have to be addressed – the biggest one being forests. We are fairly limited by Unity 4’s physics engine at this point, which is why the tree count cannot be as high as we would like it to be. We’re working on evaluating the ideal tree density – once that is found we’ll cut it down to something Unity 4 can handle and go balls deep with Unity 5.
You might have noticed some flickery shadow weirdness and z-fighting on the landscape at times. This is because we’re stressing accuracy of the z-buffer by having a really close nearz. We need a really close nearz because of how we draw weapon view-models with a single camera. We need to draw the weapon view-models with a single camera because it’s the only performance friendly way to get them to accept world shadows.
So this week I added Helk’s dynamic ZNear from legacy. What this does is push the z-near forward when there’s nothing in front of the player’s view. So if the player doesn’t have a viewmodel it tries to push the znear to 1.0f. If there’s something in front it sets the znear to 0.05.
This works. There are better alternatives to this, but these would take weeks to implement and test properly, and we’d probably end up finding them too heavy handed. But this works for now. Here’s a video of the problem.
We accidentally worked out how to use Mechanim properly this week, and now Goosey is working at revolutionizing the way we handle hold types. We were previously masking off the top of the torso and overriding that layer with the weapon hold animations. This ended up looking odd. Then we discovered the sync option. So now we’re doing it that way.
In our defense I’m not sure whether that sync option was there the first time we set it all up :)
The wooden storage box is now craftable and deployable again!
I added a notification when using voice chat. I don’t think many people realise that voice chat exists. It does. The default key is V.
Dan has pretty much finished the Thompson!
Procedural Virtual Texturing
The terrain shader is slow. It has too many texture reads.. and we’re hitting a limit. So Diogo has been hard at work implementing PVT. So instead of the shader reading a splatmap, then reading 1-4 different textures, and 1-4 different normalmaps, then blending them all together.. we just generate the textures and stream them in.
This has a dramatic impact on performance and is required for some stuff we want to try to do further down the line. It also means we have normal maps again.. and in the future will be able to mess around with parallax mapping.
Hopefully the only difference you’ll notice right now is that the performance is a little better and it has normal-maps. Please let us know if you have any issues like the terrain being pink or your house burning down.
We’re desperate to get more clothes in soon (or some clothes at all because the hoody is technically a placeholder to prove that clothes work). Meg has been doing more sketching.
We’re also going to be looking at re-doing the bow model at some point to make it work better with ironsights. Meg made some options.
Paul conceptualized a better furnace.
And a bunch of stone based hatchets
We’re making a lot of good progress on the building system. It’s getting really exciting. Over the next week I want to give Bill some more wiggle room on experimenting with the building meshes, to see if we can find a better way to do it before we fully commit. One thing we’re keen to explore is different inside/outside wall models. But it’s tricky to determine whether something is outside because of how open the building system is. We also need to start experimenting with the frame and lerp models. Then the plan is to make it so you can upgrade your walls.. so to go from wood to stone, then from stone to metal.
I’m hoping next week we’ll be able to get a set of meg’s clothes together too. Tom has already started progress on this. I want to explore the possibility of using workshop for clothes, in a similar way CS:GO is using it for weapon skins. This seems like a fun and harmless way to let the community mod the game. Not sure how all this would actually tie together though in terms of getting items, maybe a random drop like TF2? We really hate the trend for IAP so want to avoid that at all costs.