3. Terms of Service question on 3rd party Account Operation

Terms of Service question on 3rd party Account Operation


  • @Ccomp

    I agree entirely with you that botnets are against the game's intent and an alliance should be a group of individuals working together towards a common goal.

    What I don't agree with is that there is any problem with your last statement:

    > If I'm being completely honest this is taking an alliance and making it more efficient by removing the need to coordinate at the human level.

    The end goal of this game in my mind is a series of fully automated AIs, some of which might be collaborating under an alliance. The human element should not be a requirement of any element of this game. Human interaction is a temporary necessity to handle the lack of appropriate code to deal with complex circumstances.

    As a practical example, different members of the SUN alliance have independently developed scripts to handle collaboration. The most fundamental of which is automatic resource sharing between recognized allies. Yet this extends to more complex behaviors. These collaboration protocols were implemented independently by different people to fit within completely different code bases.

    Another simple example is the commonly used rampart permission where a number of SUN members have implemented different approaches on allowing passage for friendly units.

    The longer I think about this subject it is clear that the problem is not so much with the AI's ability to react automatically and collaborate with other AIs part of its network (alliance). The problem is whether or not the developer behind the AI is an active participant in the community.

    With that in mind, I get the feeling the only real option is for Artem to start automatically deactivating zombie players. Players who may still have an active subscription but have not logged in or submitted code in months.


  • What if API accessible communication was taxed at a rate of 1 CPU per UTF8 byte?

    This is a shortcut to the inevitable communication via rampart toggling or creep dances.


  • This feels a bit like an engineer's reaction on dealing with laws.

    To me there the rules should be based on broad principles (don't cheat, use common sense, etc), not narrowly defined use cases set in stone.

    If a clever loophole in the rules or inventive use of a game mechanism allows one player to amass vast and disproportional amount of "power" (not the resource) to such an extent that it's not fun for anyone else, the devs should be able to step in and change it to balance the playing field.

    However at this stage, there is no evidence that your approach is feasible. How many people would like to pay for a completely afk game ? Also, perhaps the rest of the players will band together and squash any clone popping up.

    I'm all for experimentation, so to me, sure, go nuts and implement a clone swarm. And when (or if) if becomes so successful and wide used that it effectively breaks the game, the rules or game mechanics should get changed.

    One possible change to make clone swarms harder: put on each player page a "is a clone" % likelihood indicator (perhaps based on comparing code snippets - I realize this cant be done with 100% accuracy) + disallow deliberate code obfuscation.


  • UPDATE: Not all of OCS agrees with this idea, a few members are starting to think this is a bad direction. As per usual we're a democratic organization, but we've never had a "this is a bad idea" moment before.

  • Culture

    > In this scenario, the players making decisions do not have direct control over the responding accounts. If they are using terminals to send commands, all they can do is hope that the "bot" AI responds as expected. 

    Is this statement actually true? If it's a group of people sharing the same code base (or a single person with multiple accounts sharing the same code base) then they have a reasonable expectation that their "commands" will be followed, at least within the parameters that their own code base uses. 

    Let me bring up another scenario. Lets assume I made a code base that can work with other copies of my code base. I then invite my girlfriend, sister, brother, best friend, and one of my neighbors to play and I give them my code base to use. None of them modify the code, they just upload it and let it automatically grow and expand. I may even provide them with subscription tokens to keep them playing.

    The question is should that be allowed? The difference between me creating alt accounts and having non-coding friends of mine do it seems like a minor one. It also seems like a minor step to open my alliance to anyone and provide them with my code, and then when they walk away or stop playing I essentially get "free rooms" since I can control those players via terminal commands. There also doesn't seem to be a reasonable way for the game devs to be able to tell the difference between these three scenarios either.

    Basically to me it seems like there's a big advantage to creating multiple accounts, whether it's doing it yourself or by having players who aren't ever actually playing do it on your behalf. If that's allowed then I don't think it's fair to ban people from using multiple accounts, since that's basically what OCS is doing with their shared code base anyways.


  • > Let me bring up another scenario. Lets assume I made a code base that can work with other copies of my code base. I then invite my girlfriend, sister, brother, best friend, and one of my neighbors to play and I give them my code base to use. None of them modify the code, they just upload it and let it automatically grow and expand. I may even provide them with subscription tokens to keep them playing.

    It is a good scenario to bring up because my interpretation is that this would still be allowed. If your true intent was just to have multiple personal accounts, that is against the ToS. But if all these people were interested in screeps and actually sat down to play the game, I see nothing wrong with the above scenario.

    There's obviously no way to know what a players "true intent" is in this scenario, that is why these rules are largely unenforceable. This isn't just a problem with Screeps, it applies to every MMO with this policy. The only way it is enforceable is if the player actually admits that is what is happening, which is easy not to do. This is why some MMOs don't even bother to make it against the rules.

    All that being said, it is a far-cry from the current scenario. As I understand it, all of the accounts in question belong to different people. They are not giving direct access to each others' accounts. There is a natural limit to how much you can control another account by using terminal communication. Most importantly, you cannot modify the code itself. (I suppose you could if you came up with a sophisticated way of exploiting the bug that allows arbitrary HTML to be executed through the console, and that would put us into different territory). Even if you did come up with a very sophisticated system, that reflects player ingenuity and effective code, as I stated above. That is not the type of thing we should be trying to discourage.

  • Culture

    The difference between this MMO and others is that the game devs can see our code. In theory it shouldn't be difficult at all for them to find "cloners" by calculating how unique a code base is. If they wanted they could easily say "one player per code base".

    > All that being said, it is a far-cry from the current scenario.

    But the current scenario can easily grow into this.

    > As I understand it, all of the accounts in question belong to different people.

    How do we know this? Even more importantly, how likely is this to change when code bases that allow multiple account coordination are available? As the benefit to doing this increases so will the temptation to exploit it.

    > They are not giving direct access to each others' accounts. There is a natural limit to how much you can control another account by using terminal communication.

    That natural limit is purely based off of code and automation. My goal for my code base is to be able to do something like "empire.goToWar(playername)" and step away. Assuming my code base can handle that then cloning it and adding a small protocol wrapper around terminals would be trivial. Attacking players, manipulating the market, returning minerals or energy- all of this seems trivial to do over multiple accounts as long as the code base supports those features.

    Admittedly for players who are dependant on placing flags or running constant manual console commands are not going to be able to do this. However I feel any group that's playing this for long enough will automate most things eventually.

    > Most importantly, you cannot modify the code itself.

    "Hey, [GIRLFRIEND], can you run that terminal command I taught you? Yeah, the one to pull down the latest code and upload it to screeps. Awesome, thanks!"


  • @tedivm

    I think you've identified some good issues relating to what is fair play, but there are plenty of these issues that are outside the scope of what the ToS covers. If you knew of a way to rewrite the policy that was simple and easy to apply and prohibited all of the behaviors that you consider abuse without simultaneously calling into question all the interesting ways that AIs could (and some currently do) coordinate, I'd say it is worth considering.

    I don't think we should be punishing people for having similar or even identical codebases. There are plenty of people who collaborate on code and run the same code. This has never been regarded as against the ToS before or even a negative practice by the community, and I don't think we should start doing it now.

  • Culture

    Yeah to an extent I'm ignoring the existing ToS and am instead questioning what we do or do not want to be allowed.

    Honestly though if we're going to allow people to reuse code wholesale then I don't understand why multiple accounts aren't allowed.


  • I think the fact that OCS is now questioning whether they actually want to do this supports the idea that it is a self-balancing issue. There are obviously risks with this kind of arrangement, it could easily backfire for those involved.


  • I'll add my two cents to the conversation since Hive may have helped generate this particular conversation (even though I realize these same question existed long before this event and will continue to be asked long after). I don't think we want to be playing this game dominated by botnets. I don't think the intent of this particular module is to take advantage of players who have long since quit the game but it does enable that. I don't think there is anything wrong with active players using automated communications to enact basic functions (resource help, passage through rooms, defense requests) but that isn't really whats being talked about here (even if that is what is being proposed). We are talking about controlling others accounts and I don't think that is anything that we should want to allow, but I also don't think that is anything that can be enforced by the game devs or the TOS. I think this is an issue that we need to address as a community and enforce as a community.

    The current Hive event is an instance of this, we in the Hive see running others code as a problem. We watch the new novice zones that pop up and we talk with a lot of new players and what we have been seeing more and more often is that these new novice zones are being dominated by new players running others code, and when we talk to the other new players in the zone we are hearing a lot of frustration with not being able to compete with these other players who started playing at the same time but simply run someone elses code. Now I don't think opening up your bot code (bonzaiferroni and tooAngel) or having a shared downloadable complete code base (OCS) is against the TOS or should be restricted by the game developers, but I do think that in the screeps community when we see what we identify as a problem, we should act on it. This means we will all have different problems and all be acting on different things (I know on at least 1 occasion I have been identified as a problem) but I think that is how these issues should be worked out.


  • @Tedivm I do not share your disdain for collaborative coding projects. I cannot quantify whether or not OCS has a negative impact on the community. I generally shy away from making moral judgments unless backed up by concrete facts and analysis.

    Judging that OCS has a negative impact on the experience of new players by having a few targeted conversations with individuals in novice areas does not quantify as a proper analysis of the subject.

    I do however agree with Rajecz on the fundamental principle that the community itself should be the one to organize itself and react to matters that are judged destructive to the well-being of the community. I do not feel inclined to make the judgment that he has made regarding OCS, but I do respect the principle of taking matters into one's own hands.

    I've been part of MMO communities and MMO strategy games since the golden days of 2003. As Bonzai has correctly noted, the only realistic cases where multis get banned by game admins is when there is concrete proof. In all of these communities, it is almost always the community core itself which actively organizes and targets "known" abusers.

    On the subject of collaborative projects themselves, I must confess a double standard. I find it perfectly acceptable for veteran players to band together and work on a collaborative project which one or all might be running.

    It's all a lot less clear when it comes to completely new players making use of a predeveloped code base. I personally found the early challenges and experience fascinating. It was an excellent learning opportunity. However, I can also imagine with ease how joining a project such as OCS can be better suited for personalities and experience levels which defer from my own. I cannot assume that everyone's relationship to the game and their path must match my own. Without making a systematic, concrete analysis of the impact OCS has in the various novice areas it exists, I must refrain from judgment.

  • Culture

    What if, to be allowed into a novice zone, you could only have (say) 50KB of code? Enforced at upload time, so if you hit the 50KB limit while you're in there, guess you need to go remove some characters from variable names.

    That'd solve the novice zone problem at least. You want to download a fully developed codebase? Then play with the fully developed players.

    edit: But of course then you'd have the problem with some super-optimized codebase that fit in 50KB out there to download. Still, it seems much less likely to be a problem - you have to put effort into that, specifically, and improving your 50KB codebase doesn't help your "main".

  • Culture

    I do not see any statement I've made about a "disdain for collaborative coding projects", and I've released or started several open source projects on my own. I'm going to ask that you stop trying to start arguments or vaguely insult people in these threads and focus on the discussion at hand.

    What I want to know is what the community feels the line should be (both socially and with regards to rules), and where the admins plan on drawing their own lines. Games are made up of rules, and I think it's better to have those rules be clear and known. I think it's important to talk about how rules can be exploited when creating them, or whether it's even feasible to enforce them at all, so that means bringing up some worst case scenarios. 

    I also think it's important from another level to discuss where "multiaccounting" is allowed. As I'm sure everyone on this thread knows I have two accounts- one that I play with, and one that is a pure "API" account that is used to run the "League of Automated Nations" site (it's probably sent you a log in message). The admins haven't banned the league site, have endorsed it on several occasions, and even added a new API Endpoint for us to use to create the LeagueBot. So when it comes to multiaccounting there are clearly exceptions.

    I am also aware of one instance where an account was banned for being a "multi account"- a player who had been wiped but had still had active controllers used a friend to pay for a subscription (either by getting a steam client or via the web, I'm unsure) and uploaded their own code. That new account rebuilt the original player's spawn and bootstrapped back up from dead, and the second account was banned as a result (and we have no proof that the second player wasn't actually controlling the first players code).

    So we have one example where using a second account is allowed, and another example where sharing code with a friend who just purchased an account (not against the rules according to people in this thread) did get banned. What if I get my girlfriend an account, place a single room in the game just to have a terminal, and use this to drive a new third party web service that's open to the public (like LoAN) but actually interacts with the game world?

    I think it's pretty clear that it's time for a revision to keep up with how the game has evolved and people are experimenting with things more. I'm not saying more restrictions need to be put in place, just that things need to be clarified.


  • I'm not getting it why there are so many concerns about OCS.

    1. Sharing a codebase

    When I started playing screeps, there was this option to publish my code to github. Offered by the screeps application itself. I never used github before. But having a code repository seemed to be a good idea, I'm used to other repos.

    But Github is a public place (by default, without paying higher fees). After I loaded my code to Github, I added a little readme file (if anyone would enter) and explored Github, started to add tons of issues (simply to organize my own work, remind me of what I wanted to do). Quite fast the first collaborators showed up. Which was great, of course, and it was the beginning of what we have now.
    So, what the hell is the problem with collaborating on a shared codebase? codeBASE!

    It is intended to alter our code. We provide simplified code injection, lots of parameters etc. Also, there are a lot of different combinable branches.
    So each OCS player, in general, is running it's very own code.
    There could be some players who are simply running the "default" raw codebase, but that wouldn't make any sense at all in the long run.

    However. If it wasn't intended to collaborate on code, that github option wouldn't/shouldn't have been there. 

    2. Current Hive Hunt Event

    We may be the largest alliance regarding player count. But most of them are novice or low GCL players (compared to other alliances). Focusing on offending them means focusing on offending new players.
    Personally, I don't think this is a good idea.

    3. 3rd party account operation

    I can understand that there are some concers about this idea. This is why Karl did the right thing to discuss this topic openly.
    Please try to stick at that topic.

  • Culture

    I think the reason why OCS keeps bring brought up is that one of their players started this thread, and the questions they raise about what is or isn't allowed are good ones.

    There is a separate cultural issue that we seem to be veering off in to, but I too would like to focus on the main discussion regarding what should or shouldn't be covered in the terms of service, and what changes (if any) should be in the terms of service.


  • I agree with cyberblast that said "cultural issue" did not need to be introduced here and is a distraction.

  • Dev Team

    This is a complicated topic. While I find all comments in this discussion very interesting, I should highlight that we try keep our rules as non-invasive as possible to keep the game entertaining for all players at the same time. In most cases, we stick to the following logic:

    1. If your code base is unique, you're safe. You can even register multiple accounts, but if they use completely different codebases, they are considered different players, since there's no way to distinguish such a case from a family member playing at the same computer.

    2. If your code base is shared, we need to have clear evidence that this is you playing this code base, not the code base owner. In case of any doubts in this regard, we'll investigate your account activity and may ban your account if we have proofs that the account is used only to expand this code base influence without your participation as an individual player.

    We don't restrict players collaboration and interaction of any sort, including automatic collaboration and interaction. All rules applied by ToS are related to user accounts activity, not to code base features.


  • Based on this judgement I think that I will introduce a build signature for OCS members code and will consider a strong caution about circumventing the ToS using command and control features.


  • As always, I'm late to the party 🙂 Interesting discussion.

    Artem: Thanks for clarification. If you ever have any issues with my code base, let me know. Didn't happen yet, so I think I should be fine. It also tells me, I shouldn't include anything which sends me resources 🙂 (never seriously planned)

    Even though I think the discussion is over, with an expected and highly appreciated result, still I would like to add my cents:

    Multi-account is a no go. I thought about it by myself a couple of time, to be able to test my attack and defense, but this is solved with the private server. So no reason for Multi-account (tedivm your second account is fine).

     

    Communication protocol: I wouldn't have opened a thread here, I would have expected that it is fine. Planing it anyway since a couple of month, while the authentication is in my case much more important and tricky, than sending some commands.

    New players: I'm well aware that some new players are upset by my code, sometimes by the players using my code. It is not necessary a screeps question: Do I reinvent the wheel or do I just use a framework or ready made system. Reinventing the wheel and being upset that you are slower, well I'm missing the understanding for that. Btw. my autoattack is not that strong, I see it more as the minimal level you should be able to handle to survive when the newbie area times out. Just to make it clear, I fully understand the fun in writing the first thousand lines of code, I started from the scratch, there were some code pieces (not compared to today), but I wanted to do it on my own. I wouldn't do it again, today.

    The Hive event: Whatever, I don't mind. - Slowly I get the messages from players using the TooAngel AI, mostly from active contributing members. And this is exactly the point where the argumentation for the Event breaks in my opinion. I think it got more tricky to attack other players, because of the alliances, without provoking a proper War. If you want to attack certain players do it (I would do it), but please don't try to reason it by something which is not true. Tbh I think it is boring to attack more then one TooAngel AI, the next one will anyway behave pretty similar 🙂

    TooAngel Bot: (I distinguish between the bot for the private server, and the TooAngel AI which is the actual logic). I didn't plan to opensource my AI or let other players use it (I didn't announce that my code is opensource at anytime, except of now?;-)). I wanted to release my code as bot, so that I'm able to play against it. From the feedback I got, it is highly appreciated. So you can't have both a bit more advanced bot that the simple bot, but no fully automated code available.

    Because I'm mainly developing with the bot in mind, this my most tricky part for the communication. How do I make sure that I don't friend up with the TooAngel bots on the private server, while doing it with the TooAngels and ocs on live 🙂