Press Kit Wiki

Hurtworld Update #74


Hey guys, so this week we decided that a character update was not a priority as it would have been a whole lot of work to get to exact same point that the current character is at. After coming to this conclusion we decided to move onto gear creation and a tactical vest seemed like the perfect starting point. This is the first pass on the vest, a lot of things are still just place holders and need proper cloth folds and seams but so far so good. After trying out the new Zmodeler tools in Zbrush I’ve realized that I can build something like this almost (if not) entirely in one program, which can really speed up my work flow and allow me to build stuff like military gear and other clothes faster than ever before. Going to run some tests in the next day or so to see how well something like this will look in our game environment.



I was working on the ‘DLC” (Diemens Land Crew) graffiti skin last week, but we decided to switch gears and get all the current attachments done for the AR15. This will add a second attachment for all the slots on the gun and will help with balancing and development of the attachment systems. This will let me go full steam on model production. I am at the UV layout stage of a second Barrel Guard and should have the baking and texturing done tomorrow.

NewGraphicShader_0000_Layer 3

I added a couple of cable ties and dents to break up the large flat surfaces of the new guard.

NewGraphicShader_0001_Layer 2 NewGraphicShader_0002_Layer 1


Hey folks. This week I’ve working more on realtime icon rendering, and it’s coming along pretty nicely. A lot of optimisations and neatening up of the architecture have happened so things are running faster.

A recurring problem has been the handling of caches for these assets. If you ask an item what it looks like often, it’s better to save that information somewhere rather than making the item do work every time. This means that you want to tie that item as a key for some data object as a value. I wrote a little data structure that does the job pretty well, as a limited-size dictionary. You can just set the maximum size of the cache, and what it should do with elements that it pops out the back (like properly releasing RenderTexture or Mesh objects). It has a concept of when items were added, so when the cache gets too big it releases only the older objects. It’s pretty handy and it’s formed the backbone of both the data on how to display items, and the actual render textures that each itemslot is pointing to.

I also vastly improved the auto-zooming functionality for item rendering. If all you want is for the item to be rendered at a certain angle and you’re happy with automatic zooming, you can tell the item renderer to just try and find a best fit of the mesh. Previously I did this by placing the camera right at the origin of the mesh, and then iterating back, testing the camera planes every time to see if I was zoomed out enough. However, this just wasn’t fast enough. Although I managed with some optimisation to get it down to only around ~10 iterations, the basic math was just too expensive, so I came up with a different tactic with some nice trigonometry, you can see it below. As a tip for any game programmers – when solving geometric problems, start in 2D!


So you can see the result of this below – some procedurally rendered item icons and world items! Next up is adding effects and animations to items that need them, which will be an interesting job to do quickly. There are still a few issues to iron out with icons around getting the render texture to the UI without the blurryness and aliased edges, but most of the hard work is done.




This week I’ve been finishing up work on the patch mostly which is rolling out as I write this, you can find the patch notes in game or here.
Thanks to everyone reporting stuff, you certainly are keeping me busy! We received many reports regarding a crouch desync bug where the server and client could get their crouch states mixed up. This would then lead to client predicted movement always being wrong and having to be corrected and players were in turn abusing this to be able to briefly look through walls and scan other players bases. Luckily we had a fix already implemented in itemv2 which was faster than expected to transfer back into the live branch. Now crouch state (and camera perspective) is properly serialized and synced across the network rather than trying to derive crouch state from player input and other data.

Another fix I worked on was removing a bug where the emote manager could get out of sync. Previously after some chaotic spamming of an emote it was possible to get an extra ‘StartEmote’ trigger that hadn’t been used yet whilst already being in an emote. This meant when you went to exit the emote the left over trigger would fire immediately after leaving the emote animation, returning you into the emote animation but unlocking all movement and allowing you to use equipped gear (like fire your guns). Now this trigger is explicitly cleared on emote exit.

