Game.cpu.generatePixel change

Helam

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.

NobodysNightmare

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?

CrAzYDubC

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.

artch

@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 if condition. Now this decision is a bit more complicated and involves more factors.

Gadjung

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.

CrAzYDubC

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

Gadjung

Also, since most active ppl are preparing for seasonal, this is quite ill-picked timing (and encourages even more abandoning feature altogether by players)

RayderBlitz

@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 if condition. 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.

Gadjung

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

artch

@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.

artch

@rayderblitz @Gadjung We don't consider any challenges that involve world game objects in pixel-related mechanics.

SystemParadox

@artch said in Game.cpu.generatePixel change:

@rayderblitz @Gadjung We don't consider any challenges that involve world game objects in pixel-related mechanics.

That makes sense for buying them and using them, but for generating them that seems like a strange policy.

Also, you are involving game world objects now - all of them. Every single object in my empire has to pause to generate pixels.

Helam

@artch said in Game.cpu.generatePixel change:

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 if condition. Now this decision is a bit more complicated and involves more factors.

This is not like other limitations in the game. Other limitations exist in the game world and the decisions involved are about what your creeps/structures should do in the game world to react to those challenges or limitations in the game world. The whole game is about writing code to make better decisions in the game world.

This limitation or “decision” you want to introduce is very different because it takes you out of the world and you are basically choosing:

Play the game this tick / participate in the world this tick
Don’t play the game this tick / don’t participate in the world this tick

This is not an interesting choice and it seems to go against the very purpose of the game.

I believe many players have written their code in such a way that something useful is happening EVERY tick. I remember watching one of @Mototroller ’s rooms a long time ago and being so impressed that a remote mining creep showed up and moved into place on the exact tick that the previous creep died. It was beautiful in a way. There are many other types of things that can be optimized in similar ways that I believe many players have worked on. Skipping ticks entirely throws a wrench in all of this.

Choices and limitations are good, but I think it is bad if one of the options in the choice is to stop playing the game entirely for a tick.

Yes we can come up with complicated ways of deciding, but it places unnecessary complications on EVERY other part of your code, and still results in nullifying ALL of your code for a tick to perform one small action.

CrAzYDubC

I suspect that this decision isn't about game play, but about how you can purchase pixels for cheaper on the steam marketplace than you can by buying it direct from screeps.

artch

@helam said in Game.cpu.generatePixel change:

Choices and limitations are good, but I think it is bad if one of the options in the choice is to stop playing the game entirely for a tick.

Why stop playing the game entirely for a tick? Take note generatePixel call doesn't cancel your tick, it just cancels your intents, i.e. creeps and structures commands. You still can process data, memory, perform calculations, build caches, make estimations, tune your heuristics. This is totally up to you how you overcome this challenge with maximum efficiency.

artch

@crazydubc It would be very strange if players sold items on the community marketplace for a higher price than the official store, their offer would be quite pointless then

Gadjung

@artch imo idea of wrapping "You still can process data, memory, perform calculations, build caches, make estimations, tune your heuristics" around 'generatePixel()' is quite pointless.

I'm aware that one could do 'refresh all CostMatrixes and all Paths in all rooms' on 'generatePixel()' lost tick, but most (if not all) prefer to do, and is doing that just fine, without losing a tick.

I think i would not be wrong to say that in general, what players DO NOT want, is to lose a tick of intents, especially since gain itself is barely above nil

SystemParadox

@artch can we have some clarification on whether we are still charged 0.2 CPU for the cancelled intents?

I think the answer is going to be yes, in which case you should really make that clear to everyone.

NeyaZayah

I think that the overwhelmingly negative replies to this idea should be taken as a sign that the wrong decision is being made here, even if the intention is pure. And I think it might help to break down the properties of generatePixel as it is now and as it will be if the scheduled change occurs:

AS IT IS NOW:

This is a super boring solution and virtually the only interaction people have with the system -> if(Game.cpu.bucket>9700) Game.cpu.generatePixel();
Hard to balance <- With a bucket limit of only 10 000, the CPU consumed by generatePixel cannot be higher than that.
Economic woes <- It's trivially easy to turn unused CPU into money, thereby flooding the market with both pixels and credits.
CPU woes <- It's trivially easy to stack large amounts of unused CPU.

AS IT WILL BE:

This is a super boring solution and virtually the only interaction people have with the system -> if(Game.shard===ONE_I_DONT_USE) return Game.cpu.generatePixle();
Hard to balance <- With a bucket limit of only 10 000, the CPU consumed by generatePixel cannot be higher than that.
Economic okay? <- Pixels will be far less common, so this is mostly* fixed <- *Not fixed for people with barely-utilized alt-shards; economy isn't actually fixed.
CPU woes <- It's trivially easy to stack large amounts of unused CPU.

It's easy to whine and complain that something isn't how we'd like it, but I think it'll be a lot better for both the players and the game if we explore alternatives; otherwise, this is going to 1) Not actually do what's intended and 2) Become an underutilized feature. I've read through all of @artch's replies to the complaints so far, and I think I've come up with an idea adjacent to what he intends that could actually be interesting for players?

Game.cpu.chargePixel();

It's similar to generatePixel in that it consumes CPU, but different in the following ways:

Consumes X active CPU when called (far less than 5 000; think 100-490; this number counts against "CPU used this tick").
Must be called Y times IN A ROW (X=200 cpu & Y=25 ticks would equal 5 000 CPU consumed total).
Has a Z percent chance that, at the end of the call-series, a pixel is generated (Z=1 would be as it is now; this is your knob for economic balance!).

This function does not create any additional world-objects. X, Y, and Z are variables that can be tweaked for balance or dynamically adjusted to hit a performance goal on the server.

Variable X provides a challenge to the player: Can you operate at -100 CPU per tick for an extended period?
Variable Y provides a CPU-sink for the server: How big this number is will determine how much CPU is removed from the game.
Variable Z provides an economic knob: Too many pixels/credits? Lower the percentage! Too few? Raise it!

Optional extras:

Stun the creeps in a room provided by Game.cpu.chargePixel(roomName) at the end of the call-series? 4.1) Must be a controlled room? 4.2) Number of creeps adjusts the chance of Z? 4.3) Stun the creeps in adjacent rooms? 4.4) Generate extra fatigue for affected creeps during the call-series?
Creeps in a room provided by Game.cpu.chargePixel(roomName) "poop out" pixels with a random chance of variable W? It drops on the floor, and you have to be quick before it decays! <- This could potentially cause some chaos in a person's logistics network that they might be challenged to overcome 5.1) Pixels that exist physically have a timeToDecay of variable V EVEN IF carried by a creep; get it to a terminal/controller fast!
Variable Z could compound with each successive call-series-loop to encourage LONG TERM pixel generation (e.g. it starts at 10% and adds 1% for each call-series, resetting after a time of disuse).
Probably a bunch of other things I'm not thinking of that could make this fun.

In summary: There's a better way to approach this problem that's more fun AND better addresses the economic, cpu, and player-challenge problems posed by the current (and proposed) solutions

artch

@neyazayah So your basic procedure (without extras) is simply calling the same method again and again every tick and eventually gain a pixel. It's absolutely the same challenge as it is now - one line of code. With one if condition for how much spare CPU I have. I don't see how it's more interesting and fun than the current API. And it has the same issue - too little coding effort to get a pixel.