Press Kit Wiki

Hurtworld Update #80



This week I’ve been working on the upcoming bugfix patch. This patch will be going live on the 12th of May (Friday) and we will be wiping ALL official servers on release.
We’ve got a release candidate of this build up on our devtest branch now, so if you want to jump in, try and break it and let me know how you go ( that would be really appreciated!
We’ve upgraded our devtest server ( with this build or you can change the dedicated server tool over to the devtest branch to test yourself locally.
To switch branches, right click on Hurtworld in your steam library and then click on properties. From there switch to the beta tab then change the drop down menu over to devtest. This should start the download immediately although sometimes you’ll need to restart steam or verify the files from the local files tab to force it to start.

Here’s our changelog for so far:

  • Triggers have been added to the borders of the Diemensland map that will instantly kill any player wandering out too far
  • No build colliders have been added to doors and the hatch preventing a range of construction exploits
  • CharacterController height is synced with crouch state every simulation frame, this prevents potential desyncs where the character acts like they are standing up but they have a crouching height on their collider
  • Fixed the attachment dependency for the hatch, hatches will now stay alive in unoccupied grids until their attached wall is removed
  • Added a temporary NoBuild zone around C4 explosions, this prevents defending players instantly rebuilding destroyed walls/doors/etc
  • Improved player movement correction, correction offsets no longer accumulate, moving in the direction of the offset reduces it by the same amount and offsets past the maximum limit are instantly rewound. This fixes a bunch of issues where players could peak through geometry when affected by some kind of desync
  • Improved construction validation against machines. This prevents a bunch of bugs where you could build things over ownership stakes and other machines to hide and protect them
  • Added an extra NoBuild collider on the ownership stake to improve construction validation
  • Fixed vehicle exit validation to properly check against trees
  • Slightly reduced size of c4 collider and fixed the construction validation. This fixes an issue where c4s could be placed inside a player to push them around


Hey folks, this week I’ve been working on fixing a bunch of bugs and regressions that occurred with the 5.6 Unity upgrade. Not many pretty pictures from me this week! There were quite a few gotchas that came up with this upgrade that broke a few things. For instance, in 5.6 it seems that a RenderTextures don’t correctly take the alpha channel of the camera’s background. Because of this, I needed to write a simple post effect on the icon camera that put the alpha back in from the depth map. There was also an issue where disabling and re-enabling a Reflection Probe caused its texture to destroy. As we turn off all Reflection Probes when we’re rendering an item, this meant that reflections broke every time an item needed to be rendered for a few seconds. To fix this, I changed the pattern from disabling Reflection Probes to changing their effective size to zero. This worked well! 5.6 also changed how UI canvases anchor themselves in the UI hierarchy which meant we had to remove them from all sub-windows. Still trying to find out if this is a bug, or an intentional change. Hopefully the former as this was an easy way to section off UI invalidation.

A lot of machines were in a broken state that I’ve been working on bringing back up to speed.I began fixing C4, but that quickly took me into deeper problems with how we were managing construction ghost instantiation and data management. There wasn’t really a clear authority for who was responsible for setting what, which meant that quite often a construction prefab would get into a bad state and either remain in the world or disappear forever. I fixed up the structure of this a lot more to make it clearer and not susceptible to race conditions across the network. I also brought a few UI windows up to scratch with the ever evolving UI structure, which is moving towards a much more UnityEvent based and component based system. Really there’s only two problems to solve at this point for pretty flexible modded UIs: dynamically linking server variables for machines to client side UI elements, so an Oxide script or whatever can have it’s variables reflected in a UI window on a client, and sending client events like button presses, sliders, etc, back to the server.

This coming week I’ll be continuing to fix a bunch of bugs in the UI, as well as continuing the process of bringing everything back up to parity with the live game.


I’ve been busy putting 3 skins that I designed last week onto the components of the AR15. I’m getting closer and have done about two thirds of the parts. We chose 2 of the concepts and stuck with the Angular Camo skin that was initially tested also. For now there will be 3 skins which will be unique to the AR15. These skins are fairly basic and will initially not have Specular and Gloss overrides on. This means that unlike the earlier testing phase where you could add Metallics and Pearlescent paint to sections of the designs, they will simply be a one-finish paint style. Eventually we will probably make the finishes changeable, but for now we’ll stick to the basics.

I should be done with these tomorrow and we’ll be getting them into the game and having a good gawk at them and a bit of a play possibly.

Ar15Skins_0001_Layer 1 Ar15Skins_0000_Layer 2


Got heaps of stuff done this week, I’m starting to get hyped for the initial ItemV2 release, awesome to see it all coming together!

Unity 5.6 Upgrade
I started the week with the 5.6 Upgrade, gotta say props to Unity, massive improvements with only a few regressions. I upgraded our AI to use the new built in navigation system, which is not only a lot faster, it means map makers can bake the Navmesh for their maps with the click of a button inside unity before publishing their map, no more screwing around with the live game. You likely won’t see any behavioral changes with AI from this update, however it opens up the door for us to do a lot more stuff with the navigation as we didn’t really want to go near it before.

I also switched over a few of our image effects to the new Unity official post processing stack which some would call an uber shader. It saves a few blit operations as it rolls many post effects into one shader. In addition to this 5.6 has some really nice graphical upgrades including a reverse depth buffer that puts a lot more detail closer to the camera over long render distances. This should stop a lot of the shadow flicker you’ve not seen for ages because you have had shadows turned off.

Skybox upgrades
We upgraded time of day to be more compatible with 5.6, and its looking amazing.


Performance check in
Its easy with a developer spec machine to let performance get sloppy in long dev cycles, I’m running a GTX 1080 so its pretty hard to tell when perf has degraded. So a while ago Mils put together a potato machine for us to test with, he just so happened to have our exact min spec lying around. Cow_trix had some concerns about the performance of 5.6 so I fired up our current un optimized dev build on the potato. Results were awesome!

The potato was pulling a solid 60fps with the graphics around the medium settings, which I think is better than what it gets in the current live build. We still have a few new optimizations up our sleeve which is going to make things run mega tight even on older machines, so fear not that the new graphical upgrades are going to kill your FPS, if anything with ItemV2 you will get a boost.

Red dot sight
I implemented the red dot sight mils finished recently. It works slightly different to the holosight, mainly that the dot doesn’t parallax when the gun is angled, it feels very awesome and accurate. While I was at it, I increased the gun FOV slightly and pushed the sight from the camera.

Here is it in action in both night and day:


UI Design Pass
I spent a bit of time skinning the new item slot stuff and hotbar making everything pixel perfect and what not, still a fair bit to do as I have disabled rarity showing on the slot which we will likely have in there, for now I’m happy with the basics.

While I was at it, I created decent icon poses for the runtime icon render system. Its quite a challenge to fit complex objects into 48px and make them look readable. I found that very low fov and rotation tricks help the best.


When update
Progress this week has been good, we are burning through our bug list. Still hopeful we can get an experimental dev build out to you next week. Stay tuned 🙂


This week was spent really trying to nail a few key items that are going to be pretty prominent in players inventories without spending more than 2 or 3 days on each. Due to time constraints a lot of the concept sculpts need to be done specifically so they look good as icons otherwise you end up at the end of the pipeline with an unreadable icon. This presents a lot of challenges that you would not expect from something as small as 48×48 pixels. Silhouette and colour contrast are generally the two main things that get lost in icons, so while doing these last 3 we have really gone back and fourth on pushing them to their best so they are readable and look good at such a small size. These two have a sharpen filter on them to make them pop nicely.


This render here is in Substance Painter, using their standard iron material. This is a perfect example of something looking good up close but not working as an icon. The detail was too fine for the light to really catch the edges at such a small size so the icon would just look like a flat blob of grey hence why a second icon mesh was made with much thicker bevels to catch the light nicely.


This is the icon for stone, in it’s current state it look good up close but once scaled to icon size, it too will look like a grey blob. The plan is to add different colours to certain faces as if the stone has freshly broken away, lighter faces mixed with the illuminated and shadowed faces create a good amount of variation for an icon to pop, then with possibly a little bit of colour variance it should make for an icon that looks great in your inventory.


Hurtworld Update #79


This week has been fixing all the broken stuff that would block progressing in ItemV2 survival. The map and initial progression is now in a playable state as we close towards an initial ItemV2 release.

Cow_trix and Tom have both finished their respective projects which were the final feature blockers for a releasable ItemV2, and I’ve now put the entire team on Release mode. We will be all hands on deck fixing regressions, testing and getting the game back to a decent state instead of adding new features and breaking more stuff 😉

Unity Upgrade
The only major blocker left is getting AI working again. The way we generate maps right now is causing havok with our old pathfinding system, which has been a pain in the ass for most of development, but has also been the only good solution. The good news is Unity 5.6 is out, and with it a heaps better Navmesh system so I’ve bit the bullet and am attempting an upgrade tonight.

With everyone in release mode, I hope to get something out to the experimental branch in 2 weeks time.


This week I got started on getting some of the non-equippable items into Unity. Doing simple items comes with a lot of challenges as they don’t need to have over the top detail but they can’t just be flat boring models, they need to be somewhere in the middle. Another challenge with smaller more background items is their triangle count has to be lower, this is fine for things like clay and bricks but requires a decent amount of thought when it comes to small items with lots of detail. Probably the biggest hurdle to overcome with these non-equippable items is making sure they don’t just turn into a blob of noisy colour when they get scaled down to icon size. Zbrush definitely makes life easier when it comes to these sorts of items though (and most others) as it allows me to concept them quickly using pre-built materials already in Zbrush, this is a life saver as it stops me from having to go back and fourth through the entire pipeline making changes, instead I can get it close to perfect before getting it in Unity.


I also tested out some new patterns for the pants, I think they look pretty good, having such quick and easy control over color schemes using the color masking shader is extremely helpful. The mix of objects with different specular values stand out nicely across most color schemes and will most likely be something we try to do to all upcoming models as breaks up the monotony of items with a mostly flat specular, this is something that’s pretty important for bigger items.



Hey folks. This week I’ve been doing a bit more work on the UI, integrating Tom’s threading mesh baking into the icon system, fixing a few bugs in the SDK for Spencer and figuring out the best way to set up collider data on world items.

I spent a fair bit of time on item dragging to make it feel intuitive and spatial. It turned out to be pretty tricky, as icons can change contexts pretty massively as you drag them around. An icon can change both aspect and display size as you drag over a slot, and that needs to feel like the actual item drag isn’t jumping around the screen – i.e. there needs to be a feeling of continuity. To achieve this I had to put in a few offsets that play off each other, so the internal sprite is offset from the drag raycast point, which is in turn offset again from the actual mouse cursor position. As usual with UI work, a lot of this was just testing and going off what feels good.

The hotbar has seen a few changes. Items in your hotbar are somewhat “focused” or important to you, so we thought they should probably show larger icons. I’ve been playing around with this idea, stretching the hotbar up so it can display different aspect icons to a pretty nice resolution. Check out two prototypes of how this might look below!


Finally, I’ve been looking into more explicit mesh generation for the colliders of world-items. Mesh colliders are just not performant enough to run large amounts of rigidbodies, but they were very easy to configure! I’ve been working out a good way for a world item to figure out what physical volumes it takes up in the world and the best way it can create primitive colliders to fill that volume. Currently we’re just slapping cubes on everything, although I’ve set things up so that hopefully when we find objects where that really doesn’t work, we can extend the system to create more complex collider structures.


A new Stock and a new Muzzle Brake are now good to go. This completes my run on the current components for the AR15. There are now 2 options for all the component slots.

2 x Iron Sights, Red Dots, Magazines, Stocks, Suppressors, Muzzle Brakes, Barrel Guards. That’s 14 component items and 15 with the Receiver. Actually this is a lot more items than I thought after doing a recount.

I really like how this stock came out. Was interesting to model.

cache01 cache02 Bounty01

I’m now working on 2 skin designs for the AR15. These like the car skins will be unique to the gun type but will be available across all the AR15 components. I already have 1 design which was seen previously on this gun. I’ll be adding that design onto the rest of the components and then making a new one and applying that also. Below are some new designs that are just painted over a screenshot of the AR.



This week I finished up converting our mesh combiner into a threaded system. First up was implementing a system to pick level of detail for a combined mesh, you can now set the distances for medium, low and culled (high is picked when closer than medium distance) and CowTrix has added a way to override the distance behaviour and allow another component to control and set the detail level (distance doesn’t make much sense for things like the new icon renderers).
I also ran into some complexity around cleanly serializing the configurations. The mesh data from the configurations isn’t calculated until building a mod out of the SDK (or if previewing in the SDK the data is built temporarily as you need it), this data and a reference to it needs to be built into the asset bundle.
To achieve this I added pre and post build steps to our mod build pipeline, during the prebuild all mesh attachment configurations build their mesh data and save them into a temp folder. The postbuild step deletes the temporary folder then iterates through the attachment configurations setting all buildstep object references to null. Without explicitly nulling the references Unity keeps the old reference around even though it doesn’t point to anything so it can generate extra information for errors. In our case though we know we only need these references while the game is running so we don’t need the extra error info plus when using a version control system the changing reference will be marked dirty after every build which is a real pain.

I’ve also started working on the next bugfix patch, which we will get out as soon as possible! Thanks to everyone helping me out by reporting bugs!
I don’t want to spill the beans on all the changes just yet and spread the bugs before they are fixed but as a quick idea we’ll be fixing some remaining crouch state desync bugs, some construction bugs, fixing a few issues with the Diemensland map and adding a short temporary no build zone to c4 explosions to prevent bases being immediately rebuilt.

Hurtworld Update #78


I got a lot done this week, I finished the Red Dot sight, which is one of my favourite sights in any game that uses it. With it’s thin bezel for maximum viewing and active anti occlusion, this sight will be a staple for most players. A lot of the silencers and sights will be interchangeable between the various guns which means we get a lot more use out of these items. Red Dot on a bow maybe? 😛

Dappler_0000_Layer 2

Next on the menu is the thick stubby silencer which really gives a meaty feel to the end of the gun. I’m really starting to get in the groove making items now, and the process is speeding up. I’ve started working on another stock for the AR15, then I’ll do another tip/muzzlebrake. After that Spencer has requested I move onto the Sniper Rifle.

Quash_0001_Layer 1


With my workflow now sorted I’ve managed to get a more time consuming asset than the vest to the same stage in half the time which is great progress. When it comes to games, pants can be tricky to get right, too much detail and they are distracting, not enough detail and they are boring. I like having noisy areas around the knees and ankles and relatively smooth areas in between so the players eyes have a place to rest. Some different materials were added to the pants to break up the generally flat, boring specular reflection that fabric has, there’s still some tweaks I want to do to the make certain things pop better like the belt clips. Everything baked out nicely and I didn’t run into any problems, Substance Painter definitely makes the baking process much easier with it’s “By Mesh Name” feature that allows you to bake perfectly without a cage. All in all I’m pretty happy with the outcome.


Here’s the pants in Unity (these screen shots are using Unity’s standard lighting not Hurtworld lighting) with the RGB mask shader, there’s a bit of trial and error that goes into figuring out which parts would be best left untouched. I haven’t done a dirt/damage layer yet, they possibly don’t need it, although I have found that dirt layers that look good on coloured assets look terrible on full white assets so that’s something for me to keep in mind. The next step will be testing out some cool patterns and designs to use with the colour masking.



Hey folks. This week I’ve been continuing work on multi slot items, fixing up bugs, making everything a bit smoother and also playing around with changing slot sizes and the UI a bit.

Something we’ve realised with UI design is that scrollbars suck, and if possible we should try to get rid of them from the UI. We’ve been looking at reducing the inventory grid size by about 25%, which has worked pretty well. Icons are still readable, and it means you can get much wider view of what is in an inventory. Inventories can also take up far less room on the screen. Then, for more important items like the things you have in the hotbar, we can have a larger slot that shows the item in more detail.

I changed up a lot of stuff around dragging items between slots, so the expanding circle is now dead. We changed over to just dragging the icon itself, which gives a more tactile feel to things. I’ve also been playing around with some slot decorators to quickly show item rarity, which currently is some colored borders to a slot. These are a bit ugly right now, but work pretty well when it comes to actually identifying items.  Check it out below.

The workflow around setting up poses for different icon aspects is a bit messy right now, so that needs to be cleaned up. Basically, you need to be able to pose the item differently for if you want a 1:1 icon vs, say a 1:2 icon. Originally I put that information in the item component, but it needs to be moved out somewhere else now. Then, after that I’m onto a new type of machine! More info on that soon.


I’ve been continuing work on the mesh combining / baking system and improving the model viewer. The idea of the model viewer is to have a way to preview assets in our SDK and have them look as close to in game as possible. It sounds simple but quickly gets complicated as we use several third party plugins and assets in our rendering pipeline that whilst we have a license to publish them with our game, we don’t have a license to redistribute them through our SDK.
This means we can’t perfectly recreate in game lighting conditions in the SDK so instead I created a lighting snapshot asset that creates a skybox from the surrounding level geometry, a reflection probe from the in-game skybox and captures the current directional and ambient light settings.
All lighting snapshots are selectable for preview within the model viewer.

To build the skybox I used render textures where rather than drawing to the screen you draw onto a texture.
Whilst I was experimenting with render textures I Implemented a technique where rather than draw directly to the screen you draw onto a render texture first then draw the texture to the screen.
This sounds like useless busywork but its power is that we control the size of the render texture and it doesn’t have to match the screen.
This should allow our players near the minimum spec to squeeze a bit of extra performance out and people with beasts can render at a higher resolution and downsample back to their screen (which gives a smoothing effect like anti-aliasing).


I’ve also been keeping my ear to the ground listening and watching for bugs and exploits. After putting the finishing touches on the mesh baking I’ll be moving onto fixing issues in the live game with a small patch.
If you know how to reproduce any bugs or exploits you can help me out and report them at


This week I’ve been cutting our content design back down to a manageable size so we can get a survival build out onto the experimental branch. My dreams of infinite procedural progression tiers have been put on hold for now. I got a bit ahead of myself attempting to re-define the survival genre and lost sight of our original goal for ItemV2:

“Rebuild our content progression to be well balanced for full loot”.

This alone is a pretty big change that will need careful refining, and adding completely procedural loot for everything, procedural creature generation, infinite tiers of progression and procedural maps into the mix has pushed us into a very long development cycle. While all these systems are somewhat working, configuring them has proven to be a much harder task than I imagined. All these systems will make it into the game one way or another, we will be releasing them in baby steps as not to loose sight of the parts of the game that worked so well in the first place.

The Plan
The only really crucial feature of ItemV2 for survival is that things are crafted using blueprints. As I have gone off the concept of everything you craft requiring blueprints found in the world, we need a way to keep the semantics of this without actually gating the crafting of items until you find a blueprint. If we take the finding of blueprints off the table for a second, we have a pretty simple solution, allow the creation of base level blueprints by the player and keep the rest of the workflow the same. If creating blueprints only to be able to craft them seems like it doesn’t make any sense, I can see why, it will make much more sense when playing it.

What this creates is players always having the ability to progress any item slot they need without waiting for an item drop. If we re-introduce rare blueprints at this point, we can now make them much less common as players aren’t at all dependent on finding them to progress. Blueprints found in the world can be upgraded versions of the base level blueprints the player can create on demand and will always provide aesthetic and stat bonuses over their default counterpart, maintaining the feeling of finding rare loot without overloading the player with trash blueprints they don’t need.

The Drafting Table
This brings me to our new machine, the drafting table. Its role is to both allow the creation of base level blueprints at any time for little or no cost, and to reveal the contents of rare found blueprints. The revelation of found blueprints is designed to shift the loot discovery point from when you are out in the world in danger of being killed, to when you are safe inside your base and can actually pay attention to the rare item you have discovered. Found blueprints will only tell you the class and rarity of the item the blueprint is for when initially looted, only giving you a hint of what you will get.

when Update.

Dev Blog