Selecting authoritative host after matchmaker matched players

Game Design
1

Hello Friends!

I’m using Nakama in Unreal Engine. I’m trying to achieve following logic flow:

  1. Match players (normal matchmaking functionality)
  2. From matched players select one to be a host
  3. Host creates Steam session (only for now, later I will do relayed p2p)
  4. Other players join host’s session

Points 1, 3, 4 are not a problem, but I’m wondering how to select a host so that all players know his ID. I was trying to use matchmaker_matched method to manipulate one player’s properties, but it looks like “Match” payload that I receive on each client doesn’t have those changes.

Do you have any other idea how I could achieve that? This is my server logic, maybe there is an issue? As I come from C++ world, lua language is not my thing :slight_smile:

local function matchmaker_matched(context, matched_users)
  
    if #matched_users < 2 then
      return nil
    end
  
    matched_users[1].properties["host"] = true;
end

nk.register_matchmaker_matched(matchmaker_matched)

Thank you very much for all your help!

2

Hello @Sitiana,

Adding properties to the matched users in the matchmaker_matched function won’t work in the Lua or JS runtimes as the hook wasn’t designed to work in such a way, and the underlying Go structs aren’t updated to mirror these changes, but I believe it should work in the Go runtime.

As an alternative however, you could do an alphanumeric sort on the user IDs to select the host, or the sessionIDs of the players (which offers some randomization).

Hope this helps.

3

Hello @sesposito,
Thank you very much for your answer. I implemented alphanumeric sort and it works well for now - of course there are some drawbacks from moving this functionality from server to client.

If some functionalities are only available in Go runtime, is that the most recommended language to use with Nakama?

4

This is not a matter of functionality being absent for the JS or Lua runtimes, but rather a quirk of their implementation, the matchmaker_matched function is not really designed to mutate properties of the matched players, although you can achieve it in Go.

We strive to have feature parity across all the runtimes, however there are a couple exceptions - in which case it’s possible to register and mix usage of the several runtimes.

There are pros and cons between the supported runtimes/languages, so I’d say it depends on which language you are most comfortable with and what useful features would using a particular language expose.

1 Like
5

I see, thank you very much for the explanation.