Different Types of MaxPlayers

blueteak

Hello! I've been using Photon quite a lot recently, and one of the things we'd like to set up is a system for Asynchronous multiplayer with different device types.

However, we've run into a problem with the way MaxPlayers works. We would like to create an 8 player multiplayer room that allows 4 computer players and 4 mobile players, however we need the room to stop a 5th mobile player from connecting if the 4 slots are filled, but still allow 4 computer players to connect.

Due to race conditions regarding joining a room and then setting a separate custom property, we need to be able to create some other form of MaxPlayers that will take a parameter when trying to join a room (ie "mobile" or "pc") and then accept/reject based on how many slots, and then when it accepts auto-increment the correct value like it does with player count.

Please let me know if this is possible or how best I might achieve something like it

[Deleted User]

Hi @blueteak,

yes this is possible.

Whenever a client creates the room, it will be created with MaxPlayers set to 8 as this is required. When creating the room the client also set custom properties: 'NumberOfMobileClientsConnected' and 'NumberOfComputerClientsConnected' both set to 0. These properties can be made to the lobby, too, by using RoomOptions.CustomRoomPropertiesForLobby.

If a client now joins the room and OnJoinedRoom() is called, the client can check his current platform using if (Application.isMobilePlatform) { } else { } and increase the matching room property based on the result of the previous condition.

Before actually joining the room, the client needs to check if there are enough slots free in order to allow him joining. Since you have published these properties to the lobby this can be done mostly like shown before.

You can read more about this in the Matchmaking Guide.

blueteak

That is how I would expect to go about it, however if a two players join a room near-simultaneously, there will be a period of time between when the first player is in the process of joining the room but before they have increased the room-property where the second player thinks they should be able to join, even if the first player will fill up the mobile slots.

The issue, unless I am mistaken, is that the MaxPlayers property is special compared to other room properties in that it is modified by the server and not the client joining the room.

What I want to do is use JoinRandomRoom with that special custom property and have JoinRandomFail if all rooms are full of mobile players. Unless I don't understand correctly, this would not work if two people tried to join a 3/4 game at the same time, since the check only happens when JoinRoom starts, and if both start joining before the first updates the property then both will be allowed to connect.

[Deleted User]

You are right about this. This is actually a case I honestly didn't think about.

But maybe we can use this approach nevertheless and extend it a little more by letting the MasterClient decide which client is allowed to join and which one should leave the room.

So when being connected to Photon you can set the Player Properties and add the client's platform to them. When a client now joins the room, OnPhotonPlayerConnected(...) is called on already connected / joined clients. The MasterClient can now check the value of connected clients per platform stored in the room properties and decide what happens to the new player. If there are enough free slots, the client can join, nothing happens. However if there are not enough free slots, the MasterClient can send a RPC to the new player telling him to leave the room.

Another task of the MasterClient is to keep track of the Room Properties and increase or decrease the number of players.

blueteak

Oh! That's a very interesting approach. Is there any documentation about denying connection from a player within the OnPhotonPlayerConnected() method?

If there was a way to trigger OnJoinRandomFailed() by the MasterClient responding to OnPhotonPlayerConnected with a "Access Denied" type of message that would definitely solve the problem.

Quite a lot of information gets passed to players once they join a room, even if there was a way to ensure that a particular piece of code gets executed first (either kicking the player or letting them stay) before all the other game info gets passed along it would be useful.

Edit: Alternatively, might it be possible to use 'expectedUsers' parameter when creating a room in a unique way to be a bit more generic so that instead of usernames being used, it sets 4 "mobile" expected users and 4 "pc" expected users? (Matchmaking Slot Reservation section of Matchmaking Guide)

[Deleted User]

Is there any documentation about denying connection from a player within the OnPhotonPlayerConnected() method?

Well you basically don't deny the connection of a player, because when OnPhotonPlayerConnected is called, the new client has already joined the room and is already connected. This is also the weak spot of this approach; clients successfully join the room and get kicked afterwards.

As far as I know there is no optimal solution for this when using the (non-enterprise) Cloud.