Press Kit Wiki

Hurtworld Update #58


The guns are now getting some iron sight designs as a starting point for the grey-box testing. we need to get a feel for the type of sights we want. Spencer said he wants something that feels fairly fine, so you can really feel your victim being lined up. I couldn’t agree more. This is difficult until we get it in game and actually look at it. I just made a greybox version of an SMG as well. This was based on an old style world war gun. I’ll be designing a component based pickaxe next, using the same construction system as the new guns.

I also made a box for the new sleeper system, which I think you’ll agree is quite hilarious. It had to be low poly and the size of the players collider capsule, so a box was the best option for this one.

random_0006_layer-1 random_0005_layer-2 random_0004_layer-3 random_0002_layer-5 random_0001_layer-6 random_0000_layer-7


This week I finalized the two basic shoes, and knocked out a set of Timberland style boots with three skins being classic, dark, and worn.



We are also looking to do some extra character skins of varying nationalities/skin tone. The changes need to be enough to sell a different look, however a lot of the facial landmarks need to stay intact to accommodate hair/hats/facial hair etc.



Hey folks. Not a lot of pretty pictures from me this week. I started off this week by sorting and trying to make a dent on the Bankroll support email. Still about eight hundred emails still needing a read, but hopefully we will get through all of them eventually. Thanks for all of your bug reports and suggestions!

For the Friday patch, I fixed an exploit where people were able to push themselves through solid objects by building into the space they were occupying. We think this was exacerbated due to recent changes to player collision. The solution was to just create a conservative collision check on all the construction attachments that only checked against players. This might mean that your friends can block your building a bit more easily, but it’s a small price to pay for guaranteeing that when a construction piece is placed, it isn’t going to push a player through a wall. I would strongly advise anyone who has made a custom construction pack to go back and add a new ConstructionVolume to all of your attachments. There’s a handy “Snap To Bounds” button now that will set the ConstructionVolume to encompass the attachment. Set the “Don’t Bake” and “Override Collision Mask” flags to true. You’ll want to set the Collision Mask field to Players, PlayersRoot and PlayerSelf. See below (and the updated attachments in the SDK) for examples.


I’ve gone and optimised the map generation a bit, and ran Spence through the map generation workflow for the first time. This was good as Spence was able to pick it up and make sense of it pretty fast! I was worried that after all this time being in my map-generation-programming hermit cave, the pipeline might have been far too convoluted, but it seems like it has turned out to be a pretty cool toolset. Spence requested some QoL upgrades which I implemented, as well as giving me some direction on what needs some tweaking in the generation. More on this next week.

I also took a bit of a look at how Biomes are structured, and it looks like I’ll rework them to be a bit more flexible in what they can do. For instance, we are probably going to implement things like NoBuild zones within the Biome system for ItemV2, instead of with colliders as they currently are. We’ve run into some performance issues with big colliders, so it’s something we need to move away from. How this would work is that biomes now can choose how they are blended with all other biomes. The logical structure of this is very similar to how we blend ambient audio sources – a biome can be Normalized, Greedy, or Overlayed. Currently the behaviour of all biomes in Hurtworld is normalised, which means that the total weight of all biomes adds up to 1. Adding these two other modes means we can have additive biomes – like a biome that only adds a binary effect like NoBuild. The Greedy blend mode also opens up a different way of doing weather which might be a lot better. I’ll go into more detail with this when it’s more complete.


This last week I’ve been working on getting the sleeper update finished.
The reason we added sleepers so suddenly rather than waiting until after ItemV2 was to deal with an exploit where people were logging off and then having their friends build over their position causing them to be pushed away when logging back in, with the right setup and a bit of luck people were using this to push themselves inside rocks and other terrain.
Sleepers stop this by adding a no build area around the sleeper, if the server you’re playing on has sleepers disabled then a different invisible sleeper is created that is just a no build area that can’t be interacted with.
These invisible sleepers have a timeout so they don’t stick around forever creating permanent no build zones but the timeout is long enough that someone would have to be seriously committed to be able to exploit them.

I also made a change to the way vehicle stats are updated that hopefully will stop a bug where the physics world became desynced from the main simulation after sending many redundant updates over a long period time (20+ hours), this was causing vehicles to move in strange ways after resting for a long time, sometimes penetrating through walls and other terrain. If you notice this still happening in please let us know!
I’ve also had some time to work on ItemV2 fixing some bugs in the mesh baking system, extending our model viewer to work with the first person view and getting vehicles working.

