Press Kit Wiki

Hurtworld Update #68


This week I finally implemented the dynamic item generator framework as the final system needed for procedural loot. What this does is control injecting random properties into item definitions on creation based on difficulty and rarity of the creature that was killed, and of course randomness. Its sematically similar to CowTrix’s creature mutator system and will be fairly similar to configure.

My test item isn’t very exciting, but shows 5 copies of the same item with different random properties applied to it on creation. Variations on the pick include colors, attack speed and mining power. The paintable pickaxe is a rubbish programmer art test also, but it proves the concept ready for proper content. The thing that stands out most here is the lack of an item icon renderer that shows any difference between them, its on the list of things to do, but for playtesting its not needed so I’m putting it off.

From the SDK side, the randomization of items is configured like this:


Also Mils spent a bit of time making some awesome icons for our SDK, so our custom types aren’t all just white squares anymore and you can actually tell them apart.


This Week

Today I’ve been putting together the blueprint system so that loot sources can drop a procedural items blueprint, you can decide if you want to craft it based on how good it is / if its an upgrade then load it into a workbench for limited uses. I should have that going by mid week, we are hoping to have an ItemV2 super rough prototype RPG progression test build up, with procedural creatures + loot working together for the first time internally by Friday. If this ends up being fun at all, I will push it out to our experimental branch and you guys can check it out.


This week I have mainly been working on allowing us a to spawn variety of enemy types via the custom colour shader that Tom has mentioned previously. This involves isolating sections of the albedo texture via a RGB mask and allocating the strength that the RGB mask has on your texture via the alpha channel.

RGB Mask example.


Example of an Alpha for the RGB Mask








Forest Shigi







Hey folks. This week I’ve been fleshing out the spawn building, fixing a few bugs in the HurtDatabase, looking into some possibilities for creature scaling, and setting up some temporary gating mechanics for creatures so we can test progression. Work was a little slowed by a big reorganisation on Tuesday, but we’re back to 100% now.

Spawn builders – the thing that takes a spawned object like a creature or a resource node, and changes it to fit the environment it was spawned in – are now a lot more fleshed out and easy to extend. I spent some time moving them across the Spencer’s generic value generation stuff, added in support for changing mesh attachment colors, and they are pretty much ready for content generation.

I’ve been looking a bit into exactly how we can gate harder creatures for players, so they have some kind of gear-check or skill-check. This led me to find a couple of issues with how we were using EntityStats on creatures, mostly with them being entities that didn’t think themselves for performance reasons and so more complex operations didn’t work with them. I implemented some prototype concepts like armor (player’s must do above x damage to a creature for it to apply), health regen that can stop when the creature is getting attacked, and a real temporary gating mechanic which pretty much means if you attack a creature above some magical number, you get killed real bad. Now emphasis on all of these is temporary, it’s unlikely that the real creature progression will work like this, but for now it gives us some temporary levers to pull as we figure out what the item, crafting and weapon progression looks like. I’ve pretty much just laid out a gradient of difficulty in a test level, to try and crunch down the game into as small a physical space as possible to focus purely on mechanics.seantest


This last week I’ve been finishing up the patch that was just released. As well as the rock check fixes I talked about last week I also patched up a bug in player to player collisions that was allowing people to see through walls. This occurred because we had a slight mismatch in character collider sizes where the colliders of other players clientside were slightly bigger than serverside. This meant when running into other players the client would stop before the server where it thinks the player collider is but then because of our server authoritative netcode it receives a correction to where the server collides. The problem is this ‘corrected’ position is now inside the other player which stuffs up all the collision checks being made during clientside prediction allowing players to run briefly through walls and other geometry before getting a correction from the server.


I also finished up the model viewer changes to allow previews with any characters implemented under our new mesh attachment system (players, ai and vehicles). It also can preview any animations assigned to the character and recolor any colorable attachments that have been setup, this allows you to preview content without having to rebuild your mod pack and load it in game.