The other big change in this patch was removing rigidbodies (Physics objects) from many objects.
The character controller component that we use for player movement has an easier time resolving collisions against static colliders (objects without the rigidbody component that enables simulation) so we’ve removed rigidbodies where we can to hopefully reduce players being able to penetrate through solid objects like storage chests. In older versions of Unity you needed to have a rigidbody on any collider that would move but now we only need them on objects with actual physics simulation (like vehicles) or if an object needs to be able to set off triggers (like the player). Another plus is that not having rigidbody means moving and rotating object has less of an overhead so we should see some small performance improvements from this change also.


This week I’ve been experimenting with the best ways to structure our content and thinking through the new ItemV2 progression. There is an enormous amount to think about here, like what creatures spawn where, what properties do they have like speed, damage, colors, size, rarity, health etc. Then once they are killed, what they drop, how much they drop, when they drop a recipe, how much of what resource that recipe should cost, what environmental effects are trying to kill you in each area, how loot from creatures of that area can be used to counter such effects, how those resource should scale up as you progress into tougher areas.

Resource scaling can be approached from a couple of different angles, by increasing volume output and volume requirements (eg: tier 1 boar drops 1 leather, basic clothes cost 10 leather, tier 2 boar drops 10 leather tier 2 gear costs 100 leather), or by changing the actual resource as you tier up (eg: tier 1 boar drops leather, tier 2 boar drops 1 Amazing Leather).

After trying to design all this stuff using spreadsheets and difficulty curves, I’ve gone back to basics of throwing a bunch of stuff into game and playing around with it till it feels right.
There are too many variables to think about at once to get interesting synergies between parallel progressions.

Right now I am testing a build where Shigi’s are basically slot machines, dropping blueprints to upgraded bows that hunt shigis better. Once I get something together that has the magic fun element to it I will put it up on experimental.

I spent half an hour dicking around with the gun painting system now that the AR is mostly complete, here are some glory shots!

Pasted image at 2017_03_21 08_32 PM
Pasted image at 2017_03_21 08_54 PM
Pasted image at 2017_03_21 09_13 PM

Pasted image at 2017_03_21 09_00 PM

Pasted image at 2017_03_21 08_33 PM

Hurtworld Update #73


This week I’ve been focusing on content design, implementing more of the procedural stat wishlist and refining the weapon feel. The bow in the current public Hurtworld is awesome, its a lot to live up to for the ItemV2 version, since the upgrade the bow hasn’t quite felt the same. I spent a few hours refining it and found a few bugs in the way we do projectile direction calculation and drawback speed.

Part of the ItemV2 weapon system is the ability for a weapon to specify a custom camera configuration for different stances and sighted states. I spent a bit of time creating a custom one for the bow in third person, and the results feel awesome (Note the accuracy of the third person cross hair now matches that of first). I will probably use this as a base for all third person weapon cameras.

Next I implemented the stat wishlist for bows, most notable of which is the rare chance to get a bow blueprint with bonus projectiles on fire.

The number of bonus projectiles and the spread pattern is all stat driven, don’t think we will go crazy with this but might make for some interesting mods.

While I was at it, I decided to give my new projectile system a bit of a stress test. Most of you would know I am pretty OCD when it comes to performance, and the new projectile system is one of the jewels of ItemV2. I set the bow to distributed circle pattern and set the extra projectiles to a ridiculous count of 500 per shot. Expecting my FPS to tank, the results were amazing. FPS drops barely even register at 1000 projectiles in the air. Also notice that there is very little additional network traffic happening (and all projectiles are server authoritative). What this means for you, is even on shitty PCs, you can trust that you’re FPS won’t tank in a firefight (at least not because of gunshots).


This week I’ve been continuing on with work on the spawn window. Now it’s up to the game mode if it uses the spawn window, when it uses the window and what the window does.
I’ve also improved how you access the spawn window, in a compatible game mode you’ll be able to open the spawn window from the main menu to make changes which will apply on your next spawn. Rather than showing the spawn window on every respawn there is an option (if the game mode chooses to use it) for the UI will now show a small prompt to open the window if the player chooses, if not they will spawn with previously chosen options.

