Press Kit Wiki

Hurtworld Update #26



Hey guys. Couple of new things this week, including construction, and looking at highlighting community servers that are doing cool things.


When I haven’t been getting this patch sorted, I’ve been looking into revamping the construction system. Currently, the system has exactly the same mesh for collisions and rendering. Because complex mesh colliders are very expensive, this means that the building generally have to look very simple as well as collide very simply. It’s also tricky to do things like complex level-of-detail, finding out what part of a building a projectile hit, and more complex destruction.
So, I’ve been looking at expanding the already very nice construction system to be able to accommodate all of this! First, a bit of information about how the construction system works, specifically the passive construction system. Things like machines, firepits, storage lockers, we refer to as active, and are just objects in the world we treat like individual things, because they need to do stuff. However, if we did that for every single wall piece in the world, the game would be unplayable. So, for things like wall-pieces, trusses, foundations, etc. we gather them all up, and bake them into combined meshes to save on both physics processing, and rendering.

Basically, say you construct a new wall. The game goes and finds the whole structure, and tells it about this addition. The structure adds this information to a list of things that have gone into making up the structure, and then goes and rebakes whatever meshes it needs to – in this case, all the combined walls.
So one tricky problem we had to deal with was this. Say you’ve combined a building into one big collider, and then you shoot it. How do you tell which of the original building parts it hit? The physics doesn’t have any distinction anymore between one part of a building and the next, it just treats it as one big object. The solution we figured out was to count the mesh triangles. Let me explain. Meshes are made up of a list of triangles, or tris, that describe an overall shape. When you raycast against a mesh collider in Unity, one of the bits of information you get out of that is what the index of the triangle you hit in that mesh was. We also know how many individual triangles were in each piece of the building parts. So, we can simply count upwards, adding on the total triangle count for each piece as we move through this list of additions, and when we get to the range surrounding our number, we know we’ve found the piece.

Awesome! This opens the door to cool things like stats for individual parts of buildings, and much more dynamic destruction. You might be saying C4 already does what seem like fairly dynamic destruction, and you’re right, but the way it does it is very expensive and not particularly good. This method is much more flexible and future-proof. We can start saying this piece of wall has this amount health or heat resistance or anything, really.

Featured Community Servers

Something we’ve wanted for a while is a way to highlight community servers that provide a good experience for players, or are doing something really cool with mods. We’ve introduced Featured Community Servers, so we can highlight servers that we think are cool and should get some more love. Of course, we want to do this with the server owners consent, so we’re not flooding someones intentionally small server with attention and new players. We’ve had some awesome feedback and lots of nominations on this! It’s been really awesome reading about how much you folks love the servers you’re on and want to see them get the recognition they deserve.

If you’ve got a community server you think should be featured, let us know here!


This week I have started to update our construction materials and textures. The process I use at this stage is to usually grab a photo ref texture base, tweak it in photoshop ( mainly levels and saturation, sometimes quick painovers ) then take it straight into unity and throw it onto some construction pieces. Making sure that the tiling isnt overly obvious is the first thing I pay attention to, either tuning the tiling settings in the material setting, or scaling the texture in photoshop. Having a large structure built like the one below helps in this and I will move to various distances to check the readability as well as occasionally changing the lighting conditions. During this time I am also taking into account how the colours read and whether or not something is standing out too much against its neighbor. I then take the base texture back into photoshop and paint out a lot of the photo real detailing, making sure that everything still tiles ok as I do.


I want to add normal maps and spec maps to the new materials ( nothing crazy just something to add a tiny bit more pop and personality ) so when I have a texture that I think possibly looks ok, I will paint a height map and use that to generate a normal map. I also use the height map as a fairly decent start point for a spec map.



I’ve been hard at work on the upcoming equipment restructure and infamy changes. As part of these changes I am taking the opportunity to do a major refactor of the equipment system which will provide massive improvements to the stability and quality of gunplay. Now that we are starting to see some deathmatch servers coming up (with new awesome community made maps), we have a better platform to iterate over the gunplay and push them to the quality we have been aiming for.

I am still a few weeks out on getting any of these things in game.

Item Schematic Concept

I’ve spoken a few times about wanting to introduce procedural loot drops (think diablo / borderlands) and have been trying to figure out a way to fit them into a more survival crafting oriented style. The biggest challenge I see is the difference between finding something awesome, and crafting something awesome. In a lootfest RPG, you constantly sift through trash loot until you find something that is an upgrade for you, stuff you don’t want is of no cost to you. Some RPGs also contain a crafting element where you collect resources and basically get one roll with a decent chance of good stats. In reality you end up crafting 10 of the same item hoping for something decent and throwing away the rest, as your gear gets better the chance of getting an upgrade gets lower and lower meaning having to craft more are more for less returns.