I got the normal baking and 90% of the texturing done on the AR15 Receiver this week. The baking went fabulously, thanks Handplane Baker! I switched to this a little while ago because while XNormal is great, Handplane Baker has some time saving features. Everything baked out without much fuss. I moved onto the texturing and got most of the way there. Smart materials in 3D Coat are performing smoothly. I also added a few variants of custom plastic smart materials to my tool set, which were used on the AR15’s Grip.

Mmm metally….

AR15Rec_0002_Layer 3 AR15Rec_0003_Layer 2 AR15Rec_0001_Layer 4 AR15Rec_0000_Layer 5 AR15Rec_0004_Layer 1

Hurtworld Update #67


This week I’ve been fighting against rock bases again, getting a patch ready that will be released in the next few days and will be followed by a full infini wipe on Friday the 17th of February. We received some reports that rock bases are still around so I did some investigating and it turns out there is a very narrow edge case where the ‘am I inside a rock’ check fails when checking an area overlapped by multiple rocks. To deal with this edge case the check first scans through the raycast generating a list of expected colliders, after the standard raycast is complete it checks to make sure all expected colliders were hit, if not it runs the same raycast explicitly against the missing collider/s (ignoring everything else), adding all hits to the original hit count (the method counts hits going in and out of the rock and compares them to determine if inside).

That will hopefully solve the problem of players placing ownership stakes inside rocks but we also need to stop players getting inside the rocks in the first place. I don’t want to spill the beans about this just yet until the fix goes live but we’ve identified 2 ways players are doing this and developed fixes for both.

On the ItemV2 side of things I’ve been working on improving our model viewer, making it more generic so it can load more than just the player and also working on the ui so you can see what mesh configs are attached, adjust any custom color channels and quickly enable/disable visibility. I’m also adding search windows in for selecting mesh attachments to preview without having to build an item or a mesh config group.


I tweaked the metal smart materials in 3D-Coat last week, they are looking fii-ine. We may still tweak these, but they are getting really close and so is the workflow needed to reproduce this over all the guns. I did a lot of organising and folder restructuring of the assets in the project and in my personal working files, which was necessary so that I don’t end up in file chaos hell. There are a lot of parts and construction files that go into the guns, so now that I have something I won’t get lost in I can press ahead.

I also worked on the AR15 Receiver (Main Gun Body) Hi poly mesh and got that done on the weekend. I will be UV mapping and then baking in the coming days. Can’t wait to see the new materials on this. 😀

Note; these are renders of the Ironsight out of 3DCoat are at 4096 texture sizes, and while the in game guns look great they won’t be quite this texture density.

IronsightsWitnessMetal_0005_Layer 4 IronsightsWitnessMetal_0004_Layer 5 IronsightsWitnessMetal_0003_Layer 6 IronsightsWitnessMetal_0002_Layer 7 IronsightsWitnessMetal_0001_Layer 8 IronsightsWitnessMetal_0000_Layer 9

The AR15 Upper & Lower Receiver High Poly. Added a few dents and some repair work to add life to the mesh.

IronsightsWitnessMetal_0008_Layer 1 IronsightsWitnessMetal_0007_Layer 2 IronsightsWitnessMetal_0006_Layer 3


Good progress on the new progression this week. I implemented durability that can be applied to any item and extended item slot UI functionality to allow any item components to feed data into the progress bar (in this case used as a durability meter), and also for items to request that an icon overlay be displayed in a modular way. This will come in handy when we have items with things like battery power. I’ve also been thinking about moving item transitions into using this system to make things like cooking and going moldy easier to read in the UI.

Here is the system in action (with drastically accelerated rates of wear):


This week I have been finishing up some of the hair/beard sets and making sure all the separate eyebrow meshs/mats work as intended. I also wrapped up the Harem Pants.


I have also been going through the project and tying up loose ends, making sure that assets are in a finalized state and without errors. Removing, renaming, or replacing any such items. As well as making sure that work files and some archived older work and in game content share naming conventions.


