- Joined
- Jun 23, 2013
- Messages
- 504
- Reaction score
- 127
[A suggestion I wrote during the forum downtime, before the new mechanics were implemented. Since the new mechanics are far from perfect, and I've made all these pretty diagrams and written the whole thing already, I decided to post it anyway. Post-update additions are enclosed in brackets.]
The idea is for stabilizers to have an alternative mode of operation (they have plenty of rotation bits to spare) where they evaluate their position differently and boost other, normal stabilizers.
This demonstrates the most simple case. Suppose we draw a line from reactor to stabilizer. A stabilizer in beta mode will only count its distance to that line. This distance doesn’t stabilize the reactor directly, rather, it increases the distance at which the game “thinks” the main stabilizer is placed.
This should roughly correspond to ships’ breadth adding to their effective, stabilizer-wise length. For example, all these ships would have roughly equal power. (One might reasonably want the rightmost ship to be stronger, not equal, this could be reduced to a simple issue of putting the right multiplier/exponent in the config for beta stabilizers.)
Of course, this is only the core of the idea, and I’ve only bothered to consider one stabilizer and one beta at a time. Some qualifications and details are in order.
In general:
The reactor-stabilizer line has nothing to do with the current stabilizer streams. It’s a purely mathematical thing, so I didn’t have to say “the distance component orthogonal to the reactor-stabilizer axis”.
Unlike stabilizers, beta stabilizers as proposed here completely ignore inactive reactors. As best as I can tell, the reason stabilizers do interact with inactive reactors is to prevent us from spamming backup reactors everywhere. With those limitations already in place, we don’t need beta stabilizers to nerf backup reactors even more. Therefore, this mechanic reaps the full simplicity benefits of only considering one reactor at a time.
Beta stabilizers probably shouldn’t have any of the stream mechanics regular stabilizers do, for much the same reasons as above.
Some remarks:
[If I may, I think the current solution is a good example of why this problem is hard. Sectioning ships off into six directions does, mostly, represent the intuitive idea we're striving for, but it creates arbitrary categories. Therefore, we're stuck with hard diagonal cutoff lines. This is mitigated by how we can rotate the grid manually, but there we are again with more menu adjustments in a supposedly block-based game.]
We’ve all seen a great amount of proposals to fix stabilizers, one way or another. What I like about this one in particular are two points, essentially.
First, it only expands on the existing system, instead of trying to rework it outright. All the stabilizer mechanics we do have already would go mostly unchanged, so there’s no significant shift in directions.
Second, it takes the most difficult problem here - a concrete, intuitive and consistent definition of which direction is which - and hands it over to the player. This lets us avoid weird cutoff effects or arbitrary categories.
In spite of all these details, I don’t think this system is too complicated. I realize that’s easy for me to say, but I do think it adds up to something mostly intuitive. The computational details are complicated, of course, but that’s because matching human intuitions with rigorous rules is hard. In the end, the user-facing mechanics boil down to “place different blocks in as different directions as possible,” which shouldn’t be too difficult to grasp.
The idea is for stabilizers to have an alternative mode of operation (they have plenty of rotation bits to spare) where they evaluate their position differently and boost other, normal stabilizers.
This demonstrates the most simple case. Suppose we draw a line from reactor to stabilizer. A stabilizer in beta mode will only count its distance to that line. This distance doesn’t stabilize the reactor directly, rather, it increases the distance at which the game “thinks” the main stabilizer is placed.
This should roughly correspond to ships’ breadth adding to their effective, stabilizer-wise length. For example, all these ships would have roughly equal power. (One might reasonably want the rightmost ship to be stronger, not equal, this could be reduced to a simple issue of putting the right multiplier/exponent in the config for beta stabilizers.)
Of course, this is only the core of the idea, and I’ve only bothered to consider one stabilizer and one beta at a time. Some qualifications and details are in order.
In general:
The reactor-stabilizer line has nothing to do with the current stabilizer streams. It’s a purely mathematical thing, so I didn’t have to say “the distance component orthogonal to the reactor-stabilizer axis”.
Unlike stabilizers, beta stabilizers as proposed here completely ignore inactive reactors. As best as I can tell, the reason stabilizers do interact with inactive reactors is to prevent us from spamming backup reactors everywhere. With those limitations already in place, we don’t need beta stabilizers to nerf backup reactors even more. Therefore, this mechanic reaps the full simplicity benefits of only considering one reactor at a time.
Beta stabilizers probably shouldn’t have any of the stream mechanics regular stabilizers do, for much the same reasons as above.
The first implementation question is, of course, “What if there are several stabilizers?” The simple solution here is to just draw the line to the stabilizers’ common center of mass.
To the left: Why this makes sense. To the right: Why it’s a terrible idea.
I think the sensible approach here is not to use the line through the CoM, but the line that goes closest to all stabilizers.
I’ll admit I don’t know exactly what the equation for this would look like, but unless I’m terribly mistaken, this is basically just a variant of linear regression, an old and well-studied problem with very efficient solutions.
To the left: Why this makes sense. To the right: Why it’s a terrible idea.
I think the sensible approach here is not to use the line through the CoM, but the line that goes closest to all stabilizers.
I’ll admit I don’t know exactly what the equation for this would look like, but unless I’m terribly mistaken, this is basically just a variant of linear regression, an old and well-studied problem with very efficient solutions.
Then, there’s the question of how to count multiple beta stabilizer blocks. This ought to be the one cut and dry question in this proposal.
For the final distance figure, take the average of all betas.
For quantity, require more betas the more stabilizers there are, though not necessarily linearly. If there are too few betas, the distance bonus is lessened.
For the final distance figure, take the average of all betas.
For quantity, require more betas the more stabilizers there are, though not necessarily linearly. If there are too few betas, the distance bonus is lessened.
Then, the question of how, exactly, to apply the bonus. I’ve been able to think of several ways to do this. Some are more fair, some seem easier for performance.
Again, there’s a simple solution, simply increase every stabilizer’s perceived distance by X.
And again, on the right is why I’m sort of iffy about it.
Make no mistake, this isn’t nearly as bad as the CoM exploit. To work, the rightmost design requires the ship to be basically triangular, which is more or less what we’re hoping to encourage anyway.
Nevertheless, we might want a system where the bonus is somehow directional, benefitting stabilizers more the closer they are to the line. Or not. I’m undecided on this. This gets complicated, because while betas ignore inactive reactors, stabilizers do not, and they all have different points they need to be distant from.
In any case, there needs to be a limit - a stabilizer can never be boosted to more than twice its original distance. That way, we can’t get ships that get more of their stabilizer distance from betas than from stabilizers themselves.
Again, there’s a simple solution, simply increase every stabilizer’s perceived distance by X.
And again, on the right is why I’m sort of iffy about it.
Make no mistake, this isn’t nearly as bad as the CoM exploit. To work, the rightmost design requires the ship to be basically triangular, which is more or less what we’re hoping to encourage anyway.
Nevertheless, we might want a system where the bonus is somehow directional, benefitting stabilizers more the closer they are to the line. Or not. I’m undecided on this. This gets complicated, because while betas ignore inactive reactors, stabilizers do not, and they all have different points they need to be distant from.
In any case, there needs to be a limit - a stabilizer can never be boosted to more than twice its original distance. That way, we can’t get ships that get more of their stabilizer distance from betas than from stabilizers themselves.
Now, to expand a bit on the beta stabilizer placement. Thus far, we’ve only encouraged ship expansion in one direction. Pancake ships may be preferable to needles, but we’re not done here.
Furthermore, as one can notice in the second topmost diagram, we’re also doubling down on encouraging reactor placement as far out to the edge as possible. With regular stabilizers, this is only in the ship’s longest dimension, with betas, it’s in at least two.
The next diagram will be looking straight down the stabilizer line, represented as an orange dot, to better illustrate beta placement.
To the left: What this system encourages. To the right: What I think we want to encourage.
Fortunately, we’re effectively in a 2D grid, and we only need to produce a single, mostly fair “distance” value. Instead of making it the total average, split the coordinates into +X values, -X values, +Y values and -Y values. Average those separately, and add them together. That way, the four small distances in the rightmost diagram would add up to something comparable to the leftmost diagram.
To do this, we need to chose some kind of coordinate system for this imaginary 2D grid, which may in actuality be any sort of weird diagonal through the ship. It’s not too important, but I do believe we might get the most consistent results if we simply chose the grid that has the beta CoM directly beneath one of it’s axes.
Furthermore, as one can notice in the second topmost diagram, we’re also doubling down on encouraging reactor placement as far out to the edge as possible. With regular stabilizers, this is only in the ship’s longest dimension, with betas, it’s in at least two.
The next diagram will be looking straight down the stabilizer line, represented as an orange dot, to better illustrate beta placement.
To the left: What this system encourages. To the right: What I think we want to encourage.
Fortunately, we’re effectively in a 2D grid, and we only need to produce a single, mostly fair “distance” value. Instead of making it the total average, split the coordinates into +X values, -X values, +Y values and -Y values. Average those separately, and add them together. That way, the four small distances in the rightmost diagram would add up to something comparable to the leftmost diagram.
To do this, we need to chose some kind of coordinate system for this imaginary 2D grid, which may in actuality be any sort of weird diagonal through the ship. It’s not too important, but I do believe we might get the most consistent results if we simply chose the grid that has the beta CoM directly beneath one of it’s axes.
Some remarks:
[If I may, I think the current solution is a good example of why this problem is hard. Sectioning ships off into six directions does, mostly, represent the intuitive idea we're striving for, but it creates arbitrary categories. Therefore, we're stuck with hard diagonal cutoff lines. This is mitigated by how we can rotate the grid manually, but there we are again with more menu adjustments in a supposedly block-based game.]
We’ve all seen a great amount of proposals to fix stabilizers, one way or another. What I like about this one in particular are two points, essentially.
First, it only expands on the existing system, instead of trying to rework it outright. All the stabilizer mechanics we do have already would go mostly unchanged, so there’s no significant shift in directions.
Second, it takes the most difficult problem here - a concrete, intuitive and consistent definition of which direction is which - and hands it over to the player. This lets us avoid weird cutoff effects or arbitrary categories.
In spite of all these details, I don’t think this system is too complicated. I realize that’s easy for me to say, but I do think it adds up to something mostly intuitive. The computational details are complicated, of course, but that’s because matching human intuitions with rigorous rules is hard. In the end, the user-facing mechanics boil down to “place different blocks in as different directions as possible,” which shouldn’t be too difficult to grasp.
