Game Architecture and Packet Analysis

This page contains links to videos and packet captures from their respective games. While the overall results of these comparison experiments are inconclusive, observing how various fighting games tackle their netplay architecture is still an interesting endeavour.

Videos were captured using Open Broadcasting Software. The packets used for analysis were captured using Wireshark. To force unfavorable latency where normally unavailable, the tool Clumsy was used.

Using Clumsy to Force Unfavorable Latency

Clumsy is an open-source tool that uses the WinDivert library to interact with packets. Clumsy can be found here. A demo of Clumsy's interface can be seen in the following GIF.

The primary features used in the following tests were forcing lag and dropping packets. Attempting to use the other features resulted in undesired game crashes.

Equivalents of Clumsy are readily available for other operating systems as well. For similar functionality in OSX, you would want to use Network Link Conditioner. For Linux, netem would be the tool of choice.

Analysis on Skullgirls

Skullgirls uses peer-to-peer for all of its netplay functionality and uses UDP to transmit all packets. This is partially due to the usage of the GGPO middleware for part of its network stack. When playing online, players can participate using Tournament Mode, Local Only (for LAN tournaments/games), Quick Match (random matches against other online players) or Lobby Play. For the purposes of this project, Lobby Play was setup with a peer in Australia for stress testing Skullgirls' usage of GGPO.

Packet Capture Analysis

• two packet capture files taken, total size of 33MB from 9 matches
• packet lengths in 40-319 range, 90% are in 80-159 range
• 10.75% of packets had to explicitly traverse through NAT, assuming this to be lobby setup and idling
• while users in lobby, PING/PONG messages periodically sent between lobby members as a keep-alive

Video Highlights

The following list of links showcases the notable test matches played.

1. 223ms, frame delay set to 8 on both sides
2. 243ms, frame_delay set to 0 on both sides
3. 380ms, frame_delay set to 8 on host side.Game saw longer load times and match ending discrepancy
• Match end discrepancy mentioned above
4. 400ms, frame_delay set to 0 on both sides. Lots of frame skipping and sound duplication can be seen.
5. 223ms, frame_delay set to 0 on both sides. Packet loss of 20% forced on host end.
6. 320ms, frame_delay set to 5 on host side. Game is slightly smoother but slow-paced with infrequent input drops.

Attempts at matches with more than 20% packet loss were made, but the game would crash either on attempts to load or during the game. Attempts above 400ms also resulted in similar crashes.

Analysis on Street Fighter V

Attempts at analysing Street Fighter V's traffic were not as successful. Information regarding Street Fighter V's server setup were gathered but analysis from the actual matches is unreliable.

Assumed Server Architecture

On starting the game, the following server information is sent to the Steam client as a JSON message.

• "Game": {"DNS": "api.prod.capcomfighters.net", "Port": "80"}
• "STUN1": {"DNS": "stun1.prod.capcomfighters.net", "Port": "23478"}
• "STUN2": {"DNS": "stun1.prod.capcomfighters.net","Port": "33478"}
• "Message": {"DNS": "message.prod.capcomfighters.net","Port": "20002"}
• "File": {"DNS": "fdlcdn.prod.capcomfighters.net","Port": "80"}
• "Proud": {"DNS": "209.58.132.134","Port": "30850"}

Of note is that the "game" server they have set up on port 80. This demonstrates that Street Fighter V may use a server/client model for some of their online play. Tests were inconclusive on this front as only lobby play was tested, from which the majority of traffic was UDP traffic. However, from packets alone we were unable to discern whether this was peer-to-peer traffic or a server/client model. The above JSON response suggests that there are game intermediary servers being used, but in our lobby play the UDP traffic was exchanged directly between peers. Although this makes the comparison to games with GGPO unfair (one uses an authority server and one does not) the findings from games played are still relatively interesting.

Game Setup and Idling

Street Fighter V uses a combination of server/client architecture alongside peer-to-peer in lobby play. For authentication purposes, Capcom uses a network they call the Capcom Fighter Network (CFN). Players that wish to participate in online play register their desired username and country. This lets players mark "favorite" players that they can send quick lobby requests to, and allows for searching of players using various criteria. The CFN player list is infrequently updated - while unsure on the exact refresh period, the playing partner selected for tests was unable to find my CFN ID when searched for. However, no restrictions were on the new player for searching for players and inviting players to lobbies. Since gameplay was conducted over the course of an hour, this suggests the list of players registered in Capcom's Fighter Network could be refreshed only once or twice per day.

To keep consistent with the Skullgirls tests, only lobby play was tested. The game also offers matched casual play and matched rank play. While idling in the game (whether in a lobby or on the main menu) the following heatmap can be seen in the background.

This heatmap is periodically updated from Capcom's fileserver through the following HTTP request:

While sitting in the lobby with a peer, the following datagrams are sent back and forth directly between peers.

Videos from Street Fighter V

The following videos highlight some of the difficulties encountered when analyzing Street Fighter V's gameplay. All videos were conducted with a peer in Seattle, minimizing the distance between players. Unfortunately audio was not captured during testing, but any latency/packet loss issues are noticeable without audio.

• First game played.

This game was conducted with minimal background traffic and appears to be smooth.

• Second game played.

This game was conducted while in a Discord server with the opposing player. The packet drop rate was highly noticeable starting from the menus.

• Third game played.

Same conditions as previous game, packet drops were still noticeable but not as severe as the previous match.

The unreliable gameplay seen in the last two clips may have been a result of a variety of factors. We were unable to test many of our initial thoughts on fixes, as the Capcom Fighter Network had not updated with my ID yet. This prevented us from switching lobby hosts to see if we could "restart" from a more reliable point. Furthermore, as seen from the heatmap above there was "noisy" traffic occuring in the background of the game by default.