Determining Match ID from Match Name


I’m writing a multiplayer, coop game in Godot 3.5.1. The game is turn based and cooperative, and given the nature of the project I think implementation of an authoritative server is overkill and not a strong fit for the game loop. As a result, I’ve chosen to progress using Relayed Multiplayer for the time being. The plan is to use webRTC for Godot, using Nakama as the signalling server.

To that end, I’m currently working on getting the lobby system set up. Since this is for a coop game, and Match ID’s are fairly user hostile, I wanted to get matchmaking done via Match Names if possible.

The general premise is that, upon hitting “Host Game” a random lobby code would be created (6 alphanumeric characters) to derive the Match ID from. Since the Match ID is deterministically driven from this code, others can then join your game with it.

It’s my understanding that for Relayed multiplayer I can’t get a list of taken “Match Names” from the MatchList API, and it appears I can’t set any labels on a match either. However, I can get a list of Match IDs, so in theory if I can map the Match Name to Match ID I should still be able to validate the Lobby Code is unused.

I was wondering if it was possible to determine what the Match ID would be for a specific match name without actually making a connection to a host player? It helps streamline the lobby logic fairly considerably (I can validate a lobby code is unused before spinning up a game without the risk of popping into another player’s active lobby, I can validate a lobby exists before trying to join a game without creating one if it doesn’t, etc.,)

Apologies if this is a dumb question. I’m new to networking, and it’s all fairly overwhelming.

If it’s not available- is it possible for me to create a custom Match Handler like in an Authoritative Server, but otherwise rely on Relay multiplayer logic?

Hello @LemonadeFlashbang,

I’d suggest you use a storage object to keep track of the taken names and keep this record updated as matches are created or terminated, reading it to check whether a name is available or not.

You can create an authoritative match handler by setting up a custom RPC that calls the runtime matchCreate API, provided you also implement the related custom match handler hooks. To make it relayed, you’d simply add logic to relay the messages to all presences within matchLoop. You can see an example of an authoritative match handler here, it should be easy to infer how to strip out all the authoritative logic to transform it into a relayed match handler.

Authoritative matches don’t support using names though, so you’d have to implement something as described here: Custom matchId for private lobby/room? - #3 by mharis.

Hope this helps.

Using a storage object is a fantastic idea, thank you for the guidance.

I do have a follow up question in regards to match termination. It appears I can add records to the storage object via the client, however I won’t be able to remove the records on match termination client side since the game could just be force quit or internet dropped.

Ideally, I’d like to create a function to modify the storage object on match termination with as little overhead as possible.

Is my only option to set a new match handler here, or is there an alternative solution to allow me to run server side code on match termination?

You’d have to use authoritative matches, in the example I linked you’ll see custom code that terminates the match if it has been empty for some amount of time (authoritative matches don’t need connected players and will exist regardless, unless max_empty_sec is set).

You can add some logic to detect if no player is connected to the match anymore after some time, update the storage object and terminate the match.

Just as a point of clarification- when you say authoritative matches are you talking purely about the match handler or would I need to change my entire framework from relayed to authoritative?

You can keep most of your logic relayed but you’d need to use match handlers that mostly just relay the messages. However by adding some authoritative logic you’ll end up with a hybrid approach so you might need to make some slight changes to your relayed logic, but it’s not required you move to a fully authoritative approach.

Hope this clarifies.