I agree with @TuN9aN0 about the convenience factor of not opening the constants document. I made some other notes of other potential documentation improvements. Note that these are all discoverable easily enough through experimentation, it's just nice to have it available outside the game.

• Similar to the PWR_* constants, would be nice to see TicksToLive/hits per level/carry capacity outside the constants document.
• Clarification about whether simultaneous execution of powers is allowed
• Clarification about whether powers are enabled in rooms without controllers
• Clarification about whether power creeps can be spawned/renewed in rooms with power disabled. (after understanding the feature more, it is obvious that you have to create a power creep in order to enable power, but I initially was confused by this)
• Which, if any of the normal construction limitations apply to rampart creation. For instance, neutral rooms, opponent's rooms, room borders/edges.
• Clarification about stacking (e.g. you can't use REGEN_MINERAL with 5 different creeps on the same X node.)
• ticksToLive is listed as undefined for power creeps that are not spawned, but appears to actually be NaN.

If any of these are present in the docs and I just missed them, please disregard. It wouldn't be the first time I was looking in the wrong place.

I like the idea of having some kind of additional world asymmetry, as a means of stimulating meaningful conflicts. There are many potential ways of doing that. I think it would be hard to get something like this implemented though.

I have a strong bias on this, but I'd like to give voice for the most extreme "please keep preboosting" side. My novel-length initial reaction can be found here: https://screeps.com/forum/post/11451, and I'll try to avoid repeating myself. Thanks again to artch for the exceptionally fast response on reverting that change to allow a more formal discussion.

To frame the discussion, I'm going to assume the goal we are working towards is to create the most enjoyment for the most players over the life of screeps. This feature isn't going to affect profits much one way or the other (probably only a dozen affected players), so I don't think that's much of a factor.

As evidenced from the discussion above, it's fairly easy to contrive an analogy in which preboosting "makes sense", or vice versa. We can make that work either way. The start of this thread raises concerns about consuming developer time to exhaustively consider whether other actions should allowed for creeps during creation. I understand the "slippery slope" fear. I honestly don't think it will come back to bite the developers to let preboosting stand. I haven't seen any players express confusion over whether any other new actions should be allowed while spawning. We've had 4-6 months for those confusions to surface, so that seems like a good data point. I don't think players are likely to waste your time about enabling various other actions moving forward.

Even though I don't foresee much of a cost to leaving preboosting in, the cost of removing it is admittedly localized to a few players. There are a handful of players besides myself who would be acutely affected by this, but I can't pretend it's a majority. For my little anecdote, knowing preboosting is on the chopping block has killed the game for me, at least in the short term. I went from averaging 3+ hours of screeps play per day to ~2 hours total in the month since the feature was slated for removal. It's really a tough pill to swallow. For me, it's difficult to imagine that the many hours already spent by players to implement preboosting could be equaled by brief confusions over the potential API inconsistency it implies. If there's any path forward that could let us leave things as-is, or consider a non-breaking change, I would love to pursue that.

@artch thank you, very much appreciated.

I am affected by this change. I think this sort of thing can be handled better in the future. To give credit where it's due, developer communication is at an all-time high right now. I think all the players enthusiastically appreciate that. This update does present a problem though, and I believe more communication was needed.

Based on the commit message, the developers have taken the stance that this was a bug. For a minor bugfix, it is reasonable to slip in a change without forum announcements. Unfortunately, I was unaware that this was considered a bug. As a player, it was not obvious to me. Here was the sequence of events from my perspective.

• Heard about preboosting in my alliance slack. This sounded like a very cool thing, but it definitely sounded like an "unitended consequence" sort of thing.
• After a few weeks, I saw discussion about preboosting in official slack (which I don't keep up on very well.) The two categories of responses I saw were "Neato" and "Neato, I think I'll do that." I did not see anyone flag it as a flagrant abuse or indicate they thought it would/should be patched out. There was no developer response that I saw discouraging implementation of this feature. If players who used this feature thought it was OK to openly discuss, they probably didn't consider it an exploit either.
• I waited. I am a cautious person by nature. I have 300M ramparts in my rooms. Getting my old lab reaction+boosting code to work right took me months of debugging edge cases, and I had no desire to rewrite it if there was a chance of preboosting being removed. Note that I did consider this possibility. However, there had been very little updates in the last year, and similar features (multiple mineral harvesters harvesters at the same time, harvesting just minerals in SK rooms to avoid invader spawns) that existed for longer had never been patched. My completely rational conclusion as a player was that preboosting is part of the game, unlikely to be removed, and fair game for implementing.
• In July, I made a completely new room layout to take advantage of preboosting and reacting all 10 labs. It was a nightmare to implement, and I got it absolutely seamless. The boosting happened during the gaps between reactions. I could run 10 labs and boost and there was never a hiccup for all but the cheapest cooldown time reactions. I'm pretty proud of this, I think it was the most elegant piece of code I have ever written. Note that there were tradeoffs/sacrifices in base layout required to make this work.
• I started updating my rooms to use the new layout. Currently I think I have 18 of them on the preboost layout. I had to move spawns, labs, storages, terminals, and 300M ramparts to make this work. Not Fun.
• 3 days ago I heard a rumor preboosting might be removed.
• Today I found out that it was patched out with no announcement. Over half of my rooms are now defenseless, since I had preboosting reliably implemented and there was no fallback boost mechanism needed. The rooms either preboost, or they don't boost at all. I have economic features the depend on boosts, and those are broken as well.

I hope you will understand that this is a big problem for me as a player. My new rooms don't have enough space to switch to my non-preboosting method. The new layout made significant sacrifices in walk-ability of labs in order to get preboosting to work. I now have to code up a third boosting solution (internal weeping), that will have only the worst properties of both my previous solutions, and in the meantime, I am vulnerable to attack. My feelings are probably not relevant to this discussion, but I feel that I have been royally screwed.

I would like to request the following actions from the developers. I acknowledge that this is not a democracy. You will make the game that you want to make, and it's for us to play or not play if we enjoy it.

• Please consider reverting this change for a month to ameliorate the damage to affected players.
• Please make a public statement regarding similar "bugs." (multiple mineral harvesters harvesters at the same time, harvesting just minerals in SK rooms to avoid invader spawns, ect.). We need to know if these are going away before more people implement them.
• With power creeps on the horizon, there are going to be necessary re-balances that break people's code. As soon as you are aware that a feature is overpowered and needs to be re-balanced or removed, please make a forum post stating such. Nothing is worse for me as a player than having weeks of work rendered useless, and it will be important to mitigate that.
• Please consider taking a less binary approach to preboosting. I do not see this as a game-breaking issue. There are advantages to having your creep preboosted, and there are disadvantages to laying out your base in such a way that it is possible. Just because it wasn't originally intended doesn't make it not awesome. I think it is cool, and it was a good coding challenge to implement my solution. If the preboosting feature/bug is just too unpalatable as-is, consider a fatigue penalty as mentioned above. That would give preboosting players no benefit from preboosting, but would prevent our bases from being broken.

This is a very long-winded post. I tried not to say unnecessary things, but there was a lot to be said. I hope the tone has remained respectful, in spite of my current emotions.

Sincerely, omnomwombat

@artch @o4kapuk, thanks for the response and clarification. I saw something in slack that made me think spawn-at-edge-of-map invaders would no longer occur for source keeper rooms. Glad to hear that is incorrect!

This is very cool. There are a lot of thoughts being posted here (because we're excited!), but I wanted to add one more.

it sounds like this will supersede SK room invaders. In my opinion, SK rooms are one of the most genius features in the game right now. There is nothing else I know of that has such a diverse set of solutions. Some people use armed miners, some people use a melee+ranged patrol pair, some people use just a ranged creep, some people use a single boosted attack creep, some people use an attack creep for clearing the SK spawns and then a separate healer to just tank the damage of invaders, ect, ect. I haven't watched all that many people's rooms, but it seems like everyone has a slightly different approach.

This is pretty much the holy grail of balancing for a strategy game. No cookie-cutter solution, and everyone weighing the tradeoffs differently. Obviously, NPC strongholds will attempt to also have a plethora of viable strategies, but I would lobby for preserving the existing feature while adding NPC strongholds. This has the added benefit of not invalidating significant coding effort by everyone who has implemented SK mining. Which probably doesn't resonate with the developers, but it's always something to consider when adding new features.

I have experienced this as well, starting 11 or 12 hours ago.

I don't yet use harvest boosts, but I have several of the aforementioned uses working their way to the top of my "to-do" list. My brother and I used to laugh about the uselessness of harvest boosts, but they've been slowly growing on me. I now think of them as one of the most interesting economy boosts. I've had several pleasant nights of not-sleep-brainstorming, trying to think up new ways to use them.

Not saying the suggestion of giving extra resources is a horrible idea, but I do think they are quite interesting as-is, and have some untapped potential.

Disclaimer: I don't currently use recycling of HEAL parts to move energy to my temple room, but I have been previously aware that it is possible.

I am surprised that this is considered an abuse, rather than an innovation. One of the coolest parts of the game for me is trying to figure out a way to use the existing mechanics in a way that no one has ever thought of before. I feel like the game designers should be patting themselves on the back for making systems that foster emergent gameplay. It's OK if recycling wasn't intended originally to be used this way. I would have to code a special solution to take advantage of HEAL recycling; basically we have a new "feature" for free, just from player cleverness.

If HEAL recycle effectiveness was absurdly better than regular hauling, I think a nerf would be appropriate. As-is, it feels like a punishment for innovation. I am already thinking of several features I use that might be similarly punished, and feeling concerned. Ultimately it falls to the developers to determine where the line between "abuse" and "innovation" falls, but I wanted to put my two cents in.