Cow_Trix

This week I’ve been testing and writing documentation for the new modding framework, and the creating of Construction Packs. I’ve also been preparing for the next patch – more info below! All hosted on the official wiki, you can now read how to Create a Construction Pack, Install a Construction Pack, how the Construction Attachment Editor works, and more! I also brought all the other modding documentation up to date, as a few things have changed. There’s still a bit to do, as testing the modding framework has led to a few changes over the past week. Whereas before I had thought of the architecture as Levels, Construction Packs, and then whatever we added in the future, after some discussion I realised that it’s really Levels and then an overarching additive Mod category, as we want mods to be able to incorporate multiple levels of custom content. For instance, a mod should be able to package up all into one custom vehicles, construction pieces, dynamic objects, and all of that, in any combination.

In between writing documentation, I put in a bit of visualization for construction attachment rotations. Now, you’ll be able to clearly see when an attachment point in the construction system has multiple rotations, what those rotations are, and what rotation you are currently on. This should make multiple attachment rotations a bit more intuitive.

I also have been working on getting basic networked entities into the SDK. At this point, you’ll be able to spawn dynamic objects into the world, but they won’t be able to do much. As of the next patch, we’ll probably support dynamic networked rigidbodies, which will sync their positions. Which, I reckon, you’ll be able to do some very, very cool stuff with, when combined with Oxide! This will be a huge boon for those mods, which will now be able to use custom assets as well as in-built ones.

We’ll be aiming to get this patch out by this Friday, the 24th of June. This patch is not backwards compatible, so all servers will wipe when upgrading. This is always unfortunate, especially for community servers that prefer to never wipe. However, I know most of the official infin-wipe servers are aching for a wipe. This also means that the 14-day servers will actually be 7-day servers for this cycle.

Gavku

So I have finished up the MP5 and it looks to be a good test case for weapon attachment/modifiers. I may end up tweaking a couple of the maps slightly once we have it on the player and can accurately view it in first person etc, but I think in general its fine especially for a stock standard smg.

Having the multiple scopes will be fun as we currently dont have any in game atm. Next up for me is to jump back on to character gear 😉

Mils

I have been testing performance with our new grid culling system which I covered in the Devblog a couple of weeks ago. I did some tests using different sized grids with different culling distances as below;

Baseline test – No Culling

Culling 100×100 metre 50% cull distance

Culling 50×50 metre 25% cull distance

Culling 200×200 metre 50% cull distance

We didn’t get great performance out of these and realised that the culling result was being applied based on the bounding box of the tallest object and how much of the vertical screen-space it was taking up. What is preferable and simpler for us is to set distance culling per grid square. This would be calculated from the center of each grid space to the POV of the player.

So Tom is busy fixing the culling tool (amongst other things) and in the meantime I am pushing on to the suburbs and industrial areas around the city.

The suburbs are going to be achieved by standalone one unit structures, spaced out around the road network.

Above shows the same building just rotated 180 degrees. Where possible I will try to create buildings that have a dual frontage design. This will allow us to flesh out the suburbs quickly.

Swapping textures will also help use the same meshes whilst having a bit of visual difference. That said I would like to get a few different designs into the house zone.

Below are more versions of the same house simply with swapped textures. Makes quite a believable neighbourhood with the added fences.

 

Tom

This week I’ve been hunting down bugs in our vehicle system, a big thanks to all who contributed to the feedback discussion thread and helped with pinning some of this stuff down.
First up are the infamous vehicle launching bugs. This one was a tricky one as there were actually two separate issues that both caused the same behaviour. The vehicle launching bug occurs when the vehicle and an object that isn’t being simulated by the physics engine overlap. This causes a force to be applied to the vehicle to push it away from the overlapping object. Unity gives us a way to set a limit on this force but a bug causes this limit to get reset every time the vehicle is disabled and re-enabled. Now we are reapplying this limit every reset so objects like loot crates and resource nodes can no longer create huge forces on vehicles launching them into the air.
The other big launching bug comes from players, more specifically their character controller which is a special capsule shape collider that provides a nice controllable way to move a character around and collide with the physics engine. Remember that force limit I was talking about before? Unfortunately a bug means it is totally ignored when physics objects overlap with character colliders allowing vehicles to be launched into the air by players standing in them. This was very easy to achieve using a spear to lift a vehicle and crawling under the opening.
This has been fixed by listening for player collisions in the physics update and if any are detected that are generating a large force then the vehicle velocity is reset to whatever it was before the physics step. Here you can see a before/after gif of the behaviour.

