Rust - 2546\4.04.2024
HurtWorld - 1.0.0.6
MILS
The dirt bike is coming along nicely. The low poly for the 3 wheel designs and one of the body kits are done. I decided to model all the wheels and the body kits at the same time to make sure I don’t go over our poly limit. One of the wheel sets (the one on the right) that most resembles a standard dirt bike tyre, stretched our poly budget a bit more than previously thought. I had to use mesh to get that nobbled tread silhouette which increases the poly’s significantly for that design. Once the 2 other low poly body kits are done I can check the combined polycounts of that tyre set with the other body kits to make sure we aren’t blowing out our poly budget.
I also made some updates to the raid drill which you have now probably been playing with. We split the machine into 3 parts to make it’s creation and use more interesting. I had to update some of the mesh, textures and icons for it.
COW_TRIX
I spent this week getting the Raid Drill out and fixing a few bugs that came up from that patch. That was a mostly smooth process, and now we’ll be looking at the feedback from you folks and metrics on the drill’s usage and uptake.
It’s always a balancing act when releasing a new gameplay mechanism, and it’s almost a statistical impossibility we’ll get it exactly right first time. The question then becomes – do you balance a new mechanism erring on the side of caution and maybe buff it later, or do you release a possibly overpowered mechanism and maybe nerf it later? Both tactics have advantages and disadvantages. If you err on the side of caution, and release a mechanism that may be under-powered or not viable, then you have less uptake on the mechanism and some players might be disappointed. If you go the other way, you will get good uptake as the mechanism dominates the meta, but it will be frustrating to be on the receiving end of it and a nerf will have to be quick, as damage is being done. Personally I prefer to err on the side of caution, simply because in the time it may take to re-balance and buff, generally, damage isn’t being done. You have the frustration of this new thing is useless!, but not this new thing is destroying the game!
My new main task, and what you’re going to be hearing about for the next few weeks, is making a new map to go hand-in-hand with the ItemV2 update. This map will integrate a lot of new assets, including the cities that Mils has been working on, as well as experimenting with some different layouts and structures. While Diemensland has been a great map that we’re proud of, Diemensland is just an aspect of Hurtworld. Part of this, which is what I’m doing right now, is looking at Diemensland and trying to learn some lessons from it. I’ve been pulling apart savegames and analysing them, seeing where people play, build their bases, hide their loot, and more. There haven’t been too many surprises, and we were glad to see that a lot of the design decisions we had made had had their intended effects on player behavior. You can see some of the aggregated maps below, showing where on the map certain objects are. So, the most populated part of the map is the transition between the Forest and the Starting Beach, which makes sense. You’ve got the Dome, Valley, and Fortress all in a small area, it’s resource rich, survivable and accessible. There are way too many workbenches.
Workbenches
Vehicles
Structures
Storage Chests/Lockers
Ownership Stakes
Shacks
Owrongs
It’s some interesting data that has given us a lot to think about when planning this next map. I’ve also been looking at the community maps that people have been playing and liking, to see what they’ve done with layout and flow.
GAVKU
Nothing overly exciting from me this week, just more clothes in the form of jeans and tshirt, trying to round out all the standard/base clothing items. Once all these standard issue type gear is done, I will jump onto things like jackets, footwear, and gear more in line with some of the concepts I had posted previously.
Next week I will post up a fully kitted out new character next to the current one to give everyone an idea of how different they look.
TOM
This week I’ve been refactoring the core of the vehicle system. I’ve been trying to simplify the code base making it easier for both ourselves and modders to work with. I’ve removed serialization from variables that were being overridden by equipment and environmental factors (eg. Throttle torques, traction modifiers, fuel efficiency etc.). Each component is smaller now and the separation of responsibilities is clearer which makes it easier to work on and maintain as well as making it easier to setup new vehicles.
For example here’s how the vehicle motor and controller classes look in the sdk when comparing versions.
I’ve also been able to squash some bugs and move some edge case handling back into the main general simulation. This will lead to more consistent handling with less seemingly random spinning out and flipping over.
I also found several cases where the forces we applied weren’t being affected by the vehicle’s weight, I’ve been rebalancing these so in the average case the handling should be roughly as before but with a particularly light or heavy vehicle (depending on equipment and passenger numbers) you should notice more nimble/sluggish handling respectively.
With these changes in place, this coming week I’m going to do some experiments with client side prediction to try and remove the input delay vehicles currently suffer from. No promises as it’s a tricky problem and for a persistent world style of game where death is potentially costly we think it’s a better experience to have a bit of input delay rather than have players rubber banding and teleporting all around the place.
I also spent a bit of time this week poking around our AI system and doing some research as that’s my next area of focus after vehicles. I’ve been looking into using the state machine / behaviour tree system Spencer has been using for item v2 which should mean it’ll be faster for us to create new content and also open up NPC modding.
SPENCER
Didn’t get as far as I wanted to with recoil this week, as the more I dug into the requirements for the recoil system it became clear that the entire camera system needed a rewrite. The reason for this was that the server had no knowledge of the clients camera positioning, and our camera logic was wildly inconsistent and spread all over the project.
As the rabbit hole deepens, like all other systems being touched on this journey, I decided to rebuild it with all the missing features we want to have soon:
Ability to look over your shoulder aka headlook
Just like the Arma engine, this feature is useful when sprinting and you want to look left and right without having to change direction. To do this I needed to introduce the concept of more than just an aim angle. I also needed to add the ability to restrict the camera movement rotation left and right depending on situation, which needs to be fed back into the input controls (mouse angle) on the client, but also enforced on the server
Look restrictions in first person in a vehicle
When in first person in a car, you shouldn’t be able to spin 360 degrees. We wan’t your facing direction to be properly animated soon, and if you have look freedom we can’t really come up with a decent pose in a lot of situations without looking like the exorcist. This meant using the view rotation restrictions mentioned above, but extending it to be able to be restricted dependent on parent rotation (the vehicle). There are also different situations for vehicle seats, like the tray seat on the Roach could have full rotational freedom (including legs), the passenger seats should be able to change aim direction while their legs are locked forward in the seat, and the driver should only be able to change his headlook direction while his aim is fixed forward. This made things pretty complicated, but I’m sure now we can handle just about any camera / look scenario including…..
Shooting from Vehicles
Probably the most requested feature we’ve had, something I’ve wanted to add forever also. There were a LOT of issues we needed to iron out to make this possible, but with the camera restriction, and concept of facing direction, aim direction and look direction cleanly separated I decided to have a crack at solving the other issues.
The biggest of which is the paradox of your own player on your screen being ahead of server time, shooting from inside a vehicle on your screen that is behind server time (as the server owns it), and reconciling the hit registration. Normally we only have to apply antilag on the object being hit by a gunshot (rewind your target on the server to the point they were at when you shot them, to determine if you actually hit them). But in this case, the server has no idea where you actually were when you fired the bullet, as by the time the server simulates the gunshot happening, you may be 20m further down the road.
To solve this I created a concept called parent simulate time, which when in a vehicle, your client sends to the server each tick some data indicating what time its parent was at when your machine simulated the tick. I then had to add a history buffer of vehicle positions on the server, so when simulating a player inside a vehicle firing a bullet, the server can rewind the vehicle position to where the client thought it was when it fired, and simulate the bullet from the exact same trajectory (before moving the vehicle back to where it was).
Parent simulate time also paves the way for awesome stuff like being able to walk around in the local space of a parent object! (Think moving platforms / standing on moving vehicles)
As I still have the equipment / camera system in pieces on the floor, shooting from vehicles isn’t up and running yet. However, all the roadblocks stopping us delivering it should now be removed. Fingers crossed it will make it for itemV2!
No Touch On Server
This is one of the most annoying bugs we have currently, is caused by our server side authentication system for interacting with objects like chests / machines. The server has a concept of touch, in that if you look at an object on the server and nothing is blocking your line of sight, you are added to a “touching list” that allows you to interact with the object. Without this, players could send packets saying they are interacting with your chests and remove items from them. Distance checks aren’t enough as they may be just over the other side of a wall.
This fails when the server doesn’t agree with what you are currently seeing, which happens a lot inside 1 level buildings in third person, as the server has no idea what you are actually looking at because it doesn’t run the full camera logic. Now it does, so the servers view of what you can touch should be 100% accurate. There was also a bug where the clients interaction view would be offset by the clientside interpolation smoothing which is purely for rending and shouldn’t affect simulation logic. This made a few scenarios where the server and client would disagree on what you touched, or even what you hit with a pick. This will also be fixed in ItemV2.
The dirt bike is coming along nicely. The low poly for the 3 wheel designs and one of the body kits are done. I decided to model all the wheels and the body kits at the same time to make sure I don’t go over our poly limit. One of the wheel sets (the one on the right) that most resembles a standard dirt bike tyre, stretched our poly budget a bit more than previously thought. I had to use mesh to get that nobbled tread silhouette which increases the poly’s significantly for that design. Once the 2 other low poly body kits are done I can check the combined polycounts of that tyre set with the other body kits to make sure we aren’t blowing out our poly budget.
I also made some updates to the raid drill which you have now probably been playing with. We split the machine into 3 parts to make it’s creation and use more interesting. I had to update some of the mesh, textures and icons for it.
COW_TRIX
I spent this week getting the Raid Drill out and fixing a few bugs that came up from that patch. That was a mostly smooth process, and now we’ll be looking at the feedback from you folks and metrics on the drill’s usage and uptake.
It’s always a balancing act when releasing a new gameplay mechanism, and it’s almost a statistical impossibility we’ll get it exactly right first time. The question then becomes – do you balance a new mechanism erring on the side of caution and maybe buff it later, or do you release a possibly overpowered mechanism and maybe nerf it later? Both tactics have advantages and disadvantages. If you err on the side of caution, and release a mechanism that may be under-powered or not viable, then you have less uptake on the mechanism and some players might be disappointed. If you go the other way, you will get good uptake as the mechanism dominates the meta, but it will be frustrating to be on the receiving end of it and a nerf will have to be quick, as damage is being done. Personally I prefer to err on the side of caution, simply because in the time it may take to re-balance and buff, generally, damage isn’t being done. You have the frustration of this new thing is useless!, but not this new thing is destroying the game!
My new main task, and what you’re going to be hearing about for the next few weeks, is making a new map to go hand-in-hand with the ItemV2 update. This map will integrate a lot of new assets, including the cities that Mils has been working on, as well as experimenting with some different layouts and structures. While Diemensland has been a great map that we’re proud of, Diemensland is just an aspect of Hurtworld. Part of this, which is what I’m doing right now, is looking at Diemensland and trying to learn some lessons from it. I’ve been pulling apart savegames and analysing them, seeing where people play, build their bases, hide their loot, and more. There haven’t been too many surprises, and we were glad to see that a lot of the design decisions we had made had had their intended effects on player behavior. You can see some of the aggregated maps below, showing where on the map certain objects are. So, the most populated part of the map is the transition between the Forest and the Starting Beach, which makes sense. You’ve got the Dome, Valley, and Fortress all in a small area, it’s resource rich, survivable and accessible. There are way too many workbenches.
Workbenches
Vehicles
Structures
Storage Chests/Lockers
Ownership Stakes
Shacks
Owrongs
It’s some interesting data that has given us a lot to think about when planning this next map. I’ve also been looking at the community maps that people have been playing and liking, to see what they’ve done with layout and flow.
GAVKU
Nothing overly exciting from me this week, just more clothes in the form of jeans and tshirt, trying to round out all the standard/base clothing items. Once all these standard issue type gear is done, I will jump onto things like jackets, footwear, and gear more in line with some of the concepts I had posted previously.
Next week I will post up a fully kitted out new character next to the current one to give everyone an idea of how different they look.
TOM
This week I’ve been refactoring the core of the vehicle system. I’ve been trying to simplify the code base making it easier for both ourselves and modders to work with. I’ve removed serialization from variables that were being overridden by equipment and environmental factors (eg. Throttle torques, traction modifiers, fuel efficiency etc.). Each component is smaller now and the separation of responsibilities is clearer which makes it easier to work on and maintain as well as making it easier to setup new vehicles.
For example here’s how the vehicle motor and controller classes look in the sdk when comparing versions.
I’ve also been able to squash some bugs and move some edge case handling back into the main general simulation. This will lead to more consistent handling with less seemingly random spinning out and flipping over.
I also found several cases where the forces we applied weren’t being affected by the vehicle’s weight, I’ve been rebalancing these so in the average case the handling should be roughly as before but with a particularly light or heavy vehicle (depending on equipment and passenger numbers) you should notice more nimble/sluggish handling respectively.
With these changes in place, this coming week I’m going to do some experiments with client side prediction to try and remove the input delay vehicles currently suffer from. No promises as it’s a tricky problem and for a persistent world style of game where death is potentially costly we think it’s a better experience to have a bit of input delay rather than have players rubber banding and teleporting all around the place.
I also spent a bit of time this week poking around our AI system and doing some research as that’s my next area of focus after vehicles. I’ve been looking into using the state machine / behaviour tree system Spencer has been using for item v2 which should mean it’ll be faster for us to create new content and also open up NPC modding.
SPENCER
Didn’t get as far as I wanted to with recoil this week, as the more I dug into the requirements for the recoil system it became clear that the entire camera system needed a rewrite. The reason for this was that the server had no knowledge of the clients camera positioning, and our camera logic was wildly inconsistent and spread all over the project.
As the rabbit hole deepens, like all other systems being touched on this journey, I decided to rebuild it with all the missing features we want to have soon:
Ability to look over your shoulder aka headlook
Just like the Arma engine, this feature is useful when sprinting and you want to look left and right without having to change direction. To do this I needed to introduce the concept of more than just an aim angle. I also needed to add the ability to restrict the camera movement rotation left and right depending on situation, which needs to be fed back into the input controls (mouse angle) on the client, but also enforced on the server
Look restrictions in first person in a vehicle
When in first person in a car, you shouldn’t be able to spin 360 degrees. We wan’t your facing direction to be properly animated soon, and if you have look freedom we can’t really come up with a decent pose in a lot of situations without looking like the exorcist. This meant using the view rotation restrictions mentioned above, but extending it to be able to be restricted dependent on parent rotation (the vehicle). There are also different situations for vehicle seats, like the tray seat on the Roach could have full rotational freedom (including legs), the passenger seats should be able to change aim direction while their legs are locked forward in the seat, and the driver should only be able to change his headlook direction while his aim is fixed forward. This made things pretty complicated, but I’m sure now we can handle just about any camera / look scenario including…..
Shooting from Vehicles
Probably the most requested feature we’ve had, something I’ve wanted to add forever also. There were a LOT of issues we needed to iron out to make this possible, but with the camera restriction, and concept of facing direction, aim direction and look direction cleanly separated I decided to have a crack at solving the other issues.
The biggest of which is the paradox of your own player on your screen being ahead of server time, shooting from inside a vehicle on your screen that is behind server time (as the server owns it), and reconciling the hit registration. Normally we only have to apply antilag on the object being hit by a gunshot (rewind your target on the server to the point they were at when you shot them, to determine if you actually hit them). But in this case, the server has no idea where you actually were when you fired the bullet, as by the time the server simulates the gunshot happening, you may be 20m further down the road.
To solve this I created a concept called parent simulate time, which when in a vehicle, your client sends to the server each tick some data indicating what time its parent was at when your machine simulated the tick. I then had to add a history buffer of vehicle positions on the server, so when simulating a player inside a vehicle firing a bullet, the server can rewind the vehicle position to where the client thought it was when it fired, and simulate the bullet from the exact same trajectory (before moving the vehicle back to where it was).
Parent simulate time also paves the way for awesome stuff like being able to walk around in the local space of a parent object! (Think moving platforms / standing on moving vehicles)
As I still have the equipment / camera system in pieces on the floor, shooting from vehicles isn’t up and running yet. However, all the roadblocks stopping us delivering it should now be removed. Fingers crossed it will make it for itemV2!
No Touch On Server
This is one of the most annoying bugs we have currently, is caused by our server side authentication system for interacting with objects like chests / machines. The server has a concept of touch, in that if you look at an object on the server and nothing is blocking your line of sight, you are added to a “touching list” that allows you to interact with the object. Without this, players could send packets saying they are interacting with your chests and remove items from them. Distance checks aren’t enough as they may be just over the other side of a wall.
This fails when the server doesn’t agree with what you are currently seeing, which happens a lot inside 1 level buildings in third person, as the server has no idea what you are actually looking at because it doesn’t run the full camera logic. Now it does, so the servers view of what you can touch should be 100% accurate. There was also a bug where the clients interaction view would be offset by the clientside interpolation smoothing which is purely for rending and shouldn’t affect simulation logic. This made a few scenarios where the server and client would disagree on what you touched, or even what you hit with a pick. This will also be fixed in ItemV2.