Friday Facts #448 - Tuning platforms

Hello,
Welcome to another Friday.

Asteroid damage changes Bilka

In 2.0, asteroids dealt damage to space platforms based on the relative speed of the asteroid and the collision would cause the asteroid to slow down. After an asteroid dealt a certain amount of damage, it would simply disappear. It was a bit strange to have the asteroids suddenly disappear into thin air with no indication of when it would happen.

As you may have already experienced, version 2.1 reworks this asteroid damage to be dependent on the health of the asteroid instead, combined with asteroids taking damage when they deal damage. However, asteroids no longer slow down as they deal damage to platforms. As you'd expect, an asteroid is destroyed when it loses all its hitpoints by dealing damage. This makes the damage much more predictable, as it is a fixed number per asteroid type, and the remaining damage an asteroid will deal to the platform now directly depends on the asteroid's visible health bar and not an invisible counter of how much damage it already dealt. This means that if you manage to shoot and partially damage an asteroid before you collide with it, it will now deal less damage to the platform.

Adjusting the impact

We playtested these changes during 2.1 development and immediately noticed a large drawback: medium asteroids would one-shot platforms in orbit around planets like Vulcanus. Before 2.1, the damage asteroids dealt to platforms in orbit would be greatly reduced since the platform isn't moving, but with the new speed-independent algorithm that was no longer the case. To counteract this, we buffed the health and resistances of the space platform hub, so that medium asteroids would no longer kill it in one hit. We decided to hold off on further asteroid damage nerfs, or related changes like buffing platform tile health, until we knew whether this change fixed the issue.

During the playtest, several of our platforms fell victim to medium asteroids.

After the 2.1 release, we received your feedback that building platforms in Vulcanus orbit was too punishing even after the buff to the hub, so in 2.1.13 we reduced all asteroid damage to stationary platforms by 90%. A medium asteroid could previously do 3200 damage to a platform in orbit; after this change, it was only 320.

While this massively reduced the frustration around parked platforms, the damage of medium asteroids was still too high compared to 2.0. Some experiments showed that in 2.0 a medium asteroid would deal around 1700 damage to a platform moving at a relatively slow 160 km/s, while it was 3200 damage in 2.1.13. We wanted to keep some of this increased asteroid damage, but not as much, so with 2.1.21 we reduced the damage of medium asteroids and halved again the damage to stationary platforms, so that a medium asteroid now deals 2000 damage to a moving platform and 100 to a stationary one. This is closer to the approximately 67 damage that a medium asteroid would deal to a stopped platform in 2.0. Additionally, we increased the damage dealt by huge asteroids to also be closer to the 2.0 damage numbers to discourage cheesing the trip to the edge by simply tanking the asteroid damage.

So overall, the way asteroids deal damage to platforms is now more predictable by being directly dependent on asteroids' remaining health and independent from their speed. Compared to earlier 2.1 versions, taking a hit on your first few flights or building platforms in dangerous orbits is now less punishing.

Space platform acceleration & drag CodeGreen

Everyone who has designed and flown a space platform has knowingly or unknowingly experienced the effects of the space platform acceleration expression. This formula is what effectively determines the top speed of a platform, using variables for current speed, thrust, mass, width, and height, though height is unused. The existing formula has served us well for quite some time; however, I've always felt unsatisfied with it. I am but a humble modder of 6 years though, not a dev, so my say in the matter is much smaller in comparison. Upon my request, I was told if I could come up with something better, it would be considered. To improve, we must first identify what to improve, which brings us to the next section:

The problem

