Boss Room, released in Early Access in April 2021, is a living example of Unity's project for developers, while Boss Room, which now uses more Unity Gaming Services (UGS) elements, is more suitable for multiplayer game development.
As an example project for multiplayer, Boss Room showcases various UGS features in an environment that can be used in actual production, providing learning resources for multiplayer development.
Boss Room has two main uses:
One is as an exemplary sample for the community to use as a project foundation or as a component in the developer's own Unity game.
This also gives developers the opportunity to try their own solutions for themselves, working hand in hand with the UGS team to create and maintain a multiplayer game with all the common features using the SDK provided by Unity. As Unity continues to add new tools and features, So does Boss Room.
Just last month, Boss Room was updated with v1.1.0-pre, bringing a whole new set of features to developers on multiplayer services.
Let players join forces to brave the Boss Room
As a multiplayer game, Boss Room has to have a way to search and join the game.
Currently, there are two ways for players to search and connect to the game.
DIRECT IP allows players to connect to each other using a publicLY available IP address. However, a computer's network is usually relayed through NAT (Network Address Translation Equipment) and routers, so connecting directly to someone else's computer is not as simple as you think.
Port forwarding technology makes direct connections possible, but the host side still needs to make some additional settings to allow other players to connect. This solution also does not have the ability to search for game matches, and players must pass on the relevant joining information through out-of-game information sharing channels. And the advantage of it is that it can be run with a local area network and does not require an internet connection.
Multiplayer games like Boss Room must be playable on the Internet, game rooms must be easily searchable, and players cannot be forced to complete port forwarding by themselves.
That's where Unity Gaming Services comes in handy — authentication, Lobby, and Relay make it easy for players to create or join connected games without having to rely on port forwarding or out-of-game coordination.
After the integration of Auditing, Lobby, and Relay services into Boss Room, game creation and onboarding will become simpler, making port forwarding and sharing of game information redundant.
Overall, the game's online experience is now smoother and faster, which is a plus for the sample project and a must for the real game.
Let's take a look at the experience we have learned from project production!
Overview of the Boss Room development process
From the perspective of gaming experience, Boss Room is a full-featured, host-hosted PVE multiplayer co-op RPG that supports up to 8 players – detailed game features and gameplay can be found here.
Step 1: Authentication, UGS, and local iteration of the process
Players must be authenticated in order to use other Unity Gaming Services services, so the game launches Auditing after launching and loading the main menu.
Authentication supports anonymous login, and players do not need to enter additional information to start the game.
By default, the Authentication API does not distinguish between multiple game instances on the same device, and even if the player opens multiple game processes, the game is still logged into the same account. This made it difficult to test the game locally – both Parrel Sync cloned and actual games were affected.
Fortunately, there is a simple solution here: Authentication supports Profiles player profiles, which is the key to solving the problem. Profiles can effectively allow multiple players to play on one device at the same time. To test locally, we need to have the production and editor versions switch freely between multiple Profiles.
If you want to create a player profile, you need to decide which type of Profile to use based on the ProfileManager class. In the production version we use the '-AuthProfile' command line argument to specify the new file ID. When iterating through the editor, we used ParrelSync, and the ProfileManager class also supports specifying the type of player profile using ParrelSync's 'CloneManager' custom parameter.
We also used 'ProfileManager.Profile' to generate custom 'InitializationOptions'.
Once the above tasks are complete, we can start other services, and we have somehow automated the local iteration process of ParrelSync and Profile. This has been changed to dataPath-based in Boss Room to reduce tool constraints, but the above solution still works for ParrelSync users.
Create a room: The process of setting up a host
Players who want to create a console can enter the name of the game room, set the open or encrypted room, and click the "create" button.
The API for creating the room is then called. The newly created game room will enter the locked state (unlike the game room that has been set up and opened) until the system successfully completes the steps below to assign a relay network and start the network code transmission:
The host requests a relay network to the Relay
The UTP is activated and the host will enter the character selection scene room to unlock the state, so that other clients can join freely.
Joining a game room: The process of networking the client
There are several ways to join a game room:
Connect to a public room hosted on a Lobby service
Quickjoin, a random addition to a public room
Join with a password, which can be shared outside the game. These methods apply to both public and private rooms.
After joining a room, we will connect to the host via UTP Relay using the relay network entry code included in the room metadata.
The host will receive a connection request from the client, and if all goes well, the player will jump into the appropriate scene according to the authority of the server (host).
After the player creates or joins the game
After establishing the connection, the player will enter the character selection scene, choosing one of eight heroes. After all players have prepared, each hero will be teleported to the Boss Room world after the countdown is over, and the game will officially begin.
Note that the UGS Lobby and the "lobby" in our game, i.e. the character selection scene, are not the same thing. The character selection scene in Boss Room is driven by netcode.
It should be emphasized that the Lobby service can transmit arbitrary metadata, so the same character selection scene can be applied to other games.
Currently, the Lobby service updates the status by polling, which is not conducive to improving responsiveness when selecting a role, and if the Lobby service introduces a feature that can be updated in real time in the future, then this method can be used as a viable alternative.
Handling of disconnections and reconnections
The disconnection and reconnection feature of multiplayer games is very important.
Boss Room uses a game progress management system that retains some of the data when a player disconnects, reconnects it, and then accurately passes it back.
The reconnection data recovery method we used can be found in sessionManager.cs - SetupConnectingPlayerSessionData, which is called when the host processes connection approval.
When playing in a room, disconnected players are best removed immediately. Otherwise, the server will always assume that the player is still in the room, preventing the player from rejoining.
When a player disconnects from The Relay, the Lobby and Relay integration system (enabled before running the UTP connection) kicks out the disconnected player, however the disconnected state lasts for quite a long time (about 2 minutes), so we can't rely on this mechanism alone.
To make the process of exiting the room more reliable, we applied several additional cleaning mechanisms:
The client contains logic to exit the app and can send a request to remove the player
The host has dedicated cleanup logic, and if a player disconnects, the host removes the player from the room (by calling 'NetworkManager.OnClientDisconnectCallback') – which is useful if the client crashes and can't send a 'exit the room' request. In order to do this, the host uses sessionManager to save the UGS playerId corresponding to the NGO clientId.
Finally, the client also contains detection logic that detects whether the host has left the room, and if the host leaves the room, the client also leaves.