Press Kit Wiki

Hurtworld Update #44


Finally making it through the woods of engine upgrades and starting to see some new features creeping into the game. I’ve put the final touches on the new camera system which was one of the last truly ugly systems in the engine.

Now the view can be clamped inside the vehicles and is calculated serverside also, we can do firing from vehicle seats! In reality the driver won’t be able to shoot, but this was easier to record. We still need to implement animations pivoting from the hip while pinned to a seat, but that’s the easy part.

Next we have a new headlook feature, similar to the arma engine allowing you to look around on a limited swivel while running / aiming in specific direction. Useful when crossing a valley in sprint and checking your surroundings. (FPS animator needs some touchups so it doesn’t look weird in side angles, not a big issue though.

Lastly we have the completely unrestricted Roach back seat that allows crouching / standing and 360 degree freedom.
This video also shows the improved third person aiming system, notice the arrow is now accurate regardless of perspective.

Once again, I should be able to get to recoil this week. Those wondering what the ItemV2 ETA is, we are still a couple months off.

Things that need to be implemented before we can go live:
New tooltip system that supports itemv2 state
AI for new creatures
Upgrade loot table system to generate weapon attachments / procedural stats
Cow_trix finish new map

No more fucking around

Now I am through most of the serious upgrades I need to do, I am switching gears into delivery mode. I wanted to take the time necessary to make sure we deliver some really game changing stuff with the upcoming update, however I am starting to see some patterns emerge that I see in other games that never get finished. I always thought that the reason games that have some initial success slow down after the early access launch was due to a lack of motivation / cashgrabery.

I see now how easy it is to get caught up in trying to make everything perfect once the pressure of going bankrupt in the next week is taken off the table. We are still working harder than ever, but we really need to start focusing on pushing this release cycle out the door and stop trying to cram every feature we ever wanted into the game. There is plenty of time for more features, in future releases, I see now we still need to make compromises in the short term if we want to finish anything.

That said, ItemV2 has become more like Hurtworld V2 as almost all elements of the game have been improved… a lot. We can’t wait to get your hands on it, hopefully I can make that not too far away!


This bike is starting to shape up nicely. All the high poly versions of the wheels, fairings and chassis are done now, the next step is to add some damage to these by carving into them. If you look at the image I have added, you can see some damage has been added already. These are the types of damage that affect the silhouette of the model, and so are also present in the low poly mesh. The next step is to UV map the low poly and then bake out the normals maps so that texturing can begin. Vehicles have high polycounts so this takes a bit of time, especially when baking normal maps, as you can never be 100% sure that they will come out right the first time you bake them. This is especially true when it comes to more complex shapes. Any part of geo with an angle over 90 degrees will generally cause a normal baking disaster. Adding in a little more geo in these areas by simply adding a bevel on the offending edge of the low poly mesh will usually fix this, but you must be careful not to start beveling edges everywhere and blow out your poly budget.

HighPolyDone HighPolyDoneWheels


This past week I was focusing on nailing the workflow of getting mesh’s skinned in maya, exported, and viewable in Toms new Vis Scene. This involved a little bit of back and forth with Tom, especially in regards to having the player character display as close as it can to what it does in game ( which it now does ). I went through and modified some of the previously made clothes to better fit the new body shape, and they seemed to come across pretty well. We noticed that just lowering the head a little and applying a normal map makes him look a bit more jacked, which we don’t mind.



I also have been updating the fps arm model to bring it line with the other character changes. This involved getting rid of some of the acute sharpness that was in the original model, especially around the forearm/elbow, as well as decreasing the fingernail size and blocky-ness of the hands.




I started the week out working with Gavku bringing the new character model into the itemv2 branch. We found a few bugs that we were able to squash and I added a whole bunch of useability improvements into the model viewer. The viewer now uses the same lighting model as in game and uses the same dynamic skybox so you can adjust time of day and other variables to view the player under all different conditions.
I’ve also added a simple equipment ui that allows you to swap between any gear in your project easily along with selectors to preview any skinned or static mesh in the project without having to create an item and setup the visualization component.

Also this week we spent some time testing out the motorbike build which didn’t go as well as I’d hoped. We found a lot of bugs with how proxy players were trying to sync animation data and also some ease of use concerns where basically the motorbikes were way too easy to crash. To have a place within the metagame of hurtworld they needed to be more reliable otherwise they would just be outclassed by the other vehicles. To this end I’ve adjusted the leaning system so it has special case handling for off-camber corners (corners which are banked opposite to the turning direction), clamped the target lean value and removed crashes being triggered from leaning too far. The handling has also gotten a lot tighter with an increase in the steering assist twisting force plus higher sideways traction for both tires but especially the rear. I’ve also made the bike dampen its yaw velocity when only 1 wheel is grounded to prevent the high traction tires from spinning you out.
I adjusted the collision crash component so it should only be triggered in large head on collisions (like driving flat out into a wall) and also added in an air stabilization system where whenever the bike is airborne it will correct itself into a safe neutral orientation. Because roll in the air was now being controlled by the stabilizer we changed the left/right inputs from roll to yaw (meaning you can now do 360s instead of barrel rolls).
I’ve got a new list of fixes to work on for this week but we’re definitely getting close!


Hey folks. This week I’ve been further iterating on the map work, making a lot of progrees in making a procedural map that retains the Hurtworld feel. A big part of it as well has been figuring out how to conceptualize the map generation in a procedural way, finding the methodology that works.
An interesting problem I had to solve was the generation of the initial hills. Something we settled on when making Diemensland was that for the map to have good occlusion, generally the hills had to be roughly the same height. I initially tried to generate these shapes with a Voronoi noise map, which worked okay, but had the problem where it was difficult to make the hills all the same size without distorting the shape. What I then tried, which worked way better, was a “stamping” technique where I took a single hill of the shape that I wanted, and then stamped it all over the map in the same kind of pattern of valleys separated by ridges. This way we could guarantee much more that the slope and heights of these hills would be consistent.
What I’m going to focus on next is generating the macro layout of the map. I’ve got my head around generating the micro, but I’d like to be able to feed in something like the diagram I showed 2 weeks ago of the general layout of the map, and get something out that resembles that layout. That’s going to be an interesting challenge, the biggest problem being I think having this information laid out in a way that works logically and is maintainable. The whole mask workflow that we used previously for Diemensland has some maintainability issues where a change to one mask causes a cascade of changes to every mask it touches. I’m thinking of basing it directly of biomes, and seeing if that can work.
I’ve also been experimenting with placing hotspots and structures in the map, which we could make as little areas to explore and loot. I’ll be looking into a similar system to put in natural artifacts – for instance, things like the stone arch in Diemensland – but I can see that being a bit more involved.


Hurtworld Update #43


This week I have been finishing off ( hopefully ) tweaks to the main player and getting rid of any errors that have popped up. One of the main ones was obvious seams where the character had been split apart. Previously I had hand edited the normals anywhere the player mesh was split which would often get rid of anything visible, but was very time consuming and left us with a mesh that was fragile, with them sometimes resetting when moving between max and maya.

Now that the character has a normal map I had originally thought that that alone would take care of it, however this was not the case and still left seams of varying visibility depending on workflow/how it was baked.
In the end what ended up working was to make sure each separate piece was individually uv’d, then I would recombine all the pieces into a single mesh but not weld the verts along each join. I would then bake out the normal map using this as a target mesh with a generous amount of padding and convert the map to tangent space with Handplane. This seems to work fine.
I also went and finished the textures for the new hair/beard combos.


This week I’ve been having heaps of fun doing stuff like this:




The motorbike and the vehicle refactor are coming together well, I think I’ve found a good balance between realism and fun given the relatively limited control scheme (it’s hard to handle turning and leaning well without an analogue input like a thumbstick). I’ve put a early build together that we’re going to be testing internally and we’ve been talking about pushing out the vehicle changes before the itemv2 update so watch this space!

I’ve also been doing some more work in itemv2 working on the backend of our baking system pooling groups of datatypes used by meshes. This allows us to preallocate the memory the baking system is going to use rather than request it at runtime. When working with high level programming languages like C#, systems like this are essential for good performance as the garbage collector (named because it turns no longer used objects back into free memory) isn’t fast enough to work smoothly in real time and frequently leads to framerate spikes. If we preallocate all (or at least most) of the memory we need on start up and don’t release it we can massively reduce garbage collector use.
I’ve also developed a system for turning static meshes into basic skinned meshes by binding them 100% to one bone.
This should help modders out creating items like hats and masks easily, I used this horse mask from the asset store, bound to the head bone to test it out.



Hiya everyone. This week I optimised a lot of the city assets, and played with a new map-making tool.

One of the big challenges with the city, as we’ve mentioned before, is getting it to perform well. It’s a complex problem with some distinctions from optimising an open terrain like Diemensland. We get a lot more out of aggressively culling objects, and it’s much less noticeable due to the amount if culling we get from the buildings. We started of as you can see at around 30fps in most scenarios, and up to 3 million polys.

The first thing I did was write a tool to find the objects hogging up the render time – where were we spending these polys? Well, it turned out we were spending a lot on very small amounts of texels at a distance – that is, lots of polygons were making up very few pixels. I put on my 3D modelling hat and made some quick and dirty LODs for the worst offenders. Thanks to Mils’ modular design of the city, this meant I only had to make a few before we got some real dividends.


You can see a before/after performance comparison below.


I’ve also been playing around with Map Magic, a recently released procedural terrain composition tool. Hopefully we should be able to streamline our map making process using middleware tools like this in the future. As worthwhile as Shigi Tools was, and probably will be for some niche procedural generation, the more tools we can outsource, the faster we can make content. I’m working on reproducing some of the basic microstructure that we ended up with in Diemensland. Think the hills, rock placement, tree placement. These were all iterated over a lot to try and get a good feeling of scale and place. Reproducing this in an entirely procedural way will really allow us to lock in the micro and start playing around more easily with the macro. This has meant I’ve gotten to right some cool procedural heightmap generators – check out this custom warp generator I whipped up!


Hurtworld Update #42

This week and next, Spencer and Mils are away.


This week I’ve been helping out with itemV2, hooking up the skinned mesh baking work I’ve been doing. We’ve also been making a lot of changes to player rendering to support customization. The plan is to have players be able to pick a skin colour and a hair colour as well as hair and beard styles. We want to implement this as part of your characters default setup rather than through gear like how we currently handle it. When creating gear in the sdk you’ll add a skinned mesh attachment item component to the item which will allow you to select a mesh or group of meshes to be baked into the character model when the item is equipped. The component also allows you to mask out sections of the default player to remove them from the bake, this is handy if we want to do something like turn off the hair model when wearing a hat.

We’ve also been working on decoupling player rendering from player simulation and control and this has allowed me to write a player model viewer to help speed up our workflow. The model viewer gives an easy way to test visual item components, player default setups as well as skinned and static mesh attachments under the whole range of player animation without having to load up the entire game. This should help speed up item creation for modders as well once itemV2 makes its way into our SDK.

The motorbike is also coming along well, both Mils and Dazzler have been hard at work on content and now we have low poly models and rider animations complete. I’ve started bringing these into Unity and have split up the range of rider animations into the following blend tree.

This tree allows us to drive the animations through 5 variables:
Speed (blends between the stopped pose regular motion)
GroundedWeight (used to blend between air poses and grounded poses)
InputY (taken from up/down input, used to blend between forward and back poses in the air)
InputX (taken from left/right input, used to blend between left and right in both drifting and normal turning)
DriftWeight (represents drift amount, 0 being no drift and 1 being full drift. Used to blend between turning and drifting)

To give an idea of what the nodes represent, here’s what the ‘Air Fwd/Back’ node looks like running through its range in all its barhumping glory.

With all this in place I can start fine tuning the handling, making sure it all blends together nicely. I’ve only just started this process and need to smooth out the transitions but I think its coming together pretty well already



Hey folks! This week I’ve been planning out the new map that will be coming with ItemV2. The new map is going to be a big task. It will incorporate the amazing work that Mils has done creating an enormous library of city assets, as well as reflect some of the big gameplay and balance changes that are coming. We’ve been doing a lot of planning and talking through map ideas as abstracts, and now I’ve started actually building something to see if it works. While we loved Diemensland, we felt that it missed the mark on a couple of things. We didn’t really get a strong progression through biomes, there weren’t enough of them, and the main mechanism was temperature, which is something we want to move away from. Using temperature as the main “gating” mechanism throws in a whole lot of complications, as we also use temperature in a bunch of other stuff. It strongly limits how we are able to scale biome difficulty – for instance we can’t make a biome 100 times harder without increasing the temperature by 100, and this complicates stuff like putting in dynamic behaviors for entities at high temperatures. So, everything will just catch fire. This means we’ll probably move away from temperature as a gating mechanic for biomes.


Another change we’re entertaining is much more binary transitions between biomes, pretty much a line you step over. We think this will make balancing the biomes a bit easier, as we don’t really have to worry about the transition zones. As well as that, we felt the transition zones were generally ugly and limited how different we could make the biomes feel as we always had to consider the transition. We’ve also been thinking about player flow and forces a lot, and what we want the flow of players to be around the map. We’ve been considering a design with quite a different layout to  where players begin in a middle hotspot, the city, and must get out as quickly as possible, grabbing some supplies to survive the day, and move out to one of several separate zones. These separate zones would have distinct, increasing difficulties and rewards as you progressed out, pushing players outwards. Also, as players reached the end of that progression (not necessarily establishing a base there, but having sufficient gear to travel there), they would then be able to return to the city to do high-tier farming runs. They would also be able to travel to different zones, to raid and pillage or to claim some other territory. As always, we’ll see how this layout works with a rough version first, before going forwards with a fully polished map, but it should be pretty cool and different!


Since last week I have mainly been working on tweaking the player character both in regards to proportion as well as making sure the in game mesh can separate in the correct way to line up with the new build system.

His mesh will now be split into : Finger Ends, Hand, Lower Arm, Upper Arm, Torso, Crotch, Upper Leg, Lower Leg, Feet, Neck, Head, Hair, Beard, and Eyes.
We noticed that the players neck appeared thin and and slightly elongated, which became more obvious when there was no beard or hair pieces loaded onto the player. Whilst fixing this I took the opportunity to fix other areas especially around the torso and pelvis. I also separated the default shorts off into their own map.
*Textures still need tweaking and proper spec maps applied.
Dev Blog