Press Kit Wiki

Hurtworld Update #83



Hi Guys, a much more positive note this week. For the first time in ages, Hurtworld is playable again. Our Friday internal build was close enough to releasable I am confident we should have something to push to experimental this Friday!

With that, I will outline our plans for the next couple of months. However you probably know by now to take whatever I say with a bag of salt 😉

Experimental Experiments
Over the weeks / months of internal testing I’ve tried to do, I’ve found that my goals for the systems we’ve been building aren’t as simple as “throw them in and game is 100x better”. We are trying a lot of things that really haven’t been done before, and with that comes a lot of stuff that doesn’t work first time. The hard part here is determining whats a bad idea vs sub par execution. The only way to figure these things out is keep trying different things, rapidly iterating and scrapping until we break through the barrier.

We have established the wipe schedules, which have obviously become stale after a long period no new content. We plan to turn this on its head.

The current live branch will remain for those who want a more stable experience, and each week / fortnight we will be wiping and releasing drastic changes to the experimental branch. One week might be on a massive map with an RPG progression, the next might have guns everywhere and make C4 super cheap. We are going to prototype drastically different types of survival without worrying about staying true to our roots. The ultimate test of these experiments will be how much you guys want to play them. We eventually hope to distill the perfect survival experience from these experiments, and refine it into a polished game.

Our tools and your tools
Probably the most exciting thing about the Hurtworld post ItemV2, is that over the last 8 months we’ve been working our asses off to restructure the way we work to give modders almost as much power over the game as we have ourselves. We now author content for vanilla Hurtworld using our own mod tools, meaning while we are flipping Hurtworld on its head making experimental builds, modders can start doing the same. Like a configuration from one of our experimental weeks? Grab a copy of the mod project and keep working on it or install it semi permanently on your server.

What experiments come out this Friday?
This weeks build will be a much buggier version of the current live branch of Hurtworld (not super exciting). As much as we can cram into our new systems, we aim to match what we already had. This is in the interest of walking before we can run. We need to test our new systems at scale before thinking about game play experiments, we have done an enormous amount of work under the hood, so this week will be to let everything break and give us some time to fix it in a controlled environment. The awesome part about re-implementing the legacy progression is how easy it was with our new tools, this means iteration will be mega fast.

What after that?
Once our new systems are stable, I expect this to take about a week maybe 2, we will start to introduce the new gameplay elements I’ve been talking about in the blog for ages. Things like blueprints, how and where resources come from, punishment for death, kill loot, durability, repairing, respawning mechanics, teleportation, raiding costs etc.

Each new experimental wipe, I also hope to include drastic map changes. What we are releasing on Friday will be a completely procedurally generated map, meaning by tweaking configuration values we will be able to deploy a new map with very little effort. As a minimum we can change the random seed to generate a new map with no effort, but I hope to slowly improve it as time goes rather than it stay as a monolith that I don’t dare touch like daemonsland. We have a truckload of buildings and city assets waiting to go into the map, more and more of these will be added to the generation landmark sets as we go.

Pre-early access all over again
So we are sort of back where we started, which I have no problem with. Nobody would say we got Hurtworld perfect the first time, and I think its safe to say the survival genre is still a bit of an awkward experiment straddling between Arma and World of Warcraft. I still believe there are amazing possibilities to explore.

We do actually want (and need) your feedback
We’ve been a bit quiet on the old community interaction for a while… we haven’t released anything new for a while, it doesn’t really make sense to get feedback. We’ve discussed the live branch to the ends of the earth, we just needed to get stuff done. Now that we are releasing the experimental builds, we will be ramping up our presence in our community channels, tell us what you think, we will be listening.

Re imagining of live branch in ItemV2 on experimental branch this Friday for stress testing (if all goes to plan), then weekly or fortnightly wipes with drastic gameplay experiments on the experimental branch over the coming months.

I’ll leave you with the procedural bot configuration (which picks eye bleeding colors), and running them down on a bike.


I’ve been making some alterations to some of our existing assets this week. Firstly I was tasked with combining the eye of the Shigi into the rest of the mesh. Using some weight copying to assign the mesh the correct weights got me most of the way there. Turns out Maya’s copy weights tool is not the best. The tool copied most of the weights across without issue, however the front feet lost some weight data, and I had to manually paint them back in. I got there in the end but I feel that if the tools weren’t so dodgy it would have taken far less time.


