Heya folks. This week I’ve been working on visualisation tools for the editor, as well as taking a look at a revamping the spawning system.

A common problem we’ve had to solve with the SDK and map-making is displaying large sets of spatial data like spawns and biomes. We ended up with a few different systems that dealt with visualisation and painting of these datasets and it was a bit of a mess, and most importantly just couldn’t handle the size of the data we were throwing at it without reducing the editor to a crawl. The main cause of the performance hit was using the UnityEditor.Handles class to draw the cells in our data, which was a process that had to be done every frame and turned the editor into a slideshow above ~3000 cells. Drawing even a low-resolution biome map in Nullius required around 9000 cells to be drawn, so obviously we had to do something completely different. Another motivator for implementing this was the changes to spawns, which I’ll talk about a bit later.

So, to solve this issue I changed individual calls to the UnityEngine.Handles class to instead building and maintaining a single, hidden mesh object within the scene. This mesh object has a vertex for every cell that holds a color. This single vertex is turned into a quad with a geometry shader, which is much faster than having to build every vert manually and means we hit the 65k limit much, much later. This works really well, and means the only real workload is when we invalidate the mesh. Check out this gif of painting on the map!

So these improvements were partly because of discussed changes in the way spawn maps are going to work, which meant that this part of visualisation and painting really had to be up to scratch. One of the problems right now is that spawns are really tied to the map – you look at an area and you say “I want exactly 3 iron rocks to spawn here”. This works, but it makes balancing difficulty. Spawns are one of the things that most server-owners play around with, so we want to defer those decisions as late as possible. So, what we’re more shifting to is a spawner based around two maps – density, and difficulty. A density map will do roughly what the spawner map did before – say how many objects there should be in an area. However, we’re going to implement a system that supports non-integer and <1 values for these cells, so, for instance, two cells next to each other with a density of 0.5 will try to have 1 object spawned between them. The difficulty map – see below – is a general value that will determine what will be spawned in an area. So, for instance, a high difficulty value for a creature spawn would make it be a harder creature. This gives us a lot more easy knobs to play with to balance a level.



Adding more parts to the Mac-10 and new parts to the existing Beretta this week. They look really nice even at this level, the techiness is really satisfying to look at. I’ll be testing some UV unwraps a little this week and continuing to add parts to the Beretta. I want to get the texture scaling right when you are up right near the Iron Sights and various Scopes.

MAC10andBeretta_0001_Layer 7 copy 4 MAC10andBeretta_0000_Layer 7 copy 5 MAC10andBeretta_0005_Layer 7 MAC10andBeretta_0004_Layer 7 copy MAC10andBeretta_0003_Layer 7 copy 2 MAC10andBeretta_0002_Layer 7 copy 3


So I finished off the Low riding jeans, and did a temp skin on them.


I also did a bunch of clean up of my assets within the project, organizing things and updating head assets like hair, beards, masks etc to make sure they fit correctly, skinning them and baking them. I did a pass over the player face as he had a sort of creepy thousand yard stare, and tweaked it to give him a slightly more friendly look. The changes were subtle but still enough that they caused errors in the game mesh that meant I had to go back change the sculpt, re bake his maps, re skin, and re bake his game mesh to test. His eyebrows were also replaced.


I also spent some time cleaning up and reorganizing a bunch of my work files so that if someone else need to access them they can tell what is what. This involved placing files in easy to find folders and making sure that PSD’s have correctly named layers. I am currently going over the spec maps for hair sets, then will jump onto some more player items.


I’ve spent most of the last week continuing on with work on the customisation system. It’s been pretty tricky to develop a system that meets all of our requirements but we are getting close. We wanted a system where the player can colour their gear on a per item basis and where items using the same shader could be combined into the same material to save on draw calls.
Our current vehicle customisation system wasn’t quite up to the job as its customisation works on a per vehicle level rather than per item (ie. the vehicle has 3 colour slots rather than each vehicle attachment having its own colour slots).
Whilst we could use the same shader to colour the gear after baking it all together if we want to use the same material to reduce draw calls we need a way to tell different parts of the baked mesh apart so they get their own individual colour customisation (ie. colouring a hat slot and a chest slot differently), this is further complicated by the fact that GPUs don’t deal well with branching if the condition is changing within the same draw call (so we can’t do conditional selection based on the type of gear).
Our solution is to create a small texture with 3 pixels reserved for every item type to represent the 3 customisable colours, we then use an extra UV channel in our mesh to find the customised colours (UVs are texture coordinates that are used to map textures onto a mesh, they are normalized between 0 and 1 so they can map to any sized texture, 0,0 is the bottom left texture and 1,1 the top right). Zoomed in our texture would look something like this (without the overlay text).


