Press Kit Wiki

Hurtworld Update #114


Hi Guys, we’ve been making awesome progress on this weeks build. I’m confident that the direction we are heading is the right one. Having items be valuable again has really opened our design options up for utilizing all the amazing tech we’ve built over the last year to do with item customization. I mean who wants to upgrade, paint, name, pimp an item if its only gonna die on you in a few hours of use. Tomorrows build will be our foundation, with some really exciting stuff to come.

The new map is also coming together amazingly. Cow_trix has done a great job bringing everything together on that front and it should really bolster the playability of this build.

This week I’ve been working on automating the amber protection cost calculation to be based on source materials as well as boring content configuration stuff. Currently this tool is only usable for us, so modded items will have to explicitly specify their amber protection cost in the data provider. Eventually I plan to do this calculation on the fly at runtime.

Perf is currently pretty ratshit, the new map has very high creature and tree density which feels really good if you can pull 60fps. Once we lock down our new content targets we will do a heavy optimization pass on foliage and creatures, fear not.


So I spent a lot of time messing with the chopper’s proportions last week. I am making sure that the scale suits the Huey proportions which is weirdly a hard hard thing to do. All the blueprints for the Huey seem to be wrong, so I have been back and forthing between blueprints and photo’s and measurements from chopper enthusiast’s websites. Helicopters are not mainstream consumer vehicles, so the information available on them is limited to people with businesses that run/fix them, enthusiasts and rich peeps. I’m getting close to being happy to start the high poly modeling.

We did some play testing on Friday of the new map and it was pretty good. Still a ways from the final product but will be great to see a good map back in V2.

I also got stuck into selecting some colours for the vehicles. These will  be used until we build the UI customisation section. They are hand picked by me to look good, and not like, er… cancer. I checked these on the Kanga and Roach as they have fairly different shapes/surface area. The other vehicles should look fine with these also.

Kanga Roach


Hey Hurtworldians! This week I’ve been helping to sync up our base content with legacy hurtworld as well as chasing down some elusive bugs.

I fixed the problem of tree leaves and bushes appearing ‘see-through’ when using deferred rendering combined with the SSAO effect on. This was occuring because the leaves translucency required them to be drawn after the deferred pass so they had data about the background color to apply the translucent lighting. A consequence of this was that the leaves and bushes weren’t being written into the normal buffer which is what SSAO uses to apply its shadowing effect, instead the effect was applied to the objects behind giving them effectively outlining these objects through the leaves. To solve this I changed our SSAO method over to a different implementation that doesn’t depend on the normal buffer.


I also fixed a few other issues like resource nodes spawning pre-damaged, stat events not being fired properly after loading from a save (things like toxin not clearing off your character after loading in with toxin applied or smelting machines not updating their temperature until being relit), the construction ui not removing itself properly after using a construction item and fixing issues with vehicle inventory ui not updating after adding or removing storage slots.

I also setup a vehicle crafting machine that is crafted out of the first workbench and allows crafting of vehicle airdrop beacons, vehicle repair wrenches and also vehicle engine upgrades.
We’re now at a point where we are pretty much back to legacy balance with everything but vehicles plus we’ve got our new item insurance system + item recycling. We’re hopeful this can serve as a stable base that we can gradually add to based on the lessons we’ve learned with our experimental releases so far.


Heya folks! This week I’ve been getting together a new version of Mangatang for the new patch. It’s been going well, and I’m pretty happy with where the pipeline is at. I’ve passed off the hand-polishing to Splatt, so soon we’ll see some awesome, interesting areas in the map. Building a new map from scratch is always a bit of a mammoth task, but the brief of trying to somewhat emulate the layout of diemensland helped a lot in that. It was nice to return to it’s familiar structure, while being able to apply the many new lessons we’ve learnt since then. In many ways we’ve tried to combine the best of old Mangatang with the best of Diemensland. There will be some familiar but different landscapes – including the sand dunes! Instead of a beached aircraft carrier, you’ll have the skeletons of a deserted city to explore for some good loot. Check out some screenshots below!


There’s still a few things that need tweaking – for a few of the biomes, I don’t think the base ground ripple is right, and there are some spots that just don’t work in terms of ground scattering and line of sight. However, with the new workflow we can split this work up nice and easily, thank god! So map iteration will now be a lot more parallelizable.

On the code side of things, I was working on the usability of the map tools, trying to fix up some of the more confusing parts of the UI and putting in some warnings and restrictions to prevent setting up stamps and layers in a nonsensical way.


