Press Kit Wiki

Hurtworld Update #108


Heya folks! This week I’ve finished up on improving the internal spawning architecture and the spawn window, and fixed some stuff relating to user interface focus control (edge of your seat stuff!). As with all polish work, there’s not really a tonne of awesome stuff to show, apart from things just being a nicer and better structured. Your death marker is now tied to your death loot, so you’ll be able to see if another player snatches it up as the marker will disappear. The journey to reclaim your lost loot is already pretty risky, so this should give you a bit more of a home advantage. I also re-implemented a few spawn features that had fallen to the wayside, such as spawn fatigue. As in legacy, respawning at a stake will add a small debuff to your respawn time. This is intended to make pushing into an actively defended base easier, as killing a defending player repeatedly will increase their spawn fatigue and give the attackers more time to push. This slightly mitigates the defender advantage, as well as the offense if they have built a raiding respawn point outside the base. Behaviour around disconnecting and reconnecting while dead should be a lot more consistent.

I also took a look at improving the explosion simulation, after reading this paper the other day. Did you know that it’s actually trivial to calculate the exact volume of an arbitrary mesh? Chalk that one up to “things that excite programmers and nobody else”. But it does mean that we can figure out some exact values where previously we were just eyeballing stuff. In terms of how this works exactly, when an explosion raycast hits a piece of a building, it’s damage is scaled based on the volume of that mesh. Previously, we just eyeballed that value, but with a few quick changes we can now have a much more accurate method of dispersing damage across a structure. This will change raiding a bit, but make things a lot more consistent. I also fixed an annoying bug where you couldn’t place a single door and wall at right angles to each other in an independent order, which I’m sure everyone who’s tried to place the single door has encountered.

Mils Tekmoth Von Guava

Yo! I completed another set of limbs for the Recurve Bow this week. This set sports fibreglass (glass wool) limbs with galvanized tin reinforcements and a rubber recoil enhancer. This set has a more mechanical feel and looks a bit more mad max-ish. I’ll do the ‘Rest’ which the arrow sits on tomorrow and then onto the Riser for the 3rd set. We made a change to the plan of making an arrow per set. We will for now only be using the one arrow that I previously completed. This was a game play based decision.



This week I’ve been working on vehicles mostly, first up was fixing a range of bugs dealing with the new map system. Now when in a vehicle the map’s player marker will point in the direction of the vehicle and the compass will be pointing in the correct direction in both first and third person perspectives.
I also added a vision cone to the player marker which will display whenever the player isn’t looking directly forward (ie. inside a vehicle or ‘free looking’).
Whilst making these changes I also fixed a regression from legacy so changing perspective inside a vehicle will preserve the camera direction.


Next up was extending our material system to work with vehicles. Our material system is a way of assigning physical material types (eg. dirt, wood, stone, metal etc.) to objects, these materials are then used to lookup things like impact sounds and particle effects.
Our main motivation for bringing vehicles into this system was to change their traction based on the material type being driven on. For now we are just adjusting acceleration traction which basically changes the vehicles speed over a material, the different vehicle types have separate material/traction lookups allowing us to differentiate them better and give each type a role. We are also using this system to significantly speed up slugs on roads, this should give players some interesting decisions planning their getaway route trying to balance speed with predictability.

I also spent some time looking into how vehicle traction is applied in an effort to improve the low speed handling of the Kanga. During this I found a few bugs, mostly with how static and dynamic friction were calculated and also how they were blended between. With this cleaned up and the wheel settings readjusted the behaviour feels similar to before except the Kanga doesn’t drift around at low speed and is a lot more controllable.
Eventually I’d like to look at modifying sideways/turning traction based on material type but currently we set traction modifiers and stats on a per vehicle basis rather than per wheel so rewriting and rebalancing all of that is more time than I want to spend right now on it. I have setup a lot of the data necessary for that kind of change though (ie. individual wheels know what material they are contacting) so we’ll be ready when the time comes.


Hello, this week I continued experimenting with the loot cache model and ended up with a pretty worn out rugged looking crate that was pretty noisy and wasn’t really much lower poly than the one it was meant to be replacing. I ended up going back and cutting down the original loot box and making some LoDs for it. Here’s a picture of the loot crate that won’t be used.


I also started to look at efficient ways to transfer the current clothes to female proportions, I built a little rigging system that can take the old clothes and automatically deform them to fit any new proportions thrown at it (I don’t have any photos as of yet). So once that system was made, it was safe to jump into concepting for the female model. The hardest part about the female model is keeping the joint placement exactly the same, male proportions are pretty different to female proportions so I did as much as I could to make the character feminine without moving the joints, this involved cutting down a lot of muscle forms and smoothing out some noise. Here’s the current state of the character.




