Rust - 2546\4.04.2024
HurtWorld - 1.0.0.6
TOM
This week I’ve been pushing those vehicle related fixes into the latest patch, helping test the patch and also starting testing the city environment.
Performance is a big priority for us at Bankroll so I’ve been looking into how we can have all the extra detail of the city without a large performance overhead.
To achieve this I’ve been working on properly integrating the baking system I was working on in the first week into both the mapsdk and the Hurtworld client.
On the mapsdk side of things we tag all the objects that are part of the bake process as a ‘DetailObject’. Then when you run the bake process, the environment is broken into a 2d grid and all the detail objects are grouped based on the grid cell they are sitting in. Each cell is then baked together into the least amount of objects possible (Unity has a vertex limit of ~65k per mesh).
This step then repeats except it looks for ‘DetailLOD’ rather than ‘DetailObject’. These DetailLOD objects define a low resolution version of the cell that will be displayed whenever the high poly version isn’t loaded. We do this so we can still have important occlusion objects like walls and containers even if the cell isn’t fully loaded, without this a player could see another player behind an object once they were far enough away to unload the cell.
The next step is to grab all the colliders (these define the collision geometry) and bake these all together as well, now we remove all the detail objects to free up memory and reduce draw calls and create a new object to hold the data about the grid along with lookup tables so we can quickly turn a cell index into a list of either the high or low resolution renderers. Because these are destructive changes we save the post-bake scene into a new file ready for publishing or further tweaking.
On the game client side the player on load will look for the grid data object when they first spawn. If its not found the grid manager deletes itself to free resources, if it is found it rebuilds the grid with the given settings and gets the references to the lookup tables. The player then builds a list of offsets which essentially are a set of rules to easily find the index of the surrounding cells. The size of this adjacency list will be controllable from the settings allowing you to stream in more or less cells depending on what your computer can handle.
As you move through the level the grid manager activates the high poly renderers for all adjacent cells while deactivating the low poly renderers. Any cells that fall outside the adjacency list swap back to the low poly version.
Between this system and other gains we’ve made by not using the terrain system in the city we’re currently seeing performance similar to Diemensland on live.
Speaking of performance if you haven’t tried the deferred rendering setting I highly recommend it! Because our post processing pipeline relies on both depth and normal screen space textures and in deferred rendering we get these ‘for free’ as part of the usual rendering process.
Everyone who meets our minimum specs should be able to use deferred rendering and it should produce be a performance improvement for everyone so please try it out if you haven’t yet!
MILS
I have been adding more buildings to the industrial and residential areas. I have started building a few ‘hero’ structures, which will give character to the mass of buildings.
I created a ‘Smelter’ structure, which will be a good positional reference for people as they cruise around the industrial area. It’s tall stacks can be seen from a distance and used by a player to determine their location.
I am still working on a dried out pool, which will be in the suburban area. This would be a good contention point for resources.
COW_TRIX
Hey folks! Been busy getting 0.3.6.0 and 0.3.6.1 out and running this week, and fixing some bugs that came up with that release. This was one of those updates that seemed quite small on the surface, as is often the case in game development. We take something, tear it back, and build it back up to where it was but with a better structure. Same looking house, better foundations. However, it really should be a different ballgame now for modding as we know have a framework all set up.
I’ve got a big, ever-growing list of little fixes and bugs that I’ll move onto next. In terms of big tasks, I’m going to get modded vehicles in first, and then the ol’ raid drill. Modded vehicles should be pretty easy now. You’ll be restricted to four-wheelers at this point, Tom’s awesome two-wheel vehicles are still some time away. Got any ideas about cool custom cars? Let us know!
I’ll also be working on the raid drill, a new method for raiding. We couldn’t implement this device when it got made back in Dev Blog #20, but now with the new construction system it should be pretty trivial. We’ve been thinking about how the drill will work in terms of gameplay. While all of this is subject to change, we’ve got some ideas about how it can be different to raiding with C4. We think the drill will be a loud device that will draw attention, making it risky especially as you’re using it in enemy territoy. It may require maintainence, meaning you won’t be able to just set and forget it. You will need to either replenish some resource, or maybe just turn it back on. This is to increase the risk. But the advantage may be that instead of needing to rely on det-cap chance, you’ll be able to make raid drills using farmed materials. Something else to consider is making C4 less effective on some types of materials, and raiding drills be the more effective choice. This way, you can structure a base so that it forces any raiders to use both methods. It’ll be an interesting thing to implement, and we’ll definitely need to tweak and balance it carefully. It’s easy to see ‘balance’ as a simple set of scales, where you just add weight to one side or another. In a complex game though, it’s a bit more like a house of cards.
We’ll also be trying to pick up our game on Featured Servers, trying to get some for regions which don’t currently have any, and updating regions where servers have gone down or the playerbase has disappeared.
GAVKU
So I am fully back onto character gear. Initially I started modelling up a variety of different types of pants etc so that we could preview them in game see how they look on the moving character. The screenshot below was a couple of those tests ( un textured )
During this process we came across a piece of software called Marvelous Designer that looks promising in regards to speeding up our workflow when it comes to being able to crank out a bunch of standard clothing. The software was designed to be used in the fashion industry there has been a bit of a learning curve but I think I am coming to grips with it now. Basically the workflow we are pursuing is to build a piece in MD, generate, construct a game mesh on top, bake, then texture.
Basic tshirt and pants.
This is a work in progress jacket. Still need to add a collar and lapels.
SPENCER
I was planning on tackling recoil this week, but as the item construction was holding back creating any real complex items I started work on building the new Item creation system.
Item Creation System
Previously, we used a massive block of C# code called StaticItemBuilder to create our item list. As we move more and more of our content into the SDK to make it extensible, we rely on a new system of content creation that the core game has no knowledge of it (thus allowing mods to dynamically load in new content). Having items hardcoded into the game makes them very hard to modify, and even harder to author.
Over the last few weeks, we have been working on migrating our systems to be driven by ScriptableObject assets in Unity. The magic of these objects, is they can be packaged into assetbundles and loaded into the game at runtime. All we need to do, is create a nice editor for our SDK that allows definition of all the properties of a thing (eg construction attachments, items, vehicles etc) and expose those scripts via our SDK. We then create all the official content using the same tools we give to our modders, ensuring there is plenty of power there.
Back to the point, this week I’ve been working on the Item Creation editor! This little baby combined with the item behavior state machine editor, and the work Tom has been doing on mesh Baking, can configure everything needed to define something simple like Ash, to incredibly complex like a modular assault rifle.
We are at a point now for the firs time, where new items (not just simple ones) can be created without a single line of code! This is a big milestone for us, as it knocks down another wall between fast content generation, not only for our team but anyone who wants to see something in game.
This week I’ve been pushing those vehicle related fixes into the latest patch, helping test the patch and also starting testing the city environment.
Performance is a big priority for us at Bankroll so I’ve been looking into how we can have all the extra detail of the city without a large performance overhead.
To achieve this I’ve been working on properly integrating the baking system I was working on in the first week into both the mapsdk and the Hurtworld client.
On the mapsdk side of things we tag all the objects that are part of the bake process as a ‘DetailObject’. Then when you run the bake process, the environment is broken into a 2d grid and all the detail objects are grouped based on the grid cell they are sitting in. Each cell is then baked together into the least amount of objects possible (Unity has a vertex limit of ~65k per mesh).
This step then repeats except it looks for ‘DetailLOD’ rather than ‘DetailObject’. These DetailLOD objects define a low resolution version of the cell that will be displayed whenever the high poly version isn’t loaded. We do this so we can still have important occlusion objects like walls and containers even if the cell isn’t fully loaded, without this a player could see another player behind an object once they were far enough away to unload the cell.
The next step is to grab all the colliders (these define the collision geometry) and bake these all together as well, now we remove all the detail objects to free up memory and reduce draw calls and create a new object to hold the data about the grid along with lookup tables so we can quickly turn a cell index into a list of either the high or low resolution renderers. Because these are destructive changes we save the post-bake scene into a new file ready for publishing or further tweaking.
On the game client side the player on load will look for the grid data object when they first spawn. If its not found the grid manager deletes itself to free resources, if it is found it rebuilds the grid with the given settings and gets the references to the lookup tables. The player then builds a list of offsets which essentially are a set of rules to easily find the index of the surrounding cells. The size of this adjacency list will be controllable from the settings allowing you to stream in more or less cells depending on what your computer can handle.
As you move through the level the grid manager activates the high poly renderers for all adjacent cells while deactivating the low poly renderers. Any cells that fall outside the adjacency list swap back to the low poly version.
Between this system and other gains we’ve made by not using the terrain system in the city we’re currently seeing performance similar to Diemensland on live.
Speaking of performance if you haven’t tried the deferred rendering setting I highly recommend it! Because our post processing pipeline relies on both depth and normal screen space textures and in deferred rendering we get these ‘for free’ as part of the usual rendering process.
Everyone who meets our minimum specs should be able to use deferred rendering and it should produce be a performance improvement for everyone so please try it out if you haven’t yet!
MILS
I have been adding more buildings to the industrial and residential areas. I have started building a few ‘hero’ structures, which will give character to the mass of buildings.
I created a ‘Smelter’ structure, which will be a good positional reference for people as they cruise around the industrial area. It’s tall stacks can be seen from a distance and used by a player to determine their location.
I am still working on a dried out pool, which will be in the suburban area. This would be a good contention point for resources.
COW_TRIX
Hey folks! Been busy getting 0.3.6.0 and 0.3.6.1 out and running this week, and fixing some bugs that came up with that release. This was one of those updates that seemed quite small on the surface, as is often the case in game development. We take something, tear it back, and build it back up to where it was but with a better structure. Same looking house, better foundations. However, it really should be a different ballgame now for modding as we know have a framework all set up.
I’ve got a big, ever-growing list of little fixes and bugs that I’ll move onto next. In terms of big tasks, I’m going to get modded vehicles in first, and then the ol’ raid drill. Modded vehicles should be pretty easy now. You’ll be restricted to four-wheelers at this point, Tom’s awesome two-wheel vehicles are still some time away. Got any ideas about cool custom cars? Let us know!
I’ll also be working on the raid drill, a new method for raiding. We couldn’t implement this device when it got made back in Dev Blog #20, but now with the new construction system it should be pretty trivial. We’ve been thinking about how the drill will work in terms of gameplay. While all of this is subject to change, we’ve got some ideas about how it can be different to raiding with C4. We think the drill will be a loud device that will draw attention, making it risky especially as you’re using it in enemy territoy. It may require maintainence, meaning you won’t be able to just set and forget it. You will need to either replenish some resource, or maybe just turn it back on. This is to increase the risk. But the advantage may be that instead of needing to rely on det-cap chance, you’ll be able to make raid drills using farmed materials. Something else to consider is making C4 less effective on some types of materials, and raiding drills be the more effective choice. This way, you can structure a base so that it forces any raiders to use both methods. It’ll be an interesting thing to implement, and we’ll definitely need to tweak and balance it carefully. It’s easy to see ‘balance’ as a simple set of scales, where you just add weight to one side or another. In a complex game though, it’s a bit more like a house of cards.
We’ll also be trying to pick up our game on Featured Servers, trying to get some for regions which don’t currently have any, and updating regions where servers have gone down or the playerbase has disappeared.
GAVKU
So I am fully back onto character gear. Initially I started modelling up a variety of different types of pants etc so that we could preview them in game see how they look on the moving character. The screenshot below was a couple of those tests ( un textured )
During this process we came across a piece of software called Marvelous Designer that looks promising in regards to speeding up our workflow when it comes to being able to crank out a bunch of standard clothing. The software was designed to be used in the fashion industry there has been a bit of a learning curve but I think I am coming to grips with it now. Basically the workflow we are pursuing is to build a piece in MD, generate, construct a game mesh on top, bake, then texture.
Basic tshirt and pants.
This is a work in progress jacket. Still need to add a collar and lapels.
SPENCER
I was planning on tackling recoil this week, but as the item construction was holding back creating any real complex items I started work on building the new Item creation system.
Item Creation System
Previously, we used a massive block of C# code called StaticItemBuilder to create our item list. As we move more and more of our content into the SDK to make it extensible, we rely on a new system of content creation that the core game has no knowledge of it (thus allowing mods to dynamically load in new content). Having items hardcoded into the game makes them very hard to modify, and even harder to author.
Over the last few weeks, we have been working on migrating our systems to be driven by ScriptableObject assets in Unity. The magic of these objects, is they can be packaged into assetbundles and loaded into the game at runtime. All we need to do, is create a nice editor for our SDK that allows definition of all the properties of a thing (eg construction attachments, items, vehicles etc) and expose those scripts via our SDK. We then create all the official content using the same tools we give to our modders, ensuring there is plenty of power there.
Back to the point, this week I’ve been working on the Item Creation editor! This little baby combined with the item behavior state machine editor, and the work Tom has been doing on mesh Baking, can configure everything needed to define something simple like Ash, to incredibly complex like a modular assault rifle.
We are at a point now for the firs time, where new items (not just simple ones) can be created without a single line of code! This is a big milestone for us, as it knocks down another wall between fast content generation, not only for our team but anyone who wants to see something in game.