Spencer

Closing in on the deathmatch build this week, we’ve been hammering out some play testing and having heaps of fun. Getting pretty close to something releasable.

Lighting / Skybox

Since the migration of all our lighting settings over to ItemV2, we upgraded our Skybox plugin to the latest version. Our of the box the lighting settings are not great, I managed to get our early access release looking decent by countless hours of tweaking. Since the upgrade to the latest version, all the configuration settings have changed, and the calculation model is completely different meaning all those finely tuned settings are now useless, hence why our screenshots of late have had pretty rubbish lighting.

While deciding whether we should downgrade back to the old version or not, I dug around a bit for new solutions that have come up since our initial build. What I found was an amazing asset called Tenkoku Sky which out of the box looks absolutely amazing. I spent a day having a crack at implementing this to link into our biome and lighting systems and it ported across like a dream thanks to some awesome work cowtrix did abstracting our old skybox with some neat ahead of time compiled logic.

Not only was I able to quickly switch to the new skybox, I was able to leave the old skybox intact as a fail safe if performance of Tenkoku sucked on lower end machines.

Here is a before and after screenshot of old and new skybox in action around the same time of day:

Another awesome win we got from this switch was the skybox and lighting play Heaps better with our water plugin:

Deathmatch Preview

Lastly I’ve been madly building a tuning weapons for the ItemV2 preview deathmatch build. We’ve been having a heap of fun playing with them, and can’t wait to get your hands on it. Just a few last bugs to iron out.

Cowtrix made an awesome TDM map this morning out of a section of the city. Here is 10 mins of unedited footage from this morning of Tom mopping us all up 🙂

Mils

Greybox sights have been my world this week. So far I have made some of these very similar to real life, some I made up. I tried to follow the engineering techniques/style that real life sights follow. We had a play with them on Friday in the ever-evolving Deathmatch map and damn some of them feel really good. The new gun systems Spencer has been working on, combined with the new sounds has made these guns really start to come alive. I had a lot of fun shooting my co-workers. The image below shows the sighted and unsighted view the models.

Tom

This week I’ve been working on getting construction up and going again in ItemV2. It was the first time for me going deep into our construction system internals so I started out with recreating basic machine placement by implementing the campfire.
This led to finding a few bugs in our revamped entity stats system that I’ve patched up and now campfires are working correctly and we have a basic construction prefab item component to allow items to place construction prefabs into the world.

After this I did some more work on the mesh baking system, fixing up a problem with normals and tangents not being transformed correctly and streamlining the workflow a bit by saving static mesh offsets and allowing new static meshes to be baked from an existing reference rather than having to be aligned with the skeleton.
Then I was on to recreating the construction hammer, luckily I could use a lot of the logic from the basic prefab construction component, the main change was just driving the prefab selection from the client side construction ui menu. The rest of the work was recreating the various materials and resources and updating the construction prefabs with references to the new items so they could resolve their costs and refund amounts properly.

Today I’ve been fixing a few remaining bugs with the construction hammer refund costs and creating the rest of the construction prefab items (storage chest, ownership stake etc.) which is super fast once the first one is figured out, just a matter of cloning then renaming things and setting up the prefab reference.
This week I’ll be continuing to implement our items from the live build, next up should be the spear so it’ll be ready for the deathmatch build!

Gavku

So I have continued exploring character stuff focusing on a female in particular. I created a female head piece which seems to look ok so far. I have also made a few hair pieces starting with a couple of shorter styles.

After texturing up some hair we will have to make an evaluation of her in game and see what sort of body tweaks we can get away with.

Cow_Trix

This week I started off by extending the biome framework to allow for skybox modifiers. In simple terms, this means that biomes can now change how other biomes display. For instance, now you can make a biome that instead of setting the sunlight color directly, just darkens or lightens whatever the light color was going to be. To do this I extended the skybox Ahead-Of-Time compilation framework, so it will reflectively look at the skybox configuration classes and figure out what needs to be done to provide serializable modifiers for each variable. As Spencer may have mentioned, he has been playing with Tenkoku sky, and it was pretty much plug-and-play for swapping that system over, which I was pretty happy with. Spence just had to tell the AOT framework to create “stack” classes for Tenkoku, and it went and generated a whole bunch of modifiers for it.

