Press Kit Wiki

Hurtworld Update #117


Hi Guys, this week I’ve been continuing work on the Town Event System. To enable us to test each town event quickly without needing a fully spun up level and full server, I spent some time fixing up our deathmatch game mode and extended it to allow us to load a single town and continuously run the town event like a call of duty server. Once the event finishes, everyone respawns and the event starts again. Earlier in the week we spent some time doing a 3 team, deathmatch in the event Splatt designed without the custom event logic and it is playing really well. I will release these mini maps with town event test game mode to the workshop as we build them so anyone can start a server and give them a run.

Weapon Balance
Our TDM playtesting gave me a good chance to revisit weapon balance. At some point the shotgun became stupidly powerful, this will get a slight nerf in the next patch.

Farewell Cow_Trix
This week our homie Cow_Trix is leaving us to travel the world after giving his absolute all to Hurtworld for the last 4 years. He was the first programmer I ever hired, has surpassed every expectation I had of him. I only hope that he finds happiness in his travels until he gets kidnapped and needs us to pay his ransom, forcing him to return to the team.


I’ve got the normal baking done on the Mozzy this week. This was a pretty straightforwared task and it all came out fairly easily give or take a couple of mishaps. I’m now doing the Alpha and Normal map detail pass that I do when I feel it’s necessary to add details at this stage. Some Normal map details are best added now because they can more easily be included in the Occlusion Map bake and Curvature Map. The curvature map and the Occlusion map control some aspects of the Smart Materials within 3DCoat and so am going to include these normal details so the Smart Mat’s produce the best results. Some of these shapes are better done in Illustrator too, which I have been using for a long time and can get very precise results with. Things like repeated lines and very specific shapes like those you can see on the back of the pilots chairs are some examples. I also got the cockpit instruments halfway done at this point so I could see what they would look like. These will be dissected a little more and then filled with the correct PBR materials once I start working in 3DCoat. It’s all looking good and how I envisaged it.

Also I would like to say Ciao Bello to CowTrix, who is off the get kidnapped in Bolovia or adjacent countries. Cow was the second hire after me and we’ve been in the trenches for years now. Will miss your face amigo. xx



Hiya folks! Not a lot to report from me, as I try to pack everything up in my final week. I’ve been trying to clean up my code base, get the map pipeline as clean and easy as I can in preparation for Luka and others to take over, and generally tie up loose ends. Had a great time playtesting Splatt’s town battle zone on Monday, some really fun stuff there.

This will be about my hundredth dev blog, not counting ones I’ve been on holiday for. It’s been a hell of a journey, so I thought I’d put together a little collage of the highlights.



Hey Hurtworldians, over the last week I’ve been tracking down a bug where the first item icon rendered wouldn’t receive any custom colors and also looking into allowing creatures to damage vehicles and vise versa.

The way our item icons work is that we render them on demand at runtime, this allows us to ensure the icon is always accurate to the item (ie. shows correct attachments, colors, etc.).
Currently the first icon created doesn’t receive custom colors, this can be tricky to notice as often the first icon won’t have any custom colors or the icon will be for the bottom right alert panel so it is only seen temporarily. It’s also difficult to notice as a single item usually has a few icons for different contexts (ie. inspection window, hotbar, backpack, alert panel) and only one of them would ever be broken.
The issue ended up occuring in our icon renderer initialization step, we have a component that passes the custom colors to the shader after receiving the OnWillRenderObject callback, the problem was this component was using its first OnWillRenderObject call to initialize itself instead meaning that first icon wouldn’t receive its colors and then that incorrect icon would be saved into the icon cache and reused whenever the icon was used in that same context again.
This was hard to track down as I was trying to debug it through the Unity editor which was redrawing frames when paused, triggering another OnWillRenderObject making everything appear normal when trying to inspect the rendering setup after the event has occurred.
Lesson learned to be careful about how Unity editor updates when trying to debug rendering issues.