This morning I’ve been working on a quick patch for the sleeper update to fix spawns after your sleeper is killed so you’ll properly respawn back at your totem if you have one. In this patch I’m also going to tweak the spear right click numbers a bit to make it easier to flip goats back up as it’s gotten a bit tricky after the last spear balance change.
This week I’ll be adapting the mesh baking system for vehicles and working on reimplementing all our current items under the new system.


This week I’ve been mostly playing studio head, getting upto speed with what everyone else is doing and making sure we are moving in the right direction. I had a bit of a play with Cow_Trix’s terrain generation toolkit and have to say its pretty amazing. It really takes all the repetitive work out of map creation, meaning we should be able to pump out some sort of new map per month or so once we get rolling. I spent a bit of time refining the basic formula to the terrain, to ensure things don’t feel too empty or too small. I’ve now passed it back to Cow_Trix for further iteration.

I spent the rest of the week looking at upgrading our ItemV2 branch to the Unity 5.5 beta, there are a few features that we have been waiting on a while. This failed miserably, so I’ve settled for 5.4. One awesome benefit this brings is allowing us to re-use the same asset bundle builds between platforms. Meaning all workshop items will be 1/3 the size and build in 1/3 the time.

Lastly I ported our tooltip system to ItemV2. This week I’ll be back on bullet feedback in preparation for the ItemV2 deathmatch release.

Hurtworld Update #57


Things are ramping up a lot around the studio in the last couple of weeks. We’ve been working really hard on heaps of new stuff on our own for ages, and its finally coming together.

I spent most of this week working on planning the road to the ItemV2 release, and implementing a game mode system to support the official Team Deathmatch mode. I figured if we were going to use the deathmatch to iterate on guns, we may as well make it fun.


The main function of the game mode system, is allowing us to swap out logic for things specific to a particular game mode without having hacky checks all over the place to see what we should do when something happens. The game mode drives things like: spawning, scoring, giving equipment, friendly fire etc

This week I’ll be fixing a few bugs that came up in ItemV2 from our deathmatch tests, and improving the feel of the guns before unleashing it on you guys, hopefully the following week.

Sleepers on Logout

It’s been a long time coming, but we’ve finally decided to add a representation of your player in the world after you logout that doesn’t disappear until you connect the next time to the same server. This means your player is always vulnerable to being killed while you are offline. This solves a bunch of issues around people using themselves as unbreakable vaults while logging off, it also solves the issues around raiding a base, taking it over and not knowing if a previous owner will spawn inside your walls. Most importantly, some people discovered an exploit where logging off, building structures in the place where you logged off, then logging back in would kick you through objects. This can only be solved by leaving something behind when you logout that blocks building. This is one of the last steps to ensuring continuity in our physics system.

There will be an option to disable it and use the current functionality on community servers, however all official servers will use sleepers.

Patch And Wipe This Friday

This (and only this, not all the other stuff we’ve been working on) will go out this Friday along with a official server wipe. Wipes will not be mandatory for community servers. Checkout Toms post for more details.


Welcome to Grey Box Citeh… We have entered the grey box phase for the weapons now.  The image directly below is just a pretty render of an Assault Rifle and a Sniper Rifle.

These are based off the designs below, although slightly modified from the silhouette sheets, as we are thinking we can squeeze some of these into the existing animation sets. This will help speed up production.  These are low poly meshes, which will be mashed up until we lock in the form and function. There will also no doubt be a lot of detail geo added to make them more interesting.

I’ve been getting up to speed on our Static Mesh Baker this week too, so that I can send the goodies across to the coders for testing etc.

gunsprettyrender gunsils_0000_layer-2 gunsils_0001_layer-1


This week I was finishing up the patch and then quickly fixing up the broken ladders for
After this I was back into ItemV2, merging up the latest changes from live, fixing some bugs in our new mesh generation system and starting to get vehicles working again.
This didn’t last long though as we were quickly made aware of some remaining bugs and exploits and I was back onto patching them up.
As a part of this next round of fixes we are adding a sleeper proxy system into the game so you can no longer simply log out with your items to keep them safe!

