Press Kit Wiki

Hurtworld Update #38



Hey folks! Been working on some bugs this week, which should be fixed in, out soon. Also been finishing up on getting modded vehicles in, working on an example project, and expanding some feedback for the UI.

There was a pretty nasty bug where structures wouldn’t load properly for clients, when connecting to servers under heavy load. The reason for that turned out to be “I’m an idiot”. To make client structures load a bit smoother and try to put the server under less load when player connects, I split the structure initialization step up to take place over a few frames. The logic was basically to get a pooled bitstream, fill it with data, and if we had hit the frame budget of structure data syncs, wait until the next frame to send it. Yeah… that was the problem. I got the bitstream, which is only valid for that frame, and then held onto it for more than one frame! On busy servers, some other networked object would come along, clear that stream, and use it, meaning the client would receive a garbled mess and not be able to build the structure. Thankfully this should be fixed now.


I’ve also been getting vehicles moved over to the SDK, which has opened up a lot of new modding possibilities. As a result of vehicles being in, other machines are buildable in the SDK as well. At this point, not only can you make a custom vehicle, but you can also make a custom inventory-based machine with Oxide scripting. This is because we also moved across a fair bit of UI scripting so the vehicle UIs live in the SDK as well. So, custom storage crates, and simple item-based machines are now entirely possible.

Custom vehicles are pretty cool as well! I put in what I called the Cancallare, a pretty cool sports car. It cost me $5 from the Asset Store, and was a breeze to implement! That whole library of
cars is pretty cool actually, check them out. Modded vehicles are a bit simpler than the Goat and Roach, as we can’t do things like custom items that make the car look different, or custom paints. These features will come soon. Check out the Cancellare on the Steam Workshop.

I also gave UI a bit of love, as part of putting in support for custom UIs. Itemslots are now much more consistent as they mostly build themselves by script, and should also be slightly more performant. They will no show when a slot is one-way (you can only place or take the item, e.g. ambers in an ownership stake) or locked (you cannot take or place the item, e.g. attachments on a vehicle). Previously you kind of had to figure this out by trying to drag items in and out, but now there should be some more intuitive feedback there.


The cities are now near a place where we are fairly happy with them. The city currently exists in a test map and so need to be moved into the actual map that will exist in the game. I’ll be working with Cow_Trix on this process when he is finished implementing some other game items. I finished off the public pool structure for the suburban area of the city and I built some high rise apartment structures.

OuterSuburbs_0002_Layer 4 OuterSuburbs_0003_Layer 3 OuterSuburbs_0001_Layer 5OuterSuburbs_0000_Layer 6

While Cow_Trix is busy on his other tasks, I am starting to work on the Dirtbike, for now I have named it a ‘Kanga’ The base chassis is inspired by the bike below, which is a KTM 450. I’ll be modeling the chassis first then doing some concepts of the varying body kits later. Can’t wait to drive it. 🙂

ktm bike


This week I’ve been finalizing the SDK setup of our Item creator so that everyone has access to the powerful tools we use. One of which is the seriously awesome unity plugin NodeCanvas. Big shoutout to our homies over at Paradox Notion for licencing us a re-distributable copy of their editor tools for our SDK! Any unity heads out there should definitely check them out.
Now that everything is loading nicely from asset bundles, I am going through the process of re-building all the existing gear and item functionality in the new system with the upgrades required for dynamic generation. Nothing fancy to show off this week but getting closer to the baseline of ItemV1.

Why aren’t these things in the game yet?

