Spencer

Things are ramping up a lot around the studio in the last couple of weeks. We’ve been working really hard on heaps of new stuff on our own for ages, and its finally coming together.

I spent most of this week working on planning the road to the ItemV2 release, and implementing a game mode system to support the official Team Deathmatch mode. I figured if we were going to use the deathmatch to iterate on guns, we may as well make it fun.

The main function of the game mode system, is allowing us to swap out logic for things specific to a particular game mode without having hacky checks all over the place to see what we should do when something happens. The game mode drives things like: spawning, scoring, giving equipment, friendly fire etc

This week I’ll be fixing a few bugs that came up in ItemV2 from our deathmatch tests, and improving the feel of the guns before unleashing it on you guys, hopefully the following week.

Sleepers on Logout

It’s been a long time coming, but we’ve finally decided to add a representation of your player in the world after you logout that doesn’t disappear until you connect the next time to the same server. This means your player is always vulnerable to being killed while you are offline. This solves a bunch of issues around people using themselves as unbreakable vaults while logging off, it also solves the issues around raiding a base, taking it over and not knowing if a previous owner will spawn inside your walls. Most importantly, some people discovered an exploit where logging off, building structures in the place where you logged off, then logging back in would kick you through objects. This can only be solved by leaving something behind when you logout that blocks building. This is one of the last steps to ensuring continuity in our physics system.

There will be an option to disable it and use the current functionality on community servers, however all official servers will use sleepers.

Patch And Wipe This Friday

This (and only this, not all the other stuff we’ve been working on) will go out this Friday along with a official server wipe. Wipes will not be mandatory for community servers. Checkout Toms post for more details.

Mils

Welcome to Grey Box Citeh… We have entered the grey box phase for the weapons now.  The image directly below is just a pretty render of an Assault Rifle and a Sniper Rifle.

These are based off the designs below, although slightly modified from the silhouette sheets, as we are thinking we can squeeze some of these into the existing animation sets. This will help speed up production.  These are low poly meshes, which will be mashed up until we lock in the form and function. There will also no doubt be a lot of detail geo added to make them more interesting.

I’ve been getting up to speed on our Static Mesh Baker this week too, so that I can send the goodies across to the coders for testing etc.

Tom

This week I was finishing up the 0.3.7.5 patch and then quickly fixing up the broken ladders for 0.3.7.6.
After this I was back into ItemV2, merging up the latest changes from live, fixing some bugs in our new mesh generation system and starting to get vehicles working again.
This didn’t last long though as we were quickly made aware of some remaining bugs and exploits and I was back onto patching them up.
As a part of this next round of fixes we are adding a sleeper proxy system into the game so you can no longer simply log out with your items to keep them safe!

Now after leaving a server for any reason you will leave behind a proxy of yourself in the world. Players will be able to kill the proxy triggering the standard loot drop for the server type.
If your proxy is killed you’ll respawn when you next log in rather than returning to your previous location.
Proxies run their own inventories and stats simulations behind the scenes so we can properly assign infamy and determine loot drops, this also has some other interesting effects such as items being constantly simulated (meaning your food will turn mouldy while offline). The stats simulation is not updated however so you can’t wait out infamy and you won’t starve to death while offline which would be frustrating and overly punishing.

In the future we’ll also also be able to things like let you open a players inventory and take some of their stuff or maybe you’ll be nice and leave them a new item (hey it could happen!), were going to save this kind of stuff for once ItemV2 is live because otherwise we’d have to implement it twice essentially and it’s not worth the time.
At the moment we are aiming to get this next update out in time for the next wipe on the 28th of November, we’ll be wiping the infini wipe servers with this update as well due to the way sleeper proxies are constructed on server start. We wanted the proxies to exist even if a server didn’t shut down correctly so on server startup we construct a proxy for every living player who doesn’t currently have one (players who have had their proxy destroyed are marked as dead so they’ll be skipped over in this process).

Gavku

So this week I ended up going through all the gear and trialing different paint methods, testing which items look good with global paints, and which should just have selectively masked areas.

All the hair and beard items I think work well with us enabling the player to affect the overall colour of the item, as do things like jeans.

Other Items like the packs would benefit more from selective masking.