I personally never buy into these systems as it feels like a waste of resources, and re-crafting the same thing over and over isn’t much fun.

Now take a survival game, where most things are crafted from resources. How do we infuse the loot drop excitement with resource gathering and crafting without it being a very expensive gun slot machine?

The solution I am leaning more and more towards is having creatures / loot crates drop single use schematics that have already revealed the random bonuses on the item. The item still needs to be crafted at an advanced crafting table with variable resources required depending on the quality of the item, however there is still the gathering and crafting element similar to the existing items in the game right now.

I feel this will be the best way of delivering loot with varying quality, stats, bonuses and attachments while still fitting into a survival game. Upgrading the gear after the fact isn’t out of the question however this would be much more expensive.

I will be fleshing out this idea over the next couple of weeks, and it will hopefully make it into the game at the same time as procedural loot (still a while off)


I went on a Road Trip this week. Having created a good range of pieces for the Buildings, Sidewalks and Roads, I moved on to creating the proper assets within Unity. Firstly I made some tower prefabs, which after some thought, seems to be the best way to quickly build various shapes and sizes of structure.




Next I built a network of roads, and the idea here is that they be modular as with the buildings. I had to create a few more pieces as I went to plug small holes and generally make the system more flexible. I can think of 10 more meshes at least that will help the road system along. I need to dirty things up a lot more in general also.





Hurtworld Update #25



Hey Hurtworldians,

It’s been an exciting week for us as we start to dig our teeth into the more juicy changes to Hurtworld we’ve been wanting to get to for a while. This blog is a lot more technical than usual, with a less pictures. It should give you a good idea about where we are headed over the next few months.

Infamy changes Part 1

Over the last couple of weeks we have tossed up pretty much every possible scenario to improve the issues posed by the current implementation of infamy. This included looking at everything we have committed to so far with the direction of the game, and asking the question “How married to this are we. Does it create more problems than it is worth?”

The first thing that stands out is tying prevention of griefing to penalty for death was a dumb idea. Griefers gon’ grief, we shouldn’t destroy the game trying to prevent that. The first thing we need to master is penalty for death, so for the first iteration of these changes, that is all we will be focusing on.

The second thing we had a long hard look at was “Is storing progression value in gear a good idea?”

In my previous infamy devblog I spoke about the extra challenges we face by having so much progression value stored in gear without looking at if this was really improving the state of the game. It was just a given, that’s what we do.

The more we discussed different options to make progress securable while still creating constant danger for the player from death, the more we realized that we are making our lives harder than they need to be.

Regardless of any suggestion we or anyone else came to about how to fix the current problems, the glaring point that came out of it was the problem is far too hard to solve using our current tools. There are simply too many factors involved that we have no finite control over to ever reach something balanced.

We need a cap on item value

As long as the value of items can constantly increase, balancing loot is going to be impossible. When you craft an item, it can have infinite value to you because you will have it forever. We balance for this by making things very expensive, this is what makes full loot suck.

As I described in the first infamy blog, we will be shifting some of the value from items to other places like your base. The upcoming C&C machine and others is perfect for this purpose. Instead of investing 100 iron and 100 mondinium in an AR rifle, you would invest that in a machine that can craft rifles, then pay a cheaper price to craft the rifle.

At this point losing the rifle will only take away the cheaper cost to create a new one, but not the whole investment, yet your attacker can get the bounty of the function of the item.

Nothing lasts forever

This poses a new problem for us, if the reproduction price of the item is low, first person to get the production facilities can deck out his whole crew with guns that will last forever. Anyone who kills someone that is pumping out these guns also instantly gets decked out.

To give us more control over balance we need to be able to restrict the lifespan of an item. The best way to do this is to introduce durability.

With durability on items, we can say, one creation will net you x amount of gathered resources before you either need to repair or replace it. It serves as a currency sink so one person doesn’t end up with 100s of useless pickaxes, and most importantly limits how much you lose if you drop an item, as even gear is a finite resource.

The second problem I see here is that the manufacturing facilities being shared, gives larger groups a massive advantage. While we can’t completely balance PVP with groups of different sizes, we can do our best not to give them more advantages.

To counter this, our plan is to also introduce durability to machines. Meaning that initial investment in production of an item isn’t infinite, so depending on how many people are trying to share it, they will need to spend more to keep it running along with the crafting costs.

What this means for infamy