The next small project I was tasked with was modifying the FPS version of the arms. This model is used to show the arms and hands in fps mode. The FOV (field of view) has been modified on at least some of the guns, causing the tops of the arms to clip through the camera plane. I removed the shoulder parts for the arms and initially had just rounded off the shoulders to be a kind of stump. I didn’t  love the stump look so I made a cross section of cut off meaty texture instead. These were a hit with the other guys and so we decided to keep them. They have now been dubbed ‘Steak Arms’ I also had issues with copying the skin weights over. The fingers had issues where the weight maps were copying onto the wrong parts even though the geometry is exactly the same. Sorted that out too though.



This week I’ve been continuing getting ItemV2 ready for the experimental release. It’s been awhile since we’ve ported the bugfixes over from the live game into ItemV2 so that’s been my focus this week. The last time we merged in changes from the live branch was just before we added sleepers so I’ve had six patches worth of stuff to merge up.
Unfortunately any kind of auto-merge wasn’t really appropriate because some of the fixes were for systems that don’t exist or have radically changed in ItemV2, some were fixes that were ported over from ItemV2 and for some things like Unity prefabs or our item objects the serialization has changed so much that no kind of auto-merge was possible.
Luckily because I’ve been doing most of the bugfix patches the changes and reasoning for them are relatively fresh in my mind so I’ve been able to get through them at a good pace. Currently we are now synced up with except for the sleeper system which I’m working on as I write this and should finish soon.

Unfortunately we didn’t make it to experimental release last week as hoped but we managed to get our internal test build up and going on Friday.
Whilst this contained some bugs we are working through now and it also needs a bit of an early game rebalance due to the nature of full loot we are feeling pretty happy about where it’s at and as long as no major disasters occur you’ll be able to play it this week!


Had an enjoyable week designing different ammo containers, looked at a lot of vintage ammo boxes for inspiration, back before design principals existed. Due to the simple shape of the boxes, the colour selection had to differ greatly other wise players could potentially become confused about which ammo they had, which is not a great situation in the heat of battle. Made some changes to the 5.56 ammo crate, took out a lot of the noise from the texture making sure it fit into our style a bit better. The quiver ended up with a very primitive design which I think suits it considering arrows can be crafted pretty early in the game. The arrows are very low poly as the poly count needs to be kept down considering you can throw out a ton of world item, which is why they look very square. The feathers will possibly change once the arrows get done properly.

Getting pretty close to finishing the list of world items I have, Concrete, String and Wood Planks next! Still trying to figure out the best way to go about texturing shiny things like Amber and Diamond stuff, most likely a job for someone on the technical side of things.



Hey folks. This week I’ve been fixing up and extending some of our commonly used shaders, implementing some performance improvements and fixing various broken things for the ItemV2 patch. We had a good play on Friday, and it’s all looking and feeling pretty sick!

First up this week, I changed how we copy the EntityStats to a creature when we instantiate a new instance. We’ve talked about EntityStats on here before, but if you don’t know, it’s the system that Hurtworld uses to simulate things like temperature, health, damage, nutrition, all that stuff. Every instance of a creature, player or machine needs its own instance of it’s EntityStats. Previously, we did this with a very expensive JSON based clone method that was very easy, but very very slow. I remembered that Spencer had built a pretty awesome Ahead-Of-Time clone attribute a while ago for Items, and I thought that it might work well for this use case as well. It was awesome! With just a few little adjustments, I could generate concrete AOT cloning methods that would create deep, new instances of these complex objects. You can see how much of an improvement that was to the server startup time! We went from 18 seconds, to < 1.


I also spent some time getting our commonly used shaders up to scratch. Our shader workflow is pretty successfully in the Unity Standard PBR now, but there are some things where that just isn’t possible. Namely, water and tree billboards, which are transparent and complex. As they are transparent, they don’t (nor should they) draw to the depth buffer. This means that post effects like atmospheric scattering don’t work out of the box like they do for opaque objects. Previously I had to do this whole thing where I extracted the atmospheric scattering logic in a way that could work easily for vertex shaders, but I was in luck! The Time Of Day 5.6 patch contained functions that easily did all this so it was much easier to implement this time around.


Hurtworld Update #82


Hi Guys. Progress feels pretty pathetic this week, I have been testing the shit out of all our systems, raising a truckload of bugs over and over again, doesn’t feel like the list is getting any smaller. I’ve also been sick for the last couple days, hence the blog delay.

We will be doing an internal playtest with whatever broken state we can come up with. If that goes OK, I might put it out mid next week.
Stay tuned.


