3. What is considered "abusive api usage"?

What is considered "abusive api usage"?

  • Culture

    In the PTR post 

    http://support.screeps.com/hc/en-us/community/posts/115000604154/comments/115000847733 

     

    there was mentioned that some use of the API is considered abusive. To what extend should we think about this?

     

    I think we could place this into categories:

    1. Doing actions in game (placing construction sites, moving creeps, etc)
    2. Performing pre-calculations (path-finding, flow fields, external memory manipulation etc)
    3. Reading from the API to get game data (stats gathering, profiling)

     

    If anyone has other ideas about categorizing the abusiveness I'd love to hear it as well.

    Please beware that this should not become a blanket statement. All abuse cases should be reviewed on a case-to-case basis.


  • When we discussed the Terms of Service and multi-account play previously I was heartened by Artem's response, to paraphrase: there are no new rules other than the rules as written but don't try to circumvent these rules with code.

    1. Offline command execution should be ok because of the 2 levels of uncertainty: the results of the correct context for a command are not knowable by an external script, and commands are not executed until the following tick. This means at minimum a 2 tick latency for commands.
    2. I consider offline training of an AI to be a primary motivation for experimenting in this game. Getting that AI to perform well is a challenge because of the limitations placed on user scripts: limited CPU and 12MB of persistent storage. Offline pathfinding is hardly an issue and using it is just a crutch which limits the abilities of a script.
    3. information leakage is the most significant use of the web API "not as intended" by the developers and the thing I think we should be addressing.

    Already we have both public and private services which scrape the web API in order to gain new information and reveal tactical information about the game world. Some of these services mirror functionality which could be gained by having a large network of allies in the game, but other services can remove gameplay constraints and provide an advantage which can only be repaired by hiding information from the best advertisement for the game: the ability to spectate the living world.

    I propose that communication creep population from the web API and introducing this information to the game without human intervention should result in a ban. I don't think that any other data tool like portal or markets is as threatening to the core gameplay as unlimited visibility of creeps on the map.


  • This is a difficult subject. I personally prefer that all my interactions with the game world be through the game's internal API. Using websockets has felt like an unfair advantage.

    Briefly, after the end of WW1, I implemented a service for SUN which provided a host of tactical information. It provided portal details, player resource levels, alliance resource levels and historical data on each point. The advantage this would have provided at the alliance level felt too great so I scrapped the service.

    With this new round of intense conflicts, I've managed to find somewhat of a middle ground. I've decided to follow the Culture's lead and create such services fully open (code and service wise).

    This resolves the moral dilemma for me quite cleanly. I do intend to develop ws based tools/services in the future but will make them public and accessible to all.

    Fundamentally though, I would prefer if the use of ws is carefully regulated and limited.

  • YP

    Maybe some information should be removed from websockets (and the client) in the future .. like visibility in other players room. Is it really necessary that you can check tower / terminal / link / container contents via the client for foreign rooms for example? maybe that could get linked with visibility.


  • I think it is important to mention that this is a game for developers (or aspiring ones). Offering such an API, it must be assumed to be used. And finally this means it becomes/is (an advanced) part of the game.
    This would mean there is no such thing like abusive use, except when using exploits or the like.

    But I’m unsure as well if this is what game developers had in mind when creating the API or if its consequences could be foreseen. It can give very powerful advantages.
    So I am with W4rl0ck – maybe we need a discussion about what should and what should not be possible to do with the API in terms of what it offers. What may be too powerful at all. What needs sensitive limitation. Some things may be missing as well. 
    But I wouldn’t call using powerful implementations of given functions abusive, as it has that “illegal” touch. I’d consider it more like Atavus calls it “unfair”.

    And in no way should the usage of given functions result in something like "banning" (well, again except regarding exploits, explicit abuse...)

    It could also be an option to introduce another currency, to be used for API calls to limit its use. This offers a lot of more options, regarding its implementation, e.g. when and how it increases/reloads or how API call costs are calculated.

    Like it could refill faster by killing other creeps ^^
    Just an idea… I guess there are a lot of possibilities.


  • Undifferentiated access unfortunately harms the ability to observe gameplay which is a significant way to experience the game and an excellent way to advertise the game.

    Something like a 50 tick delay for rooms outside of the player's vision would be an ideal compromise, but this is most likely a non-trivial feature.

    Test edit.