PTR Changelog 2018-11-05: preboosting
-
@mrfaul Clear, straightforward, intuitive and easy to understand game mechanics are as important as performance and quality of gameplay. You mentioned before that this feature is very obscure, and this makes it a good candidate for removing. Or reworking in a clear way (not just documenting, it wouldn't make it less obscure essentially), but it doesn't seem to have enough gameplay value to be introduced as a separate gameplay feature.
-
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.
-
@omnomwombat I can see your point here, thanks for participating in the discussion. But it's not about what players request or complain on, and not about developers or players time. API consistency is the crux in a game like this. We must either remove it or make it consistent with other methods. Currently it definitely feels like an undocumented, highly obscure and unobvious hidden example of bad design, or in other words, a bug. In fact, creeps being spawned were always intended to be untouchable, and it's just my fault that I haven't noticed this case for many months and not fixed it in due time. We can't just pretend now that it's intended and leave as-is, the game will become a mess eventually if we go this road and start making decisions this way. I understand it can cause some difficulties to players to adapt, but it's good for the game in the long term.
-
@artch Well since you seeing this a bug, then clearly state it please.
Your wording in the opening post doesn't state that in any kind and looks like you wanted an open discussion.OK well then on that note of consistency, please remove the ability to name spawns.
It is the only building with a name and kinda pointless. It is used in the tutorial to teach new players how to spawn a creep.
But beyond that it is bad practice to hard-wire your spawning algorithm to spawn names.
-
@mrfaul I believe spawns having names is what allow them to store data in memory. But then again, that would make them the only structure to have even a memory.
-
@mrfaul While I agree that hardcoding structure instances is not a good practice, they will find a way to do it without names (by id, for example)
-
I think I said this before, possibly in slack, I don't use pre-boosting and can't see I ever really would (never say never). But when I heard about it I went, that's cool.
In my mind it doesn't confuse the API (more than it already is), its an action which is part of the creation process. I can already cancel it, set the direction it will come out, and change its memory in preparation for its birth, I don't see why I couldn't also boost it. I.e. there are already some inconsistencies.
As others have mentioned I don't think anyone has suggested any other actions, attack, heal, transfer etc that should be done to it, and I don't think its that hard to enumerate them, I've looked over the API and can see (along with my feelings):
- Creep object actions on itself: all: not allowed
- Creep effecting other creeps: attack, heal, transfer: not allowed
- Spawn: recycle and renew: not allowed
- Tower: attack, heal: not allowed
- Spawn.Spawning: all: allowed
- Lab: boost, unboost: only boost allowed (can see an argument for allowing unboost to be consistent, i.e. Lab and StructureSpawn.Spawning are the only things allowed to affect it before it pops out; and it might be useful to do before doing a cancel)
Can anyone else think/see of any other functions that can take a creep as a parameter which would need to be decided upon?
All that said, to reiterate my first point, I don't use the mechanic so if its removed I'm not going to worry, just seems unnecessary to remove what seems to be a cool mechanic with the only reason being to be clean when there are other inconsistencies which continually trip me up (why is a controller a structure but a source and mineral aren't, why does a container, storage and tombstone have a store, but a creep has carry and then resources, labs, nuker, source and mineral all have their own versions)
-
@mrfaul The discussion we wanted to open is not about whether to remove this hidden behavior or not, but whether this game mechanic is valuable enough to critical number of players so that we develop and introduce it as a proper game feature. We are not going to leave it as-is in either way.
-
Creep object actions on itself: all: not allowed
Creep effecting other creeps: attack, heal, transfer: not allowed
Spawn: recycle and renew: not allowed
Tower: attack, heal: not allowed
Spawn.Spawning: all: allowed
Lab: boost, unboost: only boost allowed (can see an argument for allowing unboost to be consistent, i.e. Lab and StructureSpawn.Spawning are the only things allowed to affect it before it pops out; and it might be useful to do before doing a cancel)
This is a nice visual representation of inconsistency. Not allowed, not allowed, not allowed, allowed, not allowed, not allowed... wait, what? It's definitely looks like someone overlooked a missing check somewhere. But now we decide that no, it's intended to miss that check, and it's a feature, not just a mistake. Simply due to the fact that someone managed to take advantage of that missing check.
(why is a controller a structure but a source and mineral aren't, why does a container, storage and tombstone have a store, but a creep has carry and then resources, labs, nuker, source and mineral all have their own versions)
While I admit these don't represent perfect design (and honestly today I'd design them in a different way, and probably will do in some Screeps API 2.0), they are not inconsistences though, they are different API pieces trying to represent different in-game situations.
-
Would it be possible to benchmark on the live server how many people use this feature?
There is only a handful of people really invested in the forum, a shout out in slack would also be nice.Because it is a really nice coding challenge for people who like hardcore optimization problems.
I'm really interested how the entire community thinks about that.
A poll would also be a good idea regardless of how we proceed in this matter.
-
-
Well I'll voice my two cents since everyone seems to want this feature. I think it doesn't make sense, and even if it was in the documentation, it is very easy to miss things in the documentation.
It doesn't fit with the other mechanics, and I think it's best to remove it.
-
I wish I'd know about this before I spent weeks redesigning my layout to put all the spawns next to the labs!
One thing I would like to point out is that MOVE boosts are fundamentally tied to the body of the creep (unless you're equally boosting MOVE and CARRY). For all other cases of boosting MOVE, the unboosted creep will be intolerably slow-moving. With preboosting removed, we have to make sure it can exit the spawn directly onto a square which is both adjacent to the labs for boosting and out of the way of other creeps.
Although in fairness, with the whole unboost-renew-boost system you actually need such an area anyway.
-
@systemparadox This is why we're adding
Creep.pullat the same time.
-
This is a nice visual representation of inconsistency. Not allowed, not allowed, not allowed, allowed, not allowed, not allowed... wait, what? It's definitely looks like someone overlooked a missing check somewhere. But now we decide that no, it's intended to miss that check, and it's a feature, not just a mistake. Simply due to the fact that someone managed to take advantage of that missing check.
But the first "allowed" is still going to be allowed (on the spawn), so its still going to be inconsistent. As I said I don't use the mechanic and I'm not likely to, but I don't agree with breaking a mechanic used by quite a few people to tidy up an API in a way that still won't be "clean", I've not seen a single person confused by and has what I see as bigger inconsistencies . It just seems like an unwanted change, but at the end of the day it's not my decision and won't affect me so I shouldn't care, I just do for some reason.
-
@qgazq can you quantify your "quite a few people?" I feel like the number of players using it can only be identified by the devs, and if "quite a few people" were using it, there would be a much larger community outrage than there was...
-
Well just based on this post and from slack, there must be 10 maybe have said they are to some degree. And there will be those that don't use the forums/slack. I'm not saying it is a huge number, but "if it ait broke don't fix it", or in this case, "if it ait broke don't break it".
-
@qgazq I think people with pre-boosting code will be more engaged with the game, and therefore more likely to be around in Slack or on these forums. So there's some selection bias in the population you used for your observations.
