Forums » General
I'm thinking a game feature could eliminate the need for most multiboxing complaints. For instance the ability to have "agents" that you pay for with supplies or credits, that provide the functionality a "spy" plugin or "trade" plugin would hope for.. this would give developers control over the use case instead of battling against what people will do on their own machines.
This isn't going to placate anyone who wants to do this at scale. That can only be done by making the actual mechanics involved more challenging.
I'm not ruling out future gameplay systems that could convey information awareness about the galaxy.. like talking to NPCs about what pilots they've seen recently, or any number of other things. I've always had plans for such possibilities.
But, one cannot implement that with just the "hope" that maybe "people will just stop" because you made some watered-down version of an exploitative system. The people who pursue multiboxing at scale do so specifically because of the scale. They don't want a watered-down version.
This isn't going to placate anyone who wants to do this at scale. That can only be done by making the actual mechanics involved more challenging.
I'm not ruling out future gameplay systems that could convey information awareness about the galaxy.. like talking to NPCs about what pilots they've seen recently, or any number of other things. I've always had plans for such possibilities.
But, one cannot implement that with just the "hope" that maybe "people will just stop" because you made some watered-down version of an exploitative system. The people who pursue multiboxing at scale do so specifically because of the scale. They don't want a watered-down version.
I'm just going to be honest about it.. I don't think multiboxing is offering anything more than carrying capacity. We are literally talking 2 or 3 players in your player base that may possibly use this, and none of those players are making a ruckus that is cause for someone else to complain. Even spybots are not very useful in the grand scheme. I really don't see how this particular topic came suddenly into focus. If someone wants to multibox, they can do something as simple as using 3 or 4 old phones that are collecting dust. I mean, there's just no way you can mitigate it through code or policy. The idea of implementing features that make the desired functionalities possible was just to offer something that actually CAN be done.
But I think we are talking past each other a bit. The term "multiboxing" in industry encompasses a few different concepts. There is the issue of running multiple clients on one machine and controlling them all by passing keystrokes to all of them simultaneously.. That is the one that some try to mitigate and those MMOs are of a type that this presents a particular problem. VO doesn't function that way, the ships are too big and the varied movement in the 3d space makes this an impossible prospect for a user. Another use of the term refers to simply being logged in on two or more devices at the same time.. you already can't do that on VO. Then there is the use of additional clients that may or may not be on the same physical machine, which a person might use for intel or game data. This is not possible to mitigate due to modern technologies available to users (which, with AI are quite a bit easier to use and understand) but this data can just as easily be relayed over chat channel anyway. In this last category you have players that will run multiple clients like a particular player who has been seen leading a trail of 3 or more cap ships through VO. He uses them to carry a larger payload, in combat they are impotent. He uses simple scripting to accomplish this all within VO itself. You can't mitigate that really, there is no way to determine if those ships are being individually controlled by an actual player with any certainty and there's certainly no necessity that they all would be running on the same physical machine or account.
This is what I mean, the only thing that can be done I guess is to create a policy to threaten suspects with and manually ban accounts based on your personal judgement as to whether they are doing this or not.
• EVE Online: CCP Games fundamentally embraces multiboxing as a normal part of the sandbox gameplay loop. Players routinely use separate "Omega" (paid subscription) accounts to act as scouts, haulers, industrial miners, or cynosural field lighters while operating their main combat ship on another monitor.
• Final Fantasy XI: FFXI is widely considered a premier game for "dual-boxing" or "party-boxing". Because the classic turn-based combat system requires very little fast-paced physical movement and heavily relies on robust built-in /follow and /assist text commands, players can easily control an entire party manually.
• Wakfu & Dofus: Ankama Games explicitly tolerates multi-accounting. Because combat is entirely grid-based and turn-based, a single player can naturally wait for one character's turn to finish before clicking over to the next client window to execute a tactical move.
• Guild of Souls: An indie RPG designed specifically with the community in mind, allowing players to natively sandbox and multibox up to 40 characters simultaneously without needing to jump through backend software loopholes.
• EverQuest & EverQuest II (Live Servers): Outside of the dedicated "True Box" servers, standard live servers have openly allowed software-assisted multi-boxing for decades to let veterans clear older, top-tier group content solo.
and some who attempt to mitigate but only specific use cases:
Most modern developers mitigate multiboxing by aggressively targeting input broadcasting software (tools like ISBoxer or Keyclone that mirror a single keystroke across multiple game clients), or by using server-side code to limit connections per PC.
World of Warcraft
Blizzard heavily restricts the effectiveness of multiboxing. While you are technically allowed to pay for multiple subscriptions and have multiple characters logged in at once, input broadcasting software and hardware hardware key-syncing are strictly banned. If you want to multibox, you must alt-tab and manually control each window individually.
EverQuest
On its standard live servers, EverQuest generally tolerates multiboxing. However, Daybreak Game Company manages player frustration by introducing "True Box" progression servers. These servers use specialized detection code to limit players to one game client per physical computer, effectively preventing software-assisted multiboxing but this fails due to widely available software.
Defiance / Defiance 2050: Developers implemented strict hardware limits—colloquially known as the "alt account limit" patch—which completely blocks players from launching more than a designated number of clients (such as four) per PC to stamp out botting and real-money trading (RMT).
Guild Wars 2
ArenaNet historically maintains rigid rules against automation and macro use. Running multiple accounts is allowed for login rewards, but utilizing any external software to broadcast combat keys or farm materials across characters simultaneously will trigger a permanent ban.
But it's important to note that of these attempts to mitigate, none of them actually fit the same bill as VO. Also none of them were successful at mitigating it outside of very specific use cases, and even then we are talking about games that aren't offering scripted plugin systems in the same vain as VO. Botting for resources is only plausible in VO in recent years as you have greatly restricted the abilities of player pirates who would otherwise hunt and kill unmanned ships. You increased the PvP consequences for it, and now you are left trying to figure out how to police it all by yourself, but you can't.
I think you should allow it explicitly... then make certain use cases that you don't like more difficult to implement. Though you haven't exactly laid out those use cases clearly. You mentioned spy bots.. but you could easily prevent that and you haven't... do you mean group mining with bots? You allowed that when you started persuing ways to make things easier on players who want to "mine in peace". Do you mean carrying capacity? You added commands like "follow" that make this extremely simplistic for even the least skilled player. So I think you should follow the path you are already on and allow it completely. I would even make it easier, allow multiple logins on the same account as long as they are on different characters. Offer some breadcrumbs in event exposures and commands that make it easier to accomplish like you already do.
But I think we are talking past each other a bit. The term "multiboxing" in industry encompasses a few different concepts. There is the issue of running multiple clients on one machine and controlling them all by passing keystrokes to all of them simultaneously.. That is the one that some try to mitigate and those MMOs are of a type that this presents a particular problem. VO doesn't function that way, the ships are too big and the varied movement in the 3d space makes this an impossible prospect for a user. Another use of the term refers to simply being logged in on two or more devices at the same time.. you already can't do that on VO. Then there is the use of additional clients that may or may not be on the same physical machine, which a person might use for intel or game data. This is not possible to mitigate due to modern technologies available to users (which, with AI are quite a bit easier to use and understand) but this data can just as easily be relayed over chat channel anyway. In this last category you have players that will run multiple clients like a particular player who has been seen leading a trail of 3 or more cap ships through VO. He uses them to carry a larger payload, in combat they are impotent. He uses simple scripting to accomplish this all within VO itself. You can't mitigate that really, there is no way to determine if those ships are being individually controlled by an actual player with any certainty and there's certainly no necessity that they all would be running on the same physical machine or account.
This is what I mean, the only thing that can be done I guess is to create a policy to threaten suspects with and manually ban accounts based on your personal judgement as to whether they are doing this or not.
• EVE Online: CCP Games fundamentally embraces multiboxing as a normal part of the sandbox gameplay loop. Players routinely use separate "Omega" (paid subscription) accounts to act as scouts, haulers, industrial miners, or cynosural field lighters while operating their main combat ship on another monitor.
• Final Fantasy XI: FFXI is widely considered a premier game for "dual-boxing" or "party-boxing". Because the classic turn-based combat system requires very little fast-paced physical movement and heavily relies on robust built-in /follow and /assist text commands, players can easily control an entire party manually.
• Wakfu & Dofus: Ankama Games explicitly tolerates multi-accounting. Because combat is entirely grid-based and turn-based, a single player can naturally wait for one character's turn to finish before clicking over to the next client window to execute a tactical move.
• Guild of Souls: An indie RPG designed specifically with the community in mind, allowing players to natively sandbox and multibox up to 40 characters simultaneously without needing to jump through backend software loopholes.
• EverQuest & EverQuest II (Live Servers): Outside of the dedicated "True Box" servers, standard live servers have openly allowed software-assisted multi-boxing for decades to let veterans clear older, top-tier group content solo.
and some who attempt to mitigate but only specific use cases:
Most modern developers mitigate multiboxing by aggressively targeting input broadcasting software (tools like ISBoxer or Keyclone that mirror a single keystroke across multiple game clients), or by using server-side code to limit connections per PC.
World of Warcraft
Blizzard heavily restricts the effectiveness of multiboxing. While you are technically allowed to pay for multiple subscriptions and have multiple characters logged in at once, input broadcasting software and hardware hardware key-syncing are strictly banned. If you want to multibox, you must alt-tab and manually control each window individually.
EverQuest
On its standard live servers, EverQuest generally tolerates multiboxing. However, Daybreak Game Company manages player frustration by introducing "True Box" progression servers. These servers use specialized detection code to limit players to one game client per physical computer, effectively preventing software-assisted multiboxing but this fails due to widely available software.
Defiance / Defiance 2050: Developers implemented strict hardware limits—colloquially known as the "alt account limit" patch—which completely blocks players from launching more than a designated number of clients (such as four) per PC to stamp out botting and real-money trading (RMT).
Guild Wars 2
ArenaNet historically maintains rigid rules against automation and macro use. Running multiple accounts is allowed for login rewards, but utilizing any external software to broadcast combat keys or farm materials across characters simultaneously will trigger a permanent ban.
But it's important to note that of these attempts to mitigate, none of them actually fit the same bill as VO. Also none of them were successful at mitigating it outside of very specific use cases, and even then we are talking about games that aren't offering scripted plugin systems in the same vain as VO. Botting for resources is only plausible in VO in recent years as you have greatly restricted the abilities of player pirates who would otherwise hunt and kill unmanned ships. You increased the PvP consequences for it, and now you are left trying to figure out how to police it all by yourself, but you can't.
I think you should allow it explicitly... then make certain use cases that you don't like more difficult to implement. Though you haven't exactly laid out those use cases clearly. You mentioned spy bots.. but you could easily prevent that and you haven't... do you mean group mining with bots? You allowed that when you started persuing ways to make things easier on players who want to "mine in peace". Do you mean carrying capacity? You added commands like "follow" that make this extremely simplistic for even the least skilled player. So I think you should follow the path you are already on and allow it completely. I would even make it easier, allow multiple logins on the same account as long as they are on different characters. Offer some breadcrumbs in event exposures and commands that make it easier to accomplish like you already do.
It seems like you didn't really read the initial post? That's my best guess anyway, because I would think most of your points were already addressed there.
Your response has made a whole lot of assumptions, many of which are objectively false.
I do appreciate the time you took to write that, and I did read the whole thing; but I'm not going to do a complete point-by-point response to a message that's basically a lengthy negation of everything I wrote in the first post. I'll try to respond on a few of them..
First of all, "No", we aren't doing the polar opposite of what this entire thread is about.
You have strong opinions about what you think is possible, and why you think we did those things. That's fine. But those are opinions. Your knowledge and awareness are clearly limited.
I mean, your fundamental thesis is basically "this rarely happens anyway, and doesn't really matter, and no one cares, so why bother?". Which begs the question of why I would engage with all these policy and game-design changes if I hadn't had to spend hundreds and hundreds and hundreds of hours dealing with blowback, accusations and massive community-management problems on variations of this topic in the past?
I don't have a lot of available time. I'm not likely to waste it on "problems that are not problems".
Botting for resources is only plausible in VO in recent years as you have greatly restricted the abilities of player pirates who would otherwise hunt and kill unmanned ships. You increased the PvP consequences for it, and now you are left trying to figure out how to police it all by yourself, but you can't.
What? Player pirates are completely irrelevant to this. There have never been enough player pirates in the game, ever, to create any kind of impact on the issues I'm dealing with (or have ever historically been dealing with). And there definitely won't be in the face of the kind of mass-farming found in modern MMOs. (And, Yes, automated multi-boxing for resources sure as hell happened during the "peak" of player pirates; if anything it had a peak around the same time).
• EVE Online: CCP Games fundamentally embraces multiboxing as a normal part of the sandbox gameplay loop. Players routinely use separate "Omega" (paid subscription) accounts to act as scouts, haulers, industrial miners, or cynosural field lighters while operating their main combat ship on another monitor.
This misses the point enough to end up being fundamentally incorrect. CCP Games (now Fenris) embraces subscriber multi-boxing. But they have a massive internal effort on making sure all the people doing so are legitimately subscribed to the game, which is really not that different from what we (or any other MMO) could do (the methodology is the same, the purpose is just different; you still have to "detect" the illicit multi-boxing). So, the example you're making in "favor" of the idea of "there's nothing you can do anyway, so just give up", is actually the opposite of that. EVE invests a tremendous amount of manpower, analytics and computational resources in tracking multi-boxing, and making sure they're paid for it.
Also, even within the strictures of EVE's "Omega" paid-multibox system, there are still limits put in place by their EULA in how the accounts may legitimately be used. A lot of people try to violate these policies, especially around combat ("group piracy" effectively, other things), so they still have to be constantly looking for automation.
Attacks against EVE by large for-profit farming operations are continuous and escalatory, because of the RWT value of the resulting assets. See the June 2026 EVE Ban Report, or the EVE Fanfest 2026 video where they discuss the 473,498 automated-creation accounts they had to ban in the previous 14-month period, as well as the 42,915 accounts they had to perma-ban for macro usage (in-game automation).
Moving along.. On multi-box mitigation specifics: Because this topic pushes up against "adversarial methods", I'm not going to publicly go into specifics on what options are available on our side. But, I think it's reasonable to assume that after a quarter century of operating a live-ops competitive online environment, I'm probably pretty aware of the options?
Among other things you didn't seem to read from the original post, was the sentence:
For example, the upcoming Mining System Changes have nothing to do with account limits, but inherently would make the entire mining mechanic substantially more challenging to automate.
Why would I be rebuilding the entire mining system into, effectively, a gigantic, gamified, latency-sensitive CAPTCHA, if I didn't think there was reason and value in doing so?
Yes, you can assume we are aware of AI. Especially given the amount of fully-custom machine learning that has gone into this making game, going back decades.
It is not always advantageous for us (as developers) to be completely transparent about the parameters of every problem; it just isn't always in the best interest of the community or the game as a whole.
But, it would be a bit naive to assume that I don't have a pretty robust grasp of the parameters of the problem I'm addressing.
Your response has made a whole lot of assumptions, many of which are objectively false.
I do appreciate the time you took to write that, and I did read the whole thing; but I'm not going to do a complete point-by-point response to a message that's basically a lengthy negation of everything I wrote in the first post. I'll try to respond on a few of them..
First of all, "No", we aren't doing the polar opposite of what this entire thread is about.
You have strong opinions about what you think is possible, and why you think we did those things. That's fine. But those are opinions. Your knowledge and awareness are clearly limited.
I mean, your fundamental thesis is basically "this rarely happens anyway, and doesn't really matter, and no one cares, so why bother?". Which begs the question of why I would engage with all these policy and game-design changes if I hadn't had to spend hundreds and hundreds and hundreds of hours dealing with blowback, accusations and massive community-management problems on variations of this topic in the past?
I don't have a lot of available time. I'm not likely to waste it on "problems that are not problems".
Botting for resources is only plausible in VO in recent years as you have greatly restricted the abilities of player pirates who would otherwise hunt and kill unmanned ships. You increased the PvP consequences for it, and now you are left trying to figure out how to police it all by yourself, but you can't.
What? Player pirates are completely irrelevant to this. There have never been enough player pirates in the game, ever, to create any kind of impact on the issues I'm dealing with (or have ever historically been dealing with). And there definitely won't be in the face of the kind of mass-farming found in modern MMOs. (And, Yes, automated multi-boxing for resources sure as hell happened during the "peak" of player pirates; if anything it had a peak around the same time).
• EVE Online: CCP Games fundamentally embraces multiboxing as a normal part of the sandbox gameplay loop. Players routinely use separate "Omega" (paid subscription) accounts to act as scouts, haulers, industrial miners, or cynosural field lighters while operating their main combat ship on another monitor.
This misses the point enough to end up being fundamentally incorrect. CCP Games (now Fenris) embraces subscriber multi-boxing. But they have a massive internal effort on making sure all the people doing so are legitimately subscribed to the game, which is really not that different from what we (or any other MMO) could do (the methodology is the same, the purpose is just different; you still have to "detect" the illicit multi-boxing). So, the example you're making in "favor" of the idea of "there's nothing you can do anyway, so just give up", is actually the opposite of that. EVE invests a tremendous amount of manpower, analytics and computational resources in tracking multi-boxing, and making sure they're paid for it.
Also, even within the strictures of EVE's "Omega" paid-multibox system, there are still limits put in place by their EULA in how the accounts may legitimately be used. A lot of people try to violate these policies, especially around combat ("group piracy" effectively, other things), so they still have to be constantly looking for automation.
Attacks against EVE by large for-profit farming operations are continuous and escalatory, because of the RWT value of the resulting assets. See the June 2026 EVE Ban Report, or the EVE Fanfest 2026 video where they discuss the 473,498 automated-creation accounts they had to ban in the previous 14-month period, as well as the 42,915 accounts they had to perma-ban for macro usage (in-game automation).
Moving along.. On multi-box mitigation specifics: Because this topic pushes up against "adversarial methods", I'm not going to publicly go into specifics on what options are available on our side. But, I think it's reasonable to assume that after a quarter century of operating a live-ops competitive online environment, I'm probably pretty aware of the options?
Among other things you didn't seem to read from the original post, was the sentence:
For example, the upcoming Mining System Changes have nothing to do with account limits, but inherently would make the entire mining mechanic substantially more challenging to automate.
Why would I be rebuilding the entire mining system into, effectively, a gigantic, gamified, latency-sensitive CAPTCHA, if I didn't think there was reason and value in doing so?
Yes, you can assume we are aware of AI. Especially given the amount of fully-custom machine learning that has gone into this making game, going back decades.
It is not always advantageous for us (as developers) to be completely transparent about the parameters of every problem; it just isn't always in the best interest of the community or the game as a whole.
But, it would be a bit naive to assume that I don't have a pretty robust grasp of the parameters of the problem I'm addressing.
Thank you for the thorough reply, Incarnate.
I'm honestly sorry you have to go down this road. It is unfortunate, more for your own time than for your player base. We will all be just fine and adapt our play to the system you provide.
I also apologize for that long post; it was late in the day for me, and my mind was racing on the topic. I was deep in the coding zone state of mind. Having added some nice functionalities to the Perl distribution I was working on.
In fact, it was that piece of software that reminded me of VO and sent me back to take a look at the new rmlui features and how that is coming along. Very exciting stuff!
Nevertheless, I do have a Linux platform and some useful experience to offer if you want some tricky testing done as you develop your mitigation. Of course, Linux will be the most difficult platform to mitigate, so that offer is genuine.
I'm looking ahead and considering rewriting one of those controversial plugins using my new set of Perl libraries for the server, and I hope I will be able to write UI features in the new rmlui. This was/is known as Skynet, which was a rewrite of a very old plugin called Voce. It is not a multiboxing plugin, but player spotting automation between users is a defining feature of it, and that, of course, could lend itself well to "spybots".
I'm honestly sorry you have to go down this road. It is unfortunate, more for your own time than for your player base. We will all be just fine and adapt our play to the system you provide.
I also apologize for that long post; it was late in the day for me, and my mind was racing on the topic. I was deep in the coding zone state of mind. Having added some nice functionalities to the Perl distribution I was working on.
In fact, it was that piece of software that reminded me of VO and sent me back to take a look at the new rmlui features and how that is coming along. Very exciting stuff!
Nevertheless, I do have a Linux platform and some useful experience to offer if you want some tricky testing done as you develop your mitigation. Of course, Linux will be the most difficult platform to mitigate, so that offer is genuine.
I'm looking ahead and considering rewriting one of those controversial plugins using my new set of Perl libraries for the server, and I hope I will be able to write UI features in the new rmlui. This was/is known as Skynet, which was a rewrite of a very old plugin called Voce. It is not a multiboxing plugin, but player spotting automation between users is a defining feature of it, and that, of course, could lend itself well to "spybots".
I'm honestly sorry you have to go down this road. It is unfortunate, more for your own time than for your player base. We will all be just fine and adapt our play to the system you provide.
I appreciate that. Honestly, I think it's a stupid waste of energy (unfortunately, also a necessary one, due to current conditions). I would much rather just focus on making fun stuff.
Everything these days is shoring up defenses against lawsuits and fines (changing legal frameworks in the US and elsewhere), raising defenses against DDoS attacks and the like (lots of them these days, mostly targeting games. These days it costs like $10 to hit someone with a 20gbit attack, with a friendly phone-app), hardening all services against more sophisticated LLM-assisted compromise attacks on the server infrastructure, plus the client+server anti-tampering / anti-exploit / anti-cheat bullshit (although that's been on-going for awhile).
But, at the end of the day, it's like shitty weather. There's no point in whining about it. You learn to do your work in the freezing rain (or you give up and go do something else).
In fact, it was that piece of software that reminded me of VO and sent me back to take a look at the new rmlui features and how that is coming along. Very exciting stuff!
I think RmlUi going to be really cool. There has been a.. huge lift over the last couple of years, completely restructuring a lot of code, and I think it's going to start becoming more apparent soon. We're getting closer to where I can start "moving fast and breaking stuff" (albeit, mostly on Win64 beta, for the moment). RmlUi (and updating the game UI) is really just one small part of it, but it's one I personally care about a great deal.
Nevertheless, I do have a Linux platform and some useful experience to offer if you want some tricky testing done as you develop your mitigation. Of course, Linux will be the most difficult platform to mitigate, so that offer is genuine.
I appreciate that. It's actually not all-bad for us on Linux. Windows is really no picnic, at least unless you do the ring-0 privileged driver thing, which I philosophically refuse to do. Regardless, the complete next-gen client runtime architecture is a bit of a doozy. So far we're only testing fractions of it.
There will be plenty of testing to go around for anyone who wants to be involved, so thanks for that.
I'm looking ahead and considering rewriting one of those controversial plugins using my new set of Perl libraries for the server, and I hope I will be able to write UI features in the new rmlui.
Fair warning: There will probably be changes to how the client plugins can independently engage over a network, likely with substantially stricter limitations than there have been in the past (it's necessary for compliance with certain platform policies, even emerging laws). The capabilities will likely focus more on client data-retrieval than two-way data-exchange. There will also probably be some positive expansions of the plugin API for things like on-disk storage. None of that is the priority right now, we're.. swamped with our current workload. But a heads-up before you go writing a lot of major Plugin code, that networked plugins may become more limited.
Anyway, moving on.. anyone else have any concern about a limitation of two accounts, or additional points of feedback?
I appreciate that. Honestly, I think it's a stupid waste of energy (unfortunately, also a necessary one, due to current conditions). I would much rather just focus on making fun stuff.
Everything these days is shoring up defenses against lawsuits and fines (changing legal frameworks in the US and elsewhere), raising defenses against DDoS attacks and the like (lots of them these days, mostly targeting games. These days it costs like $10 to hit someone with a 20gbit attack, with a friendly phone-app), hardening all services against more sophisticated LLM-assisted compromise attacks on the server infrastructure, plus the client+server anti-tampering / anti-exploit / anti-cheat bullshit (although that's been on-going for awhile).
But, at the end of the day, it's like shitty weather. There's no point in whining about it. You learn to do your work in the freezing rain (or you give up and go do something else).
In fact, it was that piece of software that reminded me of VO and sent me back to take a look at the new rmlui features and how that is coming along. Very exciting stuff!
I think RmlUi going to be really cool. There has been a.. huge lift over the last couple of years, completely restructuring a lot of code, and I think it's going to start becoming more apparent soon. We're getting closer to where I can start "moving fast and breaking stuff" (albeit, mostly on Win64 beta, for the moment). RmlUi (and updating the game UI) is really just one small part of it, but it's one I personally care about a great deal.
Nevertheless, I do have a Linux platform and some useful experience to offer if you want some tricky testing done as you develop your mitigation. Of course, Linux will be the most difficult platform to mitigate, so that offer is genuine.
I appreciate that. It's actually not all-bad for us on Linux. Windows is really no picnic, at least unless you do the ring-0 privileged driver thing, which I philosophically refuse to do. Regardless, the complete next-gen client runtime architecture is a bit of a doozy. So far we're only testing fractions of it.
There will be plenty of testing to go around for anyone who wants to be involved, so thanks for that.
I'm looking ahead and considering rewriting one of those controversial plugins using my new set of Perl libraries for the server, and I hope I will be able to write UI features in the new rmlui.
Fair warning: There will probably be changes to how the client plugins can independently engage over a network, likely with substantially stricter limitations than there have been in the past (it's necessary for compliance with certain platform policies, even emerging laws). The capabilities will likely focus more on client data-retrieval than two-way data-exchange. There will also probably be some positive expansions of the plugin API for things like on-disk storage. None of that is the priority right now, we're.. swamped with our current workload. But a heads-up before you go writing a lot of major Plugin code, that networked plugins may become more limited.
Anyway, moving on.. anyone else have any concern about a limitation of two accounts, or additional points of feedback?
I'm guessing a lot of players will be surprised to know that I strongly support this.
As long as it's 2 concurrent accounts, as in logging off of one account to log in to another is always allowed, I see no problems. Having an objective standard of 2 concurrent logged-in accounts as a policy removes a lot of the ambiguity where people find X behavior to be "cheating" and Y behavior to be totally permissible, despite them being essentially the same mechanics. The objective standard cuts a lot of the doubt and FOMO out of the equation and lets players know exactly what's allowed and what's not. I'm not naive enough to think that there aren't things that could still be done with 2 accounts that are "abusive", but I do think the limitation is a sensible one that cuts off most of the obvious abusive cases while not fundamentally changing how veteran players with multiple accounts play too drastically.
As far as *policy* bans on using multiboxing *within the policy limits* to gain strategic advantage, I'm strongly against that. It's the developer's responsibility to ensure that whatever the policy is, that gameplay mechanics are conducive to that policy, and game systems are effective at enforcing it. Any policy that relies on players to self-enforce either because the undesired behavior is too easy and too much more effective than legitimate play, or too weakly enforced such that players can "get away with it" for a long time without consequences, are destructive to legitimate play. Players willing to exploit will always exploit, so the only thing a weak policy does is hamstring players who want to play legitimately. Essentially, saying "please don't do X" without backing it up with consequences for doing X is just an invitation to exploit, and leaves those of us who don't want to exploit in a bad place.
As far as being conducive to gameplay, as someone who has multiboxed extensively, I'm convinced that for most use cases in VO a 2-concurrent-account limit doesn't significantly impede efforts to optimize play, and is compatible with the first point. Running more than 2 accounts simultaneously has significant diminishing returns already, at least for the multiboxing use cases I know of. That said, if people have issues with that or think 2 accounts provide unfair advantage, I think the appropriate way to handle that would be to adjust the gameplay systems to make it less of an advantage rather than any policy stricter than a 2-concurrent-account limit.
I'm perfectly happy to leave the details of how to enforce this policy to the devs; it's a notoriously difficult problem to address from an engineering perspective, but as long as it's consistently enforced without punishing policy-following play I think this policy is quite reasonable. My only concern with enforcement would be that ideally I continue to never see a captcha during gameplay. If whatever systems put into place to combat people abusing this policy lead to more aggressive captchas affecting legitimate players more often, I would be against that. As long as I abide by the policy and avoid sitting afk or other bot-like activities, I should be essentially guaranteed to never see a captcha. Again, that's an enforcement issue and not a policy one, and if it doesn't change significantly from the current system I have no problem here.
As long as it's 2 concurrent accounts, as in logging off of one account to log in to another is always allowed, I see no problems. Having an objective standard of 2 concurrent logged-in accounts as a policy removes a lot of the ambiguity where people find X behavior to be "cheating" and Y behavior to be totally permissible, despite them being essentially the same mechanics. The objective standard cuts a lot of the doubt and FOMO out of the equation and lets players know exactly what's allowed and what's not. I'm not naive enough to think that there aren't things that could still be done with 2 accounts that are "abusive", but I do think the limitation is a sensible one that cuts off most of the obvious abusive cases while not fundamentally changing how veteran players with multiple accounts play too drastically.
As far as *policy* bans on using multiboxing *within the policy limits* to gain strategic advantage, I'm strongly against that. It's the developer's responsibility to ensure that whatever the policy is, that gameplay mechanics are conducive to that policy, and game systems are effective at enforcing it. Any policy that relies on players to self-enforce either because the undesired behavior is too easy and too much more effective than legitimate play, or too weakly enforced such that players can "get away with it" for a long time without consequences, are destructive to legitimate play. Players willing to exploit will always exploit, so the only thing a weak policy does is hamstring players who want to play legitimately. Essentially, saying "please don't do X" without backing it up with consequences for doing X is just an invitation to exploit, and leaves those of us who don't want to exploit in a bad place.
As far as being conducive to gameplay, as someone who has multiboxed extensively, I'm convinced that for most use cases in VO a 2-concurrent-account limit doesn't significantly impede efforts to optimize play, and is compatible with the first point. Running more than 2 accounts simultaneously has significant diminishing returns already, at least for the multiboxing use cases I know of. That said, if people have issues with that or think 2 accounts provide unfair advantage, I think the appropriate way to handle that would be to adjust the gameplay systems to make it less of an advantage rather than any policy stricter than a 2-concurrent-account limit.
I'm perfectly happy to leave the details of how to enforce this policy to the devs; it's a notoriously difficult problem to address from an engineering perspective, but as long as it's consistently enforced without punishing policy-following play I think this policy is quite reasonable. My only concern with enforcement would be that ideally I continue to never see a captcha during gameplay. If whatever systems put into place to combat people abusing this policy lead to more aggressive captchas affecting legitimate players more often, I would be against that. As long as I abide by the policy and avoid sitting afk or other bot-like activities, I should be essentially guaranteed to never see a captcha. Again, that's an enforcement issue and not a policy one, and if it doesn't change significantly from the current system I have no problem here.
I'm perfectly happy to leave the details of how to enforce this policy to the devs; it's a notoriously difficult problem to address from an engineering perspective, but as long as it's consistently enforced without punishing policy-following play I think this policy is quite reasonable. My only concern with enforcement would be that ideally I continue to never see a captcha during gameplay. If whatever systems put into place to combat people abusing this policy lead to more aggressive captchas affecting legitimate players more often, I would be against that. As long as I abide by the policy and avoid sitting afk or other bot-like activities, I should be essentially guaranteed to never see a captcha. Again, that's an enforcement issue and not a policy one, and if it doesn't change significantly from the current system I have no problem here.
It does present challenges from an engineering standpoint, so I cannot absolutely guarantee that no one is going to see a CAPTCHA, especially if we suddenly get inundated with for-profit gold-farming types.
But, having an official policy on this, and potentially (down the road) having an official way of "linking" accounts, potentially mandating they both be subbed for the multi-box usage case, having robust account history on "legit" multi-boxers and things like that; this kind of data and validation history makes it a hell of a lot easier to limit "false positives". It makes for a much clearer separation between automation-heavy alt farmers and genuine players, which makes it far less likely that we would need to target a broader base of users.
However, as a corollary, it's also important to remember that CAPTCHAs have historically served the purpose of limiting automation. I'm not likely to be any more friendly to automation, even with the policy change we're discussing. If anything, the whole point here is that one human being can play two accounts at the same time in a meaningful way (management on a capship, then flying a fighter or mining craft, or running two trade-ships at the same time, whatever).
It's also worth keeping the above linked EVE video in mind: a lot of the players they ban for automation are only doing this on a subset of their accounts. Their "mains" are legitimate, but they run some alt with automation on a separate account over a VPN, and think no one will possibly be able to figure out that they're related. But EVE detects and bans all the related accounts. This kind of thing happens to us too, and will inevitably happen again.
I'm not likely to ever be positive about automation that isn't an explicit gameplay feature (like the capship remote-command set), as VO is a game for humans. Conversely the existence of the plugin API is not and never shall be an excuse for full-bore-gameplay-automation (hence the removal of the original /displayshippos, and the banning of autopilot systems, decades ago).
At any rate, I think clarity on all of these topics, and policies, will make things better for everyone: Eliminate player-vs-player accusations, make the "playing field" as clear as possible, and similarly give no excuse to those who choose to cross the red lines and get themselves banned.
It does present challenges from an engineering standpoint, so I cannot absolutely guarantee that no one is going to see a CAPTCHA, especially if we suddenly get inundated with for-profit gold-farming types.
But, having an official policy on this, and potentially (down the road) having an official way of "linking" accounts, potentially mandating they both be subbed for the multi-box usage case, having robust account history on "legit" multi-boxers and things like that; this kind of data and validation history makes it a hell of a lot easier to limit "false positives". It makes for a much clearer separation between automation-heavy alt farmers and genuine players, which makes it far less likely that we would need to target a broader base of users.
However, as a corollary, it's also important to remember that CAPTCHAs have historically served the purpose of limiting automation. I'm not likely to be any more friendly to automation, even with the policy change we're discussing. If anything, the whole point here is that one human being can play two accounts at the same time in a meaningful way (management on a capship, then flying a fighter or mining craft, or running two trade-ships at the same time, whatever).
It's also worth keeping the above linked EVE video in mind: a lot of the players they ban for automation are only doing this on a subset of their accounts. Their "mains" are legitimate, but they run some alt with automation on a separate account over a VPN, and think no one will possibly be able to figure out that they're related. But EVE detects and bans all the related accounts. This kind of thing happens to us too, and will inevitably happen again.
I'm not likely to ever be positive about automation that isn't an explicit gameplay feature (like the capship remote-command set), as VO is a game for humans. Conversely the existence of the plugin API is not and never shall be an excuse for full-bore-gameplay-automation (hence the removal of the original /displayshippos, and the banning of autopilot systems, decades ago).
At any rate, I think clarity on all of these topics, and policies, will make things better for everyone: Eliminate player-vs-player accusations, make the "playing field" as clear as possible, and similarly give no excuse to those who choose to cross the red lines and get themselves banned.
Why not set the limit to 1, but allow up to 2 concurrent logins for the same account from the same IP? Maybe expand characters per account. Maybe this is a semantic difference (since "login" and "account" are synonymous at this juncture) but it's clean and clear: one account per person, 2 simultaneous logins per account. Alt characters are fine, alt accounts are bannable.
But that's just me. I've been playing off/on on a single account for...22 years :O
But that's just me. I've been playing off/on on a single account for...22 years :O
Well, like you say, it is a bit a semantic difference. Mandating two accounts means that people don't have to consolidate all their characters to one account, nor do we have to build special-case features for expanding the account limit. But, more fundamentally, as I wrote in the first post at the start of the thread..
* Why two accounts?
It's challenging for us to adapt the game client to control more than one character at the same time, there's just a lot of code assumptions in there. And I know there are valid reasons to use concurrent accounts for gameplay, like capship + fighter control (even if, perhaps, that's been a bit mitigated by our built-in capship automation).
It's simplest it just keep using the same mechanics we already have. Plus, the whole "per IP" thing isn't always that relevant. Also, a given user may want to play with pair of phones on a cellular connection, where both have unique IPs.. trying to do that on a single account would be a bit odd, we'd have to have some separate "instance" system. There are a lot of different types of networks in the world, and not everyone has wifi at home (particularly in the developing world).
To be clear, I don't know for sure if my proposal is going to be the "best" solution or not. It's just the simplest that tries to set a clear on-going policy, and give us a place to work from, without incurring a lot of development time or additional overhead right now.
* Why two accounts?
It's challenging for us to adapt the game client to control more than one character at the same time, there's just a lot of code assumptions in there. And I know there are valid reasons to use concurrent accounts for gameplay, like capship + fighter control (even if, perhaps, that's been a bit mitigated by our built-in capship automation).
It's simplest it just keep using the same mechanics we already have. Plus, the whole "per IP" thing isn't always that relevant. Also, a given user may want to play with pair of phones on a cellular connection, where both have unique IPs.. trying to do that on a single account would be a bit odd, we'd have to have some separate "instance" system. There are a lot of different types of networks in the world, and not everyone has wifi at home (particularly in the developing world).
To be clear, I don't know for sure if my proposal is going to be the "best" solution or not. It's just the simplest that tries to set a clear on-going policy, and give us a place to work from, without incurring a lot of development time or additional overhead right now.
When I mentioned *never* seeing a captcha, I was more talking about the current state of things. I personally haven't seen any captchas for a long time. Ideally that would continue, but I do understand the "this is why we can't have nice things" concept when it comes to bad actors, and it is what it is.
Certainly the current use-cases for captchas to prevent automation even within the 2-concurrent-account policy are still good. I certainly wouldn't take a 2-account policy as permission to automate using 2 accounts. My concerns were more along the lines of new captchas being added at login or otherwise when switching between accounts regularly.
I would be happy to have a linked account requirement if it helps with detection/enforcement. Ostensibly the idea would be that players should link all of their accounts and the game would physically prevent more than 2 concurrent logins between linked accounts? If the policy is that players will be required to link all of their accounts, I'm not sure that requiring being subbed to link makes sense though, since a lot of us have tertiary+ accounts that aren't heavily used on a regular basis, or accounts where the point of having them is to play with limited resources, where subbing doesn't really make sense, and a linked account policy doesn't really accomplish its goal if players have some linked accounts and some unlinked accounts (like EVE and other games where players try to keep their main accounts "clean" and bot/automate on throwaway accounts). There's also a concern of multiboxing becoming somewhat "pay2win" if linked accounts have to be paid. I'm aware that ultimately it will still come down to other methods of detection, since bad actors aren't just going to voluntarily link the accounts they intend to use illicitly, but a linking system couldn't hurt.
I definitely agree that clarity and an objective standard are beneficial for everyone who wants to play legitimately, whether they multibox or not.
As far as /displayshippos is concerned, I heard there's an excellent plugin that adds that feature back for the hippo enjoyers out there... ;)
Certainly the current use-cases for captchas to prevent automation even within the 2-concurrent-account policy are still good. I certainly wouldn't take a 2-account policy as permission to automate using 2 accounts. My concerns were more along the lines of new captchas being added at login or otherwise when switching between accounts regularly.
I would be happy to have a linked account requirement if it helps with detection/enforcement. Ostensibly the idea would be that players should link all of their accounts and the game would physically prevent more than 2 concurrent logins between linked accounts? If the policy is that players will be required to link all of their accounts, I'm not sure that requiring being subbed to link makes sense though, since a lot of us have tertiary+ accounts that aren't heavily used on a regular basis, or accounts where the point of having them is to play with limited resources, where subbing doesn't really make sense, and a linked account policy doesn't really accomplish its goal if players have some linked accounts and some unlinked accounts (like EVE and other games where players try to keep their main accounts "clean" and bot/automate on throwaway accounts). There's also a concern of multiboxing becoming somewhat "pay2win" if linked accounts have to be paid. I'm aware that ultimately it will still come down to other methods of detection, since bad actors aren't just going to voluntarily link the accounts they intend to use illicitly, but a linking system couldn't hurt.
I definitely agree that clarity and an objective standard are beneficial for everyone who wants to play legitimately, whether they multibox or not.
As far as /displayshippos is concerned, I heard there's an excellent plugin that adds that feature back for the hippo enjoyers out there... ;)
If the policy is that players will be required to link all of their accounts, I'm not sure that requiring being subbed to link makes sense though, since a lot of us have tertiary+ accounts that aren't heavily used on a regular basis, or accounts where the point of having them is to play with limited resources, where subbing doesn't really make sense, and a linked account policy doesn't really accomplish its goal if players have some linked accounts and some unlinked accounts (like EVE and other games where players try to keep their main accounts "clean" and bot/automate on throwaway accounts). There's also a concern of multiboxing becoming somewhat "pay2win" if linked accounts have to be paid.
Yeah, I've thought about the Pay-to-Win accusation that could come out of it as well. The tradeoff, though, is that it's far easier to validate someone who has monetized, and is continuing to do so on a regular basis, compared to a free account or someone who monetized only once (which can have a high propensity for fraud). A subscription gives you a established financial record on a player for (potentially) a lengthy period of time.
"Linking" would effectively be a way of creating a "compliance system" for people to explicitly register the accounts they use for multiboxing. Effectively, for us, it would be an easy way of "whitelisting" certain activity, so those accounts would be unlikely to get the same attention (or enforcement) from the various systems that would otherwise analyze behavioural and gameplay patterns.
Additionally, linking could also provide a mechanic in the event that we need to set limitation guardrails around how multiboxing can be done. For example, at the moment the proposal is that people can have "N" accounts and only play two of them at once. If that ends up becoming a problem later, there could be a limit that one can only link up to "X" accounts.. whatever number that is, to set a limit on the total number of characters that could be utilized for multiboxing. As always, this will be a work in progress as new problems emerge.
For instance, say we increase the complexity of the economy, and someone decides to then multibox 25 accounts so they can place characters in every single station, rapidly iterate between them and execute some kind of arbitrage scheme. That exceeds the purpose of what we're trying to allow here. This is really for traditional gameplay, and giving people the opportunity to run two accounts at the same time. Anything that starts to smell like automation or "high frequency trading" or other weird schemes and I'm going to have a problem with it. Account linking could be a system to help address those scenarios.
Yeah, I've thought about the Pay-to-Win accusation that could come out of it as well. The tradeoff, though, is that it's far easier to validate someone who has monetized, and is continuing to do so on a regular basis, compared to a free account or someone who monetized only once (which can have a high propensity for fraud). A subscription gives you a established financial record on a player for (potentially) a lengthy period of time.
"Linking" would effectively be a way of creating a "compliance system" for people to explicitly register the accounts they use for multiboxing. Effectively, for us, it would be an easy way of "whitelisting" certain activity, so those accounts would be unlikely to get the same attention (or enforcement) from the various systems that would otherwise analyze behavioural and gameplay patterns.
Additionally, linking could also provide a mechanic in the event that we need to set limitation guardrails around how multiboxing can be done. For example, at the moment the proposal is that people can have "N" accounts and only play two of them at once. If that ends up becoming a problem later, there could be a limit that one can only link up to "X" accounts.. whatever number that is, to set a limit on the total number of characters that could be utilized for multiboxing. As always, this will be a work in progress as new problems emerge.
For instance, say we increase the complexity of the economy, and someone decides to then multibox 25 accounts so they can place characters in every single station, rapidly iterate between them and execute some kind of arbitrage scheme. That exceeds the purpose of what we're trying to allow here. This is really for traditional gameplay, and giving people the opportunity to run two accounts at the same time. Anything that starts to smell like automation or "high frequency trading" or other weird schemes and I'm going to have a problem with it. Account linking could be a system to help address those scenarios.
"Someone decides to then multibox 25 accounts so they can place characters in every single station, rapidly iterate between them and execute some kind of arbitrage scheme."
That's eve online in a nutshell and yeah we're way better off not going there...
I'd be partial to enabling logging into multiple characters with a single account and enacting/enforcing a strict one account:head policy providing additional character slots as a one time purchase option.
(instead of subscription benefits being specific to the account they'd be assigned to a given number of characters with the premium sub applying to up to three characters and the lite sub only applying to 2 chars or something to that effect)
With that suggestion in mind some changes to the subscription's features would be in order and capship shenanigans could be put behind a monthly subscription premium/addon that way multiboxed capship shenanigans at least have the side effect of at least bringing in a bit more revenue.
I figure going that route would enable more flexibility in your pricing structure too.
That's eve online in a nutshell and yeah we're way better off not going there...
I'd be partial to enabling logging into multiple characters with a single account and enacting/enforcing a strict one account:head policy providing additional character slots as a one time purchase option.
(instead of subscription benefits being specific to the account they'd be assigned to a given number of characters with the premium sub applying to up to three characters and the lite sub only applying to 2 chars or something to that effect)
With that suggestion in mind some changes to the subscription's features would be in order and capship shenanigans could be put behind a monthly subscription premium/addon that way multiboxed capship shenanigans at least have the side effect of at least bringing in a bit more revenue.
I figure going that route would enable more flexibility in your pricing structure too.
i really like the sound of some kind of whitelisting.. because unlike the others.. im inundated with captchas in my main account, and always have been.. minus the short period where i received support.. as many as two an hour. i understand that its "my own fault" but.. its frustrating at the best of times, i get them frequently midbattle and in situations where i should really never see them. i have trouble filling them and the results are not great. im in the game a *lot* and will continue to be... im not a bot i just dont sleep lol
I'd be partial to enabling logging into multiple characters with a single account and enacting/enforcing a strict one account:head policy providing additional character slots as a one time purchase option.
So.. you're saying any given subbed account would have access to multi-boxing only a limited number of its character slots? Or it would just have less character slots and others would need to be unlocked with one-time fees? Or what, exactly? I'm not quite following your proposal.
i really like the sound of some kind of whitelisting.. because unlike the others.. im inundated with captchas in my main account, and always have been.. minus the short period where i received support..
Whitelisting for multi-boxing is not the same as issues around automation. So, this isn't a solution to your problem. But, you could always open a ticket? We'll likely improve our automation detection as well, that's just a different topic from this thread.
So.. you're saying any given subbed account would have access to multi-boxing only a limited number of its character slots? Or it would just have less character slots and others would need to be unlocked with one-time fees? Or what, exactly? I'm not quite following your proposal.
i really like the sound of some kind of whitelisting.. because unlike the others.. im inundated with captchas in my main account, and always have been.. minus the short period where i received support..
Whitelisting for multi-boxing is not the same as issues around automation. So, this isn't a solution to your problem. But, you could always open a ticket? We'll likely improve our automation detection as well, that's just a different topic from this thread.
Yep sounds like you got the jist of it fron what i gather.
It would require reworking a bunch of stuff ranging from the launcher to the login screen depending on how one goes about it and also more or less overhauling the pricing structure but at least it would help mitigate creating accounts willy nilly since paying for a sub would grant logging in simultaneous charachters and stuff.
It would require reworking a bunch of stuff ranging from the launcher to the login screen depending on how one goes about it and also more or less overhauling the pricing structure but at least it would help mitigate creating accounts willy nilly since paying for a sub would grant logging in simultaneous charachters and stuff.
since paying for a sub would grant logging in simultaneous charachters and stuff.
Er.. is this back to the "connect to a single account and play two characters at the same time" thing again? That's like.. a complete paradigm break of our entire login structure (I mentioned that in the OP).
I also don't get what this has to do with the Launcher, at all.
It would be helpful if you could carefully explain your proposal in some detail?
Er.. is this back to the "connect to a single account and play two characters at the same time" thing again? That's like.. a complete paradigm break of our entire login structure (I mentioned that in the OP).
I also don't get what this has to do with the Launcher, at all.
It would be helpful if you could carefully explain your proposal in some detail?