You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Merging Develop with Main (#813) (#826)
* Updating docs page in 2D space shooter (#810)
Updating docs page in 2D space shooter which has a reference to an unconfirmed feature (Prediction)
* updating boss room example used in mid-game reconnecting doc (#725)
Co-authored-by: Sara [Unity] <89528471+s-omeilia-unity@users.noreply.github.com>
Co-authored-by: Christopher Pope <chris@unity3d.com>
* Update getting-started-boss-room.md (#812)
Co-authored-by: LPLafontaineB <louisphilippe.lb@unity.com>
Co-authored-by: Sara [Unity] <89528471+s-omeilia-unity@users.noreply.github.com>
Co-authored-by: Sam Bellomo <71790295+SamuelBellomo@users.noreply.github.com>
Co-authored-by: Christopher Pope <chris@unity3d.com>
Co-authored-by: LPLafontaineB <louisphilippe.lb@unity.com>
Co-authored-by: Sara [Unity] <89528471+s-omeilia-unity@users.noreply.github.com>
Co-authored-by: Sam Bellomo <71790295+SamuelBellomo@users.noreply.github.com>
* small fixes for tutorials (#829)
* renamed command line argument and variable in helloworld code snippet
* fixing broken link in gp module 2
* fixing indentation issues in gp 1 code snippets
* fixing log not corresponding to code example
* updating gp table of contents
* removing unneeded instructions
* Update NGO changelog to 1.1.0 (#834)
* Update NGO changelog to 1.1.0
* Add PR and issue links
* In-Scene Placed NetworkObject updates for v1.1.0 (#816)
* Merging Develop with Main (#813)
* Updating docs page in 2D space shooter (#810)
Updating docs page in 2D space shooter which has a reference to an unconfirmed feature (Prediction)
* updating boss room example used in mid-game reconnecting doc (#725)
Co-authored-by: Sara [Unity] <89528471+s-omeilia-unity@users.noreply.github.com>
Co-authored-by: Christopher Pope <chris@unity3d.com>
* Update getting-started-boss-room.md (#812)
Co-authored-by: LPLafontaineB <louisphilippe.lb@unity.com>
Co-authored-by: Sara [Unity] <89528471+s-omeilia-unity@users.noreply.github.com>
Co-authored-by: Sam Bellomo <71790295+SamuelBellomo@users.noreply.github.com>
* Start 1.1.0 updates
Just creating a branch to start working on v1.1.0 updates
* update
updated the spawning and despawning portion.
* update
Final first pass for in-scene placed NetworkObject documentation updates.
* update
adding temporary warning to users about in-scene placed NetworkObject parenting.
Co-authored-by: Christopher Pope <chris@unity3d.com>
Co-authored-by: LPLafontaineB <louisphilippe.lb@unity.com>
Co-authored-by: Sara [Unity] <89528471+s-omeilia-unity@users.noreply.github.com>
Co-authored-by: Sam Bellomo <71790295+SamuelBellomo@users.noreply.github.com>
* WorldPositionStays update (#778)
* WorldPositionStays update
The update to this documentation requires NGO SDK PR-2146 before it should be made public/merged.
* update
Still WIP
* update
additions and adjustments.
* update
* update
final pass adjustments for the PRs suggested updates.
Co-authored-by: Christopher Pope <chris@unity3d.com>
Co-authored-by: Larah Armstrong <larah@unity3d.com>
* Remove internal comment (#830)
* update ClientNetworkTransform information (#791)
* update ClientNetworkTransform information
This just provides users with a bit more information about setting NetworkTransform into owner/client authoritative mode,
* update
adjusting the text copy and pointing the example of the ClientNetworkTransform to the co-op samples version
* update
Applying suggested update for section that outlines how to add the multiplayer samples utilities package to your project.
Co-authored-by: Christopher Pope <chris@unity3d.com>
Co-authored-by: Larah Armstrong <larah@unity3d.com>
* Updated existing or added missing dark themes to our sequence and scene diagrams! (#838)
Co-authored-by: Larah Armstrong <larah@unity3d.com>
* Add NGO 1.1.0 documentation (#839)
* Bump version
* update
Adjusting the code example to be compliant with the recent updates.
Adding additional information about the example in the note.
* parenting update
Adding some additional language to the parenting related documents and fixing a minor spelling issue.
Co-authored-by: NoelStephensUnity <73188597+NoelStephensUnity@users.noreply.github.com>
* NGO 1.1.0 release notes (#843)
* Fix version drop-down order
* Add NGO 1.1.0 release notes
* fix: tutorial improvements (#840)
* fixing typos and broken links
* clarifying the Testing Hello World section
* Clarified the usage of OnNetworkSpawn in HelloWorldPlayer
* clarified Adding Editor Modes section in GP1
* clarified use of command line helper
* Adding high-level explanation of what NetworkManager and UTP are in HelloWorld tutorial, with links to detailed docs
* restructured GP1 to have instructions to add script after description of why we add them
* adding links to gp_intro
Co-authored-by: Larah Armstrong <larah@unity3d.com>
* Add "coming soon" note to empty pages (#845)
* Add Optimizing Boss Room Performance
* Revert "Add Optimizing Boss Room Performance"
This reverts commit 427c1f2.
Co-authored-by: Christopher Pope <chris@unity3d.com>
Co-authored-by: LPLafontaineB <louisphilippe.lb@unity.com>
Co-authored-by: Sara [Unity] <89528471+s-omeilia-unity@users.noreply.github.com>
Co-authored-by: Sam Bellomo <71790295+SamuelBellomo@users.noreply.github.com>
Co-authored-by: Noel Stephens <noel.stephens@unity3d.com>
Co-authored-by: Jil Franco <89089503+jilfranco-unity@users.noreply.github.com>
Co-authored-by: NoelStephensUnity <73188597+NoelStephensUnity@users.noreply.github.com>
@@ -83,5 +84,5 @@ You should place this script on your in-scene placed `NetworkObject` (i.e. the f
83
84
84
85
85
86
:::note
86
-
Remove any parenting code you might have had from your player prefab before using the above script.
87
+
Remove any parenting code you might have had from your player prefab before using the above script. Depending upon your project's goals, you might be parenting all players under the same in-scene placed `NetworkObject` or you might intend to have each player parenting unique. If you want each player to be parented under a unique in-scene placed `NetworkObject` then you will need to have the same number of in-scene placed `NetworkObject`s as your maximum allowed players per game session. The above example will only parent all players under the same in-scene placed `NetworkObject`. You could extend the above example by migrating the scene event code into an in-scene placed `NetworkObject` that manages the parenting of players (i,e. name it something like `PlayerSpawnManager`) as they connect, make the `SetPlayerParent` method public, and add all in-scene placed `NetworkObject`s to a public list of GameObjects that the `PlayerSpawnManager` will reference and assign player's to as they connect while also freeing in-scene placed `NetworkObject`s as players disconnect during a game session.
Copy file name to clipboardExpand all lines: docs/basics/scenemanagement/timing-considerations.md
+36-9Lines changed: 36 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,11 @@ In each diagram, you will see two types of black arrows:
18
18
19
19
## Client Synchronization:
20
20
The below diagram, Client Synchronization Updates, steps you through the entire client synchronization process from starting the client all the way to the client being fully synchronized and connected.
Above, we can see that the client will first send a connection request to the server that will process the request, handle the approval process via ConnectionApprovalCallback (if connection approval is enabled), and if approved the server will:
23
27
- Send a connection approved message back to the client
24
28
- This only means the connection is approved, but the client is not yet synchronized.
@@ -45,7 +49,11 @@ Take note that after the client finishes processing the synchronization event, t
45
49
46
50
### Client-Side Synchronization Timeline
47
51
Now that we have covered the high-level synchronization process, we can dive a little deeper into what happens on the client side as it processes the synchronize message. The below sub-diagram, "Scene Event Synchronization Timeline", provides you with a more detailed view of how the client processes the synchronize message:
You can see that upon receiving the message, the client appears to be iterating over portions of the data included in the synchronize message. This is primarily the asynchronous scene loading phase of the client synchronization process. This means the more scenes loaded, the more a client will be required to load which means the Client Synchronization Period is directly proportional to the number of scene being loaded and the size of each scene being loaded. Once all scenes are loaded, the client will then locally spawn all `NetworkObject`s. As a final step, the client sends the list of all `NetworkObjectId`s it spawned as part of its `SceneEventType.SynchronizeComplete` scene event message so the server can determine if it needs to resynchronize the client with a list of any `NetworkObjects` that might have despawned during the Client Synchronization Period.
50
58
51
59
## Loading Scenes
@@ -54,9 +62,11 @@ You can see that upon receiving the message, the client appears to be iterating
54
62
Looking at the timeline diagram below, "Loading an Additive Scene", we can see that it includes a server, two clients, and that the server will always precede all clients when it comes to processing the scene loading event. The big-picture this diagram is conveying is that only when the server has finished loading the scene and spawning any in-scene placed `NetworkObject`s, instantiated by the newly loaded scene, will it send the scene loading event message to the clients.
55
63
56
64
Another point of interest in the below diagram is how Client 1 receives the scene loading event, processes it, and then responds with a `SceneEventType.LoadComplete` scene event message before client 2. This delta between client 1 and client 2 represents the varying client-server latencies and further enforces the underlying concept behind the `SceneEventType.LoadEventCompleted` message. Once a server has received all `SceneEventType.LoadComplete` messages from the connected clients, it will then broadcast the `SceneEventType.LoadEventCompleted` message to all connected clients. At this point, we can consider the scene loading event (truly) complete and all connected clients are able to receive and process netcode messages.
While a client can start sending the server messages (including NetworkVariable changes) upon local `SceneEventType.LoadComplete` event notifications, under more controlled testing environments where the network being used has very little to no latency (i.e. using loopback with multiple instances running on the same system or using your LAN), this approach will not expose latency related issues. Even though the timing might "work out" under controlled low latency conditions you could still run into edge case scenarios where if a client approaches or exceeds a 500ms RTT latency you could potentially run into issues.
62
72
:::
@@ -86,15 +96,24 @@ How you load scenes is really up to your project/design requirements.
86
96
- Any scenes loaded by `NetworkSceneManager`, prior to scene switching, will be unloaded and any `NetworkObject` that has the `DestroyWithScene` set to `true` will be destroyed.
87
97
- If `DestroyWithScene` is set to `false` it will be "preserved" (_see the sub-diagram "Load New Scene Timeline" below_)
Both scene loading diagrams (Additive and Single) refer to the below sub-diagram that provides additional details of the scene loading process.
93
107
:::important
94
108
When looking at the below sub-diagram, both single and additive scene loading modes use close to the exact same flow with the exception that additively loaded scenes only flow through the four middle steps that are grouped together by the light red filled region highlighted by red dashed lines. When loading a scene additively, no other scenes are unloaded nor are any NetworkObjects moved into the DDoL temporarily. This setting, by default, is true for dynamically spawned `NetworkObject`s unless otherwise specified when using `NetworkObject.Spawn`, `NetworkObject.SpawnWithOwnership`, or `NetworkObject.SpawnAsPlayerObject`. In-scene placed `NetworkObject`'s, by default, will be destroyed with the scene that instantiated them. At any point, within a `NetworkBehaviour` you can change the `NetworkObject.DestroyWithScene` property.
2. During the scene loading process, in-scene placed `NetworkObject`s are instantiated and their `Awake` and then `Start` methods are invoked (in that order).
@@ -119,7 +138,11 @@ Primarily, this applies to unloading additively loaded scenes via th `NetworkSce
119
138
### Unloading an Additive Scene
120
139
If you look at the below diagram, "Unloading an Additive Scene", you will see a very similar flow as that of loading a scene. The server still initiates the `SceneEventType.Unload` scene event and will not send this message to clients until it has completed the `Unload` scene event locally.
Review over the below diagram and take note of the following things:
@@ -131,4 +154,8 @@ Review over the below diagram and take note of the following things:
131
154
- While a server is unloading a scene, the client could begin to receive a bunch of despawn messages for the `NetworkObject`s being destroyed on the server-side while the scene is being unloaded.
132
155
- By the time a client receives the `SceneEventType.Unload` scene event message, it very well could have no remaining `NetworkObject`s in the scene being unloaded. This will not impact the client-side scene unloading process, but it is useful to know that this will happen.
`NetworkTransform` always synchronizes positions from the server to the clients and position changes on the clients are not allowed. Netcode for GameObjects comes with a sample containing a `ClientNetworkTransform`. This transform synchronizes the position of the owner client to the server and all other client allowing for client authoritative gameplay.
53
53
54
-
The `ClientNetworkTransform` lives inside the Multiplayer Samples Utilities package. You can add this package via the `Package Manager` window in the Unity Editor by selecting `add from Git URL` and adding the following URL: `https://github.com/Unity-Technologies/com.unity.multiplayer.samples.coop.git?path=/Packages/com.unity.multiplayer.samples.coop#main`
54
+
You can use the existing ClientNetworkTransform in the Multiplayer Samples Utilities package.<br />
55
+
To add the Multiplayer Samples Utilities package:
55
56
56
-
Or you can directly add this line to your `manifest.json` file:
57
+
- Open the Package Manager by selecting Window > Package Manager.
58
+
- Select the plus button (+) > Add from git URL....
59
+
- Copy and paste the following Git URL: https://github.com/Unity-> Technologies/com.unity.multiplayer.samples.coop.git?path=/Packages/com.unity.multiplayer.samples.coop#main
60
+
- Select Add.
57
61
62
+
Optionally, you can directly add this line to your `manifest.json` file:
You can also create your own `ClientNetworkTransform` by deriving from `NetworkTransform`, overriding the `OnIsServerAuthoritative` virtual method, and returning false:
| Creating a new project<br/> Installing Netcode<br/> Creating and testing the basic networking building blocks<br/> |Adding scripts to objects<br/> Editor modes (Host Server and Client)<br/> Basic player movement <br/>Basic RPC use |
22
+
|[Creating a new project](../helloworld.md#create-a-new-project-in-unity)<br/> [Installing Netcode](../helloworld.md#install-netcode)<br/> [Creating and testing the basic networking building blocks](../helloworld.md#create-the-basic-components)<br/> |[Editor modes (Host Server and Client)](gp_module_one.md#adding-editor-modes-to-hello-world)<br/> [Basic player movement](gp_module_one.md#adding-basic-movement-to-the-player-object) <br/>[Basic RPC and Network variable use](gp_module_one.md#some-simple-rpc-use)|
0 commit comments