fix : Update Readme

2 年前 · 8522da67
--- a/README.md
+++ b/README.md
 * **Lobby creation**: Players host lobbies for others to join.
 * **Lobby query**: Find a list of lobbies with filters, or use lobby codes.
 * **Relay obfuscation**: Players in a lobby are connected through an anonymous IP.
-* **UTP communication**: Players transmit basic data to lobby members in real time.
 * **Lobby + Relay connection management**: Together, the services automatically handle new connections and disconnections.
 * **Vivox Voice**: Create a voice channel for the lobby to allow for voice communication, with per-user volume control and muting.


 ### Running the sample

-You will need two “players” to demonstrate the full sample functionality. Create a standalone build to run alongside the Editor in Play mode. Although Auth creates anonymous credentials using your machine’s registry, your Editor and your build have different credentials because they create different registry entries.
+You will need two “players” to demonstrate the full sample functionality. You can either use the included Parrelsync package to create duplicate projects for testing, or create a standalone build to run alongside the Editor in Play mode. Although Auth creates anonymous credentials using your machine’s registry, multiple Editor projects and client builds allow for multiple anonmyous auth tokens.


 #### **Lobby Join Menu**
 &nbsp;&nbsp;&nbsp;&nbsp;**C**. &nbsp;&nbsp; **Lobby user**: A player in the lobby. The player’s name, state, and emote are displayed; this data is synchronized through Relay + UTP, so any changes that a player makes will appear immediately for all connected players. Incoming players will be sent the current data once they have connected.\
 &nbsp;&nbsp;&nbsp;&nbsp;**D**. &nbsp;&nbsp; **Emotes**: Shows the player’s Emote, as well as controls for voice chat if the user has a mic connected. \
 &nbsp;&nbsp;&nbsp;&nbsp;**E**. &nbsp;&nbsp; **Vivox Voice Controls**: Clicking the audio icon will mute/unmute that user.\
-&nbsp;&nbsp;&nbsp;&nbsp;**F**. &nbsp;&nbsp; **Relay IP** :The anonymous server IP that Relay generates. This does not need to be shown to players and is displayed here simply to indicate that Relay is functioning.\
-&nbsp;&nbsp;&nbsp;&nbsp;**G**. &nbsp;&nbsp; **Relay Code**: An internal join code generated by Relay that is used during Relay connection. This does not need to be shown to players and is displayed here simply to indicate that Relay is functioning.\
+&nbsp;&nbsp;&nbsp;&nbsp;**F**. &nbsp;&nbsp; **Relay IP** : No longer used here with the new Lobby-relay integration.\
+&nbsp;&nbsp;&nbsp;&nbsp;**G**. &nbsp;&nbsp; **Relay Code**: No longer used here with the new Lobby-relay integration.\
 &nbsp;&nbsp;&nbsp;&nbsp;**H**. &nbsp;&nbsp; **Emote buttons:**: Sets the player’s emote and is synchronized using UTP.\
 &nbsp;&nbsp;&nbsp;&nbsp;**I**. &nbsp;&nbsp; **Lobby color**: (Host only) Sets the lobby color for filtering in the Lobby List. This is synchronized through Lobby, so changes won’t appear immediately for all players because Lobby queries are rate limited. See Rate Limits.\
 &nbsp;&nbsp;&nbsp;&nbsp;**J**. &nbsp;&nbsp; **Ready button**: Sets a ready state on the player. When all players are ready, the host initiates a countdown to an “in-game” state, and the lobby becomes hidden from the public lobby list.\


 * Logic for using the Auth, Lobby, and Relay services are encapsulated in their own directories. Much of the API usage is abstracted away for convenience. 
-    * For example, **LobbyAPIInterface** contains the actual calls into the Lobby API, but **LobbyAsyncRequests** has additional processing on the results of those calls as well as some structures necessary for timing the API calls properly.
-    * The Relay directory also contains logic for using the Unity Transport (UTP) because it requires a transport to function.
+    * For example, **LobbyAPIInterface** contains the actual calls into the Lobby API
-    * **Locator** mimics a Service Locator pattern, allowing for behaviors that might otherwise be Singletons to easily be swapped in and out.
-    * **Messenger** creates a simple messaging system used to keep unrelated classes decoupled, letting them instead message arbitrary listeners when interesting things happen. For example, a lobby is updated, or a player disconnects from a relay.
-    * An **Observer** pattern is used for all UI elements and for local copies of remote Lobby and Relay data. An Observer is alerted whenever its observed data changes, and the owner of that data doesn’t need to know who is observing.
-* Multiple **Tests** directories are included to demonstrate core behavior and edge cases for some of the code. In particular, the Play mode tests for Lobby and Relay can be used to ensure your connection to the services is functioning correctly. (Run tests using the Test Runner, accessible under **Window > General > Test Runner**.)
 * In the Editor, the project assets are broken into nested prefabs for convenience when making changes during sample development. Their details should not be considered vital, although there are UI elements that depend on event handlers that are serialized.


-


 * All operations using Lobby and Relay rely on asynchronous API calls. The sample code has some logic for handling issues that can result from receiving the results at arbitrary times, but it doesn’t have logic for enqueuing calls that the user initiates during setup and cleanup. Rapid operations when entering and exiting lobbies can result in unexpected behavior.