Press Kit Wiki

Hurtworld Update #110

Mils

I finished the Riser that I started last week. This one is a black oxide frame with Filigree patterns and cutouts on it. The wood areas also sport the carved filigree inlays. This bow will be the snazziest of the lot, not the best, just the most bling of the sets. I had a fair battle with the wood texture on this one. Getting it right took a little more time than expected. Unity handles PBR  values differently than in the programs that we use to paint. We often have to play with the glossiness after the painting process has been complete to tone down how shiny things look. What looks matte as hell in 3D Coat or Substance Painter, comes out polished in Unity. Different shaders produce different results. This is looking really nice though and now I’ll move onto the Limbs and Rest. The texture end of the bow parts will be done this week and then I have to do the weighting/skinning and somewhere in there make the LOD’s. I decided to wait til after to do the LOD’s. I have to build the parts in a regular format where they are laying flat along either X,Y or Z axis. I then need to move the parts into position so they line up with the character’s animations correctly. After talking to Tom about the problem.  Tom recommended that we move the skeleton so that it fits the bow in it’s flat axis oriented build position. This should make skinning simpler. Long story short, I will figure out the best workflow on the first item I skin and then use that technique for the rest of the parts. This will speed everything thing up.

Invictus01

Cow_Trix

Heya folks! This week I’ve been getting weather back up to scratch, fixing more bugs, and finished up implementing both a new UI for the road tool, and a cool little tool for inserting intersections into road nodes.

Weather has been out of the game for a while, as we figured out a bit where we wanted it to fit. It’s behaviour will probably change in this iteration of the system, moving from the fuzzy legacy version of “it’s raining, so you get wet, so you get cold 10% faster” to the much more binary version of “it’s a sandstorm, and unless you get out of here in the next few minutes, or have the necessary gear/base upgrades, you gon’ dieee”. In the same way that dynamic hotspots create moving points that pull players in, these dynamic hazards can create points that push players away. We plan to give players the tools to invest a bit in bases, vehicles and themselves to become immune to these environmental hazards, so they will mostly impact new players, and players who are just transient to the zone and haven’t invested any resources in it yet. This follows a lot more the soft-gating model of legacy, while still being a strong environmental threat. We’re still balancing exactly how lethal these weather systems will be, so stay tuned for more info on how they will fit into the game.

Sandstorm

I brought all three weather systems from legacy up to scratch, so that’s blizzards, sandstorms and rainstorms. The new system is a lot more flexible and easy to configure, and you pretty much just assemble a weather system out of whatever parts you want. I made a few improvements to the overall structure as I went, and I’m pretty happy with it now.

With the road tool, by far the clunkiest piece of the workflow was managing intersections. Previously, you would need to drag the prefab intersection out into the scene, move and rotate the prefab so it was in the right place, delete the node that you wanted to replace with the intersection, and then rejoin up all the disconnected nodes with their relevant node on the new intersection. I got frustrated just writing that out, so I took a little time to automate the process, as well as putting in a few quality-of-life improvements. You do have to set an intersection up with a bit of metadata so it knows how to insert itself, but it is still a vast improvement on the previous workflow.

I also fixed a number of bugs this week. This included a regression on music that meant it would sometimes stop playing permanently, and several other bugs in ambient sound loops that meant that they wouldn’t play either. I implemented a potential fix for large world-items spawning below the terrain, and then dropping through the world, by enforcing a minimum terrain collider thickness that should mean any depenetrating forces are upwards, not downwards.

Tom

Unfortunately this past week started off with me falling prey to the flu going round the office so I didn’t get through all the vehicle work I wanted to. I was able to get engine power and top speed decoupled so now engine power is the only stat that controls acceleration power (previously top speed would also effectively increase acceleration as the vehicle acceleration curve was being evaluated based on current speed as a percentage of top speed, now the top speed for this calculation is predefined for each vehicle type rather than being stat driven).
I’ve also made vehicles destructible, right now this is in a pretty basic state where non-wheel attachments will not take damage separately to the vehicle making shooting an attachment panel the same as shooting the vehicle itself.
Whilst we have the technical backend stuff setup to be able to support separate attachment health (and this is running for vehicle wheels now) on the user experience side of things we really need better ways of communicating attachment health without having to open the vehicle inspection window. These will likely take the form of new ui elements for vehicles you’re inside of and probably some kind of overlay effects (like the resource node cracks) on attachments for when you are shooting at them. None of that is going to be ready for Friday however which is why we’ll be sticking with the simplified model for the time being and showing a simple smoke effect when the vehicle hits low health.