Speaking of flipping vehicles with the spear, I noticed this was very inconsistent and tracked down another bug in the way the collision check was being applied. You can now aim the spear with the crosshair to flip vehicles rather than looking at the ground. The vertical offset that was being applied to the collision before has now been moved to the flipping force so you should find this behaviour a lot more consistent and easier to use once these changes go live.

I’ve also been looking into how the vehicles and landmines play together and tracked down another bug with how explosive forces were being applied. Previously we were applying the force for each collider in the vehicle when it should have only been applied once for each vehicle. Because a vehicle can have a different number of colliders based on its configuration and vehicle type this was leading to some pretty inconsistent behaviour.
Here you can see a before/after gif of a roach running over a landcrab mine.

I’m also looking into reapplying explosive damage to the driver in these situations as a temporary fix but ultimately we need to make the vehicles destructible and it should be the exploding vehicle that kills you rather than the exploding mine.

Several people on the vehicle feedback thread brought up the need to be able to crash the motorbike. I agree with this both from a realism and a gameplay perspective so I’ve started working on a crash system. Generally in a crash system you want to ragdoll the player and let the physics system sort it out. Unfortunately in a networked game you either use a lot of bandwidth syncing up all of the player skeleton accurately or you run into desync issues because most physics engines aren’t deterministic meaning given the same inputs there is no guarantee of the same output. This is why we run all our vehicle physics server side.
So far I’ve been experimenting with running the torso of the player server side and then running physics on the limbs on the client. This keeps the player position in sync even if the exact ragdoll pose isn’t which gives us relatively consistent behaviour without a huge overhead on the network.

Whilst the motorbike and vehicle overhaul are still a ways off we should be able to push the bug fixes with vehicle launching into the next patch so look out for that.

Spencer

Last week I’ve been working on upgrading the ballistics system to bring it inline with ItemV2. The first area of focus has been moving projectiles from being what we call first class entities into a system that is managed in a central point. As none of our bullets are hitscan (no travel time), we have to deal with the extra challenge of client side predicting real world objects that are constantly being created and destroyed. If we didn’t, and just waited for the server to spawn the bullet before you see it, there would be a very noticeable delay when firing a gun, especially on higher ping servers.

To prevent the problem of your client needing to predict an entity that doesn’t yet exist, we cheated slightly by spawning the bullet projectiles for the gun ahead of time. The server sends your client a message when you equip the gun saying “The next bullets you fire will be entity: 125,128 then 141…”. When you fire your weapon, your client looks for the next bullet in the list and fires it predicatively, knowing that the server will be firing the same entity once it gets the message that you fired.

This method has heaps of overhead, as with an automatic rifle, the server is constantly instantiating fully networked entities and sending queue messages to the client upto 20 times per second. Sometimes one of these packets can get lost, causing the client to predict the fire of a different bullet than the server. This is pretty easy to detect, but requires the entire bullet buffer be thrown away, re spawned and re queued. I’m sure most of you have experienced this when your gun won’t shoot for a couple of seconds for no reason, quite often resulting in you getting killed.

The solution I’ve been working on this week, is downgrading bullets from first class entities to virtual objects managed by the ballistics system. The ballistics system is a single networked entity that is responsible for all bullet projection, hit detection and visualization across the entire game. Now when a bullet is fired, the ballistics system is notified with all the relevant properties of the weapon, it can first create a local predicted bullet on your client and create a hash of the event that created it. By using the exact time tick when it was fired and playerid that fired it we can infer a unique enough identifier for the bullet that the server can also automatically determine at fire time. Meaning no pre-sharing of bullet sequence is required. The second benefit to this is bullets will use a fraction of the CPU time and eliminate all garbage generated as we can properly pool the local virtual entities without upgrading them to the network system.

