Skip to main content

General development tips

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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 using ElympicsConfig connection quality presets visible at the bottom of the Unity Inspector of Unity Clone instances. Testing connection presets

  6. 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.