I also spent some time this week helping Splatt get the female character into the game. This involved diving into the world of Maya scripting to fix some skinning issues we were encountering. It took some time to get to grips with how Maya handles its data and its python API but I was able to solve our problem so we can average skin weights between verts on separate shapes and skinning clusters.
I’m hopeful I’ll be able to use this knowledge again soon to help Mils and Splatt out with any tech problems they may run into and also to simplify and cleanup our character skeleton.

FemaleSunrise

TEHSPLATT

This week I got into sculpting the basic faces for the different ethnicities. They went through a couple of iterations to get to this stage, excuse the hair style, it’s just a place holder. Sculpting people from different ethnic backgrounds has its challenges, you really need to study the subtleties that make them different from each other like general face shape, cheek bone height, eye and mouth shape, the bridge of the nose etc. all of those things can change, some times it’s a very small change but can really make all the difference. I’m currently getting all these head in game and then I’m going to start on some actual hair styles that look good as the old hair models no longer fit the new head and really, they could use some love. The female clothing rig I built works well and I managed to transfer over all the clothes into a usable state within a a couple of hours so now I just have to go through and start tweaking them all so they don’t have clipping issues.

Faces_Draft_2_DevBlog

Spencer

This week I’ve been implementing Vehicle Airdrop Beacons, content progression, and finally the ability to set aim down sights to toggle. Toggle ADS has been requested heaps lately probably due to PUBG.

Patch Progress
We have all the features ready to go, what we put out on Friday will be very rough in terms of balance as usual when we overhaul everything. At this point we will be pushing it out on our smaller map “zonetest” which should make things pretty chaotic. We might put lower player caps to account for that and spin up more servers if they are getting smashed.

Tom has managed to get vehicle destruction in for this patch, so we will be playing with making vehicles more throwaway and common as well as distributing more loot through random drops, and removing hard gating from biomes.

Looking forward to shooting a bunch of you 😉

Hurtworld Update #109

Spencer

Hi Guys, this week we’ve been continuing experimentation on random location loot, heavy slots and are starting to introduce dangerous weather in to different biomes. We’ve been fairly lax on communicating our update schedule or lack there of over the last couple of weeks so I will try to give some insight into our plans over the next month or two.

Experimental Experiments
We’ve done a good amount failing as we would expect from anything experimental, we’ve also learnt a lot in the process about not only what works and doesn’t inside a survival game, but ways to approach the massive task of re-designing the many elements that fit into Hurtworld once one variable changes like progression depth, hard gating of biomes, where value is stored or how items are crafted. Each one of the major changes we have played with during experimental wipes have required us to author massive amounts of content (new map, new item progression, machines, loot amounts) to support the expected metagame in a short amount of time. We have disregarded polish in the interest of iterating quickly and determining what sucks as fast as possible. The difficult thing to understand after an experiment doesn’t work, is did it fail because it was a shitty idea, or did it fail because we executed it poorly.

Elements we’ve taken from experiments so far which I believe work well:

  • More expensive machines, cheaper gear (could use some refinement from last build)
  • Introducing more danger / rewards in random locations to prevent camping
  • Basic vehicles shouldn’t be competitive to acquire, latecomers can’t compete with people who already have vehicles
  • Taking ideas to the extreme makes for boring metas, need more balance between elements

Letting go of “Deep Survival Progression”
A pillar of design from day one, included in our intro steam page description is the aim for a deep survival progression that remains challenging (against PVE elements). After lots of testing to try to achieve this, we are starting to lean away from this concept of RPG like survival depth as I can’t see this being an achievable goal without compromising things like PVP, Sandbox elements and interesting interactions between players. Hurtworld played best when the progression wasn’t based on many tiers of gated areas or items. Our goals now will be shifting towards increasing the breadth of the progression rather than depth, meaning small goals like better cold protection for the snow or the ability to farm food in the desert inter playing with each other rather than being pre-requisites for progress.

Getting Vehicles
Vehicles are easily the most powerful and valuable thing in the game currently, I’ve always liked this being the case as they’re a cool thing to aspire to, they get you out in the world. However we’ve always struggled to make the process of working up to them a fair experience for different players depending on when you join the server, how big your team is, if you can play when everyone else is asleep. The problem is that having a vehicle makes it infinitely easier to find / steal more vehicles, this creates a big effect to start with which is compounded by the fact that car chassis are competitive. By competitive I mean since they spawn in the world at a fixed rate, another player being better at finding them makes it more difficult for you to find them. Adding lots more chassis to the world and making parts more common really just takes the fun out of the search.

