PTR Changelog 2017-07-20: world shards
-
- 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.
-
I would definitely be fine with any restrictions for architecture reasons. I do think it shouldn't be given huge penalties or delays "just cause". A huge part of the draw of this game is finding out clever ways to push things to the limit and gain an advantage over other players. The more restrictive it gets, the less room for innovation.
-
There seems to be some kind of major bug with memory segments in shards. I sent a creep over to the new shard, and as soon as it appeared, I started seeing all kinds of memory segment related errors on the main shard. I haven't narrowed it down, but it appears my code on the new shard was writing to memory segments which ended up overwriting data in the main segment, which caused chaos on my main shard since I use segments for storing all my room layouts and other important information.
-
> The string is rewritten all at once, so the changes are atomic. Updated the documentation a little bit.
Thanks Artem, that was exactly what I was looking for.
A few thoughts on the rest of the thread...
a) I still agree ideologically having an API to do anything that could be done in the UI and affects the outcome is the right goal to strive for, but happy to accept there are practical limitations in getting there.
b) FWIW, there might be some options in the design space here that are automatable but don't need new APIs or UI re-allocation? For example move a creep through a portal into a shard that has none of your creeps yet and 10 cpu automatically shifts there from the shard that has the most CPU. When all creeps/buildings are gone from a shard for 24 consecutive hours the CPU shifts back to the shard with the most CPU. For each controller claimed after the first another 10 CPU shifts. I'm sure there are many other variations if folks like the idea of driving it with a game mechanic but not this exact mechanic.
-
https://cl.ly/181j412A1q0x/Image%202017-07-22%20at%2011.32.42%20AM.png
I like that idea, but of course I would, I'm a 10 CPU player.
-
Yeah, it definitely helps the 10cpuers (although you'll have to manage getting to the second segment for that to work). However, I think it will make the game far more playable if everyone gets the 10cpu minimum on every shard by default.
-
What happens if a creep joins a shard and it has the same name as another creep already on that shard?
-
> I like that idea, but of course I would, I'm a 10 CPU player
Referring to my idea above? Not that I am attached to that particular scheme, but I don't think that one gave any favor to 10 CPU players in my head (sorry!). Left unspecified was that shifting CPU from shard A to shard B only works if shard A has the CPU available to give. For a 10 CPU player after your creep crossed the portal you would have all 10 CPU in the new shard and no way to get more (without subscribing).
-
> It can be used only once per day, thus manual usage is not much harder than scripted usage.
I like the once a day limit, but I have a large objection to this statement: this is not about ease of use.
If people wanted an easy game, there wouldn't be GCL1 players who are working on automatically placing buildings before they build remote mining. The appeal of this game, to many, is that a player can give themselves the challenge of doing _everything by script_.
I mean, the point of practically any game is to introduce challenge - that's what's interesting. For some screeps players, those who are newer to the game, to programming, or have less time, the challenge is simply getting a programmed AI to work at all. For the more experienced players, or those who have more time to play the game, the challenge is making an AI which operates and makes all decisions independently.
I think in your analysis of the situation, you are disregarding the second type of player. I'd count this as unwise - even though they do currently represent a minority, it's far more than 1%, and as more players become more experienced, the balance will continue to shift towards more and more players having full automation as the goal.
This is the reason there are so many players objecting to introducing the API after the feature. If you do this, you're essentially telling these players: either give up on the challenge, or you can't use this feature (shards). It's not about how easy it is, it's about allowing for this extra level of the game you created to exist. Letting people choose to challenge themselves more.
-
Also, a lot of the fully automated players or players getting close tend to be very helpful in the slack channel. (my opinion is quite biased)
-
I'm a little late to the party, but I just want to throw my 2 cents in.
I also strongly believe that all game relevant actions should have an API allowing the game AI to run fully automated. This is a game about automation.
It should not be necessary to develop web services to control the game.
CPU and GCL are relevant game resources. Their allocation should be possible to manage from within the game API.
It is fine to restrict this whichever way is necessary, but an API should be provided.
I also strongly believe the same should be applied for the future implementation of power creeps.
-
I started two new threads to break off some of the conversation-
A discussion of minimum cpu on each shard - http://screeps.com/forum/topic/32/Shard-Request-Minimum-CPU-on-all-shards
A request for reduced TTL lose during shard travel - http://screeps.com/forum/topic/33/Shard-Request-Reduce-TTL-Penalties
-
The discussion is moved here.
