Rust - 2546\4.04.2024
HurtWorld - 1.0.0.6
COW_TRIX
Hey folks! Been working on some bugs this week, which should be fixed in 0.3.6.2, out soon. Also been finishing up on getting modded vehicles in, working on an example project, and expanding some feedback for the UI.
There was a pretty nasty bug where structures wouldn’t load properly for clients, when connecting to servers under heavy load. The reason for that turned out to be “I’m an idiot”. To make client structures load a bit smoother and try to put the server under less load when player connects, I split the structure initialization step up to take place over a few frames. The logic was basically to get a pooled bitstream, fill it with data, and if we had hit the frame budget of structure data syncs, wait until the next frame to send it. Yeah… that was the problem. I got the bitstream, which is only valid for that frame, and then held onto it for more than one frame! On busy servers, some other networked object would come along, clear that stream, and use it, meaning the client would receive a garbled mess and not be able to build the structure. Thankfully this should be fixed now.
I’ve also been getting vehicles moved over to the SDK, which has opened up a lot of new modding possibilities. As a result of vehicles being in, other machines are buildable in the SDK as well. At this point, not only can you make a custom vehicle, but you can also make a custom inventory-based machine with Oxide scripting. This is because we also moved across a fair bit of UI scripting so the vehicle UIs live in the SDK as well. So, custom storage crates, and simple item-based machines are now entirely possible.
Custom vehicles are pretty cool as well! I put in what I called the Cancallare, a pretty cool sports car. It cost me $5 from the Asset Store, and was a breeze to implement! That whole library of
cars is pretty cool actually, check them out. Modded vehicles are a bit simpler than the Goat and Roach, as we can’t do things like custom items that make the car look different, or custom paints. These features will come soon. Check out the Cancellare on the Steam Workshop.
I also gave UI a bit of love, as part of putting in support for custom UIs. Itemslots are now much more consistent as they mostly build themselves by script, and should also be slightly more performant. They will no show when a slot is one-way (you can only place or take the item, e.g. ambers in an ownership stake) or locked (you cannot take or place the item, e.g. attachments on a vehicle). Previously you kind of had to figure this out by trying to drag items in and out, but now there should be some more intuitive feedback there.
MILS
The cities are now near a place where we are fairly happy with them. The city currently exists in a test map and so need to be moved into the actual map that will exist in the game. I’ll be working with Cow_Trix on this process when he is finished implementing some other game items. I finished off the public pool structure for the suburban area of the city and I built some high rise apartment structures.
While Cow_Trix is busy on his other tasks, I am starting to work on the Dirtbike, for now I have named it a ‘Kanga’ The base chassis is inspired by the bike below, which is a KTM 450. I’ll be modeling the chassis first then doing some concepts of the varying body kits later. Can’t wait to drive it.
SPENCER
This week I’ve been finalizing the SDK setup of our Item creator so that everyone has access to the powerful tools we use. One of which is the seriously awesome unity plugin NodeCanvas. Big shoutout to our homies over at Paradox Notion for licencing us a re-distributable copy of their editor tools for our SDK! Any unity heads out there should definitely check them out.
Now that everything is loading nicely from asset bundles, I am going through the process of re-building all the existing gear and item functionality in the new system with the upgrades required for dynamic generation. Nothing fancy to show off this week but getting closer to the baseline of ItemV1.
Why aren’t these things in the game yet?
I’ve seen a lot of posts of people being confused where the content from the blog is, expecting it to be in game the week after we show it. Game development is a long process. What you see on this blog are things we are actively working on, but doesn’t mean you will see it in the next patch. Despite Hurtworld being in alpha, and lots of you being keen to try out half finished content, we like to get things up to a decent standard before putting them in game. There are some things that benefit from live playtesting while they are still in their infancy, but some things that would just cause havok on the current gameplay experience if put into the game before being ready. That said, if you see something in here, there is a 99% chance it will make it into the game eventually, but only when it is ready and can have its full impact. We could throw in all the creatures we have modeled, animated as re-skinned Bors / Tokars, but this wouldn’t do them justice. Instead we will wait until we have some time to allocate to coding some new and interesting AI for them, and have a new area of the map that suits them before releasing them into the game.
Things like weapon attachments will be released as part of a very big update that we have been working on for a while. As it will change the way items are found, crafted and used (along with changes to infamy), we need to rebalance most of the content in the game as a consequence. This isn’t a quick job, we want to make sure we get it right.
We also have multiple programmers working on different things. We release hotfixes when bugs come up otherwise they would remain unfixed for weeks / months while we finish working on content, this would really suck. So when you see a hotfix release, its not instead of a content release. Content is coming.
TOM
This week I’ve been working on the motorbike, more specifically, the crash system. I started getting the system I briefly mentioned in blog #36 up and running where the hips + torso are simulated on the server and the rest of the limbs + head are simulated client side. Unfortunately while this met our performance requirements it never looked quite right. I found the torso was able to move and roll too freely and when limbs were being rolled over they were often put into impossible positions on the client side causing strange artifacts and jittering behaviour in the physics system.
Unfortunately sometimes after using a physically based system the results are close but not close enough leaving us stranded somewhere in the uncanny valley, after reviewing this we decided to move away from ragdolls for crashing and back towards an animation driven system. Now we are making the player curl up into a protective pose during the crash. Luckily this pose can be well approximated by a capsule shape so the server side physics stay the same (note: I’m just using the surrender emote as a placeholder while this is still in programmer art mode).
The player remains in this crash state until they fall below a safe speed where they can start getting up.
This means some crashes can last a long time while you tumble down a hill or something similar.
As you can see in this clip I was lucky the cliff stopped me!
As you can see it’s still pretty rough around the edges so this coming week i’ll be polishing up this system and extending it so crashes will damage you and break your legs on a large enough impact. I’ll also be extending this crash system to the existing vehicles. This should differentiate the vehicles a bit more and give players the choice between safety (the roach) and maneuverability (the motorbike) with the goat falling somewhere in between. We don’t want the roach to be totally safe though and a large enough impact should be enough to send you through the windscreen or out the door (especially without panels).
GAVKU
So I think I have become somewhat comfortable with Marvelous Designer. At least to the extent that I can handle most simple garments, and have an understanding of how most of the tool set works as well as the best non-destructive way to go about getting results out of it..
We used a basic tshirts/vest combo as a test case.
My workflow for this gear is to have something in Marvelous Designer and manipulate/sim it till I get the desired result. Then take the exported mesh into zbrush to clean it up with zremesher and add ( or subtract ) additional sculpt details. This results in a nice, clean, easy to read mesh that I can then easily construct a game mesh around in topogun.
Once this is done I bake out all mesh’s and texture in the usual way
Textures are still a work in progress at the moment.
Hey folks! Been working on some bugs this week, which should be fixed in 0.3.6.2, out soon. Also been finishing up on getting modded vehicles in, working on an example project, and expanding some feedback for the UI.
There was a pretty nasty bug where structures wouldn’t load properly for clients, when connecting to servers under heavy load. The reason for that turned out to be “I’m an idiot”. To make client structures load a bit smoother and try to put the server under less load when player connects, I split the structure initialization step up to take place over a few frames. The logic was basically to get a pooled bitstream, fill it with data, and if we had hit the frame budget of structure data syncs, wait until the next frame to send it. Yeah… that was the problem. I got the bitstream, which is only valid for that frame, and then held onto it for more than one frame! On busy servers, some other networked object would come along, clear that stream, and use it, meaning the client would receive a garbled mess and not be able to build the structure. Thankfully this should be fixed now.
I’ve also been getting vehicles moved over to the SDK, which has opened up a lot of new modding possibilities. As a result of vehicles being in, other machines are buildable in the SDK as well. At this point, not only can you make a custom vehicle, but you can also make a custom inventory-based machine with Oxide scripting. This is because we also moved across a fair bit of UI scripting so the vehicle UIs live in the SDK as well. So, custom storage crates, and simple item-based machines are now entirely possible.
Custom vehicles are pretty cool as well! I put in what I called the Cancallare, a pretty cool sports car. It cost me $5 from the Asset Store, and was a breeze to implement! That whole library of
cars is pretty cool actually, check them out. Modded vehicles are a bit simpler than the Goat and Roach, as we can’t do things like custom items that make the car look different, or custom paints. These features will come soon. Check out the Cancellare on the Steam Workshop.
I also gave UI a bit of love, as part of putting in support for custom UIs. Itemslots are now much more consistent as they mostly build themselves by script, and should also be slightly more performant. They will no show when a slot is one-way (you can only place or take the item, e.g. ambers in an ownership stake) or locked (you cannot take or place the item, e.g. attachments on a vehicle). Previously you kind of had to figure this out by trying to drag items in and out, but now there should be some more intuitive feedback there.
MILS
The cities are now near a place where we are fairly happy with them. The city currently exists in a test map and so need to be moved into the actual map that will exist in the game. I’ll be working with Cow_Trix on this process when he is finished implementing some other game items. I finished off the public pool structure for the suburban area of the city and I built some high rise apartment structures.
While Cow_Trix is busy on his other tasks, I am starting to work on the Dirtbike, for now I have named it a ‘Kanga’ The base chassis is inspired by the bike below, which is a KTM 450. I’ll be modeling the chassis first then doing some concepts of the varying body kits later. Can’t wait to drive it.
SPENCER
This week I’ve been finalizing the SDK setup of our Item creator so that everyone has access to the powerful tools we use. One of which is the seriously awesome unity plugin NodeCanvas. Big shoutout to our homies over at Paradox Notion for licencing us a re-distributable copy of their editor tools for our SDK! Any unity heads out there should definitely check them out.
Now that everything is loading nicely from asset bundles, I am going through the process of re-building all the existing gear and item functionality in the new system with the upgrades required for dynamic generation. Nothing fancy to show off this week but getting closer to the baseline of ItemV1.
Why aren’t these things in the game yet?
I’ve seen a lot of posts of people being confused where the content from the blog is, expecting it to be in game the week after we show it. Game development is a long process. What you see on this blog are things we are actively working on, but doesn’t mean you will see it in the next patch. Despite Hurtworld being in alpha, and lots of you being keen to try out half finished content, we like to get things up to a decent standard before putting them in game. There are some things that benefit from live playtesting while they are still in their infancy, but some things that would just cause havok on the current gameplay experience if put into the game before being ready. That said, if you see something in here, there is a 99% chance it will make it into the game eventually, but only when it is ready and can have its full impact. We could throw in all the creatures we have modeled, animated as re-skinned Bors / Tokars, but this wouldn’t do them justice. Instead we will wait until we have some time to allocate to coding some new and interesting AI for them, and have a new area of the map that suits them before releasing them into the game.
Things like weapon attachments will be released as part of a very big update that we have been working on for a while. As it will change the way items are found, crafted and used (along with changes to infamy), we need to rebalance most of the content in the game as a consequence. This isn’t a quick job, we want to make sure we get it right.
We also have multiple programmers working on different things. We release hotfixes when bugs come up otherwise they would remain unfixed for weeks / months while we finish working on content, this would really suck. So when you see a hotfix release, its not instead of a content release. Content is coming.
TOM
This week I’ve been working on the motorbike, more specifically, the crash system. I started getting the system I briefly mentioned in blog #36 up and running where the hips + torso are simulated on the server and the rest of the limbs + head are simulated client side. Unfortunately while this met our performance requirements it never looked quite right. I found the torso was able to move and roll too freely and when limbs were being rolled over they were often put into impossible positions on the client side causing strange artifacts and jittering behaviour in the physics system.
Unfortunately sometimes after using a physically based system the results are close but not close enough leaving us stranded somewhere in the uncanny valley, after reviewing this we decided to move away from ragdolls for crashing and back towards an animation driven system. Now we are making the player curl up into a protective pose during the crash. Luckily this pose can be well approximated by a capsule shape so the server side physics stay the same (note: I’m just using the surrender emote as a placeholder while this is still in programmer art mode).
The player remains in this crash state until they fall below a safe speed where they can start getting up.
This means some crashes can last a long time while you tumble down a hill or something similar.
As you can see in this clip I was lucky the cliff stopped me!
As you can see it’s still pretty rough around the edges so this coming week i’ll be polishing up this system and extending it so crashes will damage you and break your legs on a large enough impact. I’ll also be extending this crash system to the existing vehicles. This should differentiate the vehicles a bit more and give players the choice between safety (the roach) and maneuverability (the motorbike) with the goat falling somewhere in between. We don’t want the roach to be totally safe though and a large enough impact should be enough to send you through the windscreen or out the door (especially without panels).
GAVKU
So I think I have become somewhat comfortable with Marvelous Designer. At least to the extent that I can handle most simple garments, and have an understanding of how most of the tool set works as well as the best non-destructive way to go about getting results out of it..
We used a basic tshirts/vest combo as a test case.
My workflow for this gear is to have something in Marvelous Designer and manipulate/sim it till I get the desired result. Then take the exported mesh into zbrush to clean it up with zremesher and add ( or subtract ) additional sculpt details. This results in a nice, clean, easy to read mesh that I can then easily construct a game mesh around in topogun.
Once this is done I bake out all mesh’s and texture in the usual way
Textures are still a work in progress at the moment.