Game.cpu.generatePixel change
-
Starting December 7, due to high-energy pixel continuum bursts caused by
Game.cpu.generatePixelmethod, it will start to cancel all intents registered on the same tick when called. Essentially, it means that you will be unable to perform any game object actions (by creeps and structures) in a tick with aGame.cpu.generatePixelcall. It will additionally consume 5000 CPU when called as before.UPD: https://screeps.com/forum/post/15817
UPD2: https://screeps.com/forum/post/15895
-
Hi @artch
Could you elaborate some more on the reasoning behind this change? I don't quite get why it should also cancel all other intents? What exactly is high-energy continuum?
Are you trying to make people not generate pixels?
-
I would also like to know about the reasoning behind this. So far I get the impression that this is some form of panic reaction to something not going according to plan, which is just as likely to backfire.
-
Just a routine balancing change, no big deal.
-
Is this really the best solution you could come up with to the problem?
Logically this is going to be bad to wire up. And for those of us generating a pixel it means once every 17 - 50 ticks we're going to skip the entire tick and nothing in our entire codebase gets to act?
I understand needing to slow down pixel generation. But this is a terrible solution.
-
This change is awful. It's hard to code around, it's not clear what the reasons even are, and it's a disaster if you're in any kind of combat. We really need changes that encourage combat, not more things to make it even harder.
-
If the issue is amount of pixels generated perhaps CPU cost increase would help; If the issue is delay in generation itself (as in - processing power and database power needed to add such pixel) why not simply delay pixel generation per player, and add internal 'pixels to generate' counter, and instead of generating them one by one, generate them in bulk e.g. every 20 000 ticks? This way system needs to modify the values in database only once every few - few dozen pixels instead of at every opportunity; Pending pixels could also be added as a counter [not usable by players until generated], and generated in bulk once e.g. 100 of them is prepared for generation.
-
I brought this up on slack and it actually got more approval than I expected.
Remove pixel generation entirely and remove the ability to buy and sell pixels on the market. Make it a 100% cosmetic currency that can only be purchased with $$. That's probably the only actual way to balance it. I've been farming credits selling pixels to the point that credits don't matter anymore so you've basically broken your game economy more than it already was.
-
@artch I neither unterstand the initial post nor your response.
What's the problem that you intended to fix? How will this change make the situation better?
Others point to high amount of credit farming, though this is only possible if other players are still in possession of credits. As far as I understood the mechanic, pixels encourage saving CPU, which is good for server cost. Now I am unsure whether I should still generate pixels.
Or whether I should play less Screeps and just generate pixels, then they would not interfere at all, because there are no rooms and nothing else using CPU...
Yeah, I just can't follow your train of thought here at all...
-
I would prefer some other method of limiting it that did not result in a skipped tick. It feels like a breaking change.
Battle in progress? Losing a tick can mean death. Use % on game time to do recurring tasks on an interval? Might get skipped. Optimize your creep size and spawning to arrive just-in-time for when the previous creep would die? Now it won’t get there in time because you might lose some actions along the way.
There are probably several other cases that I cannot think of that might break from this. With this change it seems the best action to prevent breaking is to stop generating pixels completely. I realize the cases I mentioned can be coded around but it seems to be a glitchy requirement to have to consider.
-
There is no "problem" we are trying to fix. Quite the opposite, we want to create a new coding problem here for those generating pixels. We want to create more coding challenge in it besides simple CPU consumption.
We understand some may get upset since more coding efforts now should be put to continue generating pixels. But this is exactly the idea. Challenges are fun!
-
I agree that more challenge should be introduced for generating pixels, but I wish it was challenge added into the world of the game, not an arbitrary limitation that will take away from other parts of the game.
Make us interact with something in the world to generate them, put them inside walls so we have to tunnel to it, make us cooperate somehow to get them. Give us new things to do in the game world, don’t make everything existing more difficult for this.
Or you could even bring this limitation into the game world and localize it so we generate the pixels in a room, and that room loses all actions, that way it could be used more creatively and without causing headaches for all of your code everywhere.
Not all challenges are fun. This one does not sound fun to me.
-
I agree to Helam.
In my initial steam review of the game I wrote something like “all the problems are REAL coding problems“ and how I liked that. I.e. The game mechanics make sense and all that's left is coding.
This challenge sounds not fun, but like integrating with a weird vendor API at work.
Also a winning way around this mechanic is giving up the game, which you should not encourage. I.e. If I do not care about creeps getting anywhere and if I do not care about maximum map coverage, then I will just go for three rooms, keep them alive and defended and generate pixels, filling my Steam wallet with money to buy other games. Why would you encourage that?
-
Welp, I guess I am going to ignore pixels entirely. This is, respectfully, a stupid decision. Losing 100's of intents plus the energy that comes inherently with those intents just took pixels off the table in my code and I will be commenting out that function.
-
@nobodysnightmare said in Game.cpu.generatePixel change:
In my initial steam review of the game I wrote something like “all the problems are REAL coding problems“ and how I liked that. I.e. The game mechanics make sense and all that's left is coding. This challenge sounds not fun, but like integrating with a weird vendor API at work.
I don't agree this isn't a real coding problem. The limitation is artificial, but so are any other gameplay limitations in the game. This limitation forces you to think what you would like to perform on this tick - game actions or pixel generation. And now the real coding problem is how to decide this. How to predict what is the best tick to call generatePixel. The criteria was very simple before: run it whenever you have spare 5000 CPU. It's just one
ifcondition. Now this decision is a bit more complicated and involves more factors.
-
in the end i see that it will result with ppl dealing with this by doing
// Game.cpu.generatePixel()Generating pixels was mostly a credit maker, and I really doubt ppl will want to refactor codebase to make it not get broken by implementing workarounds for new logic.
Also it's quite impossible for ppl that are combat-active to use this feature because of skip-a-tick.
-
What @gadjung said.
You either generate pixels for credits (like anything else in the game), or because you want to collect decorations.
IMO, it is easy to generate pixels and to use them (minus some severe limitations that don't allow you to generate decorations via code). The challenge is getting those rarity 4+ decorations and not a bunch of level 1 vendor trash.
Here are a couple of ideas.
- Allow decoration generation from pixels and recycling via code.*
- Allow you decorations and their attributes to be accessed via code.*
- If the concern is too many pixels being generated, you can then only allow them to be generated with a cooldown or other measure.
Pausing code to generate a Pixel kind of defeats the purpose of having an automated bot and I will be selling off all my pixels and decorations and commenting out the code. After all, they are just decorations and does nothing functionally.
*this will incentivize more people to actually use pixels
-
Also, since most active ppl are preparing for seasonal, this is quite ill-picked timing (and encourages even more abandoning feature altogether by players)
-
@artch said in Game.cpu.generatePixel change:
@nobodysnightmare said in Game.cpu.generatePixel change:
In my initial steam review of the game I wrote something like “all the problems are REAL coding problems“ and how I liked that. I.e. The game mechanics make sense and all that's left is coding. This challenge sounds not fun, but like integrating with a weird vendor API at work.
I don't agree this isn't a real coding problem. The limitation is artificial, but so are any other gameplay limitations in the game. This limitation forces you to think what you would like to perform on this tick - game actions or pixel generation. And now the real coding problem is how to decide this. How to predict what is the best tick to call generatePixel. The criteria was very simple before: run it whenever you have spare 5000 CPU. It's just one
ifcondition. Now this decision is a bit more complicated and involves more factors.I can't disagree more. Yes, technically you're right, but you're forgetting about the most important factor in all this: value to the game, reason to participate, merit (fun) in the mechanic. Focusing my codebase's features around one incredibly negligible factor is not fun, I'll either just ignore pixels from here on out or buy them off the market from players who most likely just stopped playing the game because of (/for) pixel generation. "[A] limitation that forces you to think what you would like to perform on this tick"? "Now this decision is a bit more complicated and involves more factors"? Well, let me just get my unused cpu active on another shard and slap an
if (Game.shard.name == "shard1") return;
at the top of my main loop after the pixel generation statement. Again, this really does not add anything of value or any challenge to the game - especially because you can just cheese it like that. What I would like to see instead is an actual challenge that doesn't reek of friday night hotfix deployment, but is actually thought through.
What could this be? Well, for example making pixel generation a chance based on certain factors and the player has the challenge to increase the odds of success. Another could be that there are chances of increased or decreased cpu cost when generating and the player influences that in some way.
Another way is a more far reaching effect on the actual game world as has been proposed by others. Make players dedicate a room to it, or make players gather it season 1 style. There are many ways to make players work for it and even making this a breaking change of sorts without it just being a purely frustrating change devoid of substance.
-
one idea i floated on slack :
at cross-highways there's structure to which creep needs to go with X resource/Energy, use generatePixel() and that uses resource and bucket. goes within theme of game, introduces new challenges and mechanics within game framework, like defending / blocking said structure and makes idle pixel-farming harder
-
@gadjung said in Game.cpu.generatePixel change:
in the end i see that it will result with ppl dealing with this by doing // Game.cpu.generatePixel()
We're fine with less people generating pixels now. This is expected and will drive pixels price higher for those who actually manage to overcome this challenge.