Part of this will allow us to bring into line, what the person who fires sees and what everyone else sees. An example of this is when someone other than you fires an arrow at a Shigi; it dies, but on your screen there was no blood splat or hit sound, just a dust puff. By tweaking the responsibility of how the effect is generated, this should come back into line.

My second focus last week was improving the melee swing mechanics. Previously all melee weapons were a directly straight raycast from the center of the screen over a couple of frames. To more accurately represent the movement of the weapon I have introduced a fully configurable projection setup. Each weapon can model their swing arc using either a sphere cast or capsule cast. Like everything else I’ve been doing lately, this fully supports modding.

This week I will be nutting out the long awaited recoil system.

Release Date

Folks wondering when this stuff will make it into the game, we are still a couple of months out yet for all ItemV2 stuff. The main reason for the delays are the change of architecture requires a lot of re-implementing how items are built. Whenever I come across something that needs improvement, it pains me to port over sub par system and is much quicker in the long run to bring them upto scratch while I’m working on them.

Tom

This week I’ve been working on the vehicle system and adding an all new vehicle type, motorbikes!
It’s still in its early stages so you’ll have to forgive the programmer art and the use of the goat rider animations that don’t quite fit but here’s a peek at whats to come.

I’ve been working hard to find the sweet spot between simple arcade style handling and full physics simulation.
Due to our low minimum specs and our authoritative server netcode (where the vehicle physics all run on the server to ensure consistency and stop cheaters) we need to be as efficient as possible with our simulation which pushes us more towards a basic arcade style. On the other hand the large open world, player built housing and the SDK throw a huge variety of situations and terrain at our vehicles and if we go too far in the arcadey direction then there will be too many edge cases and strange situations that the physics will not be able to deliver a satisfying simulation for. This point cuts both ways however as full on simulations generally only work well in specially designed racetracks.
Another consideration is our control scheme, the current ‘wasd’ + mouselook system only gives 1 digital axis for steering which doesn’t allow for a lot of fine control, again steering us more towards an arcade model.
I’ve developed a semi-automatic balancing system that applies a torque to balance the bike towards a target lean angle. This lean angle is influenced by the speed of the bike, previous lean angle, the camber of the ground and the player’s steering input. With the right tuning this gives some nice behaviour where you can lean further into banked corners  This system is also cheaper computationally than the cost of simulating another 2 wheels which I’m very happy about as I was worried our requirements would force us to have leaning as just an animation on top of the physics layer.
Whilst it still needs some tuning and still has some edge cases I need to iron out, we get some nice physics that behaves well and is fun and interesting to play about with just ‘wasd’.

I’d love to get some feedback about what you’d like to see from motorcycles in Hurtworld as well as feedback about our vehicle system in general, I’ve posted up a thread on the Steam discussion forums here so please jump in and let me know!

Spencer

More progress on ItemV2. This week I’ve been mostly focusing on how we synchronize equiptment state machines on proxy players (players you see that aren’t you). This is a slightly different problem than the server and your own player, as both the server and your player have all the information they need to drive the simulation on their own without help. On the proxies, they have no knowledge of input controls, impacts etc and therefore need some extra information sent to them by the server to ensure they stay in sync.

In our current system, you might notice things like shotguns being shot at you making a fire sound at a different time to you taking damage / dying, or players not looking like they are aiming at you when they fire yet still get granted a hit. This is usually caused by deficiencies in our architecture for synchronizing player proxies.

There are a few possible approaches here, the main challenge is sending as little information as possible while keeping everything in sync. The more frequently we send updates the higher load on the server bandwidth and more chance of lag / less things overall we can do per server. The second challenge is building a sync layer that doesn’t require custom logic to be written on a per item basis like we did in the previous system. If we can synchronize transparently without knowledge of the item or specific scenario we are catering to, modders will have complete freedom over how they use the state machines and have to do very little work to ensure everything connects up nicely. Thinking about how things are networked is tricky, so the less of that everyone (including us) need to do in future the better.