Hello, this week I’ve spent a lot of time gathering and making assets for polishing/dressing our biomes. I’ve figured out a good way to sculpt rocks that’s extremely quick and easy to get the noise frequency looking correct over the different sizes of rocks. Due to how fast rock sculpting is at the moment I whipped up some replacement rocks for our main rocks that are everywhere. I started to implement them into the red desert biome with a new colour pallet and over all look that feels more like the Australian out back. This involved trials with a lot of vegetation and different foliage which doesn’t work great due to the grass getting culled and not providing the colour difference from far away. I played with putting the green colour into a second red desert terrain splat to get a consistent colour change even after the grass has culled but it still needs some work. I’ve also started to work with the actual map tools and am definitely planning on playing with re-doing the biomes in my spare time.
Australian Desert Pallete - High Vegetation_Fordevblog

Hurtworld Update #113


I’ve got the main chassis for the Hell-Yeah Copter ready. This is still not the final chassis as I will now concept paint the outer shell to get a nice design. I’ll then go back and model the low poly outer and look at where my poly count is sitting. I plan for this to be around 15,000 – 20,000 poly’s because it is quite large. Once the outer is done I may have to strip some of the detail out to accommodate the body work. The outer body has preference over the details on the inner chassis as they inner will be covered by the body most of the time. I have made the tail removable so that when the outer is added, all those framework bars aren’t just sitting beneath the outer hogging up my poly budget. Most of the chopper chassis will be mirrored down the centre line to save on texture space also. Although this is based on the Huey Design, I will be making it conform to our other vehicles ‘Hurtworlded’ style. The chassis for example is not like the real thing, it is a scrapped together backyard built frame, that holds a similar shape but isn’t true to real engineering standards. It is a ‘ghetto bird’ as Spencer would say. 🙂

MozzyBasic01 MozzyBasic02

Turns out I managed to get the first body concept out also. So here it is. It’s a scrappy type of body kit which gives a serious nod to the shark teeth type paint jobs that used to be on some of the Huey’s. (the teeth were Cowtrix’ idea, thanks matey)



Heya folks! This week I’ve been working on a new map, and further refining the level creation pipeline. As we’re trying to go back a bit more to legacy structures, the new map will have similar structures to Diemensland. You will have the starting desert in one corner, which branches off in one direction to the forest and snow, and in the other direction to the sand dunes and red desert.

One of the big things with putting together a large map is that it is quite difficult to split the work up into manageable, modular chunks. If multiple people want to work on the same level, there’s not real easy way to do this with everything all living in the one Unity scene. How I wanted to structure things was to have individual capture scenes of each biome, that could then be capture as a WorldStamp and stamped onto the big map as a final composite step. A couple of improvements needed to be made to the system before this could be a viable workflow.

Firstly, I created the concept of stamp templates. This means that you can set up a stamp capture in a scene, and save those settings into a gameobject. This object can then be used to set the capture up again in exactly the same way with the same mask, which makes it trivial to recapture stamps again and again. So, for instance, I could paint out the rough biome shapes in the main map and create stamp templates from that. Then, I could bring the templates in to the individual biome scenes. I could then use this template to both see the area I needed to detail and fill in the stamp, and recapture the stamp in such a way that fit perfectly together in the main map. This workflow has been working great!

Secondly, I needed to think about how roads fit into this workflow. I need a way to embed road networks into a stamp. The solution I came up with was to create a stripped down version of the road network (like we do in the build process) that can then be embedded into the WorldStamp prefab. There were two issues to solve to make this possible. Firstly, we need some way to connect these embedded road networks to their surroundings once they are stamped. To do this, I created a concept of a “stamp exit node”, which is a special type of node that sticks around when the network is stripped down. This means you can mark specific nodes, and they will be able to be connected to once the stamp is in the level. Secondly, I need to figure out a way to embed the generated meshes in the prefab. When you generate a dynamic mesh in Unity, the reference is only valid within the scene that mesh was created in. If you naively create a prefab from an object with a reference to a procedural mesh, that reference won’t stick. I didn’t really want to create a bunch of sub-assets every time a created a prefab from a road network, so I created a quick mesh wrapper object to solve this, that stores a serialized version of the mesh and detects when it needs to create a new copy.

The new map is coming along well, and will hopefully be internally playable by the middle of this week, and playable by all of you soon!


