Posts made by Knightshade

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.

@o4kapuk Just wanted to express my thanks, especially after the last fun on the forum about the World Review. This kind of communication helps a great deal. I like what I see.

Also: NPC Strongholds Hype!

@artch Fair enough. I see my accusations were at least partially misplaced.

@o4kapuk @Dissi I guess you guys are partially to blame for this as well. I'm disappointed, though I know you both have lives like Artem and can't live Screeps.

The issue remains that player engagement is falling, the community knows almost nothing about what's going on behind the scenes, and we're left with drafts and promises that go nowhere. I'll admit I'm one of the more irritated people about this, and I've been attempting to keep my irritation to myself up until now, but the issue does exist, and I don't feel like it's being addressed.

@artch

let's please not judge a 3-person part-time team with standards of an AAA project with many full-time developers and managers.

We're not. We (as a community) would just like some sign that you haven't died or suffered some horrible accident.

As for speaking to the Community Managers- I get a strong sense that they don't know anything more than I do. Both of them are loyal to you and to Screeps almost to a fault, but I don't think they actually have anything we don't aside from maybe a private email.

I know I've brought up issues with communication and lack of a roadmap to both of our CMs in the past and was promised improvement, which means either those concerns never made it to you or you disregarded them. Worse, I feel like they've been put in a very untenable position- Both CMs have tried to reassure us of plans for Screeps, discussed concerns and handled questions, but without hearing from you all of that falls by the wayside. CMs exist largely to handle the day to day BS that comes from having to deal with any online community- they aren't a get out of jail free card for community engagement.

I understand that life happens. Things happen that you aren't prepared for, things go wrong, and sometimes you just get screwed, but when you vanish for months at a time there are consequences for that. The truly sad thing is that the slow bleeding out of the community doesn't have to happen in cases like this. Ten minutes of "Hey guys, was really busy this week- a quick rundown" would do wonders, and give the people trying to support both you and the game something to point at when people like myself start complaining about the lack of engagement, the lack of activity, the appearance of lack of direction, and so on.

If nothing else, help those people help you.

@atavus I think you've touched off something very important here, in that the community no longer has any faith in the development of Screeps, and that the Screeps team has done nothing to combat this opinion.

Words are cheap, and frankly we've seen a lot of them (as I linked in my previous post). Actual development and engagement, on the other hand, we've seen very little to nothing of is the last year. We've heard lots of promises, to the point where Power Creeps have literally become a meme on slack.

Atavus also touches on another extremely important point- regular changes matter more than sweeping updates, even if sweeping updates look better for marketing and make you feel cooler. The games with the most forgiving communities and engaged devs (Factorio, Space Engineers, so on) have regular updates, even if it's just a post saying "Hey, this is what we've been working on, but it turns out that what we're working on is really hard so we had to make a tool to make it less hard, and that's all we really got done.", and in-game updates are incremental- signs that the devs are still alive and tweaking the game, even if they aren't releasing anything huge.

I feel like we, as a community, are being asked to take a very great deal on faith here that I don't feel that the Screeps Team has necessarily earned.

We closely monitored the recent events staged by the community on their own initiative, and we are excited to announce the start of the development of a new game powered by the Screeps-based engine. It will offer a completely new experience for those who want a faster, more dynamic gameplay. Screeps Arena will become our second project and a separate Steam game as a match-based RTS with the same engine but a completely different take on game content. A separate page for this project is coming very soon to allow you to follow all updates. Stay tuned!

So let me get this straight...

After having seen zero development for five months, the announcement of Room Event Log (which fell through), teasing about power creeps with zero changes to prod, the snafu with Pull Requests getting shut down with no explanation, and lifetime subs becoming a thing, there is now an announcement for a new game that isn't Screeps?

You realize how bad this looks, right?

TLDR: When a disproportionately large part of an existing branch is being changed (say, 50% or more), add a popup saying "Are you sure you want to do this?", complete with a notification that you're overwriting a crapton of your code.

