Press Kit Wiki

Hurtworld Update #55


This week I’ve been finishing off the missing parts of the gunplay system before pushing forward with deathmatch tests. Results from first iteration (which are things we mostly knew about) are that gun sounds and hit feedback needs a lot of work.

Gun Sounds

In the current version of hurtworld, the assault rifle has a lot of trouble maintaining a steady fire rate. There are a few reasons for this, one is aliasing between our update rate and the gun rate of fire not matching, another is rendering framedrops causing interruptions in the Unity sound engine.

I have an almost working framework for sub frame bullet events which should solve most of those issues, however actually synthesizing very fast firing bullet sounds well turned out to be not as simple as I thought. I managed to get some amazing weapon sound source material this week, which provided both full auto recordings and single shot recordings. To my surprise, playing single shots at full auto speed sounds nothing like the recording of actual full auto recordings (and nowhere near as good).

After some experimentation I settled on using time synced 4 bullet loopable samples scheduled with the Unity audio engine ahead of time, then scheduling early stop times when the player doesn’t actually shoot all 4 bullets of the audio chunk, then injecting the tail end of a single shot or burst shot on the end of the fire clip to ensure it doesn’t stop abruptly.

The only problem with this, is as the clips have 4 bullet fires instead of one, the rate of fire can’t be adjusted by simply playing the fire clip more often. What I tried instead was to dynamically scale the playback speed of the clip to the desired rate of fire so the loop still syncs up. This works nicely, but has one side effect of lowering and raising the pitch of the bullets, changing how the gun feels. For example silenced mp5 at 300 rpm slower sounds like a 50 Cal MG. I will likely build some auto loops at different RPMs and pick the closest, then pitch shift to the exact speed. The other option is to do a pitch constant speed modification to the clips, which I have no idea how to do. And from experience in audio tools, algorithms rarely output anything good without artifacts. The last option is to automatically stitch a bunch of single shots together with volume envelopes to make the blend better, I will have to give this a try to determine if I can achieve the same result as the recorded full auto.

Here is a recording from a realtime Unity project running at 20fps with massive garbage collection spikes happening (to test if the bullet stream is interrupted)


I have continued on with these more basic weapon type for the creature weapons. Getting a whole bunch of weapon chassis designs out so we can then select the first designs that I will end up making. After we decide on some designs and maybe do a little more concept art, we will probably do a bunch of simple grey-boxed models. These will help make sure we have all the pieces in the right places so we can cement the animations.

guns_0003_layer-8-copy-4 guns_0001_layer-8-copy-6 guns_0000_layer-8-copy guns_0006_layer-8 guns_0005_layer-8-copy-2 guns_0004_layer-8-copy-3guns_0002_layer-8-copy-5


This week I’ve been working on implementing water, and iterating through on the map.

I implemented some cool water effects for the camera, so that when the camera is half or completely in a water volume, we can do cool things like change the fog parameters, apply a vignette, and do caustics or other distortions. This requires solving what I thought was a bit of an interesting problem – calculating the intersection point of a plane along the camera frustum. To do this, we need to get the intersection of the near frustum plane, and figure out where on that plane the water plane lies, and so where the transition between above-water effects and below-water effects needs to happen.


I also made some fixes to the water shader to deal with issues of how it looked when the sun was rising and setting, as it was taking far too much color from the sunlight at these times. It now will take more from the ambient when hit at an acute angle.



The map creation has for the past week been a process of tweaking values and figuring out the relationships between issues in the “feel” and play of the map, and the actual changes needing to be made in the map creation logic. To make this easier and so we have a predictable baseline, I moved a large amount of the common logic to shared sub-biomes. This means I can adjust parameters in one place and it will effect all biomes, which should hopefully speed things up a fair bit in terms of iteration.



This last week I finished of the texturing and material setup for a couple of pairs of shorts, then moved onto getting setup with the item V2 pipeline. Following the setup I went through and generated skin mesh attachments for all the new clothing items I have been making.

To do this I drag a skinned fbx file that I have bought over from Maya into the scene.


Then select your desired skeleton via the radial button, and drag your mesh into the target character slot. Click the Generate SkinMeshAttachments from character button which will prompt you to choose a save file destination.


This will result in a skinmesh attachments file which you can select and apply any relevant material to.


Finally select the Character Default Setup in the Hierarchy which will allow you to select and place various skin mesh attachments into their corresponding slots.