Thanks to player reports I’ve also spent some time investigating some bugs from the last update and working on another small fix patch. This will include a fix for plant construction being incorrectly denied, fixes to the desert aircraft carriers collision mesh which was making it impossible to get up from a crash inside it and also causing it to incorrectly set off the inside rock check killing the player.
Another bug was discovered where if you crashed with a vehicle on top of you in a certain configuration you could stand up inside the vehicle which was leading to all kinds of crazy behaviour. To address this I’ve changed the ‘can get up?’ check on crashing to include vehicle colliders, this was a little tricky as crashing is implemented by placing the player inside an invisible ‘crash vehicle’ so the crash vehicle needed to become aware of its own colliders and check that any colliders preventing the player from getting up weren’t from the crash vehicle itself.
I also made a change to the movement rewind system due to some of the crazy behaviour we witnessed with this bug. Now if an illegal move is detected, vertical velocity is set to zero (as well as the position being reset to the pre-move position like before). This fixes the craziness we were seeing where if you were stuck inside a vehicle on the server you could fly around a little on the client because it was trying to predict from the corrected state using the old pre-rewind velocity. This also flows on to improving player to vehicle collision resolution in general which will help again in the fight against rock bases.


I got the Silencer and Red Dot Sight finished this week. They are looking purdy. Now I will start to add the designs to them and push on with some more complete design sets. I will rework the ones I did for testing also, making sure to put the finishing touches on them. I did a little more testing with gradients on the Colour Mask Overlay shader, which turned out pretty sweet.

SilencerRedDot_4 SilencerRedDot_6 SilencerRedDot_5 SilencerRedDot_3 SilencerRedDot_2 SilencerRedDot_1 SilencerRedDot_7


Not much to report, Still sorting out the work flow for the characters, after figuring out how Unity handles normal maps I’ve had to make some changes to my workflow, with these changes I will be able to get assets through the character pipeline much more efficiently.


Hey folks, this week I’ve been working on a new system for rendering icons. Currently icons are just little sprites that we make ourselves, and that’s worked up until now, but with procedural dynamic items on the way it’s become obvious we need something new. I’ve been working on something to enable any item to be rendered in the UI as a little item sprite, as well as putting together tools for dynamic world-item creation.

So the first issue is dynamically generating all the data needed to render an item. The workflow I’ve been setting up goes a little like this: Firstly, in the SDK, you configure how items or generators set up the player skeleton and render camera, in order to render out the item icon. To do this easily, I built a little mini-mod loading framework that you can use in the SDK, so you can load the game’s assets and your own to set up this configuration. You pretty much select the character that the item is going to be used with – usually the player – which will generate a skeleton. You can then position and distort this skeleton however you’d like, in conjunction with setting up the camera to the right angle, FoV, etc. This then generates a little configuration file that items can point at and say “this is how you render the icon of me”.

