Rust - 2546\4.04.2024
HurtWorld - 1.0.0.6
THIS WEEK AND NEXT, SPENCER AND MILS ARE AWAY.
TOM
This week I’ve been helping out with itemV2, hooking up the skinned mesh baking work I’ve been doing. We’ve also been making a lot of changes to player rendering to support customization. The plan is to have players be able to pick a skin colour and a hair colour as well as hair and beard styles. We want to implement this as part of your characters default setup rather than through gear like how we currently handle it. When creating gear in the sdk you’ll add a skinned mesh attachment item component to the item which will allow you to select a mesh or group of meshes to be baked into the character model when the item is equipped. The component also allows you to mask out sections of the default player to remove them from the bake, this is handy if we want to do something like turn off the hair model when wearing a hat.
We’ve also been working on decoupling player rendering from player simulation and control and this has allowed me to write a player model viewer to help speed up our workflow. The model viewer gives an easy way to test visual item components, player default setups as well as skinned and static mesh attachments under the whole range of player animation without having to load up the entire game. This should help speed up item creation for modders as well once itemV2 makes its way into our SDK.
The motorbike is also coming along well, both Mils and Dazzler have been hard at work on content and now we have low poly models and rider animations complete. I’ve started bringing these into Unity and have split up the range of rider animations into the following blend tree.
This tree allows us to drive the animations through 5 variables:
Speed (blends between the stopped pose regular motion)
GroundedWeight (used to blend between air poses and grounded poses)
InputY (taken from up/down input, used to blend between forward and back poses in the air)
InputX (taken from left/right input, used to blend between left and right in both drifting and normal turning)
DriftWeight (represents drift amount, 0 being no drift and 1 being full drift. Used to blend between turning and drifting)
To give an idea of what the nodes represent, here’s what the ‘Air Fwd/Back’ node looks like running through its range in all its barhumping glory.
With all this in place I can start fine tuning the handling, making sure it all blends together nicely. I’ve only just started this process and need to smooth out the transitions but I think its coming together pretty well already
COW_TRIX
Hey folks! This week I’ve been planning out the new map that will be coming with ItemV2. The new map is going to be a big task. It will incorporate the amazing work that Mils has done creating an enormous library of city assets, as well as reflect some of the big gameplay and balance changes that are coming. We’ve been doing a lot of planning and talking through map ideas as abstracts, and now I’ve started actually building something to see if it works. While we loved Diemensland, we felt that it missed the mark on a couple of things. We didn’t really get a strong progression through biomes, there weren’t enough of them, and the main mechanism was temperature, which is something we want to move away from. Using temperature as the main “gating” mechanism throws in a whole lot of complications, as we also use temperature in a bunch of other stuff. It strongly limits how we are able to scale biome difficulty – for instance we can’t make a biome 100 times harder without increasing the temperature by 100, and this complicates stuff like putting in dynamic behaviors for entities at high temperatures. So, everything will just catch fire. This means we’ll probably move away from temperature as a gating mechanic for biomes.
Another change we’re entertaining is much more binary transitions between biomes, pretty much a line you step over. We think this will make balancing the biomes a bit easier, as we don’t really have to worry about the transition zones. As well as that, we felt the transition zones were generally ugly and limited how different we could make the biomes feel as we always had to consider the transition. We’ve also been thinking about player flow and forces a lot, and what we want the flow of players to be around the map. We’ve been considering a design with quite a different layout to where players begin in a middle hotspot, the city, and must get out as quickly as possible, grabbing some supplies to survive the day, and move out to one of several separate zones. These separate zones would have distinct, increasing difficulties and rewards as you progressed out, pushing players outwards. Also, as players reached the end of that progression (not necessarily establishing a base there, but having sufficient gear to travel there), they would then be able to return to the city to do high-tier farming runs. They would also be able to travel to different zones, to raid and pillage or to claim some other territory. As always, we’ll see how this layout works with a rough version first, before going forwards with a fully polished map, but it should be pretty cool and different!
GAVKU
Since last week I have mainly been working on tweaking the player character both in regards to proportion as well as making sure the in game mesh can separate in the correct way to line up with the new build system.
His mesh will now be split into : Finger Ends, Hand, Lower Arm, Upper Arm, Torso, Crotch, Upper Leg, Lower Leg, Feet, Neck, Head, Hair, Beard, and Eyes.
We noticed that the players neck appeared thin and and slightly elongated, which became more obvious when there was no beard or hair pieces loaded onto the player. Whilst fixing this I took the opportunity to fix other areas especially around the torso and pelvis. I also separated the default shorts off into their own map.
*Textures still need tweaking and proper spec maps applied.
TOM
This week I’ve been helping out with itemV2, hooking up the skinned mesh baking work I’ve been doing. We’ve also been making a lot of changes to player rendering to support customization. The plan is to have players be able to pick a skin colour and a hair colour as well as hair and beard styles. We want to implement this as part of your characters default setup rather than through gear like how we currently handle it. When creating gear in the sdk you’ll add a skinned mesh attachment item component to the item which will allow you to select a mesh or group of meshes to be baked into the character model when the item is equipped. The component also allows you to mask out sections of the default player to remove them from the bake, this is handy if we want to do something like turn off the hair model when wearing a hat.
We’ve also been working on decoupling player rendering from player simulation and control and this has allowed me to write a player model viewer to help speed up our workflow. The model viewer gives an easy way to test visual item components, player default setups as well as skinned and static mesh attachments under the whole range of player animation without having to load up the entire game. This should help speed up item creation for modders as well once itemV2 makes its way into our SDK.
The motorbike is also coming along well, both Mils and Dazzler have been hard at work on content and now we have low poly models and rider animations complete. I’ve started bringing these into Unity and have split up the range of rider animations into the following blend tree.
This tree allows us to drive the animations through 5 variables:
Speed (blends between the stopped pose regular motion)
GroundedWeight (used to blend between air poses and grounded poses)
InputY (taken from up/down input, used to blend between forward and back poses in the air)
InputX (taken from left/right input, used to blend between left and right in both drifting and normal turning)
DriftWeight (represents drift amount, 0 being no drift and 1 being full drift. Used to blend between turning and drifting)
To give an idea of what the nodes represent, here’s what the ‘Air Fwd/Back’ node looks like running through its range in all its barhumping glory.
With all this in place I can start fine tuning the handling, making sure it all blends together nicely. I’ve only just started this process and need to smooth out the transitions but I think its coming together pretty well already
COW_TRIX
Hey folks! This week I’ve been planning out the new map that will be coming with ItemV2. The new map is going to be a big task. It will incorporate the amazing work that Mils has done creating an enormous library of city assets, as well as reflect some of the big gameplay and balance changes that are coming. We’ve been doing a lot of planning and talking through map ideas as abstracts, and now I’ve started actually building something to see if it works. While we loved Diemensland, we felt that it missed the mark on a couple of things. We didn’t really get a strong progression through biomes, there weren’t enough of them, and the main mechanism was temperature, which is something we want to move away from. Using temperature as the main “gating” mechanism throws in a whole lot of complications, as we also use temperature in a bunch of other stuff. It strongly limits how we are able to scale biome difficulty – for instance we can’t make a biome 100 times harder without increasing the temperature by 100, and this complicates stuff like putting in dynamic behaviors for entities at high temperatures. So, everything will just catch fire. This means we’ll probably move away from temperature as a gating mechanic for biomes.
Another change we’re entertaining is much more binary transitions between biomes, pretty much a line you step over. We think this will make balancing the biomes a bit easier, as we don’t really have to worry about the transition zones. As well as that, we felt the transition zones were generally ugly and limited how different we could make the biomes feel as we always had to consider the transition. We’ve also been thinking about player flow and forces a lot, and what we want the flow of players to be around the map. We’ve been considering a design with quite a different layout to where players begin in a middle hotspot, the city, and must get out as quickly as possible, grabbing some supplies to survive the day, and move out to one of several separate zones. These separate zones would have distinct, increasing difficulties and rewards as you progressed out, pushing players outwards. Also, as players reached the end of that progression (not necessarily establishing a base there, but having sufficient gear to travel there), they would then be able to return to the city to do high-tier farming runs. They would also be able to travel to different zones, to raid and pillage or to claim some other territory. As always, we’ll see how this layout works with a rough version first, before going forwards with a fully polished map, but it should be pretty cool and different!
GAVKU
Since last week I have mainly been working on tweaking the player character both in regards to proportion as well as making sure the in game mesh can separate in the correct way to line up with the new build system.
His mesh will now be split into : Finger Ends, Hand, Lower Arm, Upper Arm, Torso, Crotch, Upper Leg, Lower Leg, Feet, Neck, Head, Hair, Beard, and Eyes.
We noticed that the players neck appeared thin and and slightly elongated, which became more obvious when there was no beard or hair pieces loaded onto the player. Whilst fixing this I took the opportunity to fix other areas especially around the torso and pelvis. I also separated the default shorts off into their own map.
*Textures still need tweaking and proper spec maps applied.