SOLUTION TO SPAGHETTI AND DOCKED ARMOR - YEAY MATH!

[Nosajimiki]

Okay, so here is some math I came up with that could fix the spaghetti problem with minimal changes to the game engine (and help balance docked armor a bit)

The idea is all about weighing a ship's surface area and size factor against how much structural damage it takes per block destroyed such that spaghetti ships become as brittle or more so than their high density counterparts without punishing the typical complexity of RP built designs or higher surface area of small ships.

So the math:

var shipBlockCount; // ship's block count.
var shipArea; // ship's number of exposed surfaces.
var sizeFactor = (length * width * height)^(1/3);
var hitDamage; // shields/armor/structural HP damage caused by a weapon
var preFactorModifier = 60; // a coefficient of how much integrity each block gives your ship
var postFactorModifier = 1.25; // a coefficient of how harshly the penalty scales once a ship breaks the integrity limit.

var shipIntegrityFactor = (shipArea * sizeFactor / shipBlockCount / preFactorModifier) ^ postFactorModifier;
if (shipIntegrityFactor < 1) {shipIntegrityFactor = 1;}
var shipIntegrity = 1 / shipIntegrityFactor * 100; // use this as % indicator of a ship's integrity.

hitDamage *= shipIntegrityFactor;

To verify the effects of this formula, I ran the following case studies:

Each of the following spaghetti ships are assuming that they are 250k block ships build in a 500 x 500 x 1000 m area .

If the system strands are 1x1 block, the co-efficient of damage = 106.921
If the system strands are 2x2 block, the co-efficient of damage = 25.160
If the system strands are 3x3 block, the co-efficient of damage = 10.801
If the system strands are 4x4 block, the co-efficient of damage = 5.952
If the system strands are 5x5 block, the co-efficient of damage = 3.729

This means that true spaghetti ships will suffer punishing damage from each hit simulating the effect of a weapon digging through 107 system blocks (or several thousand blocks if hit by a missile.) More reasonable low density ships by contrast such as the one with 5x5 block strands will suffer a factor closer to 4:1 meaning a penetrating shot will have the effect of hitting about 19 blocks if hit dead on.

This may still give spaghetti an advantage in some fights, but leave it open to some good hard-counter tactics as well as placing a soft cap on the size of spaghetti ships making unreasonably big ones worthlessly fragile.

The following are also factors regarding docked armor

If someone makes a flate plate that is 1x100x400, the co-efficient of damage = 1.187
If someone makes a similar mass sandwich plate that is 25x50x400, the co-efficient of damage = 3.404

While this does not make docked armor completely unviable, it encourages the use flat plates or smaller, selectively placed plates which cause a lot less lag than their wrapped or sandwich plate counterparts. This also makes docked hull completely nonviable on bigger ships, since it would get overheated after the first few hits anyway.

The following are case studies of various ships that could be defined as normal and minimally-exploitative that show that they would not take any integrity penalty because they all fall under a factor of 1.0

A solid 63x63x63 deathcube of the same aprox. mass as the above spaghetti ships would have a shipIntegrityFactor of 0.100.

An extremely RP happy sample frigate of the same mass that is 25x50x400 with about a 50%
density would have a shipIntegrityFactor of 0.639.

Very small ships that often have a lot of 1-block thick surfaces would be unaffected as well. For example, a 10x1x1 stick ship would only have a shipIntegrityFactor of 0.150; so, other pretty high surface area small ships like drop shuttles would be just fine.

It also works fine for Titans and Battleships with reasonable RP features. Even a 5.4 million block sample titan that is 90x100x800 at 75% density would only have a factor of 0.509

In all, this formula appears to make it such that only ships of obviously exploitative design would be penalised. For the PvP crowd, it still leaves enough wiggle room for reasonable design optimisations such as spaced armor, spaced reactors, bulkheads, and responsibly designed docked plates. For the RP crowd it, leaves plenty of flexibility for interior and exterior decorations as well. And for the die-hard spaghetti folks (if there are any), it forces much more thoughtfulness and optimisation to continue to get any positive effect out of their designs.

