Was looking over the Rust roadmap, and considering a pretty interesting point on the "Next" section (As of Mar 2019). What is essentially, nerfing honeycomb.
I gave it some thought, and the idea that I had was with a skeletal torque model for structures. It would be used to examine a wall relative to adjacent structures, and assign a structural integrity value that adjusts the damage resistance of the wall. So, a wall with ideal supports would for example minimize incoming damage by half, based on some diminishing return curve on the "Support" value. An unsupported wall sitting on foundation takes normal damage. An improperly supported wall under a load suffers a penalty to its durability, taking increased damage.
To visualize, imagine instead of a solid wall, each wall is a Square with an X through it. The left vertical is 1, the right vertical is 2, the top horizontal is 3, and the bottom horizontal is 4, the / beam on the X is 5, and the \ is 6. Now imagine a structure composed of a 3 by 3 of walls.
The bottom most walls have a load applied to their 1 and 2 based on the walls above them. This is a float determined by the amount and material of the walls above it. 3 has a load value assigned to it based on the floors which attach to it. 4 has a value assigned based on the foundation on which it rests.
5 and 6 are a bit tricky to explain, but not calculate. They would represent the torque applied to a wall, based on the uneven distribution of load across it. Imagine a wall which has a very high load on its 1 but not its 2. In reality, this wall would be very rigid on one side and flexible on the other. The result being that when stressed, it would be exceptionally vulnerable.
An unsupported wall can flex in its entirety, distributing stress even across its foundation and maintaining its integrity. But when stress is unevenly distributed, such as when some parts of the wall are more or less flexible. A small amount of stress, unevenly distributed in a material is far more dangerous than a much larger amount distributed much better. If this is hard to visualize, imagine a large pile of sand. If you lay on top of it, the entire mound compresses. The friction between sand grains increases as they are forced together, and they support one another. But if you stand up and go to the side instead of the top of the pile, you don't compress it evenly. Some parts are pressed into eachother at different amounts. Shear lines don't match up, and eventually things start slipping past each other. Long story short, a symmetry is really good. Even a crappy wall is good if it distributed stress evenly.
A second detail would be floors. They would have a only 4 skeleton bones. They would have a value based on their material, and would apply a load to all connected walls based on how many walls are supporting the floor. The less walls there are, the exponentially more burdensome the floor is to the walls that continue to support it. The equation for the load would be something along the lines of:
a^(b/U)) where U is the value representing the number of unsupported sides, a is the material's base load, and b is used to tweak exactly how quickly the load ramps up with each consecutive missing wall.
The final value is calculated based on the various loads, with weights aside to the various number (4 for example could be negative, reflecting how well the base material holds up and absorbs stress from the above wall) and anytime the wall takes damage this value is used to adjust the amount of damage taken before applying it to the wall's health pool.
So the way this address the issue of honeycombing is fairly simple and direct. As the structure of the base degrades during a raid, eventually, honeycomb becomes more and more detrimental. At first it may have been providing support, and picking up the slack where prior layers had failed, now all that heavy stone, metal, and wood is stressing the walls below it, putting them under a load, and creating large differences between one side of the wall and another. The end result is that ultimately, honeycombing would be incredibly infeasible above the first floor. Meaning that if you have the ladders to get onto the top of the honeycombing, the ideal design would have just plain single walls here.
Additionally, once you were in the honeycombing, the load of walls above the one's you just broke would be bearing the additional load of the now unsupported wall. When a wall under a load breaks, adjacent walls also take an amount of portion of the last instance of damage based on the load the wall was under. The result being that as parts of a base collapse, it would drag itself down and harm other portions, modeling real building far better.
For the final concern, performance, I've got an answer too. The values would not be tracked and updated real time. It would work similar to block updates in VOXL games like Minecraft. Whenever a wall of floor was place/upgraded/broken it would trigger a block update, telling the managing entity "Hey you need to recalculate the values for there parts of the structure" which it would do, and then the only part the wall itself would store is the final damage modifier, with no real concern for how it was gained or when it needs to be updated.
As far as coding goes, it could just be a component on the foundation. When the first foundation is placed, it adds the StructureSupportManager component to itself and marks itself as the "Master Foundation" and prevents new foundations from adding it . Whenever an update was triggered, it would add them to whatever structure (likely a matrix) which was keeping track of the walls as simple float values, perform relevant operations including removing any which no longer are connected. When this foundation was being destroyed, it would look for a connected foundation to promote to the Master, and if none could be found, then it doesn't matter the building is no longer standing. Other optimizations like automatically promoting the Foundation the TC is deployed on to the Master to minimize the likelihood of having to do future promotions.
Because it only performs calculations as needed, and just caches the output for future use, it remains performant, unless you're constantly destroying and replacing tons of walls at once. But I imagine rust doesn't particularly like you doing that as it is.
What
Its just a way to nerf honey combing, pulling from the real engineering problem of load distribution. The current system is a absolute load system. But using a relative one to modify damage on a sliding scale would be better and more realistic
Rust
wrong section. I am moving this to the rust section
Sorry, you need to Log In to post a reply to this thread.
