Exhausting EventCodes in PhotonNetwork.RaiseEvent()

Options
Raising events over Photon is a great way to get a lot of your code working in a pretty de-coupled way without needing to have handles on PhotonViews. One issue is the upper bound on the number of event codes that can be defined. Seeing as the variable is of type byte, we have 256 possible different events. Additionally, a number of events are already used by Photon to handle events which makes the number of possible different events even less.

When thinking of scale, this seems like an issue that might cause problems later on once a project gets large enough to require more than this upper bound.

Is PhotonNetwork.RaiseEvent() not supposed to be used to define a large number of events? Should Rpcs instead be used instead? Anyone worked on a project where they exhausted the number of defined events? What did you do then?

Comments

  • Hi @talothman,

    Is PhotonNetwork.RaiseEvent() not supposed to be used to define a large number of events?


    Depends on. After excluding the build-in events, you still have 200 codes left for using Custom Events, which is quite a lot and should cover most (all) use cases.

    Should Rpcs instead be used instead?


    As you already mentioned, RPCs require an attached PhotonView and aren't decoupled of certain objects. In my opinion, RPCs should be used, whenever the event is related to a certain object, for example reducing an object's health value. Any other event should be handled with Custom Events that are not related to a certain object.
  • talothman
    Options
    Thanks @Christian_Simon . Another core feature that I've found useful when using PhotonEvents is the fact that you can selectively delete those events if need be, which is not possible with RPCs unless you delete all RPCs associated with a PhotonView.

    This has been very useful for us in order to present late joining users with the most current state of the room without having to replay events from the beginning of room creation.

    The idea that RPCs update a gameobject's state that they're associated with makes sense.