Hey folks. This week I’ve been working on dynamically spawned entities. Before, when we spawned an object we would spawn exactly that object with no changes or randomness. A Shigi is always a Shigi, with the same health, texture, mesh, behaviour and so on and so forth. However, as discussed last week, we want spawns to be a lot more dynamic, different and diverse. Some Shigis should be Legendary Shigis, some should have crazy textures, or some mesh attachment, or anything like that. Diverse dynamic objects make for an interesting world. It also means that we’re dealing with way, way fewer prefabs as we don’t have to make an entirely new one to get some variety in objects.

So how this has ended up working is we give a builder object the difficulty the object was spawned with, a seed for making random decisions, and a rarity (things like Common, Uncommon, Rare, etc) that will all influence which object is spawned, what it looks like and how it will act. This has evolved into a pretty fully-fledged system for making these kinds of decisions. For instance, we can occasionally spawn Rare or even Legendary creatures in areas that are difficult enough, that have higher health and attack but drop way better loot. Check out an example of how we can mutate the Bor over harder and harder difficulties!

Itty Piggy -> Boss Hog

Itty Piggy -> Boss Hog

I’ve also been moving the creatures over to the new MeshAttachment system that the player uses for gear, that the rest of the team have been using and building for a while. We currently don’t have any art assets that take advantage of the system, and really we only swap out materials at this point, but it’s a step towards creatures having attachments that can distinguish and individualise them.

Hurtworld Update #66


This week I started off working on fixing up how our variable item state is communicated to clients from the server. There were a few issues where our old item authority system didn’t quite give us everything we needed for determining who needs to know about an item. Previously, if you couldn’t access the storage that an item was in, you didn’t really care about it. Now we have situations where another player is wearing an item, and its properties change how it looks. In this scenario we have a second criteria for eagerly sending variable item state to non authorized players. To get around this, I came up with a memory efficient system for determining if a client already has the most up to date version of an item from the server. Then when an item is equipped on a character (this includes vehicle parts), we send its dependent state to all other clients that are subscribed to the characters network lod cell (aka are near it). This is the last roadblock for paintable gear that Tom has been working on.

Modular AR Implementation
I also implemented the first modular weapon using embedded items. The UI stuff is all pretty placeholder but it allows things like silencer, sights and magazine mods to be added to a weapon, and some removed. While I was at it, I improved on the item context menu system a bit and added the ability to unload a weapons ammo.

I’ve now started work on the durability system workflow in prep for the proper ItemV2 loot hunt / progression prototype. I’m hoping to have something very rough ready to play in the next week.


Heya everybody. This week I’ve been working on the spawner system, implementing the changes and logic that Spencer and I discussed in our blogs last week. The problem has been an interesting one which I thought I’d briefly discuss.

Now the first question to ask is what properties we want our spawning system to have. Well, firstly it needs to be predictable – a given density map should output roughly the same amount of spawned objects over time and over server restarts. Secondly, it needs to be fast and scalable, as a large map can have up tens-of-thousands of spawner cells that need to be updated in a timely enough manner so that the predictability requirement is upheld. Thirdly, it needs to be unpredictable on the micro level. This is a new requirement that is necessary because of the fact that multiple spawner cells with a free density less than 1 can “share” spawns. With this requirement, removing an object from the spawned objects (say by mining a rock) should mean that the spawner shouldn’t always put a spawned object back in the cell it was, but also try to place it in other areas.

First, a quick rundown of how the spawner system works. Obviously, we only spawn objects where players are in a server, for performance reasons. We split the world up into cells, and pass our spawning system a list of cells where players are doing stuff, and the spawners should be active. Then, we update the spawner cells in that player-activity cell so that they can spawn stuff if they need to.

So this is one of those problems that turned out to be a sort of different problem once I got into it. Collecting many spawns with <1 free space all together to “share” a spawn is basically a packing problem. You can sort of see what I mean with the image below. This is a grid of spawns with 0.5 density that therefore have been paired off by the spawner and colored the same color. The little white boxes are spawned objects. If a square is grey, there are no spawns in it.