Now after leaving a server for any reason you will leave behind a proxy of yourself in the world. Players will be able to kill the proxy triggering the standard loot drop for the server type.
If your proxy is killed you’ll respawn when you next log in rather than returning to your previous location.
Proxies run their own inventories and stats simulations behind the scenes so we can properly assign infamy and determine loot drops, this also has some other interesting effects such as items being constantly simulated (meaning your food will turn mouldy while offline). The stats simulation is not updated however so you can’t wait out infamy and you won’t starve to death while offline which would be frustrating and overly punishing.

In the future we’ll also also be able to things like let you open a players inventory and take some of their stuff or maybe you’ll be nice and leave them a new item (hey it could happen!), were going to save this kind of stuff for once ItemV2 is live because otherwise we’d have to implement it twice essentially and it’s not worth the time.
At the moment we are aiming to get this next update out in time for the next wipe on the 28th of November, we’ll be wiping the infini wipe servers with this update as well due to the way sleeper proxies are constructed on server start. We wanted the proxies to exist even if a server didn’t shut down correctly so on server startup we construct a proxy for every living player who doesn’t currently have one (players who have had their proxy destroyed are marked as dead so they’ll be skipped over in this process).


So this week I ended up going through all the gear and trialing different paint methods, testing which items look good with global paints, and which should just have selectively masked areas.

All the hair and beard items I think work well with us enabling the player to affect the overall colour of the item, as do things like jeans.




Other Items like the packs would benefit more from selective masking.



I have also started making some new items starting with footwear. At the moment I have made some basic boots and basic sneakers.

Basic sneaker sculpt.


Basic boot sculpt.


In engine pic of basic footwear.



Hey folks.  This week has seen a lot of iteration over the map, and I think it’s getting to a pretty good place. This iteration also exposed a few bugs in the road system which have been fixed. Early in the week I did some work on the city suburbs, building out the CBD into suburbia, as well as a park area. I’ve also been working on the general play area generation and I think that we’re pretty close to something workable. Check out some screenshots below.

map6map5 map4 map3 map2 map1

I also finally came up with a semi-decent solution to blending road segments together, which was mainly a thing of finding a shared boundary between the segments. If the boundary is deterministic from the start and end nodes, then the blending between two nodes will work fine. I still don’t have a great solution to blending between an arbitrary amount of nodes, but considering how we’re doing intersections as separate distinct objects that might be a problem we never need to solve. I also solved a bunch of bugs around rolling nodes, and editor-side bugs to do with selecting, deleting and moving nodes.

Hurtworld Update #56


This week I did some exploration into producing a better type of metal finish for the guns we have been working on. The aim here is to create a more satisfying metal finish for the new weapons, which will make them feel more alive and ‘heavy metal’ The screenshot below may not be where this actually ends up, but is a step in the right direction.

I have taken the new gun designs in a slightly different direction. Instead of each gun chassis having completely interchangeable parts, we are going to keep the central body of each gun the same. So for example if I had machine gun, the grip and the core of the gun will now be one item. This will take a lot of the headache out of the component design and give the main body of the weapons a distinct silhouette. The issue with the first creature weapon designs was that the gun body generally ended up being a square or cylinder of a mix of the two. All of the design work so far will still be used, they will just be reworked to adapt to this new design ideal.



I was sick for a lot of last week so not not a great deal on my end. Finished getting the new gear moved across and tested. At the moment am going trough some of the items and testing ways to apply paint-ability to them. Some basic items may end up being universally paintable with the colour changing the entire item. Something say like the tshirt. Or we may keep a basic set and allow logos and trims to be changed.


Other items we will wish to keep the overall aesthetic integrity of the item intact and instead allow the trims, stripes, tape etc to be altered.