I have also started making some new items starting with footwear. At the moment I have made some basic boots and basic sneakers.

Basic sneaker sculpt.

Basic boot sculpt.

In engine pic of basic footwear.

Cow_Trix

Hey folks.  This week has seen a lot of iteration over the map, and I think it’s getting to a pretty good place. This iteration also exposed a few bugs in the road system which have been fixed. Early in the week I did some work on the city suburbs, building out the CBD into suburbia, as well as a park area. I’ve also been working on the general play area generation and I think that we’re pretty close to something workable. Check out some screenshots below.

I also finally came up with a semi-decent solution to blending road segments together, which was mainly a thing of finding a shared boundary between the segments. If the boundary is deterministic from the start and end nodes, then the blending between two nodes will work fine. I still don’t have a great solution to blending between an arbitrary amount of nodes, but considering how we’re doing intersections as separate distinct objects that might be a problem we never need to solve. I also solved a bunch of bugs around rolling nodes, and editor-side bugs to do with selecting, deleting and moving nodes.

Mils

This week I did some exploration into producing a better type of metal finish for the guns we have been working on. The aim here is to create a more satisfying metal finish for the new weapons, which will make them feel more alive and ‘heavy metal’ The screenshot below may not be where this actually ends up, but is a step in the right direction.

I have taken the new gun designs in a slightly different direction. Instead of each gun chassis having completely interchangeable parts, we are going to keep the central body of each gun the same. So for example if I had machine gun, the grip and the core of the gun will now be one item. This will take a lot of the headache out of the component design and give the main body of the weapons a distinct silhouette. The issue with the first creature weapon designs was that the gun body generally ended up being a square or cylinder of a mix of the two. All of the design work so far will still be used, they will just be reworked to adapt to this new design ideal.

Gavku

I was sick for a lot of last week so not not a great deal on my end. Finished getting the new gear moved across and tested. At the moment am going trough some of the items and testing ways to apply paint-ability to them. Some basic items may end up being universally paintable with the colour changing the entire item. Something say like the tshirt. Or we may keep a basic set and allow logos and trims to be changed.

Other items we will wish to keep the overall aesthetic integrity of the item intact and instead allow the trims, stripes, tape etc to be altered.

Tom

This week I’ve been continuing to work on our character controller problems which unfortunately became a much harder problem to solve than I originally thought, delaying the 0.3.7.5 update.
Whilst my first attempts at solving the problem were able to remove the penetrating through walls exploit they introduced a lot of jitter and stuttering when colliding with vehicles which we decided was unacceptable.
This jitter was due to the delay between client and server making clients see vehicles slightly in the past compared to the server. What was considered an illegal move on the client and rewound due to vehicle penetration was considered legal on the server because the vehicle had already moved on out of that same position. This meant the client was corrected back into the vehicle by the server only then to have the whole process repeat. This was solved by changing the method of detecting illegal moves from physics checks to directly checking actual movement changes against the expected movement change and allowing for a significant margin of error (without being so significant that you could still ‘push’ through geometry).
I also removed the ability for a rewind to be triggered clientside by changes in the y-axis (up and down), instead just running them on the server and allowing the correction method to rewind the client over a number of frames which again reduced jittering. We’ve also slowed the speed of server corrections slightly which again helps to increase smoothness.
I’ve also tightened up our crouching method, previously we were just changing the character controller height which would also shrink the collider upwards from the feet (we did this due to strange behaviour when changing the controllers center and how it affected triggers, as part of this change we have decoupled the controller from triggers completely) which could strangely enough make it easier to walk up ledges while crouched and also allow the player to be pushed under the world by something pushing down on their head.
Now in effect we have the same crouch height with a more accurate collision volume, in practice however the minimum height you can crawl through has been reduced as you can no longer squeeze your feet under the world.

One upside of the patch delay is I also had some time to squeeze in a small change where you can now change your display through the graphics options, you can find this under Options > Graphics > Resolution > Display number.
As I’m writing this I’m building the release candidate for 0.3.7.5 to go onto devtest, if testing goes well (fingers crossed) we should be releasing this patch very soon.

Spencer

