Matchmaking Queries

Local Setup
1

We are going to finish our poker game soon, but before going need to fill some gap that we fill as blank in start.
As i told you above we are making poker game of 5 players

Question # 1
Query we are set on matchmaker ticket

minCount = 2 maxCount = 6

when player 1 call AddMatchmakerAsync() with related Query then user add on the matchmaker pool

When player 2 comes he also have same query and flow , both comes out from matchmaker pool , on server side

RegisterMatchmakerMatched hook called

Problem is when player 3 comes he also follow same query and flow but he don’t comes out from matchmaker pool because minCount = 2
and always minCount >1

he waits for 4th player with same query

how to solve this ?

Question # 2

we get list of matches with Query

limit := 10
isAuthoritative := true
label := “skill=100-150”
min_size := 0
max_size := 4
if matches, err := nk.MatchList(ctx, limit, isAuthoritative, label, min_size, max_size, “”); err != nil {
// Handle error.
} else {
for _, match := range matches {
logger.Info(“Match id %s”, match.GetMatchId())
}
}
on match list we dont give the name of match we want to get ?

but when we create a match

modulename := "pingpong" // Name with which match handler was registered in InitModule, see example above.
if matchId, err := nk.MatchCreate(ctx, modulename, params); err != nil {
    return "", err
} else {
    return matchId, nil
}

iparams on matchcreate is Equivalent with match list params except ctx ?

While get list of matches we don’t have to pass gamename .
and while create a match we dont pass room boundaries.

here i clear in future we have multiple types of poker Game

“NOTE: WE are also implementing Bots”

2

Hi, as discussed on chat, here is my response. I am sure Nakama team will correct me if my understanding is wrong.

Question #1: The behaviour is as expected. When you set minCount = 2, as soon as your first two players sent the request they were matched and the match started. By the time the third player sent the request, first two were not in matchmaking, they were in match. Thus the third player remained in the matchmaking queue only.

Different values for minCount / maxCount are useful if you have traffic in production environment, where server may have received MANY matchmaking requests in very short time. In development environment, where you are sending very few requests, it will be very difficult to two test different values for minCount and maxCount.

To summarise, matchmaking will matchmake as soon as minCount users are waiting in the queue and it will make sure that it doesn’t match more than maxCount. But it will not wait for maxCount users before it matchmakes.

If you want the third user to join the same match, you should first look for matches that may have available seats, via MatchList and try to join them first. If no open matches are found, only then send the new player to matchmaking queue.

I hope this addresses your question 1.

Question 2: How to get matchlist the way you want.
I haven’t used MatchList in my game but this is what I understand. Since you have multiple gamemodes, you should assign them different ‘labels’. You will then search the matches by labels, not by modulenames.

E.g. when you create a texas hold’em match, label it “TH” and when you create a Sit and Go table, label it “SG”. BTW, label is created in MatchCreate function. It is the third parameter returned by this function. Now when you want to list all Texas Hold’em matches search for matches with label “TH”.

Does that help?

@novabyte, @mofirouz, @zyro please do correct me / add anything relevant that you may want to.

3

That was a fantastic reply @gupta-vaibhav nice one! :+1:

To summarise, matchmaking will matchmake as soon as minCount users are waiting in the queue and it will make sure that it doesn’t match more than maxCount. But it will not wait for maxCount users before it matchmakes.

Yes exactly. This is by design because players want to be in matches as much as possible. If you want to loosen the search constraints over time you should apply this pattern to your matchmaker logic from the game client:

  1. Make most targeted matching request for the player.
  2. After X seconds cancel it and submit another one with looser constraints.
  3. After X+Y seconds cancel it and submit another one with looser constraints. If no match go to (2).
  4. When matched place the player into the multiplayer match (i.e. join the match).

Since you have multiple gamemodes, you should assign them different ‘labels’. You will then search the matches by labels, not by modulenames .

Yes I agree with this advice with one small tweak. I’d suggest you use numeric enums to assign the match types to search within the match labels on. i.e. “TH” = 1, “SG” = 2, etc. This is a small optimization because it’ll index more efficiently in the search system and generates results marginally faster.