The UVs are slightly offset so they match to the center of the pixel rather than the corner. I’ve only listed the UVs for colour1 as this is all that the mesh knows about, the other two colours are retrieved by the shader automatically shifting the pixel over. We are using a 32*32 texture, giving us 1024 pixels meaning we can represent 341 items with 3 customisable slot colours at a time. When an item with customisable colours is equipped it sets the pixel colour depending on its slot type.
Now if we combine the other textures together into an atlas we can use the same material for multiple bits of gear allowing us to batch things together efficiently reducing draw calls (each material is at least one draw call depending on shader).

I’ve also been adding a new shader for custom colours. Previously we were saturating the diffuse texture with the custom colours based on an rgb mask where each rgb channel corresponded to custom colour 1,2 and 3 respectively. The amount of saturation was based on the brightness of the colour channel in the mask. The new shader doesn’t use saturation but just a simple blend instead. Now we use the brightness of the mask colour channels to tint the custom colour (see how in the example below the overlay colours fade to black towards the bottom) and added an alpha channel to the mask that controls the blend weight. This method doesn’t require a desaturated diffuse texture and gives more control especially when blending into and out of the mask.
Here’s a demonstration where purple, yellow and green have been picked as the three custom colours.



Good progress this week, we had our first internal play test of ItemV2 in survival mode. Still a broken mess, but marks us being pretty much on par with the master branch feature wise. I pushed out an update mid week to the ItemV2 Experimental build which contains the new assault rifle model and the broken survival build.

I’ve had my design hat on for most of the week, fleshing out the details on how gun attachments work, how you find them, what can be removed / added vs what is fixed.

Unfortunately as this is all theoretical design, I have no pretty pictures. Just a wall of text.

I’ve gone over the ItemV2 details in the past, but it is scattered through lots of posts so I will re-summarize here:


First of all, the below is designed and balanced for full loot aka no infamy. The objective is to shift some of the gear progression storage to things inside your base, making it less painful when being killed deep into a progression without taking away the punishment of death. Also giving other players valuable item drops while limiting their value should they kill you.

Recipes for Weapons, Gear and Tools beyond the very basic will be obtained in the world by killing animals, looting ruins and gathering resources. You can think of this as the loot hunt similar to something like Diablo, where instead of finding a complete usable item, you find a blueprint to a specific item.

Every blueprint generated by the loot system will be unique. You will be able to see the stats of an item before you attempt to craft it. Blueprints with better random rolls will be more expensive to craft.

One blueprint will give you a limited amount of uses before being destroyed.

Each blueprint will need to be loaded into a dedicated crafting bench, and once loaded can not be removed.

All tools and gear will have durability, after a set amount of use will become broken.

Crafting benches will be able to repair items if the item’s blueprint is loaded into it. Meaning only the creator of an item can repair it.

Weapon blueprints will contain roughly half of the weapons attachment configuration. The rest will be able to be added and removed on the fly.
Example – Assault Rifle
Blueprint generated will randomly roll a lower receiver, barrel and stock. These items will be generated at blueprint time, with randomized stats and will be fixed for the life of the weapon.
Additional items can be attached for: Silencer, Sights, Scope, Magazine which will modify the stats and operation of the weapon further.

All parts of the weapon will be paintable with custom patterns and colors.

Map Spawn Generation

To support the large progression we are working on, we need to move away from manually configuring each individual creature, loot table and placement in the map. We are moving towards a more semi procedural solution where we specify difficulty of an area and the density of each type of spawn we want and we let creature and resource generators do the rest with algorithms. Cow_Trix has been working on the source data for these systems, I have been working on taking that data and spawning things.

The objective is to have our systems determine something needs to be spawned based on density and difficulty, and pass a set of parameters into a random creature or resource spawner which can be configured to generate all sorts of variations on creatures and gatherables.

An example would be, instead of having 3 different types of Tokar hand authored, we specific ranges of damage, speed, colors, mesh additions like horns, and sounds that occur at different difficulty settings and let the creature generator spit out a random variation based on a few dice rolls. At this point we could also inject rare spawns into the config, so we could have a rare albino Tokar spawn anywhere in the map a very small percentage of the time.

With random creatures, we then need loot to match. With too much configuration requirements we usually end up copying stuff from other loot tables and changing them slightly (hence the higher level tokars that are pretty much the same).

To follow on from this system, we will pass the spawn information we used to create the creature to the loot table once it is killed, allowing us to automatically scale up the loot dropped depending on the difficulty rating and rarity.

I see this as being a very important step towards pushing out our content by orders of magnitude. We want to push towards 50+ tiers of loot instead of our current 4 or so.

Nested Items

I’ve also been working on the implementation of items being able to store other items. Initially I was going to make all loot generated at blueprint stage and fixed for technical reasons, but as I just know everyone is gonna want to modify their weapons a lot, I decided to change the way we are going to do attachments.

Attachments are now item instances that can be “equipped” on a root item.
Eg: An assault rifle lower receiver will have multiple child items in the form of a barrel, stock, silencer, magazine, scope etc

This will also make modding for weapons a heap easier as modders will only need to make an item that fits the silencer slot of the AR to integrate it into the existing game.

tl;dr: Cool stuff coming