Currently we have matchmaking implemented using the Rocket sample as a base, and it works pretty well. Our matchmaking algorithm is pretty simple, it is more or less a queue waiting until we have sufficient players, so in theory there shouldn't be much more than maximum 15-20 concurrent players. I'm wondering if the Multiplayer Entities could be a good candidate for the matchmaking instead, because this way we can make use of the callbacks

OnParticipantSessionEnded

,

OnClientAppStatusChanged

etc. to determine whether the player is online, instead of relying on dispatching heartbeats from the

SessionActor

? I suppose this way we can detect earlier if a client has connection issues? If our matchmaking algorithm evolves to be more complex, how many concurrent players is estimated to be easily be handled by a Multiplayer Entity? Thanks beforehand for your help!

Yeah, the Rocket's MatchmakerActor is a plain EphemeralActor in order to keep it simple, and provide an example of such actor. You can definitely inherit from the MultiplayerEntity to gain the additional functionalities and boilerplate, and you'll likely want to still use an Ephemeral version of the entity and not persist it in the database. The Multiplayer Entity does run e.g. the Action Journal (Timeline), so there is some additional overhead you're inheriting, but it's probably not that bad compared to the utility you can get from the multiplayer functionalities. I wrote those heartbeat messages into the Rocket's Matchmaker Actor back when our Multiplayer Entity was in early stages, and didn't have e.g. the

OnClientAppStatusChanged

. The message passing is somewhat obsolete approach by now, I guess.

Thanks a lot! That makes a lot of sense