Press Kit Wiki

Hurtworld Update #40


We will be releasing a small update for the raid drill on Thursday. See below for details.


Three concepts I have been working on for the Kanga dirt bike are mostly done. These are nearly ready to move into the modeling stage. There are still some elements I want to change to give each body kit a unique silhouette.  The base bike also may need some polycount reduction, which I will address once I get the low poly modeled for the body kits. My target polycount for the base bike whilst equipped with any of the body kits and a set of wheels is 10,000. This is about what the Goat quad bike sits at.



So this week I had to get up to speed on our skinning pipeline as there was a few roadblocks that would occasionally arise forcing me to jump back and forth on multiple tasks. Chris (Dazzler) took me through it in a fairly thorough manner and so far so good. I used this to skin up a smoother version of our player model onto the game rig so that i could pose it in a way that generated better results out of marvelous designer.

I used this new pose to start the initial geo for a player jumper, which I then go through to the entire gear creation process  and came out with the jumpers below.
I have also started to further unify the look of all the player assets which has meant going back to facial and head gear and treating them the same way as the rest of the gear ie: baking out normal maps and setting up their shaders.


The raid drill is pretty much done! I’m just waiting on some icons, and polishing up some of the client-side effects. It took me a while to nail down a mechanic for the drill. I previously mentioned how we wanted it to be something that you couldn’t just set-and-forget, something that would require some attention while it was running. I originally implemented this whole thing where it was all these counteracting forces, and you could set how much coolant you pump in to cool it down, and the RPM would drive the temperature up, and it was “realistic”. But while it did end up quite nicely simulating a real thermodynamic system, it didn’t end up being particularly fun or intuitive.

I ended up vastly simplifying the system into something a bit more arcade-y. The main mechanics are still heat, and jamming. Running the drill at a high RPM will mean you do more damage with it, it runs hotter, and jams less. Running at a low RPM means that you do less damage, it runs much less hot, and it jams more. The trade-off then is how long you have to react to a jam. When running the drill at low RPM, you will have substantially longer to react to a jam before the drill overheats, catches fire and blows up. At higher RPM, you may only have a few seconds.
Another element to the raid drill will be recrafting it. When the raid drill breaks through a wall, or is disassembled, it will break into three component parts – the base, the motor, and the drillbit. You’ll need to pick these pieces up and recraft them back into a drill, in a workbench. This should hopefully make players be quite choosy and careful about placing the drill, as it’ll be a few minutes before you can re-place it.

I also finished up on the UI, which included a bit of new feedback for item slots, where they can now have a progress bar. In this UI they will show the use of the fuel and coolant, but later I think we can use these for showing things like durability.raiddrillUI

As I have a habit of doing, I also did some small improvements to some other areas in my spare time. Removing building pieces with the hammer has changed. Now, a ghost will appear that will show you exactly what you are removing, and the removal is based on a raycast rather than removal points. To me this feels a bit more intuitive and less likely to remove things you didn’t mean to.


I also implemented basic structure decay! This means that when a structure is in an unclaimed territory, and has not been altered by a player in an amount of time, it will begin to decay. Given enough time, it will decay entirely. The purpose of structural decay is to decrease the buildup of garbage on long-life servers. While stake-decay has improved this a lot, there is still a fair few situations where structures are left abandoned, and are either to inconvenient for other players to destroy completely, or it’s just not worth it. It will also show a clear visual indication of what bases are abandoned as well, as they will be visibly damaged. We think this is another step towards servers being truly infinite-wipe (although don’t take that as me saying that all servers being infinite-wipe is something we’re moving towards). Of course, structural decay will be totally configurable and able to be turned off, for community servers. So, some questions for you all – how quickly should abandoned bases decay? How long should a structure be abandoned before it decays?


This week I’ve been working on vehicles again and everything is getting closer. I’ve moved the motorbike and all the wrecked vehicle corpses over into the sdk along with the ‘crash vehicle’. The crash vehicle is essentially an invisible vehicle the player enters when crashing and can’t exit until the crash is over (which is how crashing runs behind the scenes). This will allow local and custom servers to mod motorbikes and the crashing behaviour (things like damage amounts, collision thresholds and if and how the vehicles can crash) as soon as the changes go live.