I’ve seen a lot of posts of people being confused where the content from the blog is, expecting it to be in game the week after we show it. Game development is a long process. What you see on this blog are things we are actively working on, but doesn’t mean you will see it in the next patch. Despite Hurtworld being in alpha, and lots of you being keen to try out half finished content, we like to get things up to a decent standard before putting them in game. There are some things that benefit from live playtesting while they are still in their infancy, but some things that would just cause havok on the current gameplay experience if put into the game before being ready. That said, if you see something in here, there is a 99% chance it will make it into the game eventually, but only when it is ready and can have its full impact. We could throw in all the creatures we have modeled, animated as re-skinned Bors / Tokars, but this wouldn’t do them justice. Instead we will wait until we have some time to allocate to coding some new and interesting AI for them, and have a new area of the map that suits them before releasing them into the game.

Things like weapon attachments will be released as part of a very big update that we have been working on for a while. As it will change the way items are found, crafted and used (along with changes to infamy), we need to rebalance most of the content in the game as a consequence. This isn’t a quick job, we want to make sure we get it right.

We also have multiple programmers working on different things. We release hotfixes when bugs come up otherwise they would remain unfixed for weeks / months while we finish working on content, this would really suck. So when you see a hotfix release, its not instead of a content release. Content is coming.


This week I’ve been working on the motorbike, more specifically, the crash system. I started getting the system I briefly mentioned in blog #36 up and running where the hips + torso are simulated on the server and the rest of the limbs + head are simulated client side. Unfortunately while this met our performance requirements it never looked quite right. I found the torso was able to move and roll too freely and when limbs were being rolled over they were often put into impossible positions on the client side causing strange artifacts and jittering behaviour in the physics system.

Unfortunately sometimes after using a physically based system the results are close but not close enough leaving us stranded somewhere in the uncanny valley, after reviewing this we decided to move away from ragdolls for crashing and back towards an animation driven system. Now we are making the player curl up into a protective pose during the crash. Luckily this pose can be well approximated by a capsule shape so the server side physics stay the same (note: I’m just using the surrender emote as a placeholder while this is still in programmer art mode).


The player remains in this crash state until they fall below a safe speed where they can start getting up.
This means some crashes can last a long time while you tumble down a hill or something similar.
As you can see in this clip I was lucky the cliff stopped me!

As you can see it’s still pretty rough around the edges so this coming week i’ll be polishing up this system and extending it so crashes will damage you and break your legs on a large enough impact. I’ll also be extending this crash system to the existing vehicles. This should differentiate the vehicles a bit more and give players the choice between safety (the roach) and maneuverability (the motorbike) with the goat falling somewhere in between. We don’t want the roach to be totally safe though and a large enough impact should be enough to send you through the windscreen or out the door (especially without panels).


So I think I have become somewhat comfortable with Marvelous Designer. At least to the extent that I can handle most simple garments, and have an understanding of how most of the tool set works as well as the best non-destructive way to go about getting results out of it..

We used a basic tshirts/vest combo as a test case.

My workflow for this gear is to have something in Marvelous Designer and manipulate/sim it till I get the desired result. Then take the exported mesh into zbrush to clean it up with zremesher and add ( or subtract ) additional sculpt details. This results in a nice, clean, easy to read mesh that I can then easily construct a game mesh around in topogun.

Once this is done I bake out all mesh’s and texture in the usual way 😉

Textures are still a work in progress at the moment.




Hurtworld Update #37


This week I’ve been pushing those vehicle related fixes into the latest patch, helping test the patch and also starting testing the city environment.
Performance is a big priority for us at Bankroll so I’ve been looking into how we can have all the extra detail of the city without a large performance overhead.
To achieve this I’ve been working on properly integrating the baking system I was working on in the first week into both the mapsdk and the Hurtworld client.
On the mapsdk side of things we tag all the objects that are part of the bake process as a ‘DetailObject’. Then when you run the bake process, the environment is broken into a 2d grid and all the detail objects are grouped based on the grid cell they are sitting in. Each cell is then baked together into the least amount of objects possible (Unity has a vertex limit of ~65k per mesh).
This step then repeats except it looks for ‘DetailLOD’ rather than ‘DetailObject’. These DetailLOD objects define a low resolution version of the cell that will be displayed whenever the high poly version isn’t loaded. We do this so we can still have important occlusion objects like walls and containers even if the cell isn’t fully loaded, without this a player could see another player behind an object once they were far enough away to unload the cell.
The next step is to grab all the colliders (these define the collision geometry) and bake these all together as well, now we remove all the detail objects to free up memory and reduce draw calls and create a new object to hold the data about the grid along with lookup tables so we can quickly turn a cell index into a list of either the high or low resolution renderers. Because these are destructive changes we save the post-bake scene into a new file ready for publishing or further tweaking.

