Press Kit Wiki

Hurtworld Update #105


So I took a little longer doing these limbs this week than I’d hoped. They came out looking sickballs though. This bow is really starting to shine as a quality weapon. I also put a fair bit of detail into the feathers so we can use them for world items in the game. I can’t wait to use this bow now. These match up well with the enhanced weapons texturing and use the full pbr workflow, same as the AR15 and AWM. I’ll do the Arrow and the Rest now which should take no time. I’ll be doing the 3 sets of gear for these then weight skinning them and they’ll go out with the V2 release, or maybe sooner.





This week I’ve been working on finishing off the meteor shower, implementing the art TehSplatt has been working on and bringing everything together for our new game mode. I wanted to have a lot of the stuff we are working on going into experimental this Friday, unfortunately things generally take longer than I had hoped and I don’t want to release this stuff in a half finished state like our last few releases. We are going to spend the extra time to get things right, meaning this week isn’t looking good for a content patch.

At this point we will be just doing a wipe on experimental with bug fixes.

Here is the meteor shower in action:

Loot Balance
The things left to do with the dynamic hotspots are to figure out how frequently they should spawn, what items they should drop, how they should interact with bases, and how to rebalance static loot to make room for the added items from meteor showers and air drops. This is the part we often fall short on after implementing a new mechanic. It doesn’t matter how cool the effects are if the stuff that you get from them is useless or unbalanced. This will also tie into how the truck fits into the game. The truck is slow, annoying to drive, and easy to highjack so we need make the reward big for using it.


Heya folks! This week I’ve been working on various bugfixes, the new in-game map, and polishing little bits and pieces. Firstly, through using the map and comparing it to maps in other games, we realised how important continuous motion was in being able to do things like focus on a single point while zooming and panning, so I went about changing the behaviour to interpolating between target positions and zoom levels, instead of just immediately snapping to them. This meant a bit of a rethink about how we were invalidating an recalculating things, so we were saving as much performance as possible. Recalculating the UI layout in Unity can be an expensive process, especially if you’re using a map with many markers, so we wanted to minimise how often that happens. It is still possible that lots and lots of markers will slow the map down a lot, and in the case where that becomes a substantial concern, there is the possibility of rendering the map to a texture which we then display, as opposed to moving a transform with a complex hierarchy below it, which will eventually bring the framerate down. I also implemented a zoom-to-cursor functionality, and the ability to remove your waypoint marker once placed. These quality-of-life features will roll out in the next patch and hopefully make the map feel a lot better to use. If you guys have any other suggestions for making the experience feel better or more intuitive, let us know!

In other optimisations, I was a bit all over the shop. I optimised the construction shader to remove a whole bunch of unused shader channels that were left over from development. I also fixed a bug where construction items weren’t initialised properly when they were first equipped and couldn’t be placed until they were reequipped. On the SDK side of things, I made some changes to the road tool which removed a previous restriction, in that the order you placed road nodes mattered in how the road bent between them. I also experimented with some tools to improve map FPS, including a tool to automatically delete geometry below the terrain that seemed to give a fair boost to FPS. More experiments on this are needed.

This week I’ll be continuing to polish features and fix bugs. The Bug Report forum on the Steam discussion board is the best place to have your say on the critical things that need fixing, so make a post if you something is really bugging you.


This week was spent making some quality particle systems for the meteor and meteor ground explosion. Last week was my first attempt at some sort of explosion using particles, and the intial results I got were pretty terrible, but I’ve learnt a lot through the week and ended up with something that, while it could be better (pretty typical in art), I feel has the epicness and scale that I was trying to get across. You can see below the comparison between day one and the final version. The first one uses static images as particles which make everything look like cotton wool, while the final version uses animated sprite sheets which give the particles a realistic and lively feeling. Another thing that helps a lot is bloom, which gives the flames that intense brightness more inline with a realistic explosion. You can see the meteor trail particles in Spencer’s video, the meteor originally had a blue glow around it but due to the flames being added over the top the final result is a green glow which I like so that was a happy accident.

I’ve also started working on a Substance material for the meteor that you will see after it’s landed. It’s still in very early stages but I currently it set up so you can controll the amount of cracks and lava which might be useful for animating down the line.