Now in detail- I, as well as several others, have had issues with the browser deleting code. I had my entire codebase get wiped a couple years ago, and it seems to be a regular thing on slack for someone to say that their code either was mass deleted by accident to to sim or the tutorial changing branches without saying anything, or to have an issue with having a browser tab for console output overwrite a browser tab for code editing, and so on.

I'm not even necessarily saying it isn't user error, I'm just saying a bit of idiotproofing would go a long way to help. Having the ability to see a diff and choosing what to keep (or to cancel all changes) would just be gravy.

@gankdalf Agreed. Making the game more newbie friendly is something I think we can all get behind, but not at the cost of existing players. I hate to say it, but not reading the documentation is on the player, not us.

@artch So to be clear, will all of the old data still be accessible, but simply under a different name, or are you suggesting removing our ability to access the data entirely.

@mrfaul said in Power Creeps update:

Especially if they process power directly into Ops.

I'm not sure what I think of the possibility of being able to process power as a resource either into power for an account or opts.

On one hand, it allows players not using power creeps the ability to potentially market power, but it also opens us up to the snowballing problem we had when power creep abilities didn't consume resources.

So, to start off, I want to say that I'm going to be personally locking my opinions to the Operator power creep. Yeah, punch seems like it's still dumb, but it's not on the creep that is currently being actively developed, so I'm ignoring it until it becomes an issue. That being said:

Pros:

• Opts: I think it's a terrible name for a resource, but I like having a separate resource to manage that can potentially be burned out (and make a power creep useless)

• Enabling Power In Rooms: This potentially resolves one of the major complaints I had before regarding the risk of high level power creeps curb-stomping players. Defensive battles remain largely the same for players who haven't unlocked power creeps, though field battles and assaults against those who have them will be more difficult.

• Variety: I like the distribution of powers here. Things like EXTEND_SOURCE and OPERATE_STORAGE that, while perhaps not useful in all circumstances are gamechangers when useful.

Questionable:

• EXTEND_MINERAL: This is... sketchy. We'll have to see how the market pans out, but I'm skeptical.

• EnableRoom(): yeah, this was in the pros, but there's a major potential flaw here in that it can only be removed by unclaiming the room entirely, but it can be used on neutral rooms that can't be unclaimed. This is a huge potential issue. (Also, I assume the range is melee on this?)

• API: I'd say this matters. Setting up a constant of choices-per-level-per-type may be necessary, and it might be annoying, but I think it's key to the game. That said, I'm willing to drop the issue until I see the full implementation details.

Cons:

• Honestly, I don't have much here yet. Most of the powers seem pretty well balanced, or at least useful.

A few other observations:

EnableRoom has some interesting results. This renders PCs useless in controllerless rooms, meaning highways, portal rooms, and SK rooms. I'm not sure this will heavily affect the operator, but this may have interesting implications for further development. There are some potential issues with reserved rooms (does enabling go away when the room reverts to unowned? How exactly are reserved rooms handled? Any chance of being able to sabotage SK rooms?)

@artch I will say, I was skeptical of a solution to handle the potential griefing issue. While I'm still curious about the details of enableRoom, I do like the approach.

That said- What are we looking at for other stats on power creeps- Will the operator have static health, or are we looking at potentially allowing some type of health scaling per level? Will the PC have to return to an owned room, or even return fully to a Power Spawn to upgrade?

OPERATE_LAB- Am I understanding this correctly to increase both the rate of production and consumption, not be a straight efficiency increase?

OBSTRUCT_SPAWN - Will this be massively increasing the spawn time of any creeps that are spawned during that time period, or will it apply a temporary delay to creeps already spawning? Will there be a way to programmatically detect that a spawn has been sabotaged? (I remember something about a room event log. Possibly there?)

SHIELD - This still consumes energy? Is this deliberate, or a typo? If it consumes energy, where exactly is the operator meant to get the energy from?

And just to double check, the operator is the only power creep currently being considered for release, correct?

EDIT: Also, we will be able to programmically detect if a room has been enabled, yes?