Questions about presences [Relayed]

Runtime Framework
,
1

Part 1

There is three players want to play match.

Amy and Bob create matchmaker by

socket.add_matchmaker_async(...)

when the matchmaker matched, socket will notice by

socket.received_matchmaker_matched.connect(on_received_matchmaker_matched)

func on_received_matchmaker_matched(matchmaker_matched: NakamaRTAPI.MatchmakerMatched)

Amy and Bob will get same user list (same order) by

matchmaker_matched.users

That array is [ Amy’s user, Bob’s user] or [ Bob’s user, Amy’s user]

Use deterministic sorting to decide who is the host, like Official Documentation

Part 2

Amy and Bob join the match immediately by ticket

var current_match = await socket.join_matched_async(matchmaker_matched)

They will get different users(in presences) by

current_match.presences

Amy get [Bob’s presence] and Bob get empty list
or
Amy get empty list and Bob get [Amy’s presence]

Question 1

Is this reasonable?

Part 3

When Amy and Bob playing in match, Chris found that match by

client.list_matches_async(session, min_presences, max_presences, limit, false)

Join later by match_id

var current_match = await socket.join_match_async(p_match_id)

He will get all user presence in match(not including himself) but in different order
That will be
[Bob’s presence, Amy’s presence]
or
[Amy’s presence, Bob’s presence]

Question 2

Since nakama has saved the user list, why can’t the same order be given?
Is there a API to implementnt ?

Question 3

How can the all clients get consistent user list (same content and same order) ?

Question 4

If the clients cannot obtain consistent presences, is it only broadcasted through the host?

In multiplayer games Players order is important which Related to game rules.

2

Hello @wantg,

Q1: Yes, this is expected, it depends on who joins first. Match is empty, A joins, gets empty list as there’s no one else in the match yet. B joins, receives A’s presence as part of Join, then A receives B’s presence through callback.

Q2: The ordering of the presences list maintained by the server shouldn’t matter, only that joins and leaves are received in-order. Nakama may send joins and leaves in the same batch for optimization reasons, but the presence ordering within the same message is not guaranteed.

Q3: If you want to keep your presence tracking data structure ordered to reliably elect the 1st entry as the host, then it should up to your client implementation to keep it ordered, and all clients should eventually converge to the same presence list as they receive the joins and leaves messages.

Q4: I believe this is already addressed in the previous responses.

Hope this clarifies.

3

Thank you sesposito.