Terms of Service question on 3rd party Account Operation
Myself and tooAngel are prepared to collaborate on a more comprehensive command and control protocol based on the Diplomacy Packet.
I call it the "Do You Even Hive, Bro?" protocol.
DYEHB? is a distributed command and control system which fosters collaboration between players who program and players who pilot; players who analyze and players who sometimes afk.
With that in mind I'd like to know where the violation of ToS occurs:
* Can my script avoid directly harming another player?
* Can my script avoid harming the interests of another player?
* Can my script command another player for access to a rampart?
* Can my script command another player for access to a resource?
* Can my script command another player to send me resources?
* Can my script automatically give another player resources? (and at what price is appropriate?)
* Can my script follow another player's war party and fight anyone that they damage?
* Can my script command another player to launch an attack on a pre-determined target?
* Can my script command another player to launch an attack on a target specified at the time of communication (ad-hoc)?
* Can my script command another player to fire a nuke at an ad-hoc target?
* Can my script command another player to create a construction site?
* Can my script command another player to destroy one of their buildings?
* Can my script command another player to abandon a room?
* Can my script command another player to respawn?
* Can another family member give me their account if they stop playing?
* Can another player not related to me give me their account if they stop playing?
* Can more than one player directly control one account? (Not allowed by many MMO's)
* Can another player give me their account if I stop playing with my existing account?
* Can I register another account if I do not play on the same Screeps.com world with both accounts at the same time? (for instance separate accounts for PTR and production, or separate accounts which are only active and maintain spawns on production one at a time)
* Can another player give me their account which I play along with my current account? (hearsay: players have been banned for this)
* Can I register a second account and play Screeps.com production on both? (No, explicit violation of the Terms of Service)
I believe I have put these in order of most acceptable 3rd party command and control toward the egregious violations of the ToS.
EDIT: of course the final vector:
* Can I use a terminal transaction to command a player to perform some or all of the above actions?
EDIT2: Not all of OCS agrees with this, 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.
Ccomp5950 last edited by
One person able to control multiple accounts (albeit indirectly and with the account owners permissions and through code) seems to violate rules as intended. Having an alliance that is primarily a botnet is essentially splitting hairs with the "one account, one player" intent.
I find this whole thing intriguing and I'm loathe to say clever implementations shouldn't be allowed, but this is getting ridiculous.
Alliances: Individual people working together for a common goal.
This: Individual people downloading code other people wrote that allows other people to control who gets attacked in a coordinated fashion.
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.
I think the multiple accounts part of the ToS unambiguously refers to a situation where a single person is registering more than one account (presumably for the purpose of getting around the CPU limit).
I don't think players organizing themselves in this way breaks the letter of even the spirit of the ToS.
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. If a bug occurs they are unable to log into the other account to see what happened. To the extent that it works well and bugs do not occur, this reflects player ingenuity and effective code, which is what screeps is all about. A player who is willing to allow another player to command their AI takes the risk of the other player not making effective decisions and wasting resources and opens the door for interesting ways of betrayal. To the extent that these decisions ARE effective and betrayal does not occur, it reflects well on the trustworthness and composition of the members in the group, so at some point there was effective organization on the human level. So it ends up being a self-balancing issue.
Trying to apply that part of the ToS puts a lot of other player activities into a gray area. There are some alliances where one AI can direct another AI to do a coordinated nuke strike. That would now seem to be a questionable practice as well.
Atavus last edited by
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.
vrs last edited by
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.
> 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.
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!"
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.
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.
Rajecz last edited by
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.
Atavus last edited by
@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.
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".
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.
cyberblast last edited by
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.
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.