Besides thrust, the biggest influence on the top speed of a space platform by far is its width. It directly scales the drag component of the formula (yes, there's drag in space, deal with it). While being adequate enough to make flying space platforms fun, width has some aspects and implications that I, and many community members according to a poll I posted on reddit a while back, found less than ideal. Thank you to all who voted, and to those who took the time to voice their thoughts and opinions in the comments.

~50% of voters didn't like width, and only ~10% did!

The design of a space platform is an intricate process, one that oftentimes involves a sizeable amount of iteration and adjustment. Width is determined by the furthest left/right tiles of the platform, so if one of those adjustments happens to make the platform even one tile wider in one location, the top speed is reduced almost as much as if that whole column of tiles had been filled vertically. This felt unnecessarily punishing, especially since the effect of width on acceleration becomes much stronger the narrower the platform is.

That leads to another aspect of width I found odd. Because width is so impactful, it became "optimal" to design platforms with minimal width and maximal height, which I call "pencil ships". Encouraging some shape isn't necessarily bad, since that choice is mostly arbitrary, but I don't think pencil ships are the right shape to encourage. The existence of asteroids already incentivizes narrower designs. There's a natural tradeoff between making a wider platform for more area and the cost of defenses to protect said area. It doesn't make sense to me for the wider ships to also be slower. Because of that, there is virtually no reason to build wider (other than farming for asteroid chunks, I guess), and thus narrow platforms reign supreme.

A very small "pencil ship" in flight.

On a separate note, thrusters are designed around not having any part of the space platform behind them. There wasn't a perfect method to prevent this, so thrusters were made to only prevent building behind them in a finite range. Naturally, some players exploited this behavior, resulting in platforms that have multiple layers of thrusters, AKA "thruster stacking". Since the usual limiting factor to how many thrusters a platform can have is its width, thruster stacking sidesteps this organic restriction entirely. Combined with the aforementioned pencil ship, hyper-unrealistic speeds were achieved with platforms fifty times taller than they were wide. When it comes to balancing, thruster stacking can mostly be ignored, since the majority of players aren't doing it and it wasn't intended in the first place. It does, however, show how absurd narrow platforms can get with the existing formula.

Lastly, even if none of what I mentioned above were an issue, the space platform tooltip on the right side of the screen doesn't mention width at all, only speed, mass, thrust, and damage taken. You had no indication that width mattered unless you already knew it did. Obviously, that can easily be solved by adding width to the tooltip, but that wouldn't be necessary if width were to be removed from the acceleration formula and replaced with something else entirely.

The solution

If not width, then what? There are plenty of interesting ideas for how to balance drag, however only one stuck out to me as the clear winner: Mass. Making drag based on mass addresses everything I mentioned above, and introduces some new and interesting design implications at the same time.

For starters, adding tiles to the side of a platform doesn't have as drastic an effect on drag anymore. There's still a downside, as every tile adds up, but it won't be as punishing as before. In fact, it doesn't matter where tiles are added anymore, as they all have the same effect on drag. Shifting the focus away from the shape of the platform and towards the amount of space it takes up encourages clever design, where keeping things compact rewards the effort put in to do so. The idea of doing more with less space also rather conveniently aligns particularly well with quality buildings and modules.

If the shape of a platform doesn't have an effect on acceleration, the other aspects of design determine the shape much more than before. Most notably, making ships faster requires a better thrust-to-mass ratio, and the only way to do that is by having more thrusters or higher quality thrusters (or both). A platform twice as wide as it is tall allows fitting twice as many thrusters versus the other way around, so wider ships emergently have the capacity to fly faster, at least with the same amount of mass. The tradeoff between width and defense gains an impactful incentive for actually doing so. Of course, you can still make well-designed narrow ships, or ships of any shape; the point is to expand the design space, not switch what gets punished.

The process

Hypothesizing a change is one thing, actually implementing it is another. To get a better understanding of what I was dealing with, I plotted the existing formula in Desmos. There were too many independent variables to have a useful graph for testing, so for consistency's sake I decided to make some of them dependent on each other: Mass (or weight as called internally) is scaled using width * height, and thrust is scaled by width / 4. Now the only variables to control are width and height, with the assumption that the platform uses the entire rectangle of space for tiles, and that the back of the platform has as many thrusters as it can fit. The point where the line crosses the X axis is the top speed of the platform, since that is the speed where 0 acceleration is gained.

The acceleration graph for a 50x50 space platform.

Now I could start trying out different ways of changing the formula to see how they would affect the graph. From the start, I limited myself to changing only the drag component, since I didn't want the shape of the line itself to change, only how it scales. After a few experiments, I settled on (weight / 200) ^ b in place of width * 0.5. The 200 comes from the mass of one space platform foundation tile, and b is a magic number between 0 and 1 that depends on how much drag should scale with mass, which ended up being 0.8 at the end. The predecessor mod Simpler Platform Drag did something very similar, with an exponent of 0.5 instead.

Of course, making a change this significant cannot be done without extensive testing in game, and I knew my limited selection of space platforms from my own games wasn't going to cut it. Thankfully, I had turned to the reddit community for help in advance, asking for people to send in as many space platform blueprints as they could shortly after the poll. There are too many names to list, but thank you to everyone who sent me blueprints in this post; I used almost all of them. A good portion of them were more optimized for width, which makes sense, but it's important to see how existing designs will be affected. There was still enough variety between all of them that I had a pretty good idea of how everything was affected overall.

I couldn't fit all of them, but these are the beasts that helped shape the future.

After much iteration, V453000 and I decided on the numbers together, which gave us the new formula present in 2.1.21. Here's a comparison of old (red) to new (blue) for a space platform 50 tiles tall, with width scaling up to 1000 tiles to see how it behaves as it gets wider.

As you can see, it starts off slightly slower than the old formula, but as width increases, so does the top speed, with diminishing returns, until it reaches a point where it becomes worse to add more width. This lines up exactly with what we wanted, where building wider rewards the player with a higher speed, but not to the point where the optimal ship is an infinitely long wall. The only ships that were significantly hurt in testing were those making excessive use of the thruster stacking exploit; the rest of the skinnier ships didn't suffer too harshly. The wider ships and the tiny starter ships gained some speed, since they already had a decent thrust-to-mass ratio.

With this change, narrow ships no longer have dominating speeds, wider ships don't get punished just for being wide, and designing space platforms should be more fun overall. 2.1 has been in experimental for quite some time now, and since this change retroactively affects all existing platforms, I apologize that this wasn't done earlier in development. I do hope you'll enjoy making more space platforms from this point on, and it'll be exciting to see what cool and unique ships everyone will be making. Many thanks to Wube for accepting the change and having me write this section, it's been a pleasure sharing the journey with you all.

Community spotlight - Biter Battles Carl

Most of us enjoy Factorio as a peaceful (well, peaceful-ish) game where you build your factory at your own pace. But there are always a few who want a bit of a different challenge, and over the years a competitive scene we never really imagined has grown around the game.

Biter Battles has been around since 2018. Two (or more) teams build their factories side by side, and the goal is to feed science packs to the biters as fast as possible, which sends increasingly large waves of biters at the opposing team. Whoever destroys the other team's base first wins. Over the past 8 years the community has refined the mode a lot, and watching the top players today is genuinely impressive.

If you have already launched your rockets and built your megabase, and are looking for a completely different challenge, there are a few ways to get into it:

• Casual play - The BiterBattles.org server runs 24/7 on the latest stable vanilla version (no Space Age), with no mods or registration needed. Just find it under Multiplayer → Browse public games. All skill levels are welcome.
• Ranked play - The Biter Battles (BB) League is a continuously running ladder, free and open to everyone. You just need to link your Factorio account on biterbattles.org.
• Tournaments - The 3 vs 3 BB Cup runs about three times a year and features some of the fastest and most competitive Factorio players in the world. The matches are streamed on Twitch, and the last Summer Cup reached four-digit live viewer counts.

If you want to see what high-level play looks like, check out Zaspar & Dalvos playing a 3 vs 3 balance test for the upcoming Autumn Cup, or AntiElitz's POV of the Summer Cup semi-final.

As always, let us know what you think at the usual places.