This week I’ve been working on a new feature that I wanted to get in before we put out our meteor showers update: Heavy Slots

Heavy Slots
With the introduction of the Slug truck, there really needs to be a reason to ever drive one around. Having it as just a mega slow vehicle with lots of storage would never really fit into the current meta game. For a while I’ve planned to create a new mechanic to make heavier vehicles useful.

Heavy slots are similar to restricted gear slots in that only heavy slot items can be placed in them, the big difference is that heavy slot items MUST be placed in a heavy slot and can not be carried in any regular slots.

Players only have 1 Heavy slot which is located in their hotbar, and the heavy slot item will take over the equip slot in the hotbar while it is being carried. This means while carrying a heavy slot item, you can’t use and hotbar equipment like guns. You will also run much slower and be unable to sprint.

This aims to create some more interesting challenges moving valuable things around the world. We can start to create higher risk higher reward situations like needing a truck to carry meteorite fragments back to your base for refining, or needing a truck to extract valuable machines from a successful raid.

The truck being naturally slower than other vehicles, we hope to foster traps, high jacking attempts and escorts on Goats and Kangas.

Here is the system in action (with placeholder art)

Hurtworld Update #107


Hey folks! This week I’ve been continuing on various bugfixes, and mostly polishing up a bit about how we handle death and connecting to the server. We weren’t handling some scenarios particularly well around this, so I’ve been streamlining those structures. While the current architecture does work with no super obvious downsides, it does lead to some confusing scenarios. For instance, if you disconnect from a server while dead, or someone kills your sleeper, you’ll actually respawn and die instantly. This feels like it’s the spawn that has killed you, when in reality it was something else. It also meant that there were some cases where you’d be spat out into a random spawn when you had a stake it was possible to spawn at. We don’t really communicate this particularly well, especially as we don’t store the reasons you died across server restarts. These are all very delicate structures, as bugs introduced can damage player progress, so I’ve been going slow, changing as little as possible, and doing a lot of testing.

There were a few places where you couldn’t interact with the player spawning system unless you had already spawned in the world, which hasn’t happened yet for players who are just connecting. This was because we were using the player entity as a keying object in a number of lookups. I changed the system to use the connected network session to key any data, which worked well. It also removed some coupling between the game mode object (which is an object that configures what game mode the game is currently using and the configuration of that mode) and the spawn window, which is always nice. As an added quick job, I moved the player customisation interface into it’s own little widget, as before it all just lived in the spawn window code. I also extended the game mode structure to allow game modes to write state into a savegame. In the case of the Survival game mode, we can write in stuff like how a player died when they were offline, so we can tell them when they log back in. We could also store things like leaderboards, teams, or other forms of game mode state with this in future.

So with these fixes you should have a much clearer experience when joining a server, as to what killed you when you were offline, as well as always giving you the choice where to spawn when there are multiple.

Mils Lord 5000

So I’ve finished the texturing on the second Riser for the Recurve Bow. This one is a re-purposed metal bar. So that the bow parts have a lot of variation, this one will be made from man made materials. There’s a steel bar, with a layer of yellow foam, wrapped in black rubber as the grip. This one contrasts nicely with the previous mostly wood version. I added a little rust near the welds to sell that it has seen some action. This came out just as I wanted it to.


I have also got the high poly done on the limbs for this set. These were going to be metal also, but the more I thought about it the less this made sense. I didn’t want the whole thing to be metal when combined with the new Riser. I have made the main flexy bit fibreglass (or as peeps from the elsewhere call it ‘glass wool’), and then galvanized sheet metal reinforcements where the limbs deviate. This should look pretty special when it’s done. 😀 😀



Hello, not much to show this week due to a short week and I’ve mainly been cleaning all the mess I made doing the particle stuff and getting the last little random jobs done. I did make a start on a new loot cache though, the original one had to be redone due to it being over the general poly budget but the one I did to replace it was just a place holder and looks very simple and average. So I’ve gone about it in a bit of an interesting way and instead of make a box then sculpting some wood grain and scratches into it, I’ve done the reverse and made all the different bits of a wooden crate separately and sculpted both sides of each bit of wood so that I can flip and position things in specific ways that don’t show any repeating details. Due to this being an item that you see a lot I’ve put a good amount of effort into the actual sculpt, once everything gets positioned and baked out it will be a very nice box with a nice solid feel.



