What constitutes an exploit?
The EVE Online knowledgebase defines an exploit as "when someone bypasses normal game mechanics, such as by utilizing a bug in the game, allowing him to take advantage of other players without them having any means of preventing it whatsoever." The key parts of this are the bypassing of normal game mechanics, a player gaining an advantage over another player, and there being no means of preventing it. The first criterion is fairly clear-cut. Since practically all of the eight-hour setup period for Test Alliance's TCUs fell within an extended server downtime, the entire attack-and-defense mechanic was bypassed for an automatic victory.
A clear advantage was created over the local IT alliance, as it would ordinarily have been almost impossible for Test to activate 14 TCUs in systems neighbouring IT simultaneously and defend them all successfully. If Test had been forced to defend its TCUs for the mandatory eight hours, it would have been limited to claiming one or two systems at a time, making its encroachment upon enemy space slow enough that the enemy would have time to mobilise and react. Setting up in downtime robbed IT of this opportunity, and that's the sole reason Test did it. IT Alliance could not have done anything to prevent the 14 claim units activating as they were anchored at the last moment and the server was not up during their deployment. According to all the criteria by which exploits are judged, this most certainly is one.
To the point of absurdity
When you're trying to determine whether something should be allowed or not, a good rule of thumb is to extend the tactic to its logical extreme and see how much of an unfair advantage it could convey. For example, imagine if this weren't categorised as an exploit and someone decided to make serious use of it against Test alliance. Before the upcoming extended downtime for the Incursion expansion deployment, a rival alliance could place pilots carrying sovereignty blockade units in every system Test owns and territorial claim units in every empty system nearby.
Just over five minutes before the servers would be set to go down, all of the SBUs could be anchored and deployed at once. After the server came up, the TCUs in every single Test system would suddenly be vulnerable, and Test would have had no opportunity to prevent it. Ordinarily, an alliance would have three hours in which to mount a defense and destroy any enemy SBUs before the claim units even become vulnerable. If the enemy chooses to defend its blockade in one system, the defenders could just go to another system and destroy the blockades there.
This mechanic makes it infeasible for an alliance to blockade more than a few systems at a time as its members must defend all of the SBUs they place while the defending alliance is free to concentrate its forces and pick one target at a time. In this hypothetical scenario, Test's enemies' abusing the extended downtime to deploy their blockade units robs Test of the opportunity to repel that first invasion wave. Test would suddenly find itself on the other side of the fence, forced to defend every system while its enemies could choose to concentrate their forces and hit any single system they liked. All the enemy need do in order to win is destroy the TCUs in a system. If gaining that kind of instant foothold isn't an exploit, then nothing is.
Accusations of favouritism
Almost immediately after GMs took action, Test pilots began spamming the forums with claims that IT Alliance had fired up the old CCP bat-signal to call in help. This has been a sore spot for EVE players because the core corporations in IT Alliance were previously in Band of Brothers alliance, the beneficiaries of developer misconduct uncovered during the T20 scandal all those years ago.
The crux of this most recent accusation rests on the suggestion that downtime deployment wasn't considered an exploit until it was used against IT. The suggestion is that IT holds some kind of sway over the developers or GMs and used that to cheat. Test further backed this up by pointing out that no other TCUs deployed during the downtime had been removed.
While I'm sure it's terribly uncool of me to suggest it, I'm pretty sure the truth is something a lot more likely and boring than the exciting headline of potential developer misconduct. The Test TCUs were removed because IT Alliance petitioned the incident and the GMs ruled in its favour. The other TCUs deployed during downtime weren't removed because nobody bothered to petition them. Once they were brought to the attention of GMs, the other TCUs that had spent a significant part of their onlining period under the protective screen of downtime were also removed. There's no favouritism here, no matter how hard you look for it.
The debate rages on
The most convincing argument I've heard from Test pilots is that this exploit has been in use for years and yet GMs have never stepped in before. People used to manually adjust the levels of strontium clathrates in their control towers to make the reinforced timer end at the start of the daily downtime, for example, giving extra time for the shields to recharge. There may even have been cases of people deploying territorial control units during previous extended downtimes. Why did GMs step in this time? Because someone petitioned it and the issue was big enough that he got Senior GM Lelouch involved.
Senior GMs are the only ones allowed to declare something an exploit and so change game policy on it going forward. Any player can ask for his petition to be escalated to a senior GM if he's not satisfied with how an issue has been handled by a standard GM; no bat-signal is required. Over the years, people have indeed used downtime for minor tactical advantages, but temporarily saving a control tower from destruction using downtime is definitely still an exploit by any definition of the word. Until now, these issues haven't been a big enough nuisance for any alliance to petition it en masse and get the senior GMs involved.
What Test did to change things was scale this practice up to the level of a full-blown invasion and use it on an alliance known to petition any time the outcome might benefit it. Regardless of the fact the systems it captured were unclaimed, Test used this exploit to capture them automatically and without resistance and stepped over that invisible line where an exploit goes from being a minor nuisance to a full-blown gameplay issue. It doesn't matter that players have previously used downtime to deploy structures -- it's ludicrous to think that abuse on this scale wouldn't eventually be challenged by someone in a petition.
Something we need to keep in mind when dealing with GMs is that they are not omnipotent. While potentially exploitative tactics might be obvious to many of us playing the game, GMs could be unaware of them until we report them via the petition system. Even then, standard GMs are often ill-equipped to deal with an exploit themselves. Ultimately, Test forced CCP's hand by deploying the tactic on a large enough scale that its enemy got the senior GMs involved. Any alliance suffering at the hands of this exploit could have done the same, and all through perfectly legitimate channels. The only reason people are crying foul in this case is that former BoB corporations happened to be pulling the plug on this exploit.
Developer or GM misconduct is a very serious thing that can cost the offender his job. Any actual evidence of it should be supplied directly to CCP's independent Internal Affairs department for investigation -- a system put in place after the T20 incident to ensure players have a legitimate way to report their concerns that can't be covered up or surpressed. Beyond that, spamming the forum and petition queue with the issue serves no purpose other than to cause drama.
Brendan "Nyphur" Drain is an early veteran of EVE Online and writer of the weekly EVE Evolved column here at Massively. The column covers anything and everything relating to
EVE Online, from in-depth guides to speculative opinion pieces. If you have an idea for a column or guide, or you just want to message him, send an email to firstname.lastname@example.org.