Press Kit Wiki

Hurtworld Update #81



Another big week of hunting and crushing bugs, filling in item configurations and making sure everything is properly setup to close in on some sort of release.

When Update
We have made massive amounts of progress this week towards the release, but as we test more the bug list keeps growing. At this point it will be atleast another week before the ItemV2 preview will be made public.

Our code that handled impacts was a horrible mess, melee and ranged impacts were completely different code despite doing 90% the same thing. This led to big inconsistencies between them and made improving functionality hard. I was fixing a bunch of bugs in the ItemV2 impacts so I spent a night rebuilding the impact system to be more modular and be re-usable. These can now be configured as scriptable objects in our SDK projects and tailored to specific uses.


I also re-implemented the spear to use the new Equipment system and Mesh attachment system.

Projectile Rendering
Our projectile rendering was broken in 5.6, so I spent a bit of time fixing the projectile visualizations to use the new 5.6 linerender features.

You may also notice I am shooting with a piece of animal fat apparently, another bug the team is working on.

Gun Generation
As Mils has now put all the AR 15 pieces into the project, I built an item generator that constructs a fully kitted AR15 with procedural paints. They are looking pretty sex.

Playing with this generator has given me a decent idea of how we will do low tier equip painting. The auto generator is coming up with fairly good consistent colorways with the occasional trash. What I will be implementing for low tier painting, is a sort of slot machine system where you get 5 or so rolls on getting a good paint job. At any point you can lock it in, or re-roll and try to get a better one. Each group of rolls will have some non trivial cost, and should make for an interesting mini game for pimping your gear.

Here is an example of 8 procedural AR15s



Hey folks. This week I’ve been fixing up more bugs in the UI and with items, changing how we do static item visualisation, and fixing up as many things as I can in preparation for the test release that’s coming soon.

Debugging the UI got a whole lot easier, as I wrote a little framework to easily visualise points, rectangles as an overlay on screen. This made it a lot easier to see exactly what was happening under the hood with the UI and exposed some good ways we can optimise in future! For instance, a simple application was showing on screen what was currently capturing the mouse UI raycast. I found that we are raycasting against a lot of objects that we really don’t need to be, like random bits of text or things within buttons. I also changed item slot dragging to be a multi-raycast system instead of the single UI raycast I was trying to get away with before, which led to some inconsistencies with dragging that we didn’t like very much.

We also changed how we do icons and world-items for non-equippable things like food, materials, machines, etc. So things are more unified, these static objects will now use the pretty amazing MeshAttachment tool, just baked to an empty character. I spent a fair bit of time setting up the many items in the project to this new structure, and it’s working great! I also put in a bunch of the world items tehsplatt has been working on.


Other than that I’ve been fixing up a bunch of bugs in both the SDK and the game, such as vastly optimising how we were setting up skeletons for creating icons and world-items, which means every item having it’s own pose is now an entirely achievable dream with little to no overhead.


My name is David Bow-ie this week. I started with some concept designs for the new Recurve Bow. The old bow was fine but while we are redesigning it we thought we’d add a component system to it’s design. Much like the other weapons we wanted this to have parts that would be interchangeable. There will initially be far less parts for this bow, but the design is very modular, so we can swap parts around as we create more of them. I also beefed up the shape of it so that it had a thicker appearance so it would not get lost in the world and in the UI.


I’m now doing some skinning to fit these into the animation sets that exist for the current bow.  I’ve not done this with our systems ever, so it will be a learning experience, shouldn’t be too hard though.  The idea is to check this mesh with the current animations, to make sure that they work and don’t look whack. After that can move onto properly sculpting the high poly. This will be a welcome change from dealing with metal plastic and rubber that the AR15 was constructed of.



Been getting through as many world items as I can this week, really enjoying the small design challenges that come with each new world item, although not enjoying the baking problems that each one presents but with all the midnight problem solving I’ve been doing in substance painter I finally feel like I’ve worked out all the kinks in my workflow. Down below are two of world items I was most happy with. Figuring out how we were going to approach animal fat in 3D was an interesting task, Cow_Trix had the best suggestion, a slab of pork belly. This was definitely the best option as a blob of animal fat just looks like a white smudge at 48×48 pixels and isn’t a very interesting world item (hoping for jiggle physics on the pork belly). The leather was probably the hardest/weirdest thing I have ever retopoligised and took a couple goes to get right. I felt the duct tape was a nice addition.


Here’s all the icons so far (excluding clay, flint, animal tendons and seeds). I think I’m becoming addicted to collecting these little icon snap shots. Gotta catch ’em all.


Figured I would add this in here as an example of a bad looking icon. This is the detonator cap, while the idea of adding the wires to beef it’s silhouette up made sense and looks decent when it’s larger, the icon is just a blob of noise and just doesn’t look good from any angle. The world item is now getting changed to a bright yellow detonator case, this makes it easier to see in the world and stands out in your UI as something special/rare.



This week I made some last minute changes to, put it through testing and got it released. Big thanks to everyone who jumped onto the devtest server to help test! You were all a big help and contributed to finding some broken construction validations, problems with the camera whilst crouching on a ladder, fixing ui performance issues and adding a fix for empty player names.
During the test process I also learnt that we need to improve our process for testing with the community and give players some kind of starting kit of items or other ways to bypass progression without handing out admin access, luckily this kind of thing is about a hundred times easier to setup in ItemV2 so it’s something we’ll keep in mind as we move towards the test release.

I also spent some time working on ItemV2, improving the accuracy of the lighting snapshots, fixing some bugs in the mesh baker and improving mesh attachment validation to make sure textures are imported as the correct type (eg. normals imported as normal type, Recoloring masks imported as non-sRGB textures so they aren’t converted into a different color space).
I also started work improving the build step for mesh attachments which I’ll be finishing up this week. Whilst the mesh attachments are now in a good place in terms of creation and configuration deferring mesh attachment creation to the mod build step has bloated our build times by an unacceptable amount so we’re changing the system to keep mesh attachment assets around and mark them as dirty and requiring a rebuild whenever their source meshes are changed. Now a mod build will only create missing and out of date attachments.

With out of the way I’m now back onto ItemV2 full time and can’t wait to get it in your hands to test out ASAP!

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.

Dev Blog