How does synchronization works with photon realtime for UE4

CASBraga

Hi!

I have been wondering for a while now, how can a competitive FPS or other fast paced game can be done with just photon realtime. How are things synchronized? How do you detemine things like hits and the like?

I am asking because we just finished developing all networked gameplay using the UE4 framework but are willing to give Photon Realtime a chance if it fits in with our project.

Kaiserludi

Hi @CASBraga.

There is no built-in synchronization in Photon Realtime.
Clients send any kind of data to any other client with opRaiseEvent() (via the servers in between as a relay).
Photon does not enforce a certain model on the game on how to synchronize things. This is fully up to you and what works best for your style of game.

For example you can have all the clients send position update events (that contain the most recent coordinates of the sending client) to every other client in the room (or only to those clients who have a chance to actually be able to see that client visually to optimize the amount of msg/s) x times per second (what to choose for x depends on what works best for you - more updates per second give better results, but result in more traffic and msg/s).

On top of that you would add interpolation algorithms to make remote player movement smoothly and not have the players visually jumping from one position to the next.

You could also include movement information in the events. So an event would no just included the information that a player has moved to position x1040 / y8956, but also that it is moving with a speed of 189 unity per second in x and 456 units per second in y direction and is accelerating by 2 unity per second in x and 7 in y direction. This way remote clients can already predict the coordinates that will come in in future position updates, when no new player input changes the course of that remote character. You can also let the clients simulate how the physics in the world will change the course of players by feeding the physics engine with the information form the movement updates and simulate the physics of future frames, then use that as input for your interpolation algorithms. That way you can predict stuff like a remote player likely colliding with some object and adjust the interpolation of his movement accordingly.

Another option is to not send position or movement updates, but just input data. In this scenario clients would send around info like "key 'left arrow' pressed" and the receiving client would then just react to that input for remote client in the same way like it would have done if the key press input had came in locally for the local client. Again you could simulate the movement for future frames and apply interpolation algorithms to adjust for differences coming from latency.

Another common trick is to add a small local input lag:
If a player presses a key, you immediately create the according events and send them out to the other players, but don't react to the event yet locally, but only do so after a certain time has passed. In depends a lot on the type of game how much local lag you can add until players can actively notice it, but something like 100ms is normally perfectly save.
Example:
At 10:40:32,540 player A presses key "shoot"
You immediately send out that info to players B and C.
At 10:40:32,620 the info arrives at player B.
At 10:40:32,640 player B and C start the simulation of the shot.
At 10:40:32,710 it arrives at player C. it immediately starts simulating the shot and uses interpolation to catch up the remaining time difference.

This way if you local input lag is greater than the latency between two players, you can cut off latency induced differences between those two players simulations of the game state completely, and if is smaller than the latency, than you can at least reduce the latency induces differences by the time of the local lag.
In our example without the local lag player B would have had a difference to catch up to player A of 80ms and it would even be 170ms fro player C, but with the 100ms local lag for player A we end up with 0ms difference for player B and only 70ms for player C.

How do you detemine things like hits and the like?

You can either make on of the clients authoritative (either for every decisions or only for decisions that have been triggered by that client) and let it decide depending on the player positions and the bullet positions in his local version for the simulation, if it was a hit or not or you let all clients check this locally and then decide it by majority vote (if in a 4 player game 3 clients calculate that it was a hit and 1 client calculates that it wasn't, then the 3 clients have the last word because they agree with each other).



With photon Server and Photon Enterprise Cloud you could also run game logic on the server via a plugin and make the servers state of the game have the last word on every decision like where a player is actually positioned at which point in time and if a shot was a hit or not, while clients local states are just treated as pre calculated approximations / educated guesses that are used for visual representation of the game to the players. This is not an option for the public Cloud as we don't allow developers to run their own server-side code there for security and performance reasons (if one developer writes buggy code, it could potentially affect the games of other developers as well, because the servers are shared with other developers on the public clouds (this makes it able to offer lower prices than with dedicated machines) ).

Kaiserludi

Hi @CASBraga.

There is no built-in synchronization in Photon Realtime.
Clients send any kind of data to any other client with opRaiseEvent() (via the servers in between as a relay).
Photon does not enforce a certain model on the game on how to synchronize things. This is fully up to you and what works best for your style of game.

For example you can have all the clients send position update events (that contain the most recent coordinates of the sending client) to every other client in the room (or only to those clients who have a chance to actually be able to see that client visually to optimize the amount of msg/s) x times per second (what to choose for x depends on what works best for you - more updates per second give better results, but result in more traffic and msg/s).

On top of that you would add interpolation algorithms to make remote player movement smoothly and not have the players visually jumping from one position to the next.

You could also include movement information in the events. So an event would no just included the information that a player has moved to position x1040 / y8956, but also that it is moving with a speed of 189 unity per second in x and 456 units per second in y direction and is accelerating by 2 unity per second in x and 7 in y direction. This way remote clients can already predict the coordinates that will come in in future position updates, when no new player input changes the course of that remote character. You can also let the clients simulate how the physics in the world will change the course of players by feeding the physics engine with the information form the movement updates and simulate the physics of future frames, then use that as input for your interpolation algorithms. That way you can predict stuff like a remote player likely colliding with some object and adjust the interpolation of his movement accordingly.

Another option is to not send position or movement updates, but just input data. In this scenario clients would send around info like "key 'left arrow' pressed" and the receiving client would then just react to that input for remote client in the same way like it would have done if the key press input had came in locally for the local client. Again you could simulate the movement for future frames and apply interpolation algorithms to adjust for differences coming from latency.

Another common trick is to add a small local input lag:
If a player presses a key, you immediately create the according events and send them out to the other players, but don't react to the event yet locally, but only do so after a certain time has passed. In depends a lot on the type of game how much local lag you can add until players can actively notice it, but something like 100ms is normally perfectly save.
Example:
At 10:40:32,540 player A presses key "shoot"
You immediately send out that info to players B and C.
At 10:40:32,620 the info arrives at player B.
At 10:40:32,640 player B and C start the simulation of the shot.
At 10:40:32,710 it arrives at player C. it immediately starts simulating the shot and uses interpolation to catch up the remaining time difference.

This way if you local input lag is greater than the latency between two players, you can cut off latency induced differences between those two players simulations of the game state completely, and if is smaller than the latency, than you can at least reduce the latency induces differences by the time of the local lag.
In our example without the local lag player B would have had a difference to catch up to player A of 80ms and it would even be 170ms fro player C, but with the 100ms local lag for player A we end up with 0ms difference for player B and only 70ms for player C.

How do you detemine things like hits and the like?

You can either make on of the clients authoritative (either for every decisions or only for decisions that have been triggered by that client) and let it decide depending on the player positions and the bullet positions in his local version for the simulation, if it was a hit or not or you let all clients check this locally and then decide it by majority vote (if in a 4 player game 3 clients calculate that it was a hit and 1 client calculates that it wasn't, then the 3 clients have the last word because they agree with each other).



With photon Server and Photon Enterprise Cloud you could also run game logic on the server via a plugin and make the servers state of the game have the last word on every decision like where a player is actually positioned at which point in time and if a shot was a hit or not, while clients local states are just treated as pre calculated approximations / educated guesses that are used for visual representation of the game to the players. This is not an option for the public Cloud as we don't allow developers to run their own server-side code there for security and performance reasons (if one developer writes buggy code, it could potentially affect the games of other developers as well, because the servers are shared with other developers on the public clouds (this makes it able to offer lower prices than with dedicated machines) ).

CASBraga

Thanks! This will help us make the decision!