Press Kit Wiki

Hurtworld Update #65


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

Hurtworld Update #64


This week we’ve been focusing on getting our survival systems back to baseline for ItemV2. I’ve been putting off re-implementing the legacy progression as most of it will change soon, however its been hard to get a grasp on what needs to be fixed while we can’t play the game. So cow_trix and I have spent most of this week fleshing out the basics needed for simple survival. For me this included bringing AI into ItemV2 land, and implementing a new loot table system that is based on ScriptableObject assets instead of hardcoded C# files.

Just like all our other asset based configuration data, these loot table files will be inside the SDK and will be easy to tweak and replace without any coding or oxide knowledge.

Here is an example of the first cut loot table configuration:


I also implemented the new AR15 mils has been working on, I will push it out to the Deathmatch branch tomorrow.


I have been adding components to the AR15. There are two sets of parts now for it, we are testing the parts in game to see how they feel so that I can get the go ahead to texture them. I’ll be making parts for the Mac-10 this week and maybe looking at other guns too.

AR15Bits_0000_Layer 2AR15Bits_0001_Layer 1


I am currently finishing of a pair of low riding jeans with player boxers peaking over the top. Below is a picture of the pattern from Marvelous Designer, with the white parts being the boxers, and the blue the jeans. It took a fair bit of noodling around, activating the sim, pausing, pinning, repeat to get them to sit right. I had a placement belt which I later replaced with one I made in max.


This is the resulting sculpt in Mudbox. I am currently retopologizing and finishing of the low poly.



Hey folks. This week I’ve been working on getting Hurtworld back to baseline survival.On my end this has meant getting navmesh generation working in the SDK, setting up Nullius and solving some regressions in map generation, laying out spawns and loads of bugfixes.

First up was a bit of work on my road tool, fixing some issues with generation where a connection between two nodes would sometimes be “flipped”, so that if you asked it if a point was within or outside a connection, it would always get it wrong. This meant that some connections wouldn’t affect the terrain properly. I also figured out a bit more how to use the Unity Editor’s ideas of selection and focus, which solved a lot of bugs around clicking on nodes and selections and Unity instead selecting the objects behind those objects. I also fixed some issues with how meshes were stretched along the spline – I was previously using the natural time of the spline to translate the mesh points along it, but this led to some weird artifacts, so I changed it to a uniform time.

I’ve been trying to get the basic elements of Hurtworld running in the new map – gathering, crafting, hunger, and heat. This meant getting all the spawners up and running, all the biomes configured, and all procedural. There’s still a couple of things we need to do to make generation completely procedural, there were a few things I was left doing by hand at the end of the process. There’s just no comparison with the pipeline we used to have though, things are a lot easier.

Something we can do really easily to play around with increasing biome difficulty as you move around is Overlay biomes. These mean you can have a root biome, which is your starting point for things like temperature, effects, hazards, and lighting settings, and then permutate it as you move out to harder areas instead of having to make an entirely new biome from scratch. So, instead of having to specift a MildDesert, MediumDesert and HarshDesert each with their own set of properties and settings to maintain, we can instead have some BaseDesert biome that specifies our baseline, and add Overlay biomes that for instance increase the temperature by 10 degrees across the board while making the sunlight strength higher.

At this point Nullius is looking pretty good. While the map is still pretty basic in it’s spawns and and probably a little too forgiving – there’s about 4 resource nodes every couple of meters at this point – it’s a substantial step!


This past week I’ve been working on integrating character customisation into ItemV2. Our design is to interrupt a player’s spawn (both loading into a server and respawning after death) with a window presenting the customisation options. Once the player has picked their setup they’ll spawn like normal once the spawn timer is finished (the spawn timer also runs in the background while you pick your look).
Currently you can pick between the base types that Gavku has been previewing over the last couple of months (Current default, female, asian and african) along with different hairstyles and beards depending on the type.
We also plan to let you pick hair and eye colour here but as of writing I’m still working on it.


Working on this exposed some problems with our mesh baking system so I had to dive back into it to decouple materials from mesh attachments, create a new layer of abstraction with a mesh configuration object to allow assigning materials to mesh attachments and then add another object abstracted above that, that defines the setup for an item, referencing groups of mesh attachment configs for both first and third person (many items have a high detail version for first person view as they take up a large percent of the screen and we can guarantee there will only be one at any time so the performance costs aren’t bad) as well as a mask that can turn off parts of the base mesh (for example, turning off the torso and arms while a jumper is worn).
This new setup is a lot more memory efficient, we no longer need a new mesh for each material variant and items just hold a reference to a configuration object rather than multiple references to all the mesh attachments it’s using.

So far it’s coming along well, I’ve got the spawn interrupt and base type, hair and beard picking working and synchronizing over the network, now with the mesh attachment baking in a better format I can move onto colour picking both for hair styles as well as gear.

Hurtworld Update #63


