7.1. PiaSync Overview

The PiaSync (SyncProtocol) module provides a way to synchronize user input (key synchronization). This model is common in multiplayer games. As long as the following three conditions hold, you can synchronize the states of each station just by communicating user input data.

  1. The states are in sync when synchronization starts.
  2. Synchronization starts simultaneously on all stations.
  3. The game processes identical user input data (both content and order) simultaneously on all stations.

This document describes the main features of the PiaSync module: synchronizing the timing of game frames, and synchronizing user input content.

Synchronizing Game Frame Timing

The game frame timing synchronization in PiaSync is simple. Assuming that all stations are operating at the same frame rate, synchronization on a game frame level is achieved by creating a situation where a station that receives the nth frame data from another station treats it as the nth frame data. Figure 7-1. Synchronizing Game Frame Timing (Schematic) shows an overview diagram of synchronization when PiaSync is performed.

Figure 7-1. Synchronizing Game Frame Timing (Schematic)

Frame numbers that have already been synchronized once will generally increase at the same speed, so PiaSync timing synchronization will not be disrupted even if a particular station experiences processing slowdown and communication causes dropped frames (described later).

Each station communicates by making the decision to advance frames after input data from all stations is available, and does not advance frames if all the input data has not yet arrived. As a result, between the least delayed station and the most delayed station, it is possible to have delays amount to the number of frames specified as the input delay. However, the station with the least delay will not have sufficient data and will synchronize toward more delayed stations, and so it is autonomously adjust to reduce lag. For most cases, this lag will not be prominent.

Synchronizing User Input Data

The timing synchronization feature described previously enables each station to maintain the "user input at the nth frame." PiaSync buffers this data for several frames and then sends the buffer sequentially to other stations to create a situation where all stations maintain the data for "user input at the nth frame" for all users several frames later. Figure 7-2. Synchronizing User Input Data (Schematic) shows a simple diagram of the system.

Figure 7-2. Synchronizing User Input Data (Schematic)

Note: This diagram shows the situation when the input delay is set to three frames.
Note: While the diagram focuses only on station 1 for clarity, the processing in this figure is performed between all stations.

As indicated in Figure 7-2. Synchronizing User Input Data (Schematic), the user input data is buffered for several frames (a number specified by the application) in PiaSync, and these buffers are sent or received sequentially to and from stations other than the location station. Each station includes data about which frames they have received. To reduce the send data volume, data for frames that all stations have already received is not sent. This allows the station to maintain the latest user input from its own users and recent user input from other stations. PiaSync provides an application for all user input to match the timing of these buffers.

Note:

"m frame delay" in PiaSync means "use the data set for the nth frame for the (n+m)th frame". This "nth frame" indicates the synchronization frame rather than the game frame. Note that if the synchronization frame for a game is the nth frame and the synchronization frame advances due to SyncProtocol::Step after setting data, the data from the (n+1)th synchronization frame will be available.

In general, PiaSync is used to exchange controller input (such as key input, touch panel input, and motion), but you can synchronize any type of data using this module.

Setting the Type of User Input Data To Send

PiaSync can assign different data IDs to each category of data sent or received by your application. You can set different data IDs for the data to send for each station when starting synchronous communication, and that information is shared with all stations. For this reason, the types of data that are sent by each station do not have to be the same. For example, even in cases where each station sends different input data, such as one station sending key data while another sends motion data, setting send data IDs for each station makes it possible for only that particular piece of input data to be sent. When receiving data, it is possible to only get the valid data based on the data ID set by each station.

Sending and receiving only the necessary data reduces the data transmission volume and the possibility of frames being dropped.

Another possible way to use the module is by managing how controller data is transferred depending on the number of players on each station. For example, when synchronizing a game in which station A has one player and station B has two players, station A could use only data ID 0, and station B could use data IDs 0 and 1.

User Input Delay

The optimal input delay differs depending on the latency between the local station and the communication target. PiaSync provies a feature to change the delay value not only when starting synchronization but also at any time during synchronization. The advantage of this feature is that the game application can use it to reduce lag to a minimum, but at the same time there is the disadvantage that the amount of delay changes each time the user plays. In addition, the PiaSync algorithm interpolates the data from the next packet that is received even when there is packet loss, so the greater the input delay setting value the less likely dropped frames are to occur from packet loss.

For these reasons, consider factors such as communication latency, packet loss rate, and the feel of online gameplay when determining the delay value.