Press Kit Wiki

Hurtworld Update #107

Cow_Trix

Hey folks! This week I’ve been continuing on various bugfixes, and mostly polishing up a bit about how we handle death and connecting to the server. We weren’t handling some scenarios particularly well around this, so I’ve been streamlining those structures. While the current architecture does work with no super obvious downsides, it does lead to some confusing scenarios. For instance, if you disconnect from a server while dead, or someone kills your sleeper, you’ll actually respawn and die instantly. This feels like it’s the spawn that has killed you, when in reality it was something else. It also meant that there were some cases where you’d be spat out into a random spawn when you had a stake it was possible to spawn at. We don’t really communicate this particularly well, especially as we don’t store the reasons you died across server restarts. These are all very delicate structures, as bugs introduced can damage player progress, so I’ve been going slow, changing as little as possible, and doing a lot of testing.

There were a few places where you couldn’t interact with the player spawning system unless you had already spawned in the world, which hasn’t happened yet for players who are just connecting. This was because we were using the player entity as a keying object in a number of lookups. I changed the system to use the connected network session to key any data, which worked well. It also removed some coupling between the game mode object (which is an object that configures what game mode the game is currently using and the configuration of that mode) and the spawn window, which is always nice. As an added quick job, I moved the player customisation interface into it’s own little widget, as before it all just lived in the spawn window code. I also extended the game mode structure to allow game modes to write state into a savegame. In the case of the Survival game mode, we can write in stuff like how a player died when they were offline, so we can tell them when they log back in. We could also store things like leaderboards, teams, or other forms of game mode state with this in future.

So with these fixes you should have a much clearer experience when joining a server, as to what killed you when you were offline, as well as always giving you the choice where to spawn when there are multiple.

Mils Lord 5000

So I’ve finished the texturing on the second Riser for the Recurve Bow. This one is a re-purposed metal bar. So that the bow parts have a lot of variation, this one will be made from man made materials. There’s a steel bar, with a layer of yellow foam, wrapped in black rubber as the grip. This one contrasts nicely with the previous mostly wood version. I added a little rust near the welds to sell that it has seen some action. This came out just as I wanted it to.

ScrapperRiser01

I have also got the high poly done on the limbs for this set. These were going to be metal also, but the more I thought about it the less this made sense. I didn’t want the whole thing to be metal when combined with the new Riser. I have made the main flexy bit fibreglass (or as peeps from the elsewhere call it ‘glass wool’), and then galvanized sheet metal reinforcements where the limbs deviate. This should look pretty special when it’s done. 😀 😀

ReckerLimbstrings

TEHSPLATT

Hello, not much to show this week due to a short week and I’ve mainly been cleaning all the mess I made doing the particle stuff and getting the last little random jobs done. I did make a start on a new loot cache though, the original one had to be redone due to it being over the general poly budget but the one I did to replace it was just a place holder and looks very simple and average. So I’ve gone about it in a bit of an interesting way and instead of make a box then sculpting some wood grain and scratches into it, I’ve done the reverse and made all the different bits of a wooden crate separately and sculpted both sides of each bit of wood so that I can flip and position things in specific ways that don’t show any repeating details. Due to this being an item that you see a lot I’ve put a good amount of effort into the actual sculpt, once everything gets positioned and baked out it will be a very nice box with a nice solid feel.

LootCacheWood

Tom