The working solution

The solution I am working with currently is running a full state machine on the proxy, progressing state positions based on things like attack speed, but not executing any transition or event code. Instead we serialize a very efficient byte stream from the server of when and where a transition happens. As there are only ever a few possible targets for a transition, and the movement updates are already being sent with time information, we can compress the transition and event data to only a couple of bytes per transition. This adds up to a negligible amount of data while ensuring that everything stays 100% in sync.

Fast Firing Weapons

The next part of the Item system I’ve been working on this week is ensuring we can handle sub frame events. More specifically, if a gun is firing at 17 times per second and the game updates at 20 times per second, that we don’t get a stuttering mess. Currently we can only emit events on each update tick, meaning we can either chose to fire now or wait until the next tick. If we are exactly in sync with the update rate (10hz or 20hz) everything works fine. If we want to update at 18hz, we would require a timespan between bullets of 1/18 seconds which could never sync up with intervals of 1/20 seconds. What you get instead is stuttering bettween 1/20 and 1/10 seconds (similar to if you have vsync turned on and can’t get 60fps).

The solution to this is part of state machine design, where events can be emitted from the state machine with an exact time delta from the state of the tick (tick being 1/20th of a second). In effect we do partial ticks for the equipment system then store the resultant events that are emitted in a time accurate buffer to have their sounds (and possible visual effects) played at exactly the right rhythm at any frequency.

This is 90% working now, I am lastly figuring out the best way to try to give the sound event information to Unity slightly ahead of time so laggy machines have time to get the audio buffer ready and won’t miss a beat.

Overkill?

While this is probably overkill for your average survival game, we are doing our best to raise the bar to what is expected from other shooters. I think its worth the extra time to get the foundations right as we have with many other gameplay systems. Better gun play is never going to be a bad thing.

You guys are amazing..

We’ve been constantly blown away by the awesome stuff our community has been creating with the tools available, hence why we are working so hard to give you more powerful ones… We just stumbled across this today, which I would have probably told you this wasn’t currently possible without client side mods. But it looks like the creators found an old unfinished meteor prefab in our assets and fixed it up and completed it.

You can download the mod for oxide here:
Meteors for Hurtworld | Oxide

Mils

I am filling up the building interiors with low geo items that you would expect to find inside office buildings. I have a couple of different coloured sets of office cubicle walls, lobby desks & those couch bench-a-muh-jigs. These help create hiding spaces for fire fights, occlusion & to place loot crates or other items behind.

It takes time to place these due to the individuality of the building shapes and trying to move the items around in each building to create difference.

I finished off adding in the shop fronts also. These have large windows that actually span two floors in height now.

Gavku

Not a whole lot from me this week as I have been bouncing around on this smg testing a few things. However I now have an in game mesh built with its normal map and ambient occlusion all baked out. Next up is to paint up its diffuse and spec maps. If I want something to be heavily damaged and worn I will usually take it into a sculpt program, scuff it up, and bake it out. but when the damage is lighter surface level damage I tend to just generate a normal map from a height map that I paint up at the same time as the diffuse. In the case with this smg I will be going more a lightly scuffed up look.

Cow_Trix

I’ve mainly been working on getting the modding stuff done and out. I’ve created a new branch for the Hurtworld SDK called “experimental”, that anyone can switch to on Steam. Check it out if you want to get a head start on creating some awesome construction packs! I’m working now on some documentation for the SDK, as the construction system can take a bit to get your head around.

I managed to tackle the main restriction on the construction system, which I previously mentioned: custom construction attachment types. Each construction attachment has a collection of attachment points where other attachments can connect, and each of these points has a “type”. For instance, a wall piece has a “floor” attachment point at the top, so you can attach a floor to the top of any wall. Before we just had a list of types that both the client and the server knew about beforehand, and that never changed. But I wanted to give the option for mod makers to make their own types, and not be restricted by ours, so we had to move to a dynamic system where mods registered their custom types, in a way that the client and server can agree on. Mod makers can also now cooperate and create common custom types shared between mods, as they’re just based on a name. Also, as a server can choose not to load the default construction pack, and we include the default construction pack assets in the SDK, it is possible to include custom attachment types in the default pack by rebuilding it.

