Dev Log - Multiplayer Social-Deduction Game #1
first in a series of dev logs for my connected games module.
Introduction
I’m starting a new blog as part of my Connected Games Development module. The aim is to develop/design a 3D multiplayer as part of a small multi-disciplined team. As one of the developers, I’ll be sharing regular updates on the game’s progression. With that said here’s Dev Log #1!
🧠 Initial Brainstorming
The aim is a social deduction game, inspired by the likes of Secret Hitler, Werewolf & Cluedo. The challenge with the design will be finding a way to adapt the classic board game, turn-based rules to a more dynamic action, first-person shooter.
🗂 Setting Up the Project
The team went with Unity3D as the game engine for this project. Unity’s faster compile/build times makes it a lot more convenient for quick prototyping. Godd documentation, also makes things easier if we do run into issues along the way. To begin with, I set up a new project using Unity’s HD render pipeline; while the theme or art style is still up in the air, this lets us play around with some of the advanced lighting and shader features later down the line.
Having worked on a few projects have a routine in place… Firstly we setup a repository on GitHub for the project. We add the standard Unity .gitignore file and use GitBash in the project folder to set up git LFS. Next I have 2 assets I use for prototyping and organisation: Rainbow Folders & Gridbox Prototype Materials. I try to keep projects organised from the get-go and the ready-made materials mean I don’t have to start every project with creating a playerMat, floorMat etc.
Next up is BuildSettings. Ported from another of my projects. This was originally used to change the target server from dev to release builds. Eventually, the goal is to connect an SQL database to the game but for now, the script simply updates the Scripting Define Symbols.
Why? well, any code I do not want in the final build goes into a #if DEVELOPMENT block. this way there’s no need for refactoring later. Especially useful for Debug logs.
1
2
3
#if DEBUGGING
Debug.Log("Joined Lobby");
#endif
Next up, was constructing the main menu scene. The scene consists of the NetworkManager which handles the communication with the Photon system and the MenuManager which handles switching between menu panels. At the moment this system simply toggles the screens on/off but it can be quickly changed to accommodate an animated UI.
💡Diving into Photon
For the multiplayer plugin our team went with PUN2. Following the Photon as well as the module tutorial I began the basic setup for the system. The NetworkManager, or ‘Launcher’ in the tutorials is where we connect to the server and join a room. The sample script included some references to a control panel which the manager would toggle directly. This was refactored to decouple the classes from each other, opting instead to have static events that the MenuManager could listen to.
The approach of the tutorial was that of random matchmaking. when the game is started the player would connect to the Photon network and immediately join a random room.
1
2
3
4
5
6
7
8
9
10
if (PhotonNetwork.IsConnected)
{
// #Critical we need at this point to attempt joining a Random Room. If it fails, we'll get notified in OnJoinRandomFailed() and we'll create one.
PhotonNetwork.JoinRandomRoom();
} else
{
// #Critical, we must first and foremost connect to Photon Online Server.
PhotonNetwork.ConnectUsingSettings();
PhotonNetwork.GameVersion = gameVersion;
}
As our game is designed as a cooperative effort this approach would not work. Instead on Awake, we connect to the Photon Network, using the PUN callback OnConnectedToMaster, we then connect to a lobby. According to the forums, lobbies are where all available ‘Rooms’ are listed, making it perfect for our use case.
1
2
3
4
5
6
7
8
9
10
11
public override void OnConnectedToMaster()
{
if (isConnecting)
{
#if DEBUGGING
Debug.Log("Connected to Master Server: Attempting to Join Lobby");
#endif
LogFeedback("Connected to Master");
PhotonNetwork.JoinLobby();
}
}
Once there, players can create or join rooms allowing players to band together. Most approaches I’ve encountered in other coop games involve an alphanumeric ‘code’ to enter a room, so this potentially has to be adjusted. At the moment the Create Room screen has an input field for naming it.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public void CreateRoom(string roomName)
{
if(!string.IsNullOrEmpty(roomName))
{
PhotonNetwork.CreateRoom(roomName, new RoomOptions { MaxPlayers = this.maxPlayersPerRoom, EmptyRoomTtl = 0 });
MenuManager.Instance.OpenMenu("loading");
}
else
{
#if DEBUGGING
Debug.LogError("Input Field is empty. Room name must not be empty");
#endif
}
}
In terms of updating the tables, there are three callbacks I use. OnRoomListUpdated. OnPlayerEnteredRoom, OnPlayerLeftRoom. I use these to update the room list and player list respectively. These invoke delegates which the Menu’s listen in to. this removes the dependency but also prevents the MenuManager from having to inherit from the pun callbacks class.
1
2
3
4
public override void OnRoomListUpdate(List<RoomInfo> roomList) => RoomListUpdated(roomList);
public override void OnPlayerEnteredRoom(Player newPlayer) => RoomPlayersUpdated();
public override void OnPlayerLeftRoom(Player otherPlayer) => RoomPlayersUpdated();
Finally, the ‘Start Game’ button is only available to the master client. when it is pressed the game loads the room into the game scene.
1
2
3
4
5
6
7
8
9
10
11
12
13
public void StartGame()
{
if (!PhotonNetwork.IsConnected || !PhotonNetwork.IsMasterClient)
return;
//TODO check for min players
#if DEBUGGING
Debug.Log("Loading Game Scene");
#endif
PhotonNetwork.LoadLevel(1);
}
Game Scene
The game scene has a GameManager script which at the moment instantiates the player objects. when following the tutorials I encountered an issue with the replication of the master client. while clients could see other clients, the master could not. After some further digging, I found that the solution to this was a static reference to the local player. This would be stored in the PlayerManager script that would also be attached to the player.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
//Old Method
private void Start()
{
PhotonNetwork.Instantiate(this.playerPrefab.name, new Vector3(0f, 5f, 0f), Quaternion.identity, 0);
}
//New Method
private void Start()
{
if (PlayerManager.LocalPlayerInstance == null)
{
Debug.LogFormat("We are Instantiating LocalPlayer from {0}", SceneManagerHelper.ActiveSceneName);
PhotonNetwork.Instantiate(this.playerPrefab.name, new Vector3(0f, 5f, 0f), Quaternion.identity, 0);
}
else
{
Debug.LogFormat("Ignoring scene load for {0}", SceneManagerHelper.ActiveSceneName);
}
}
Player Prefab
The player prefab is instantiated for each client. At the moment it consists of a basic capsule, a character controller component controlled by the PlayerController script and the PlayerManager script. players have the PhotonView and PhotonTransformView components allowing for them to be synchronised across the network. So far I’ve tested this with three concurrent players and both positions and rotations were correctly synced.
As a bonus, I also wrote a small script to display the gamertag above players and rotate it towards you’re own camera view.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private void Update()
{
if (!photonView.IsMine)
{
var dir = transform.position - PlayerManager.LocalPlayerInstance.transform.position;
var rotationEuler = Quaternion.LookRotation(dir).eulerAngles;
if(constraints.X) rotationEuler.x = 0;
if(constraints.Y) rotationEuler.y = 0;
if(constraints.Z) rotationEuler.z = 0;
transform.rotation = Quaternion.Euler(rotationEuler);
}
}
➡️ Next Steps
firstly, I’ll be looking at adding placeholder models for the players. I’ll work on synchronising the animators as well as selecting a unique model for each of the clients connected. I’ll be looking at developing some of the basic mechanics with the game like pickups/equips and use RPCs to allow for proper networking.