Does this actually address the 3+ player situation?

Have I missed something or does this lecture not actually cover the three or more player situation, where one player is eliminated but two players remain?

In my testing, after carefully following the code presented, the eliminated player can still box-select after they are dead. I was expecting to see something like a new UnitBase.ClientOnPlayerDie action and associated disabling of the UnitSelectionHandler when raised. Perhaps easy enough to add though, thanks to the helpful guidance of the lecture.

EDIT: actually, it’s not as easy to implement as I thought it might be. I created a new Action ClientOnPlayerDie in UnitBase that I subscribe to from UnitSelectionHandler with a Client-side RPC function to invoke the Action, but unfortunately the ClientRpc or even TargetRpc calls do not wait for completion of the client function which means that the UnitBase object on the Server is destroyed before the client-side object has a chance to run the RPC function. Still trying to work out the best way to handle this, since I can’t find any function-call synchronisation mechanism in Mirror that don’t rely on the Client to respond in an particular way (therefore a security issue).

I think the problem is that the lecture conflates the concept of “Game Over” with the “Player Dead” event - the two are not necessarily the same thing when more than two players are involved.

I’m not sure if it’s ideal, however the way I finally managed to implement this was by creating a new Client-side Action that is invoked when a player has “died”, even if it’s not game-over just yet:

  1. Add a new Action to RTSPlayer:
    public static event Action ClientOnPlayerDie;
  1. Subscribe the RTSPlayer to the existing UnitBase.ServerOnPlayerDie:
    public override void OnStartServer()
    {
        // ...
        UnitBase.ServerOnPlayerDie += ServerHandlePlayerDie;
    }
  1. Unsubscribe too in OnStopServer (code not shown, trivial).

  2. Write the handler for the UnitBase.ServerOnPlayerDie event to filter for our own death and call the client relay function:

    private void ServerHandlePlayerDie(int connectionId)
    {
        if (connectionId != connectionToClient.connectionId) return;

        TargetPlayerDie();
    }
  1. And a Target RPC function to convert this Server event into a Client Action invocation:
    [TargetRpc]
    private void TargetPlayerDie()
    {
        ClientOnPlayerDie?.Invoke();
    }
  1. In UnitSelectionHandler, subscribe/unsubscribe to this new Client Action:
    private void Start()
    {
        // ...
        RTSPlayer.ClientOnPlayerDie += ClientHandleOnPlayerDie;
    }

    private void OnDestroy()
    {
        // ...
        RTSPlayer.ClientOnPlayerDie -= ClientHandleOnPlayerDie;
    }
  1. Respond to this client-side event by disabling the UnitSelectionHandler:
    private void ClientHandleOnPlayerDie()
    {
        enabled = false;
    }
  1. Not completely sure about this, but I think that Targeter also needs to subscribe to UnitBase.ServerOnPlayerDie and call ClearTarget as a result of this event, but this only needs to happen on the server side, not the client side:
    public override void OnStartServer()
    {
        // ...
        UnitBase.ServerOnPlayerDie += ServerHandleOnPlayerDie;
    }

    public override void OnStopServer()
    {
        // ...
        UnitBase.ServerOnPlayerDie -= ServerHandleOnPlayerDie;
    }

    [Server]
    private void ServerHandleOnPlayerDie(int connectionId)
    {
        if (connectionId != connectionToClient.connectionId) return;
        ClearTarget();
    }

If there’s a nicer way to transform a Server Action into a Client Action then I’d use that instead, but I wasn’t able to find one…

Hi there,

At some point in the course we use the ClientOnGameOver event in the GameOverHandler to handle this functionality. This includes disabling the UnitSelectionHandler. If you haven’t reached here yet, then maybe tackle a few more lectures before coming back to this problem.

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.

Privacy & Terms