This week I’ve been integrating sub frame bullet events into the equipment pipeline based on last weeks experiments. I also changed the repeat method to use single audio files per bullet instead of 4 bullets per file to simplify the integration To ensure I had the same audio results, I constructed single shot sounds using snippets from the fully automatic clips and tails stiched on that get silenced when a new bullet is fired. This allows me to drive the audio system on a much simpler basis, as now only the state machine needs to know how fast the bullets will be firing. Results are feeling very good.

While adding back in the bullet sound emission to weapons, I spent a bit of time building a new sound layer that manages creation and configuration of AudioSources in Unity that allows us to define things like falloff distance, clip group selection details and distanced based clip swapping all at the sound level. By default, the Unity audio workflow is designed to have most of this stuff configured on the object emitting the sounds which really sucks. Given that a player will emit all sorts of different sounds with different falloff properties, you are forced to create a multitude of audio sources all with explicit configuration on every player. Now we can say, an un-silenced 5.56mm supersonic bullet has a logarithmic falloff with a max distance of 1000m, and is substituted for a supersonic crack if the listener is a long distance away, while a footstep can only be heard upto 20m away. Anything that wants to play either of these sounds will only need to specify what sound and where.

The other reason we need this is to decouple sounds from code (previously represented by an enum) so they can be loaded from the SDK using our new mod architecture.

Here is a test rifle in game running at a few different fire rates, previously every gun needed to fire at exactly 10 bullets per second, or 20 bullets per second so it would sync up with the 20hz tick rate.

This displays an interesting problem in that, as recoil is calculated per bullet, increasing the fire rate makes the recoil head a bit out of control. I will likely add a scaling factor to recoil depending on the fire rate that is generated for the weapon.

I will be pushing round 2 of our internal deathmatch build this week and should hopefully have something for you guys soon.

Cow_Trix

This week I’ve been further building up the map, and starting to make some real progress. I’m pretty happy with where we’re at in terms of the tools and workflow I’ve built up over the last few months. I can do everything I need to quickly, don’t need to worry about ever throwing away work, and can tweak some base variables and see the changes cascade up the generation. I’ve also been going back to the city, which still has a fair bit of work needing to be finished.

I also got started on implementing all the entity stats needed for water to work (i.e. kill you) so that meant starting to implement an oxygen stat that would make you asphyxiate. Implementing this made me realise how obtuse and confusing the entity stat system can be in it’s current state, which I didn’t beforehand just copying over old configurations. I’m still figuring out the best way to make effects like oxygen only care about the position of the player’s head – as it doesn’t make sense for someone to start drowning when they stick their feet in water.

I’ve added a framework for landmarks and structures to tell the generation what it needs to do to accommodate it. This is based a lot off what I’ve shown previously with intersections. Now, a structure can define several shapes around it’s foundation which the map generation will take into account when generating, removing rocks, trees and even hills to make way for the structure. While for a time I considered making even placing these man-made landmarks procedurally, I think we will have more ability to design if we are able to specifically place them.

 

We also now have a way to place trees explicitly in the tree system, which has meant that the city has come to life! The once empty planter boxes, parks and sidewalks can now have trees which use the existing, high performance system.

Spencer

This week I’ve been finishing off the missing parts of the gunplay system before pushing forward with deathmatch tests. Results from first iteration (which are things we mostly knew about) are that gun sounds and hit feedback needs a lot of work.

Gun Sounds

In the current version of hurtworld, the assault rifle has a lot of trouble maintaining a steady fire rate. There are a few reasons for this, one is aliasing between our update rate and the gun rate of fire not matching, another is rendering framedrops causing interruptions in the Unity sound engine.

I have an almost working framework for sub frame bullet events which should solve most of those issues, however actually synthesizing very fast firing bullet sounds well turned out to be not as simple as I thought. I managed to get some amazing weapon sound source material this week, which provided both full auto recordings and single shot recordings. To my surprise, playing single shots at full auto speed sounds nothing like the recording of actual full auto recordings (and nowhere near as good).

After some experimentation I settled on using time synced 4 bullet loopable samples scheduled with the Unity audio engine ahead of time, then scheduling early stop times when the player doesn’t actually shoot all 4 bullets of the audio chunk, then injecting the tail end of a single shot or burst shot on the end of the fire clip to ensure it doesn’t stop abruptly.