Tenkoku raised some annoying render bugs with transparent objects and image effects. As anyone who has delved into the Unity render pipeline can tell you, things like screen-space fog and transparent objects can have a… tricky relationship, especially in deferred rendering. Transparent objects do not write to the depth buffer (and rightly so, as otherwise the objects behind them would not be rendered). However, screenspace fog uses the depth buffer to calculate how far away a pixel is from the camera, and so it ends up seeming like transparent objects are floating above the fog. Now one method of solving this is just telling the screen-space ambient effect to draw after transparent objects. This solves tree billboards not fogging perfectly, as we can get them to draw to the depth buffer. It even solves the issue somewhat for water, but not quite. There are still some issue with the depth buffer here, obviously, that need fixing.

I’ve also been iterating over the forest, trying to get some interesting rises and falls in the terrain. Check out some screenshots.

Spencer

Good progress this week, but before I get into it I should probably talk a bit about scheduling of big updates. I have mentioned vague dates we want to release by in the past, we were originally aiming to push out the full ItemV2 in December. As we still have a truckload of stuff to do, so December isn’t going to happen 🙁

What I will commit to is ItemV2 deathmatch before the end of December, it’s starting to feel really nice, and once I add in the last few features to weapons we will throw out a build and constantly iterate over it. We will be posting out polls to get some feedback from you guys on what you like and what you don’t.

The full ItemV2 still requires a lot of work, as we have massive plans for it. Its really going to be closer to a sequel than a content update, and we don’t want to cut our scope short after pushing through the hard parts. Another factor here is we know how much everyone loves to hit the ground running when a big update drops, discovering stuff first, bringing back the competetive spirit. With that in mind, we don’t want all our new systems to fall over under the stress of an influx of players old and new. Thats why we will be releasing smaller chunks to battle test them before bringing it all together and really pushing the marketing side to let everyone know, we’re ready for them.

We’ve been quiet while developing ItemV2, and you might have noticed we haven’t gone on sale for a while. We think now isn’t the best time to pickup Hurtworld. We have so much awesome stuff almost finished, we want to stay under the radar until ItemV2 is ready to go, at which point we will be going full ham on the hype train. We expect this to bring in more players than we have had before and we will be much better equipped to deliver frequent content to keep everyone focused unlike our EA release.

We appreciate you guys sticking with us while we get our shit sorted. And those who haven’t, we love you anyways 😉

Week Progress

Now onto this weeks progress. I started with working on the damage feedback layer. Firstly by re-implementing the directional hit indicator, then enabling the outer screen non directional indicator for directional damage also. Lastly I added in the new camera spring force procedural animation which depends on direction you were hit from to give more instantaneous info when hit. Not only will it grab your attention, but also tell you the direction the hit came from. Damage in the below video is being caused by a Testing Creature i created to spam me with damage. The impact force will also scale with the amount of damage that the source did to you. The below shows damage of 1/3 your HP bar indicating a large hit.

Next up I started integrating the grey box weapons Mils has been working on. The idea behind the grey boxing is to test the overall feel of the gun shapes and sightes without going into high detail on the models, so we can rapidly iterate over them. While doing this, I implemented the bolt action properly inside the ItemV2 framework. The state machine layer allowed me to do some stuff I’ve wanted to fix for ages. I’ve decoupled the bolt pull from the fire animation, meaning the gun keeps track of a bullet in the chamber. If you sprint right after firing, you will still need to load another bullet once you stop sprinting. It also didn’t make sense that you would bother doing a bolt reload before a clip reload, as there is nothing left in the clip. The player will automatically go into the reload animation without a bolt reload once the clip is empty making it feel a lot less clunky.

Next I built a method for guns to adjust their FPS viewmodel depending on the sight position without requiring us to build new animations. This allows us to generate a weapon of any configuration, and simple push around the fps viewmodel proceduralally so the sights always line up. Part of this phase is to get a feel for what is good in terms of sights for different weapon types. We deliberately made the stock sights for some of the weapons suck, so there is more insensitive to upgrade them later on.

Here is a few in action:

 

Lastly I spent a bit more time on the new audio layer and implemented a way to trigger audio for player animations like equipment and footsteps that doesn’t rely on horrible Unity animation events. We are now using StateMachineBehaviors, which seem to fit the task perfectly, and allow us to do more inteligent things like stop a long running sound if an animation is stopped half way through. To finish up I built a audio test bed for authoring sound effects that will ship with our SharedSDK, making it much easier to create good falloff curves and ensure sounds aren’t audible over dumb ranges. The weapons are the first things using this system, and Its an absolute dream to work with compared to the Unity AudioSource + Clip system. Something simple like a gunshot being audible over 200m, but the bolt reload only being audible over 20m requires no work at all. And doing things like playing different clips when the sound is further from the Camera can be done purely in configuration without the equip layer knowing about it. Expect our audio stuff to get a hell of a lot better.