On the game client side the player on load will look for the grid data object when they first spawn. If its not found the grid manager deletes itself to free resources, if it is found it rebuilds the grid with the given settings and gets the references to the lookup tables. The player then builds a list of offsets which essentially are a set of rules to easily find the index of the surrounding cells. The size of this adjacency list will be controllable from the settings allowing you to stream in more or less cells depending on what your computer can handle.


As you move through the level the grid manager activates the high poly renderers for all adjacent cells while deactivating the low poly renderers. Any cells that fall outside the adjacency list swap back to the low poly version.
Between this system and other gains we’ve made by not using the terrain system in the city we’re currently seeing performance similar to Diemensland on live.

Speaking of performance if you haven’t tried the deferred rendering setting I highly recommend it! Because our post processing pipeline relies on both depth and normal screen space textures and in deferred rendering we get these ‘for free’ as part of the usual rendering process.


Everyone who meets our minimum specs should be able to use deferred rendering and it should produce be a performance improvement for everyone so please try it out if you haven’t yet!


I have been adding more buildings to the industrial and residential areas. I have started building a few ‘hero’ structures, which will give character to the mass of buildings.

I created a ‘Smelter’ structure, which will be a good positional reference for people as they cruise around the industrial area. It’s tall stacks can be seen from a distance and used by a player to determine their location.

OuterSuburbs_0002_Layer 3

OuterSuburbs_0001_Layer 4

OuterSuburbs_0000_Layer 5

OuterSuburbs_0003_Layer 2

OuterSuburbs_0000_Layer 6

I am still working on a dried out pool, which will be in the suburban area. This would be a good contention point for resources.

OuterSuburbs_0004_Layer 1


Hey folks! Been busy getting and out and running this week, and fixing some bugs that came up with that release. This was one of those updates that seemed quite small on the surface, as is often the case in game development. We take something, tear it back, and build it back up to where it was but with a better structure. Same looking house, better foundations. However, it really should be a different ballgame now for modding as we know have a framework all set up.

I’ve got a big, ever-growing list of little fixes and bugs that I’ll move onto next. In terms of big tasks, I’m going to get modded vehicles in first, and then the ol’ raid drill. Modded vehicles should be pretty easy now. You’ll be restricted to four-wheelers at this point, Tom’s awesome two-wheel vehicles are still some time away. Got any ideas about cool custom cars? Let us know!

I’ll also be working on the raid drill, a new method for raiding. We couldn’t implement this device when it got made back in Dev Blog #20, but now with the new construction system it should be pretty trivial. We’ve been thinking about how the drill will work in terms of gameplay. While all of this is subject to change, we’ve got some ideas about how it can be different to raiding with C4. We think the drill will be a loud device that will draw attention, making it risky especially as you’re using it in enemy territoy. It may require maintainence, meaning you won’t be able to just set and forget it. You will need to either replenish some resource, or maybe just turn it back on. This is to increase the risk. But the advantage may be that instead of needing to rely on det-cap chance, you’ll be able to make raid drills using farmed materials. Something else to consider is making C4 less effective on some types of materials, and raiding drills be the more effective choice. This way, you can structure a base so that it forces any raiders to use both methods. It’ll be an interesting thing to implement, and we’ll definitely need to tweak and balance it carefully. It’s easy to see ‘balance’ as a simple set of scales, where you just add weight to one side or another. In a complex game though, it’s a bit more like a house of cards.