Hey folks! Back into it after Christmas and the New Year. I’ve been working on the map, extensions to chat and the UI, and some stuff for testing out lighting.

A lesson we’ve learnt over the past few years is that testing lighting is a tricky thing – there’s a million levers to pull, and changing some variable can affect some other thing you never even thought about. Lighting can often regress. To try and help compare “apples to apples” as they say, I built a quick framework for generating screenshots for a level. It sets the quality settings, the skybox, the time of day, and then goes through and takes screenshots at pre-set locations. This means that we can keep archives of what levels looked like, and go back and compare screenshots to make sure we haven’t screwed things up.

Comparing different lighting setups

Comparing different lighting setups

I also added a few quick additions to the UI, which I’ve been meaning too for a while. There was a general restructure to extend chat and make it a bit smarter. The big thing was implementing in-text links, which means we can create dynamic, clickable contexts within chat. Basically, we can make any word clickable and functional. You can now mute individual players in chat by right clicking on their name and selecting Mute.

You can also context click any item and send it to chat as a token which can be seen by other players, tooltip and all. ItemV2 is a lot about finding cool loot, and this is a way you can quickly share the cool stuff you find. I also implemented a general-use context menu, which is used for chat stuff but also on items to do things like splitting and dropping without needing to remember key combinations.



So after much deliberation, we have scrapped the the current weapons that we made and are going to focus on implementing realistic weapons and components. The argument here was that the weapons would take too long to produce whilst trying to copy the functional form of weapons that have evolved in real engineering and manufacturing processes. Such gun designs have been iterated over for decades. We want them to functionally look right. We really don’t have decades and we aren’t engineers. So, the guns will look and feel like guns should and not end up looking like Nerf guns 😛

First in the line of guns is the remade AR15, which I have been making sure lines up as close as possible with a real AR15. I looked at 50 to 100 photo’s and diagrams to make sure this looks as close to the real form as possible. We went for a MAC-10 also, which is a good bridger weapon between a pistol and the AR15.

We want these to be a big part of what makes a satisfying gunplay experience.

ar15_0002_layer-2 ar15_0003_layer-1 ar15_0001_layer-3 ar15_0000_layer-4mac-10_0002_layer-2 mac-10_0003_layer-1 mac-10_0001_layer-3 mac-10_0000_layer-4


So after the break I set about making a hoodie for the player model. Below is a pic of the sculpt within mudbox, as well as a lineup of them from within unity setup as a paintable item. Currently it is sitting as a plain/completely paintable object, but it would be easy enough to add prints, trims, patterning etc for increased variation of we decided to go that way.




After a short break through the christmas/new years period I’ve been back working on ItemV2.
I started the week off trying some melee experiments but quickly ran into issues trying to get animation driven mechanics working and determined it would require too much refactoring so it’s been put on the backburner for now.
Instead I’ve moved back into implementing the rest of the item mechanics for ItemV2, starting with item transitions. Transitions make items transform into other items under the correct conditions. Currently we use this to smelt ores and cook food but it doesn’t need to be tied to temperature, it can reference any stat type and you can turn off the DestroySelf flag to keep the original item. This could allow you to make something like a chicken that lays eggs whenever you’re hungry. Here’s how the setup for a raw steak looks to give an idea on how it works.


Next I implemented consumable items allowing them to modify any stat and add or remove any binary effect (eg. burning, freezing etc.). Here’s the setup for a frozen raw steak giving some nutrition and freezing you at the same time.


Next up was getting crafting working again, recipe lists are now serialized objects and crafting machines (like the workbench) can take any number of recipe lists. This allows us to easily setup new crafting machines so we don’t have to cram everything into the workbench and also allows modders to rebalance crafting costs or create whole new crafting machines themselves. Something like a vehicle crafting station would be easy to implement. Here’s an arrow recipe from the workbench.


I also started getting resource nodes working again as well as getting the spear throw working but these still have some bugs left for me to squash this week.
Also this week I’ll be working on getting a customisation window working that will allow you to pick between the different character models and hair styles Gavku has been working on so you should be seeing that show up in the deathmatch soon.


Back into the action today after a relaxing break, and have been looking at the feedback from this weeks ItemV2 deathmatch tests, along with getting upto speed with the rest of the crew and planning our push towards ItemV2.

I’ve also started experimenting with a new item icon renderer that works at realtime based on the mesh data instead of a custom designed icon. We sort of need this considering the amount of customization we are going to add to items, no 2 items will look the same, we want our icons to show it properly.

I also created a combined ItemV2 and Master build on steam and pushed it to the default branch with different launch options, so you can now launch the latest ItemV2 build without ever switching branches. Simply launch the game as usual and select “Launch ItemV2 Experimental” in the dialog.

Let me know in the ItemV2 feedback forum if you have issues launching the Experimental branch from OSX or Linux.

Dev Blog