Hello Hurtworldians! This week I’ve been continuing working with vehicles mostly, starting with improvements to vehicle spawning. Vehicles now will receive random wheels on initial spawn rather than the same wheels every time and its relatively smart about which wheels get picked, both front wheels must match and both rear wheels must match as well, also, big ‘Sand Hopper’ style wheels will only ever apply to the rear making sure wheel spawns are always balanced.
Our basic customisation features have been rolled out to vehicles as well, vehicles now roll their color and paint mask on initial spawn and all their attachments now inherit their appearance from the base vehicle to match how the weapons operate. Currently like in the example below these colors are completely random but we should have them limited to a few good looking color sets in time for release.
In the hopefully not too distant future we are really keen to open up the customisation to player choice but that still requires design and UI work and for right now our priority is to get back to a stable experimental release.


Also in vehicles I’ve been implementing a camera perspective cache. Basically what this means is the game will remember which perspective (first or third person) you last used in vehicles and will store this separately to your standard perspective. It will then automatically switch perspectives when entering/exiting vehicles.

I also spent some time extending our ‘uber’ shader that we use to shade almost everything. Previously vehicles were using a very similar shader that was blending its custom colors through saturation rather than a linear blend. When checking through vehicle world items I noticed a few panels needed to have their backfaces drawn so rather than add a backface option to the vehicle shader I decided to add a saturation option to the uber shader. Whilst doing this I also added an emission option (with both color and texture) for self-lit objects and fixed a series of bugs around shader variant creation. As a result of this fix the uber shader is no longer replaceable through modding but you can still use any shader you like by assigning an override material to the mesh attachment.


This week I’ve been continuing work on the set dressing assets I was working on. After changing a few things on the terrain chunk mesh It’s now very easy to swap textures in and out to match them up with all the biomes. At the moment the terrain chunks work better in certain biomes due to the general noise of the terrain which gives me more dips and valleys to fit them into, but that won’t be an issue when I place them in the real map as I can edit the terrain manually to make them fit nicely. I’ve also been looking at creating a few medium sized rocks to be used as hard occlusion, at the moment the only rocks we really have are either massive impassable objects or resource nodes, so having something in between is an easy win from a gameplay aspect. Although rocks are easy to use as hard occlusion they are a bit harder to actually model, there’s a lot of challenges when it comes to size and noise frequency, at the moment I’m putting everything I’ve learnt about them through out the year to use.



This week I finished off the loot, damage, stats, items, crafting sync with legacy as a baseline. I just put the finishing touches on the amber protection system which fits into our item architecture nicely and doesn’t add much complexity to the progression. It currently works by simply right clicking->protect an item which will put a lock icon on it indicating it will stay with you after death, pretty simple.

The biggest work here is now configuring how much amber each item costs to insure, which I think would be better done by a formula based on crafting recipe. Reversing crafting recipe from an item isn’t currently very easy, but is something we had planned for the recycler machine that will be rolling out with this patch so I’ve opted for implementing that first, then I will work backwards to calculate the amber cost of all droppable items and we should get to a decent baseline balance for it.

Schedule Bump Up
The original schedule for our next experimental release was the 26th of Jan, as this is a public holiday for us we will be releasing on Thursday the 25th of Jan at 5pm Melbourne time instead.

Hurtworld Update #112


Happy new Year to all the Hurtworld family, the studio is back at full capacity after a much needed couple weeks of down time. It was a good chance to reset, and get a fresh perspective on where we are at and what needs to be done to bring ItemV2 into the main branch with a bang.

We are still on the same trajectory as I mentioned in the last blog, balancing things similar to legacy with an ItemV2 twist on the content. Infamy being a necessary evil of legacy, that without we have a far too punishing game where you can drop days of farm in a single death, we will be trialing a new system allowing you to keep your gear on death which will work similar to an insurance policy.

Amber Protection
On any equippable item, you will be able to drag amber into the item to put it into a protected state. On death you will drop 80% of the amber used to protect the item, the remaining 20% will be burned and you will keep the item. The item will return to its un-protected state. Any unprotected items will drop on death as normal full loot.

The amber protection cost will vary between items based on the value of the item. We will try to balance things so generally the amber needed to protect it will be around 20% of the value of re-crafting the item. This we can tune at a later stage.

Item Sink
Items without durability will end up accumulating as there is no destruction mechanism. This is shit, (think Diablo 3 on release). To solve this we will be introducing the ability to recycle items for a portion of their crafting ingredients (not 100%).

Amber Loot Tables
We will increase the amber loot drops to account for the increased demand and burn rate as we go. We expect this to cause amber to be even more of a currency than it already is, which we are fine with. Having things funnel back to amber gives us some easy dials to turn when balancing out the game.

Next Experimental Release
We will be aiming to finish this build on the 19th, and release it on 26th of Jan with a new version of Mangatang built from the ground up for this structure.


Merry New Xmas Year! After a good holiday break we are all back with a vengeance! I have a very fun project to get on with in the new year. Can anyone say HELICOPTER?

