Press Kit Wiki

Hurtworld Update #111

Spencer

Hey guys, apologies for the blog not getting posted last week, I usually publish it and was sick last week. So the following is 2 weeks rolled in to one.

Using Legacy as a Baseline
This week I’ve been playing a bit of legacy and getting a good contrast of where we are at now with experimental vs legacy. There is definitely something to be said for the original loot tables, damage, progression and stats that we iterated on for some time before releasing Hurtworld to steam. This is a treatment our experimental branches don’t get at all due to us trying to design a full progression from scratch a lot of the time in a week. While this serves its purpose for testing an idea out in a really rough way, it often clouds our judgement on what works and what doesn’t due to the imbalances in the basic metagame.

Now that we are moving back towards something closer to legacy in terms of structure, I’ve decided to bring back the loot, crafting, damage and stat balance from legacy to use as a base that we can iterate one from a more predictable base. This also makes a shift in our goals for Experimental, we will now focus more on the sustained play-ability of Experimental to up the progress towards replacing legacy.

I feel we have now learnt enough from our experiments to properly solve the major issues with legacy. Namingly: Infamy / Death Punishment, Camping Hotspots, Reasons to wear gear.

Timeline
I’m 70% of the way bringing experimental in line with Legacy, we are currently testing a new valuable gear protection mechanism to work in the place of infamy to allow us to A) Abolish durability, B) Bring back expensive to craft items. I will go into this more in next weeks blog.

The office will by at minimum capacity over Christmas / New Year, I would expect us to have a pretty solid build in early Jan.

Merry Christmas Yall!

Mils

Good news! The Recurve Bow textures are finished! This last set has really come out fit for a king. The combination of wood, steel and ivory have combined really well to give that luxuriant feel. Now we will need a pompous set of clothes to go with it. I am very happy with how this came out. I was a bit worried that this set would look a little less interesting than the other two, but with the addition of the ivory lions head and the filigree panels, it looks far from boring. The 3 bows are really quite different, which is what we tend to want in Hurtworld. Lot’s of variation and the ability to mix them really does add a lot to the game. It was particularly nice to sculpt the lion’s head, as I don’t get much chance to do organic modeling since Splatt has that well in hand. I’ve got the weight skinning almost done also, this has been a tricky process, as we have tried to simplify the method we use to accomplish this. Previously I would skin the mesh in the position that the bow was held in by the character, this took a lot of extra time and confusion as I had to move the meshes exactly into position so the animations wouldn’t look bad. I had created my own workaround for this, but it was clunky as. This time round Tom helped out and created a stripped down skeleton that contained only the necessary bones, which we then moved into position to suite the mesh in it’s axis oriented build position. The mesh then gets moved into position when the bones snap back to their previous locations later.

RecurveFinalSet01

These are some combinations of the various parts that are possible with the Recurve Bow. We are looking into making the skinning of the RBow easier/faster, while Tom is wokring on that I will be dabbling with the Pistol for a bit, so we can get that updated and into game soon too.

MixedParts01

Recurve Bows in all their glory; skinned, textured and added to the project.

RBowFinished01

Cow_Trix

Heya folks! Firstly, I have been optimizing our build process and starting the search for memory leaks. Our current asset structure sees the game’s SDK content split up into two parts, content and art. Content is all configuration objects, data containers, and similar assets. It’s where we define items, machines, loot tables, and all that other good gameplay based stuff. Art is where we put all the textures, audio assets, meshes, and other big binary files. The purpose of this separation is to make Content as quick a possible to build by putting all the things that slow a build down – i.e. big binary files – into the Art pack.

There’s still a fair few assets still in Content however, which I’ve been working on moving over to Art while maintaining all necessary references. There are still a few places where we will need some kind of code refactor to allow for that separation to take place, namely construction items and creatures, so that may be a project for the future.

I’ve also been looking for server memory leaks. The best way we’ve found to do this is to smash individual systems and see what explodes. This is a pretty slow and difficult way to do things, and we typically have written these tests as just throwaway code, so I’m trying to think about how we could make something a bit more reusable this time around. I’ve written a pretty simple set of tests that we can store as scriptable assets, which run on the server and record it’s memory usage. Stress testing leads to some pretty cool screenshots – check it out!

ItemStressTestingMachinesTest WorldItemStressTest ConstructionTest

I discovered a few places where we were leaking some data, like when we exploded buildings or let them decay we would create the refund item and then it would just be left in limbo until the server was restarted. However, no big breakthroughs on massive leaks, although I’ve heard from several server owners that the worst of it seems to be fixed now.

Now, I’m back on map stuff and working on a revamp of Mangatang for this balance pass. This will mean a few structural changes to the map layout, which I’ll get more into next dev blog, but expect the central building biome to be removed as everywhere is buildable again.

TEHSPLATT

Afternoon, this week I spent my time getting the female characters game ready. This whole process went pretty smoothly, Tom had to do some Python scripting to help me out with a skinning problem causing seams to show where the different sections of the mesh met during deformation, this problem was most likely handled manually on the original character which would have consumed a lot of time, so having custom tools for the job really does save a lot of time. The main thing now is just all the small tweaks to really refine the characters. Even today alone there’s been a ton of tweaks to textures, eye size, facial structure etc. and still a few more things I would like to do. I also got two hair styles in game, sculpting hair can be a bit time consuming as it needs a lot of polish or else it looks pretty bad. I’ll be creating more hair styles this week and tweaking what ever else needs refining on the female models.

Female_Characters_Ingame

I’ve also been testing out some new environment stuff, at the moment there’s not much in the way of cover, so if you get caught out in the open it can be pretty harsh. I did some research and found a pretty easy to implement technique that can have a lot of impact both visually and from a game play perspective. These clumps of terrain really break up the silhouette  of the rolling hills and give you lots of cover, they also work really well for isolating small areas to use as focal points. They are in a very early test stage visually so they don’t look amazing. Also adding in new vegetation and rocks really help break up the world as well as add additional cover. Also been looking at some new terrain splats for the future just to break up the tiling a bit, as well as hopefully getting to use a bit more water.

Terrain_Clutter_Test_3.2

Tom

This week I continued working mostly with vehicles getting as much ready to go for last Friday’s 0.4.8.3 patch as I could.
I started with continuing to flesh out the vehicle destruction work with adding pvp armor onto vehicle attachment panels, this gives the attachment panels more importance in gameplay as all attachments will now have useful stats rather than just the few adding storage capacity or extra utility like a light or a seat.
Next I added the vehicle repair wrench to the game which consumes a large amount of its durability each swing to heal the hit vehicle.
TehSplatt helped me out with an improved damaged vehicle smoke particle effect and then I added a healthbar into the vehicle ui window as a damaged / not damaged state wasn’t really enough information to be able to make decisions like, can I take this vehicle on a quick run or should I repair it first?

I also spent some time working on material assignments in our mesh baking system. Currently our mesh attachment configuration assets can either take an explicit material assignment or a series of textures to be built into a material using our ‘uber’ shader. Previously the generated material was being built in the editor along with the mod it belongs to but I’ve now changed this over to happen at runtime after all mods are loaded, this allows us to share materials between mods easier reducing draw calls when these attachments are baked together.

I’ve also been fixing a bunch of bugs such as air drop caches bouncing back into the sky after touchdown, being able to enter vehicles while carrying a heavy slot item, cracks not showing up on meteor resource nodes and making sure vehicle damage smoke particles stop playing after the vehicle has been healed out of low health. As well as bug fixing I’ve been helping Mils with skinning the new bow models so they deform with their bow strings and then getting them into the game and they are looking great!

NewNewBows

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.

Dev Blog