We’ll also be trying to pick up our game on Featured Servers, trying to get some for regions which don’t currently have any, and updating regions where servers have gone down or the playerbase has disappeared.


So I am fully back onto character gear. Initially I started modelling up a variety of different types of pants etc so that we could preview them in game see how they look on the moving character. The screenshot below was a couple of those tests ( un textured )


During this process we came across a piece of software called Marvelous Designer that looks promising in regards to speeding up our workflow when it comes to being able to crank out a bunch of standard clothing. The software was designed to be used in the fashion industry there has been a bit of a learning curve but I think I am coming to grips with it now. Basically the workflow we are pursuing is to build a piece in MD, generate, construct a game mesh on top, bake, then texture.

Basic tshirt and pants.


This is a work in progress jacket. Still need to add a collar and lapels.



I was planning on tackling recoil this week, but as the item construction was holding back creating any real complex items I started work on building the new Item creation system.

Item Creation System


Previously, we used a massive block of C# code called StaticItemBuilder to create our item list. As we move more and more of our content into the SDK to make it extensible, we rely on a new system of content creation that the core game has no knowledge of it (thus allowing mods to dynamically load in new content). Having items hardcoded into the game makes them very hard to modify, and even harder to author.

Over the last few weeks, we have been working on migrating our systems to be driven by ScriptableObject assets in Unity. The magic of these objects, is they can be packaged into assetbundles and loaded into the game at runtime. All we need to do, is create a nice editor for our SDK that allows definition of all the properties of a thing (eg construction attachments, items, vehicles etc) and expose those scripts via our SDK. We then create all the official content using the same tools we give to our modders, ensuring there is plenty of power there.

Back to the point, this week I’ve been working on the Item Creation editor! This little baby combined with the item behavior state machine editor, and the work Tom has been doing on mesh Baking, can configure everything needed to define something simple like Ash, to incredibly complex like a modular assault rifle.

We are at a point now for the firs time, where new items (not just simple ones) can be created without a single line of code! This is a big milestone for us, as it knocks down another wall between fast content generation, not only for our team but anyone who wants to see something in game.

Hurtworld Update #36


This week I’ve been testing and writing documentation for the new modding framework, and the creating of Construction Packs. I’ve also been preparing for the next patch – more info below! All hosted on the official wiki, you can now read how to Create a Construction Pack, Install a Construction Pack, how the Construction Attachment Editor works, and more! I also brought all the other modding documentation up to date, as a few things have changed. There’s still a bit to do, as testing the modding framework has led to a few changes over the past week. Whereas before I had thought of the architecture as Levels, Construction Packs, and then whatever we added in the future, after some discussion I realised that it’s really Levels and then an overarching additive Mod category, as we want mods to be able to incorporate multiple levels of custom content. For instance, a mod should be able to package up all into one custom vehicles, construction pieces, dynamic objects, and all of that, in any combination.

In between writing documentation, I put in a bit of visualization for construction attachment rotations. Now, you’ll be able to clearly see when an attachment point in the construction system has multiple rotations, what those rotations are, and what rotation you are currently on. This should make multiple attachment rotations a bit more intuitive.


I also have been working on getting basic networked entities into the SDK. At this point, you’ll be able to spawn dynamic objects into the world, but they won’t be able to do much. As of the next patch, we’ll probably support dynamic networked rigidbodies, which will sync their positions. Which, I reckon, you’ll be able to do some very, very cool stuff with, when combined with Oxide! This will be a huge boon for those mods, which will now be able to use custom assets as well as in-built ones.

We’ll be aiming to get this patch out by this Friday, the 24th of June. This patch is not backwards compatible, so all servers will wipe when upgrading. This is always unfortunate, especially for community servers that prefer to never wipe. However, I know most of the official infin-wipe servers are aching for a wipe. This also means that the 14-day servers will actually be 7-day servers for this cycle.


