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.

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.

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.

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.