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.

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.

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.

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.

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)