Testing Multiplayer Movement

版本检查: 5.3


难度: 中级

To test Multiplayer movement we must again have two instances of the game running simultaneously. The instance being run from the editor will be up-to-date with our changes, but the standalone build will be stale and needs to be updated with the most recent changes that we have made to the project.

  • Build and Run this scene as a standalone application.

The standalone player will now start and show the in-game UI from the NetworkManagerHUD.

  • Click the LAN Host button from the in-game UI to start this game as a Host.

We should see the game running with one player GameObject in the scene.

  • Return to Unity.
  • Enter Play Mode

The game will now run in the editor and show the in-game UI from the NetworkManagerHUD.

  • Click the LAN Client button from the in-game UI to connect to the Host as a Client.

There should be two player GameObjects; one for the local player on the Host and one for the remote player for this Client. Currently, they will be in the exact same position, so it may appear that there is only one player GameObject in the scene. By checking the Hierarchy Window, there should be two Player(clone)’s.


To test moving the Client’s player GameObject in the scene:

  • Press the WASD or arrow keys to move and turn the Client's player

Note how the player GameObjects now move independently of each other.

  • Switch back to the Stand Alone player.

    To test moving the Host’s player GameObject in the scene:

  • Press the WASD or arrow keys to move and turn the Host’s player.

The two Player GameObjects should now be completely independent of each other and be in sync on both instances of the game.

When running two instances of the project, the remote player GameObject may not appear to be moving smoothly on the local client. There may be a “steppy” feel to the movement of the remote Player's GameObject. It is worth keeping in mind that all networked applications will be affected to some degree by latency and, more often, the limitations to the speed in which data can be moved moved between the Clients and Server.

There are many ways that latency and data transfers can be optimized. For example, the NetworkTransform has a Network Send Rate setting which can be used to set how often the NetworkTransform sends synchronization data. The frequency of updates over a network between Clients and Server can have a heavy impact on how a Networked Multiplayer game feels.


More importantly, however, there are many ways that a Networked application can cover for discrepancies in synchronization, whether these discrepancies are from sheer latency or due to the frequency of synchronizational updates. These solutions can include interpolation, extrapolation and many other forms of smoothing and prediction. None of these will be covered in this lesson.

At this point, it is worth bearing in mind a few key points. A balance will need to be struck between how often state synchronization happens and the performance of the game. If a game tries to synchronize too much data too often over a network, the performance of the game will suffer. If a game does not synchronize data often enough, then the feel of the game and game-play could suffer. In all cases there will need to be some form of interpretation of the synchronized GameObjects to keep all Clients feeling smooth and in sync while playing. All Multiplayer Networked games are never in perfect synchronization, as this is not physically possible. Two or more remote Clients cannot be in the exact same state at the same time due simply to the time it takes to transfer the data between them. Games, however, need to feel as if they are in proper synchronization for the best player experience, even if the separate instances are slightly different in their exact state. How to do this will be covered in detail in other lessons.

  • Close the Stand Alone player.
  • Return to Unity.
  • Exit Play Mode.