Yes I’ve been tasked to expand our vehicle range to now include air travel. The design I’m going off is the classic Huey design seen so many times in films and footage about the Vietnam War. Following the style I have created with our vehicles I will start with a frame style chassis as the base, which will then have the ability to add armour panels and other attachments. The current plan is to make this vehicle expensive to run so that it doesn’t become the main mode of transport, we need to keep it balanced with the other vehicles. Right now there is a base frame I am working on which takes a lot of thought as to how it will look and function in relation to the outer panels that will be designed after. I may use this base as a reference to paint some concept art over the top. Should be a lot of fun making this 🙂



Hello, after a bit of a break I’m back into getting these new environment features ready. As you can see in the image below, the top image shows a hill with scene dressing using large chunks of terrain, foliage of varieing heights and rocks ranging from small to massive. These scene dressing props help both asthetics and (hopefully) gameplay. The different shapes and heights of the layers of props break up the sillhouette of the land and give good cover over decent distances. You can clearly see how bare and open the bottom image. I still have to find out a good way to  blend between the terrain chunks textures I’m making and the actual terrain splats, we have a blending tool but I don’t know if it’s usable in this situation. I would also like to get through some of the more random scene dressing assets like animal bones, old broken ruins, tree stumps etc. Hand crafting areas of the map is definitely something I would like to try, to give the players some very memorable land marks that also serve as compact areas of specific level design catered towards gun fights and/or other aspects of game play.



Happy New Year Hurtworldians!

After returning from a refreshing holiday break today I’ve been looking at how our vehicle changes are going to fit into our return to the legacy baseline.
We’ve never been all that happy with how vehicles were obtained in legacy Hurtworld, it was too random and generally too difficult for something so powerful. That might sound a little counter intuitive (ie. shouldn’t I have to work harder to get a more powerful item) but because of the persistence and potential for loss in Hurtworld getting an early vehicle can give you a large advantage that can snowball out of control pretty easily.
With this in mind we want to make it much easier to get a low tier vehicle like a Goat with a weak engine but make it hard to upgrade your engine to a powerful one and find a full kit of attachment panels (these are way more valuable now that they are supplying armor to the vehicle, effectively increasing its health).

To achieve this we’ll be keeping the vehicle air drop beacons we added in the last experimental update round. I’m still playing around with exactly how they are going to fit into the legacy progression, but it will be starting with the Goat at the iron tier and then moving on from there.
Vehicle attachments will be found mostly in town loot crates and sometimes in random air drops.

I’ve also been looking into making the night less pitch black for those who aren’t using the eye adaptation graphics option (if you can run this you really should!) without making it too bright for those who are using it. No breakthroughs just yet but it’s definitely something on our radar that we want to fix soon.

We know the current experimental build is pretty broken and we want to replace it ASAP, because of this we’ve been talking about pushing to get the baseline legacy build in v2 first and releasing that without the Slug, airdrop and meteor mechanics then working on rolling those out once we’re back to a nice playable foundation. Hopefully we can get something into your guys hands again soon!


Heya folks! Hope everyone had a great break over the new year and got a bit of rest and relaxation. Just arrived back, and back into both level building and tool development. I’ll be working on the next iteration of Mangatang over the next few weeks, as well as further building up the level building pipeline. I want to work on moving map development away from having a monolithic central scene – something we experimented a bit with in the development of the Red Desert, but which we need to continue on in my opinion to make it seamless. Optimally we want something where Mils and Splatt can jump into an individual scene that contains a segment of the map, do hand polish or make whatever changes are needed, and then be able to make a new stamp that can exactly replace existing stamps in the scene where everything is assembled.

There’s a couple of things needed for this. Firstly, I’m creating the ability to store the settings used to create a world stamp in a scene. Previously, you had to pretty much just remember the settings with which you had previously captured a scene if you wanted to recapture to reflect some changes or polish. Now, you can set a stamp capture up and save that configuration as an object within the scene, which can then set itself up again. This will mean that it will be trivial to recapture stamps exactly. I’m also implementing the ability for a stamp to capture a road network and include it in the scene. This currently supports packaging up a baked version of the road network with explicitly selected “exit nodes” that can be connected to, and including the entire network copied 1:1. The first use case is probably the more useful one, as hand-polish can be applied to the road network itself. The next iteration of Mangatang will be not centered around a central “build biome”, and will be structured much more along the line of Diemensland than for instance the current, live building biome. We’re going back to the valley and hill formula that has been tried and tested for the kind of gameplay we’re trying to make. Hopefully I will have some cool screenshots to show next week!

Dev Blog