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!
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.
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
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.
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.
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.