Calling in Chassis Drops
In the next major experimental release, we will be introducing the ability to call in entry level vehicle Air Drops for a significant construction cost. The location won’t be fixed so you may have to fight over it or make a big drop area you control. This will provide everything you need to get moving at a cost. You will have to save for it, but it will be much more predictable and balanced than the process of wrenching chassis in legacy. We still want exotic vehicle parts to spawn in the world and be competitive, these will be higher tier stuff that isn’t
crucial to your progression out of the stone age.

Mangatang Restructure
We are removing the build restrictions on all biomes, removing the linear progression through biomes, and removing hard gating on biomes. This means the layout of the map doesn’t need to be so boring like it currently is, we can patchwork the biomes together again closer to Diemensland creating more interesting places to build. All basic resources needed to progress, build, and raid will exist in most areas in the map in varying amounts. A large amount of this will be from random meteor strikes, air drops and other random world events that will be either telegraphed by sound / effects or marked on your ingame map. These will be competitive and high value. You won’t need to go for them to progress.

Exotic Items
Each biome will have small progressions inside them that allow non crucial upgrades to parts of the core progression or quality of life improvements. Over the weeks of a wipe I would imagine most people would spend time collecting them as the become available, however you will be fully able to carve out a niche anywhere on the map without needing to do a shitload of travelling.

Hazardous Weather
Less constant environmental pressure, but harsher random events that you will be warned about. An example would be a sandstorm or blizzard that is forecast on your map with plenty of time to get out of it, if you stay it will kill you unless you have specific exotic items to mitigate its effects.

when Update.
As you can see from the above points we have lots of content authoring work to do, fortunately we have all the systems in place to achieve the above with very little code. This means we don’t have to spend weeks building new systems, the bulk of the work is content design and balance, something we are slowly getting better at.

We had a lot of fun in the very broken experimental meteor build we’ve been testing internally. As the experimental build that’s currently live is getting pretty state I won’t stress too much about the state our next experimental build needs to be in before release. There is far too much to do to get anything out this Friday still. We will aim for a fairly broken experimental build by next Friday with most of the above features (which I’m actually really excited about).

Experimental Wipe
We will be wiping experimental this Friday without a patch as the servers are getting pretty stale. This will likely result in a one week wipe cycle if we can get the patch out next Friday.

Cow_Trix

Heya folks! This week I’ve been continuing polish and bug fixes. I fixed a few more issues with construction validation, improved server memory stripping, and fixed construction effects. It turned out we weren’t validating a few construction attachments correctly, which meant that some attachments could be placed in an incorrect way that would lead to building we wouldn’t want. I won’t go into too much detail here, but this was just a matter of enforcing a player line-of-sight check across the board. For some larger attachments, this can be a bit tricky sometimes, so I also added in the ability for these line-of-sight checks to succeed when only one raycast succeeds. I also fixed something that has been missing for quite a while! Construction particles and sounds have been gone for a while, and putting them back in definitely reminded me how much they add to the tactility and feel of construction.

I also took a look at our server memory stripping, and fixed a few places we were missing. When a server starts up, it loads in all the assets that a client would, including things like sounds, textures and shaders. We have a process where the server goes through all the assets, including the loaded level, and deletes everything it doesn’t need. I took another look at this process and found a lot of places we were keeping hold of resources that the server has no use for, which should mean about a 300mb uniform reduction of RAM usage. Not a lot, but every bit counts. I also did some work on the road tool, adding in a number of small quality of life improvements and removing a fair bit of dead code from that system. I’m working on improving the ability to add in intersections, as right now it can be quite unwieldy and there’s a lot that can be automated around that process. Finally, I removed a big chunk of obsolete code from our audio framework, where we had two parallel audio clip wrapper objects where one was pretty much just a worst version of the other.

TEHSPLATT

Afternoon, this week I’ve been working on the rigging system to efficiently morph the male clothes to fit the female character. So far so good, it’s almost ready but still needs some tweaking. As you can see it’s just a bunch of bones bound to the areas that need the most change like the waist, chest, shoulders etc. I use an animation tool called “set driven keys” to essentially record all the changes made to the mesh to fit the female body then I can re-skin any piece of clothing we need using a copy skin weights tool, toggle a slider I made and the rig will automatically run the mesh changes. It works pretty perfectly on most meshes, luckily the controllers can be moved manually if they need to be so it has a lot of use. Even though this has taken me about a week to put together it will still be faster than doing this process by hand and it will continue to be useful any time we need to make female clothes from the male ones.

Female_Toggler_2 Female_Toggler_1

Mils

