- Joined
- Aug 17, 2014
- Messages
- 34
- Reaction score
- 11
I apologize in advance for such a wall of text, but here it comes.
One of the biggest problems in Starmade as i see it is that there is no clear reason why not to make death cubes (or spheres, if you know about build helper). They have the best possible ratio of thickness of hull to number of blocks needed for that hull. All other stats of such ships are pretty much equal to those of other ships.
Why is that? I suggest looking on real world's armored structures, and remember, that what actually matters is not the thickness of armor, but the effective thickness, which is determined, inter alia, by the angle between the normal and the momentum vector of the projectile.
"But akimzav, aren't theese parts already simulated by the fact that the projectile must first destroy a certain amount of blocks before it fully penetrates the hull? Isn't it equivalent to what you are trying to say here?" you can ask. No, it isn't, and this is why:
A: (for AP projectiles)
C: (for structures in general)
D*: (for Astrotech beam)
// those parts marked with a '*' are somewhat offtopic, and can be (more or less) safely excluded from this suggestion.
What are the benefits of such a system? Well, it clearly is more physical than what we have now, and also it gives more variables for ship engineer to consider while working on a blueprint. It sounds stupid, i know, but i think theese are the things that can put more fun into both designing and battling parts of Starmade.
So, what do you think?
One of the biggest problems in Starmade as i see it is that there is no clear reason why not to make death cubes (or spheres, if you know about build helper). They have the best possible ratio of thickness of hull to number of blocks needed for that hull. All other stats of such ships are pretty much equal to those of other ships.
Why is that? I suggest looking on real world's armored structures, and remember, that what actually matters is not the thickness of armor, but the effective thickness, which is determined, inter alia, by the angle between the normal and the momentum vector of the projectile.
"But akimzav, aren't theese parts already simulated by the fact that the projectile must first destroy a certain amount of blocks before it fully penetrates the hull? Isn't it equivalent to what you are trying to say here?" you can ask. No, it isn't, and this is why:
- IRL, there are certain cases where a projectile can not penetrate armor at all. (Example: tank plating versus a SMG. The latter here has no armor-piercing properties, and the momentum of its shots it too low to create sufficient stress in armor plating to ever bring it from the zone of elastic deformations to the zone of plastic deformations.)
- The size (area of transverse section) of a projectile is much smaller than the same parameter of a block it hits. As of now, if a projectile successfuly penetrates the armor, it leaves a large (in comparison to its own size) tunnel behind, allowing the second projectile to traverse the armor without any interaction. This, however, is not physicaly realistic at all, as the probability of such a scenario should be dependent on the ratio of two areas, one being the area of the transverce section of the projectile and the other being the area of a surface of the block. This probability seems to be small for Starmade's typical sizes.
A: (for AP projectiles)
- Upon collision of armor-penetrating projectile (beam and AMC shots) count the armor (hull) blocks that stand in possible penetration trajectory. (The blocks don't have to be uniform; we can (and should) count them considering weights (for example: hull being 0,5; stand. armor being 0,7; adv. armor being 1). Also, the weight has to scale with block's health (but not necessarily linearly).(later it will be clear, why)) Let's name this number 'n'.
- If total number is less than the "penetrating property" (let's name it 'p') of a projectile (of course theese numbers are affected by corresponding active effects!), then the projectile is considered to be stopped by armor: there is damage dealt to the blocks involved, but i suggest it to be much smaller than initial damage contained in that shot. (example: multiply initial damage by a small factor (~10^-4, for instance) and apply this damage to those blocks, the presence of which would be enough to stop the projectile, distributing the damage (maybe evenly, maybe not) between them) Also, there might be a threshold (like if p<2*n and 'shot damage'<2*'total involved plating effective hp' (where total involved plating effective hp is a sum of each in-line of fire block multiplied by it's armoring factor)) when all damage is considered to be dispersed, and no damage is dealed.
If total number is more than said parameter, then the projectile is considered to succesfuly traverse the plating. It still deals said small damage to armor blocks it passed, but also it continues to travel past the armor, however, only keeping 1-p/n part (or, i don't know, exp(-1/(p/n-1)) ) of its initial damage.
No changes, exept now we shall also scale armoring of each block with it's remaining hp.
C: (for structures in general)
1. Remove the "ArmorHP". Yes, i said it. The explanation is simple: why would we need it, if all what it is supposed to do (decrease the armor after some hits) is already built-in our brand new system! (see A:1). As a bonus, we get the localisation of said ArmorHP, making more tactics possible, and, more importantly, increasing physical realism.
2*. Make ShipHP only determine if the ship starts overheating.
3*. Now, we already have implicit grouping of blocks into systems (may be seen on Entity Structure screen). What i am proposing here is to make each such group have it's HP, meaning that if that particular system takes damage, it, and nothing more, will break.
2*. Make ShipHP only determine if the ship starts overheating.
3*. Now, we already have implicit grouping of blocks into systems (may be seen on Entity Structure screen). What i am proposing here is to make each such group have it's HP, meaning that if that particular system takes damage, it, and nothing more, will break.
D*: (for Astrotech beam)
- Add penetrating properties to the beam based on lenth of group of astrotech beam blocks, so it can heal deep blocks.
- Change it (if it's not already like this) so an entity1 docked to entity2 can use astrotech on entity3, which is docked to entity2, if entity3 is not currently involved in combat. (think auto-repairing docks for fighters).
// those parts marked with a '*' are somewhat offtopic, and can be (more or less) safely excluded from this suggestion.
What are the benefits of such a system? Well, it clearly is more physical than what we have now, and also it gives more variables for ship engineer to consider while working on a blueprint. It sounds stupid, i know, but i think theese are the things that can put more fun into both designing and battling parts of Starmade.
So, what do you think?
Last edited:
