The lack of direct twitch-based controls in EVE is often cited by gamers as a big part of the reason they can't get into the game. There's no active dodging of missiles, manual ship targeting, or really complex tactical maneuvers in EVE, but that's kind of the point. Most ships in EVE are colossal lumbering hulks more akin to today's seafaring battleships than fighter planes, and combat with them is more a game of strategy and teamwork than a battle of reaction speeds. But that isn't exactly true of all ships; interceptors and fast microwarpdrive frigates move at several kilometres per second and are so agile that pilots can already pull off some interesting tactical maneuvers. So isn't it about time we made the combat for those ships a bit more visceral and immersive?
In this week's EVE Evolved, I look at the fast-paced world of interceptors and explore how twitch controls and weapon aiming could possibly be implemented without killing the server.
Why interceptors should get direct controls
Interceptors are the speed-demons of EVE, able to move at several thousand metres per second and complete clever high-agility maneuvers like the zig-zag approach and corkscrewing to avoid turret fire. But these moves are bloody hard to pull off, usually involving spinning your camera around and quickly double-clicking on the right parts of the screen at the right time. This isn't quite the same as taking direct control of your ship, and as defensive maneuvers, they're effective only against turrets.
You can avoid being hit by turrets by keeping your transverse velocity relative to the turret ship higher than the enemy's tracking speed, so dodging left and right as you close the gap will stop you from being shot out of the sky. There currently aren't any mechanics for dodging missiles and drones other than just moving very fast; missile damage decreases against fast-moving ships and drones can be outrun and then shot down. It's here that twitch controls could really pay off and provide a more immersive game experience, but the problem developers have always faced with this idea is that the server just can't handle it.
How the server currently handles ship movement
When you double-click in space, the client currently tells the server what direction to move in as a linear vector, and then the server sends the data out to all other clients in the area. The clients then appear to use it in a dead reckoning algorithm that predicts where the ship will be in between position updates from the server in order to provide the illusion of smooth movement. Because ships don't change direction frequently in EVE, the server currently doesn't need to send updates about ship position very often. That's part of the reason EVE can handle battles with large numbers of pilots involved even though server load scales up exponentially with the number of players involved.
My understanding of how EVE's server works under the hood is mostly from old devblogs, and things may have changed a lot since they were published, but as far as I know, EVE still works with only linear ship movement vectors. That means direct flight controls can't simply be inserted into the game, as smoothly turning in one direction or another would produce a rapid stream of new linear vectors and the number of updates required per second to produce smooth movement from that would be far too high. The server not updating quickly enough is what causes rubber-banding in games, and you can sometimes see it in EVE if an agile ship rapidly changes direction while the node is laggy. That's the reason that's normally given for why twitch controls wouldn't be feasible in EVE, but there may be a way this could be accomplished with very little impact to the server.
Moving with predicted curves
When you think about it, there's actually no reason that the server and client have to calculate or predict movement in straight lines. Instead of sending the server a linear vector indicating the new direction to move in, what if the client were to just send a vector indicating a rotation on the X, Y, and Z axis based on which controls are being pressed? The server could then send that information to all nearby clients, and the clients could then predict ship movement as an extrapolated curve rather than a straight line.
The server already seems to calculate ship movements in curves when a player with inertia changes direction, though this may just be a sum of input linear vectors and drag effect on existing velocity. EVE's physics engine currently ticks on a one-second heartbeat, so new resultant vectors can currently be sent to the clients only that frequently. If the client were receiving updates on ship rotation instead of linear heading, it would likely be rolled into the physics update frame and updated only once per second. That means a direct control scheme would still be limited to changing direction once per second, but that actually might not be a big deal.
Watch someone play a dogfighter like EVR and see how often he actually changes the direction buttons being held; it's surprisingly only once every few seconds. Players tend to hold buttons down for long durations to do big sweeping turns, and smaller course corrections are infrequent by their very nature. As long as the interceptor turns slowly enough that big turns take a few seconds and there's a system in place to roll small course corrections under one-second long into the physics update, there shouldn't be any rubber-banding.
Immersive targetting, afterburners and evasive maneuvers
If twitch controls ever do come to EVE's smaller ships, it's clear that developers must create an option for players to switch it on for small engagements and off for fleet battles. What I'd love to see is a direct flight module that acts like a siege mode for interceptors, switching the way the ship works. The camera could be locked behind the ship for a more hands-on feel, and a targetting reticule could even appear in the middle of the screen and highlight whatever ship is closest to the centre. Then you could have a shortcut key or button on a game pad that targets the highlighted player and if necessary unlocks the oldest target you have locked to make room.
Modules like afterburners could be loaded with evasive maneuver scripts that program in a set of timed course changes. The idea here is that the server and every client knows exactly how the command is executed, so it can accurately compute the entire course in advance without needing to send or receive every little course correction from the server. The script could even have pre-programmed sections of "dodge bonuses" in the form of a temporarily reduced signature radius. The speed boost then becomes an immersive defensive tool as well as an offensive one.
This kind of system would invariably produce some additional lag, but it shouldn't be much more than people changing direction once per second. If it were limited to just interceptors, the impact to the server would be further reduced. The main problem in this system is that time dilation can slow systems down to as low as 10% normal speed during large fleet fights, which wouldn't feel very hands-on. What do you think? Could direct flight controls improve interceptors, or are tactical maneuvers like the Zig-Zag enough twitch for you? And is there a feasible way to implement twitch controls without the server grinding to a halt?
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.