This last week was a bit shorter than usual thanks to a public holiday so I don’t have heaps to share this week unfortunately.
I spent most of the week continuing on with bugfixes including a material sharing bug in the mesh caching system and a race condition that could occur with attachable vehicle seats for the roach.
The material bug was occurring because I had incorrectly assumed I could rely on the ordering of elements in a dictionary if GetHashCode() didn’t generate any hash collisions (where multiple objects share the same hash) between elements. Unfortunately it’s not quite that simple as elements get indexed internally as (hash/internal array size) meaning collisions can be much more frequent than I had assumed plus the removal of elements from the dictionary can change where the next entries will be placed (see https://www.red-gate.com/simple-talk/blogs/the-net-dictionary/ for a detailed explaination).
When retrieving a mesh from the bake cache I was assuming the collection of attachments would be in the same order and I could just iterate through getting the material for each and then assign this material list. Because the order had changed between the job that was entered into the cache and the current job we would end up with the wrong materials pointing at the wrong submesh (part of the mesh that is drawn by a single material). To fix this I added some extra data into the bake job cache to preserve the order of attachments, when retrieving from the cache we now use this list to resolve material assignments properly (by comparing old list to current).

I also fixed a nasty client side race condition with attachable vehicle seats like you see for the roach front and back seats. Basically what was happening here was that on spawn the vehicle was trying to place the passenger into the seat before the seat had initialized itself and the initialization was waiting on the equipment system to equip the attachment. This would cause the system to error and then on your client this passenger would appear running like a normal character but standing inside the car.
Rather than try to manage this order of execution across the client/server boundary I chose to refactor the initialization of the attachments to not depend on them being equipped first (they’ll initialize on entity creation instead). I also changed them so when the attachments are activated/deactivated they now run a list of actions serialized into the attachment itself rather than just activating/deactivating the game object, this gives us some performance benefits as well as configuration flexibility. In this instance we can now enable/disable the seat attachment by just enabling/disabling the box collider that is used to trigger the player to tell them they can use the seat. Disabling just the collider is much faster than disabling the whole game object.

NewVehicleAttachment

Spencer

This week I’ve been iterating on the random geography hotspot playtest. We had a bit of a play on Friday and came up with a big list of refinements that I’ve been working through today to ensure we get the value we expect out of the meteors and air drops. Getting the pacing right is a tricky one, as we want these events to be contested but not so frequent that you come across them without meaning to. The key here is balance between classic evenly spread resources, static hotspots and the new random location hotspots.

Hopefully tomorrows internal playtest will be better paced and we can work towards integrating it into the overall game by Friday for the experimental branch.

Hurtworld Update #106

Mils

I carried on with the Recurve Bow parts again this week. I have a Rest (which is a slightly bent nail) and an arrow to show you. The nail was pretty easy and looks fine. The arrow ended up looking really satisfying with the flint head material contrasting with the wood and feathers. One set is now completed on this one.

ArrowRiser01

I got into the Riser on the next set also. This one is a piece of square pipe that has been scavenged and hammered and bent to fit the use as a Riser. There’s a leather wrap handle that I wanted to try and find an easier and better way to create. I tried using Maya’s nCloth to simulate the strap wrapping around the bar and making the cloth surface really sticky, so that it would cling to the bar and not fall off. This was interesting to learn a bit about nCloth dynamics, but in the end I decided to drop that method as it was taking too much time. I will say that the basics of cloth simming in Maya using nCloth is really easy. I ended up using a bend deformer and rotating it to get a slight offset. This created the layered wrapped effect fairly well. The UV mapping and normal baking are done on this so I will start the texturing this afternoon.

ScrapperRiser02

Cow_Trix

Heya folks! This week I’ve been working through a number of bugs that you guys have raised. I refactored the chat window a bit, so you can more easily read long messages like server announcements. Previously, if the message exceeded the height of the chat window it was actually impossible to read the whole thing. While I was at it I tried to tweak the text display to make it a bit more readable on both a very dark and very light background. I also added some quick native support for one of the most common features server owners ask for, greeting messages, as well as an indicator of when a message is a server announcement.

newchat

I also looked into making claiming vehicles have a bit more functionality. Right now it’s pretty easy to quickly strip a car for parts with vehicle attachments being easily take-on and take-off. This means it’s pretty rough to leave your car anywhere, as in just a few seconds it can be completely destroyed and all the loot you were keeping in it stolen. We already had the concept of enabling and disabling inventories, so I extended that to give the owner of a vehicle the ability to lock and unlock the storage of their car so people can’t take parts on and off, or things out of the boot without you around. That being said, they still can drive the car away and they still can wrench the car and get all of it’s parts, though wrenching a claimed car is a pretty slow job. I’ve been thinking about various upgrades that would be easy to make for vehicles to make them less susceptible to these scenarios, such as kill-switches, trackers, and car alarms, which hopefully we will be able to explore in the future.

Aside from those few little projects, I’ve just been working on various bugs. I fixed some scenarios where your construction raycast went through walls, changed a lot of machines and sound-emitting objects over to the new sound system (which will mean that you won’t get random things making noise even when you’ve got the game volume down), fixed some machines continuing to play sounds after they were destroyed, and fixed a few bad areas in Mangatang. All these fixes and more will hopefully be coming to all very soon!

TEHSPLATT

This week I’ve been continuing trying to create an interesting looking resource node for the meteor strikes. Melting lava ball is where I’m at right now, I created this hollow ball with holes in it, then made an inner sphere with an emissive glow that shines through the holes. I wanted to make it stand out from your basic resource nodes so I tried to add some particles, sort of like smoke leaking out of the holes. Originally the smoke looked very obviously fake against the emissive glow due to it not receiving any lighting from the glow. I used the particle system’s colour over lifetime gradient to fake the lighting of the particles, it now gives the impression that the glow from within the node is lighting up the smoke as it leaks out. I also tried  a few different smoke variations the second one below is one of the more ridiculous ones.

I also revisited the Amber world item which is honestly a pretty difficult one when using the standard shader, it’s hard to convey a semi transparent rock that catches the sun in interesting way using only an albedo, spec and gloss. So I saw something worth trying out and in my opinion its the best looking version yet, but, possibly a bit too realistic and also might not stand out on the ground among other earthy colours.

Amber_v2

Tom

This week I’ve been finishing setting up destructible wheels for vehicles, doing some bug fixes and also improving our tools and mod build process.

As part of implementing destructible wheels I needed a way of binding hitboxes to storage slots, we already had a basic implementation of this going on with the way the players armor works but it was all hard coded bindings which wouldn’t work for vehicles as the different vehicle types have different storage configurations. So with this in mind I’ve moved the hitbox bindings into the StorageConfig asset used to setup inventories. Below is the Roach’s StorageConfig (left) paired with its EntityStatsBuilder (right) which is the other half to setting this up. In the StorageConfig you can see RoachWheelFrontLeft is bound to the Wheel FL hitbox. Over in the stat builder you can see DamageProxy WheelFL also has a HitboxMapping for Wheel FL. I’ve also setup a FluidEffectImpactMultiplier of -1 which adds the original damage value * -1, essentially cancelling all damage to the vehicle. Below the hitbox mappings you can also see the RaiseMitigatedEvent flag is checked, this causes a new event to be raised with data about how much damage was prevented by this stat. Finally either a PlayerStatManager or VehicleStatManager will handle these mitigated events by looking for storage slots with a matching hitbox binding and then pass the mitigated damage onto any item in this slot.

StorageHitboxBinding

I also managed to get through some bugfixes including fixing an issue that would cause rifles and shotguns to become tiny when aimed down sights from third person mode, fixing seed items recolouring your hats again, fixing an issue that allowed the shotgun to fire without a shell loaded, returning ladder climb speed to legacy values and improving vehicle exit behaviour. Unfortunately due to most of the office getting sick we weren’t ready to deploy these fixes in time for last Friday’s wipe but we hope to get them out to you soon.

GunScaleFix

I also spent some time improving our VehiclePassenger tools. I was struggling with debugging some vehicle exit problems and decided we needed a clearer visualisation of what was happening as it can get very complicated with exits that are defined in the vehicle’s orientation space (so they rotate with the vehicle) but then can also have an additional cast to ground step, then with the position worked out we need to check the whole player’s volume over the exit rather than just a point and if that passes then we do a final raycast from the seat to the exit, if this passes then the player can exit the vehicle. To make this all easier to see I created a debug view that will draw all exits and their current state. I’ve also changed the vehicle exit list to a reorderable list (as exit order defines priority) and created a custom inspector for copying exits from another seat (while shifting them into the new seats orientation space).

I’ve also been working on speeding up our mod build process so we can iterate quicker, first up I added a proxy check (ie. is the object real or is it a placeholder?) that can be run based off an unique id that is generated for all assets by unity. During pre and post build steps (where things like preparing mesh attachments happens) we can use this check to skip over all the proxy assets without having to load them into memory first (because we use the id instead). I also added another early exit check for when the asset is labeled as ‘dontbuild’, these were being correctly ignored from the build but were still running pre and post build steps for no reason.

 

Spencer

I haven’t got much done this week due to being knocked out with the flu. I am still working towards a dynamic geography hotspot build which is playable for the first time today. If by some miracle tomorrows playtest goes really well, I might try to push it out to you guys on Friday. I wouldn’t hold your breath though.

Good news is all the features I wanted to get in for dynamic hot spots are working really well. I added some sound effects to the meteor strikes that came together really well. Looking forward to getting them out in the wild!

Hurtworld Update #105

Mils

So I took a little longer doing these limbs this week than I’d hoped. They came out looking sickballs though. This bow is really starting to shine as a quality weapon. I also put a fair bit of detail into the feathers so we can use them for world items in the game. I can’t wait to use this bow now. These match up well with the enhanced weapons texturing and use the full pbr workflow, same as the AR15 and AWM. I’ll do the Arrow and the Rest now which should take no time. I’ll be doing the 3 sets of gear for these then weight skinning them and they’ll go out with the V2 release, or maybe sooner.

InuitLimbstrings01

 

 

Spencer

This week I’ve been working on finishing off the meteor shower, implementing the art TehSplatt has been working on and bringing everything together for our new game mode. I wanted to have a lot of the stuff we are working on going into experimental this Friday, unfortunately things generally take longer than I had hoped and I don’t want to release this stuff in a half finished state like our last few releases. We are going to spend the extra time to get things right, meaning this week isn’t looking good for a content patch.

At this point we will be just doing a wipe on experimental with bug fixes.

Here is the meteor shower in action:

Loot Balance
The things left to do with the dynamic hotspots are to figure out how frequently they should spawn, what items they should drop, how they should interact with bases, and how to rebalance static loot to make room for the added items from meteor showers and air drops. This is the part we often fall short on after implementing a new mechanic. It doesn’t matter how cool the effects are if the stuff that you get from them is useless or unbalanced. This will also tie into how the truck fits into the game. The truck is slow, annoying to drive, and easy to highjack so we need make the reward big for using it.

Cow_Trix

Heya folks! This week I’ve been working on various bugfixes, the new in-game map, and polishing little bits and pieces. Firstly, through using the map and comparing it to maps in other games, we realised how important continuous motion was in being able to do things like focus on a single point while zooming and panning, so I went about changing the behaviour to interpolating between target positions and zoom levels, instead of just immediately snapping to them. This meant a bit of a rethink about how we were invalidating an recalculating things, so we were saving as much performance as possible. Recalculating the UI layout in Unity can be an expensive process, especially if you’re using a map with many markers, so we wanted to minimise how often that happens. It is still possible that lots and lots of markers will slow the map down a lot, and in the case where that becomes a substantial concern, there is the possibility of rendering the map to a texture which we then display, as opposed to moving a transform with a complex hierarchy below it, which will eventually bring the framerate down. I also implemented a zoom-to-cursor functionality, and the ability to remove your waypoint marker once placed. These quality-of-life features will roll out in the next patch and hopefully make the map feel a lot better to use. If you guys have any other suggestions for making the experience feel better or more intuitive, let us know!

In other optimisations, I was a bit all over the shop. I optimised the construction shader to remove a whole bunch of unused shader channels that were left over from development. I also fixed a bug where construction items weren’t initialised properly when they were first equipped and couldn’t be placed until they were reequipped. On the SDK side of things, I made some changes to the road tool which removed a previous restriction, in that the order you placed road nodes mattered in how the road bent between them. I also experimented with some tools to improve map FPS, including a tool to automatically delete geometry below the terrain that seemed to give a fair boost to FPS. More experiments on this are needed.

This week I’ll be continuing to polish features and fix bugs. The Bug Report forum on the Steam discussion board is the best place to have your say on the critical things that need fixing, so make a post if you something is really bugging you.

TEHSPLATT

This week was spent making some quality particle systems for the meteor and meteor ground explosion. Last week was my first attempt at some sort of explosion using particles, and the intial results I got were pretty terrible, but I’ve learnt a lot through the week and ended up with something that, while it could be better (pretty typical in art), I feel has the epicness and scale that I was trying to get across. You can see below the comparison between day one and the final version. The first one uses static images as particles which make everything look like cotton wool, while the final version uses animated sprite sheets which give the particles a realistic and lively feeling. Another thing that helps a lot is bloom, which gives the flames that intense brightness more inline with a realistic explosion. You can see the meteor trail particles in Spencer’s video, the meteor originally had a blue glow around it but due to the flames being added over the top the final result is a green glow which I like so that was a happy accident.

I’ve also started working on a Substance material for the meteor that you will see after it’s landed. It’s still in very early stages but I currently it set up so you can controll the amount of cracks and lava which might be useful for animating down the line.

LavaSubstance4Devblog

Tom

This week I helped push out 2 bugfix patches, re-enabled destructible vehicle attachments (shooting off wheels is coming back) and continued to iterate on the Slug.

The first bugfix patch (0.4.8.1) was largely to address an OSX issue where the input system had become corrupted and was not being loaded properly, this was an issue that would frequently pop up when creating builds from my machine but thankfully it now looks like we’ve gotten to the bottom of it and our OSX releases should be more stable from this point on.

The second bugfix patch (0.4.8.2) was largely to address a bug in the mesh baking cache system where meshes could suddenly disappear. This system basically saves combined meshes so if we need that combination again we can quickly look it up rather than having to do the combine job again. Because we have hundreds of mesh attachments this leads to more potential combinations than we could store in memory at once, because of this we need some way of removing combined meshes from the cache to make room for others. To achieve this I’m using a reference counting system where each use of a mesh increases a counting variable, when we release the mesh (like when a ragdoll despawns for instance) we decrease the same variable. When it comes time to ‘trim’ the cache we can scan through it looking for any meshes with a 0 reference count and know they are safe to remove.
This bug occured because I wasn’t adding to the reference count when the combined mesh was first added to the cache, this meant if only 1 system was using this mesh on your local PC it could be incorrectly cleared.

Another change I added to 0.4.8.2 is options clamping. Now when the game loads or any other time your options are loaded we validate the config being loaded where possible by clamping the values between their min/max values. This means that if you had a previously valid config that has recently become invalid it will now be set back within a valid range rather than allowing you to keep a previously saved config (like when we changed our field of view min/max a few months ago).
I’m mentioning the field of view change because I’ve received some comments that our new FoV max of 80 is too small, the truth is there are two ways to measure field of view, horizontal and vertical. Currently we are measuring vertical FoV because thats how Unity handles it with their camera components but most games measure it horizontally.
For a standard 16:9 monitor our max of 80 equates to about 112 horizontal FoV.
I will look into changing our options config into horizontal FoV soon.

I’ve also been continuing to tweak the slug handling by reducing the engine power even further, increasing the weight slightly and adding a placeholder heavy slot which increases the weight of the Slug by 50% when its loaded!

I’ve also setup a system for storage slots to bind to hitbox types so we can setup passing damage through to an item’s durability and I’ve started to setup vehicle wheels to be destructible again in this way.

 

Dev Blog