PTR Changelog 2017-07-20: world shards
-
> This way every shard should gain knowledge about every other shard in the cluster. Too tight coupling, we want to avoid such architecture. Do you think interShardSegment is too hard to use? What other people here say in this regard?
I think it's too hard to use due to the disconnect between Game.time on each server as well as the race conditions that could occur if two shards write to things. It adds a whole lot of extra complexity into the system.
What if instead of all of the shards having automatic access to each other shard the code can request it (similar to requesting a foreign segment from another player)? This could potentially make it less tightly coupled.
Another option would be to add another piece of data- perhaps a second segment- that can be used as a control segment. Part of the issue right now is that a proper lock or semaphore system is impossible since you only one source to write to- the simple act of writing a lock could potentially clear data that was added from another shard.
> Will there eventually be a programmatic way to set this, rather than just the UI? This will be pretty important for automation.
> Not planned currently.
I, and pretty much everyone in #automation, is going to have a serious problem with this. I should not have to babysit my computer 24/7 to manage shard CPU, and I should be able to do things like push CPU to a shard where I am under attack from one where I am not. This is yet another situation where people who babysit the game will have a huge advantage over people who do not, and of course it means bots on private servers will not be able to use multiple shards. Please reconsider this, as I think it's a huge mistake that this isn't in the roadmap.
-
Personally, I've already worked out a way to handle the interShardSegment limits, its just going to be a pain and slow to sync any data.
The CLAIM issue means that there are going to be many players who don't have the ability to reach any claimable rooms in the other shards purely because they either 1) don't have a border room or 2) are too far away from a portal that leads to a claimable corner.
I've already tried claiming a few other rooms, but have been unable to reach them with CLAIM due to TTL reduction.
-
I do think the lack of an in game API for CPU control is more important than the segment issue, for what it's worth.
Some ideas came up in slack for alternatives- for instance, give all players a minimum of 30cpu on each shard, and then balance the rest of the CPU based on proportion of claimed rooms. However, I'm guessing that'll be too tightly coupled based off of the comments you had about segments.
-
What if instead of all of the shards having automatic access to each other shard the code can request it (similar to requesting a foreign segment from another player)? This could potentially make it less tightly coupled.
This is an option, but it introduces more complexity to this mechanic. Let’s see how it goes with
interShardSegmenton the PTR. I suppose all what you have to implement is some mutual locking mechanism based on real time, not on game tick. Shouldn’t be very hard to come up with.bots on private servers will not be able to use multiple shards
Private servers aren’t going to have shards support at all (at least officially).
Please reconsider this, as I think it’s a huge mistake that this isn’t in the roadmap.
Shards resources (not just CPU, but also GCL, Power Levels, Pixels, etc) are entities of higher order than those that your scripts are operating with. Giving an ability to allocate shard resources using the game API is similar to providing an ability of, say, changing your badge or email via the API. It is related to your account and should be set up by user, not by user’s script through an in-game mechanic. The shard itself knows nothing about the multi-shard environment it exists in, similarly to how it knows nothing about other user metadata like emails.
That being said, you can always use our web endpoints (they will get official Web API keys soon) to act on your behalf if needed.
-
> Private servers aren’t going to have shards support at all (at least officially).
That's disappointing, but I'm pretty sure it'll end up with unofficial support at some point.
> Shards resources (not just CPU, but also GCL, Power Levels, Pixels, etc) are entities of higher order than those that your scripts are operating with. Giving an ability to allocate shard resources using the game API is similar to providing an ability of, say, changing your badge or email via the API. It is related to your account and should be set up by user, not by user’s script through an in-game mechanic. The shard itself knows nothing about the multi-shard environment it exists in, similarly to how it knows nothing about other user metadata like emails.
To me this just says it's a challenge, not that it's impossible. Perhaps a special "intent" which literally just makes a call against the API you're building would resolve this. The shard doesn't need to know about the multishard environment in any way that can't be managed with the shared segment (for instance, if there are ten shards and I'm on three of them I should be able to figure that out in my own code without needing assistance from the game engine, which also means I should be able to make the adjustment from the shard with all the info I have).
`setShardCPU({shard1: 50, shard2:30})` on shard1 triggers an intent for changing data. The engine sees that intent and (for performance reasons) dumps it in a separate queue, and that queue gets processed and literally just makes an HTTP request against the API you're already building. Sure there may be some lag between when the command in game is sent and the CPU gets allocated, but I think that's pretty fair.
-
re: CPU -- it would be nice to be able to set this in script. To avoid excessive synchronization maybe have one shard be a CPU-master (whoever claims that status first) and be able to allocate CPU for own and all other shards. If script wants another shard to be master, current master must relinquish the status first.
re: segment sync -- there absolutely needs to be a way of synchronizing this, currently I don't see a way of writing into it from more than one shard. At the very least we need 2 independent segments as tedivm said.
-
I meant it's more of an ideological restriction than technical. Such things should be changed via Web API, not via Game API.
-
> I meant it's more of an ideological restriction than technical. Such things should be changed via Web API, not via Game API.
Why? Why should players who babysit their computers be given an advantage over players who focus on automation- what is the "ideological" reason for that?
-
Shards resources (not just CPU, but also GCL, Power Levels, Pixels, etc) are entities of higher order than those that your scripts are operating with. Giving an ability to allocate shard resources using the game API is similar to providing an ability of, say, changing your badge or email via the API. It is related to your account and should be set up by user, not by user’s script through an in-game mechanic. The shard itself knows nothing about the multi-shard environment it exists in, similarly to how it knows nothing about other user metadata like emails.
That being said, you can always use our web endpoints (they will get official Web API keys soon) to act on your behalf if needed.Is it only me or this answer doesn't make any sense at all - "higher order" or not, your CPU availability matters to how your script can play the game - changing the badge, email address and so on doesn't have any significance to the game itself and can be done manually or not at all. And the "shard" (if it matters at all) knows about the multi-shard environment - it has portals to the other shards - it's not like these are separate servers, but something that, at least i think we are, trying to make work altogether.
So in the end you want us to write a 3rd party script to send data between the shard. If not already, at the near future, that mechanic will be used to do any heavy processing or preprocessing outside of the game thus bypassing the CPU limit and making it uneven for anyone who doesn't do that.Again, don't know if it's only me, but these 2 points seem really really wrong and totally not in the direction i want the game to be heading
-
For the record, I agree with artem on the seperation of user and engine data
@unfleshdone theres a few easy ways to handle interShardSegment, one I'm thinking of is just a hash list of timestamps when each shard updates, then only the lowest timestamp is allowed to write
-
ags131 - can you provide actual reasons for that? What about the game play is improved by this distinction?
-
@tedivm currently the engine is in 3 very distinct parts:
- storage (db/redis)
- backend (API endpoints + websocket)
- engine (in 3 sets of modules,main(master), runners (usercode), and processors(intents))
While backend and engine share access to storage, they do not have ANY direct ties, and engine only ever writes world state(Objects, memory, etc) within storage, never user state (Such as code, badge, email etc).
This is a good example of seperation of concerns in action, only the backend is allowed to modify userstate, and in limited cases such as for construction, submit intents for the engine to see. The engine never modifies user state and only sends back 'update' events for world state changes the backend subscribes to.
-
I don’t see a way of writing into it from more than one shard. At the very least we need 2 independent segments as tedivm said.
There are a lot of ways of writing into it from any number of shards. It’s a coding challenge of how to implement it effectively. I recommend some reading about mutexes to get more info on the matter.
Why? Why should players who babysit their computers be given an advantage over players who focus on automation- what is the “ideological” reason for that?
Those who babysit their Screeps gameplay will be in advantage in much more serious ways than CPU allocation. It’s how online games work, no matter how much we wanted the opposite.
And the "shard" (if it matters at all) knows about the multi-shard environment - it has portals to the other shards - it's not like these are separate servers, but something that, at least i think we are, trying to make work altogether.
Portals to other shards are just string properties with the shard names. Database for shard1 contains a portal with
shard0string in it. No metadata from the shard0 database is fetched into the shard1 environment.So in the end you want us to write a 3rd party script to send data between the shard.
You can transfer data between shards without any 3rd party tools.
RawMemory.interShardSegmentis the only API you would need for that.
-
> Those who babysit their Screeps gameplay will be in advantage in much more serious ways than CPU allocation. It’s how online games work, no matter how much we wanted the opposite.
That doesn't justify making the situation worse. I still don't understand the "idealogical" reason for purposefully crippling players scripts here.
-
Not just that, but the stuff around making power creeps be UI only without programatic controllers just highlights this discrepancy. In a game about coding an independent AI (and thats what makes this game special, not any sort of micro) I feel it should always strive to not require the user's control.
@artem
Btw, are you considering having power creeps on a shard before they are brought to the main world? I think that would be a great way of implementing them as an opt-in testing experience. Just make power creeps not able to use shard portals and let people duke it out and find all the bugs there. Also give a limit to the amount of power you can use in the shard and a lot of the concerns about a level playing field fall away.
-
There are a lot of ways of writing into it from any number of shards. It’s a coding challenge of how to implement it effectively. I recommend some reading about mutexes to get more info on the matter.
Ah, I guess the write itself is at least atomic and all shards will be presented with consistent state at all times (which one being undefined), so a lock is easy to write. I was imagining partial writes and other horrors. Nevermind then, sync is not a problem.
-
@ags131 - since Artem already said the reasons were idealogical, not technological, your response doesn't seem relevant to the conversation. I asked what idealogical reasons you agree about here.
I'm also confused how your separation would work with power creeps. Do you not think that players should be able to programmatically design power creeps? If you do think that should be allowed why are you making an exception for them but not for CPU time?
-
@tedivm The idealogical reason (at least in my mind) is for seperation of concerns and design. Right now, with shards, there are theoretically infinite engine world states sharing one user state, if every engine decided to start modifying userstate, that breaks the whole concept of them being seperate.
I do agree that power creeps should be designable programatically, to me, they should be spawned exactly like a creep, but with a 'level', and point allocation (Eg: `{ [POWER_KILL]: 4, [POWER_TELEPORT]:1 }` to make them entirely world state. The UI could still work by just submitting the UI customized intent similar to construction sites.
-
My two cents on being able to control CPU distribution from game code:
One of the things I would love to do with my AI is implement nomadism; code is always looking for new homes, never keeping a room for too long, exploring and finding new neighbors to interact with, whether the result is friendly trade, unbridled conquest, or crushing defeat. It sure would be nice to be able to have my code opportunistically expand into a shard without having to check on it myself, carefully evaluate the CPU / GCL allocated to each shard I'm currently on, and manually redistribute based on how much I think my code might want there.
-
> Shards resources (not just CPU, but also GCL, Power Levels, Pixels, etc) are entities of higher order than those that your scripts are operating with. Giving an ability to allocate shard resources using the game API is similar to providing an ability of, say, changing your badge or email via the API. It is related to your account and should be set up by user, not by user’s script through an in-game mechanic. The shard itself knows nothing about the multi-shard environment it exists in, similarly to how it knows nothing about other user metadata like emails.
I don't know how to say this less aggressively, so sorry for this, but: how can you be so wrong about your own game?
Let's start with this:
> Giving an ability to allocate shard resources using the game API is similar to providing an ability of, say, changing your badge or email via the API.
No. My code can't see my email or badge at all. They do not affect my code's gameplay in the least. No matter what my badge looks like, or my email is set to, it has no effect whatsoever on the game. Allocating shard resources heavily affects the game.
> It is related to your account and should be set up by user, not by user’s script through an in-game mechanic.
No, it is related to my AI. My AI already knows about the amount of CPU allocated to it (currently, 100%, of course) and its own GCL.
> The shard itself knows nothing about the multi-shard environment it exists in, similarly to how it knows nothing about other user metadata like emails.
The shard itself is the server I'm playing on. It's not my AI. After the shattering, my AI will be a distributed system. It will exist on multiple shards. Crucially, it will be able to communicate between those other instances of itself using the shared segment. From here it is utterly trivial to compile a list of the shards I am running on - all I need is for a list of shards to be in the segment, and every tick my AI reads the list, checks its own shard name, and if it's not on the list, adds that shard to the list. Now I have a list of shards I'm running on. I know quite a bit about the multi-shard environment I exist in.
I still don't know anything about emails, of course, because emails aren't related to the game in any way.
I also can learn about new shards that I'm not running on simply by scouting portals. And that brings me to my main point:
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. If my code encounters a portal to a new shard, and it would like to expand across to the new shard, without an API the best my code can do is literally send me an email so I can log into a web UI and alter allocations. This is utterly ridiculous. It's completely against the spirit of this game. You have just caused emails to actually be a gameplay mechanic! My code has no way to get into a new shard without emailing me!
A similar argument applies to power creeps, of course, but this is even more ridiculous. You give me a single segment to write to and manage mutexes in, claiming that it makes your AI code more interesting - essentially handing me a distsys problem to solve on a platter - but then you decide that I shouldn't be able to manage the distributed system that is my AI programmatically? What?
I hope you reconsider. There is a significant difference between "Of course people who babysit the game will have an advantage, it's just a law of physics" and "We are specifically coding this in such a way that people who babysit the game will have an advantage because we will make it impossible to use this feature any other way."