I’ve also been extending our suspension system so wheels can now have suspension paths that aren’t straight up and down the vehicles up axis. This allows us to animate the front suspension in a more realistic manner. I’ve also created options to animate parts of the vehicles using simple ‘look at’ targets. Making the motorbike swingarm look at the rear wheel through this system is how the rear suspension is being done. Again this will all be available in the SDK and will apply to any vehicle type, not just motorbikes.

I’ve also been working on doing more with the vehicle stat system. Vehicles now transition between healthy and unhealthy states depending on their health switching various visual effects on and off. I’ve also hooked the vehicles up so they are tracked through the environment properly and can be affected by things like heat and wind. Now rather than just have a script turn on flame particles after a vehicle explodes we can have it triggered by the heat of the explosion. I’m hoping this will lead into other cool emergent behaviours like cooking meat on an overheating vehicle or using Mondinium campfires to burn up a garage from the outside (can’t promise this will make it through balance testing!)


This week I’ve been working on the ballistics system rewrite and implementing our new hit verification system. During development we had server side hit verification running properly, however due to it constantly breaking and denying hits that should have been allowed, we were forced to disable it. This is back up and running again, and bullets use a fraction of the CPU and bandwidth they used to. Although not a high priority, this system was a blocker for the recoil system which definitely needs to go in as part of ItemV2.

I’ve also been looking at ways to fix the 3rd person sight / cross-hair so that its actually accurate.


This is a logical problem rather than a bug. If you are looking from an angle different from where the bullets are fired from, a dot on your screen won’t represent the bullets path, instead the bullet will move across your screen requiring a different aim depending on how far away the object you are shooting (as you can see in hurtworld now)

Other 3rd person games cheat here, they do things like raycast from the third person camera to determine what is being looked at and then aim the gun towards that point.
This works fine for hitscan weapons (bullets doing their full cast in the first frame), if you are aiming at your target you will hit it. If the bullets are projected like say a bow, this gets significantly harder, as most of the time you won’t be aiming at your target, you will be aiming above and in front of them. Ray-casting from the camera hits nothing but sky, we are back where we started with no idea what the player is aiming at because we don’t know the depth of what they are aiming for.


The second option is to just fire from the third person camera position all the time and make the tracer look like it came from the gun somehow, this has the issue of players being able to shoot around walls without being seen as bullets can come from places where your player can’t be seen. Some games do a sanity check to see if the players view is blocked, if so fires from the players perspective and hit the wall.

I will be experimenting with this option for now and see if we can make it feel good, otherwise we may just leave it in the shitty state and people can go first person.

Hopefully will have a first cut of recoil by this week.

Hurtworld Update #39


This week I’ve been migrating over the sprint functionality into the new Item architecture and fixing up a few issues that have been long standing with the way we handle sprinting. Our old implementation was held together with sticky tape, which you can see if you fire a rifle while running and the muzzle flash goes off pointing into the sky despite the bullet going forwards, also by sprinting just after swinging a pickaxe where the sprint would play over the swing animation.

We had to explicitly tell the movement simulator a timeout for the player not being able to sprint after doing certain tasks. We set this timeout wrong in a bunch of places because we had to predict the amount of time each action would take, not to mention remembering to do it at all whenever an item pulled you out of sprint. There was also an issue where we had no way of delaying an action on the equipment until sprint had finished, we would just do the action instantly and try to snap the animation.

Now each state in the state machine can flag if sprinting is allowed in that state. This information is fed to the movement simulator as an intention rather than an actual sprint value. Due to the fact that sprinting doesn’t start and end instantly, just because a state disallows sprint, doesn’t mean we aren’t still blending out of sprint. The movement simulator feeds the actual sprint amount back into the state machine blackboard so the equipment can make decisions based on the real sprint value.

In the clips below, you can see the CheckSprint states holding up the fire transition until the sprint transition has ended. (Projectiles are disabled as I am still working on that system)

I also had a play around with the arrow draw mechanics of the bow, previously the fire/draw was a single animation. Adding new states in the simulation that was written in code was a massive pain in the ass and hard to get right. Now its trivial.