For the next week I’m on documentation, although I hope to get it done sooner rather than later. While documenting I might find some issues that need resolving, but once that’s all done we’re ready to go! We’ll just need to push out a client/server patch with attachment support, and configure the workshop so it’s a bit more organised.

Check out the documentation here. And I’ll be answering any questions relating to the system here. Enjoy!

Gavku

So some more character work and some weapon stuff from me this week. Having blocked out some character forms I needed to wait for them to be rigged and skinned so that we could eyeball the defamation and general shapes. So I moved over to creating some of the new hair and beard styles as they aren’t effected by skinning. Trying to get a better spread of shape variety than the ones we currently have in game. The textures aren’t final as we are planning to bake a bunch of these down onto one texture atlas.

We plan to have modifiable weapons, with a variety of attachments. So to test this we will use a pretty stock standard MP5 and give it a couple of scopes, stocks, silencer, and clip sizes. If this all works they way we want it to, we will go about adding a bunch more, both stock weapons and ones with more of a Hurtworld feel 😉

Cow_Trix

I’m in modding-town this week. You may have seen a new item appear on the Workshop in the past few days. It’s my little test mod for the upcoming expansion of the SDK! The Shigi Statue. Not a high-quality mod by any means, as that model is some real programmer art, but it does look pretty neat in a base!

All the ground-work is laid, and architecture built as far as I can tell. Probably still some kinks to iron out, but at this point you can make a bunch of construction attachments in the SDK, export them out as a package, upload them to Steam, and then just by putting a line in your server’s autoexec, it’s in and working! You can only add items to the Construction Hammer at this point, although we’ll be able to do items soon when ItemV2 goes live.

So how will this all look to a mod maker who wants to create their own set of pieces? Well, I’ll be making some documentation to explain in detail how everything fits together. You won’t have to do any coding or anything like that, and for the most part I think you’ll be able to find an existing piece in the default set that is similar to what you’re making and just adjust the configuration slightly. You’ll be able to use your own models, textures, and materials all native to Unity, or use our existing assets (which will make your mod super duper small and quick to download!). A server can also choose to not load the default construction pack if they want! So you’ll be able to do mods that completely replace the default set!

And how will it look to players? Well, you’ll just join a server as usual, and it will download whatever mods it needs. And you should be good to go! Workshop handles all downloading and updating. Good on ya, Valve.

There’s currently a few limitations that I want to try and get rid of before we go live, like the ability to define your own construction attachment point types in a mod. But we’re most of the way there. As always – I can’t wait to see what the community does with these tools. And I can’t wait to extend them even further!

Spencer

Some good progress on ItemV2 this week. I’ve been punching on with the Unity animator system to allow me to drive our equipment animations explicitly while still letting Unity’s Mechanim drive things like walking jumping etc.

There are some cool APIs called Playables that are almost usable, but do to the fact that additive blending (layering animations over eachother nicely) are missing we are restricted to a few nasty hacks. Specifically the hard part is doing smooth transitions between equipment animations while explicitly setting the position in an animation we are each frame. The reason we need to drive the animation position each frame is to give us the ability to do things like attach a magazine mod to a weapon that gives 20% faster reloading. Trying to propagate that the speed of the reload animation needs to be increased, and by how much to ensure it doesn’t get out of sync with our simulation state machine is very tricky. What we do instead, is tell the animator each frame:

Set animation player to “Assault Rifle Reload”
Set animation position to 30% of the animation
Render Frame
Set animation player to “Assault Rifle Reload”
Set animation position to 31% of the animation
Render Frame
…

This works like a dream, and allows the state machine to drive the animations without double handling and leaving places for the animations to get out of sync. The problem comes in when we try to cancel the reload. We want to smoothly interpolate back to the idle position or to another animation. There is a Crossfade method we can call, however as soon as we tell the animator next frame where we want it to be, it trashes the Crossfade snapping to the new animation which looks like balls.

