We will be releasing a small update for the raid drill on Thursday. See below for details.
Three concepts I have been working on for the Kanga dirt bike are mostly done. These are nearly ready to move into the modeling stage. There are still some elements I want to change to give each body kit a unique silhouette. The base bike also may need some polycount reduction, which I will address once I get the low poly modeled for the body kits. My target polycount for the base bike whilst equipped with any of the body kits and a set of wheels is 10,000. This is about what the Goat quad bike sits at.
So this week I had to get up to speed on our skinning pipeline as there was a few roadblocks that would occasionally arise forcing me to jump back and forth on multiple tasks. Chris (Dazzler) took me through it in a fairly thorough manner and so far so good. I used this to skin up a smoother version of our player model onto the game rig so that i could pose it in a way that generated better results out of marvelous designer.
I used this new pose to start the initial geo for a player jumper, which I then go through to the entire gear creation process and came out with the jumpers below.
I have also started to further unify the look of all the player assets which has meant going back to facial and head gear and treating them the same way as the rest of the gear ie: baking out normal maps and setting up their shaders.
The raid drill is pretty much done! I’m just waiting on some icons, and polishing up some of the client-side effects. It took me a while to nail down a mechanic for the drill. I previously mentioned how we wanted it to be something that you couldn’t just set-and-forget, something that would require some attention while it was running. I originally implemented this whole thing where it was all these counteracting forces, and you could set how much coolant you pump in to cool it down, and the RPM would drive the temperature up, and it was “realistic”. But while it did end up quite nicely simulating a real thermodynamic system, it didn’t end up being particularly fun or intuitive.
I ended up vastly simplifying the system into something a bit more arcade-y. The main mechanics are still heat, and jamming. Running the drill at a high RPM will mean you do more damage with it, it runs hotter, and jams less. Running at a low RPM means that you do less damage, it runs much less hot, and it jams more. The trade-off then is how long you have to react to a jam. When running the drill at low RPM, you will have substantially longer to react to a jam before the drill overheats, catches fire and blows up. At higher RPM, you may only have a few seconds.
Another element to the raid drill will be recrafting it. When the raid drill breaks through a wall, or is disassembled, it will break into three component parts – the base, the motor, and the drillbit. You’ll need to pick these pieces up and recraft them back into a drill, in a workbench. This should hopefully make players be quite choosy and careful about placing the drill, as it’ll be a few minutes before you can re-place it.
I also finished up on the UI, which included a bit of new feedback for item slots, where they can now have a progress bar. In this UI they will show the use of the fuel and coolant, but later I think we can use these for showing things like durability.
As I have a habit of doing, I also did some small improvements to some other areas in my spare time. Removing building pieces with the hammer has changed. Now, a ghost will appear that will show you exactly what you are removing, and the removal is based on a raycast rather than removal points. To me this feels a bit more intuitive and less likely to remove things you didn’t mean to.
I also implemented basic structure decay! This means that when a structure is in an unclaimed territory, and has not been altered by a player in an amount of time, it will begin to decay. Given enough time, it will decay entirely. The purpose of structural decay is to decrease the buildup of garbage on long-life servers. While stake-decay has improved this a lot, there is still a fair few situations where structures are left abandoned, and are either to inconvenient for other players to destroy completely, or it’s just not worth it. It will also show a clear visual indication of what bases are abandoned as well, as they will be visibly damaged. We think this is another step towards servers being truly infinite-wipe (although don’t take that as me saying that all servers being infinite-wipe is something we’re moving towards). Of course, structural decay will be totally configurable and able to be turned off, for community servers. So, some questions for you all – how quickly should abandoned bases decay? How long should a structure be abandoned before it decays?
This week I’ve been working on vehicles again and everything is getting closer. I’ve moved the motorbike and all the wrecked vehicle corpses over into the sdk along with the ‘crash vehicle’. The crash vehicle is essentially an invisible vehicle the player enters when crashing and can’t exit until the crash is over (which is how crashing runs behind the scenes). This will allow local and custom servers to mod motorbikes and the crashing behaviour (things like damage amounts, collision thresholds and if and how the vehicles can crash) as soon as the changes go live.
I’ve also been extending our suspension system so wheels can now have suspension paths that aren’t straight up and down the vehicles up axis. This allows us to animate the front suspension in a more realistic manner. I’ve also created options to animate parts of the vehicles using simple ‘look at’ targets. Making the motorbike swingarm look at the rear wheel through this system is how the rear suspension is being done. Again this will all be available in the SDK and will apply to any vehicle type, not just motorbikes.
I’ve also been working on doing more with the vehicle stat system. Vehicles now transition between healthy and unhealthy states depending on their health switching various visual effects on and off. I’ve also hooked the vehicles up so they are tracked through the environment properly and can be affected by things like heat and wind. Now rather than just have a script turn on flame particles after a vehicle explodes we can have it triggered by the heat of the explosion. I’m hoping this will lead into other cool emergent behaviours like cooking meat on an overheating vehicle or using Mondinium campfires to burn up a garage from the outside (can’t promise this will make it through balance testing!)
This week I’ve been working on the ballistics system rewrite and implementing our new hit verification system. During development we had server side hit verification running properly, however due to it constantly breaking and denying hits that should have been allowed, we were forced to disable it. This is back up and running again, and bullets use a fraction of the CPU and bandwidth they used to. Although not a high priority, this system was a blocker for the recoil system which definitely needs to go in as part of ItemV2.
I’ve also been looking at ways to fix the 3rd person sight / cross-hair so that its actually accurate.
This is a logical problem rather than a bug. If you are looking from an angle different from where the bullets are fired from, a dot on your screen won’t represent the bullets path, instead the bullet will move across your screen requiring a different aim depending on how far away the object you are shooting (as you can see in hurtworld now)
Other 3rd person games cheat here, they do things like raycast from the third person camera to determine what is being looked at and then aim the gun towards that point.
This works fine for hitscan weapons (bullets doing their full cast in the first frame), if you are aiming at your target you will hit it. If the bullets are projected like say a bow, this gets significantly harder, as most of the time you won’t be aiming at your target, you will be aiming above and in front of them. Ray-casting from the camera hits nothing but sky, we are back where we started with no idea what the player is aiming at because we don’t know the depth of what they are aiming for.
The second option is to just fire from the third person camera position all the time and make the tracer look like it came from the gun somehow, this has the issue of players being able to shoot around walls without being seen as bullets can come from places where your player can’t be seen. Some games do a sanity check to see if the players view is blocked, if so fires from the players perspective and hit the wall.
I will be experimenting with this option for now and see if we can make it feel good, otherwise we may just leave it in the shitty state and people can go first person.
Hopefully will have a first cut of recoil by this week.