This week has been fairly chaotic as we pushed out our third weekly experimental release. Its been awesome to start getting you guys playing with the concepts we’ve been cooking for a while. Despite still being very rough, I’m really happy with how the new mechanics are working out.
If you missed it, you can read more about this weeks update —-HERE—-
The road ahead
We’ve enjoyed doing smaller short lived experiments, but nothing really compares with full blown persistent survival. The next few update cycles will likely focus on refining the new survival concepts, making the progression clearer and a lot more rewarding. At some stage I’m sure we will do more crazy experiments, but for now we are going to drill down on the progression survival side.
Weekly experimental updates don’t leave us a lot of room for house keeping. We have a decent list of things that really need attention so can focus back on making the content awesome. To do this we are going to do a 2 week experimental cycle this round, meaning the next experimental content update and wipe will be on Friday the 30th of June.
FPS FPS FPS
We hear you, something is being far greedier on the GPU than it should be and the UI is destroying the CPU while open/dragging. This will be our top priority this week to make sure everyone can get into ItemV2 and get back to solid FPS.
VOIP Robot Earbleed
I’m half way through implementing a brand new VOIP solution that should fix all our problems, and slightly improve performance. Unless something goes wrong, this will be in the next patch.
OSX should be back to working now
There are lots more annoyances that I’ve been meaning to get to, like fixing hit feedback sounds, balancing weapons better etc which we will focus on getting up to scratch this week.
More details on the patch for the 30th in next weeks dev blog.
This week I’ve been patching up exploits in the main game getting 0.3.8.6 ready to go and also helping get our latest experimental build out.
Some players had discovered a nasty bug in our construction system where if you rotated the construction item just before it was placed you could put the system in a state where it knew of the new rotation but hadn’t updated the construction validator. If you placed the construction item in this state the validation checks would run on the old rotation but build the item at the new rotation.
If you could get your item so the old rotation was legal but the new rotation was blocked this would allow you to place your item in the blocked location (such as inside a player) which was then leading to all kinds of issues. To fix this one up I made sure the validator updates itself before running the validation checks during the deploy step.
0.3.8.6 contains mostly bugfixes but we did make a change around structure attachment dependencies, now structures dependant on an attachment point (like doors, windows, even walls need some kind of a base to attach to) will collapse after a small time even when the construction cell is claimed (previously this check was only running in unclaimed cells) so it’s time to put door frames back on your doors!
Another change in 0.3.8.6 I’m excited about is changes to the inside rock checker, by distributing the check between client and server we can afford to run this check a lot more often, so much so going inside rocks and other geometry should almost instantly kill you.
I’ve also been working on the experimental branch getting the last release ready. As well as making more progress through our bug list I also spent some time setting up the clothing items that are coming out of blueprints. This was really fun to play around with setting up different pools of potential meshes for different tiers, potential colors that can be assigned at whatever scope we choose (per tier, per item, per mesh etc.) and potential stat rolls as well.
I didn’t get as much time as much time as I’d like to set everything up, most of the gear is picking colors from a potential pool set at the tier level but after doing this we agreed it makes more sense to have color pools set on a per mesh level (so firstly a roll occurs to pick a mesh, then the custom colors are picked from a pool specific to that mesh) but this takes a lot longer to setup and I only got as far as creating specific pools for pants items in this release.
This coming week I’m hoping to make some real progress on the performance problems some players are experiencing. I took a quick look at this earlier last week but couldn’t find anything obvious that would be a quick fix easy win so the experimental content became the priority. There are many improvements I can make to mesh baker performance so I’ll be starting there and seeing what else I can do.
Dived into fixing up one of the old machines this week, added a spec map and gave the albedo a pass but quickly found that due to the original way the model had been baked (with a single smoothing group) it was causing the spec to show up with lots of weird artifacts which means I’m going to have to go back and harden specific edges then re-bake the model. The albedo could still use some love as it’s just a blue blob at this point (which is how they are in real life but could still be more interesting).
Finally learned the skinning process (learnt a bit more after this picture hence the artifact). I’ve always stayed away from rigging and skinning as it seemed terrifying but It was something I needed to learn, this picture was my first attempt and compared to the how it was after copying the skin weights it’s a lot better, unfortunately I some how missed the artifact lower down the characters back and need to go and fix it. Skinning is a complicated process that takes a lot of practice to get good at.
Finished off the blue print case for this experimental build which involves a lot of blue print drops that needed a container. The case has an RGB mask on it so it can be colour coded to the rarity of the drop. I would like to make a legendary treasure chest for legendary drops that’s a lot fancier than this basic case.
Hey folks! This week I’ve been tinkering away at our map creation tools, implementing smarter tooltips that let you compare items, and fixing some OSX issues.
With the current experimental build, it’s pretty important to be able to compare two similar items and be easily able to tell what one gives you versus another. You find a blueprint, and want to be able to quickly tell if it’s worth investing in. I implemented a quick version of a comparison tooltip that compares the raw stats of your equipped item and the item you’re hovering over, check out a screenshot below.
I’m pretty happy with it, but it has a few drawbacks and won’t properly compare some effects between items. In future we should set up a dummy entity stat object, and simulate the actual raw values of the stats we care about when we simulate equipping both items. This means we can give more meaningful and realistic feedback when comparing and displaying an item’s effects.
I’ve been plugging away a bit more at the map workflow, trying to get an easy way to pick up and clone parts of the world. I want it to be as simple as drawing a rectangle, capturing a chunk of the world with everything (trees, terrain height, grass, splats, objects) and being able to use that as a stamp arbitrarily around the level. I’ve been trying to figure out exactly how that’s going to be structured and how that’s going to work, and there’s a good start there, but no concrete results to show just yet.
I’ve also been fixing some of the major OpenGL issues that Mac and Linux users would be experiencing. It turns out that some of the things I thought about shaders and AssetBundles were incorrect, and it turns out shaders must be built with the target platform. There was also a screen-flip bug, which has been a pretty common one with Unity post effects. Why everyone just can’t agree whether the top of the screen is 0 or 1, I will never know. This means that Experimental should be getting much more Mac/Linux friendly soon. There won’t be a dev blog from me for a while, I’m off on holiday for two weeks.
Diemensland got a few new towns this week. I made 3 large towns that hold a fair amount of crate drops. I wanted them to inhabit some less known areas of the original map. We wanted these to each have an individual feel. I used a lot of the assets from the city to create the base structures of the towns. I hope these add more to the map that has for so long been the same. They should push players out to areas where they don’t usually go. This will also cause new shortcuts between towns that people don’t usually take also.
Below; A screen grab from the Unity Editor of the 3 new towns.
Darlington; This was somewhat copied from a small town I grew up in by the same name. One of my favourite places where nothing has changed much over the years. It was supposed to mimic real geography and I think it did that fairly well. It looks nice at night when the street lamps come on. Needs an asphault road laid through it still, but the feel is there.
Boreas Forge; The name Boreas forge comes from a Greek god of wind and winter. I wanted this to have a mountain stronghold feeling to it. An epic path leads up to the top with many nooks with loot crates to be found. This can be seen from the north road that leads past the two winter towns below. I like how it looms from the mountainside.
Cratora; Three crater-like conjoined plateau’s at the end of one of the Red Desert roads. This place is a strange halted construction project where something huge was once to be built but never made it. This was due to the great Tokar uprising. This town has a 3 distinct areas. One an industrial storage area. An administration tower. Finally the Maze of Insanity from which few men ever escape.