Mils

Between greyboxing the new weapons and getting used to the process of adding Static Meshes into the project I had a crack at some concepts for the Pickaxe.

I started out with a few different variations to get a feel for what we wanted. After that we narrowed down the way the parts would work together so that the thing could actually be built. In the end it’s like the gun component system with fewer parts.

Cow_Trix

Hey folks. I started off this week with some heavy modifications to the macro map generation, as we weren’t happy with the shapes it was creating. Previously we were generating areas “hill-in”, where we laid out lines where the hills would be generated and the valleys ended up being the negative space between these lines. However we found this led to some undesirable things like very long valleys, or large areas without any significant valleys. So the shift in logic was moving to a “valley-in” generation logic, where we allocate space for the central valley areas and then fill in the hills and mountains around them. This worked pretty well and the maps feel much better laid out now.

We’ve been iterating over some other biomes, mainly the forest area. This has been interesting figuring out what makes that biome feel different, and we’re trying to open up the area, play with the noise a bit, and get it feeling both unique and interesting.

I also made a cool gif of the map generation process so that you can get an idea of what we’re actually doing here under the hood.

Map:

I also have been changing the way the road system works after some feedback, so it is now a destructive process overlaid over the generated terrain. As well as this separation from Map Magic, it’s now asynchronous! Which means it won’t freeze Unity for a few seconds every time you want to rebake. This was a fun challenge and I’m pretty happy with how it turned out. One of the bigger things was that it’s tricky handling the data when it lives in the Terrain object, as it’s a C++ object that you can only pass information to, not hold a .Net reference to. The solution to this was to create a simple wrapper for the Terrain object that lives entirely in C# land, which we can do things like keep references to and treat as a cardinal dataset. The road tool just keeps getting more awesome!

Roads:

Tom

Last week after finishing up on 0.3.8.1 I’ve moved back onto ItemV2 and getting vehicles working under the new item system.
This has involved writing lots of new item components and adapting the mesh baking system to accommodate vehicles.
I’ve added a way to override bones when passing meshes into the mesh baking system, this allows 1 mesh to be used for all wheels easily and will allow us to do other cool stuff like attaching guns and tools to the player if they aren’t selected but are equipped in the hotbar so you can see what setup people are using.
I also developed some item components that change what they attach depending on the slot they are equipped to, this is used to handle things like vehicle doors (1 item but different attachments for left and right door) and the kanga wheels which use a different model for the same wheel depending on front or rear slot.
We’re now at a point where vehicles are equivalent to live with all the vehicle items reimplemented which is going to help us a lot for nailing down the feel of the new map generation tech Cow_Trix has been working on.

This week I’ll be going through reimplementing the rest of our items from live starting with the construction hammer.

Gavku

So I am going through and still working on testing out new models for different player characters. We’re hoping to have a decent selection by the end resulting in a variety of player types rather than the same old guy running around. Included in this I will be having a crack at a female character and seeing what we can get away with in regards to workload vs a decent result.

x

Mils

The guns are now getting some iron sight designs as a starting point for the grey-box testing. we need to get a feel for the type of sights we want. Spencer said he wants something that feels fairly fine, so you can really feel your victim being lined up. I couldn’t agree more. This is difficult until we get it in game and actually look at it. I just made a greybox version of an SMG as well. This was based on an old style world war gun. I’ll be designing a component based pickaxe next, using the same construction system as the new guns.

I also made a box for the new sleeper system, which I think you’ll agree is quite hilarious. It had to be low poly and the size of the players collider capsule, so a box was the best option for this one.

Gavku

This week I finalized the two basic shoes, and knocked out a set of Timberland style boots with three skins being classic, dark, and worn.

We are also looking to do some extra character skins of varying nationalities/skin tone. The changes need to be enough to sell a different look, however a lot of the facial landmarks need to stay intact to accommodate hair/hats/facial hair etc.

Cow_Trix

Hey folks. Not a lot of pretty pictures from me this week. I started off this week by sorting and trying to make a dent on the Bankroll support email. Still about eight hundred emails still needing a read, but hopefully we will get through all of them eventually. Thanks for all of your bug reports and suggestions!

