How to implement a party matchmaking

Hi everyone

I’m currently working on a party matchmaking and I know the same party members have the same TicketId. So I put code below into Lambda. For testing, four client have the same ticket id as players and one client have another ticket as monster.

            match_response = gl_client.start_matchmaking(
ConfigurationName = [MATCHMAKING_CONFIGURATION_NAME],
Players = [ { "PlayerId" : playerId, "PlayerAttributes" : playerAttr } ],
TicketId = ticketIdForParty )

And I’m using an example of “players_vs_monster_5_vs_1” in a document of GameLift

   { "name":"players_vs_monster_5_vs_1",
"ruleLanguageVersion":"1.0",
"playerAttributes":[ { "name":"skill",
"type":"number",
"default":10
},
{ "name":"desiredSkillOfMonster",
"type":"number",
"default":10
},
{ "name":"wantsToBeMonster",
"type":"number",
"default":0
}
],
"teams":[ { "name":"players",
"maxPlayers":5,
"minPlayers":5
},
{ "name":"monster",
"maxPlayers":1,
"minPlayers":1
}
],
"rules":[ { "name":"MonsterSelection",
"description":"Only users that request playing as monster are assigned to the monster team",
"type":"comparison",
"measurements":[ "teams[monster].players.attributes[wantsToBeMonster]"
],
"referenceValue":1,
"operation":"="
},
{ "name":"PlayerSelection",
"description":"Do not place people who want to be monsters in the players team",
"type":"comparison",
"measurements":[ "teams[players].players.attributes[wantsToBeMonster]"
],
"referenceValue":0,
"operation":"="
},
{ "name":"MonsterSkill",
"description":"Monsters must meet the skill requested by all players",
"type":"comparison",
"measurements":[ "avg(teams[monster].players.attributes[skill])"
],
"referenceValue":"max(teams[players].players.attributes[desiredSkillOfMonster])",
"operation":">="
}
],
"expansions":[
{ "target":"teams[players].minPlayers",
"steps":[ { "waitTimeSeconds":30,
"value":4
},
{ "waitTimeSeconds":60,
"value":3
}
]
}
]
}

If I don’t put TicketId as a parameter of start_matchmaking(), it works well. However, if I use TicketId, status of tickets are already “SEARCHING”.

What should I do?

To use parties you need to submit all players for the ticket in the same request. Just using the same ticket id will not work.

e.g., something like:


  1. match_response = gl_client.start_matchmaking(
  2. ConfigurationName=[MATCHMAKING_CONFIGURATION_NAME],
  3. Players=[{“PlayerId”: firstPlayerId,“PlayerAttributes”: firstPlayerAttr }, {“PlayerId”: secondPlayerId, “PlayerAttributes”: secondPlayerAttr}, etc…],
  4. TicketId= ticketIdForParty )

Thank you so much and I have one more question. Does that mean all party members share their attributes with each other to request their matchmakings like above start_matchmaking()? So if a party has 4 members, start_matchmaking() will be called with the same parameters four times. is it right?

Each player in the party has their own separate attributes which are then passed in on a single start matchmaking request. Typically the game developer will have a game service or similar where the party will be formed. Once the party is set and ready for matchmaking a single call (yes, only one call per ticket, regardless of the party size) will be made for that group of four. When the completion is observed (typically via SQS) the game service would notify each of the four players in the party that the game is ready to be joined.

Does that help?

It helped me. Thank you very much.

Sorry to bring up an old thread, but to confirm… this means that since players have their own attributes that are passed onto flexmatch, the players in a party can end up on different teams depending on the ruleset that is used. Correct?

@AustinK I believe it may depend on the rules implemented.
https://aws.amazon.com/gamelift/faq/?nc1=h_ls thanks

@AustinK - Can you help us understand your question as it could be interpreted a number of ways? Are you asking if players in single request could be split up based on your rules? Is it about team organization etc?

Otherwise, this is probably the best pre-canned answer: from (Does FlexMatch support StartMatchmaking where the team is already big enough to satisfy the rule used?)

"If you know all the players that you want to be together on a team, you submit all of them on a single ticket, and then the matchmaker will find players for the other team (assuming you have a match with 2 teams).

If you have all of the players you want for both teams, FlexMatch won’t be able to put the teams together in the same match – you would need to just start your game session by creating it and the player sessions directly."

If that doesn’t help, could you describe the scenario you’re trying to make work

1 Like

I think you’ve answered my question. So I basically have all of my players for a match, and I was creating a flexmatch ticket with both players in the hopes that a game session would be created from that. The reason being is that the game server is built to use the player attributes that are passed through to flexmatch. If I don’t go through flexmatch, I will have to do all of that manually which I was trying to avoid. But it seems that’s the direction I need to go.

Thanks Pip!

Hey @Pip, I think I’ve run into a little issue. So, when you go through flexmatch, there is a field that exists in the GameSession called MatchmakerData which, if I understand correctly, is used for Flexmatch but can also be used by the GameServer to get information about the user. If I don’t go through Flexmatch, there is no way for me to get those same attributes to the game session I’ve just created. I see that there is a PlayerData field inside PlayerSession when I create my own game session manually, but that’s not the same as MatchmakerData. Is there a way to either a) set the player attributes in matchmaker data when manually creating a game session, or b) set player data for each player that’s being sent through flexmatch?

Just to close this thread out - FlexMatch matchmaking data is only set for matchmaking generated game sessions and player session data is not set by FlexMatch at this time.

If you are making your own matches then you need a hybrid approach, ie read the matchmaker data if it exists, or send it along via GameSession data/properties or via player session data when it doesn’t (ie manual match mode)