So even though I was struck down by a heinous Flu last week I still got some stuff done. I got this little teeny tiny Arrow Rest finished which is a small embellishment and completes the 2nd Recurve Bow set. This is a little plastic rest that suits the type of manufacture of this bow set. That being said all the bow parts are to be interchangeable so not a big deal.

Rest01

I moved on to the new Riser for the 3rd set. Most of my tiem last week was thinking of what kind of finishes to give this one. The 3rd set has a sort of Greek/European Mythology heritage to it. This one will have a grey or black oxide finish mixed with polished medium tone wood. It will have some filigree designs on it and will be the most regal of the 3 bows. This doesn’t denote that it is better than the other bows, but will have that master craftsman feel to it. I added some cutouts to the metal frame because it was looking too heavy. I will be putting little filigree metal cutouts in these gaps, which should look great when done.

Invictus01

Tom

This week I’ve been keeping on going with working on vehicles increasing the effect weight has over the vehicle. In the current live game vehicles can have large variations in weight based on attachments and number of passengers but this often doesn’t play a large difference in how they handle.

One reason for this was how we handled the vehicle’s inertia tensor, basically this is what controls how the vehicle body responds to twisting forces (torque). This value by default is calculated from the collider setup but this doesn’t really give an accurate representation for vehicles as it doesn’t account for anything internal that isn’t given a collider and also doesn’t account for differences in collider mass (ie. the engines collider should have a greater effect than the wheels per unit of volume). The other problem with this precomputed value is that unless the colliders are perfectly square the inertia tensor will not be axis aligned with the vehicle meaning that a twisting force around the right axis will not only affect pitch but can also influence yaw and roll. Our control systems for doing things like balancing the Kanga, applying steering assists and influencing vehicle air rotation are all much easier to balance and tune with an axis aligned inertia tensor that allows us to properly separate these torques.

Because of all this our solution is to override the inertia tensor for each vehicle, previously these were effectively ‘magic number’ values that were arrived at by trial and error tuning and they were never scaled by mass.

Now we calculate the inertia tensor override based on a given box size, this is much easier to understand and visualize. Generally setting this size to equal the vehicles render bounds will give accurate results.

Another change I made was to make the inertia tensor scale with vehicle mass making heavier vehicles more resistant to changes in angular velocity (making them harder to turn, roll, flip etc.) giving mass a much greater role in vehicle handling.

I’ve also been making some changes to vehicle acceleration as well. Previously the engine power stat was being scaled by the vehicle’s mass when calculating the acceleration force. This meant that 1 engine power on a Roach put out more force than 1 engine power on a Kanga and also that engine power would scale up as you increased vehicle mass with attachments and passengers. Now engine power will be affected by mass so as you get heavier it gets harder to accelerate.

We’re still not quite 100% there yet on the Slug, it still accelerates a bit too fast but is also a bit too slow on roads (where it should be the slowest but still reasonably paced) so I’ll be working on better separating vehicle acceleration from vehicle top speed in the coming week to give us some more control here (this should also make the offroad gearboxes a more reasonable side-grade option where you can trade top speed for acceleration).

In the interests of trying to leave less stuff half done I also want to get vehicle customisation back to a good place and look at introducing the vehicle destruction work I worked on a long while ago that didn’t make the cut into the Kanga patch before I move on from vehicles.

Hurtworld Update #108

Cow_Trix

Heya folks! This week I’ve finished up on improving the internal spawning architecture and the spawn window, and fixed some stuff relating to user interface focus control (edge of your seat stuff!). As with all polish work, there’s not really a tonne of awesome stuff to show, apart from things just being a nicer and better structured. Your death marker is now tied to your death loot, so you’ll be able to see if another player snatches it up as the marker will disappear. The journey to reclaim your lost loot is already pretty risky, so this should give you a bit more of a home advantage. I also re-implemented a few spawn features that had fallen to the wayside, such as spawn fatigue. As in legacy, respawning at a stake will add a small debuff to your respawn time. This is intended to make pushing into an actively defended base easier, as killing a defending player repeatedly will increase their spawn fatigue and give the attackers more time to push. This slightly mitigates the defender advantage, as well as the offense if they have built a raiding respawn point outside the base. Behaviour around disconnecting and reconnecting while dead should be a lot more consistent.

I also took a look at improving the explosion simulation, after reading this paper the other day. Did you know that it’s actually trivial to calculate the exact volume of an arbitrary mesh? Chalk that one up to “things that excite programmers and nobody else”. But it does mean that we can figure out some exact values where previously we were just eyeballing stuff. In terms of how this works exactly, when an explosion raycast hits a piece of a building, it’s damage is scaled based on the volume of that mesh. Previously, we just eyeballed that value, but with a few quick changes we can now have a much more accurate method of dispersing damage across a structure. This will change raiding a bit, but make things a lot more consistent. I also fixed an annoying bug where you couldn’t place a single door and wall at right angles to each other in an independent order, which I’m sure everyone who’s tried to place the single door has encountered.

