top of page
Moberly
This project is a multiplayer Android mobile game that supports online hosting and joining of the game. In this game, it supports up to four online player, which was done using unity Unet.
​
My goal for this was to implement multiplayer mode of our game and create an interface for the player to be able to play the game online with their friends.
​
​
Unity Unet
Unet is an implementation of multiplayer and networking that has been integrated into unity for game creators to create multiplayer game. Using High Level Scripting API (HLAPI) we were able to create a working network system that allows server hosting and communication between the server and client. For our game this time, we implemented the online service that allows us to matchmake and join matches. Unet however is going to be deprecated from unity in the future and there will be a newer networking implementation. The newer network implementation is still unavailable for the free version of unity (which is the tool we use at home). Unet has a limited bandwidth per client, if there is an overload of messages, the game will exit and, hence ending the game.
​
Network Lobby
The lobby of the online game allows users to host and join any game. In order to manage the game, there are two implementation that we can use; Network manager and network lobby component. The network lobby is a specialized type of the network manager that includes additional attribute that includes limiting the number of players for each game, starting when all players are ready and more. Using the Lobby manager (network lobby component added), it will help to load to the online scene when all players are ready. At the same time when the game ends and the server stop hosting the game, the lobby manager will bring all client and server back to the lobby.
When the host button is clicked, the lobby manager will start the matchmaker and create the match. This hence creates an online match that allows users online to match with when the click the join button. The join button will load to a screen where the hosted room will be listed, and the users can connect to the selected room.
The lobby also allows us to create an interface where the users will be able to select their own customization to the game. In our game there are a couple of selections that the users will be able to select namely the skin of the player which they choose, the map which they want to play in as well as the modes of the game. The latter two of which can only be selected by the server. The lobby manager allows us to change the online scene of all the players. The mode and skin information will be sent via message which we will cover in the later part.
Once the online mode is loaded, we can place markers for where we want the players to spawn. The lobby manager would search for the makers that has the component Network start position. Using round robin, the players would be spawned in the position in an ordered manner. After which any attributes are all done in the game-play.
​
​
​
​
Game-play
Unet has their own messaging system (called network transform) implemented into the system that allows users to pass around player data such as the position, rigidbody2d and rigidbody3d and character controller which allows the games to sync up the data on all sides of the game. Initially we used the implementation of the network transform and realized that the game was broken due to the physics resolution on out game. These are the issues that we faced using network transform.
First, we tried to sync the position of the characters which does translate the position of the player on all sides. However, there was a significant lag between the players and no collision resolution which made it look choppy and hence unplayable.
Secondly, the syncing of rigidbody2d. The rigidbody of the object was synced up however we faced the obstacle of the players not being able to collide with one another and the position of the players were not constant.
Finally character controller was not tried as we used an on screen interface which interacts to the player directly by adding force to the object and was not synced up to the player controller in unity which seems redundant to use in the end.
These issues were also common between multiple users on forums and there were limited resources available for us to resolve. Many of such forums included options such as sending your own message. With all these issues in mind, we decided to send and receive our own personalized messages to sync the players all together. We used the unity messaging system to send our message across. The following are the messages that we sent and the reason for the messages.
​
​
Gameplay mode and player skin (Starting message and setups)
The messages that will be sent before the start of the game includes the game mode and skin of the player. Information such as the skin is held by each player individually information such as the game mode the game is held on by the server which all needs to be send to the other players respectively.
When the player is spawned, they would all have a unique network id that is constant throughout all devices. Using these ids, we would be able to customize unique features that will be constant throughout all devices. Some examples would be like the shape, color and abilities. In our case we synced up the colors based on the id.
An important note to take note when sending the starting message is to give a slight delay at the start. The slight delay is to ensure that all local players on the end has already registered the message. Registering message is to register the handler of which would tell the receiving on how and what to do the message when it reaches. If the message was not registered, the receiving end would not recognize what that message is. For our case we waited 0.5 seconds before sending the messages. We allowed a total of 3 seconds of buffer for all game data to be loaded before the starting the game.
(Server to all) In our game there is a total of 3 game modes. The game mode information is chosen at the lobby by the server. Due to the limited bandwidth that we have, there is a need to limit the number of messages that are being sent or the content of the message being sent. For our case the game mode can be sent easily with just a single int. The server would use the game mode information that they have and send the message to all the clients. Once the players receive the message, they would set and start the game.
(Client to all) The next set of data to be sent would be the skin of the players. Now for this message we would need to keep track of two main components. The first being the id of the player that sent this message as well as the skin of the player. For a client to send message to other clients, we can only do so through the server. Hence, the first step is to send the message to the server. Once the server receives, it will set and dispatch the information accordingly. This can be seen from image above. We could also specify the client we want to send to instead of a batch dispatch accordingly.
​
Client Server communication
Gameplay messages
In order to sync our gameplay, our team decided to resolve all collision and movements on the server and send the message out.
The messages that were sent out from the local player only consist of the controls. Once the button on dash was clicked the speed information would be sent to the server. Whereas for the direction of the player would be sent once there is a change in the direction. The server would get message from the players and apply the force and direction accordingly to the player in its own scene.
On the other hand, instead of sending message when players move, we decided to send 5 messages for every second. Messages includes the position, rotation, id of the player as well as the name of the last hit object. If we were to apply the position and rotation exactly as it is to the player on the client side, we would hence see the same effect we got from the unity’s network transform. So, to reduce the choppy feeling of the gameplay, we would lerp the current position and rotation of the player to the received information. This of course would mean that due to the lerp of the position we might miss a brief hit that we might have in between the message. Hence, we will have to send the last hit object in order to sync up the points and collision.
A slight note, we left information such as the player checking for death and respawning as is. Meaning to say each player oversees their own death animation and registering for their own scores on the local side. This significantly reduced the message needed to be sent.
Another small detail which we had to sync up was the flag in the possession mode. With the random positioning of the spawn position of the flag, there was a need to ensure that the flag spawns all at the same position on all devices. Hence whenever a reposition of flag is needed the server would spawn the position and send the position to all server. The points for the possession mode increases based on the frame rate of the devices as well. After a few playtests, we found that the points on the better device was increasing at a faster rate. Hence only for the possession mode we decided to send the scores as well.
After the gameplay, we would have to end the game by stopping the server and client connection. Once disconnect we will be directed to the lobby and players could make another choice
Postmortem
Through my experience with unet, it was a little difficult due to the limited resources available. There are also multiple bugs that occurs on the editor but not the devices. Some includes buttons that were reactive and unreactive on the cross platforms. There were multiple forums that had the same issue as mine but were never solved on unet. My main hack was to learn the concept on the networking and try to apply it on my own in the unity project. Although it is going to be deprecated in the future, I was able to learn how to implement a network game. This includes how to sync movements and Collison resolutions.
In order to see if my task was completed, I would test each part a few times on different modes. If I was able to play through the game from start to end without any glitch and all intended information was synced up, the task would be completed.
Being an RTIS student I have had networking classes that helped be understand what is going on the backend. Applying what I learned onto a working game was a new experience. This also made sure that I had to be organized with the information that was being sent, as it might get messy after a while.
bottom of page