PTR Changelog 2017-07-20: world shards
-
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.
-
Once per day seems fine, but I think a option to undo within 1 minute may be good for the UI. It would be a very bad thing to get wrong.
-
Artem, can you answer my questions so I can personally dial down my frustration with your game roadmap
- 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?
if the answer to the first question is that the game scripts should not be fully autonomous - the whole discussion here will go away as surely the people that are trying to create AIs that can play the game will just go do something else cause this won't be achievable here and thus pointless to waste their times
if the answer to the second question is that we should boost our ingame scripts with data imported from the web endpoints - then the discussion goes away as we'll have the answer to how to fully automate the scripts - it'll just require an external server running an off-site version of our scripts
-
It appears having a programmatic API to adjust CPU has already won the day, but I'll add my feedback as another player in favor ideologically of having such an API.
I like the interShardSegment. I trust at some point you will document in more detail what memory model we can expect now that we've effectively got a multi-threaded application with shared memory?
Thanks for all your work, I've been enjoying playing screeps!
-
a option to undo within 1 minute may be good for the U
Sounds reasonable.
- is this a game about autonomous game scripting or a “player” will need to be manually operating it all the time
I don’t think this question is something that should be answered. It’s obvious enough that Screeps is about scripting.
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
Sorry, I can’t seem to understand your question. If you mean “cap” instead of “cup”, then yes, your scripts are capped to your CPU limit. If you try to overcome this limit by offloading some calculations to your own server sending results back to your game script constantly, it might be considered an abusable behavior since it’s not very sporty.
I trust at some point you will document in more detail what memory model we can expect now that we’ve effectively got a multi-threaded application with shared memory?
Please elaborate what kind of documentation you’d expect here? Isn’t it a coding challenge that players need to solve on their own?
-
CPU re-allocation is only a part of the problem here. In order to automate inter-shard colonization, you have to re-allocate GCL levels as well (along with Power Levels when they are released). They are not shared nor synchronized, so you need to explicitly allocate some of your control levels to the secondary shard. We need to come up with such APIs regarding all user account resources, sounds like a major piece of API to introduce.
-
I think we'd love a simple explanation of what's going on with the segment, like by what process it gets replicated between shards and how conflicts are reconciled, so we might better solve the coding challenge.
Whether you want to give us that, or leave it as a mystery for us to work out through experimentation, is totally up to you.
Thanks for listening to the feedback. I'm super excited about this feature now!
-
I think we’d love a simple explanation of what’s going on with the segment, like by what process it gets replicated between shards and how conflicts are reconciled, so we might better solve the coding challenge.
It is simply a shared string (in Redis) that gets rewritten in the end of every shard tick if this shard introduces some changes to it. All shards have access to the same instance of this Redis key. The string is rewritten all at once, so the changes are atomic. Updated the documentation a little bit.
-
> CPU re-allocation is only a part of the problem here. In order to automate inter-shard colonization, you have to re-allocate GCL levels as well (along with Power Levels when they are released). They are not shared nor synchronized, so you need to explicitly allocate some of your control levels to the secondary shard. We need to come up with such APIs regarding all user account resources, sounds like a major piece of API to introduce.
I'm curious why this would be a big project, especially since the APIs to make the actual changes have to get created for the UI anyways. One way to solve it would be a special type of intent that dumps requests into a separate queue would be enough of a change from the game itself, and then a separate microservice that just reads from that queue and makes the changes (if allowed) by utilizing a special version of the API that already has to exist for the UI. This gives the minimum amount of actual game system changes, but I'm sure there are other ways to handle it as well.
-
Can you confirm that all the workers on all the shards will have NTP (or some equivalent time management system) configured (preferably against a local server but at a minimum against the same pools) so that we can depend on the system clocks being pretty much synchronized even across shards?
-
I’m curious why this would be a big project, especially since the APIs to make the actual changes have to get created for the UI anyways. One way to solve it would be a special type of intent that dumps requests into a separate queue would be enough of a change from the game itself, and then a separate microservice that just reads from that queue and makes the changes (if allowed) by utilizing a special version of the API that already has to exist for the UI. This gives the minimum amount of actual game system changes, but I’m sure there are other ways to handle it as well.
Again, I’m not about inner technical workings, let us design them on our own, it’s not a problem at all. I’m more worried about new game APIs that need to be introduced here regarding all and every user account resource. Such APIs should be very well designed, since more account-wide global resources may be added in future.
Can you confirm that all the workers on all the shards will have NTP (or some equivalent time management system) configured (preferably against a local server but at a minimum against the same pools) so that we can depend on the system clocks being pretty much synchronized even across shards?
Yes, they do have NTP running right now.
-
- is this a game about autonomous game scripting or a “player” will need to be manually operating it all the time
I don’t think this question is something that should be answered. It’s obvious enough that Screeps is about scripting.
GREAT! then why having this discussion and trying to disable a feature in the ingame API. We won't have the same heated comments from everyone again when the power creeps are introduced and u limit their usage to some manual intervention, right?
Also, great to hear that importing data from outside via the web endpoints is fraud upon
-
then why having this discussion and trying to disable a feature in the ingame API.
Well, because:
- It is a huge piece of new game APIs that should be thought through and designed future-proof considering new account resources.
- It is going to be used by 0.1% of players.
- It can be used only once per day, thus manual usage is not much harder than scripted usage.
Thus, even we have this on the roadmap, I don’t think we’ll add these APIs on launch.
-
- It is going to be used by 0.1% of players.
- It can be used only once per day, thus manual usage is not much harder than scripted usage.
doesn't matter - the game is about automation so it needs to be there - if not right away - eventually is ok - as long as the game keeps its consistency of allowing our scripts to be autonomous
-
Thus, even we have this on the roadmap, I don’t think we’ll add these APIs on launch.
That’s a really really really bad idea. This game should be about letting your scripts control your environment. If the API call is already there in the front-end, why not utilize this in the backend as well. It can even always return OK as a status, even if it’s currently not OK to change the CPU values. It can even be a call to the endpoint in the backend services as far as I’m concerned.
you have to re-allocate GCL levels as well (along with Power Levels when they are released).
I see how GCL levels would be allocated, how what that get along with power levels? Are power creeps prohibited to travel through shard-portals?
it might be considered an abusable behavior since it’s not very sporty.
This needs further clarification before it becomes a massive pain in the ass to deal with. I’ve moved the discussion of this part to the general forums here: What is considered “Abusive API usage?”
-
Any web endpoint may be changed at any moment arbitrarily, given that the frontend will be changed accordingly. On the other hand, game API should be stable, changing it after launch is a very painful process. It imposes much more responsibility on its design than on the endpoint's design. This is why we can't afford implementing game API by August 3. And we can't delay world shards launch any longer, since there are very few sectors remaining, and expanding the shard0 world again would make the performance even worse.
-
> Thus, even we have this on the roadmap, I don’t think we’ll add these APIs on launch.
You were doing so well right up until this. Come on, please just launch this properly.
-
Sorry, I missed your comment about the August 3rd launch of shards on the real world.
Can you at least commit to getting this out as soon as possible? My concern is that it will be put on a backburner indefinitely similar to power creeps. If you can let us know that you'll work on the API's for CPU usage right away that would help.
-
Artem, if this was reddit I'd give you some Gold. Great job keeping cool while handling the mob.
With respect to the CPU changing API. I'd personally be OK with some pretty ridiculous restrictions if it made the implementation/architecture easier. Call succeeds once per day. It takes up to another day for the reallocation to take effect. Whatever you need to make the API work the way you expect it to be used via the Web Interface while providing us the ability to do it from code.
As for working around the permanence of the API. How about a new object `Game.beta`. The documentation could be very sparse (e.g. just a forum post). Players that want to use it would need to be prepared for the properties of `beta` to disappear at any time. Ideally you wouldn't change the semantics of something once it was added to beta though (we need some sanity).
This has the added advantage of allowing more players to experiment with a new api feature outside of PTR before you need to commit to a permanent api. And the beta concept could be reused easily with future features.