This week I helped push out 2 bugfix patches, re-enabled destructible vehicle attachments (shooting off wheels is coming back) and continued to iterate on the Slug.

The first bugfix patch ( was largely to address an OSX issue where the input system had become corrupted and was not being loaded properly, this was an issue that would frequently pop up when creating builds from my machine but thankfully it now looks like we’ve gotten to the bottom of it and our OSX releases should be more stable from this point on.

The second bugfix patch ( was largely to address a bug in the mesh baking cache system where meshes could suddenly disappear. This system basically saves combined meshes so if we need that combination again we can quickly look it up rather than having to do the combine job again. Because we have hundreds of mesh attachments this leads to more potential combinations than we could store in memory at once, because of this we need some way of removing combined meshes from the cache to make room for others. To achieve this I’m using a reference counting system where each use of a mesh increases a counting variable, when we release the mesh (like when a ragdoll despawns for instance) we decrease the same variable. When it comes time to ‘trim’ the cache we can scan through it looking for any meshes with a 0 reference count and know they are safe to remove.
This bug occured because I wasn’t adding to the reference count when the combined mesh was first added to the cache, this meant if only 1 system was using this mesh on your local PC it could be incorrectly cleared.

Another change I added to is options clamping. Now when the game loads or any other time your options are loaded we validate the config being loaded where possible by clamping the values between their min/max values. This means that if you had a previously valid config that has recently become invalid it will now be set back within a valid range rather than allowing you to keep a previously saved config (like when we changed our field of view min/max a few months ago).
I’m mentioning the field of view change because I’ve received some comments that our new FoV max of 80 is too small, the truth is there are two ways to measure field of view, horizontal and vertical. Currently we are measuring vertical FoV because thats how Unity handles it with their camera components but most games measure it horizontally.
For a standard 16:9 monitor our max of 80 equates to about 112 horizontal FoV.
I will look into changing our options config into horizontal FoV soon.

I’ve also been continuing to tweak the slug handling by reducing the engine power even further, increasing the weight slightly and adding a placeholder heavy slot which increases the weight of the Slug by 50% when its loaded!

I’ve also setup a system for storage slots to bind to hitbox types so we can setup passing damage through to an item’s durability and I’ve started to setup vehicle wheels to be destructible again in this way.


Hurtworld Update #104


The Recurve Bow parts are progressing nicely. I got the Riser for the first set textured last week and it’s looking good. Really like the the finish on the textures for this one the wood fits our stylized look well. I’ve moved onto the Limb String part that goes with this set. These two parts will probably be the most complicated parts to do because they have more going on with them than the rest of the sets. I foresee the rest of the parts will take less time.

The way we skin the weights for these will be interesting. I was thinking about the fact that they are modeled laying flat and somewhat axis aligned, but they have to be moved into place when skinned. This creates more work whenever I make a change to the mesh. It’s a lot to explain here and since I haven’t messed with it in a few months I can’t remember the workflow exactly, but I’ll explain more about these challenges when it comes to skinning time.

GnralRiser01 InuitLimbstringLowPoly01


Heya folks! This week was spent polishing up the map, adding in features like waypoint markers, allowing servers to opt-out of players using the map, players to minimise the minimap if they wished, and general performance and architectural improvements. In the next patch, there should be a bit more functionality in the map, such as zooming in to your mouse position, a more visible version of the player marker, and the ability for server owners to override the map image on clients with their own custom maps if they so wish.

While server owners will be able to easily create markers that show up on clients through Oxide mods, they may also wish to change the underlying texture the markers are shown on without rebuilding the level themselves in the SDK. Server owners will be able to provide a URL to an image in their serverconfig, which any clients will download and use instead of the map texture built in to the level. While I wouldn’t recommend changing that texture too often, as it might slow down players who don’t have amazing connections, this could be a good way to both showcase permanent changes to maps that you may make as a server owner, or to place any branding.

I also fixed a few bugs and made some small experimental changes to the user interface. I fixed a bug where raid drills didn’t detach if you put them on a piece of a building, never started it, and then destroyed that piece of building.


Afternoon, this week I did a polish pass on the map, fixing up a lot of the problems from the previous version I did. One thing I noticed straight away when viewing the map in game via the mini map is that none of the contour lines made any sense, so I we increased them by quite a bit, which definitely helped. I splat the main roads from dirt roads to stop any confusion with that, and probably the most obvious thing is the addition of the rocks. Rocks can take up large chunks of your view in the game and change the landscape pretty heavily so it makes sense for them to be on the map. I also added in a bit more lighting detail to the hills and valleys so they were easier to make out in the mini map.


I’ve also started working on all the assets for a meteor strike. At the moment I’m just getting my head around the particle system which at this point I feel I’ve got it pretty much figured out and I just need to play with it a little bit more to really get what I want. A huge change was using animated sprites over single images for things like smoke and fire, also turning on bloom makes explosions look much nicer. The explosion to the left in the image  was my first attempt and looks very horrible, the explosion to the right is the same effects but switched out with the animated sprites, as you can see it makes a huge difference. Now I need to make an impact that actually feels like a meteor strike.

ParticleComparison ForDev


This week I’ve been continuing to setup the Slug and testing and dealing with a few bugs in the mesh bake caching system.
It’s taken longer than anticipated to get the slug up and going, even though vehicles are our most complicated entities next to players there’s a lot we could do to make their setup simpler, there’s a lot of duplicated data that could be shared better and we could improve the borders between client and server by separating more components into client/server specific versions.
I’d also like to look at creating a simplified vehicle config asset that would build the vehicle prefabs when the mod is built similar to how our mesh attachment configurations work but I think at this stage that would all be better left until after ItemV2 release.

While the Slug is now up and driving around with its own set of engine, gearbox and wheel items, new engine sounds and working lights it still needs a little more tuning to really feel like a truck. I built the slug by cloning then adjusting the Roach which is what I’d recommend for anyone looking to mod a vehicle to do.
Right now it’s still a little too Roach-like in power and handling, we want it to struggle to climb hills and getting it stuck and having to push it out with a spear will be a risk that can slow you down and give other players time to intercept your haul. We want to play around with significantly weighing down the Slug when its heavy slots are full making it somewhat easy to get in but hard to get out. We’ll be testing it out in the sandbox Spencer has set up this week and I’m really looking forward to it.


This week I’ve been working on implementing the Air Drops and meteor showers for the dynamic hotspots internal test build. We should have the internal test build going by tomorrow, hopefully this will grow into something we can release to you guys by next week.

Air Drop
The air drop is pretty much complete. Still tweaking the speed, height fall speed settings n stuff, but all the features are there and working.

Meteor Shower
For the initial implementation, the meteor shower will be run at a slower interval of the air drop and drop a number of meteors across a large area. The impact locations will be marked on the map giving players a chance to get to safety if they would have been hit by one or get closer to mine the minerals that get deposited. At least 60% of the shower area will be encapsulated by death, which will funnel players into smaller areas and cause conflicts.

Slug Gameplay
I will also be looking at integration of the Slug into the metagame, hopefully making it a required transport device for specific rare resource types. More on this once its set in stone.

Hurtworld Update #103


The Slug is ready to be implemented by Tom this week. I got the texturing finished last week and it’s looking beast! I’ll be putting a heavy slot hauler trailer thingy on the back soon too. There’s a simple colour mask on this so we can vary the paint. This truck right now won’t get the same optional panels that the other vehicles have because it’s more of a utility vehicle. The tyres got a new treatment which made more sense than the original design, which was too ‘toony’. This is going to to be a great game play addition we think and I can’t wait to drive it.

Slug_Standard Slug_Headlights Slug_Taillights Slug_Colours

I also got going on the Recurve Bow components again. This is a nice start on the ‘Gnarl, Riser’ This is the sculpt, I’ll be moving onto the low poly today.



Hi Guys, for this Fridays experimental patch we will be rolling out the following: Silencers, In Game Map, Sound Improvements & Entity Spawning Optimization. As usual we will aim to push it out at 5pm Melbourne time and will include a wipe of all experimental servers.

I started the week implementing silencer mechanics for our AR15 and AWM along with giving the pistol some new sounds. While working on the sounds I realized working with the Unity built in distance falloff curves for anything remotely spatial is impossible. I wrote a custom falloff curve generator that gives much more predictable results and should fix the issues of creature sounds being audible over massive ranges.

Entity Spawning
There are thousands of network entities around the map like doors, resource nodes, creatures, lockers. We don’t want you to have to load everything in the map at all times for performance, so we only spawn for each client what is directly around them. As you travel around the map, some objects are destroyed on your client and new ones spawned as you subscribe to new network cells.

This is a good start, however when you join a new cell (40x40m or so) with lots of creatures or an epic base with 40 cars, there is a lot of work that needs to be done to spawn everything. If we did this in one frame, your game would freeze for upto 5 seconds while everything spawns in.

To solve this, a long time ago I built a deferred spawning system, where when joining new cells, at most one network entity would be spawned per frame. The result is instead of instantly spawning 500 entities, we spawn 1 entity per frame for as long as it takes to get you up to date. At a tick rate of 80hz (most our servers), this process can take around 7 seconds to fully add you to a cell. This is usually fine as we add you a long time before you are actually standing in it, even in a vehicle.

The problem we face now is when you respawn (or teleport due to a mod), the game isn’t able to predict this ahead of time and is stuck trying to load everything as fast as possible. This is often the time you want to interact with objects most to get back out in the world and kill the guy who robbed you.

In our old system, if a player wasn’t 100% spawned into a cell, the networked objects in the cell would be in a pending state as it was too difficult to determine which ones were ready to communicate. A side effect of this issue was your storage containers showing no items because they tried to send messages before your client was ready to receive them and assumed you already had everything you need.

In this In this Friday’s patch there are 3 major changes to entity spawning:
1. Any entity that has spawned on your client is now interactable regardless of if you have finished loading all entities (If you can see the object, you can use it)
2. Deferred spawns will prioritize each entity type differently in this order: Doors, Storage Containers, Machines, Ownership stakes, Everything Else

The effect this should have is, your lockers should spawn almost instantly on respawn, you should be able to interact with them as soon as they spawn, and doors will spawn first so minimal raiding hints can be obtained while still loading objects. There is one more optimization I could do by prioritizing spawns based on distance, I will wait and see how this feels to people on busy servers before going down that hole.

In Game Map
Cow_Trix has banged together a pretty kickass map system in the last week, there are a few reasons why I decided to put this in game. I’ve held off doing something like this in the past as learning your way around can be an interesting challenge. I was concerned making navigation too easy would take away from the natural skills people can develop in the game, given that everyone uses a map from the internet (me included) this point is sort of moot.

What I am really excited about with the addition of the map, is the ability to easily mark geographic locations, areas and shapes for different gameplay mechanics. One example is localized weather events are very hard to warn people about and make visible in the distance so people can avoid them. Because of this we can’t really add weather events that are particularly harmful as its pretty much random luck if you get stuck in one, however if we can mark an area on the map ahead of time players can adjust their plans around what is going to happen.

This doesn’t just apply to negative events. As I discussed in previous dev blogs, we are currently prototyping making resource hot spots less static, but we still want people to know where they are so they can contest them rather than just stumbling across one and farming it in peace. The map makes all these things really easy to prototype without needing in world effects that can be very time consuming to build, and costly to your FPS when they are in the distance.

Hotspot Competetive Experiment
I am currently prototyping a competitive test mode, paced much faster than existing Hurtworld, where most resources come from airdrops and meteor showers that happen very frequently and are visible on the map if you are close enough. I’m looking forward to lots of gunfights over interesting Terrain, death actually mattering because your base won’t be right next to the point of contest, and freedom to build anywhere again.

I’m also playing with much denser occlusion. More trees, more frequent and smaller mountains, making it much easier to get lost when you want to. Having a map to help navigate and hotspots on the map to pull people together and means there isn’t as much reliance on large open shared spaces that are easy to navigate and spot other people. I think this will help solo players a lot as people will have more choice over when they engage in a contest over loot, and should be able to scrape by in the middle of nowhere if they aren’t up for PVP or are under geared. I aim for progression to still be possible without contesting hotspots albeit much slower.


Heya folks. This week I’ve been working on the new in-game world map, coming soon with many of the features you guys and gals have come to expect from a survival/online map. At this current iteration you have a small minimap up the top right-hand corner of your screen that shows your local proximity, which can expand up to a full screen map. There will also be a permanent compass sitting at the top of the screen. You can see ownerships stakes, shacks, and your death – with a countdown of how long you’ve got to go claim your stuff until it despawns. You can place a waypoint, and while I’d like to figure out some way of sharing that waypoint easily with your friends, that may take a bit more work on the social structures of Hurtworld. Most of my time here has just been in trying to polish this particular feature a bit and make it easy and intuitive to use, trying to draw on other games with similar UI features to make a bit of a common language. I’m excited to see what we can do with the map, and I think it opens up some doors for being able to do cool stuff somewhere, and being able to easily tell the whole server about it.


I’ll probably keep polishing up the in-game map this week, and then also try and get a new version of the actual map, i.e. Mangatang, out this Friday. The last build we did of Mangatang had a bunch of issues from the small to the large (whoops, one spawn point anyone?) so that should be fixed.


Hello, this week I made some changes to the cargo crate to give it a sense of scale while in the air and made a bunch of LoDs for everything. I’m much happier with the new look, it actually has a sense of scale to it now. I sized everything properly so nothing feels too large or too small in relation to another object. I couldn’t help myself and made some little scenes with cool lighting cause I never get to play with assets like these haha.

PlaneShot DevBlog

I also started working on a 2d rendition of the map to be used in game. This is still a huge work in process, I’ve done a couple maps before but they were all very stylized and also weren’t really going to change so I could take my time, but our map is going to change a lot and needs to be updated constantly so I have to find the most efficient way to make this look good.



This week I’ve been continuing on with bug fixes, reintroducing caching for the mesh baker system and starting to setup the Slug.
Starting with vehicles I’ve fixed the issue with the inventory UI breaking when switching to the storage tab. I also fixed an issue where you would always get your hits denied when shooting someone in a vehicle that wasn’t sitting upright. This was because we weren’t saving rotations properly in our hitbox history buffer but this rarely caused any issues as most entities only rotate around their up-axis and their collider in the forward-right plane is symmetrical.
I also fixed a bug with our vehicle cameras, when the camera updates its position we do a series of raycasts from the screen corners to the camera pivot point to make sure we aren’t placing the camera through a wall inside of someone’s base or some other geometry. When inside a vehicle this camera pivot point wasn’t being updated correctly and it was instead being taken from the players first person camera position. This was most noticeable in the ‘crash vehicle’ the player enters to simulate crashes, when rolling along the ground the players first person camera position would dip under the terrain and then the raycasts would hit the terrain telling the system that the terrain is blocking the camera and we should put the camera in front of it. The player would then roll out of this state causing some nasty motion discontinuity as the camera would quickly shift under the terrain and back again. With this fix you’ll be able to crash without the camera freaking out.

I’ve also been diving back into the mesh baking system to re-enable runtime and build time caching.
Runtime caching means each time we combine meshes we store the result so if we need that combination again we can just retrieve it from storage rather than doing all the work of putting it together again.
Build time caching is an improvement to our mod build process, our mesh baker relies on us pre preparing our mesh attachments so they already contain the full set of skinning data and skeleton bindposes and also transforming all meshes into the same space (so all the meshes have the same up, forward and right directions). Previously we were doing all this work every time we kicked off a new mod build, now we store the prepared mesh attachment after each build so we can skip that work and speed up our build process. To make sure the mesh attachments are always fresh we delete them whenever their configuration changes (eg. which bone they are attached to) or whenever changes are made to their source mesh.

In the coming week I’m going to be setting up the slug and start playing around with our heavy slot concept where you’ll want the slug to move these heavy items around. We’ll be experimenting with movement debuffs, blocking equipping items (so you can’t use guns/tools) and taking up many inventory spaces but then having special dedicated slots for heavy items on the slug.


Dev Blog