Feedback:User/Dmitri Fatkin/The drawbacks of permitted multi-boxing in MMOGs
The drawbacks of permitted multi-boxing in MMOGs
| |
|---|---|
| User | Dmitri Fatkin |
| Categories | Mechanics → Game features |
The initial roots of this article lie in the observations I've made while visiting various online gaming services, among which were Blizzard's early Battle.net network & ArenaNet's domain for the original Guild Wars. In this essay I'll try to explain of why if a certain development group or a company proceeds with foundation of the network core for their own game, it's essential to account all the troubles the absence of application's multi-launch restriction can, and potentially will pull out on the surface. At first glance, the ability to start a second instance of an application through the means of exactly the same user's credentials and computer hardware doesn't seem as something which can unleash a rain of disasters for the game's economy, character ranking system, the ladder and gameplay in general, and yet - almost all of my extensive personal experience: dating from the ages of when StarCraft 1 has saw its sunrise as an e-sports discipline in Korea and Mpath Interactive's MPlayer.com network was still around, and - up to the days of when Guild Wars 1 was haphazardly put on automation without performing substantial part of the necessary estimations in regards of where the weak spots of the project in terms of possibility of unfair play were, just screams for the fact that whenever someone starts building up a gaming application which technically allows to track down the user's exact hardware under which a connection with the server is established, it should undoubtedly be placed among mandatory development elements with a grade of importance no less than security in data exchange protocol itself.
Why? Because in the end, if the second connection isn't going to be severely-restricted, or, what's more preferable - entirely-rejected, in all circumstances where developers don't dispose the capacity of involving multiple administrative staff members into monitoring the events occurring in-game, the whole stage of events will quickly transform into this: the usage of up to 15+ externally-injected instances of the application on a single PC with the only goal of obtaining profits from activities exercised entirely on scripts, the appearance of alternate, "dummy" customer records with the aim of setting up bogus, thrown-up matches with immediate reflection on the affected ladders, the emergence of generally-unfair play, where dummy accounts will be used against other players to forementioned owners' advantage, the excessive flood of the market with previously-rare items, naturally resulting in escalation of associated prices; and - many, many other things, not mentioning the overall belittlement of prestige the game's rewards were originally meant to provide.
And, while the users are admitted to involve such means of transferring items between multiple accounts instead of resolving the associated necessities through the utilization of an in-game mail system, this presumably one of the largest loopholes which can exist in online entertainment services will result in negative consequences for those who have chosen to engage legitimately in offered gameplay. That's why one should think really carefully of how exactly hardware detection system will be implemented in the project he/she is working on and what kind of restrictions for secondary connections are going to be in place.
In the end, the impact the absence of such restrictions produces doesn't vary greatly despite whether we're talking of Guild Wars 1, Guild Wars 2, World of Warcraft, Lineage II or any other title. However, if development resources required to implement the associated items transfer storage (which grants the access to a shared depository space upon the approval from both accounts) or the mail system which permits sending a certain amount of items within a day from one account to another are beyond the attainable, an alternate workaround is applicable. It consists of creating a certain database entry counting the amount of minutes an account is allowed to spend online while operating under a secondary, made with exactly-the-same hardware connection. In case of Guild Wars 1, that mark should be set to 30 minutes, after which the limit is exceeded and no further connections from the account are allowed while another instance of similarly-matching Hardware ID is active within the system. This column should be reset once in a day, letting any account have a small amount of time reserved to perform tasks such as transfer/acceptance of various items while acting as "an alternate one". I suppose there's no need to mention that the 3rd and so forth connections made from the same Hardware identifier should never be accepted.
And regardless of how secure we think the interaction between client and server is, we should always keep in mind that the ones looking to exploit shortcomings within the system are most-likely to pick the least effort-demanding routes, which was proven numerous amount of times in the last nine years of operating history belonging to this project.
