Synchronization Issues (Unity + Photon): Part 3
Exposing a more fundamental problem with network lag.
This article is part of the series starting with Synchronization Issues (Unity + Photon): Part 1.
The Problem
In addition to the display artifacts (delay and jerkiness) seen in the second application (the one that did not instantiate the ball), there is a more critical game play problem.
To illustrate, lets add a game object to the second application that is not present in the first application, a red wall.
We can do this by creating a prefab in the Assets/Resources folder and instantiate it by adding a method to the GameManager script.
Assets/Table/GameManager.cs
With this in place the applications behave as such:
Observations:
- The movement of the ball on the left application (instantiated the ball) is as expected.
- We clearly see that the movement of the ball is controlled by the left application, i.e., the ball hitting the red wall in the right application has no impact on the movement of the ball in the left application.
- The movement of the ball on the right is fairly bizarre; sticks into the wall.
You are likely thinking that this example is somewhat contrived. Will explain, through the following example, that it captures a serious game play problem.
Thought back to my original Pong example and a particular problem. In the illustration, the left application instantiated (and controls) the ball and the right one instantiated (and controls) the paddle. The ball is moving to the right (there are three time snapshots shown).
The solid elements represent what is actually on the screen at that point in time; the dashed outlined elements represent what is shown on the other player’s screen.
note: Yes, I know the drawing is poor (and blurry); but it is good enough.
Observations:
- From the left application’s perspective, the other player is too late in moving the paddle to intercept the ball.
- From the right application’s perspective, the paddle is in place to intercept the ball.
- In the end, the ball will continue off the screen in the left application and will (likely, based on earlier example) get stuck on the paddle in the right application.
The Solution (in Theory)
The inspiration for this approach came from a colleague of mine who was previously a game developer; specifically the general idea is to have as much of the game run locally and only share the bare minimum across the network to make the game work.
With this in mind (and our Pong game also in mind), it seems that we want the ball, its movement, and interactions with the stationary walls to be handled locally.
We would want to synchronize the initial movement of the ball (accounting for network lag).
We also want to have the collision between the ball and a players paddle to happen locally (on the application that controls the paddle). Necessary information about that collision needs to be shared to the other application to appropriately affect the ball’s movement (will also have to account for the network lag).
Because the player’s paddles positions are inherently going to be lagged, we will need to create a visual distraction (say a hit animation) to hide any discrepancies relating to the remote paddle’s and ball’s position on collisions.
Next Steps
In the next article, Synchronization Issues (Unity + Photon): Part 4, we work to implement the proposed solution.