I think its probably a good place to stop calling what we are dealing with as infamy. Infamy was an experiment with a cool name, it was a standout differentiating factor from other games but ultimately wasn’t workable solution to all our problems.

The problem at hand here is penalty for death, to which infamy is no longer the solution.

What will drop on death

At this point I am leaning towards balancing for partial loot (everything except clothes always drops), with a view to eventually go full loot. At least with the above changes, full loot will be significantly less punishing stupid.

There are still some issues to work out around respawning in an area that you can’t survive in without gear, that we need to work through, so initially we will keep clothes as unlootable with durability loss on death.

As with any game design choice, testing is key. We will be working towards the above changes over the next couple of months and move from there.

We may still have some sort of amplified punishment in future for killing people, but we will look at that after we sort out penalty for death and get it right.

This brings me to the technical limitations we need to overcome to implement these changes.

Items 2.0

Something that I’ve been meaning to implement since I first started work on Hurtworld is the ability to store complex state on a per item basis. The fact we have survived this long without it is due to a few dodgy hacks, and nothing really needing it that badly.

Currently all items are static. At compile time we create things like Assault Rifle, Cooked Stake, Shaped Iron etc. The only things that can make 2 copies of the same item different are ammo count and how soon it will transition to another item (like being cooked or smelting).

This really isn’t a workable solution going forward. We could hence I have started work on Items 2.0.

There are quite a few goals for the new system, which I think is going to bring a lot to the game:

1. Ability to store and display durability information on each item
2. Ability to store ammo in a non buggy way
3. Supporting different ammo types loaded into guns
4. Weapon attachments
5. Random weapon / tool stats (think Diablo / Borderlands)
6. Proper client side prediction of weapon / tool simulation
7. Cleaner bullet simulation
8. Improved UI that can display things like how long until a steam goes off etc
9. Item stats that can modify things like reload speed and mining speed.
Most of these are self explanatory, I will go into more detail about a couple:

Client side prediction of equipment

Client side prediction is a tool which we use in network games to ensure you don’t have to wait for a response from the server before you see your input acted upon. Eg: When you run forward, you expect to instantly move despite the server needing up to 200 milliseconds to verify that you have moved.

When predicting things client side, we basically assume with some reasonable assurance that we know what is going to happen on the server when we do something. If we try to walk forward, we expect to move forward. Pretty simple. The server gets our instruction to walk forward some time later, runs the same simulation as us, and sends back the result.

By the time we get the confirmation that we walked forward for time tick 3, we are already at time tick 6. We check what position we were at time 3 (we kept a log), and verify we predicted correctly. If so we keep on ticking from time 6. If we got it wrong for some reason, we need to rewind to time 3, and replay our input to time 6 (we kept a log of input also), compare the new time 6 to the old time 6 and smooth towards where we should be. This smoothing is what people call “rubber banding”. The more lag on a server the more often we get slightly out of sync and need a correction.

Although quite tricky to get right, its not complete rocket surgery thanks to the brilliant mind that is John Carmack not only paving the way, but open sourcing the Q3 engine for us to all learn from. This is implemented for player our movement and is fairly rock solid.

For guns and tools, we predict what is going to happen, but have no way of knowing if we got it wrong let alone executing a correction. You may have seen times where the gun jams, and only re-equipping it can fix it. Or when the shotgun gets stuck in a reload loop. The reason we haven’t attempted to fix these yet is that they require a big refactor of items. Since we are changing a lot in this area, now is as good time as any to fix these foundations to bring weapon prediction in line with player movement.


As you may have already noticed sticking to a tight schedule isn’t our strong point. The above is a fair bit of investment, that will result in not a lot of updates in the next couple of months.

What we can achieve in 2 weeks with 2 programmers is not going to enable us to do much with the game. The stuff to get excited about takes months, so that’s how long we will take. We have been on the lookout for another senior programmer to get things moving a little faster, but like every other software industry, good programmers are in very high demand and thus hard to find. The search continues.


So I am still grunge-ing up the city. This week I have been breaking the walls structures up, which takes quit a bit of time. I have now got a couple of broken wall sections per wall type.


To achieve this I have just cut up the existing undamaged wall sections and moved the meshes around on the existing textures. I didn’t have to add any new parts to the existing textures to get this result which is always what you want where you can manage it. This will save texture space for all the things we want to go in like; Garden Planters, Garbage Bins, Piles of Trash & anything else that will break up the street level space.


Oh yeah, and I also made some rooftops that will probably eventually have doors, so you can lock down the stairwells. Useful to stop sneaky flying people from getting in.