So I have finished up the MP5 and it looks to be a good test case for weapon attachment/modifiers. I may end up tweaking a couple of the maps slightly once we have it on the player and can accurately view it in first person etc, but I think in general its fine especially for a stock standard smg.


Having the multiple scopes will be fun as we currently dont have any in game atm. Next up for me is to jump back on to character gear 😉



I have been testing performance with our new grid culling system which I covered in the Devblog a couple of weeks ago. I did some tests using different sized grids with different culling distances as below;

Baseline test – No Culling

Culling 100×100 metre 50% cull distance

Culling 50×50 metre 25% cull distance

Culling 200×200 metre 50% cull distance

We didn’t get great performance out of these and realised that the culling result was being applied based on the bounding box of the tallest object and how much of the vertical screen-space it was taking up. What is preferable and simpler for us is to set distance culling per grid square. This would be calculated from the center of each grid space to the POV of the player.

So Tom is busy fixing the culling tool (amongst other things) and in the meantime I am pushing on to the suburbs and industrial areas around the city.

The suburbs are going to be achieved by standalone one unit structures, spaced out around the road network.

Houses_0002_Layer 1

Above shows the same building just rotated 180 degrees. Where possible I will try to create buildings that have a dual frontage design. This will allow us to flesh out the suburbs quickly.

Swapping textures will also help use the same meshes whilst having a bit of visual difference. That said I would like to get a few different designs into the house zone.

Houses_0001_Layer 2 Houses_0000_Layer 3

Below are more versions of the same house simply with swapped textures. Makes quite a believable neighbourhood with the added fences.

Houses2_0005_Layer 2 Houses2_0004_Layer 3 Houses2_0003_Layer 4 Houses2_0002_Layer 5 Houses2_0001_Layer 6 Houses2_0000_Layer 7



This week I’ve been hunting down bugs in our vehicle system, a big thanks to all who contributed to the feedback discussion thread and helped with pinning some of this stuff down.
First up are the infamous vehicle launching bugs. This one was a tricky one as there were actually two separate issues that both caused the same behaviour. The vehicle launching bug occurs when the vehicle and an object that isn’t being simulated by the physics engine overlap. This causes a force to be applied to the vehicle to push it away from the overlapping object. Unity gives us a way to set a limit on this force but a bug causes this limit to get reset every time the vehicle is disabled and re-enabled. Now we are reapplying this limit every reset so objects like loot crates and resource nodes can no longer create huge forces on vehicles launching them into the air.
The other big launching bug comes from players, more specifically their character controller which is a special capsule shape collider that provides a nice controllable way to move a character around and collide with the physics engine. Remember that force limit I was talking about before? Unfortunately a bug means it is totally ignored when physics objects overlap with character colliders allowing vehicles to be launched into the air by players standing in them. This was very easy to achieve using a spear to lift a vehicle and crawling under the opening.
This has been fixed by listening for player collisions in the physics update and if any are detected that are generating a large force then the vehicle velocity is reset to whatever it was before the physics step. Here you can see a before/after gif of the behaviour.

Speaking of flipping vehicles with the spear, I noticed this was very inconsistent and tracked down another bug in the way the collision check was being applied. You can now aim the spear with the crosshair to flip vehicles rather than looking at the ground. The vertical offset that was being applied to the collision before has now been moved to the flipping force so you should find this behaviour a lot more consistent and easier to use once these changes go live.

I’ve also been looking into how the vehicles and landmines play together and tracked down another bug with how explosive forces were being applied. Previously we were applying the force for each collider in the vehicle when it should have only been applied once for each vehicle. Because a vehicle can have a different number of colliders based on its configuration and vehicle type this was leading to some pretty inconsistent behaviour.
Here you can see a before/after gif of a roach running over a landcrab mine.

I’m also looking into reapplying explosive damage to the driver in these situations as a temporary fix but ultimately we need to make the vehicles destructible and it should be the exploding vehicle that kills you rather than the exploding mine.