As well as bug fixing I spent some time digging into our AI system to see how tricky it would be to get creatures to start attacking vehicles and allow vehicles to run over creatures.
Now that vehicles are destructible it feels stranger than in legacy to be safe inside a vehicle around creatures, we also thought we could allow vehicles to run over creatures if we damage the vehicle for every creature hit so it doesn’t become an overpowered farming method.
I got as far as having creatures target, chase and attack vehicles but quickly found out taking it to the next stage of having creatures choose between vehicle/player targets, making sure they only target occupied vehicles and tracking the player as they enter and exit vehicles would require some significant refactoring.
Another concern we had is the time desync between AI and vehicles on the client, basically our AI is deterministic and is predicted on the client, this means the AI positions you see on your client match the server positions at the same time. Vehicles on the other hand are simulated server side only and aren’t being predicted on the client, this means the vehicle positions you see are from an older server time. The desync between the two times means these systems could look strange interacting together and would potentially need some extra work to hide these inconsistencies.
Because of these issues I’ll be moving onto other things for the immediate future but hope to revisit it somewhat soon as we’ll need to work out some solutions to the vehicle time desync problem to allow shooting out of vehicles.

This coming week I’ll be setting up a basic Mozzy skeleton prefab, working on separating vehicles into grounded and air vehicles giving us a basic prototype to start playing around with the controls and flying physics.


Hello, this week we’ve been testing the little town event battle zone I made, although it wasn’t designed for a typical deathmatch style game mode, deathmatch is a great way to test the actual playability of the area and make sure all the different areas of cover work well and the map flows nicely. All in all I think it went well, there were a couple things that I needed to fix up but they were very minor. Now that the map has proven itself in deathmatch we need to come up with a good gamemode/objective for it that ties into the natural feel of the world, this is a lot harder than it seems with all the different variables in Hurtworld like group size, player gear, stuff like that. Now that I’ve got the little battle zone done as a sort of proof of concept I’ve moved back to polishing the main map, so far I’ve put my time into the forest biome and cleaned up the overall scattering of grass and a some patches of trees a long with adding in some new rocks that will be scattered throughout to give good cover and some interest, on top of this I still have to add in the terrain chunks I’ve been working on but this is more of a hand polish thing as trying to place them via MapMagic seems like a nightmare. Part of the polish process is adding in lots of towns and interesting areas specifically for the events, however if we want to make sure the the events are genuinely fun and balanced we need to design and test the areas properly, which is a time consuming process, so I think we might have to have smaller, less important zones that don’t need so much planning and then some larger more thought out areas.


Hurtworld Update #116


Hey yall, this week I’ve been exploring ways to utilize some of the cool shit we’ve been building over the last year now that we’re back to expensive permanent items again. The theme of the week is making your items unique. This includes aesthetic and stat upgrades to get to a point where each core item in your gear set is different from most others in the game.

I started the week with putting the finishing touches on the runtime Item modifier framework that is a major part of ItemV2, this allows us to do things like change any of the components or data stored on an item at runtime based on some event (like say a modifier gem applying +5% attack speed to a pickaxe), and have it serialized properly to the people who need to know and write into the savegame correctly and efficiently.

I will be phasing these in slowly as not to break the balance we’ve gotten back to being close to legacy. The first one will be an incremental attack speed increase buff that can be stacked on melee weapons / tools. This will be a rare drop from creatures at this point. I still need to figure out the logistics of capping this somehow, I guess for one build I’ll allow stupidly fast attack speed melee weapons after many upgrades.

Item Naming
The second use case I will be introducing is the ability to name your items after you craft them. This will be done via a scroll item that can be found in the world, that can be applied to a single item once. Once an item is named, it cannot be changed again. Meaning that pimped out bow you spend a long time perfecting that was stolen during a base raid, will retain its name for the new owner, and if you get it back you will know its yours. You can also link the item in chat and taunt your victims. This is all working and will be in the next patch.