This last week was a bit shorter than usual thanks to a public holiday so I don’t have heaps to share this week unfortunately.
I spent most of the week continuing on with bugfixes including a material sharing bug in the mesh caching system and a race condition that could occur with attachable vehicle seats for the roach.
The material bug was occurring because I had incorrectly assumed I could rely on the ordering of elements in a dictionary if GetHashCode() didn’t generate any hash collisions (where multiple objects share the same hash) between elements. Unfortunately it’s not quite that simple as elements get indexed internally as (hash/internal array size) meaning collisions can be much more frequent than I had assumed plus the removal of elements from the dictionary can change where the next entries will be placed (see for a detailed explaination).
When retrieving a mesh from the bake cache I was assuming the collection of attachments would be in the same order and I could just iterate through getting the material for each and then assign this material list. Because the order had changed between the job that was entered into the cache and the current job we would end up with the wrong materials pointing at the wrong submesh (part of the mesh that is drawn by a single material). To fix this I added some extra data into the bake job cache to preserve the order of attachments, when retrieving from the cache we now use this list to resolve material assignments properly (by comparing old list to current).

I also fixed a nasty client side race condition with attachable vehicle seats like you see for the roach front and back seats. Basically what was happening here was that on spawn the vehicle was trying to place the passenger into the seat before the seat had initialized itself and the initialization was waiting on the equipment system to equip the attachment. This would cause the system to error and then on your client this passenger would appear running like a normal character but standing inside the car.
Rather than try to manage this order of execution across the client/server boundary I chose to refactor the initialization of the attachments to not depend on them being equipped first (they’ll initialize on entity creation instead). I also changed them so when the attachments are activated/deactivated they now run a list of actions serialized into the attachment itself rather than just activating/deactivating the game object, this gives us some performance benefits as well as configuration flexibility. In this instance we can now enable/disable the seat attachment by just enabling/disabling the box collider that is used to trigger the player to tell them they can use the seat. Disabling just the collider is much faster than disabling the whole game object.



This week I’ve been iterating on the random geography hotspot playtest. We had a bit of a play on Friday and came up with a big list of refinements that I’ve been working through today to ensure we get the value we expect out of the meteors and air drops. Getting the pacing right is a tricky one, as we want these events to be contested but not so frequent that you come across them without meaning to. The key here is balance between classic evenly spread resources, static hotspots and the new random location hotspots.

Hopefully tomorrows internal playtest will be better paced and we can work towards integrating it into the overall game by Friday for the experimental branch.

Hurtworld Update #106


I carried on with the Recurve Bow parts again this week. I have a Rest (which is a slightly bent nail) and an arrow to show you. The nail was pretty easy and looks fine. The arrow ended up looking really satisfying with the flint head material contrasting with the wood and feathers. One set is now completed on this one.


I got into the Riser on the next set also. This one is a piece of square pipe that has been scavenged and hammered and bent to fit the use as a Riser. There’s a leather wrap handle that I wanted to try and find an easier and better way to create. I tried using Maya’s nCloth to simulate the strap wrapping around the bar and making the cloth surface really sticky, so that it would cling to the bar and not fall off. This was interesting to learn a bit about nCloth dynamics, but in the end I decided to drop that method as it was taking too much time. I will say that the basics of cloth simming in Maya using nCloth is really easy. I ended up using a bend deformer and rotating it to get a slight offset. This created the layered wrapped effect fairly well. The UV mapping and normal baking are done on this so I will start the texturing this afternoon.



Heya folks! This week I’ve been working through a number of bugs that you guys have raised. I refactored the chat window a bit, so you can more easily read long messages like server announcements. Previously, if the message exceeded the height of the chat window it was actually impossible to read the whole thing. While I was at it I tried to tweak the text display to make it a bit more readable on both a very dark and very light background. I also added some quick native support for one of the most common features server owners ask for, greeting messages, as well as an indicator of when a message is a server announcement.


I also looked into making claiming vehicles have a bit more functionality. Right now it’s pretty easy to quickly strip a car for parts with vehicle attachments being easily take-on and take-off. This means it’s pretty rough to leave your car anywhere, as in just a few seconds it can be completely destroyed and all the loot you were keeping in it stolen. We already had the concept of enabling and disabling inventories, so I extended that to give the owner of a vehicle the ability to lock and unlock the storage of their car so people can’t take parts on and off, or things out of the boot without you around. That being said, they still can drive the car away and they still can wrench the car and get all of it’s parts, though wrenching a claimed car is a pretty slow job. I’ve been thinking about various upgrades that would be easy to make for vehicles to make them less susceptible to these scenarios, such as kill-switches, trackers, and car alarms, which hopefully we will be able to explore in the future.

