Rust - 2546\4.04.2024
HurtWorld - 1.0.0.6
GAVKU
So the basic pants have been finalized and skinned to a presentable level. Next up is an all purpose jacket which will round out the majority of the basic player gear set.
Also the player FPS arms have been finished, bringing them into line with the look of the 3rd person model.
MILS
I’ve almost finished the sculpts for the Kanga, the chassis and body kits are done, just gotta add wear and tear to the wheel sets now. I’m trying a new baking tool which I’ll use to create the normal maps. The new tool is called Handplane Baker, a great new tool with a lot of modern features, and it bakes quicker than good old XNormal. Not sure how Handplane will work out, so if need be I will use XNormal, but my hope is that it will produce maps faster and with less micro seams where the UV islands join up. This will give a cleaner normal map. Gavku uses handplane for his bakes, and I originally wanted to as well but I got inferior results because of some difference between Handplane and Maya vs Handplane and 3DMax. I’ll try simply sending my meshes to max and re-exporting them from there, and I may be able to get the same results as Gavku.
COW_TRIX
This week I’ve been putting natural landmarks, structures and simple roads into the map structure, as well as further expanding the MapMagic tool.
One of the big problems in Diemensland was that the formula we arrived at for the general map creation led to maps that were quite difficult to find your way around. In many parts of Diemensland, every direction looks much like the other and there are few landmarks. Even after hours and hours of play, I still find myself very easily lost. For this reason I want to make the new map be much richer in natural landmarks, to allow people to find their way much more easily. You can see some of the natural formations I’ve created to be scattered around the map below.
Something I think was really missing from Diemensland was movement. I really like how the waterfalls create some movement on the screen, it makes the world feel a million times more alive. That’s something that I’m going to try to get a lot more of in this map.
I’ve also been making some man-made structures, like this small outpost. You can try climbing to the top, where some rare ores will spawn, but it is a risky endeavour!
Getting roads in this system has been a challenge, and I thought it would be one area where we’d have to break out of the MapMagic tool and use some other tool such as EasyRoads. However, I had a go implementing a basic road with MM and it turned out pretty good! While it is slightly more constricted in what we can do in terms of aesthetics, as we’re dealing with a splat and not a mesh, the advantages of having it all tied together may outweigh the cons of it perhaps looking slightly less realistic.
TOM
The work on the Kanga continues! This week I merged the Kanga branch with the current live version, incorporating the raid drill and a host of other bugfixes and backend changes.
We’ve also been making some changes to how the rider animations are being driven, while we are keeping the same blend tree from blog #42 we are driving these blends from a derived client side state instead of directly from input. To set the turn speed we now compare the direction of velocity to the direction the bike is facing, the back/forward air blend is now driven by the pitch of the bike in the air rather than the throttle.
After last week we got the bike to a pretty good, controllable baseline so this week we wanted to add back in a bit of nuance and skill-based play that could allow players to differentiate themselves. To this end we’ve added in a wheelie control.
Holding down the wheelie button generates a torque lifting the front wheel into the air but only when you are accelerating at the same time. You have to be careful you don’t overcook it and flip over backwards and this requires feathering either the wheelie button and/or the throttle.
Whilst the wheelie doesn’t directly do anything new it comes in handy in a few ways. Because we dampen any twisting motion when only one wheel is grounded a little power wheelie out of a drift is a good way to quickly straighten up. As well as this you can use it to get your front wheel up and over various obstacles.
We’ve also toned down the air stabilization to a large degree, adding a cap on the maximum force it can apply, highly increasing its damping and also turning off stabilization all together if you get yourself into an extreme pitch in either direction. This last change combined with the wheelie button allows you to generate enough momentum to overpower the stabilizer and get yourself upside down so you can flip.
I’ve also been doing polish that doesn’t make good gifs, things like creating an accurate collider set for the kanga from the low poly, creating a way to mark colliders as ‘bottom out colliders’ that act as the bottomed out wheel, don’t apply damage or play effects when in a collision and have a special frictionless material. For the roach and goat we can use the vehicle chassis as the bottom out bumper but the shape of a bike requires a hard collision response long before the frame touches anything. I’ve also made optimisations to the crash components so they only watch for crashes whilst the vehicle is occupied.
The bike is getting pretty close to functionally complete now but there are still a few steps to go before it will truly be ready:
Good progress on ItemV2 this week. While working on recoil, I came across some issues around serialization of ammo counts and other dynamic pieces of state to do with items, which turned into a decent refactor on how and when we tell players about items. Previously clients would only know icon information about items until they either equipped them, or looked at their tooltip as the structure of the items was too complex to serialize on every update like we do currently.
However while thinking about what creates the state of items, I realized by only sharing the data needed to generate the Item, we would only need to send a generator id (the asset in charge of procedurally generating the item) and the configuration block (which in most cases is just a random seed).
Then if things like attachments are added, we simply send the id of the item modifier with its configuration block.
This makes the amount of data required to serialize an item almost negligible regardless of how complex the state is, allowing us to always send everything about an item (except some special cases like transition times) exactly the same way was we were in the current live version of the game. Eliminating a heap of complexity, ram that would need to be stored, and bloat in the save games.
The second benefit to this is that since the full item definition is on the client, we don’t need to build an entirely new tooltip engine as mentioned in the last devblog. We can just use our current system with some small enhancements. This should save us a couple of weeks work.
The second big change this week was removing a large layer of indirection between inventory and items. The actual instances of items were transient, and would be constantly re-allocated / destroyed with no sense of uniqueness to each instance. Now our GlobalItemManager will keep an inventory of all known items which match up to an identifier. This greatly simplifies code related to item management and enables the serialization described above.
So the basic pants have been finalized and skinned to a presentable level. Next up is an all purpose jacket which will round out the majority of the basic player gear set.
Also the player FPS arms have been finished, bringing them into line with the look of the 3rd person model.
MILS
I’ve almost finished the sculpts for the Kanga, the chassis and body kits are done, just gotta add wear and tear to the wheel sets now. I’m trying a new baking tool which I’ll use to create the normal maps. The new tool is called Handplane Baker, a great new tool with a lot of modern features, and it bakes quicker than good old XNormal. Not sure how Handplane will work out, so if need be I will use XNormal, but my hope is that it will produce maps faster and with less micro seams where the UV islands join up. This will give a cleaner normal map. Gavku uses handplane for his bakes, and I originally wanted to as well but I got inferior results because of some difference between Handplane and Maya vs Handplane and 3DMax. I’ll try simply sending my meshes to max and re-exporting them from there, and I may be able to get the same results as Gavku.
COW_TRIX
This week I’ve been putting natural landmarks, structures and simple roads into the map structure, as well as further expanding the MapMagic tool.
One of the big problems in Diemensland was that the formula we arrived at for the general map creation led to maps that were quite difficult to find your way around. In many parts of Diemensland, every direction looks much like the other and there are few landmarks. Even after hours and hours of play, I still find myself very easily lost. For this reason I want to make the new map be much richer in natural landmarks, to allow people to find their way much more easily. You can see some of the natural formations I’ve created to be scattered around the map below.
Something I think was really missing from Diemensland was movement. I really like how the waterfalls create some movement on the screen, it makes the world feel a million times more alive. That’s something that I’m going to try to get a lot more of in this map.
I’ve also been making some man-made structures, like this small outpost. You can try climbing to the top, where some rare ores will spawn, but it is a risky endeavour!
Getting roads in this system has been a challenge, and I thought it would be one area where we’d have to break out of the MapMagic tool and use some other tool such as EasyRoads. However, I had a go implementing a basic road with MM and it turned out pretty good! While it is slightly more constricted in what we can do in terms of aesthetics, as we’re dealing with a splat and not a mesh, the advantages of having it all tied together may outweigh the cons of it perhaps looking slightly less realistic.
TOM
The work on the Kanga continues! This week I merged the Kanga branch with the current live version, incorporating the raid drill and a host of other bugfixes and backend changes.
We’ve also been making some changes to how the rider animations are being driven, while we are keeping the same blend tree from blog #42 we are driving these blends from a derived client side state instead of directly from input. To set the turn speed we now compare the direction of velocity to the direction the bike is facing, the back/forward air blend is now driven by the pitch of the bike in the air rather than the throttle.
After last week we got the bike to a pretty good, controllable baseline so this week we wanted to add back in a bit of nuance and skill-based play that could allow players to differentiate themselves. To this end we’ve added in a wheelie control.
Holding down the wheelie button generates a torque lifting the front wheel into the air but only when you are accelerating at the same time. You have to be careful you don’t overcook it and flip over backwards and this requires feathering either the wheelie button and/or the throttle.
Whilst the wheelie doesn’t directly do anything new it comes in handy in a few ways. Because we dampen any twisting motion when only one wheel is grounded a little power wheelie out of a drift is a good way to quickly straighten up. As well as this you can use it to get your front wheel up and over various obstacles.
We’ve also toned down the air stabilization to a large degree, adding a cap on the maximum force it can apply, highly increasing its damping and also turning off stabilization all together if you get yourself into an extreme pitch in either direction. This last change combined with the wheelie button allows you to generate enough momentum to overpower the stabilizer and get yourself upside down so you can flip.
I’ve also been doing polish that doesn’t make good gifs, things like creating an accurate collider set for the kanga from the low poly, creating a way to mark colliders as ‘bottom out colliders’ that act as the bottomed out wheel, don’t apply damage or play effects when in a collision and have a special frictionless material. For the roach and goat we can use the vehicle chassis as the bottom out bumper but the shape of a bike requires a hard collision response long before the frame touches anything. I’ve also made optimisations to the crash components so they only watch for crashes whilst the vehicle is occupied.
The bike is getting pretty close to functionally complete now but there are still a few steps to go before it will truly be ready:
- Final bike art for all variants complete
- New crash and get up animations to replace placeholders
- Create items for the bike variants (currently just working from 1 baseline itemset)
- Validate crash spawns so players cannot use crashing to glitch through walls and into rocks
- Balance pass on vehicle health and damage
- Balance pass on vehicle spawns and loot, taking into account less vehicle permanence through destruction and a slightly diluted vehicle loot table (eg. It will be harder to collect a full setup for your target vehicle as 3 types can drop instead of 2).
Good progress on ItemV2 this week. While working on recoil, I came across some issues around serialization of ammo counts and other dynamic pieces of state to do with items, which turned into a decent refactor on how and when we tell players about items. Previously clients would only know icon information about items until they either equipped them, or looked at their tooltip as the structure of the items was too complex to serialize on every update like we do currently.
However while thinking about what creates the state of items, I realized by only sharing the data needed to generate the Item, we would only need to send a generator id (the asset in charge of procedurally generating the item) and the configuration block (which in most cases is just a random seed).
Then if things like attachments are added, we simply send the id of the item modifier with its configuration block.
This makes the amount of data required to serialize an item almost negligible regardless of how complex the state is, allowing us to always send everything about an item (except some special cases like transition times) exactly the same way was we were in the current live version of the game. Eliminating a heap of complexity, ram that would need to be stored, and bloat in the save games.
The second benefit to this is that since the full item definition is on the client, we don’t need to build an entirely new tooltip engine as mentioned in the last devblog. We can just use our current system with some small enhancements. This should save us a couple of weeks work.
The second big change this week was removing a large layer of indirection between inventory and items. The actual instances of items were transient, and would be constantly re-allocated / destroyed with no sense of uniqueness to each instance. Now our GlobalItemManager will keep an inventory of all known items which match up to an identifier. This greatly simplifies code related to item management and enables the serialization described above.