Dev Log - Multiplayer Social-Deduction Game #2

---

title: “Dev Log - Multiplayer Social-Deduction Game #2” date: 2025-01-01 10:00:00 +0000 categories: [Game Dev, Networking] tags: [photon, pun2, multiplayer, game dev]
description: Second in a series of dev logs for my Connected Games module. image:
path: /assets/img/headers/2.jpg —

🎮 Introduction

Since the last update, I’ve been working on adding new features and polishing existing ones. If you’re just joining, check out Dev Log #1 to catch up on my initial steps and challenges.

In this update, we’ve tackled:

• Character animations and room joining issues.
• Custom shaders for interactable objects.
• Lag compensation for smoother gameplay.

🏃‍♂️ Character Models & Animations

One of the first things I wanted to get working was synchronizing animations and models. Since players will be able to customize and pick their own character models, these models must be instantiated at runtime by each client.

The built-in PhotonAnimatorView component syncs animations but only works when the model is already part of the base prefab. When instantiating models dynamically, the animation view wouldn’t sync with the parent PhotonView.

🎭 Solution: Manual Animator Synchronization

The solution was to manually synchronize the animator parameters. I created a PlayerAnimController script that attaches to the base player prefab. When prompted via an RPC call, a model is instantiated, and its animator reference is passed to the controller.

🔄 Instantiating Character Models

[PunRPC]
private void InstantiateCharacter(int ownerViewID, string modelPath)
{
    var owner = PhotonView.Find(ownerViewID);
    if (owner && !string.IsNullOrEmpty(modelPath))
    {
        var model = Resources.Load<GameObject>(modelPath);
        var modelTransform = Instantiate(model, owner.transform).transform;
        modelTransform.localPosition = Vector3.zero;
        modelTransform.localRotation = Quaternion.identity;

        GetComponent<PlayerAnimController>().animator =
            modelTransform.GetComponent<Animator>();
    }
}

📡 Syncing Animator Parameters

Using the IPunObservable interface, we synchronize the animation values between clients.

public void OnPhotonSerializeView(PhotonStream stream, PhotonMessageInfo info)
{
    if (stream.IsWriting)
    {
        stream.SendNext(xVal);
        stream.SendNext(yVal);
    }
    else
    {
        xVal = (float)stream.ReceiveNext();
        yVal = (float)stream.ReceiveNext();
    }
}

To smooth movement updates, we apply damping in the Update() method.

void Update()
{
    if (inputHandler != null && photonView.IsMine)
    {
        xVal = inputHandler.MoveInput.x;
        yVal = inputHandler.MoveInput.z;
    }

    if (animator)
    {
        animator.SetFloat(moveX, xVal, directionDamp, Time.deltaTime);
        animator.SetFloat(moveY, yVal, directionDamp, Time.deltaTime);
    }
}

And the final result:

---

🔄 Room Synchronization - Late Joiners

Initially, our game didn’t support late joiners, as players are meant to be in a fixed group. However, to handle cases like disconnections, I implemented a solution allowing players to rejoin the game.

🏗️ Handling Late Joiners

I experimented with pausing the message queue on PhotonNetwork. The queue would then be resumed once the client had loaded into the game scene. This didn’t work… My hunch was that the instantiation calls were executed before the scene change and as a result the models would actually delete once it had finished

The breakthrough came with the use of custom room properties. When the master client starts the game and loads the next scene, they also set the gameStarted property to true. With this, instead of using buffered PhotonNetwork.Instantiate() any late players simply load into the game scene locally before trying to join the room.

public static void JoinRoom(RoomInfo roomInfo)
{
    if (roomInfo.CustomProperties.TryGetValue(RoomProperties.GameStarted, out object GameStarted) && (bool)GameStarted)
    {
        PlayerPrefs.SetString(RoomProperties.RoomKey, roomInfo.Name);
        SceneManager.LoadScene(1);
    }
    else
    {
        PhotonNetwork.JoinRoom(roomInfo.Name);
        MenuManager.Instance.OpenMenu("loading");
    }
}

On scene load, we check if the player is already in a room. If not, they attempt to rejoin.

private void Start()
{
    if (PhotonNetwork.CurrentRoom != null)
        InstantiateNewPlayer();
    else  
        PhotonNetwork.JoinRoom(PlayerPrefs.GetString("RoomKey"));
}

The OnJoinedRoom callback ensures late joiners spawn correctly.

public override void OnJoinedRoom()
{
#if DEBUGGING
    Debug.Log("Late Joiner, Instantiate Player Character");
#endif
    InstantiateNewPlayer();
}

---

🌐 Lag Compensation

I started implementing lag compensation to ensure smoother gameplay. One key aspect was synchronizing each client’s camera pitch so players can see what others are aiming at.

🎯 Syncing Camera Pitch

Using IPunObservable, we transmit the camera’s pitch value.

private void HandleClientSync()
{
    var oldPitchValue = mainCamera.transform.localEulerAngles.x;
    oldPitchValue = (oldPitchValue > 180) ? oldPitchValue - 360 : oldPitchValue;

    var targetPitchValue = Mathf.SmoothDamp(oldPitchValue, pitchValue, ref smoothVelocity, smoothTime);
    mainCamera.transform.localEulerAngles = new Vector3(targetPitchValue, 0, 0);
}

---

🛠️ Game Mechanics & Shaders

🔄 Interactable Items

To implement interactable items, I created an IInteractable interface with methods for focus detection and interaction.

public interface IInteractable
{
    public bool Interactable {get; set;}
    public abstract void OnFocus();
    public abstract void OnExitFocus();
    public abstract void OnInteract(int ownerViewID);
}

Additionally, we created an IEquippable interface extending interactable items for equipment mechanics.

🗡️ Item Class

I also created a base class for these items. This was class was designed as abstract and would house all the lag compensation and synchronisation code. It also implements the interface but declares the functions as virtual allowing child classes to implement their own behaviours.

Toggling between isKinematic on the rigidbody caused issues the solution was to toggle the reference from the rigidbody to the transfrom

You can then lerp the position to the adjusted network position

🔦 The Torch

Our first interactable item was a torch that reveals hidden clues when activated. The base class implements the RPC calls.

nameof is used to preserve function references. the calls sync the state of the torch with clients.

a PointLight is attached to the GameObject. The ToggleTorch RPC changes the intensity of that light accordingly. In this function we are also passing through the state from the interacting clients. This should prevent the on/off state of the torch going out of sync for the players.

🖌️ Custom Shader for Hidden Clues

To reveal hidden clues only when illuminated, we created a shader that modifies an object’s alpha based on light intensity and direction.

float strength = (-dotProduct) - cosThreshold;
strength *= smoothAttenuation * clampedIntensity;
return faceColor * strength * input.color.a

And here is the result:

---

📌 Next Steps

That wraps up Dev Log #2! Next, we’re focusing on:

• Finalizing the core game loop.
• Expanding interactable mechanics.
• Refining lag compensation and animations.

Stay tuned for the next update! 🚀