To workaround this, we were forced to drive the speed of state on the Equip layer by a generated parameter, and only explicitly tell the Animator where to be when it isn’t where we want it. If everything is working correctly, we set the speed of an animation before playing it, and call Crossfade whenever we want a change and allow it to play out. If we detect it has drifted from our own State Machine simulation, we force it back into place and let it keep going solo.

This is working like a dream now. What this means for us, is that we no longer need to think about how equipment animates. We build our equip state machine that controls the logic and don’t need to double handle anything. We can also now modify on the fly, any duration or speed property of any state in our simulation by parameters like Attack Speed, Reload Speed, Fire Rate, Draw Speed, Bad Melee hit recovery etc without worrying that synchronizing our animator is going to be a nightmare. As these properties are liquid, we will be generating random bonus values when procedurally generating items, rarely will you see 2 items that are created equal!

Once again, all these systems are completely modifiable as Equip is mostly state machine configuration which writes out to JSON.

Here is a complete state machine for the melee weapons in action in all its client side predicted, perfectly deterministic, arbitrary configuration driven glory:

Mils

‘Keep your City Beautiful’ Is not my motto.

I’ve been throwing garbage all over the place, trashing the city. I made some sets of boards that litter the streets, these help break up the road texture. I’m using geometry currently, which may change to a decal system in future, where texture is applied to create a similar effect.

When building the city I use a system of making geometry then fitting the geo into a part of the texture sheet that looks good. This means we save on texture memory and load times. The only downside is that we don’t make as many unique textured objects. The upside is we don’t end up like GTA V and have a billion year load screen and better performance. This is important, because we have a lot of players running some lower end machines.

I have added some fenced off areas with sea containers to reflect perhaps a quarantine/walking dead/martial law type vibe. This will give players some cover when moving up or across streets and helps fill the streets and break up the playspace.

I’ve changed the bottom floors to a two storey internal lobby situation. The shopfronts have changed to reflect that also. I will probably make a couple more general shopfronts to mix this up a bit.

 

Tom

This week I’ve been diving deeper into our equipment system working on integrating baking into our code base. With Spencer’s help we’ve been working on a new skinned mesh data format that will give us both a nice format for sharing custom gear through asset bundles (that can then be shared through Steam workshop) as well as allowing us to spread out the baking process over several frames to eliminate any frame rate spikes.

The plan is to distribute our base character model with the SDK allowing anyone to create their own equipment and then skin it to our characters skeleton so it will deform properly under animation. Once this step is completed there will be an importing step as part of Shigi Tools that will convert the mesh into our new format as well as run all the preprocessing we can to speed up the bake.

Generally when meshes are created they only store references to the bones that deform them (i.e. a character’s shoes don’t need to know anything about the arm bones).
Whilst this is efficient memory wise it creates a problem when baking as the final mesh needs to know about the entire skeleton, which requires joining the bone lists together and then updating the bone weight references to ensure they still point to the correct bone in the new list.

Another potential problem is when 2 equipment pieces are created and share the same bone (ie. the hats and the masks share the head and neck bones) but don’t share the same space (i.e. The hat might have its origin at the neck and a mask might have its origin at the nose). When this occurs you get conflicting data about the bind-pose for the bone (and this is what was releasing the kraken last week). The bind-pose represents the position of the bone in the skeleton when the mesh was skinned to it (relative to the meshes local space) and is used to transform the mesh into the proper position under animation. In the shot below you can see that the head model and the hair model have a different origin and orientation, you can also see the bind-pose for the neck bone according to both meshes, because bones to bindposes have a 1:1 relation per mesh we need to make these the same values. To solve this we have to transform all the meshes into a shared space (the characters root usually makes the most sense).
Luckily all this processing doesn’t have to be done at real-time if we push it into an import step when creating the asset.

It’s still going to be a little while until this stuff shows up in game as it’s being integrated into the larger overhaul of the item system that Spencer has been working on.
We’ve still got testing and things to work out with the best way to handle customization and random variations but we are really excited to see what you guys will come up with.