The only problem with this, is as the clips have 4 bullet fires instead of one, the rate of fire can’t be adjusted by simply playing the fire clip more often. What I tried instead was to dynamically scale the playback speed of the clip to the desired rate of fire so the loop still syncs up. This works nicely, but has one side effect of lowering and raising the pitch of the bullets, changing how the gun feels. For example silenced mp5 at 300 rpm slower sounds like a 50 Cal MG. I will likely build some auto loops at different RPMs and pick the closest, then pitch shift to the exact speed. The other option is to do a pitch constant speed modification to the clips, which I have no idea how to do. And from experience in audio tools, algorithms rarely output anything good without artifacts. The last option is to automatically stitch a bunch of single shots together with volume envelopes to make the blend better, I will have to give this a try to determine if I can achieve the same result as the recorded full auto.

Here is a recording from a realtime Unity project running at 20fps with massive garbage collection spikes happening (to test if the bullet stream is interrupted)

Mils

I have continued on with these more basic weapon type for the creature weapons. Getting a whole bunch of weapon chassis designs out so we can then select the first designs that I will end up making. After we decide on some designs and maybe do a little more concept art, we will probably do a bunch of simple grey-boxed models. These will help make sure we have all the pieces in the right places so we can cement the animations.

Cow_Trix

This week I’ve been working on implementing water, and iterating through on the map.

I implemented some cool water effects for the camera, so that when the camera is half or completely in a water volume, we can do cool things like change the fog parameters, apply a vignette, and do caustics or other distortions. This requires solving what I thought was a bit of an interesting problem – calculating the intersection point of a plane along the camera frustum. To do this, we need to get the intersection of the near frustum plane, and figure out where on that plane the water plane lies, and so where the transition between above-water effects and below-water effects needs to happen.

I also made some fixes to the water shader to deal with issues of how it looked when the sun was rising and setting, as it was taking far too much color from the sunlight at these times. It now will take more from the ambient when hit at an acute angle.

 

The map creation has for the past week been a process of tweaking values and figuring out the relationships between issues in the “feel” and play of the map, and the actual changes needing to be made in the map creation logic. To make this easier and so we have a predictable baseline, I moved a large amount of the common logic to shared sub-biomes. This means I can adjust parameters in one place and it will effect all biomes, which should hopefully speed things up a fair bit in terms of iteration.

Gavku

This last week I finished of the texturing and material setup for a couple of pairs of shorts, then moved onto getting setup with the item V2 pipeline. Following the setup I went through and generated skin mesh attachments for all the new clothing items I have been making.

To do this I drag a skinned fbx file that I have bought over from Maya into the scene.

Then select your desired skeleton via the radial button, and drag your mesh into the target character slot. Click the Generate SkinMeshAttachments from character button which will prompt you to choose a save file destination.

This will result in a skinmesh attachments file which you can select and apply any relevant material to.

Finally select the Character Default Setup in the Hierarchy which will allow you to select and place various skin mesh attachments into their corresponding slots.

Tom

This week I’ve been continuing to work on patching up bugs and exploits. A big thanks to all the community members that have been in contact with us helping us track down and reproduce issues.
Some people were still managing to push themselves through things with closing doors so I rewrote the overlap check to use the physics system, resized the colliders to be more defensive, removed any gameobject scaling and also slightly changed the logic that calls the check fixing some client side bugs and adding the overlap check to the client as well.
We also got some good reports with video about using the crash vehicle to glitch into rocks when getting up. I found a bug where the stand up overlap checks were slightly smaller than the character collider so I’ve fixed that up and also added an additional check using the same method as ownership stakes to see if the exit position is inside geometry.
I also fixed a ui bug where scroll windows weren’t resetting properly meaning you could scroll past some categories of crafting while using a workbench and then when you went into the handcrafted menu they wouldn’t be selectable.
I’ve also extended the radiation zones in the salt flats of Diemensland so you can’t hide in the corners of the map anymore, if you’ve got a base there you’ll want to move out before these changes go live.
Right now I’m working on adding some additional checks to the character controller when it interacts with physics objects pushing it around to make sure the character controller is still in a safe location and rewind to a previous position if it isn’t. This is the major blocker for the next patch so once I’m finished with it we’ll be ready to go.