Several people on the vehicle feedback thread brought up the need to be able to crash the motorbike. I agree with this both from a realism and a gameplay perspective so I’ve started working on a crash system. Generally in a crash system you want to ragdoll the player and let the physics system sort it out. Unfortunately in a networked game you either use a lot of bandwidth syncing up all of the player skeleton accurately or you run into desync issues because most physics engines aren’t deterministic meaning given the same inputs there is no guarantee of the same output. This is why we run all our vehicle physics server side.
So far I’ve been experimenting with running the torso of the player server side and then running physics on the limbs on the client. This keeps the player position in sync even if the exact ragdoll pose isn’t which gives us relatively consistent behaviour without a huge overhead on the network.

Whilst the motorbike and vehicle overhaul are still a ways off we should be able to push the bug fixes with vehicle launching into the next patch so look out for that.


Last week I’ve been working on upgrading the ballistics system to bring it inline with ItemV2. The first area of focus has been moving projectiles from being what we call first class entities into a system that is managed in a central point. As none of our bullets are hitscan (no travel time), we have to deal with the extra challenge of client side predicting real world objects that are constantly being created and destroyed. If we didn’t, and just waited for the server to spawn the bullet before you see it, there would be a very noticeable delay when firing a gun, especially on higher ping servers.

To prevent the problem of your client needing to predict an entity that doesn’t yet exist, we cheated slightly by spawning the bullet projectiles for the gun ahead of time. The server sends your client a message when you equip the gun saying “The next bullets you fire will be entity: 125,128 then 141…”. When you fire your weapon, your client looks for the next bullet in the list and fires it predicatively, knowing that the server will be firing the same entity once it gets the message that you fired.

This method has heaps of overhead, as with an automatic rifle, the server is constantly instantiating fully networked entities and sending queue messages to the client upto 20 times per second. Sometimes one of these packets can get lost, causing the client to predict the fire of a different bullet than the server. This is pretty easy to detect, but requires the entire bullet buffer be thrown away, re spawned and re queued. I’m sure most of you have experienced this when your gun won’t shoot for a couple of seconds for no reason, quite often resulting in you getting killed.

The solution I’ve been working on this week, is downgrading bullets from first class entities to virtual objects managed by the ballistics system. The ballistics system is a single networked entity that is responsible for all bullet projection, hit detection and visualization across the entire game. Now when a bullet is fired, the ballistics system is notified with all the relevant properties of the weapon, it can first create a local predicted bullet on your client and create a hash of the event that created it. By using the exact time tick when it was fired and playerid that fired it we can infer a unique enough identifier for the bullet that the server can also automatically determine at fire time. Meaning no pre-sharing of bullet sequence is required. The second benefit to this is bullets will use a fraction of the CPU time and eliminate all garbage generated as we can properly pool the local virtual entities without upgrading them to the network system.

Part of this will allow us to bring into line, what the person who fires sees and what everyone else sees. An example of this is when someone other than you fires an arrow at a Shigi; it dies, but on your screen there was no blood splat or hit sound, just a dust puff. By tweaking the responsibility of how the effect is generated, this should come back into line.

My second focus last week was improving the melee swing mechanics. Previously all melee weapons were a directly straight raycast from the center of the screen over a couple of frames. To more accurately represent the movement of the weapon I have introduced a fully configurable projection setup. Each weapon can model their swing arc using either a sphere cast or capsule cast. Like everything else I’ve been doing lately, this fully supports modding.

This week I will be nutting out the long awaited recoil system.

Release Date

Folks wondering when this stuff will make it into the game, we are still a couple of months out yet for all ItemV2 stuff. The main reason for the delays are the change of architecture requires a lot of re-implementing how items are built. Whenever I come across something that needs improvement, it pains me to port over sub par system and is much quicker in the long run to bring them upto scratch while I’m working on them.

Dev Blog