Mils Tekmoth Von Guava

Yo! I completed another set of limbs for the Recurve Bow this week. This set sports fibreglass (glass wool) limbs with galvanized tin reinforcements and a rubber recoil enhancer. This set has a more mechanical feel and looks a bit more mad max-ish. I’ll do the ‘Rest’ which the arrow sits on tomorrow and then onto the Riser for the 3rd set. We made a change to the plan of making an arrow per set. We will for now only be using the one arrow that I previously completed. This was a game play based decision.

ReckerLimbstrings01

Tom

This week I’ve been working on vehicles mostly, first up was fixing a range of bugs dealing with the new map system. Now when in a vehicle the map’s player marker will point in the direction of the vehicle and the compass will be pointing in the correct direction in both first and third person perspectives.
I also added a vision cone to the player marker which will display whenever the player isn’t looking directly forward (ie. inside a vehicle or ‘free looking’).
Whilst making these changes I also fixed a regression from legacy so changing perspective inside a vehicle will preserve the camera direction.

SlugVisionCone

Next up was extending our material system to work with vehicles. Our material system is a way of assigning physical material types (eg. dirt, wood, stone, metal etc.) to objects, these materials are then used to lookup things like impact sounds and particle effects.
Our main motivation for bringing vehicles into this system was to change their traction based on the material type being driven on. For now we are just adjusting acceleration traction which basically changes the vehicles speed over a material, the different vehicle types have separate material/traction lookups allowing us to differentiate them better and give each type a role. We are also using this system to significantly speed up slugs on roads, this should give players some interesting decisions planning their getaway route trying to balance speed with predictability.

I also spent some time looking into how vehicle traction is applied in an effort to improve the low speed handling of the Kanga. During this I found a few bugs, mostly with how static and dynamic friction were calculated and also how they were blended between. With this cleaned up and the wheel settings readjusted the behaviour feels similar to before except the Kanga doesn’t drift around at low speed and is a lot more controllable.
Eventually I’d like to look at modifying sideways/turning traction based on material type but currently we set traction modifiers and stats on a per vehicle basis rather than per wheel so rewriting and rebalancing all of that is more time than I want to spend right now on it. I have setup a lot of the data necessary for that kind of change though (ie. individual wheels know what material they are contacting) so we’ll be ready when the time comes.

TEHSPLATT

Hello, this week I continued experimenting with the loot cache model and ended up with a pretty worn out rugged looking crate that was pretty noisy and wasn’t really much lower poly than the one it was meant to be replacing. I ended up going back and cutting down the original loot box and making some LoDs for it. Here’s a picture of the loot crate that won’t be used.

Loot_Cache_Clean

I also started to look at efficient ways to transfer the current clothes to female proportions, I built a little rigging system that can take the old clothes and automatically deform them to fit any new proportions thrown at it (I don’t have any photos as of yet). So once that system was made, it was safe to jump into concepting for the female model. The hardest part about the female model is keeping the joint placement exactly the same, male proportions are pretty different to female proportions so I did as much as I could to make the character feminine without moving the joints, this involved cutting down a lot of muscle forms and smoothing out some noise. Here’s the current state of the character.

Player_female_version_2_full

 

Spencer

This week I’ve been working on a new feature that I wanted to get in before we put out our meteor showers update: Heavy Slots

Heavy Slots
With the introduction of the Slug truck, there really needs to be a reason to ever drive one around. Having it as just a mega slow vehicle with lots of storage would never really fit into the current meta game. For a while I’ve planned to create a new mechanic to make heavier vehicles useful.

Heavy slots are similar to restricted gear slots in that only heavy slot items can be placed in them, the big difference is that heavy slot items MUST be placed in a heavy slot and can not be carried in any regular slots.

Players only have 1 Heavy slot which is located in their hotbar, and the heavy slot item will take over the equip slot in the hotbar while it is being carried. This means while carrying a heavy slot item, you can’t use and hotbar equipment like guns. You will also run much slower and be unable to sprint.

This aims to create some more interesting challenges moving valuable things around the world. We can start to create higher risk higher reward situations like needing a truck to carry meteorite fragments back to your base for refining, or needing a truck to extract valuable machines from a successful raid.

The truck being naturally slower than other vehicles, we hope to foster traps, high jacking attempts and escorts on Goats and Kangas.

Here is the system in action (with placeholder art)

Dev Blog