As for the actual rendering, there’s going to be a little extra camera working under the hood to do renders of items and push out RenderTextures. Generating the mesh to render these texture with is an interesting problem, especially because optimally we want to use this same mesh to create a world-item. We’ve got to get all the meshes, distort them with the skeleton we made in the previous step, and then bake them out into some static representation. The tricky problems are going to be managing our VRAM allocation, safely disposing all of these managed objects (textures and meshes are never garbage-collected in C#) and being able to create the world-items of a shitload of items and render them all in a short amount of time. You can see the little proof of concept I got working today below, but there’s plenty more work to get it to a finished state. On the plus side – you won’t need to make icons for all your custom stuff!


A lump of coal and a dick crate! #progress


Hurtworld Update #72


I worked with Spencer testing the new Custom Masked Colour Overlay Shader this last week, and man is it coming up sweet! Spence built in material overrides based on the alpha of the mask (RGB) texture. We can now specifically change the properties of the mask without affecting the base texture. This lets us change the surface properties of the graphic mask area. We can make the graphics look like glossy paint, matte paint, metallic paint, rubber, metallic foil and probably some other substances too. The level of override can be turned up or down too, so we can simply inherit the original surface information and only override the colour information.

Really happy with the control level I have with this. Spence was kind enough to make the shader suit my art brain by changing the layout of it so that it makes sense to artist types. I also got the high poly modeling, UV mapping and baking done on one of the Red Dot sights, so that will be finished Monday. I’ll move onto a Silencer and that will make one complete set of components. After that I’ll be making a full set of designs/skins/masks for the completed set, after which I’ll be out of R&D land and ready to steam ahead making all the other guns/skins. I expect this process to speed up now that the development of PBR materials and the Custom Colour Overlay Shader are mostly done.

Shader NewGraphicShader_0003_Layer 1 NewGraphicShader_0001_Layer 3 NewGraphicShader_0000_Layer 4 NewGraphicShader_0002_Layer 2


This week has been spent trying to get the character to look good in game and dealing with some design challenges. Once the process for the first character is worked out then all the others can be added in game almost stress free. The female model is very much still in the works but it makes more sense to finalize the workflow for one character and then transfer that workflow to all the others as mentioned previously.


Hey folks, this week I’ve been working on sights, specifically a sniper scope and a holographic laser sight. The sniper scope came out pretty well, and allows for easy customisation of how it appears on screen by mods. You can set when the scope engages, what the sight looks like, and more! There’s a random sighted sway that players will be forced to correct a bit for, but it’s stat driven, meaning that you will be able to craft better snipers that sway less when sighted. There’s also an initial rotation when sighting, which is always the same for a given gun, so you’ll be able to get a feel for a gun’s randomness and learn to correct for it.

I also implemented a holographic red dot sight, which was an interesting little exercise in shaders. A holographic sight, for those not in the know, is a sight that shows a cross hair that is projected in the distance and displays parallax. The advantage of this is that you are able to determine the angle of the barrel, as long as you’re roughly looking down the sight. I started off trying to mutate the UVs based on the camera view angle. While this worked pretty well for a simple mesh with the origin at the center, the math got a little complicated when we were dealing with meshes with offsets. After a while I decided to take a different approach, which was to take advantage of Stencil Shaders. Stencil shaders are pretty cool! They are pretty much a buffer that you can read and write with arbitrary values. With this tool, holographic sights become a way simpler problem. All the current shader does is do a first pass that writes a number to the stencil buffer, which acts as a “viewport” for the holographic sight, and then a second pass moves the vertexes some amount in some direction, and render it again testing against the stencil we just created. This works great for all meshes, and is a million times simpler. Check out a clip below:


Bit of a short one for me this week unfortunately as I’ve had to take a few days off whilst sick. Good news is I’m all better now and ready to get stuck in again.
What I did manage to do was some work on the new spawn system. Previously as soon as you joined a server and loaded the map and game state you would be instantly spawned into the world. In ItemV2 you’ll be able to customize your character (picking different skins, hairstyles, facial hair, faces etc.) and logically at least the first time you join the server you’ll want to pick your options before you spawn in.
A lot of our initialization code was tied to the player spawn so I’ve had to decouple that and create a new game state that represents the client being fully loaded but their player entity hasn’t spawned yet.
Now we can have the client load everything and be presented with a ‘spawn window’ where they’ll pick their options then request a spawn from the server. I want to make this window customisable so other game modes (like deathmatch) and mods could implement things like picking loadouts or spawn locations but for right now I’m finishing up getting the technical side of things working on the back end, squashing a few bugs and making sure the camera starts in the correct location rather than transitioning in from under the world like it does currently.


Have been all over the place this week. I’ve been working on content implementation for the AR, sniper and pickaxe including a workflow to create items in an already fleshed out state for nested items. For example, the AR15 blueprint will spawn with some stock parts attached (so you don’t end up with just a receiver), then allow you to replace / add more later once crafted. This required getting doubly nested items working (blueprint->ar15 root->barrel etc) and allowing nested hierarchies of items to be cloned. This came out really well.

I also spent a bit of time on some painter shader experiments with Mils to allow paint masks to override more than just albedo color on the weapons. This will give us an insane amount of variation on the weapon customization.

Lastly I’ve been tracking down bugs in the item serialization system that was causing items to disappear / get bogus stack sizes, and fixing our shadows in ItemV2 which had regressed horribly.

As always we are getting dangerously close to building some actual gameplay, these tasks suck but its better to sort them now than hand you a broken mess later. Hopefully I have more time this week to get stuck into content uninterrupted.

Dev Blog