- Joined
- Jun 23, 2013
- Messages
- 504
- Reaction score
- 127
Well, here's yet another post regarding overall mechanics. Everyone seems to want a say in the matter of combat mechanics nowadays, so I thought I'd have mine. I'm trying to avoid introductions, so I'll just skip to the things I think need doing.
Making hull relevant
It's widely agreed that among the issues of this game, the utter uselessness of hull is one of the worst. Was it not for the aesthetic function, it would be worth neither the price nor the mass. To clarify my side in this, I don't think it should be able to sustain a larger ship for very long without shields, but neither should it's usefulness be limited to that scenario. As such, more tweaking than turning up it's Hp knob will be required for a desirable effect.
Firstly, shields would need to leak damage to motivate the use of a secondary line of defence. How large a fraction of absorbed damage that is leaked should of course be inversely proportional to the remaining shield percentage, starting at negligible levels but never exceeding a few hundreds until shields are fully depleted. It's important that absolute quantity of shield power has no leakage reducing effect in itself, as it would reduce the need for hull to increase in thickness along with the size of the ship it's protecting.
Secondly, hull would need to absorb damage differently. Enough firepower at a single area, even through shields and armor, should have small but not entirely negligible effect on whatever system is behind. Exactly how, I'm not sure. I've been thinking of a new kind of damage that doesn't destroy blocks, but does reduce their efficiency if they're system components, such as generators or shields. Whatever way this is implemented, a good hull should be important for reducing this effect, and the more damage it's taken, the more should get through. Exposed components should be rather vulnerable, and a hull breach should be a really, really bad thing. The game should probably make an exception for things that should be exposed, such as cannon openings and thruster exhausts, but I've got no idea how to define a mathematical criteria for that.
In any case, the above will hopefully give players a reason to actually use hull, and in multiple layers once their ships start to get larger. Hull hp should still be drastically increased, and even without shields, a capital's hull should be able to hold off a few seconds of focused fire from an equally formidable ship.
Come to think of it, this would also open for a new kind of distinction between explosive and non-explosive weaponry. While the latter should be good against shields, explosives should leak through to a larger extent, making them better for dealing direct damage while shields are still up.
Separating Capitals from fighters
Another core issue is that all ships are basically just glorified fighters. Kilometer-long, carrying smaller ones in hangars and with turrets strapped to the hull, sure, but the core mechanic is the same. I for one have seen too many capitals face off against each other in dogfights.
Considering how broad this issue is, I should probably try to break it down.
The interface is currently based in the same gui for all ships, with Wasd controls from an Fps view. A defining characteristic of capitals is that they have some form of command structure, even if it's only a captain giving orders to a computer that does the rest. Not a single person aiming the main weapons and piloting everything.
I'd say there's no single perfect capital interface. As long as it provides a 3'rd person overview of any situation or battle, autopiloting based on instructions (“Go to X,Y,Z”, or “park within a hundred meters of X ship”), and can accept commands regarding priorities (“Focus all left hangar turrets on ships within a hundred meters, prioritize by smallest size”) and actions (“Undock all shuttlepods in category C”), the needs will inevitably vary from ship to ship and player to player.
While I personally believe this should be a programmable aspect of ships, Schema could probably pull of a sufficiently large overhaul. Whatever way this is done, it should include something allowing players to control their ships without actually entering a block. Projecting a hud to the player's screen is quite acceptable, but in the end, they should be allowed the feeling of being physically present on their ship's bridge.
Maneuvering is rather ridiculous at the time. The way thrusters directly translate into thrust, combined with the dogfighter interface, means that any capability of maneuvering that's possible for a fighter, is equally feasible for a capital. Again, the game fails to set apart the two kinds of ships on a very important point. When fighters dodge shots, capitals chew them up, then some more, then return the favor.
The solution to this has already been implemented for shields, if possibly somewhat less drastically. I can't type the algorithm of the top of my head, but if I'm not mistaken, it made their efficiency in smaller scales inversely proportional to their quantity.
While this algorithm is indeed a powerful tool, there's also the question of where to use it. If applied in the current formula before mass is taken into account, it would essentially just nerf larger thruster arrays and and discourage their use.
However, if it was used in the conversion of thrust/mass ratio to actual acceleration, and a multiplier inversely proportional to the mass of the ship was added, the effect would be somewhat more complex. I'd make a graph, but I'm still trying to figure out the necessary tools.
Basically, for every quantity of mass, there would be an optimal capability of acceleration, and attempting to achieve anything larger would be at too high a cost of other capabilities. This would probably reduce the issue far more efficiently, but it would be very restrictive on ship building. This “optimal capability” would essentially be a hard cap on how agile a ship of a certain size can get, which while good for balancing, goes against the idea of a sandbox game. Not sure myself what would be the better choice.
Whatever solution is chosen, a new issue will arise. While capitals should indeed be less agile, when going from point A to point B, they should be faster. The current speed system does not make a distinction between these properties, as one's ability to accelerate is equal to one's ability to overcome air resistance, which is for some reason present in Starmade space. I don't really see this being solved without a major overhaul, such as the introduction of hyperspeed travel, which I'm not going to get into at the moment.
Force Projection would be greatly impaired by the above changes, rendering the current everyday fixed forward cannons mostly useless. I wouldn't say that's a bad thing, that's not how capitals should work, but it does leave them with only turrets and fighters to distribute the poundings they're supposed to deliver. And, well, a quick look at the game will suffice to tell you this is currently not within their range of capabilities. The apparent solution would be to allow them to function more like extensions of their mothership, but exactly how can be discussed.
As for turrets, the obvious first steps are allowing ships to extend their shields and channel their firepower through them. Currently, this would eliminate the game's only element of aiming for vulnerable components, but I believe I just dedicated a section to taking care of that. Channeling firepower should have a significant penalty on the turning speed of whatever turret is doing it, to ensure it's not used against fighters and other craft relying on agility. Also, these turrets should be granted a near-immunity to damage leaks, or at least be assisted by their capital in absorbing them, as large amounts of hull aren't very feasible for such small things.
Fighters are a more complex issue. There's a lot of debate as to how powerful they should actually be, and I won't even try to please every side in this argument. Personally, I believe that fighters shouldn't play in the same league as capitals except in large swarms, but pose more of a threat when backed by a carrier of their own.
There are countless ways such backing could work, but a few concepts need to be put on the table.
Firstly, fighters should be able to act as bombers. As in, not just having a moderate missile array, but actually carrying and delivering capital-sized explosives from their carrier. A delivery system like this would have no need for tracking, and be able to reach areas without a direct line of sight, hopefully making it a viable alternative to regular missiles.
Then, there's partial sensor jamming, point defence and a few other things capitals could do for their agile minions, but those are fairly self-explanatory, and I'm trying to avoid details.
More general support, such as the remote boosting of fighters' shields and weapons, is not out of the question. However, that would introduce an entirely new field of balancing that may or may not be worth it.
It's worth noting that little of the above would work without a major enhancement of the current Ai and interface elements. Things such as making sure firepower is only channeled through turrets with a line of sight to the target, having fighters re-dock to load new explosives and aiming for specific areas of ships are not currently among the capabilities of automated systems. Again, I think this is the kind of thing we should be allowed to program ourselves, but also again, schema could probably create something that works decently and universally.
Overall quirking
The above changes would hopefully reduce the conceptual issues of combat, but a set of more specific issues would remain. While perhaps equally significant, they'll hopefully all fit in a single section of text. Most notably, two things need eliminating:
Scattercannons. We've all seen them, and hopefully, few have enjoyed the sight. Usually dozens, sometimes hundreds of arrays, spitting out projectiles in ridiculous quantities, and somehow obliterating all that gets in the way.
I'm not certain as to how this will be affected by the upcoming weapons overhaul, but having no grounds for speculation, I'll assume things don't get better.
Getting rid of this will probably require a combination of nerfing them and buffing the alternatives.
Buffing the alternatives should be rather easy, with changes such as excess damage upon the destruction of a block being forwarded to adjacent ones, a partially exponential increase in firepower when adding new blocks to an existing array, and an accelerating AM production rate that resets upon firing.
Nerfing the scattercannons themselves is somewhat trickier, as it should not be allowed affect small cannons in general, only clusters of them. Possibly, hits could induce a slight damage reduction in nearby blocks against shots from the same ship, preferably one that stacks exponentially in both potency and persistency.
This would encourage slow rates of fire as well as keeping your firepower in as few arrays as possible. The effects of the damage reduction should not be noticeable until there are at least half a dozen cannons firing, perhaps more for larger ships, as they can only get that massive before a larger number of main cannons becomes a necessity.
Core drilling. An unfortunate element of combat. You take down your enemy's shields, and a decent salvo to their ship's centre will eliminate them. This is another issue that would probably be reduced by the changes in the hull section, but in the end, the concept remains.
This is probably among the most difficult things to fix, as the core and it's function is a very fundamental mechanic, both gameplay- and code-wise. Still, I really don't see this being solved without the core being wholly redefined, so that's what I'll have to suggest.
Firstly, it would have to be a removable block. Or at least, destructible without taking the entire ship with it, or the delay imposed by the current self-destruct mechanic. It's function as the centre of the ship would have to be taken over by the actual mass centre, but the ship could remain dependant on it's presence to operate. In light of the damage mechanic changes, this might not keep going for the core as the best option for crippling a ship, as a few unshielded hits to an exposed main generator could be equally effective.
As usual, sorry for taking your time.
Making hull relevant
It's widely agreed that among the issues of this game, the utter uselessness of hull is one of the worst. Was it not for the aesthetic function, it would be worth neither the price nor the mass. To clarify my side in this, I don't think it should be able to sustain a larger ship for very long without shields, but neither should it's usefulness be limited to that scenario. As such, more tweaking than turning up it's Hp knob will be required for a desirable effect.
Firstly, shields would need to leak damage to motivate the use of a secondary line of defence. How large a fraction of absorbed damage that is leaked should of course be inversely proportional to the remaining shield percentage, starting at negligible levels but never exceeding a few hundreds until shields are fully depleted. It's important that absolute quantity of shield power has no leakage reducing effect in itself, as it would reduce the need for hull to increase in thickness along with the size of the ship it's protecting.
Secondly, hull would need to absorb damage differently. Enough firepower at a single area, even through shields and armor, should have small but not entirely negligible effect on whatever system is behind. Exactly how, I'm not sure. I've been thinking of a new kind of damage that doesn't destroy blocks, but does reduce their efficiency if they're system components, such as generators or shields. Whatever way this is implemented, a good hull should be important for reducing this effect, and the more damage it's taken, the more should get through. Exposed components should be rather vulnerable, and a hull breach should be a really, really bad thing. The game should probably make an exception for things that should be exposed, such as cannon openings and thruster exhausts, but I've got no idea how to define a mathematical criteria for that.
In any case, the above will hopefully give players a reason to actually use hull, and in multiple layers once their ships start to get larger. Hull hp should still be drastically increased, and even without shields, a capital's hull should be able to hold off a few seconds of focused fire from an equally formidable ship.
Come to think of it, this would also open for a new kind of distinction between explosive and non-explosive weaponry. While the latter should be good against shields, explosives should leak through to a larger extent, making them better for dealing direct damage while shields are still up.
Separating Capitals from fighters
Another core issue is that all ships are basically just glorified fighters. Kilometer-long, carrying smaller ones in hangars and with turrets strapped to the hull, sure, but the core mechanic is the same. I for one have seen too many capitals face off against each other in dogfights.
Considering how broad this issue is, I should probably try to break it down.
The interface is currently based in the same gui for all ships, with Wasd controls from an Fps view. A defining characteristic of capitals is that they have some form of command structure, even if it's only a captain giving orders to a computer that does the rest. Not a single person aiming the main weapons and piloting everything.
I'd say there's no single perfect capital interface. As long as it provides a 3'rd person overview of any situation or battle, autopiloting based on instructions (“Go to X,Y,Z”, or “park within a hundred meters of X ship”), and can accept commands regarding priorities (“Focus all left hangar turrets on ships within a hundred meters, prioritize by smallest size”) and actions (“Undock all shuttlepods in category C”), the needs will inevitably vary from ship to ship and player to player.
While I personally believe this should be a programmable aspect of ships, Schema could probably pull of a sufficiently large overhaul. Whatever way this is done, it should include something allowing players to control their ships without actually entering a block. Projecting a hud to the player's screen is quite acceptable, but in the end, they should be allowed the feeling of being physically present on their ship's bridge.
Maneuvering is rather ridiculous at the time. The way thrusters directly translate into thrust, combined with the dogfighter interface, means that any capability of maneuvering that's possible for a fighter, is equally feasible for a capital. Again, the game fails to set apart the two kinds of ships on a very important point. When fighters dodge shots, capitals chew them up, then some more, then return the favor.
The solution to this has already been implemented for shields, if possibly somewhat less drastically. I can't type the algorithm of the top of my head, but if I'm not mistaken, it made their efficiency in smaller scales inversely proportional to their quantity.
While this algorithm is indeed a powerful tool, there's also the question of where to use it. If applied in the current formula before mass is taken into account, it would essentially just nerf larger thruster arrays and and discourage their use.
However, if it was used in the conversion of thrust/mass ratio to actual acceleration, and a multiplier inversely proportional to the mass of the ship was added, the effect would be somewhat more complex. I'd make a graph, but I'm still trying to figure out the necessary tools.
Basically, for every quantity of mass, there would be an optimal capability of acceleration, and attempting to achieve anything larger would be at too high a cost of other capabilities. This would probably reduce the issue far more efficiently, but it would be very restrictive on ship building. This “optimal capability” would essentially be a hard cap on how agile a ship of a certain size can get, which while good for balancing, goes against the idea of a sandbox game. Not sure myself what would be the better choice.
Whatever solution is chosen, a new issue will arise. While capitals should indeed be less agile, when going from point A to point B, they should be faster. The current speed system does not make a distinction between these properties, as one's ability to accelerate is equal to one's ability to overcome air resistance, which is for some reason present in Starmade space. I don't really see this being solved without a major overhaul, such as the introduction of hyperspeed travel, which I'm not going to get into at the moment.
Force Projection would be greatly impaired by the above changes, rendering the current everyday fixed forward cannons mostly useless. I wouldn't say that's a bad thing, that's not how capitals should work, but it does leave them with only turrets and fighters to distribute the poundings they're supposed to deliver. And, well, a quick look at the game will suffice to tell you this is currently not within their range of capabilities. The apparent solution would be to allow them to function more like extensions of their mothership, but exactly how can be discussed.
As for turrets, the obvious first steps are allowing ships to extend their shields and channel their firepower through them. Currently, this would eliminate the game's only element of aiming for vulnerable components, but I believe I just dedicated a section to taking care of that. Channeling firepower should have a significant penalty on the turning speed of whatever turret is doing it, to ensure it's not used against fighters and other craft relying on agility. Also, these turrets should be granted a near-immunity to damage leaks, or at least be assisted by their capital in absorbing them, as large amounts of hull aren't very feasible for such small things.
Fighters are a more complex issue. There's a lot of debate as to how powerful they should actually be, and I won't even try to please every side in this argument. Personally, I believe that fighters shouldn't play in the same league as capitals except in large swarms, but pose more of a threat when backed by a carrier of their own.
There are countless ways such backing could work, but a few concepts need to be put on the table.
Firstly, fighters should be able to act as bombers. As in, not just having a moderate missile array, but actually carrying and delivering capital-sized explosives from their carrier. A delivery system like this would have no need for tracking, and be able to reach areas without a direct line of sight, hopefully making it a viable alternative to regular missiles.
Then, there's partial sensor jamming, point defence and a few other things capitals could do for their agile minions, but those are fairly self-explanatory, and I'm trying to avoid details.
More general support, such as the remote boosting of fighters' shields and weapons, is not out of the question. However, that would introduce an entirely new field of balancing that may or may not be worth it.
It's worth noting that little of the above would work without a major enhancement of the current Ai and interface elements. Things such as making sure firepower is only channeled through turrets with a line of sight to the target, having fighters re-dock to load new explosives and aiming for specific areas of ships are not currently among the capabilities of automated systems. Again, I think this is the kind of thing we should be allowed to program ourselves, but also again, schema could probably create something that works decently and universally.
Overall quirking
The above changes would hopefully reduce the conceptual issues of combat, but a set of more specific issues would remain. While perhaps equally significant, they'll hopefully all fit in a single section of text. Most notably, two things need eliminating:
Scattercannons. We've all seen them, and hopefully, few have enjoyed the sight. Usually dozens, sometimes hundreds of arrays, spitting out projectiles in ridiculous quantities, and somehow obliterating all that gets in the way.
I'm not certain as to how this will be affected by the upcoming weapons overhaul, but having no grounds for speculation, I'll assume things don't get better.
Getting rid of this will probably require a combination of nerfing them and buffing the alternatives.
Buffing the alternatives should be rather easy, with changes such as excess damage upon the destruction of a block being forwarded to adjacent ones, a partially exponential increase in firepower when adding new blocks to an existing array, and an accelerating AM production rate that resets upon firing.
Nerfing the scattercannons themselves is somewhat trickier, as it should not be allowed affect small cannons in general, only clusters of them. Possibly, hits could induce a slight damage reduction in nearby blocks against shots from the same ship, preferably one that stacks exponentially in both potency and persistency.
This would encourage slow rates of fire as well as keeping your firepower in as few arrays as possible. The effects of the damage reduction should not be noticeable until there are at least half a dozen cannons firing, perhaps more for larger ships, as they can only get that massive before a larger number of main cannons becomes a necessity.
Core drilling. An unfortunate element of combat. You take down your enemy's shields, and a decent salvo to their ship's centre will eliminate them. This is another issue that would probably be reduced by the changes in the hull section, but in the end, the concept remains.
This is probably among the most difficult things to fix, as the core and it's function is a very fundamental mechanic, both gameplay- and code-wise. Still, I really don't see this being solved without the core being wholly redefined, so that's what I'll have to suggest.
Firstly, it would have to be a removable block. Or at least, destructible without taking the entire ship with it, or the delay imposed by the current self-destruct mechanic. It's function as the centre of the ship would have to be taken over by the actual mass centre, but the ship could remain dependant on it's presence to operate. In light of the damage mechanic changes, this might not keep going for the core as the best option for crippling a ship, as a few unshielded hits to an exposed main generator could be equally effective.
As usual, sorry for taking your time.
