An online multiplayer FPS game made with Unity3D game engine and PUN (Photon Unity Networking) package.
This game shows some of the techniques that are usually used to achieve:
- Consistency and
- To reduce the impact of the network latency and packet loss.
Implemented techniques: consistency management, dead reckoning, interpolation, network culling and world division.
1. MatchmakingEvery player has the option to create a new room or join existing one.
Only the master client (room creator) can start the game, scene loading for other players in the same room is automatically synced.
4. Player UI
5. Network SimulationWhen turned on, this option allows the player to simulate network conditions.
Player can add additional ping and increase packet loss chance.
Each player sends to the server 10 times per second a package that contains information about his position and rotation.
Server distributes that package to other players.
That amount of data is not enough to present smooth movement for the avatars of other players.
Increasing the serialization rate would fix that problem, but the server has a potential to become a bottleneck.
Interpolation is used to retain smooth movement and rotation without sending too much data.
That technique locally generates additional waypoints between last 2 known states.
|Movement without interpolation||Movement with interpolation|
Interpolation can reduce the amount of data that is sent over the network, but it does not solve the problems caused by an unstable network.
When a package is lost or arrives lately, movement of an avatar will still look jittery.
Dead reckoning can hide those problems successfully.
Since the serialization rate in this game is 10, we can expect a new package every 100 ms.
After that amount of time passes without getting the new package, extrapolation of data will kick in.
From the last 2 known states we can extract avatar’s velocity and predict its current position.
|Interpolation + Packet Loss (30%)||Interpolation + Packet Loss (30%) + Dead Reckoning|
7. Network Culling & World Division
Since PUN package does not allow server-side scripts, the world is divided into 16 zones in order to achieve network culling.
By default, all packages are broadcasted.
When some player turns on the network culling option he will receive only relevant data.
The player only cares about updates in the current zone and neighbour zones.
Each player has his own field of view presented by the circle on the map.
When that circle touches the border of another zone, the player will become neighbour with that zone.
|Player2 in zone 2, Player1 becomes neighbour with zone 2, number of incoming messages changes|
Field of view represents how far players can see.
If a player has turned on the Dynamic FOV option, his field of view will shrink to the shooting range if certain conditions are met. This will only happen if the number of incoming messages becomes too high.
In that particular moment, player will mark his and neighbour zones as critical and the circle (FOV) will stay shrunk until he enters some zone that is not on that list.
Player can be subscribed up to 4 zones (his own + 3 neighbours)
In those situations it is expected that the network will be overloaded, and by shrinking the circle player can reduce the chance of becoming the neighbour with other zones.
|Dynamic FOV, Player2 in zone 2, Player1 runs through different zones|
8. Consistency Management
Players can pick up the bullets in the scene. When one player picks up the bullets he is responsible to notify all other players
about that action so they can remove that object from their local copy of the game.
Suppose we have 2 players, both players have the same latency 100 ms. Player1 picks up the bullets, after 20 ms player2 does the same thing. The end result of those actions will be inconsistent behavior because both players will pick up the same object.
Because of the latency, notification from Player1 arrives too late.
In this game, when one player picks up the object he will firstly send request to the other players.
That request contains the name of the object and timestamp. Player will then wait for responses, and if all those responses are positive he will get the object.
Player with the smallest timestamp wins the object.
|W, A, S, D or Arrow Keys||Movement|
|Mouse Rotation||Look Rotation|