This week I’ve been continuing to work on our character controller problems which unfortunately became a much harder problem to solve than I originally thought, delaying the update.
Whilst my first attempts at solving the problem were able to remove the penetrating through walls exploit they introduced a lot of jitter and stuttering when colliding with vehicles which we decided was unacceptable.
This jitter was due to the delay between client and server making clients see vehicles slightly in the past compared to the server. What was considered an illegal move on the client and rewound due to vehicle penetration was considered legal on the server because the vehicle had already moved on out of that same position. This meant the client was corrected back into the vehicle by the server only then to have the whole process repeat. This was solved by changing the method of detecting illegal moves from physics checks to directly checking actual movement changes against the expected movement change and allowing for a significant margin of error (without being so significant that you could still ‘push’ through geometry).
I also removed the ability for a rewind to be triggered clientside by changes in the y-axis (up and down), instead just running them on the server and allowing the correction method to rewind the client over a number of frames which again reduced jittering. We’ve also slowed the speed of server corrections slightly which again helps to increase smoothness.
I’ve also tightened up our crouching method, previously we were just changing the character controller height which would also shrink the collider upwards from the feet (we did this due to strange behaviour when changing the controllers center and how it affected triggers, as part of this change we have decoupled the controller from triggers completely) which could strangely enough make it easier to walk up ledges while crouched and also allow the player to be pushed under the world by something pushing down on their head.
Now in effect we have the same crouch height with a more accurate collision volume, in practice however the minimum height you can crawl through has been reduced as you can no longer squeeze your feet under the world.


One upside of the patch delay is I also had some time to squeeze in a small change where you can now change your display through the graphics options, you can find this under Options > Graphics > Resolution > Display number.
As I’m writing this I’m building the release candidate for to go onto devtest, if testing goes well (fingers crossed) we should be releasing this patch very soon.


This week I’ve been integrating sub frame bullet events into the equipment pipeline based on last weeks experiments. I also changed the repeat method to use single audio files per bullet instead of 4 bullets per file to simplify the integration To ensure I had the same audio results, I constructed single shot sounds using snippets from the fully automatic clips and tails stiched on that get silenced when a new bullet is fired. This allows me to drive the audio system on a much simpler basis, as now only the state machine needs to know how fast the bullets will be firing. Results are feeling very good.

While adding back in the bullet sound emission to weapons, I spent a bit of time building a new sound layer that manages creation and configuration of AudioSources in Unity that allows us to define things like falloff distance, clip group selection details and distanced based clip swapping all at the sound level. By default, the Unity audio workflow is designed to have most of this stuff configured on the object emitting the sounds which really sucks. Given that a player will emit all sorts of different sounds with different falloff properties, you are forced to create a multitude of audio sources all with explicit configuration on every player. Now we can say, an un-silenced 5.56mm supersonic bullet has a logarithmic falloff with a max distance of 1000m, and is substituted for a supersonic crack if the listener is a long distance away, while a footstep can only be heard upto 20m away. Anything that wants to play either of these sounds will only need to specify what sound and where.

The other reason we need this is to decouple sounds from code (previously represented by an enum) so they can be loaded from the SDK using our new mod architecture.

Here is a test rifle in game running at a few different fire rates, previously every gun needed to fire at exactly 10 bullets per second, or 20 bullets per second so it would sync up with the 20hz tick rate.

This displays an interesting problem in that, as recoil is calculated per bullet, increasing the fire rate makes the recoil head a bit out of control. I will likely add a scaling factor to recoil depending on the fire rate that is generated for the weapon.

I will be pushing round 2 of our internal deathmatch build this week and should hopefully have something for you guys soon.


This week I’ve been further building up the map, and starting to make some real progress. I’m pretty happy with where we’re at in terms of the tools and workflow I’ve built up over the last few months. I can do everything I need to quickly, don’t need to worry about ever throwing away work, and can tweak some base variables and see the changes cascade up the generation. I’ve also been going back to the city, which still has a fair bit of work needing to be finished.

I also got started on implementing all the entity stats needed for water to work (i.e. kill you) so that meant starting to implement an oxygen stat that would make you asphyxiate. Implementing this made me realise how obtuse and confusing the entity stat system can be in it’s current state, which I didn’t beforehand just copying over old configurations. I’m still figuring out the best way to make effects like oxygen only care about the position of the player’s head – as it doesn’t make sense for someone to start drowning when they stick their feet in water.

I’ve added a framework for landmarks and structures to tell the generation what it needs to do to accommodate it. This is based a lot off what I’ve shown previously with intersections. Now, a structure can define several shapes around it’s foundation which the map generation will take into account when generating, removing rocks, trees and even hills to make way for the structure. While for a time I considered making even placing these man-made landmarks procedurally, I think we will have more ability to design if we are able to specifically place them.

This outpost structure dynamically raises the terrain and places some trees.

This outpost structure dynamically raises the terrain and places some trees.


We also now have a way to place trees explicitly in the tree system, which has meant that the city has come to life! The once empty planter boxes, parks and sidewalks can now have trees which use the existing, high performance system.



Dev Blog