Seaside Laboratory

In GGPO, the local actions performed by the player always happen instantly, and are always correct. This is a great property to have, as the responsiveness of the avatar to the controller is often the most important aspect in the player's enjoyment of the online experience.

Furthermore, any long-term effects caused by remote players whose inputs have already been received are also correct. For example, if your opponent in Street Fighter threw a fireball at you a few frames ago, the behavior of that fireball is completely deterministic and cannot be affected by your opponent's future inputs. Therefore, the fireball will appear to move correctly immediately after your local simulation state has determined that the player actually did throw the fireball. This makes the timing and experience of dealing with a fireball online identical to the experience offline, which is important, as dealing with fireballs is a major part of Street Fighter!

Similarly, opponents usually cannot change the arc of their jumps after initiating them, so dealing with your opponent descending from a jump, perhaps with a well-placed Dragon Punch, is identical both online and offline. So if everything appears to be correct all the time, where'd the latency go? The latency is hidden in the window between when your opponent initiates an action and your simulation realizes that an action was performed. The time lost in that window is effectively skipped to your simulation. For example, suppose both you and your opponent are playing a game of Street Fighter on a network that takes 60ms to send a packet from one console to the next. When your opponent executes a move, his simulation will process the controller inputs immediately. To him, the move comes out right away, since local inputs are sent to the simulation immediately and are always correct. Your simulation, however, will not notice that your opponent performed a move for another 60ms, when a packet arrives from the network carrying that input. When it does, GGPO will instruct the game to rewind 60ms, correct your opponent's input, and fast-forward the game simulation 60ms back to the current time. As a result, on your console you will not see the first 60ms of animation of whatever your opponent did. It is as if the move began 60ms into the animation, from your perspective.

This is not ideal, but the alternative is to delay the entire simulation by 60ms, including local inputs. In practice, losing those 60ms of animation usually results in a greatly preferable user experience. This is partially due to the greatly increased responsiveness of local actions, but is also because most of the time those 60ms just don't matter that much. To illustrate this, let's look at a specific example.

Most attacks in Street Fighter have three phases: start-up, execution, and recovery (see Figure 4). The start-up of a move is how long a move takes to become active after the user presses the button. While there is usually some animation state associated with the start-up of a move, the move isn't actually doing any damage yet. The serious business happens in the execution window; if the opponent overlaps your move's active region at any time during the execution window, the game simulation will register it as a hit. A hit causes the simulation to start new animations, play audio, subtract some life from your opponent, and lots of other effects. It's a big deal as far as simulation state is concerned. Recovery is simply the duration after a move executes before you can perform another one. These numbers are usually measured in frames, and the first thing competitive Street Fighter players do when a new game comes out is to mine the frame data for every move in the game to begin researching tactics. If we look at the frame data for one of the most beloved and fastest Street Fighter games on the market, Super Street Fighter ii turbo (http://nki.combovideos.com/flame.html), we see that a vast majority of the moves have a start-up of at least four frames (or 66ms). That's incredibly important to us, because it means that on a 120ms ping connection, it's possible to resolve almost every rollback before the execution of a move, which means that the visual and audio glitches that result from incorrect predictions are almost always limited to the animation of the start-up of a move, not the result of hitting your opponent. Modern broadband connections from Los Angeles to New York typically have a faster ping than 120ms. In fact, anecdotal evidence shows that GGPO's techniques scale well up to latency experiences on broadband connections worldwide;

A good prediction algorithm can minimize the visual glitches that can occur during a rollback. The prediction algorithm's job is to anticipate the player inputs arriving from the network at frame N + (L / F) given the inputs for all previous frames 1...N, where N is the input last received from the remote player, L is the one-way packet transmission time, and F is the frequency at which the game executes its game state.

The quality of the prediction algorithm is a function of the frequency and severity of the rendering glitches caused by a missed prediction. For example, in a game of PONG, a misprediction will cause the opponent's paddle to jump to a new position on the screen. Getting the paddle position wrong is important, of course, but an algorithm that is always wrong but only off by a few pixels is preferable to one that is only wrong 10% of the time but causes the opponent's paddle to jump by one-quarter of the screen length.

Naturally, the best-possible prediction algorithm is game-specific, and probably player-specific as well. GGPO's built-in algorithm is designed to work well with fighting games and beat-'em-ups, though it should work equally well for shooters, maze-solving games (PACMAN, GAUNTLET) and most other arcade games. To date, no developer who has used GGPO has seen the need to implement his own prediction.

The built-in prediction algorithm assumes future inputs will be identical to the inputs most recently received from the remote player. This caps the number of prediction errors to the number of times the input state changes per interval. While simple, this has proved to work quite well in avoiding the most jarring visual effects. For example, the character moving backward or forward will often cause the screen to scroll left or right. Getting that position wrong will result in the entire screen jumping to the left or right during a rollback. By assuming the joystick remains held in one direction, we ensure that the screen scrolls smoothly in the most common case: running to the right. The worst case (rapidly toggling the joystick from left to right) seldom occurs in actual gameplay.

Time-permitting, it may be preferable to use the game-state of the previous 1...N frames to provide a better prediction algorithm than the one built into GGPO. For example, in a game of Pong, it might be better to predict that the remote opponent will always move their paddle in a manner to intercept the ball, regardless of their previous inputs. In practice, however, incorporating the possibility of a misprediction into the design of the game to minimize the effect of a rollback has a better payoff, as it's impossible to completely eliminate them. For example, if you have a screen-scroll effect when a player moves on the screen, consider basing it on the average position of the player over several frames or the position of the player K frames ago (where K >= the expected latency in a game), which will minimize (or completely eliminate) the screen-jumping glitch during a rollback. If you have any effects that start on the first frame of execution (e.g. a dramatic screen blackout starting a Super Combo in a fighting game), consider starting the effect on the Kth frame instead of the 0th frame so that the effect is always based on confirmed inputs instead of predicted inputs. Obviously, there is some give-and-take between the responsiveness of the game when played offline and the smoothness when played online using GGPO, but it is an option for designers.