For the Friday patch, I fixed an exploit where people were able to push themselves through solid objects by building into the space they were occupying. We think this was exacerbated due to recent changes to player collision. The solution was to just create a conservative collision check on all the construction attachments that only checked against players. This might mean that your friends can block your building a bit more easily, but it’s a small price to pay for guaranteeing that when a construction piece is placed, it isn’t going to push a player through a wall. I would strongly advise anyone who has made a custom construction pack to go back and add a new ConstructionVolume to all of your attachments. There’s a handy “Snap To Bounds” button now that will set the ConstructionVolume to encompass the attachment. Set the “Don’t Bake” and “Override Collision Mask” flags to true. You’ll want to set the Collision Mask field to Players, PlayersRoot and PlayerSelf. See below (and the updated attachments in the SDK) for examples.

I’ve gone and optimised the map generation a bit, and ran Spence through the map generation workflow for the first time. This was good as Spence was able to pick it up and make sense of it pretty fast! I was worried that after all this time being in my map-generation-programming hermit cave, the pipeline might have been far too convoluted, but it seems like it has turned out to be a pretty cool toolset. Spence requested some QoL upgrades which I implemented, as well as giving me some direction on what needs some tweaking in the generation. More on this next week.

I also took a bit of a look at how Biomes are structured, and it looks like I’ll rework them to be a bit more flexible in what they can do. For instance, we are probably going to implement things like NoBuild zones within the Biome system for ItemV2, instead of with colliders as they currently are. We’ve run into some performance issues with big colliders, so it’s something we need to move away from. How this would work is that biomes now can choose how they are blended with all other biomes. The logical structure of this is very similar to how we blend ambient audio sources – a biome can be Normalized, Greedy, or Overlayed. Currently the behaviour of all biomes in Hurtworld is normalised, which means that the total weight of all biomes adds up to 1. Adding these two other modes means we can have additive biomes – like a biome that only adds a binary effect like NoBuild. The Greedy blend mode also opens up a different way of doing weather which might be a lot better. I’ll go into more detail with this when it’s more complete.

Tom

This last week I’ve been working on getting the 0.3.8.0 sleeper update finished.
The reason we added sleepers so suddenly rather than waiting until after ItemV2 was to deal with an exploit where people were logging off and then having their friends build over their position causing them to be pushed away when logging back in, with the right setup and a bit of luck people were using this to push themselves inside rocks and other terrain.
Sleepers stop this by adding a no build area around the sleeper, if the server you’re playing on has sleepers disabled then a different invisible sleeper is created that is just a no build area that can’t be interacted with.
These invisible sleepers have a timeout so they don’t stick around forever creating permanent no build zones but the timeout is long enough that someone would have to be seriously committed to be able to exploit them.

I also made a change to the way vehicle stats are updated that hopefully will stop a bug where the physics world became desynced from the main simulation after sending many redundant updates over a long period time (20+ hours), this was causing vehicles to move in strange ways after resting for a long time, sometimes penetrating through walls and other terrain. If you notice this still happening in 0.3.8.0 please let us know!
I’ve also had some time to work on ItemV2 fixing some bugs in the mesh baking system, extending our model viewer to work with the first person view and getting vehicles working.

This morning I’ve been working on a quick patch for the sleeper update to fix spawns after your sleeper is killed so you’ll properly respawn back at your totem if you have one. In this patch I’m also going to tweak the spear right click numbers a bit to make it easier to flip goats back up as it’s gotten a bit tricky after the last spear balance change.
This week I’ll be adapting the mesh baking system for vehicles and working on reimplementing all our current items under the new system.

Spencer

This week I’ve been mostly playing studio head, getting upto speed with what everyone else is doing and making sure we are moving in the right direction. I had a bit of a play with Cow_Trix’s terrain generation toolkit and have to say its pretty amazing. It really takes all the repetitive work out of map creation, meaning we should be able to pump out some sort of new map per month or so once we get rolling. I spent a bit of time refining the basic formula to the terrain, to ensure things don’t feel too empty or too small. I’ve now passed it back to Cow_Trix for further iteration.

I spent the rest of the week looking at upgrading our ItemV2 branch to the Unity 5.5 beta, there are a few features that we have been waiting on a while. This failed miserably, so I’ve settled for 5.4. One awesome benefit this brings is allowing us to re-use the same asset bundle builds between platforms. Meaning all workshop items will be 1/3 the size and build in 1/3 the time.

Lastly I ported our tooltip system to ItemV2. This week I’ll be back on bullet feedback in preparation for the ItemV2 deathmatch release.