Game.cpu.generatePixel change
-
Since there is still some misunderstanding, and it continues to pop up in Slack, I'd like to clarify some of my points posted before.
I said that we want to make generating pixels more challenging. Some players misunderstood it (or I misspoke it, sorry for the language barrier) in a way that we want to make it more interesting, and it contradicts the initial statement of a simple balancing change (i.e. a nerf). The misunderstanding was even to the extent calling it a misinformation and lie.
Actually what I meant by more challenging is more difficult, requires more difficult code, a higher entry barrier. It does not contradict a nerf, it is a nerf: the entry barrier was lower, and it should be higher. If we happen to make it more interesting at the same time, it's fine and good, but it's secondary, it's not the initial purpose, and is much less of a priority (at least for now).
The important point regarding this nerf is that we wanted it to be qualitative rather than purely quantitative. If we raised the CPU cost to 9000, or raised decoration pixelization price, it would only change the market value. This is not our intention. Yes, we wanted to increase the value, but indirectly - not by means of increasing some numeric constant, but by means of raising the difficulty level. It should be a complex difficulty nerf rather than a simplistic value nerf (the former though indirectly triggers the latter as well). Even 9900 CPU cost would not achieve this effect. Only exactly 10000 CPU (similar to cancelling intents) poses a new challenge. This change is qualitative.
And the number of players declining generating pixels because of this change just proves this point. It shows how easy it was for everyone to start generating pixels. Because everyone has free CPU leftovers that don't have any value. Lefovers are simply wasted otherwise, they are never used. Generating free income from such no-value freebies is not what pixels are for. Now players are forced to either code to cover low-bucket situation (a higher entry barrier), or consciously dedicate CPU to generate pixels (which is not free and has real value).
I hope this explanation will resolve some misunderstanding that has appeared in the community. Sorry for being not able to explain this earlier. Such discussions and explanations take time (this post took me 1.5 hours to formulate and write) which I didn't have by that moment.
-
@bogden said in Should generatePixel now generate 2 pixels, since it costs 10k CPU?:
So now that people are declining to generate pixels because they don't want to code around the empty bucket case, can we increase the reward to match the previous CPU/pixel generation rate for the people who are willing to code for it?
This is a very interesting idea, we will consider it.
It makes
generatePixelsemantic a bit non-consistent though, since it is supposed to be singular, one single pixel.
-
@Bogden Personally, it would drive me nuts if they did that, especially if the total number of pixels in existence when they did that was an odd number. Knowing there would be an odd pixel out there that could never be redeemed would be aggravating lol.
-
Since emotions are settled down finally, I'm opening the thread again, and moving some relevant posts here to keep it in one place. Please remember to be respectful and stick to the constructive discussion without getting personal, offending and accusations.
-
I just don't understand why you make something a challenge from something what you just can buy with money. Why not create a challenge from something you really have to do and can't buy. It looks like you just want to sell more pixels.
You have always been carefully to not make changes that can break code of inactive or afk players, but in this case you just don't care.
-
@w4rl0ck It's a balancing change. Many new endeavors require balancing over time. 5000 CPU cost turned out to be too small, too easy, too low entry barrier. Again, we don't create a challenge (you again misinterpret this like something interesting and fun), we make it more challenging, i.e. available to less players.
I still disagree it's breaking though. Missed ticks - agree, global resets - agree, less performance - agree, but a breaking change is when your code stops working rather than works suboptimally. Even with global resets every N ticks you still have your code running and your empire living.
If we call breaking a change that changes something that players have optimized against, then we must start calling every change breaking.
-
Well this explains why my code has been blowing up while I was away having a kid. The cost doubled and nukes my code every time it gets to 10k bucket.
This is definitely what I'd consider to be a breaking change that you HAVE NOT made clear in-game, this has gone from if bucket full use half and refil, to if bucket full empty bucket, and halt all code because it's in an emergency refill bucket state.
I'm not sure "set it to max" counts as balancing, but whatever.
I'm officially done with pixels.
Thanks for making that decision easier
-
I got to know about this change by coincidence on slack #general, a week after it was already live. It didn't break my code, so I didn't catch it - but only because I usually use just half of my cpu per tick.
I believe generating pixel should be easy, the 2 liner to generate them is even in the api documentation to make it easy for everyone. An easy way to use wasted cpu is an incentive to waste less cpu. It has been a very welcoming feature for non-optimized users, because a good bot would use all cpu to create more energy or credits. A less advanced bot just has much cpu to waste and can generate pixel easily by wasting less cpu.
I believe there are also not too many pixel. If you try to collect golden decorations, you'll need to spend a lot of pixel. At 13th November I created 312 decorations and got zero golden decorations.
If creating pixel is challenging, then less people care about them at all, leading to the old behaviour to use as much as possible from your cpu with mostly unnecessary calculations. A good example in my humble code base of the optimizations I did after the pixel feature came out:
- towers scan the room only every 41 ticks for damaged structures
- market code runs only every 11 ticks instead of every tick.
- use more reusePath instead of recalculating each path every tick, saves also something.
- collecting room statistics and market statistics every minute instead of every tick.
- disable logging HTML room statistics while I'm offline.
- disable map visuals and room visuals while i'm offline.
- sharing energy across rooms by terminal every 32 ticks instead of every tick.
- more would be possible, but with over 100 cpu saved per tick it has been already enough.
Without the pixel feature, I would still run unoptimized code and I think many other players also optimized their code to create more pixel. No need to make this feature more challenging, it's ok to be an non-challenging incentive for optimization.
-
I'd argue that incentive is still there, it's just a little harder to make use of.
All you really have to do is make sure that you don't exceed your CPU allocation on the tick you run generatePixel or the following tick where you've got hardly any bucket.
Most optimisations tend to be done by remaining bucket amount, which mostly works ok if like most new players you're well under your CPU allocation on almost every tick. To completely avoid resetting yourself you'll need to do a bit of work to check against Game.cpu.getUsed() as well.
-
Oh for goodness' sake guys. Having accounted for the change you announced, and prepared some days in advance, I come back here after seeing errors I couldn't explain (lost ticks), to find that you made a different change and didn't start a new announcement. Lucky this is a game and not something that actually matters...
-
@artch It looks like not all the documentation has been updated.
PIXEL_CPU_COST= 10000
https://docs.screeps.com/api/#Game.cpu.generatePixel shows 10000However, in the game web client. The intellisense in the console is still out of date. Typing
Game.cpu.generatePinto the Console brings up an intellisense completion which reads:fn() -> number Generate 1 pixel resource unit for 5000 CPU from your bucket. CPU cost: HIGH
-
@artch said in Game.cpu.generatePixel change:
Since emotions are settled down finally, I'm opening the thread again, and moving some relevant posts here to keep it in one place. Please remember to be respectful and stick to the constructive discussion without getting personal, offending and accusations.
https://www.youtube.com/embed/AZnTIP9FRdI?start=00&end=22
-
Why would I need an apology? He never got combative, just... not great communication about the desired outcome.
-
@cribbit the second biggest "fuck you" @artch gave was to you personally:
@artch said in Game.cpu.generatePixel change:
@cribbit Please let's don't play words and spam pointless discussions here. It's obvious enough what was meant.
You raised a valid point, and in response @artch raised a middle finger.
-
@tdxtor Keep my name out of your mouth. Thanks.
-
No need to appologize, this is not kidergarden. It's a discussion between adult men aware of a language barrier between them. I believe mutual respect was there most of the way, we all are trying to make things better. Lets use this as an opportinuty to make things better in the future.
This change was meant to be small and non-invasive, but as it turns out it broke some stuff for some people, and, well, if you break a hobby project of another person, they might understandably get frustrated.
I do believe that this project is, whether it was intended or not, more like a "bank" than it was planned to be. Community expects a higher stability level than the developers provide, we can see it quite frequently now and it's becoming a little bit of a consistent pattern. At the same time, I can fully understand that the devs are afraid of a rigid procedure set involved with a highly stable platform as their efforts to grow the game are already sluggish due to very small team and a massive chunk of codebase (which is a different frustration of the community - but that's a story for another day).
The perspective that seems to be missing though is that those two goals are not mutually exclusive - in fact if this is done well, then the development throughput should increase (slightly in the worst case and quite massively in the best case (if crowdsourcing kicks in)). Devs are not experienced in this area, it seems, so discussing it and showing perspectives to each other seems to be the way to go. I was upset personally when the thread was locked, but once I realized the lock was temporary, it actually made a lot of sense. And it worked. I was wrong.
-
@crazydubc I'd love to, but @artch still hasn't apologized and has to be taken to task. Soon enough I'll never have to bring it up again. Sorry to have dragged you into this.
-
@rhef It's not a discussion of peers or anything, it's a discussion between a person whose job title is "communicating effectively and professionally with customers" and said customers. I also feel like if it was a discussion between adults, an apology wouldn't be so hard to coax out of @artch
-
@rhef I appreciate your efforts and engagement in this situation, and also mature attitude in keeping this conversation within boundaries.
Still, it seems you're very new to Screeps. I don't mean to insult you with this, it just means you are not informed enough. I'd like to encourage you to research our previous efforts in crowdfunding (Screeps was crowdfunded from the very beginning), crowdsourcing (many features in Screeps were not only proposed, but implemented by the community) and community interaction. Just ask some veteran Screeps players on Slack, or dig through this forum a bit, and you will see that we are very committed to everything you're saying here. And even while being not a bank, we used extensive procedures of engaging community into drafting, discussing, and testing everything all the way during past 5 years.
In all modesty, I'm confident enough to say that we have enough experience with these things to clearly see both pros and cons for every approach we choose in different circumstances.
And again, I have to repeat, this generatePixel situation is a bit unique due to many factors. This is not how we usually handle things, and I don't think such combination of factors will happen again in the near future.
That being said, once you get yourself familiar with our previous efforts and their results, we will happily listen to any idea how things can be improved in the future, and are open to any constructive discussion.
-
@artch said in Game.cpu.generatePixel change:
Since emotions are settled down finally, I'm opening the thread again, and moving some relevant posts here to keep it in one place. Please remember to be respectful and stick to the constructive discussion without getting personal, offending and accusations.
Glad to hear it. Since you've had time to cool off and compose yourself, are you ready to apologize to @Rhef @cribbit and @CrAzYDubC now?