Other sprint upgrades

Strafing while sprinting will no longer pull you out of sprint, it will now change your sprint direction left / right slightly. And as per the 10 requests per day, you will no longer need to hold down shift after initiating a sprint. I am not going to put in an autorun at this stage, if you need to leg it over very large distances and afk we are doing something wrong in the design of the gameplay. I would rather fix the reason you need to do this, or put something in the way to kill you if you were to do that.


I’m the honorary member of the Crusty Demons this week. I’ve had a lot of fun as I always do modeling vehicles. This low poly dirt bike base is looking sweet. We made the fuel tank look like it’s been built out of sheet metal to give it a bit of a scavenged look. I still have some dents, damage bits and maybe some geo to add to the tyres, but the base of the bike is mostly there.

I’ll do up some concepts on Monday for 3 sets of fairing designs. After the concepts are locked in I’ll do the high poly modeling, UV mapping, normal baking and texturing for the base core of the bike.  After that I’ll build the 3 body kits (fairings) I may build some wheel variations after that but could be doing some work on combining the cities with the map.

Note: The spokes will actually be partly transparent normal mapped texture, to save on polycount.



I’ve been working on the raid drill this week! It’s been coming along pretty well. Functionally, it’s pretty done. You attach it to wall, insert fuel, press on, wall die. I’ve been trying to make it look super cool as well with a lot of small touches, that I hope will make the machine come alive a bit. For instance, some parts vibrate, and the drill bit will glow as the drill gets hotter.

However, we don’t want operating the drill to be trivial, something you set and forget. You’ll be able to control the drill’s RPM, where a higher RPM means more damage, but also more heat and quicker fuel consumption. If the drill does overheat, it will explode, taking out anyone nearby. It won’t take a rocket scientist to control, but nor will you be able to leave it alone. The drill might also jam sometimes, and require interaction to be unjammed. These are things that I’m currently playing around with, and trying to get something that feels interesting and dynamic, and where there’s no “stable” setting for the drill. You can hear it quite a way off, which will hopefully make it a risk as you have to announce your location. I imagine that the drill may take some balancing once it’s out in the wild, and the optimal raiding strategies change around it.

I also finally got round to fixing some cross-platform issues with the SDK, where it turns out the Mac OS filesystem has some… issues.


Not a whole bunch from me this week. I finalized the textures/materials for the vests and moved onto more gear, specifically some pants.


It was whilst doing this I realized I would need to modify the player character model, extending the mesh of his torso down a bit further than it currently is. Since I was already going to have to change his UV’s I ended up moving them all around to better make use of texture space. I then baked and fixed his existing textures to fit the new UV’s.

We also decided that he should have a normal map in order to bring him into line art-wise with all his new gear. In order to do this I edited the player model, removing tris and tweaking some of the poly flow so that it would sub divide with a minimum amount of artifacting. I then took this mesh into mudbox and did a pass adding some detail and cleaning up some areas. Another plus is that it helps to smooth out a bunch of the lighting errors we would get in places like his ear and underarm etc.





This week I’ve been continuing on with vehicle changes. I started with hooking up damage and the broken leg debuff into the crash system. When you’re crashing, large collisions will be able to hurt or even kill you and you can also be left with broken legs like when taking fall damage. Here’s a quick gif of me sliding down a hill on my bike and caving my head in on a cliff.

I’ve also done a bit of work polishing how the camera works with vehicles. Now when entering a vehicle in first person your view will automatically shift to the front of the vehicle. When exiting in both first and third person you’ll stay aiming in the same direction. I’ve also added a setting for vehicles to force them to be in third person camera. Although I added this setting to force third person during crashing it should also be a help to any vehicle modders who are using car models without the interior.

Lastly I’ve been adding destruction to the vehicle system. Vehicles now have health and they will explode into a burnt out shell when it runs out. The size and force of this explosion will be increased depending on how much fuel is in its storage. The burnt out vehicle corpses that get left behind can also be harvested for resources with the right tools. Obviously this is a significant change that we will have to rebalance things around but we want to make vehicles easier to obtain now that they will be less permanent.

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.




Dev Blog