This week was an interesting one for me, I’ve started doing a decent amount of hard surface modelling and while I’ve done a fair amount of hard surface modelling in the past I primarily focused on characters and organic modelling but I do enjoy the challenge and the practice of hard surface. The yellow pistol case is what’s now being used as the detonator cap world item, this is due to the size and design of the actual detonator cap being far too difficult to see in game. The bright yellow case is much better as it stands out in the world and can be easily recognized. The actual icon is basically a 3D rendition of the original icon.


As you can see here I’m also working on an ammo case for 5.56 ammo. These are the high poly models for the detonator cap world item and the 5.56 ammo world item. I like to add a lot of thickness to my models to give them a good silhouette in game, I find when if everything’s too thin then by the time you build the low poly and get it in game you are left with a very weak looking model.


Cutting the high poly models down to a suitable amount of polys for the game can be a very difficult process, you need the models to retain their thickness and silhouette while simultaneously cutting out as many polys as possible. Normal maps are super helpful in this process as you can keep a lot of detail while losing a lot of polys. These two renders are from substance painter, I’m not particularly happy with the ammo case texture, I feel it’s too noisy and possibly too realistic, but it’s not a hard fix.

DetonatorCaseSubstance1ForDevBlog AmmoCaseSubstanceForDevBlog


This week I have been wrastling with a pit viper called Autodesk Maya. While Maya is a powerhouse in games and film it is also super frustrating sometimes. I learned to do a bunch of Skinning  with it’s proprietary ‘Paint Skin Weights’ tool. I have to say it isn’t as bad as some of the tools Maya has (I’m looking at you Boolean Modeling Tool) It does have it’s quirks and illogical not-so-easy-to-use interface. Aside from Maya being interesting to deal with I also had to get used to setting up the configs in Unity which were actually pretty easy. The coders made our Item Configs as easy for an art brain like myself to use as possible. Thanks gang! Now I don’t blow a brain-valve every time I deal with setting up items.

This next image shows a Sock Puppet (low poly simplistic mesh) which I used to get a nice smooth gradient across the Bow limbs. This helped a lot because setting and painting the weights of a higher poly object takes a lot longer to do. This method also helps all the vertices move together without detaching or doing strange stuff.


Below is the final skinning I came up with that gave me a good result for the Limbs and String. This part of the Bow is influenced by two joints, so there are 2 weight maps assigned to it. There was a little tweaking where the Limbs meet the Riser or Grip bit in the middle and was also some tweaking where the string meets the limb tips.


Here’s a final animation of them working.


Stress testing has been colorful!

Stress testing has been colorful!

Hey folks, not really any pretty pictures from me this week, as I’ve mostly been in script land. This week I’ve been wrestling with some caching issues with the item rendering system. This system has turned out to be more complex than I first thought, and has taken a lot of thought and almost working versions to get to a good point. I did a stress test this week that placed significant load on the system, rendering a few hundred icons a frame, and I discovered that the caching key recycling was not working as intended. I’ve realized it’s really asking for it to pool a key object that you use in a high-frequency cache, and that you have to be very careful about how you manage and invalidate those objects. I was incorrectly keying the results of the icon renderer and world item builder in several places that only became evident when placed under high load. Asynchronous character mesh baking has also been thrown a few spanners in the works, as I naively put in some shared resources where I shouldn’t have when first designing the system as a synchronous, single threaded process. I think there’s light at the end of the tunnel here, I’ve just had to build a few test cases to push things to the limit. I’ve definitely learned a lot about this specific problem, multi-threaded systems and caching!


This week I’ve been working on ItemV2 helping to push it closer to being ready for the experimental release.
After finishing up the mesh attachment build changes to speed up our mod build times I’ve moved onto cracking through our buglist with the other coders.
Because of the bugs occurring in the item icon system I wrote a stress testing tool for our mesh combiner/baker that we can use to verify the stability of the system. This stress test scene loads up all our content packages then pulls all the mesh attachments from them and bakes random selections of them together as quick as it can. Because the test loads everything this includes some half setup attachments and old attachments with deleted references, this is good for our test so we can make sure the system wont come crashing to a halt due to an incorrect configuration. After running the test for a while we also use memory profiling tools to check for leaks.

We’ve been making good progress and it looks like we’ll be able to do a test release to an experimental branch on Steam this week! I’m looking forward to hearing what you all think.

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!

Dev Blog