All in all I feel that is formula would help make things like the "Fair-and-Balanced" actually live up to its name.
[doublepost=1512412993,1512411390][/doublepost]@OfficalCoding: Care to elaborate what part you disagree with?

[EDIT 1-22-18] In light of the new system released this weekend, this system could ALSO negate the need for bubble shields from a spaghetti perspective. Instead of making a spaghetti ship need to fit inside of the bubble, it would make spaghetti ships simply take more damage to their shields. In the case of the 1x1 spaghetti, a 30 mil cap shield could be broken with 300k damage such that a barrage of normal weapons can still de-shield it despite missing a lot.

 

[NeonSturm]

I like it, but I don't agree that much on the formula.

Just count blocks which have 0123456 exposed faces per group and then give a penalty.
If you really like to show off your systems, you could use glass too.

A group is everything that has a controller + thrusters (but don't punish 1 exposed surface on these).

 

[Nosajimiki]

I like it, but I don't agree that much on the formula.

Just count blocks which have 0123456 exposed faces per group and then give a penalty.
If you really like to show off your systems, you could use glass too.

A group is everything that has a controller + thrusters (but don't punish 1 exposed surface on these).

If you look at the Case Study examples, it does not punish exposed or not exposed systems because is has a hard-floor. A ship with a factor of 0.1 is the same as a ship with a factor of 0.999, they both receive damage as normal. That is what if (shipIntegrityFactor < 1) {shipIntegrityFactor = 1;} does.

At these exact values, it is actually REALLY hard to make a ship that breaks the 1.0 ceiling unless you are trying to do something sketchy; however, it's also an easily manipulated formula if this is not found to be the case. By changing the preFactorModifier, you can adjust what general density at which ships start to be penalized, and by modifying postFactorModifier you can adjust how harsh the penalty is as you increase the spaghettification of a ship. The exact best values would take some real world testing, then some follow up testing 3 months latter as people try to beat the system, but it's a very easy system to tweak until it hits the mark of what actually balances out.

These could even be made server level config settings so that server admins can decide how spaghetti is okay.

 

[Valiant70]

It could work if you only took into account external surface area.

Honestly, I think the problem could be better solved by a moment of inertia-based rotation penalty, calculated per chunk. Calculate each chunk’s mass as a particle in the chunk’s center, and the distance from center of mass. Sum the total moment for all chunks. This will stop spaghetti monsters from turning effectively.

 

[Non]

Okay, so here is some math I came up with that could fix the spaghetti problem with minimal changes to the game engine (and help balance docked armor a bit)

The idea is all about weighing a ship's surface area and size factor against how much structural damage it takes per block destroyed such that spaghetti ships become as brittle or more so than their high density counterparts without punishing the typical complexity of RP built designs or higher surface area of small ships.

So the math:

var shipBlockCount; // ship's block count.
var shipArea; // ship's number of exposed surfaces.
var sizeFactor = (length * width * height)^(1/3);
var hitDamage; // shields/armor/structural HP damage caused by a weapon
var preFactorModifier = 60; // a coefficient of how much integrity each block gives your ship
var postFactorModifier = 1.25; // a coefficient of how harshly the penalty scales once a ship breaks the integrity limit.

var shipIntegrityFactor = (shipArea * sizeFactor / shipBlockCount / preFactorModifier) ^ postFactorModifier;
if (shipIntegrityFactor < 1) {shipIntegrityFactor = 1;}
var shipIntegrity = 1 / shipIntegrityFactor * 100; // use this as % indicator of a ship's integrity.

hitDamage *= shipIntegrityFactor;

To verify the effects of this formula, I ran the following case studies:

Each of the following spaghetti ships are assuming that they are 250k block ships build in a 500 x 500 x 1000 m area .

If the system strands are 1x1 block, the co-efficient of damage = 106.921
If the system strands are 2x2 block, the co-efficient of damage = 25.160
If the system strands are 3x3 block, the co-efficient of damage = 10.801
If the system strands are 4x4 block, the co-efficient of damage = 5.952
If the system strands are 5x5 block, the co-efficient of damage = 3.729

This means that true spaghetti ships will suffer punishing damage from each hit simulating the effect of a weapon digging through 107 system blocks (or several thousand blocks if hit by a missile.) More reasonable low density ships by contrast such as the one with 5x5 block strands will suffer a factor closer to 4:1 meaning a penetrating shot will have the effect of hitting about 19 blocks if hit dead on.

This may still give spaghetti an advantage in some fights, but leave it open to some good hard-counter tactics as well as placing a soft cap on the size of spaghetti ships making unreasonably big ones worthlessly fragile.

The following are also factors regarding docked armor

If someone makes a flate plate that is 1x100x400, the co-efficient of damage = 1.187
If someone makes a similar mass sandwich plate that is 25x50x400, the co-efficient of damage = 3.404

While this does not make docked armor completely unviable, it encourages the use flat plates or smaller, selectively placed plates which cause a lot less lag than their wrapped or sandwich plate counterparts. This also makes docked hull completely nonviable on bigger ships, since it would get overheated after the first few hits anyway.

The following are case studies of various ships that could be defined as normal and minimally-exploitative that show that they would not take any integrity penalty because they all fall under a factor of 1.0

A solid 63x63x63 deathcube of the same aprox. mass as the above spaghetti ships would have a shipIntegrityFactor of 0.100.

An extremely RP happy sample frigate of the same mass that is 25x50x400 with about a 50%
density would have a shipIntegrityFactor of 0.639.

Very small ships that often have a lot of 1-block thick surfaces would be unaffected as well. For example, a 10x1x1 stick ship would only have a shipIntegrityFactor of 0.150; so, other pretty high surface area small ships like drop shuttles would be just fine.

It also works fine for Titans and Battleships with reasonable RP features. Even a 5.4 million block sample titan that is 90x100x800 at 75% density would only have a factor of 0.509

In all, this formula appears to make it such that only ships of obviously exploitative design would be penalised. For the PvP crowd, it still leaves enough wiggle room for reasonable design optimisations such as spaced armor, spaced reactors, bulkheads, and responsibly designed docked plates. For the RP crowd it, leaves plenty of flexibility for interior and exterior decorations as well. And for the die-hard spaghetti folks (if there are any), it forces much more thoughtfulness and optimisation to continue to get any positive effect out of their designs.

All in all I feel that is formula would help make things like the "Fair-and-Balanced" actually live up to its name.

Run this on my 220k range ships that you fought (if this actually ever becomes a thing) and if that ship isn't unreasonable ill agree with you.

 

[Lecic]

With proper balancing this sounds like it would be a really good solution to spaghetti that doesn't damage anything else. Especially if this was combined with something like flak or electrical chaining weapons.

 

[Nosajimiki]

It could work if you only took into account external surface area.

Honestly, I think the problem could be better solved by a moment of inertia-based rotation penalty, calculated per chunk. Calculate each chunk’s mass as a particle in the chunk’s center, and the distance from center of mass. Sum the total moment for all chunks. This will stop spaghetti monsters from turning effectively.

This is already sort of a thing, except when lag happens (as it tends to in a fight) rounding issues allow ships that should rotate slowly to rotate fast. Also, that is not nearly an adequate balance. If you've ever fought a spaghetti ship, they are generally only a fair fight for normal ships 10-30x their mass. The reason being is that no weapon system can effectively damage them.

All a spaghetti would have to do if it could not turn is rely on strafing and turrets, and it would still be a nigh undefeatable beast because most of your weapons fire will outright miss it, and that which does hit will not do more than 100 damage per salvo because you're only destroying 1 block per shot with a turret that, may be designed to destroy 300 blocks per shot. They also don't need any of the defensive systems you see on other ships so they have way more mass to devote to fire power. If you make them brittle, what you are really doing is making them take the damage that they should be taking anyway.

Also, ignoring internal surface area creates 2 problems, one is that you could just make a balloon ship where it is just a hollow 1000x1000x1000 cube of systems thereby still achieving a very spaghetti-like exploit. The other is that it's much more complex to calculate.

Spaghetti requires WAY more surface and space than any legitimate build so there is no need to worry about overlapping what is going on on the inside of your normal RP or PvP ship having the same profile as a ship that is made out of 1-block strands 3000m long 20m apart from each other. Even the spaced systems you find in ships like a MagiTech Man-of-War or one of Nastral's Seraphims would not trigger a factor greater than 1.0. Even if you have a heavily detailed Titan with spaced systems and full RP interior that does break the ceiling by accident, you'd be looking at penalties in the % range which you'd more than make up for with the advantages of having spaced systems, the x100 damage stuff only happens with super min-maxing where you literally have a ship with .1% density or less.

 

[Lancake]

Not entirely sure how you would explain that formula to any player. Most likely you'll only show the integrity factor of a ship which could go up and down while not really explaining why. Simply adding an antenna to your ship, will increase the dimensional factor a lot and ruin your integrity factor. A lot of factors are in play here too, so it's not something you can easily figure out with trial and error. That antenna would be completely fine if it was "inside" the ship's existing shape.

Wanted to try out this density factor out but not sure how the variable ShipArea is determined. Your examples only included the end result, and not the variables you've filled in.

Is ShipArea

• the sum of blocks that have 1 or more faces exposed?
• the sum of how many faces of each block is exposed (maximum 6 per block)?
• the sum of blocks that are exposed to the "vacuum of space"?

Calculating ship area sounds like it would be a major performance issue though since that check would need to apply for every block. Right now, only functional systems belong in a collection to iterate through and even keeping track of their collection sizes when building them is a problem at a million or more blocks.

Here, on top of simple counting the blocks, you would need to do a much more complex check for each one of them. While that is doable at a small enough size, it would definitely slow down to a crawl if the ship is big enough. That and having to include non functional blocks too means even more blocks have to be checked than usual.

 

[Non]

Simply adding an antenna to your ship, will increase the dimensional factor a lot and ruin your integrity factor. A lot of factors are in play here too, so it's not something you can easily figure out with trial and error. That antenna would be completely fine if it was "inside" the ship's existing shape.

Not really.

 

[Nosajimiki]

Not entirely sure how you would explain that formula to any player. Most likely you'll only show the integrity factor of a ship which could go up and down while not really explaining why. Simply adding an antenna to your ship, will increase the dimensional factor a lot and ruin your integrity factor. A lot of factors are in play here too, so it's not something you can easily figure out with trial and error. That antenna would be completely fine if it was "inside" the ship's existing shape.

Wanted to try out this density factor out but not sure how the variable ShipArea is determined. Your examples only included the end result, and not the variables you've filled in.

Is ShipArea

• the sum of blocks that have 1 or more faces exposed?
• the sum of how many faces of each block is exposed (maximum 6 per block)?
• the sum of blocks that are exposed to the "vacuum of space"?

Calculating ship area sounds like it would be a major performance issue though since that check would need to apply for every block. Right now, only functional systems belong in a collection to iterate through and even keeping track of their collection sizes when building them is a problem at a million or more blocks.

Here, on top of simple counting the blocks, you would need to do a much more complex check for each one of them. While that is doable at a small enough size, it would definitely slow down to a crawl if the ship is big enough. That and having to include non functional blocks too means even more blocks have to be checked than usual.

Surface is based on total exposed faces, and only needs to be calculated when editing or rebooting a ship. Much like reactor conduits, I would not imagine it being productive to recalculate it with combat damage. When editing, it should not take a huge load either if you store it as a number that you add/subtract to as a result of just the blocks you've made a changes to.

The player base is used to not understanding the math in this game. Even simple stuff like the diminishing return on shield capacitors (count^.995 if I recall correctly) is probably only known by 5% of players, but everyone learns through trial and error that it is a thing and about what to expect.

The line var shipIntegrity = 1 / shipIntegrityFactor * 100; was intended to show that integrity can easily be visualized as a percent but could also be shown as a damage multiplier. I picture a system where it normally does not show at all, but once you break a factor of 1.0, your system panel will show a warning like "WARNING: Structural integrity is 95%" and if you have tool tips enabled, you could have something that explains that your ship is not dense enough.

In fact, the more I think about it, not explaining what "Structural integrity is 95%" even means or does may be better than making the math well explained because then, players are more likely to have the reaction "Opps, let's not do that" vs if it says, you will take 15% more damage leaving guys like FlyingDebris or Veilith to think, "hmmm, lets see how far I break this before it's no longer worth it."

 

[Lecic]

Not entirely sure how you would explain that formula to any player. Most likely you'll only show the integrity factor of a ship which could go up and down while not really explaining why. Simply adding an antenna to your ship, will increase the dimensional factor a lot and ruin your integrity factor. A lot of factors are in play here too, so it's not something you can easily figure out with trial and error. That antenna would be completely fine if it was "inside" the ship's existing shape.

Wanted to try out this density factor out but not sure how the variable ShipArea is determined. Your examples only included the end result, and not the variables you've filled in.

Is ShipArea

• the sum of blocks that have 1 or more faces exposed?
• the sum of how many faces of each block is exposed (maximum 6 per block)?
• the sum of blocks that are exposed to the "vacuum of space"?

Calculating ship area sounds like it would be a major performance issue though since that check would need to apply for every block. Right now, only functional systems belong in a collection to iterate through and even keeping track of their collection sizes when building them is a problem at a million or more blocks.

Here, on top of simple counting the blocks, you would need to do a much more complex check for each one of them. While that is doable at a small enough size, it would definitely slow down to a crawl if the ship is big enough. That and having to include non functional blocks too means even more blocks have to be checked than usual.

Surely the game already has some way of knowing how many exposed faces there are on a ship when it renders the ship?

 

[Jarraff]

Lancake Lecic makes a great point this math is already being calculated by the game. I had an idea similar to this that would calculate the connectivity of a ship, well more of an inverse but the math is the same really.

Ultimately any number of nerfs could be placed on a ship for having too many exposed block faces for a given number of blocks. The OP gives a number of great examples.

Explaining this to a player could be challenging but there are a number of seemingly black box calculations in Starmade: thrust, jump drive charge, number of blocks needed for defensive effects, scanner charge. I know that there are mathematical formulas posted on the wiki for all of these but to a new player they are not all together intuitive.

 

[Lancake]

Surely the game already has some way of knowing how many exposed faces there are on a ship when it renders the ship?

That's code called for rendering and I doubt it cares about how many exposed faces there are per entity. It cares about chunks to draw, with all the baked info it comes with, and it cares about the model and view matrix of where to put it on the screen. Plenty of other things it cares about, but no expert on OpenGL voxel sandbox rendering.

If you want to use information per entity, you calculate and manage it per entity. It's not a complicated thing to do, but it definitely takes more processing time and can be a problem depending on what you exactly want to do.

Surface is based on total exposed faces, and only needs to be calculated when editing or rebooting a ship. Much like reactor conduits, I would not imagine it being productive to recalculate it with combat damage. When editing, it should not take a huge load either if you store it as a number that you add/subtract to as a result of just the blocks you've made a changes to.

The player base is used to not understanding the math in this game. Even simple stuff like the diminishing return on shield capacitors (count^.995 if I recall correctly) is probably only known by 5% of players, but everyone learns through trial and error that it is a thing and about what to expect.

The line var shipIntegrity = 1 / shipIntegrityFactor * 100; was intended to show that integrity can easily be visualized as a percent but could also be shown as a damage multiplier. I picture a system where it normally does not show at all, but once you break a factor of 1.0, your system panel will show a warning like "WARNING: Structural integrity is 95%" and if you have tool tips enabled, you could have something that explains that your ship is not dense enough.

In fact, the more I think about it, not explaining what "Structural integrity is 95%" even means or does may be better than making the math well explained because then, players are more likely to have the reaction "Opps, let's not do that" vs if it says, you will take 15% more damage leaving guys like FlyingDebris or Veilith to think, "hmmm, lets see how far I break this before it's no longer worth it."

This integrity value is information that needs to be verified on the server. It can be stored but it would be pointless as that is something you could easily edit and exploit to your benefit if the server did request a recalculation on loading the entity. It's not that much of a problem considering you only want the exposed faces, and don't care if it's vacuum or not. Could still be a major issue for structures that exceed a million blocks.

And you're right, a majority of the player base most likely does not know even half of the math going on in the game. That's often fine as long as it's behaving in a predictable way. Even so, in power 2.0 we made sure to reduce the amount of guessing as the more complicated formulas can be consolidated into a few core systems instead of having it all over the place.

As for this integrity value, it's something that is influenced by 3 varying factors.

1. Dimensions of your structure: Boxy ships will benefit the most out of that. It will also be quite awkward for planet plates, as the plate itself is your minimum dimensions. Stations themselves, will also be quite fragile as their size is usually quite big to accommodate for docked structures. The first power 2.0 prototype was based on this, and people brought it up multiple times, pointing out that would constantly result in changing values which is a huge problem in predictability. It was indeed something that changed constantly while making and fine tuning a ship and was discarded as a method for scaling a mechanic's strength. The same issue applies here.
   
   
2. Block count: planets and any structure that can have a varying amount of docks, will suffer from a constantly changing block count and a changing integrity factor. Not including docks in this equation opens up for exploits so can't really do that.
   
   
3. Sum of exposed faces, this is one of the better ideas yet its complexity depends highly on how you use this value to determine buffs/debuffs. We've been experimenting with shapes and sizes to see how much of a difference each makes for a collection's touching side value instead of exposed ones. It's the same principle and we've seen in our dev builds that it definitely has potential to discourage the making of abnormal ships such as the spaghetti ones.
   
   Of course, that value needs to apply a debuff in one way or another, and its strength needs to depend on something too or it won't scale well. It needs to make sense for a player, it needs to be simple enough to figure out in the first 10 seconds yet offer complexity for people to optimize if they so desire. I think your complete suggestion is just a bit too much to ask for an average player to understand.
   
   

 

[Benevolent27]

Just as a side note, I wish there was some command that allowed me to get the dimensions of a ship with my wrapper, so then I could calculate the density of the ship. As it stands, I have to use the chunk dimensions, which is wildly inaccurate, and results in density calculations that are unusable by my wrapper. It only has any sort of relevance for very large ships, where the chunk inaccuracies are minimized.

I don't think ship density or surface area should have anything to do with built-in game mechanics though. It would debuff ships in very unrealistic and very complicated ways. However, I think some kind of structural integrity system could be put into place. Like breakoff (if possible) or simply detecting when parts of a ship become disconnected from other blocks and THEN providing a debuff of some kind (to the degree the ship has non-connected blocks). We don't want to give giant debuffs to decorated ships simply because they have more block facings, compared to a big cube.

Though I still think the solution is to offer multiple power reactor types and then require power reactors be connected to the systems they provide power to. (Could be connected to a rail as well to transfer power across docked entities) In the case of spaghetti ships, the power reactors would have certain rules on efficiency that would prevent them from being shaped like big long lines (or if they were made in big long lines, then they would be horribly inefficient). So then you have discrete power generator systems that can be taken out specifically to disable the ship. Or a spaghetti ship that is terribly costly to build and wildly inefficient, but which has great block damage avoidance. Then if some kind of structural integrity debuff took effect for non-connected blocks, it would definitely no longer be worth making spaghetti ships. They would have very low structural integrity values to begin with, and even if someone were to connect all the individual lines of things, any sort of block damage would rapidly decrease the structural integrity of the ship, causing massive debuffs.

Note that a structural integrity system would need to be balanced so as to not unduly punish more decorated ships, which might have small portions of the ship become disconnected more easily. It should be aimed at debuffing HIGHLY DISCONNECTED ships.

 

[FlyingDebris]

unfinished ship hulls would need to be taken into consideration when dealing with spaghetti via a breakoff option

 

[Dire Venom]

I personaly don't see how this will change much, as Spag just avoid damage by not getting, with overpen being an additional benifit.
Could someone please fill me in:?

 

[Zoolimar]

I feel like this suggestion is like putting a bandaid on a festering wound. It may even work, but it should not be needed. Instead it would be better to deal with problems at a more basic level which this suggestions tries to correct.

 

[Nosajimiki]

I personally don't see how this will change much, as Spag just avoid damage by not getting, with overpen being an additional benefit.
Could someone please fill me in:?

Spaghetti ships minimize damage by reducing the number of blocks you can hit with a single shot. When you hit a spaghetti ship, high yield missiles designed to inflict upwards of 1 million structural damage by destroying tens of thousands of blocks might only catch 40-50 blocks in the explosion radius, and a turret that is designed to fire a salvo of beams or cannons to dig through hundreds of system blocks might literally only hit 1. Since structural damage is tied to blocks destroyed, this means that an unarmored, unshielded, spaghetti ship may easily take over 100x as much firepower to kill as pretty much any ship that is built following a logically normal continuous structure. This formula is designed to multiply the structural damage per block such that a spaghetti ship is would be roughly as easy to overheat as a solid ship in the same weight class by reducing the number of blocks you need to destroy to overheat it.

So for example: If you a 250k block ship would on average require destroying 100k blocks to overheat, this system would modify a super spaghetti ship such that it would only take destroying about 1k of the same blocks. This is not actually a nerf that punishes low density ships as some people have expressed concern over, just a formula for making low density perform more like high density ships so that players can have more creative choice.
[doublepost=1512500126,1512498710][/doublepost]

As for this integrity value, it's something that is influenced by 3 varying factors.

1. Dimensions of your structure: Boxy ships will benefit the most out of that. It will also be quite awkward for planet plates, as the plate itself is your minimum dimensions. Stations themselves, will also be quite fragile as their size is usually quite big to accommodate for docked structures. The first power 2.0 prototype was based on this, and people brought it up multiple times, pointing out that would constantly result in changing values which is a huge problem in predictability. It was indeed something that changed constantly while making and fine tuning a ship and was discarded as a method for scaling a mechanic's strength. The same issue applies here.
   
   
2. Block count: planets and any structure that can have a varying amount of docks, will suffer from a constantly changing block count and a changing integrity factor. Not including docks in this equation opens up for exploits so can't really do that.
   
   
3. Sum of exposed faces, this is one of the better ideas yet its complexity depends highly on how you use this value to determine buffs/debuffs. We've been experimenting with shapes and sizes to see how much of a difference each makes for a collection's touching side value instead of exposed ones. It's the same principle and we've seen in our dev builds that it definitely has potential to discourage the making of abnormal ships such as the spaghetti ones.
   
   Of course, that value needs to apply a debuff in one way or another, and its strength needs to depend on something too or it won't scale well. It needs to make sense for a player, it needs to be simple enough to figure out in the first 10 seconds yet offer complexity for people to optimize if they so desire. I think your complete suggestion is just a bit too much to ask for an average player to understand.
   

1. I agree that space stations tend to be very big, but the equation has a strong logarithmic falloff on larger entities. While it is possible stations might be affected, I suspect that most also have large blocks of factories, reactors, etc that would add enough covered faces to offset the size. Also, most "docking bases" have home base protection anyway, so their integrity would be a moot point.

2. Docking can be very quickly calculated. Each entity would already have it's surfaces and block count stored. You'd just need to add those values up, then take the dimensions of the new merged entity to rerun the math. This is literally no more extra processing than firing a single beam tic.

3. I think the part the keeps getting overlooked is that this mechanic would rarely even come into play. If you throw a new user in front of this game, their first instinct has been in 100% of cases I've seen to make something that looks like a ship. If the values are set right, then even highly detailed ships won't begin to approach this value. Instead you'll only see it when a more advanced player realizes, there is an exploitable mechanic. The idea is that a confusing mechanic you don't see until you've played for 6+ months is a lot less off-putting than one you encounter on day 1.

The only other solution I've seen that even begins to approach this issue is to go back to making weapons always cause their maximum structural damage on a hit regardless of blocks destroyed, but I personally found that to feel pretty flat and boring compared to the more complex weapon systems we see today.

Also benevolent's break-off mechanic idea while, interesting, does not solve the issue because you'd just need to make you ship into a grid pattern and you'd have all the redundancy you need to never lose a meaningful chunk. If anything it would nerf solid built ships because you often see tons of blocks get disconnected when a smaller area is penetrated by continuous direct fire weapons.

 

[Valiant70]

Here's a fairly simple solution that might help quite a bit:

For each system block, check the number of empty spaces around it. Apply a durability debuff to the ship based on that. Spaghetti ships would have to start encasing their strands in hull or something, which would make them very heavy. If they didn't do so, cluster missiles would be effective because (if it's balanced correctly) each missile would do just as much (or more) damage to the spaghetti ship as it would to a normal ship.

As a side effect, this would encourage decoration of exposed systems, and make such decoration advantageous rather than dead weight. If you want the blocks visible, use glass or use sideways slabs to make a finned "heat sink" look. (Remember, I said "emtpy" space! Slabs don't count as empty.) There's no reason you would have to decorate anything of course. A simple bulkhead would work just as well and might still be a little lighter.
[doublepost=1512501836,1512501692][/doublepost]

So for example: If you a 250k block ship would on average require destroying 100k blocks to overheat, this system would modify a super spaghetti ship such that it would only take destroying about 1k of the same blocks. This is not actually a nerf that punishes low density ships as some people have expressed concern over, just a formula for making low density perform more like high density ships so that players can have more creative choice.

This is precisely what my idea should accomplish.
[doublepost=1512502294][/doublepost]

The only other solution I've seen that even begins to approach this issue is to go back to making weapons always cause their maximum structural damage on a hit regardless of blocks destroyed, but I personally found that to feel pretty flat and boring compared to the more complex weapon systems we see today.

Adding an effect to beams and cannons that "spreads out" over the surface on impact would be a nice addition. (It would likely be imbalanced if allowed on missiles, though.) Rather than punching through, the damage is spread along the surface it hits. This would also make high-alpha beams or cannons effective at opening large holes in armor. This opens an opportunity for smaller craft to swoop in at close range and fire munitions through the holes, hopefully giving fighter-bombers an actual role in the game other than swarm attacks.

 

[Nosajimiki]

Here's a fairly simple solution that might help quite a bit:

For each system block, check the number of empty spaces around it. Apply a durability debuff to the ship based on that. Spaghetti ships would have to start encasing their strands in hull or something, which would make them very heavy. If they didn't do so, cluster missiles would be effective because (if it's balanced correctly) each missile would do just as much (or more) damage to the spaghetti ship as it would to a normal ship.

As a side effect, this would encourage decoration of exposed systems, and make such decoration advantageous rather than dead weight. If you want the blocks visible, use glass or use sideways slabs to make a finned "heat sink" look. (Remember, I said "emtpy" space! Slabs don't count as empty.) There's no reason you would have to decorate anything of course. A simple bulkhead would work just as well and might still be a little lighter.
[doublepost=1512501836,1512501692][/doublepost]

This is precisely what my idea should accomplish.
[doublepost=1512502294][/doublepost]

Adding an effect to beams and cannons that "spreads out" over the surface on impact would be a nice addition. (It would likely be imbalanced if allowed on missiles, though.) Rather than punching through, the damage is spread along the surface it hits. This would also make high-alpha beams or cannons effective at opening large holes in armor. This opens an opportunity for smaller craft to swoop in at close range and fire munitions through the holes, hopefully giving fighter-bombers an actual role in the game other than swarm attacks.

System exposure would create a step in the right direction, but not offer nearly enough of a disadvantage to equalize the playing field. All I would have to do is surround my systems in lightweight obliterates such as capsules, motherboards, etc. which would only add about 40% mass to the ship. While this might make a 25k speg into a 50k (with needed additional thrust), you're still looking at at something that can kill most ships in the 300-600k range just fine.

Also, spreading is a much more complex calculation than radius or punch-through. To illustrate, imagine setting your fill tool to try to fill 3.6 million blocks with a single click. That is about how long a single salvo from a despoiler class battleship would take to compute with spreading.