General development tips
-
First thing to take care of would be input separation from its effects. Which means that you cannot change the game immediately upon some input occurence. For one-time input you could also use
client->server RPC
. -
In some cases proper input handling could seem to make your game synchronized between the player and server, but relying solely on this could lead to desynchronization due to instable network nature and losing some input along the way. To prevent this, the game shall be state based, allowing it to define some crucial gameplay state and store it within
ElympicsVars
and synchronizers. With this implemented properly, any desynchronization of such state will be fixed automatically, with the authority on the server side. This approach also allows for rejoining to the match to be a possibility. -
Note that if you handle input in such a way that the client doesn’t perform his actions at all and only waits for the server response, it may introduce unpleasant input delay which should be avoided. But not every game have to avoid that, as some could hide the delay behind skillfully paced animations.
-
If you want to avoid input delay let the client run the logic along the server, using the prediction mechanism. Any desynchronization shall be then handled by reconcilliations.
-
HalfRemote
is good for general development but note that it is locally hosted, so various networking problems may not occur. You can simulate worse network condition by usingElympicsConfig
connection quality presets visible at the bottom of the Unity Inspector of Unity Clone instances.
It is worth mentioning that network simulation can be analyzed with Networked Simulation Analyzer -
Note that it is still worth testing using an uploaded server build quite often, as it may show some issues undetectable when hosting server locally. Moreover, if you are working at WebGL, it is highly recommended to go through building a WebGL client from time to time too, as some Unity assets may not work there properly.
-
Don't synchronize every object on scene and avoid putting ElympicsMonoBehaviours everywhere. Syncing a little unnecessary data for thousands of objects will result in huge amounts of data pushed through network.
-
If you want a static player and camera kept near (0,0,0), create one parent with synchronized transform, or use one ElympicsVector3 and move your objects on the server and on the client separately.
-
Avoid synchronizing animated transforms, synchronize animation state instead, e.g. default, playing, and play them separately on clients.
-
-
Watch out for heavy operations on
ElympicsVar.Changed
. The reconcilliation can change state of an ElympicsVar and run ElympicsUpdate multiple times in one update loop. -
Remember that the RPC calls will not reach target when there is no connection.
-
Occasional reconciliation warning is okay, but constant spam of any warning or error definitely is not okay. If reconciliation warning is appearing every frame, something is not properly synchronized and needs to be fixed.