Rust - 2546\4.04.2024
HurtWorld - 1.0.0.6
MILS
This week I did some exploration into producing a better type of metal finish for the guns we have been working on. The aim here is to create a more satisfying metal finish for the new weapons, which will make them feel more alive and ‘heavy metal’ The screenshot below may not be where this actually ends up, but is a step in the right direction.
I have taken the new gun designs in a slightly different direction. Instead of each gun chassis having completely interchangeable parts, we are going to keep the central body of each gun the same. So for example if I had machine gun, the grip and the core of the gun will now be one item. This will take a lot of the headache out of the component design and give the main body of the weapons a distinct silhouette. The issue with the first creature weapon designs was that the gun body generally ended up being a square or cylinder of a mix of the two. All of the design work so far will still be used, they will just be reworked to adapt to this new design ideal.
GAVKU
I was sick for a lot of last week so not not a great deal on my end. Finished getting the new gear moved across and tested. At the moment am going trough some of the items and testing ways to apply paint-ability to them. Some basic items may end up being universally paintable with the colour changing the entire item. Something say like the tshirt. Or we may keep a basic set and allow logos and trims to be changed.
Other items we will wish to keep the overall aesthetic integrity of the item intact and instead allow the trims, stripes, tape etc to be altered.
TOM
This week I’ve been continuing to work on our character controller problems which unfortunately became a much harder problem to solve than I originally thought, delaying the 0.3.7.5 update.
Whilst my first attempts at solving the problem were able to remove the penetrating through walls exploit they introduced a lot of jitter and stuttering when colliding with vehicles which we decided was unacceptable.
This jitter was due to the delay between client and server making clients see vehicles slightly in the past compared to the server. What was considered an illegal move on the client and rewound due to vehicle penetration was considered legal on the server because the vehicle had already moved on out of that same position. This meant the client was corrected back into the vehicle by the server only then to have the whole process repeat. This was solved by changing the method of detecting illegal moves from physics checks to directly checking actual movement changes against the expected movement change and allowing for a significant margin of error (without being so significant that you could still ‘push’ through geometry).
I also removed the ability for a rewind to be triggered clientside by changes in the y-axis (up and down), instead just running them on the server and allowing the correction method to rewind the client over a number of frames which again reduced jittering. We’ve also slowed the speed of server corrections slightly which again helps to increase smoothness.
I’ve also tightened up our crouching method, previously we were just changing the character controller height which would also shrink the collider upwards from the feet (we did this due to strange behaviour when changing the controllers center and how it affected triggers, as part of this change we have decoupled the controller from triggers completely) which could strangely enough make it easier to walk up ledges while crouched and also allow the player to be pushed under the world by something pushing down on their head.
Now in effect we have the same crouch height with a more accurate collision volume, in practice however the minimum height you can crawl through has been reduced as you can no longer squeeze your feet under the world.
One upside of the patch delay is I also had some time to squeeze in a small change where you can now change your display through the graphics options, you can find this under Options > Graphics > Resolution > Display number.
As I’m writing this I’m building the release candidate for 0.3.7.5 to go onto devtest, if testing goes well (fingers crossed) we should be releasing this patch very soon.
SPENCER
This week I’ve been integrating sub frame bullet events into the equipment pipeline based on last weeks experiments. I also changed the repeat method to use single audio files per bullet instead of 4 bullets per file to simplify the integration To ensure I had the same audio results, I constructed single shot sounds using snippets from the fully automatic clips and tails stiched on that get silenced when a new bullet is fired. This allows me to drive the audio system on a much simpler basis, as now only the state machine needs to know how fast the bullets will be firing. Results are feeling very good.
While adding back in the bullet sound emission to weapons, I spent a bit of time building a new sound layer that manages creation and configuration of AudioSources in Unity that allows us to define things like falloff distance, clip group selection details and distanced based clip swapping all at the sound level. By default, the Unity audio workflow is designed to have most of this stuff configured on the object emitting the sounds which really sucks. Given that a player will emit all sorts of different sounds with different falloff properties, you are forced to create a multitude of audio sources all with explicit configuration on every player. Now we can say, an un-silenced 5.56mm supersonic bullet has a logarithmic falloff with a max distance of 1000m, and is substituted for a supersonic crack if the listener is a long distance away, while a footstep can only be heard upto 20m away. Anything that wants to play either of these sounds will only need to specify what sound and where.
The other reason we need this is to decouple sounds from code (previously represented by an enum) so they can be loaded from the SDK using our new mod architecture.
Here is a test rifle in game running at a few different fire rates, previously every gun needed to fire at exactly 10 bullets per second, or 20 bullets per second so it would sync up with the 20hz tick rate.
This displays an interesting problem in that, as recoil is calculated per bullet, increasing the fire rate makes the recoil head a bit out of control. I will likely add a scaling factor to recoil depending on the fire rate that is generated for the weapon.
I will be pushing round 2 of our internal deathmatch build this week and should hopefully have something for you guys soon.
COW_TRIX
This week I’ve been further building up the map, and starting to make some real progress. I’m pretty happy with where we’re at in terms of the tools and workflow I’ve built up over the last few months. I can do everything I need to quickly, don’t need to worry about ever throwing away work, and can tweak some base variables and see the changes cascade up the generation. I’ve also been going back to the city, which still has a fair bit of work needing to be finished.
I also got started on implementing all the entity stats needed for water to work (i.e. kill you) so that meant starting to implement an oxygen stat that would make you asphyxiate. Implementing this made me realise how obtuse and confusing the entity stat system can be in it’s current state, which I didn’t beforehand just copying over old configurations. I’m still figuring out the best way to make effects like oxygen only care about the position of the player’s head – as it doesn’t make sense for someone to start drowning when they stick their feet in water.
I’ve added a framework for landmarks and structures to tell the generation what it needs to do to accommodate it. This is based a lot off what I’ve shown previously with intersections. Now, a structure can define several shapes around it’s foundation which the map generation will take into account when generating, removing rocks, trees and even hills to make way for the structure. While for a time I considered making even placing these man-made landmarks procedurally, I think we will have more ability to design if we are able to specifically place them.
This outpost structure dynamically raises the terrain and places some trees.
We also now have a way to place trees explicitly in the tree system, which has meant that the city has come to life! The once empty planter boxes, parks and sidewalks can now have trees which use the existing, high performance system.
This week I did some exploration into producing a better type of metal finish for the guns we have been working on. The aim here is to create a more satisfying metal finish for the new weapons, which will make them feel more alive and ‘heavy metal’ The screenshot below may not be where this actually ends up, but is a step in the right direction.
I have taken the new gun designs in a slightly different direction. Instead of each gun chassis having completely interchangeable parts, we are going to keep the central body of each gun the same. So for example if I had machine gun, the grip and the core of the gun will now be one item. This will take a lot of the headache out of the component design and give the main body of the weapons a distinct silhouette. The issue with the first creature weapon designs was that the gun body generally ended up being a square or cylinder of a mix of the two. All of the design work so far will still be used, they will just be reworked to adapt to this new design ideal.
GAVKU
I was sick for a lot of last week so not not a great deal on my end. Finished getting the new gear moved across and tested. At the moment am going trough some of the items and testing ways to apply paint-ability to them. Some basic items may end up being universally paintable with the colour changing the entire item. Something say like the tshirt. Or we may keep a basic set and allow logos and trims to be changed.
Other items we will wish to keep the overall aesthetic integrity of the item intact and instead allow the trims, stripes, tape etc to be altered.
TOM
This week I’ve been continuing to work on our character controller problems which unfortunately became a much harder problem to solve than I originally thought, delaying the 0.3.7.5 update.
Whilst my first attempts at solving the problem were able to remove the penetrating through walls exploit they introduced a lot of jitter and stuttering when colliding with vehicles which we decided was unacceptable.
This jitter was due to the delay between client and server making clients see vehicles slightly in the past compared to the server. What was considered an illegal move on the client and rewound due to vehicle penetration was considered legal on the server because the vehicle had already moved on out of that same position. This meant the client was corrected back into the vehicle by the server only then to have the whole process repeat. This was solved by changing the method of detecting illegal moves from physics checks to directly checking actual movement changes against the expected movement change and allowing for a significant margin of error (without being so significant that you could still ‘push’ through geometry).
I also removed the ability for a rewind to be triggered clientside by changes in the y-axis (up and down), instead just running them on the server and allowing the correction method to rewind the client over a number of frames which again reduced jittering. We’ve also slowed the speed of server corrections slightly which again helps to increase smoothness.
I’ve also tightened up our crouching method, previously we were just changing the character controller height which would also shrink the collider upwards from the feet (we did this due to strange behaviour when changing the controllers center and how it affected triggers, as part of this change we have decoupled the controller from triggers completely) which could strangely enough make it easier to walk up ledges while crouched and also allow the player to be pushed under the world by something pushing down on their head.
Now in effect we have the same crouch height with a more accurate collision volume, in practice however the minimum height you can crawl through has been reduced as you can no longer squeeze your feet under the world.
One upside of the patch delay is I also had some time to squeeze in a small change where you can now change your display through the graphics options, you can find this under Options > Graphics > Resolution > Display number.
As I’m writing this I’m building the release candidate for 0.3.7.5 to go onto devtest, if testing goes well (fingers crossed) we should be releasing this patch very soon.
SPENCER
This week I’ve been integrating sub frame bullet events into the equipment pipeline based on last weeks experiments. I also changed the repeat method to use single audio files per bullet instead of 4 bullets per file to simplify the integration To ensure I had the same audio results, I constructed single shot sounds using snippets from the fully automatic clips and tails stiched on that get silenced when a new bullet is fired. This allows me to drive the audio system on a much simpler basis, as now only the state machine needs to know how fast the bullets will be firing. Results are feeling very good.
While adding back in the bullet sound emission to weapons, I spent a bit of time building a new sound layer that manages creation and configuration of AudioSources in Unity that allows us to define things like falloff distance, clip group selection details and distanced based clip swapping all at the sound level. By default, the Unity audio workflow is designed to have most of this stuff configured on the object emitting the sounds which really sucks. Given that a player will emit all sorts of different sounds with different falloff properties, you are forced to create a multitude of audio sources all with explicit configuration on every player. Now we can say, an un-silenced 5.56mm supersonic bullet has a logarithmic falloff with a max distance of 1000m, and is substituted for a supersonic crack if the listener is a long distance away, while a footstep can only be heard upto 20m away. Anything that wants to play either of these sounds will only need to specify what sound and where.
The other reason we need this is to decouple sounds from code (previously represented by an enum) so they can be loaded from the SDK using our new mod architecture.
Here is a test rifle in game running at a few different fire rates, previously every gun needed to fire at exactly 10 bullets per second, or 20 bullets per second so it would sync up with the 20hz tick rate.
This displays an interesting problem in that, as recoil is calculated per bullet, increasing the fire rate makes the recoil head a bit out of control. I will likely add a scaling factor to recoil depending on the fire rate that is generated for the weapon.
I will be pushing round 2 of our internal deathmatch build this week and should hopefully have something for you guys soon.
COW_TRIX
This week I’ve been further building up the map, and starting to make some real progress. I’m pretty happy with where we’re at in terms of the tools and workflow I’ve built up over the last few months. I can do everything I need to quickly, don’t need to worry about ever throwing away work, and can tweak some base variables and see the changes cascade up the generation. I’ve also been going back to the city, which still has a fair bit of work needing to be finished.
I also got started on implementing all the entity stats needed for water to work (i.e. kill you) so that meant starting to implement an oxygen stat that would make you asphyxiate. Implementing this made me realise how obtuse and confusing the entity stat system can be in it’s current state, which I didn’t beforehand just copying over old configurations. I’m still figuring out the best way to make effects like oxygen only care about the position of the player’s head – as it doesn’t make sense for someone to start drowning when they stick their feet in water.
I’ve added a framework for landmarks and structures to tell the generation what it needs to do to accommodate it. This is based a lot off what I’ve shown previously with intersections. Now, a structure can define several shapes around it’s foundation which the map generation will take into account when generating, removing rocks, trees and even hills to make way for the structure. While for a time I considered making even placing these man-made landmarks procedurally, I think we will have more ability to design if we are able to specifically place them.
This outpost structure dynamically raises the terrain and places some trees.
We also now have a way to place trees explicitly in the tree system, which has meant that the city has come to life! The once empty planter boxes, parks and sidewalks can now have trees which use the existing, high performance system.