It's a change to a constant. If someone's code breaks, it's probably because they aren't handling constants and instead hardcoded shit. There's no point in having constants if we're just going to ignore them. Basically, if your code breaks, then you deserve to have your code break.

@KyraLee I'd also point out that the website overall can be a little redirect happy as well, making this whole thing worse. More than once I've tried to view a room someone linked me, had to wait for the world to load, clicked out of popups, logged in, gotten directed to either my stuff (if I'm spawned in) or where it thinks I should spawn, etc., go back, wait no now it forgot I logged in, etc.

Yeah I'd seen that the other day and wondered what had happened to the home page.

I'm just going to throw my two bits in here, but I've always hated the "scroll down twelve times to see content that could have fit on a single page" approach to web design.

EDIT: I'd also like to point out that the information density has been driven even further down, due to all the weird and pointless empty spaces next to text.

With Iso-VM being a thing, this should be a viable option, no?

EDIT: Actually, would this even be a significantly breaking change? Only players who had gone into the power creep move prototype would be having problems with the change breaking, and those players would explicitly be the ones trying to fix this problem.

Not only that, was removing preboosting not a breaking change? And that was a hell of a lot more widespread than people mucking about in the power creep movement prototype.

Come to think of it, you could just as easily just point both the power creep and regular creep move commands to the prototype they're inheriting from and mark them as depreciated. That both wouldn't break anything and allow would allow people to get their code fixed.

@ratstail91 That doesn't really explain why they didn't do this to begin with though. "Legacy Code" is a poor excuse for bad design when you get to start from scratch (and they did get to start from scratch).

This wouldn't be the first time they made a breaking change- it wouldn't even be the first time they made a breaking change without pushing it to PTR first. Yeah, it's possible that inactive players will suffer for that, but realistically if you're not paying attention to the PTR and whatnot, you don't really have any right to get upset. You're actively not participating in the game- does it make a difference if you get wiped because one of your neighbors started eyeballing your territory vs because you didn't pay attention to patch notes?

User error is not a valid excuse for bad design either.

Personally, I disagree- this is absolutely a cut and dried issue. I'm all for recognizing the nuance in complex situations, but the truth is that the longer this is left unchanged the more problematic is becomes. Precedent exists for pushing breaking changes.

Besides, note- Both Warinternal and Semp are players that use prototypes heavily. @WarInternal I know for certain uses, for lack of a better phrase, a "Prototype-based architecture". The idea that these changes shouldn't be made for the sake of players who rely heavily on prototypes is completely swatted down by the fact that those very players are the ones asking for these changes.

I feel the lack of an inherited movable-object potentially sets a bad precedent. Avoiding code duplication is a key measure in programming, regardless of language. I'll be the first to admit that if I'd implemented this, I wouldn't have thought to split off the movement prototype- it is extremely easy to get target fixation when working on a new feature. Nevertheless, the duplication here is inconsistent with the rather aggressive prototyping seen elsewhere. While Screeps is indeed a game about programming, this should be focused in areas that are more... productive. Unexpected behavior is already extremely problematic in Javascript- let us not make it worse with inconsistent prototype design.

The unlikely case that a third type of creep is to be added must be considered- must then players patch their way around three separate movement systems? Four? While some might argue this is slippery-slope reasoning, I feel that the unreasonableness of such an approach for ten different systems is proof enough of it's unreasonableness for two.

I would be extremely curious to hear the thought process behind this development choice- if it was overlooked at the time, considered and rejected, considered out of scope, etc.

I like what I see for the most part. Without hard numbers on the rewards for killing it's hard to say. I'm guessing a lot of these are going to get killed at stage one.

Personally though, I'm happy to see more PvE content.

I never take this argument about "old / new players" as valid. It's a MMO after all. It means players have constant persistent progress, and the game mechanics should make it possible to have progress for years.

Personally I think in this case @Shibdib is reaching here- it reminds me of jokingly arguing that energy should be removed because it gives older players a greater advantage. Let's be honest though- letting people recover some of their boosts is going to benefit pretty much anyone using boosts relatively equally, and boosts are already a major stepping stone for newbies.

That being said, @artch your previous actions don't really agree with the sentiment you express here. In the power creeps PTR you provided a shield against downward abuse by requiring that powers explicitly be enabled in a room by touching the controller before they can be used.

@artch @Shibdib It's important to differentiate between types of advantages- Boosts are, I think, one of the easier advantages to equalize- code is the problem, access to war material not so much.

I want to stress the difference between advantages- Veterans have an advantage in raw war materials, income, cpu management, etc. that yes, they've earned. These can also be overcome, but don't extend this to a blanket statement that it's OK to shaft new players to preserve old ones.

A player should be able to overcome issues with enough skill- veteran players have more skill (and code, which I'd argue is an extension of skill).

I still remember when this was on the website:

I guess we've come a long way since then.

EDIT:

In the interests of olive branching and not going full @tedivm on this, I do like the idea of unboosting. I'm not so certain that killing lab time is really the solution. I feel like some sort of middle ground would be useful- eat some lab time, but not just shutting down the lab entirely.

@mototroller I like the idea of being able to build in hostile rooms- it wouldn't necessarily be easy, or even useful most of the time, but simply having the option is significant.

Overall, I like the idea.

If we do get a shard3, I think it may be time to take another look at the way portals connect shards; shard0 and shard2 are already extremely isolated from each other, shard3 will make that even worse, and I feel like this sharding also sort of echos in the community as well.

A few ideas:

• Portals in highway rooms can lead to any shard, not just the next shard over

• Portals in sector centers can lead anywhere

• Portals that creeps can define what shard to exit on

• A structure allowing players to create their own portals

• Something something power creeps

I think this would help a lot with preventing shards from becoming islands.