2014-01-20

Just a bit on the Problem of Soul-Crushing Lag

Lots of folks have already written about the current problems with very large fleet fights in Eve, prompted by the events in HED-GP over the weekend.

The short version: 3500ish pilots tried to pile into a single system and blow the hell out of each other and the servers simply couldn't handle it, producing an experience similar to the bad old days (tm) of three or more years ago.

CCP put a band-aid on the problem with time-dilation which, by reducing the speed of what's happening in heavily-loaded systems to as low as 10%, effectively made their servers ten times faster. Great, if the fleets never get any bigger.

But they would. Of course they would. Inevitably. With large, heavily-organized null security power blocs fleets will, as Trebor famously said, "expand to fill the lag available."

So what do you do?

Get better hardware? Unfortunately, computers aren't getting better in directions that benefit Eve's code base very much.

Make the code more efficient? They're working on that, but even if the work done is outstanding, it just puts the same kind of timer on the situation as the time-dilation fix: if the servers and/or code can handle more pilots in big fights, so those fights will inevitably grow til they hit the new crash/freeze barrier, and we're right back where we started.

Don't get me wrong: I think optimizing the code is good and valuable work, but it doesn't fix the main problem, which is that bringing more ships is always the best option if you want to win a fight

The trick to creating a truly long-term solution to this isn't to support the current best option - it's to make other options better and/or necessary.

Competing Objectives

Corelin used this phrase, and I like it. The basic idea is to create a new normal for sovereignty battles where, to put it simply, fights and other ship-based activities need to happen in multiple locations at the same time. Corelin gave the example of having the system's the TCU, IHUB, and Station all run on the same timers, rather than in sequence, so they all have to be fought over at the same time.

Personally, I'd take it further, and in directions that let you simulate the real-world factors of terrain and supply and support chains. There have been some good suggestions along these lines, but the best of them basically boil down to making sovereignty contests more like the current Faction Warfare mechanics. Instead of a single timer revolving around a single point in single system, spread those timers out to a number of locations, with the majority of those sites within size-restricted complexes. And I really do mean spread them out: to create the illusion of ‘defending and attacking supply and support lines,' you might even consider scattering those complexes all around the target system’s constellation - attackers ignore them at their peril, a properly defended complex might set the entire offensive back by resetting vulnerability timers or removing vulnerability altogether.

The size restrictions on those complexes are worth talking about as well. Size restrictions mean that some critical parts of the sov fight would be frigate, destroyer, cruiser, 'all sub-caps' fights, set up so those complexes need to be handled at the same time as each other and/or at the same time as the 'main' battle. This means that the meta of the game changes to effectively split up fleets, spread them out, and call for different tactics (and make multiboxing to get more ships on the field far less effective, since multiboxing a frigate, a cruiser, and a carrier in three different fights/fleets/systems isn't going to appeal to many people).

Obviously the whole sov process would have to change, perhaps incrementally, but it feels like the best direction for (a) more manageable per-system, per-fight load and (b) more interesting Sov gameplay.

No comments: