So I took a little longer doing these limbs this week than I’d hoped. They came out looking sickballs though. This bow is really starting to shine as a quality weapon. I also put a fair bit of detail into the feathers so we can use them for world items in the game. I can’t wait to use this bow now. These match up well with the enhanced weapons texturing and use the full pbr workflow, same as the AR15 and AWM. I’ll do the Arrow and the Rest now which should take no time. I’ll be doing the 3 sets of gear for these then weight skinning them and they’ll go out with the V2 release, or maybe sooner.
This week I’ve been working on finishing off the meteor shower, implementing the art TehSplatt has been working on and bringing everything together for our new game mode. I wanted to have a lot of the stuff we are working on going into experimental this Friday, unfortunately things generally take longer than I had hoped and I don’t want to release this stuff in a half finished state like our last few releases. We are going to spend the extra time to get things right, meaning this week isn’t looking good for a content patch.
At this point we will be just doing a wipe on experimental with bug fixes.
Here is the meteor shower in action:
The things left to do with the dynamic hotspots are to figure out how frequently they should spawn, what items they should drop, how they should interact with bases, and how to rebalance static loot to make room for the added items from meteor showers and air drops. This is the part we often fall short on after implementing a new mechanic. It doesn’t matter how cool the effects are if the stuff that you get from them is useless or unbalanced. This will also tie into how the truck fits into the game. The truck is slow, annoying to drive, and easy to highjack so we need make the reward big for using it.
Heya folks! This week I’ve been working on various bugfixes, the new in-game map, and polishing little bits and pieces. Firstly, through using the map and comparing it to maps in other games, we realised how important continuous motion was in being able to do things like focus on a single point while zooming and panning, so I went about changing the behaviour to interpolating between target positions and zoom levels, instead of just immediately snapping to them. This meant a bit of a rethink about how we were invalidating an recalculating things, so we were saving as much performance as possible. Recalculating the UI layout in Unity can be an expensive process, especially if you’re using a map with many markers, so we wanted to minimise how often that happens. It is still possible that lots and lots of markers will slow the map down a lot, and in the case where that becomes a substantial concern, there is the possibility of rendering the map to a texture which we then display, as opposed to moving a transform with a complex hierarchy below it, which will eventually bring the framerate down. I also implemented a zoom-to-cursor functionality, and the ability to remove your waypoint marker once placed. These quality-of-life features will roll out in the next patch and hopefully make the map feel a lot better to use. If you guys have any other suggestions for making the experience feel better or more intuitive, let us know!
In other optimisations, I was a bit all over the shop. I optimised the construction shader to remove a whole bunch of unused shader channels that were left over from development. I also fixed a bug where construction items weren’t initialised properly when they were first equipped and couldn’t be placed until they were reequipped. On the SDK side of things, I made some changes to the road tool which removed a previous restriction, in that the order you placed road nodes mattered in how the road bent between them. I also experimented with some tools to improve map FPS, including a tool to automatically delete geometry below the terrain that seemed to give a fair boost to FPS. More experiments on this are needed.
This week I’ll be continuing to polish features and fix bugs. The Bug Report forum on the Steam discussion board is the best place to have your say on the critical things that need fixing, so make a post if you something is really bugging you.
This week was spent making some quality particle systems for the meteor and meteor ground explosion. Last week was my first attempt at some sort of explosion using particles, and the intial results I got were pretty terrible, but I’ve learnt a lot through the week and ended up with something that, while it could be better (pretty typical in art), I feel has the epicness and scale that I was trying to get across. You can see below the comparison between day one and the final version. The first one uses static images as particles which make everything look like cotton wool, while the final version uses animated sprite sheets which give the particles a realistic and lively feeling. Another thing that helps a lot is bloom, which gives the flames that intense brightness more inline with a realistic explosion. You can see the meteor trail particles in Spencer’s video, the meteor originally had a blue glow around it but due to the flames being added over the top the final result is a green glow which I like so that was a happy accident.
I’ve also started working on a Substance material for the meteor that you will see after it’s landed. It’s still in very early stages but I currently it set up so you can controll the amount of cracks and lava which might be useful for animating down the line.
This week I helped push out 2 bugfix patches, re-enabled destructible vehicle attachments (shooting off wheels is coming back) and continued to iterate on the Slug.
The first bugfix patch (0.4.8.1) was largely to address an OSX issue where the input system had become corrupted and was not being loaded properly, this was an issue that would frequently pop up when creating builds from my machine but thankfully it now looks like we’ve gotten to the bottom of it and our OSX releases should be more stable from this point on.
The second bugfix patch (0.4.8.2) was largely to address a bug in the mesh baking cache system where meshes could suddenly disappear. This system basically saves combined meshes so if we need that combination again we can quickly look it up rather than having to do the combine job again. Because we have hundreds of mesh attachments this leads to more potential combinations than we could store in memory at once, because of this we need some way of removing combined meshes from the cache to make room for others. To achieve this I’m using a reference counting system where each use of a mesh increases a counting variable, when we release the mesh (like when a ragdoll despawns for instance) we decrease the same variable. When it comes time to ‘trim’ the cache we can scan through it looking for any meshes with a 0 reference count and know they are safe to remove.
This bug occured because I wasn’t adding to the reference count when the combined mesh was first added to the cache, this meant if only 1 system was using this mesh on your local PC it could be incorrectly cleared.
Another change I added to 0.4.8.2 is options clamping. Now when the game loads or any other time your options are loaded we validate the config being loaded where possible by clamping the values between their min/max values. This means that if you had a previously valid config that has recently become invalid it will now be set back within a valid range rather than allowing you to keep a previously saved config (like when we changed our field of view min/max a few months ago).
I’m mentioning the field of view change because I’ve received some comments that our new FoV max of 80 is too small, the truth is there are two ways to measure field of view, horizontal and vertical. Currently we are measuring vertical FoV because thats how Unity handles it with their camera components but most games measure it horizontally.
For a standard 16:9 monitor our max of 80 equates to about 112 horizontal FoV.
I will look into changing our options config into horizontal FoV soon.
I’ve also been continuing to tweak the slug handling by reducing the engine power even further, increasing the weight slightly and adding a placeholder heavy slot which increases the weight of the Slug by 50% when its loaded!
I’ve also setup a system for storage slots to bind to hitbox types so we can setup passing damage through to an item’s durability and I’ve started to setup vehicle wheels to be destructible again in this way.