Town Events
I’ve also been working on the new town world event system this week. This system will randomly choose a town in the map (there will be heaps more than diemensland, some big some small), and initiate a pre planned event in that location that will incoorperate the design of the town or landmark. These events will mostly be competitive PVP / PVE scenarios that require you to hold an area, or clear a bunch of mobs to reach some win condition. On completion the event will drop some valuable loot to the winner. Events will be marked on the map ahead of time, which should give players enough time to travel to the location and compete for the spoils. This is the next step in our efforts to get people out in the world and away from the security blanket of their base. If you are far from home, you are risking more, its more of a natural encounter in the world than naked guy with spear runs around fortress over and over with no real reason to enter into battle with people who are there, therefore doesn’t care about protecting themselves unless they found something good which happens rarely. This is also to stop the core game loop of checking empty containers for loot over and over again, this is mega boring. The event system will basically guarantee that if you succeed you will get something of value and draws people together from far parts of the map causing conflict for a good reason. The events will be designed to create interesting combat scenarios that require skill and prep to take down. Splat has been designing the first prototype see below.

I will likely tune the frequency that there is always an event going somewhere on the map. If you want to run events and get into fights, you can do this continuously. This peppered with airdrops, meteor showers and dynamic hostile weather I think will bring the map to life in a way we haven’t seen before. I’m really happy with how meteor showers and air drops are feeling in the current build. It obviously needs some tuning, but I’m really excited about where we are heading 🙂

Next Experimental Wipe
The next experimental wipe will be on Thursday the 22nd of Feb with a fair bit of cool stuff.

Mils Lord of the Dark, Keeper of Weasels

So we played a lot of Hurtworld on the weekend on the public servers, I had so much fun. It’s great that the world is fun to explore again. The balance of things is feeling pretty damn good right now and I haven’t felt bored at any point. I think this is mainly because of the Meteor Drops and Air Drops.

I have been deeply entrenched in the UV mapping for the Mozzy Helicopter. UV mapping complex vehicles takes a bit of time, but some of thew new UV mapping toolkit tools in Maya are really helping speed these tasks up. It seems that Maya has very similar uv tools to a plugin for Maya called ‘Nightshade’ as of the 2018 version. These tools are really getting a lot better. I got the high poly modeled last week, and found a new way to do that stuff a lot faster. JOY! I’ve finished the UV mapping and about to start on the Normal Baking. Wish me luck for it is a dark art. 😛

Below is a sneak peak of the object grouping technique I use to logically group sections of the mesh so that you don’t get baking artifacts. Basically I group these based on whether they are touching or if their bake cages would start to intersect (not touching but still too close together) The grey areas are bits that I don’t need normal baking on. The body kit will be UV mapped and placed onto the 4096 px texture after the chassis is done.



This week was spent learning Cow_Trix’s map tools, there’s a fair bit to learn so I’ve basically had to document my process as I go. Earlier In the week I when I was still going over some Map Magic stuff I made a more detailed forest biome just to push a bit further than our normal biomes. It was a fun test and although it was pretty unusable for the actual game it gave some good insight into the use of much taller trees and detail meshes for grass instead of billboards. I also did some concepts for a re-do of the higher tier resource nodes. At the moment they seem a bit sad in comparison to the earlier resource nodes.

Forest_tester_4devblog ResourceNodeColourtest4devblog

Last night I went a bit crazy after drawing a map idea for these new town events. I play a lot of FPS games and knew I couldn’t just jam a bunch of stuff together and hope for the best, especially with these town events being a battle for what I imagine will be some pretty good loot. The event zone had to be a fair battleground that gives all players a chance to win if they use good strategy. The insane web of red lines are all the different lines of sight from different vantage points. The challenge is making sure that no one spot is over powered, this means that if you have a good view from one point then you will most likely be vulnerable to your blind side and if you are completely safe in a little camping spot then you shouldn’t have a long or valuable line of sight. I made sure to grey box the level before hand to get figure out all this sort of stuff before building it out of assets. In the future the levels will be tested in a proper death match environment in their grey box state before building them out of assets but as I was already pretty deep into this one I wanted it to look good for testing (great decisions generally aren’t made at 2am).



