Using Shared Group Data for a simple async league system.

Question

question

ali asked Jan 23, '20

Using Shared Group Data for a simple async league system.

I've been investigating SharedGroupData to use for a feature in our game. I might have a solution for what I'm trying to achieve but it's kind of weird so I wanted to ask for advice.

Here's the explanation of the feature.

1. One of the game mode in our game is called "Leagues". A league has maximum of 10 players who have similar rankings to each other.

2. We want our players to enter a league whenever they want. If there are no eligible league for their ranking, they would just create a league with only player being themselves. Soon enough, other players would join that league anyway.

3. Players within a league will be able to fight with other players in the league. Winning battles would earn you league points. We need to store small amount of data for each league. (Like how many points each player has in that league.) These "fights" are asynchronous, and doesn't require opponents within your league to be online at that moment.

4. These leagues would last 24h after they are created. At the end of 24h, players will be rewarded based on the league points they were managed to collect.

The first problem is to find eligible leagues since Shared Group Data api doesn't provide any queries. (I understand the reasoning behind that decision, but kinda makes them useless for so many possible use case.)

We thought about using matchmaking to put players in a league together, but that's not the real expected behavior from number 2. We want entering a league to be an immediate action (or as quick as possible) - even though the entered league would be empty in the beginning. Matchmaking solution requires players to constantly check the status of their ticket until a match happens. Since it's an async thing, I'm totally okay for a player to sign up for a league and close the app. There should be another solution.

Another possible solution is to use a separate leaderboard for this league matching process. We can only update this leaderboard stat for matchmaking purposes. When a player with a certain rank wants to enter a league, we check this league leaderboard to find entries close to our rank.

- If there's no eligible player in the leaderboard:

We create a new shared group data and add that player's ranking in the league leaderboard.

- If there's an eligible player in the leaderboard:

We add our player to the eligible player's league shared group data. If this group has 10 players (which is the maximum of players in a league), we remove the owner of the sharedgroup's rank from the league leaderboard (or set the stat to 0)

Since we use a custom server for all playfab interactions, it would be possible to do this.

This second approach makes sense to me right now, but it sounds such a weird use for a leaderboard that I wanted to consult if it makes sense to you. If this makes sense, same approach can be used to query for clans based on a single stat. What do you think?

Leaderboards and Statistics Shared Group Data Matchmaking

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2020-01-24T09:14:58Z

Sarah Zhang answered Jan 24, '20

According to your descriptions, it looks like your main question is about the async matchmaking that based on the players’ rankings, is it right?

>> This second approach makes sense to me right now, but it sounds such a weird use for a leaderboard that I wanted to consult if it makes sense to you.

Leaderboard may not very suit such usages. Firstly, PlayFab leaderboard has the number limits, a free tier can have at most 25 leaderboards. We don’t recommend loop the whole leaderboard to do query operations too. Such operations may exceed PlayFab API call limiting rates. If you want to use the second approach, it will be better to use an external cache (like Redis) instead of leaderboards.

In addition, PlayFab Matchmaking although has some limitations, it can support async matchmaking within 24 hours. Because the max give up time of one matchmaking ticket is 24 hours. “Constantly checking the status of their ticket until a match happens” makes sense for sync multiplayer matches, but it is not necessary for the matchmaking process. Actually the matchmaking process is executed on PlayFab Server, clients just get the status. Clients can get the status when they need, for example, when they open the application. The problem is a match session can’t keep 24 hours, it is recommended to use as a match about one hour. You can combine PlayFab matchmaking and the external cache to make the match keep longer.

1

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

ali commented · Jan 24, 2020 at 09:36 AM

Thanks for the answer Sarah!

Just to clarify a few things:

We are actually using enterprise tier for another project of ours, so free tier limitations are not a problem. Even if it was though, I think I only need a single leaderboard for the use case I described. I'd be using that one leaderboard to do matchmaking. And I don't think I need to loop the whole leaderboard, I can just get players around a certain value.

It's nice to know matchmaking can last 24 hours, but as you say, I need the sessions to last 24 hours as well. Also, I don't want to wait until the match is filled. I want the player to immediately enter a league, even if the league is empty or half filled.

I'm trying to find a solution without the need to use external cache first. If there's no way, we'll investigate other options.

Would be happy to hear your thoughts about using the leaderboard for the async matchmaking process with these additional information.

Thanks for your help.

0 ·

question