Game.cpu.generatePixel change
-
@crazydubc Sorry to hear that. To be fair, the 10000 CPU alternative has been discussed since November 25, so it's not really that "last minute". The top post has been updated long time ago as well.
-
To be fair, it was discussed for a while, but then officially announced less than two days before deployment without proper communication, in the middle of a week.
@artch are you trying to say that the announcement and delivery of this change has been executed perfectly and so nothing shall be improved in the future, if a similar change is going to be deployed one day?
Or maybe there is some room for improvement, we'll remember this situation and use this it as a lesson to improve our ways?
-
This post is deleted!
-
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”So I finally found this after having unexpected behaviour for the past few days. @artch top post still says 5000 cpu and cancelling intents, and the Nov 25 post about it makes it sound like a suggestion not the planned update. When are we getting a bigger bucket to accommodate this change?
-
PIXEL_CPU_COST still returning 5000.
Screeps Documentation still lists PIXEL_CPU_COST as 5000.
While this isn't fixed you are breaking people's... trust in you!
(and also incidentally their code)
-
@rhef There is always room for improvement for everything, that's sophistry. What I'm saying is that we always treat breaking changes seriously, and non-breaking changes less seriously. Because we don't have enough resources to run full-scale communication procedure for every tiny change. We only have 4 people in our entire team for both World and Arena, and the community manager is also the game engine developer. Hence the more communication, the less development. We did our best in this case, and I think it was good enough, given how tiny this change was in comparison to the initial intents cancelling idea.
Please don't judge us how you judge big companies with a lot of staff and resources. We're a small indie team, and we cannot follow all the same procedures you got used to in other places. Especially given that it's a game, not a banking system.
-
@tdxtor Oh wow, and this is the real issue here, unlike communication. Sorry for that, fixed now. It should have been deployed together, but somehow got overlooked.
-
@artch said in Game.cpu.generatePixel change:
@tdxtor Oh wow, and this is the real issue here, unlike communication. Sorry for that, fixed now. It should have been deployed together, but somehow got overlooked.
Screeps documentation still lists PIXEL_CPU_COST as 5000.
The communication is a real issue here, you are insulting us by dismissing it over and over again so flippantly. Your SEO is garbage. Google "screeps patch notes" and tell me where you see this thread or a link to this forum. I see links to people asking where to find patch notes, but no patch notes. I see no links to screeps' twitter or slack or discord or forums or whatever on page one of search results.
"Top post still says 5000 cpu and cancelling intents, and the Nov 25 post about it makes it sound like a suggestion not the planned update." You still hadn't decided which tact you would take with the update here https://screeps.com/forum/post/15881 and you only actually announced the change 5 days ago here https://screeps.com/forum/post/15895 but you have lied about it in several posts since.
You failed to communicate this.
Take a deep breath, admit it, then make sure to do better next time.
Because of how badly you did communicating this, people are asking "hey, are you going to do a better job in the future?" and you are just blowing them off when we need a real answer. Also, maybe you should have a tip pop up to let players know this is where they need to be looking for critical update news so they find out 2 days before a change happens, instead of 2 days after.
Next and perhaps more importantly, you used to have a system to buy back your cpu for a fake currency, now you largely don't. What used to be in people's "if(Game.cpu.bucket>9500){" used to be "give the devs compute back in exchange for fake currency so that game ticks can be faster" but now we have to go back to "while(Game.cpu.getUsed()<400){}" so that we are getting our cpu's worth. This slows the game down, make the game less fun for subscribers, and devalues all cpu subscriptions since they will work for fewer ticks (which will cost screeps real money as people unsub).
-
@tdxtor wow on https://status.screeps.com/ you can see some people have already gotten wise and are making ticks longer. Just wait until the devs actually communicate this update to the players.
-
@tdxtor We are definitely going to do a better job in the future, when we become an enterprise-grade service with dedicated QA, SEO, SMM, community management teams, and dozens of full-time employees!
Until then, we're sorry for any inconvenience and thank you for understanding. And don't forget it's just a small niche game for enthusiasts.
-
Also @tdxtor, indiscriminately spamming several negative emoji on each and every my post is not conducive to constructive discussion really. Especially like this middle finger one:
Consider it final warning. One more such offensive action, and you will be banned on the forum.
I'm closing this thread for now.
-
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.