So obviously we could pack the previous image better, to eliminate those 3 empty grey cells. But unfortunately, our 2nd and 3rd requirements prevent doing this. We don’t have time to try multiple packing configurations to try to minimize empty spaces, nor can we always pack optimally as we need the result to be semi-random. This means that actual spawned numbers of objects will always be slightly lower than the expected result. For instance the image above has 49 cells with 0.5 density, and spawns 22-24 objects when we might expect an optimal 25. I think this slight low-balling is a unavoidable side-effect, but I might be wrong. If I am – let me know!

Next up on the new spawning system is making the actual spawn smarter off the Difficulty value that’s passed to them – making creatures harder, resources rarer, and all that stuff! More on that next week.


I have been testing PBR textures this week and ironing out the kinks in some new baking workflows I have been trialing. I am experimenting with a mid poly mesh workflow with my normal map baking. This means instead of starting with a low or high poly mesh, I start in the middle which lets me add or lower geometry for the respective models. This I hope will speed up the baking process on the large quantity of bakes coming as I move toward texturing the guns. I find that fixing geometry on the low poly mesh which has a lot of triangles (due to the nature of hard surface modeling) takes a fair amount of time. I feel that a mesh that still retains mostly square poly’s will be easier to turn into a high poly version.

I’m continuing to work on the PBR materials, especially the black oxide coated metal. We want to get a nice balance between believable metal, and our game’s stylistic art.

IronsightsTextTest_0001_Layer 1 IronsightsTextTest_0000_Layer 2


This last week I’ve been continuing refactoring our mesh baking system and tools. What started as something very player character specific has now become nice and generic. I’d been shoehorning vehicles into the system but it required a lot of special handling and was quickly becoming a bit of a mess, with customisable characters happening and potentially a female character that would require more special handling it was definitely time to clean it up. Now mesh attachment configurations store a list of compatible characters so we can now just throw all the potential mesh attachments into the baker and it will just ignore anything it can’t use making item configurations much easier and less error prone as well as allowing functionality like allowing monsters or vehicles to equip items and have them show as long as their is some compatible mesh defined for their character. It also deals neatly with the female character where some gear can have the same look but others like chest slot items will need a different mesh. Now we also treat the FPS player as another character type so we can remove all our special handling to deal with this.


Speaking of making things easier I’ve spent some time making vehicles easier to configure and much easier to mod. Previously we had all the vehicle attachments stored inside the vehicle prefab with a key to reference it and at startup the vehicle would turn them off and hide them away until an item referencing that key is equipped and it gets turned on again. This means the prefab needs to be configured in multiple locations and also adding a new item (say for a mod) means adding the item into the vehicle prefab and then rebuilding the vehicle pack. Whilst this works it bloats the size of the mod considerably and also makes it impossible to combine mods (say you make a new wheel and someone else makes a new bumper bar you’d never be able to run both mods at the same time). Our mesh baking system uncouples the look of the vehicle from the prefab but vehicle attachments also have hitboxes of their own and may run some of their own logic as well (like a light or an attachable seat) so we still need to be able to attach prefabs to vehicles.
To deal with this I’ve created a new item component that will attach a prefab to a bone in a skeleton when equipped with configurable offsets and scaling.


I’ve also created BoneReference objects to reference a bone in a skeleton, these are much easier to work with in configuration rather than using the index of the bone in the skeleton and will also save us lots of maintenance time if we change the setup of the skeleton, if indices need to be shifted we only need to fix the index on the reference object rather than trying to find every place we reference the bone by index and fix it there.


This week I was doing a pass over a bunch of the hair and beard assets. I made sure that there was no longer any eyebrow models incorporated into the hair models, they are now going to be handled separately. As I was already touching these assets I added detail to the sculpts helping with surface variance, and allowing the spec maps to work better.




As these have been baking I started work on a pair of Harem Pants. They might end up a little tricky to skin, but we figure its doable and worth a crack 😉


Dev Blog