Community Communication

Hey Hurtworlders! This week I’ve been looking into ways to get more feedback from the community, directly in game, as well as getting some level of communication from the us to you in-game as well. While we have the Steam forums and some other channels for feedback and developer communication, we find that a significant majority of players don’t interact with these. So, optimally, we’d like some kind of announcements panel in the main menu, where we can put things like news, polls, patch notes, and more! We want every player to have at least some exposure to the wider Hurtworld community than just the server they play on. Dota 2 do this pretty well I think, if you’re still trying to picture what I’m describing.

To do this, I’ve been looking into integrating a webkit browser into the UI, which would give us the ability to display pretty much whatever we wanted. This means we could just display a web page as part of the UI. We could update it dynamically, without needing to put out a patch, and it would be extremely flexible in what we could display. To change the look and feel of it, we could just update the CSS, and to change the content it’s a quick edit to some html. Awesome!

Things like polls showing up right in the main menu are exciting, as it gives us a very broad sample base for polling. If we posted a poll on the Steam forums, we’d get some really important information, but we’d also have a pretty huge selection bias. Most Hurtworlders just don’t frequent the forums, and we want their feedback as well.

We hit some frustrating road blocks in this, or I reckon it could have made it into this patch. There seem to be some issues with how the webkit plugin interacts with the Graphics Layer, which causes crashes from mis-timed render events. Basically, the webkit plugin tries to interact with Unity’s graphics at the wrong time, and Unity doesn’t know how to handle it, so it has to crash. Hopefully we’ll get some love from the plugin developer and have these issues resolved, but I think its gonna be pretty awesome when it’s done.


This week I have been modeling and texturing the Monkey-Bat guy thing. Initially I had built him in a more leaned over neutral pose something akin to a Baboon, however we have decided to go with a more upright bipedal critter.


So essentially I cut up that model, rotated and manipulated the geo, then stitched it back together. Because I had already done a bunch of the texturing I was able to bake that across to the new model as a decent starting point. This is what it looked like after being stitched back together.


I then began repainting in mudbox and photoshop, fixing up all the seams, and giving it some characteristics more in line with a bipedal creature.



I have been carrying on with the cat animations, which are almost done. He has been a challenging creature to animate, trying to get that nice fluid power. Aggression is easy. Smooth is easy. Smooth Aggression is quite hard! Here are two transition sequences between aggressive idle poses.

Few little bug fixes for the patch, and the template laid out for the Skoogler rig too.

Hurtworld Update #24


Hey Hurtworlders! Couple of things I’ve been working on over the past week.

Ambience and Music

I’ve been setting up the infrastructure to do more complex ambient sounds, as well as some music tracks. We’ve got at least 2 ambient tracks per biome, one for day and one for night.
This meant a bit of refactoring of how we create the soundscapes of Hurtworld. What seems on the surface like a pretty easy thing gets complicated fast once you start digging a bit. For instance – it starts raining, which makes noise. You can just overlay the rain over the ambient sound, but this ends up being a bit of a cacophony. Optimally, as the rain gets louder, we want the ambient sounds to get quieter. We’ve got a finite amount of volume to give to all ambient sounds, and we need to figure out a way to share it out.
So, the new architecture gives ambient sounds three options – Greedy, Normalize, or Overlay. Overlay is the simplest – this doesn’t care how loud other sounds are, and other sounds don’t care how loud it is. We use this for things like the irradiated effect. Normalize means that the sound should try and fill whatever volume it can, but it should never reduce the volume of any other sound. This would be all ambient background tracks. Finally, Greedy would be the rain, which consumes whatever volume it wants and leaves the Normalized sounds to fight over the scraps.

I’ve also been adding in some music tracks, which will play randomly every so often. Don’t worry, there’s a volume slider if you’d rather blast some death metal while spearing nakeds. All in all, these new sounds add a lot of atmosphere and ambiance to Hurtworld.


Hurtworlders love to break stuff – which is great! We’ve come a long way in fixing exploits since release, and we owe that to the community for finding and reporting these. Remember that time you could double-jump by opening your inventory? The series of events that made that possible in our code was… pretty mind-boggling, and we may have never found out about it without your help.

It turns out that there’s one scenario that creates exploits a lot, and that’s whenever you transport the player. This happens a lot in vehicles.

