Rust - 2546\4.04.2024
HurtWorld - 1.0.0.6
COW_TRIX
So a lot of progress with the map and the tools we’re using to make this map awesome this week. The biggest blocker right now is waiting for some new features, such as biomes, to come out in MapMagic. Biomes in this context means being able to blend between completely different generation rules between areas, that should allow us to really start creating the macro of the map, so I’ve been playing around with some of the other existing assets and making some other biomes. I also completed working entity spawns into the MapMagic system, so now we can procedurally place spawns based on some basic rules. This should hopefully speed up that element of map creation.
Another big thing has been roads. Previously we used a 3rd party plugin called EasyRoads. The roads in Diemensland were made with this plugin, and it was ok, but has some significant issues and is definitely a work-in-progress. As well as struggling with some tasks, it’s also obfuscated and compiled into a DLL, making it impractical to fix up and extend. So, I recently started making our own road tool, which is going to be awesome! It’s a project I’ve wanted to tackle for a while now, ever since hitting the shortcomings of the available tools. We may do this for other systems that are currently mostly 3rd party, in future, such as navmesh generation and pathfinding which are currently a frankensteinian blend of custom code and 3rd party tools.
So, I’ve started to write my own little road tool which has been a fun little trek into spline-maths, something I haven’t used since university days. But very interesting problems! I’ve got a mesh to deform to a spline, which is the main challenge. There are still a few bugs with interpolation to iron out, but it’s been surprisingly easy. Hopefully some cool new road screenshots for you all next week!
SPENCER
This week I’ve re-implemented the assault rifle in the new item system, giving the new ammo architecture a bashing and started testing recoil. In the process, finding and squashing heaps of bugs in the new item serialization.
As I had hoped, we now have full client side predicted equipment simulation and switching regardless of latency to server! This means at 200 ping, you can switch weapons and fire without that sluggish delay that exists currently, what you see other players doing on your screen will always match their screen, and that awkward jam where your gun won’t shoot will never happen again
This might not seem like a big deal, but this is a big step in raising the bar in survival game gunplay. Our architecture is close to on par with CS:GO, combined with some big performance gains we are working on, we should be able to deliver that top tier FPS gunplay we have always been aiming for.
ARBITRARY STATE ON ITEMS – REMOVING INFAMY
Something I’ve touched on before briefly, but not for a while, is the goals behind ItemV2. First and foremost, we want to get rid of infamy. Infamy was an experiment that for us patched up a simple issue: The more time you invest in your gear, the more you have to lose if you die. Full loot with extremely valuable gear doesn’t work as you get set back to square one if you die. Infamy gave people a choice, to not risk their gear unless absolutely necessary. Protecting noobs from griefing was an added bonus to the system, not the primary reason.
I wrote a large blog post on the ins and outs of the topic here: Infamy – State Of the Union
While I could have patched in some bandaid features that would have lessened the issue, I believe it would have put us at the end of our lifecycle in development. When building anything, you can only overextend yourself so far before you either need to improve the foundations or leave it as is. This is what I see in a lot of early access games, where the dodgy hacks thrown in to get something out the door make the workload for adding new features so large most just call it quits.
What we ended up doing instead over the last 6 months was some what of a “Reboot” to some large parts of our systems. Being a absolutely crucial part of our game, items are how we create value, simulate equipment, drive the economy and balance almost everything in game.
Our original system was based on items defined ahead of time that dont change at all. Eg red pickaxes were equal and we had no way of storing information against unique instances of items besides a hacky implementation of item transitions and ammo storage. Adding something like durability to an item, would require another hacky patch that all future items would need to work around. Considering we are working towards completely procedural constructed items where each instance in unique (think Borderlands) this was an impossible task. On top of this, the actual simulation of items you have equipped was a mess. While each persons client machine “predicted” the state its equipment was in, we had no way of determining if the prediction was done correctly. Resulting in the server and every other player having a different picture of what was going on than you did.
Solving the above problems were by far the most difficult engineering problems I’ve faced to date. Mostly because there is no right answer, and there isn’t really common industry knowledge of how to client side predicted high frequency simulation of complex moddable items in the scale of a persistent survival game. Nobody is doing it.
The good news is everything above is now solved in a robust architecture that also allows modders to create their own client side predicted equipment content and procedural item generators, all from the safety of our unity editor SDK. I know I have spoken about this before, but now we are reaching the point where we can start filling it with content.
REWRITING THE ITEM PROGRESSION
Back to the task at hand… to remove infamy means we need to completely rethink how we store value that a player has accumulated. If we go full loot, we need a way to ensure that being killed doesn’t set you back to square one. To do this we are completely re-writing the item progression from the ground up.
Now that we have an architecture that allows us to do infinitely more with items we are really going to shake things up. More on this in the coming weeks!
MILS
I had great success with the new baking software that I mentioned last week. Handplane baked out the normals quicker, with less work and better results than the previous software I was using. It’s a great step forward for this kind of work. So the Kanga chassis normal maps are complete and I also got through all the unwrapping on the uv maps for the rest of the body kits. Now I just have to lay out the UV’s scale them to the right sizes and I can bake them out as well.
I plan to be into texturing by the end of the week, and after the base texture is done I will need to design the skins that will decorate the Kanga so you can all customise colours and patterns and make the Kanga your own.
GAVKU
So this week I have been working on a player jacket. It involved a bunch of noodling around in Marvelous Designer especially when I was getting closer to something I liked, as it can be pretty easy to tie yourself in knots, or get in to a loop of continually pushing and pulling segments trying to get something that would sim correctly.
I placed the player tshirt underneath the garment to help give it some bulk as well as layer cloning the pattern when I was happy with it to beef it up a little.
This is an image of the pattern, and undershirt.
Marvelous Designer 3d screengrab
This mesh needed a bit of cleaning up in zbrush and max, mainly due to birdsnesting of verts ( a whole bunch of messy verts in one location ), as well as having to flip normals on certain segments.
I then took it in to mudbox to clean up some lines.
I have built and unwrapped the low, and am in the process of baking and texturing. I’ll then be test skinning it, and seeing how well it interacts with gear lying underneath ie: tshirts, vest etc.
TOM
The Kanga draws closer! This week I’ve been working on integrating the Kanga properly into the game, creating the equippable items and ui window and setting up the paint and masking system.
The gearboxes and engines come in the same variations as seen on the Roach and Goat at the moment (offroad/on road and damaged/weak/standard/powerful respectively). There are 3 wheel types to match the 3 panel attachment types that affect traction, weight, turn speed and fuel consumption.
The panel attachments will be split into front and back panels the same as the Goat, I’ve created some placeholder panels to add storage with the rear containers and am experimenting with adding vehicle armor through attachments.
I’ve also changed our explosion effect so it scales with explosion size. Below you can see the difference between a vehicle with no fuel and a vehicle with max fuel. The max fuel one is a bit overkill at the moment and will likely be scaled back once I dive into balancing this week.
Something we want to achieve with the vehicle changes is being able to remove the claim system, vehicle auto despawns and vehicle spawn limits. The real blocker for us to achieve this at the moment is the rendering overhead, especially when you have heaps of vehicles in the same location like when you drive by the garage of that player who has been hoarding vehicles and it loads them all. To deal with this I’ve been working on a dynamic level of detail system that sorts objects by their priority and uses this sorted list to decide the level of detail the object needs to be displayed at. The system has a player chosen budget so users can make their own compromise between level of detail and performance depending on their hardware.
At the moment it’s just running on vehicles with priority based on distance and whether the vehicle is occupied (so vehicles with players in them always have a higher priority) but if it works well there we can extend it into players, constructions and other dynamic objects.
Here’s a visualization of the system working on a pile of Goats
So a lot of progress with the map and the tools we’re using to make this map awesome this week. The biggest blocker right now is waiting for some new features, such as biomes, to come out in MapMagic. Biomes in this context means being able to blend between completely different generation rules between areas, that should allow us to really start creating the macro of the map, so I’ve been playing around with some of the other existing assets and making some other biomes. I also completed working entity spawns into the MapMagic system, so now we can procedurally place spawns based on some basic rules. This should hopefully speed up that element of map creation.
Another big thing has been roads. Previously we used a 3rd party plugin called EasyRoads. The roads in Diemensland were made with this plugin, and it was ok, but has some significant issues and is definitely a work-in-progress. As well as struggling with some tasks, it’s also obfuscated and compiled into a DLL, making it impractical to fix up and extend. So, I recently started making our own road tool, which is going to be awesome! It’s a project I’ve wanted to tackle for a while now, ever since hitting the shortcomings of the available tools. We may do this for other systems that are currently mostly 3rd party, in future, such as navmesh generation and pathfinding which are currently a frankensteinian blend of custom code and 3rd party tools.
So, I’ve started to write my own little road tool which has been a fun little trek into spline-maths, something I haven’t used since university days. But very interesting problems! I’ve got a mesh to deform to a spline, which is the main challenge. There are still a few bugs with interpolation to iron out, but it’s been surprisingly easy. Hopefully some cool new road screenshots for you all next week!
SPENCER
This week I’ve re-implemented the assault rifle in the new item system, giving the new ammo architecture a bashing and started testing recoil. In the process, finding and squashing heaps of bugs in the new item serialization.
As I had hoped, we now have full client side predicted equipment simulation and switching regardless of latency to server! This means at 200 ping, you can switch weapons and fire without that sluggish delay that exists currently, what you see other players doing on your screen will always match their screen, and that awkward jam where your gun won’t shoot will never happen again
ARBITRARY STATE ON ITEMS – REMOVING INFAMY
Something I’ve touched on before briefly, but not for a while, is the goals behind ItemV2. First and foremost, we want to get rid of infamy. Infamy was an experiment that for us patched up a simple issue: The more time you invest in your gear, the more you have to lose if you die. Full loot with extremely valuable gear doesn’t work as you get set back to square one if you die. Infamy gave people a choice, to not risk their gear unless absolutely necessary. Protecting noobs from griefing was an added bonus to the system, not the primary reason.
I wrote a large blog post on the ins and outs of the topic here: Infamy – State Of the Union
While I could have patched in some bandaid features that would have lessened the issue, I believe it would have put us at the end of our lifecycle in development. When building anything, you can only overextend yourself so far before you either need to improve the foundations or leave it as is. This is what I see in a lot of early access games, where the dodgy hacks thrown in to get something out the door make the workload for adding new features so large most just call it quits.
What we ended up doing instead over the last 6 months was some what of a “Reboot” to some large parts of our systems. Being a absolutely crucial part of our game, items are how we create value, simulate equipment, drive the economy and balance almost everything in game.
Our original system was based on items defined ahead of time that dont change at all. Eg red pickaxes were equal and we had no way of storing information against unique instances of items besides a hacky implementation of item transitions and ammo storage. Adding something like durability to an item, would require another hacky patch that all future items would need to work around. Considering we are working towards completely procedural constructed items where each instance in unique (think Borderlands) this was an impossible task. On top of this, the actual simulation of items you have equipped was a mess. While each persons client machine “predicted” the state its equipment was in, we had no way of determining if the prediction was done correctly. Resulting in the server and every other player having a different picture of what was going on than you did.
Solving the above problems were by far the most difficult engineering problems I’ve faced to date. Mostly because there is no right answer, and there isn’t really common industry knowledge of how to client side predicted high frequency simulation of complex moddable items in the scale of a persistent survival game. Nobody is doing it.
The good news is everything above is now solved in a robust architecture that also allows modders to create their own client side predicted equipment content and procedural item generators, all from the safety of our unity editor SDK. I know I have spoken about this before, but now we are reaching the point where we can start filling it with content.
REWRITING THE ITEM PROGRESSION
Back to the task at hand… to remove infamy means we need to completely rethink how we store value that a player has accumulated. If we go full loot, we need a way to ensure that being killed doesn’t set you back to square one. To do this we are completely re-writing the item progression from the ground up.
Now that we have an architecture that allows us to do infinitely more with items we are really going to shake things up. More on this in the coming weeks!
MILS
I had great success with the new baking software that I mentioned last week. Handplane baked out the normals quicker, with less work and better results than the previous software I was using. It’s a great step forward for this kind of work. So the Kanga chassis normal maps are complete and I also got through all the unwrapping on the uv maps for the rest of the body kits. Now I just have to lay out the UV’s scale them to the right sizes and I can bake them out as well.
I plan to be into texturing by the end of the week, and after the base texture is done I will need to design the skins that will decorate the Kanga so you can all customise colours and patterns and make the Kanga your own.
GAVKU
So this week I have been working on a player jacket. It involved a bunch of noodling around in Marvelous Designer especially when I was getting closer to something I liked, as it can be pretty easy to tie yourself in knots, or get in to a loop of continually pushing and pulling segments trying to get something that would sim correctly.
I placed the player tshirt underneath the garment to help give it some bulk as well as layer cloning the pattern when I was happy with it to beef it up a little.
This is an image of the pattern, and undershirt.
Marvelous Designer 3d screengrab
This mesh needed a bit of cleaning up in zbrush and max, mainly due to birdsnesting of verts ( a whole bunch of messy verts in one location ), as well as having to flip normals on certain segments.
I then took it in to mudbox to clean up some lines.
I have built and unwrapped the low, and am in the process of baking and texturing. I’ll then be test skinning it, and seeing how well it interacts with gear lying underneath ie: tshirts, vest etc.
TOM
The Kanga draws closer! This week I’ve been working on integrating the Kanga properly into the game, creating the equippable items and ui window and setting up the paint and masking system.
The gearboxes and engines come in the same variations as seen on the Roach and Goat at the moment (offroad/on road and damaged/weak/standard/powerful respectively). There are 3 wheel types to match the 3 panel attachment types that affect traction, weight, turn speed and fuel consumption.
The panel attachments will be split into front and back panels the same as the Goat, I’ve created some placeholder panels to add storage with the rear containers and am experimenting with adding vehicle armor through attachments.
I’ve also changed our explosion effect so it scales with explosion size. Below you can see the difference between a vehicle with no fuel and a vehicle with max fuel. The max fuel one is a bit overkill at the moment and will likely be scaled back once I dive into balancing this week.
Something we want to achieve with the vehicle changes is being able to remove the claim system, vehicle auto despawns and vehicle spawn limits. The real blocker for us to achieve this at the moment is the rendering overhead, especially when you have heaps of vehicles in the same location like when you drive by the garage of that player who has been hoarding vehicles and it loads them all. To deal with this I’ve been working on a dynamic level of detail system that sorts objects by their priority and uses this sorted list to decide the level of detail the object needs to be displayed at. The system has a player chosen budget so users can make their own compromise between level of detail and performance depending on their hardware.
At the moment it’s just running on vehicles with priority based on distance and whether the vehicle is occupied (so vehicles with players in them always have a higher priority) but if it works well there we can extend it into players, constructions and other dynamic objects.
Here’s a visualization of the system working on a pile of Goats