Hiya folks! This week I’ve just been continuing to polish up Mangatang, and fixing some bugs with the current patch. I’ve been trying to speed things up a bit in terms of the terrain workflow. One of the big issues has been the file size of the terrain layers, so I’ve been putting in some data compression. That’s worked really well and reduced the filesize of these layers substantially. I also wanted to take a look at the road parallax issues (i.e. the road appearing to float above the terrain). This is a bit of a tricky one, and I am still working through possible solutions. The most promising one so far has been a two-pronged approach. First, we drop the vertexes based on distance to the camera, which reduced close parallax while keeping the road from clipping through the terrain at a distance, when the terrain begins to lose resolution. Secondly, I fixed the render queue for the shader so that it write to the depth buffer immediately after the terrain, which means other geometry will correctly depth test against it. Check out the results below:


I also fixed a few bugs here and there. It turned out that an exploding raid drill could actually take out a door, due to the way we’d set up the door armor. This wasn’t intended, and was actually a general problem with how we were applying damage to structural machines like doors, pillboxes, that kind of thing. The solution was just splitting explosion damage into two different effects, structural and everything else. I also fixed things like creatures running into shacks and wrecking you, wrote a map based spawner for controlling meteor shower spawns, fixed the options menu resetting all of your options every time you opened it, and tweaked a number of spawns in Mangatang.

So finally, bit of an announcement from me. After almost 4 years working on Hurtworld, I’m going to be heading off as of next week for my next adventure. It’s been an amazing experience bringing this awesome game to you all. If you want to keep in touch, and see what I’m doing, you can follow me at @cow_trix.


Hey Hurtworldians, this last week I’ve been back in bug fixing mode. In the release we had the mesh attachment building step of our mod build process fail for our base content bundle, without us catching it. This led to a couple of machines having to fallback to the generic crate icon, luckily it wasn’t the art bundle otherwise items, players and vehicles wouldn’t have been visible (although this one would have been easy to notice)!
The mod build step has been our bottleneck for content creation and iteration speeds so I’d been doing everything I could to speed this process up. As part of this I took a lot of the asset modification out of the Unity editor and changed it so we edited the text serialization directly, this allowed us to dodge most of the overhead of Unity’s asset database and having to load a lot of assets we didn’t really need to load. Unfortunately this could create some strange race conditions that I was never able to fully eliminate and after much frustration I decided to move the process back inside the editor because consistency is more important than the small speed improvements. Lesson learned: don’t work around Unity unless you really NEED to.

Other than the build process issue I also fixed a problem we had with shader variants not being included in builds. Our uber shader has a few shader features that can be toggled like backface drawing and saturating the custom colors rather than linearly blending them in. Usually Unity knows to include these shader variants in the build because assets that use the variants are also included in the build. Since we have moved over to building all our content out of the SDK this no longer applies to us so instead we force include a few simple materials referencing these variants. This problem was tricky to track down because it didn’t occur in the Unity editor as shaders are compiled on the fly when they are requested (which doesn’t happen in the final build).

I also removed the terrain layer from the construction line of sight checks to make it easier to build walls and other structures partially intersecting terrain and rocks (all the other construction validation still applies).
I also did a pass of our item list removing all our older items that had been broken in updates from our content bundle, this makes the ‘g all’ command safe once again for admins and will hopefully lead to less problems due to plugins accidently creating the wrong items.

Hurtworld Update #115


This week we’ve all been in polish mode, now that we have something a little more solid to work from, we are going through all the outstanding issues that make ItemV2 less stable than legacy. No mega exciting features from me this week as I’ve been on bug fix duty.

I played a bunch of ItemV2 over the weekend and had a heap of fun, it has definitely re-sparked my inspiration for what is to come in future. The first task for us is to get all our new systems bug free, and our core balance to a point we can build upon.

ItemV2 Wipe and patch this Thursday
Due to the dupe bugs in this weeks experimental build, we will be doing an ItemV2 wipe and patch to address a ton of issues we have found over the last week. Progression will be fairly similar but should be a lot more stable.


