Created using:
- Unity 2017.2.0f3 (uses 2017.2.5f1 as of 09/19/2019)
- Forge Networking Remastered - Github build
An implementation of Authoritative Server Movement in Forge Networking Remastered.
The example shows client-side prediction, reconciliation of inputs, error interpolation, and server-side authoritative processing (the server has the final say on game state).
Clone the project and open it in Unity. Import the latest Github version of Forge Networking Remastered (this project uses this commit). NOTE: when you import Forge Networking Remastered do NOT import "Assets/Beaded Man Studios Inc/Generated" or you will nuke the generated network object implementations!
If needed, add the prefabs of the network objects (GameManager, InputListener, Player) to the NetworkManager prefab.
Build and run two or more instances of the build (ensure the two scenes are Forge's MultiplayerMenu.unity and this example's AuthoritativeMovementExample.unity).
Host on one instance and then join on the others and you can move on any client that didn't host using the Arrow keys.
This project is a very similar implementation to g-klein's AuthoritativeMovementDemo.
The main difference is how reconciliation is done in that an RPC is not used to send the game states processed on the server to the client. Instead the unreliable network object fields are used. Since missing one or two server updates isn't a big deal, RPCs aren't needed.
Also, some optimizations were done in both the Player and InputListener for reconciliation and when/how Inputs should be sent/processed.
Additionally, this build is deterministic. and Physics2D (not sure about 3D, untested) rigid body physics work as far as I've tested so far. I've changed the build to decouple Unity's Physics2D. The build now uses a very simple collision detection & resolution system using the Collider2D.OverlapCollider and Collider2D.Distance methods and direct updating of the rigidbody's position. I did this so I could simulate physics on individual objects allowing all inputs in the queue to be processed at once server side.
(Outdated - will do more testing soon.) This build was tested by me both locally (to/from localhost) and with a server hosted on a Linux VPS with ~100ms ping from my location. Clumsy Lagswitch was used to do further network testing (especially for higher pings).
July 13, 2018:
- Added error interpolation for movement to smooth away errors due to networked collision between players if both players are moving.
- Fixed some bugs (namely the spawning issue which was caused by using the playerConnected event instead of the playerAccepted event for spawning).
- Refactored code.
g-klein's AuthoritativeMovementDemo
Fast Paced Multiplayer Implementation: Smooth Server Reconciliation
-
Lag detection & handling - if excessive lag is detected:
- The local client should mitigate processing time from excessive reconciliation, wait for the last processed server update and snap to there.
- The server should stop processing inputs, extrapolate the player forward along the current movement direction until ping is either lowered (snap to position and start processing inputs again) or too high/too unstable (drop the player).
-
Add a small time delay to incoming inputs on the server to smooth out processing processing (this may not actually be required, Forge may already do this, but I want to experiement a little time permitting).
- At high pings, non-owner clients see choppiness in the interpolation. Smoother interpolation which adapts to the ping is needed.
This is a demo build and is by no means perfect. Use this at your own risk and take the time to understand how it works. Making your own improvements is encouraged and if you feel that you can contribute something back to this example feel free to contact me on the Forge Networking Discord or submit an issue.
Thanks to the members of the Forge Networking Discord who helped me extensively with ideas, discussion and feedback as I worked on this.