PTR Changelog 2018-11-05: preboosting
-
@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.
