Show Sidebar

Webhooks FAQ

How to rejoin rooms?

There are two ways for users to rejoin previously existing rooms that they left and did not abandon. Each one requires a condition to be met and both of them are done by calling LoadBalancingClient.OpJoinRoom() from game client. The passed actorNr argument is different than zero which means a rejoin (actorNr != 0).

  1. The recommended way: RoomOptions.CheckUserOnJoin = true
    The first method could be considered as an implicit rejoin and is totally transparent to the user. It supposes that when the room was first created the RoomOptions.CheckUserOnJoin flag was set to true. In this case to rejoin a room you just need to call OpReJoinRoom() from client SDK.
  2. The explicit way: RoomOptions.CheckUserOnJoin = false, ActorNr>0
    When RoomOptions.CheckUserOnJoin was set to false at the moment of creation of a room, there is always another approach to rejoining it by specifying a strictly positive ActorNr (actorNr>0) in the OpJoinRoom() call. In order to reach the expected outcome you need to use the exact same original ActorNr of the rejoining actor that was assigned to him/her when he/she joined that room for the first time. So you need to save the ActorNr per room for each user.

What if I just set EmptyRoomTtl to its maximum value during new room creation?

This is not possible and the Photon Cloud will return an error indicating that EmptyRoomTtl should be modified to a lower value. The threshold of EmptyRoomTtl in Photon Cloud is set to 300,000 milliseconds (5 minutes) while this value could be changed for privately hosted Photon servers.

For realtime games, a best practice value of EmptyRoomTtl is 12 seconds (12,000 milliseconds).

Can webhooks modify the room's state?

Webhooks can not change the content of the room's state.

Is there any interesting use case for webhooks other than storing and retrieving the room's state?

Well, there are many things possible with webhooks :)

Here's a list of few :

  • Server side authoritative code:
    This can be useful when some specific game logic need to be executed at server side only.
  • Protection against malicious hackers:
    Webhooks can also be handy when it comes to detect cheaters. GameProperties and GameEvent webhooks can be used to authorize players' actions from server side code.
  • Sending Push Notifications from server side:
    With GameEvent webhook sending push notifications can be optimized by sending it from server side to inactive players only.
  • Save game data other than Photon's room state:
    It is not an obligation to use only Photon's room properties or events cache as game data.
  • Analytics:
    Webhooks can be a powerful and free of charge analytics service. The statistics you can track are numerous like room creations, actors joins, room events, ...

Can webhooks modify room events data or send new Photon events?

No, webhooks cannot alter the data of received events nor send any other events.

Is it possible to access custom room properties from webhooks?

The short answer is no. However, the State object, available as an argument in GameEvent, GameProperties and GameClose of Type=='Save' webhooks contains a readable form of public custom properties (i.e. visible to the lobby).

When should an actor be considered as left or flagged as inactive?

Any Photon actor disconnected from a GameServer has left a room somehow. The question is whether the same actor left the room intentionally - which means that he/she explicitly "abandoned" or "quit" or "exited" the room - or not. If left intentionally, the actor will no longer be part of the room's actors and thus removed from the room's ActorList. On the contrary, if the actor temporary left the room willing to rejoin it later then he/she will be marked as Inactive or IsActive = false or IsComingBack.

Any actor joined to a room and still connected to its respective GameServer will always be considered as Active. Actors status is exposed in the room's ActorList in the GameEvent webhook. See its respective section for more information.

To abandon a room, you should call OpLeave(false) and to leave it for a while just use Disconnect() or OpLeave(true). For possible scenarios like "resignation" or "rage quit" specific to some game types, the user could choose one of the two approaches.

See the GameLeave webhook section for additional information.

Does it make sense to have 0 <= PlayerTTL <= EmptyRoomTTL with IsPersistent = true ?

PlayerTTL is the amount of time that an actor can stay inactive inside a room. Meaning, how long a player can stay disconnected from a room. If you create rooms with PlayerTTL = 0 then you should not expect players to come back. And if they don't come back then there is no need to save the room state for them. This is by design, a room state should be saved only if it contains at least one inactive player.

See the GameLeave webhook section for additional information.

 To Document Top