PTR Changelog 2017-07-20: world shards
-
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.
-
The overwhelming majority would like to have this feature. They also all agree with you that it should be limited in some form or another.
If it's already possible to do in the UI, than it means it's an API call to an endpoint. If it's and endpoint we can also expose some memory value somewhere to just make an API call to do it for us.
We just want to remove this hurdle of Memory -> get memory externally -> set cpu using the webcalls
If we can do it directly, in game, with a proper limit than it won't be an issue for either side.
-
I agree, although I would have phrased it differently from tedv. Please, don't remove what make this game special, because I guarantee it's the clever coding solutions and not the tedious micro.
-
If we can do it directly, in game, with a proper limit than it won’t be an issue for either side.
The limit would be, say, once per day. Do you think it’s fine to have an API call that works only once per day? Considering that it is related to real time, not game ticks at any shard.
-
Once per day is more than enough. Sometimes a shard would require more CPU (massive GCL boosting, preparing for attacks / defenses if needed). If you are using this call you can assume that the player is experienced in their coding capabilities to make proper use of it, as he's already on multiple shards.
-
> The limit would be, say, once per day. Do you think it’s fine to have an API call that works only once per day? Considering that it is related to real time, not game ticks at any shard.
I'm happy with this. While it would be nice for this limit to be more often (four times a day?) I can live with one if that makes it easier for us to get this feature.
It would be nice if the limit could be higher on PTR for testing purposes though. Nice, but not a requirement if it's too complicated to do.
-
It would be a nice touch to make the API call cost a lot of resources in-game as well?
Say we can build resources like RESOURCE_SHARD_CONTROLLER and apply those to our account?
-
> Say we can build resources like RESOURCE_SHARD_CONTROLLER and apply those to our account?
Only if that limit also applies to the UI.
Would the 24 hour CPU allocation limit apply to the UI as well? That would be my preference.
-
Would the 24 hour CPU allocation limit apply to the UI as well? That would be my preference.
Sure. It would be the limit on the web endpoint.
-
I would suggest that the same limit also applies to the UI.
-
I would be fine with once a day (though as tedivm says I would prefer a _little_ more often than that). It's not like I need to do it very often, so most days I probably wouldn't change it. It'd be a strategic resource, kind of like safe mode. If I need more CPU in a shard because I'm under attack, and I reallocate, and then the enemy forks their attack to another shard that I pulled CPU from, tough cookies for me!
I don't agree with adding a resource requirement unless it is a requirement no matter how you call the API, though. Smells too much like an explicit advantage to manual play.
e: sounds like everyone else thinks that too. Cool, sounds good to me.
-
Once a day would be definitely fine for me!
I'd also be open to the UI either matching the limits, or not having them. We can assume someone calling via code knows what they want, and thus apply a limit to them. Via the UI could be a new player just experimenting though (if it isn't heavily warned against), and accidentally assign all their CPU to a shard they're not on.
-
So the safemode thing, plus daboross concern about the new player experience, bought up an idea.
What if every 24 hours we got a "reallocate token", with a max of something like four tokens (and no transfers to other players). There could still be a cooldown between them (30 minutes?), but it would mean that players could at most average a change a day (even though they can "burst") and would make mistakes a bit easier to handle when they occur.
