Analysis on GGPO Middleware

GGPO, short for "Good Game, Peace Out" is a middleware suite designed with fighting games in mind. It was developed by Tony Cannon, a member of the Shoryuken online fighting community. The functional part of this middleware (where the magic happens) is closed source, but the section of code pertaining to the GUI for its client can be found at this GitHub repository. The GGPO middleware is an attempted solution at providing a smoother online experience for peer-to-peer fighting games. This section goes through two parts:

1. how the middleware is structured
2. a high level overview on how the middleware operates.

Structure of GGPO Middleware

This software sits at the network layer behind the desired game. It was not designed for any one game in mind, but instead to allow netplay for a wide variety of fighting action games. Its primary functionality is twofold:

• it offers older, emulated games a chance at reliable netplay
• it lets game participants set a frame delay for matches to try and smooth out gameplay

The second point is of more interest here, as this is what middleware like GGPO attempts to use to differentiate itself from regular netplay. Before starting a match, each client can select a frame delay with which they're comfortable using. This delay is selected from a range of 0 to 8 frames. A frame delay of 0 would let the game behave as normal, where the max possible delay of 8 means both clients have any inputs delayed by 8 frames before being processed. From preliminary tests, the middleware selects the higher of the two frame delays. So if one client selects 0 frame delay and the other selects 5 frames of delay, the game proceeds with 5 frames of delay. This means the games are still subject to latency, packet loss and other network issues but the overall experience can still feel smoother than a game just randomly dropping inputs.

From here, the game uses a process called speculative execution to try and eliminate perceived input delay. Tony Cannon explains how this process works in this interview with writers at Gamasutra. The main idea is that in combination with the frame delay set previously by players, the GGPO middleware predicts inputs before they occur based on previous actions. When inputs are actually received, they are compared to the predicted inputs. If any discrepancies occur, the middleware "rolls back" its simulation to the first incorrect frame and corrects using the received inputs.

Another explanation on how GGPO functions with respect to frame delay can be found from this blog post written by a developer of Skullgirls.

One very important side effect of using this middleware is that games using this middleware must use a peer-to-peer architecture. You can use any protocol to send packets, but the packets have to be sent and interpreted by each client directly. Games using GGPO cannot use a server/client architecture and any benefits associated with using such an architecture.

GGPO's primary functionality relies on an archive named "ggpo-build-030.zip" as per the last GitHub update from above. To ensure the middleware functions out-of-the-box, both users need to perform the following tasks:

• UDP ports 6000-6009 (inbound/outbound) and TCP port 7000 (outbound) opened in home network
• Adobe Air installed on machine
• GGPO account registered if needed, no longer possible with site being down

However, the site they link as a source of the archive, ggpo.net, has been disabled indefinitely.

For the purposes of analysis, a copy of the archive was found on a 3rd party rehost. The archive's contents and structure can be seen in the following image.

As seen at the bottom of the screenshot, this middleware also includes 4 DLLs that hold the majority of its functionality:

• ggponet.dll
• kailleraclient.dll
• mfc80u.dll
• msvcr80.dll

The first two DLLs here are of higher interest, as msvcr80.dll and mfc80u.dll both contain typical Windows function calls.

Purpose of DLLs in GGPO

These DLLs were created from Visual C++ source code. Because of this, Visual Studio's dumpbin tool was used to dump function information from both ggponet.dll and kailleraclient.dll. The functions found from each can be seen below.

ggponet.dll:

• ggpo_advance_frame
• ggpo_client_chat
• ggpo_client_connect
• ggpo_client_set_game_event
• ggpo_close_session
• ggpo_get_stats
• ggpo_idle
• ggpo_log
• ggpo_logv
• ggpo_set_frame_display
• ggpo_start_replay
• ggpo_start_session
• ggpo_start_streaming
• ggpo_start_synctest
• ggpo_synchronize_input

kailleraclient.dll:

• _kailleraChatSend@4
• _kailleraEndGame@4
• _kailleraGetVersion
• _kailleraInit@4
• _kailleraModifyPlayValues@8
• _kailleraSelectServerDialog@4
• _kailleraSetInfos@4
• _kailleraShutdown@4

From these method names, I made the assumption that kailleraclient.dll is used to handle networking functions between games and the client itself. This would include things like starting up the client, creating and managing lobbies, handling chat between connected peers and initiating games.

This leaves ggponet.dll as the primary source of our interest, as it would handle all of the in-game networking. Of note is the capabilities to advance frames, synchronize input as per the previously set frame delay, connecting peers properly before and during a game and ensuring the game stays alive for as long as necessary.