This week I’ve been continuing to work on patching up bugs and exploits. A big thanks to all the community members that have been in contact with us helping us track down and reproduce issues.
Some people were still managing to push themselves through things with closing doors so I rewrote the overlap check to use the physics system, resized the colliders to be more defensive, removed any gameobject scaling and also slightly changed the logic that calls the check fixing some client side bugs and adding the overlap check to the client as well.
We also got some good reports with video about using the crash vehicle to glitch into rocks when getting up. I found a bug where the stand up overlap checks were slightly smaller than the character collider so I’ve fixed that up and also added an additional check using the same method as ownership stakes to see if the exit position is inside geometry.
I also fixed a ui bug where scroll windows weren’t resetting properly meaning you could scroll past some categories of crafting while using a workbench and then when you went into the handcrafted menu they wouldn’t be selectable.
I’ve also extended the radiation zones in the salt flats of Diemensland so you can’t hide in the corners of the map anymore, if you’ve got a base there you’ll want to move out before these changes go live.
Right now I’m working on adding some additional checks to the character controller when it interacts with physics objects pushing it around to make sure the character controller is still in a safe location and rewind to a previous position if it isn’t. This is the major blocker for the next patch so once I’m finished with it we’ll be ready to go.

Hurtworld Update #54


This week I made a lot of progress towards a public deathmatch build. This involved updating the ragdoll system to use the new character mesh baking system, speeding up the transition massively. I also brought the gear equipment system (non hotbar equip) into the current century heavily simplifying how it works.

During this process I started running into one of the first big challenges of actual ItemV2 use, where each client doesn’t know about every item ahead of time. In the old architecture, items were represented by id codes + stack sizes. When an item is equipped, everyone needs to know some information about it, what meshes to attach to a player model, how to modify the players stats on the server, how to simulate the item on the owner etc. In ItemV2, items are created on the fly, meaning that at some stage clients need to be told about the definition of an item, and also notified when it changes (by adding a scope for example).

If an operation requires an item to progress, its quite easy to run into race condition scenarios where the client knows it wants to equip item 23422 but doesn’t know anything about it. To solve this problem for all future cases, I implemented a system that can lazy load items from the server. If a client needs an item before its ready, the item manager returns a dummy item, tells the consumer that the item isn’t yet complete, and then requests the full definition from the server. In a few frames when the full definition comes in, the item manager fleshes out the instance that is already held by the consumer and notifies anyone subscribed that an update has occurred. This works quite well, and will save us heaps of headaches in future.

I spent the end of the week working through all the deployment issues around our new build architecture. Everything is much more modular, allowing mods to remove default configurations for almost anything in the game and replace them with custom content. Due to the structure changes, and the fact that this branch I’ve been working in hasn’t been built properly for 5 months, this took a while to get everything working again.

Today we got the first internal test build up, not only running ItemV2, but the new Nullius map.

Its pretty barebones right now, but we will be looking to open the experimental build up to the public in the next couple of weeks.


This week I’m back into developing the map and getting ItemV2 up to scratch. I’ve fixed up and brought across things like ambient sound tracks, ambient particle effects and localized visual biome effects. You’ll be able to specify custom ambient tracks for both day and night, as well as particle effects and other effects.

The map itself – which has the working title “Nullius” – is coming along well! I’ve been playing around with the layout, and currently it’s a number of islands surrounded by water. This has meant I’ve had to jump back in to water in Hurtworld, which is a bit of a rabbit hole, but luckily there are a number of tools out there that should get us 70% of the way there. The problems that still need to be solved is allowing for multiple Levels of Detail so water doesn’t kill lower end machines, creating a underwater camera effect, and figuring out how the player should interact with the water. We’ve been thinking about doing it as a vehicle that you enter whenever you get a certain depth below the water. Hopefully what comes out of this is a general water system that you can use in all your custom levels, for whatever you want, that performs well.


To this end, I’ve been playing around with tools like AQUAS for the shading side of things, and looking into mesh generation. Water is mainly limited by fill-rate, which means we need to aggressively cull rendering of the water.


The two packs are all baked out and textured. We now have two different sized packs. A large military/camping styled pack, and a smaller crumpler style one. Both will be paintable in some fashion. Next for me is baking out and texturing the shorts, then moving a bunch of this newer gear across to the dev branch for testing etc.









I’ve continued to explore the shapes and materials that we want to use on the Creature weapons. Now that we have a fairly good array of variation in design elements, like switches, batteries, capacitors, grilles, vents & other components, I am now going to focus on knocking our some more basic shapes for the weapons. The first 3 images follow on from the previous weeks concepts. The last two images show some simpler body shapes that would then, when modeling have these detailed elements added to them. I can speed up the concept process to get more body types designed in a shorter time period.

pumper01 magrail01 pistol01

Below: .22 caliber machine pistol.


Below: SMG body type.




This week I was working on finishing up the update.
Thanks to bug reports on the steam forums I was able to patch up a few more exploits. There was a bug where Goats and Kangas weren’t checking if doors were blocking a player’s entry to the vehicle allowing a pretty nasty exploit where you could position the vehicles right up against a door so when you entered the upper half of the player’s body would be through the door which would instantly trigger a crash due to the collision but the position of the body would spawn the crash vehicle on the wrong side of the door granting access to the base. I’ve fixed this so doors properly block entry to vehicles as well as adding an additional raycast check on crash vehicle spawn that can deny a crash if the crash vehicle is going to spawn in an illegal location.