So, a simple scenario. You’re on a goat, and you decide to get off. This is basically a teleport – you just kinda poof off the goat, and appear somewhere else. But where do you appear? It’s a simple problem when your surroundings are simple – say, you’re just on a flat surface. Just appear next to the goat, problem solved. As your surroundings get not complicated though – say, a bunch of rocks, buildings, etc. – there’s a lot of trickiness introduced, and it’s difficult to always answer that question properly. When it gets it wrong – say, teleporting you halfway into an object – that’s when exploits happen.

I’ve been making this system a lot more robust so this can’t happen. This means, however, that there are some situations where there is no good answer to where you should exit. Say, if you’re completely surrounded by walls. There’s nowhere to go, so what do you do? Easy, right? You just tell the player that they can’t get out. Problem solved! But wait – there are situations where the player has to get out of the vehicle. When you disconnect, or the vehicle is destroyed for some reason, you must exit, because its nonsensical not to. Really, the only solution to this is to kill the player when they end up in that kind of scenario. And I mean really, if you’re trapped that bad, you’re probably going to have to suicide anyway. The moral of the story is – don’t disconnect when you’re in a vehicle.

We’ve also had some reports about sneaky people getting under the terrain! Fortunately, it’s pretty easy to check for this and just kill the player.


This week I put the finishing touches on the Map SDK which is now live. This isn’t much use without a tutorial on how to use it, so I’ve been also recording my first dev videos and uploading them to YouTube. Definitely not my forte but I’m sure they will get you started on using our toolset.

Getting the SDK

The SDK is downloaded through Steam under the Tools section of your library. I am currently working with Valve to ensure everything shows up as it should, if you can’t see it now give it a couple of days.

To use the SDK you need to first download Unity 5.3.2 P4. To build maps you need to make sure you tick the Windows, Linux and Mac Standalone support in the installer (not enabled by default).

Usage beyond that can be found in this video series:

YouTube / Hurtworld – via Iframely

The focus on these videos was not to tie up too much of my time editing and rendering, so excuse the roughness. The final part of the quick guide is rendering now and will be added to this playlist tomorrow. I have a new found respect for youtube / streamer fam as I now see how much work it is to plan record, edit, render and upload a video to YouTube!

Infamy Stuff

Going through all the infamy stuff this week was pretty time consuming, I appreciate everyone’s input on the discussion. I feel that writing it out in a blog was useful for myself to lay out the next steps to take with fixing the problems.

I have a pretty clear idea of what approach we need to take, some things pretty drastic, I am keen to get back to working on it as soon as we get the engine upgrades and current patch cycle released.

Server Perf

I’ve seen a few posts about server performance getting pretty shitty on the infini wipe servers. This was expected at some point, we are now 26 days into the wipe schedule, far longer than ever before. There is obviously some areas we need to look at to ensure perpetual servers are sustainable, we will be looking at that this week.

When’s the Patch?

There won’t be a patch this Friday as there are still a lot of things that need testing. The patch won’t require a wipe when it hits, so I will aim for mid next week.


We are big fans of the Skoogler, so I did an extra skin, making a version that gives it a more dirtied up, slightly diseased look. Such a filthy Skoog.


I have now moved on to a new creature, who is sort of a monkey/bat hybrid. Hopefully they will have fast movement and a decent sized leap, allowing them to both chase down players and also attack via leap/harassment. We want to make the critter something that players will think twice about engaging. Potentially making it nocturnal giving it it increased stats or perception etc during the night………….I also think some sort of Howler Monkey esq sounds as they chase players down might be cool.


We’ve been pumping out creatures while we still have our creature animator full time. That role will hopefully be transitioning into a programmer so we can through the bottleneck of game mechanics work.


Not much from me this week. After spending some time in official servers over the last few weeks I have been hanging out in community servers this week meeting players and making contact with server admins. During this time I have been amazed at the creativity and community surrounding the servers I have visited. I have seen events ranging from deathmatches to dodge ball, taken part in a purge and have seen player structures varying from castles to pyramids. It is always great to see the different ways players are having fun in game.

On the other side of the server list I have been monitoring official servers. Last weekend full loot servers went infini wipe leaving 14 day servers as the only servers with scheduled wipes. The next scheduled wipe for these servers is at the end of the week and there won’t be any changes to wipe schedules or server numbers as part of this.

As always I’ll be in and out of servers so if you see me in game feel free to say hi!


Destruction is my name this week. These individual rubble pieces make up the bulk of the rubble. By making a few detailed bits at the start I can then stick them together in a variety of ways to form unique looking piles.



I made 3 Normal mapped blobs of geo after to stick the individual pieces into. I think 3 piles will give a good variety which I can then smoosh together and scatter around to create more individual shapes.



These have turned out quite well. I will be breaking more of the city moving forward.

Dev Blog