PTR Changelog 2017-07-20: world shards
-
"@ags131: what @kotarou was asking is, if I send a creep over to the other shard, do I need CPU allocated there to be able to control it?
I can't imagine it working any other way. Which is my point. I can't send a creep through a portal I just discovered. I have to wait until my caretaker allocates CPU (or GCL) to that shard. And I don't have any way to know when that has happened (at least, no in-game method - of course my caretaker could have written some values to memory.)"
Honestly, I'd be fine with a base 1 cpu per tick in each shard but a capped bucket of 100cpu unless you allocate account cpu to it. Have a players code only run if you have something in that shard. That way if they wander into a shard they have a bit of a grace period to move around and/or allocate cpu. It also lets you explore a shard without having to move your allocations around.
-
> ...move off the portal?
This is what I was responding to, the creep will NOT be on a portal
-
> Honestly, I'd be fine with a base 1 cpu per tick in each shard but a capped bucket of 100cpu unless you allocate account cpu to it. Have a players code only run if you have something in that shard. That way if they wander into a shard they have a bit of a grace period to move around and/or allocate cpu. It also lets you explore a shard without having to move your allocations around.
Maybe a base 10 instead? With base 1 you can never refill your bucket, which means you won't be able to run `require` statements on your code after a certain point.
-
10 seems fine if it doesn't cause any concerns on their side. Plenty of 10cpu players would be happy suddenly getting a lot more too.
But really, I don't think they should be running every single main world player's code each tick on all the shards. I think it should only run if you have something there.
Hence why 1 cpu would fill a bucket if no code is running. It would also limit outsourcing code requests to shards you are farming cpu on because you would need a physical presence in the shard to run the calcs. If you didn't require it you could just use the 10cpu to farm up cpu and run a bunch of calcs.
-
Thats one thing about it, IF its purely allocating GCL points and not CPU directly, you can just allocate 1 GCL to each shard, bam, instant 20CPU(?) available on each since each would effectively be at GCL1. That or maybe give 1 'free' GCL point per shard that cannot be allocated away.
-
> But really, I don't think they should be running every single main world player's code each tick on all the shards. I think it should only run if you have something there.
Currently (as in right now on PTR) if you do not have at least one creep or a claimed room (possibly just the structure) then your code does not run.
-
Then why wouldn't a 1 cpu base allocation work? It should still fill a player bucket up. Nothing against 10 but curious since you mentioned it wouldn't work previously.
-
bucket doesn't build if your code doesn't run.
-
Really? Because when we skip ticks etc I thought your bucket filled up.
-
I just double checked in the source to make sure I'm thinking of this right, when skipping ticks, your user is kicked out very early. When you have no objects, your user also exits out early before the bucket is updated. With shards, each shard is effectively its own seperate server, so if you have no creeps, structures, or rooms, you have no objects, therefore it exits out early.
-
Hm good to know, definitely not impossible to change if they decide to go that route.
-
How about adding a 100 CPU CONST cost to the API that requests the change in CPU allocation?
-
To play off of ags131's suggestion, what if it worked like this-
* 20 cpu automatically on any shard that has activity (creeps).
* 10 cpu for each claimed room on a shard.
* Extra CPU split proportionally among claimed shards (shards with claimed rooms).
This would make sending creeps to explore new shards much easier and would remove the manual aspect from the game altogether.
-
Biggest problem is that requires a central location tracking room counts in each shard, with the current design, that adds a lot more extra data to track and more update queries.
If its done by user allocating GCL points though, it could easily function identically without relying on trying to keep track of room counts on every shard
-
> Biggest problem is that requires a central location tracking room counts in each shard, with the current design, that adds a lot more extra data to track and more update queries.
> If its done by user allocating GCL points though, it could easily function identically without relying on trying to keep track of room counts on every shard
Instead of building it into the existing system I think they should have a separate "shard" microservice. Using the already existing API that service can run through a queue (lis of active users), request the gcl and number of rooms for each user, and then issue the new CPU levels. They already are planning to add the CPU to the API, and once that is done this service should be able to do everything that's needed without making additional modifications to the main system. In fact, regardless of the actual algorithm this is probably the best way to handle it. From an architectural standpoint this microservice can also handle reading and writing the shard segment(s).
-
never mind of how the technical part is actually done, i'm still concerned about my 2 questions not being answered:
- is this a game about autonomous game scripting or a "player" will need to be manually operating it all the time
- is the CPU limit a cup for the scripts and balancing for the players or the available server resources and thus distributing some of the processing time to an own server and just sending the data back via the API is the way the developers see the game in the future?
-
I currently agree with the players. We must get an API to control the CPU that is available to us! Same with the GCL room count.
I also agree that these calls (however they will be implemented) should get some form of limit to prevent abuse. Once per hour should be more than enough.
-
If you don’t let us dynamically allocate CPU to different shards, then claiming a room on a new shard will always involve user intervention.
Exactly, this is the whole point here. Think of it as a respawn action which always requires manual first room choice. Creating inter-shard colonies are not supposed to be automation-able. You hear about the new shard opened up, you go the game, investigate your options, allocate some CPU to the new shard, and either respawn there or write your colonization script for this specific shard. Full automation is only achievable for in-shard operations, but inter-shard activities are like registering your account at different "shard servers" which we’d like to keep manual.
As to responding to attack with adjusting your CPU, it may be even considered an abuse. We most probably will rate-limit this web endpoint to prevent this. You shouldn’t be re-allocating CPU too often, it might break server-side optimizations of all sorts (especially when
isolated-vmis implemented).Game.cpu.limitis supposed to be very stable. Without shards, it is changed only once per week or two when you get new GCL. With shards, it shouldn’t be allowed to break this principle.Are we going to be allocating CPU directly? LIke 25 to shard0, 20 to shard1, 45 to shard2
You allocate CPU and GCL levels directly (not GCL points).
-
Trying to think of a compromise here.
What would both sides think of a function `setCpuBalance({'shard0': 0.2, 'shard1': 0.8})` that's callable at most every 1000 ticks per server, and takes up to 50 ticks (on the slowest server) to 'activate'?
The timeout/delayed affect could significantly ease the burden of synchronization, and if it came into affect on servers where the limit was lowered *before* it came into affect on servers where the limit was raised, this could also avoid all abuse.
I would also think the delayed nature would set this function apart from regular game functions, and make it clear it's a "meta" capability, not to be used often.
-
It's not a respawn action though. This is ridiculous, we have all the pieced in place for this to work the way a bunch of people would prefer it to work except one. How about you just listen to your customers instead of trying to impose this idea that the programming game you made should require human intervention for things. The whole point of this game for many players is the fact that we can program it, so making that impossible despite the fact that far more people are asking about it is pretty much a slap in the face to your fan base.
Seriously, look at the three pages of comments here. Most people want this feature, and by removing it you're taking what should be an awesome rollout of a new feature (shards) and replacing it frustration and anger over your decision to essentially dumb down the game for idealogical reasons.