Whilst working on the rock bases I also took a look at how people were using doors to push themselves inside of rocks. We run a check when the door is closing to make sure there are no players in the doorway and then reopen the door if it is blocked. I found a couple of bugs in our overlap check where you could stand in certain locations to ‘dodge’ it so I replaced it with a more defensive bounds check which should make this exploit a lot harder to pull off, if you find situations where it’s still possible please let us know!

Speaking of rock bases I also added a change where ownership stakes now check if they are inside a rock on server startup and destroy themselves if needed, hopefully some of you were able to get some revenge after the patch went live, unfortunately we couldn’t announce this ahead of time and give an opportunity the rock bases to prepare.

After the patch I spent the rest of the week merging the latest changes into our ItemV2 branch and started getting vehicles working again under our new gear simulation system.
Unfortunately today though we’ve noticed some more issues with the current build so i’ll be back to bugfixing for the start of this week so expect another update soon.

Hurtworld Update #53


So before jumping on to back packs, I went about taking a couple of Marvelous Designer shorts through the clean up process. I ended up with a pair of basic shorter shorts, which could have a thin-ish feeling type material applied to then, and a pair of longer shorts that could have a slightly thicker feel of denim, or like cargo shorts cotton etc. I will bake and texture these up upon approval.



The first backpack I have built is a smaller nylon type pack, next up is a bigger almost army type pack.





Larger backpack sculpt



After  almost two weeks away, we are back in full swing. Dev Days was a really good experience, I learned a lot of interesting stuff, which hopefully we can use to further our game design. The part I really liked was a talk given by a Valve employee Mike Ambinder about the Psychology of Games.

So I have 3 new concepts for the Creature Weapons to show you all. After looking at our game and thinking how these guns would look compared to the rest of the game and also how they would feel when used, we decided to tone back the designs to things grounded in a modern-ish reality. Also a reality that relies partly on scavenging and repair.

The original designs were a little too sci-fi and also we wanted them to have tactile feedback that you can relate to and feel like you are really firing them (lasers are hard to give these attributes to). This is always appreciated by the player, as it gives that feeling of a huge force being unleashed as you shoot each weapon.

So I have 3 body types shown below that will have different component sets. The 3 bodykits you see for example could be classified as one complete set per gun. We want to use the same animation sets where possible, removing the need to animate a whole new set with each ‘hold’ configuration.

So the Pistol will have the same animation set and so would the other two. We will create the other visual components with the same sized interactive pieces. For example the ammo clip will always be the same size, so that the hand, when reloading will always go to the same spot on the weapon and grab an object the same size and move in the same way. The object itself will look as different as we can make it within these constraints.

Also note, the main Blue/Grey areas on each weapon would most likely be the designated area for ‘designs’ as seen on the vehicles.


Above: The Pistol Body Type


Above: The Mag Rail Body Type


Above: The Pump Action Body Type



We returned from Seattle this week and I’ve been fighting jetlag and working on the next minor update.
I’ve been working on improving vehicle reversing behaviour, to limit reversing speed currently we are directly reducing the acceleration force.
This works well enough for limiting speed but has introduced a new problem where there is no longer enough force to reverse up hills once they get steep enough.
In the next update rather than limiting the force directly, we sample the acceleration curve using a reverse speed percent that is roughly 1/5th of the standard top speed. This allows the same force output as acceleration at low speeds with a much quicker falloff meaning you can reverse up hills again but top speed will still be limited.
Here’s a visual example where the x-axis is the inverse speed percent (ie. (1-speedPercent) so at a stop the value is 1 and at full speed the value is 0) and the y-axis is the normalized force (ie. percentage of maximum acceleration force delivered).

The other major change for this update is more fixes for rock bases. For the Kanga patch I was too hasty declaring the end of rock bases and I apologize. Whilst we made it harder to plant ownership stakes inside rocks there were some bugs in our technique and it was still possible to get stakes down inside rocks usually in spots around the edges where our raycast checks weren’t working like expected.
I’ve fixed up this bug in our logic and it should be even harder (hopefully impossible) to get those stakes down inside rocks. Please keep making noise about the problems you see, we are reading the forums even when we don’t have time to reply.


Back into the swing of things, this week I’ve been ironing out the last bugs in ItemV2 ballistics hit and verification code, added back in the muzzle flash.
I added a new impact feedback flash that ensures you can see where your bullets hit in any range in any light. It doesn’t particularly make sense, but I think the feedback is crucial for the feel of the weapon.
My testbed seems to have turned into a Salvador Dalí painting recently. Can’t say I hate it 😉

I also added a hit/flinch layer to our player animations to give better feedback when a player is hit by stuff

Ranged projectile claiming and verification are back to baseline and applying damage once again. The plan is to have it up internally this week and push out a deathmatch only build to the devtest branch next week for you guys to have a play around with and give us some feedback.

Dev Blog