Aside from those few little projects, I’ve just been working on various bugs. I fixed some scenarios where your construction raycast went through walls, changed a lot of machines and sound-emitting objects over to the new sound system (which will mean that you won’t get random things making noise even when you’ve got the game volume down), fixed some machines continuing to play sounds after they were destroyed, and fixed a few bad areas in Mangatang. All these fixes and more will hopefully be coming to all very soon!


This week I’ve been continuing trying to create an interesting looking resource node for the meteor strikes. Melting lava ball is where I’m at right now, I created this hollow ball with holes in it, then made an inner sphere with an emissive glow that shines through the holes. I wanted to make it stand out from your basic resource nodes so I tried to add some particles, sort of like smoke leaking out of the holes. Originally the smoke looked very obviously fake against the emissive glow due to it not receiving any lighting from the glow. I used the particle system’s colour over lifetime gradient to fake the lighting of the particles, it now gives the impression that the glow from within the node is lighting up the smoke as it leaks out. I also tried  a few different smoke variations the second one below is one of the more ridiculous ones.

I also revisited the Amber world item which is honestly a pretty difficult one when using the standard shader, it’s hard to convey a semi transparent rock that catches the sun in interesting way using only an albedo, spec and gloss. So I saw something worth trying out and in my opinion its the best looking version yet, but, possibly a bit too realistic and also might not stand out on the ground among other earthy colours.



This week I’ve been finishing setting up destructible wheels for vehicles, doing some bug fixes and also improving our tools and mod build process.

As part of implementing destructible wheels I needed a way of binding hitboxes to storage slots, we already had a basic implementation of this going on with the way the players armor works but it was all hard coded bindings which wouldn’t work for vehicles as the different vehicle types have different storage configurations. So with this in mind I’ve moved the hitbox bindings into the StorageConfig asset used to setup inventories. Below is the Roach’s StorageConfig (left) paired with its EntityStatsBuilder (right) which is the other half to setting this up. In the StorageConfig you can see RoachWheelFrontLeft is bound to the Wheel FL hitbox. Over in the stat builder you can see DamageProxy WheelFL also has a HitboxMapping for Wheel FL. I’ve also setup a FluidEffectImpactMultiplier of -1 which adds the original damage value * -1, essentially cancelling all damage to the vehicle. Below the hitbox mappings you can also see the RaiseMitigatedEvent flag is checked, this causes a new event to be raised with data about how much damage was prevented by this stat. Finally either a PlayerStatManager or VehicleStatManager will handle these mitigated events by looking for storage slots with a matching hitbox binding and then pass the mitigated damage onto any item in this slot.


I also managed to get through some bugfixes including fixing an issue that would cause rifles and shotguns to become tiny when aimed down sights from third person mode, fixing seed items recolouring your hats again, fixing an issue that allowed the shotgun to fire without a shell loaded, returning ladder climb speed to legacy values and improving vehicle exit behaviour. Unfortunately due to most of the office getting sick we weren’t ready to deploy these fixes in time for last Friday’s wipe but we hope to get them out to you soon.


I also spent some time improving our VehiclePassenger tools. I was struggling with debugging some vehicle exit problems and decided we needed a clearer visualisation of what was happening as it can get very complicated with exits that are defined in the vehicle’s orientation space (so they rotate with the vehicle) but then can also have an additional cast to ground step, then with the position worked out we need to check the whole player’s volume over the exit rather than just a point and if that passes then we do a final raycast from the seat to the exit, if this passes then the player can exit the vehicle. To make this all easier to see I created a debug view that will draw all exits and their current state. I’ve also changed the vehicle exit list to a reorderable list (as exit order defines priority) and created a custom inspector for copying exits from another seat (while shifting them into the new seats orientation space).

I’ve also been working on speeding up our mod build process so we can iterate quicker, first up I added a proxy check (ie. is the object real or is it a placeholder?) that can be run based off an unique id that is generated for all assets by unity. During pre and post build steps (where things like preparing mesh attachments happens) we can use this check to skip over all the proxy assets without having to load them into memory first (because we use the id instead). I also added another early exit check for when the asset is labeled as ‘dontbuild’, these were being correctly ignored from the build but were still running pre and post build steps for no reason.



I haven’t got much done this week due to being knocked out with the flu. I am still working towards a dynamic geography hotspot build which is playable for the first time today. If by some miracle tomorrows playtest goes really well, I might try to push it out to you guys on Friday. I wouldn’t hold your breath though.

Good news is all the features I wanted to get in for dynamic hot spots are working really well. I added some sound effects to the meteor strikes that came together really well. Looking forward to getting them out in the wild!

Dev Blog