Man playing the new V2 patch on Tthursday & Friday was awesome fun. I am loving where V2 is going now. Still a lot of things to add/fix up but the game is really fun again.

So the Mozzy low poly is now ready with it’s first body kit. Pending Spencer’s approval of the scale of the chopper I will got ahead and start making the high poly. Pretty happy that the initial poly count has come in at around 17,500 tri’s. This is fine considering the size of this vehicle. It will also let the poly count creep up a bit if some of the later body kits have a couple thousand more poly’s. It’s going to look pretty good with all the additional detail that will come with the normal maps. I want this to look scavenged, with weld lines and patches of discoloured rusty metal in spots. This has taken a bit longer than expected but is on track to be finished pretty soon. Spencer said he wants this thing to take a lot of skill to fly and land, so should be a good challenge, especially considering how much access to bases it will provide.



This week was a pretty fun week. I started learning the map magic tools in depth, learning Substance Designer has really helped me feel completely comfortable with node based work flows. I started working on a new version of the start biome as a way to learn Map Magic and because I believe it needs a re-work. First thing I wanted to get done was small consistent rolling dunes in the sand so that you can’t just see for miles over a flat terrain I did this using a mildy tweaked Voronoi node, this creates endless rolling hills of varying size and height. Next up was creating a my own version of the current formula we have for large occlusion, at the moment we use more of a typical hill with rocks scattered around it in a sort of circular form. My version is essentially the same but a bit more random with some character. I acheived this by using another Voronoi node only this time it was a lot more intense with larger and taller hills. I then excessively tweaked a Unity noise node and created a mask to represent the islands. Once I felt it had the right frequency and shapes, I plugged it into the more intense Voronoi node as a mask, thus leaving out certain areas to only be influenced by the less intense base Voronoi. As you can see it leaves a natural path way around all the hills. I then plugged in a bunch of test assets and the newer environment assets I’ve been working on. It was a great little show case for the new terrain chunks and rocks. The overall colour pallet hasn’t been correctly picked yet so lots of stuff is off and some of the assets are just rough ones I had lying around.

Map Magic Noise



Heya folks! Not a huge amount to show off this week – although you can now jump in game and explore the new map! This week was mostly polishing the map in preparation for the patch release last Friday. Even with that polish work there were a few areas that I’m not happy with, and that’s part of what I’ll be working on this week. Overall I thought the general layout of the map worked well, and having an in-game minimap has really solved the biggest problem we had with the original Diemensland structure – in that it was good for the micro gameplay, but began to fall apart at the macro level when navigability became an issue. I spent a long time making Diemensland, and I even I couldn’t find my way around the thing.
There’s a few places with floating rocks and road/terrain interaction not working well, so I’ve been going through those spots where I can find them and fixing them up, as well as tweaking a few road settings so they happen less often. The biggest culprits are always when the road dips or banks. Hopefully I will be able to have an improved version of the map for the next build that will fix a few of these glitchy points.
I’ve also been looking into some glitchiness around map markers, and UI focus where things like chat, ownership stake names and signs weren’t managing cursor lock properly.


Hello Hurtworldians! This last week I’ve been continuing to help setup content for the recently released patch mostly focusing on creature balance. This involved going through the creature stats and rolling them back to legacy levels and correctly setting up spawn builders to spawn variants of the same type (like bors become rad bors when spawned near towns or sasquatches become yetis when spawned in snow).
I also got some quality of life improvements done with removing the random aim offset that was applied when using a scope to aim and reducing the base level scope sway. Also in quality of life improvements I removed the UI swipe circle from appearing when hitting anything but a resource node.

We’ve been pretty happy how this patch has turned out, it isn’t perfect with a few balance issues around the changes from legacy (airdrops, meteors, vehicles and item protection) and some nasty bugs but we will be sticking with this setup and working to fix the bugs and issues rather than trying to overhaul the base game radically again.


Dev Blog