Handling larger (1,000+ entry) leaderboards?

Question

question

corporate asked Jan 11, '18

Handling larger (1,000+ entry) leaderboards?

Hi there -

I will be adding leaderboards in an upcoming release for my Unity-powered mobile title. We expect each leaderboard to have 1,000+ entries (essentially, one for every user to have submitted a particular statistic). The above means that we need some sort of a solution for retrieving and presenting leaderboard data in a way that is mobile-friendly, does not cause performance issues on the device, and does not trigger excessive PlayFab queries.

The solution I'm leaning towards is something like this:

On opening the leaderboard, the user is automatically redirected to their own location on it (GetLeaderboardAroundUser).
Since we're talking mobile performance, I'd like to keep it to 20 entries per page, so I'd limit the result size to 20 entries (there are workarounds for that limit, but I'm not sure how much sense they'd make in the long run - see below)
The user always has the option to go to the first page of the leaderboard (GetLeaderboard, StartPosition = 0, MaxResults = 20).
On any given page, the user has the option of going to the previous page (GetLeaderboard, StartPosition = currentPosition - 20, MaxResults = 20) or the next page (GetLeaderboard, StartPosition = currentPosition + 20, MaxResults = 20)

In the above solution, a fresh GetLeaderboard call will be made every type the user flips pages, goes to their own page, or to the current page.

Is this excessive? I was wondering if there is a caching solution of some kind, but since GetLeaderboard results are anyway limited to 100, it seems that navigating any leaderboard with 100+ entries would involve repeated queries to PlayFab.

Another alternative is to make each leaderboard page 100 entries long (that is, the maximum amount of entries that I can get per request). In theory, this could reduce the frequency of leaderboard queries (as there would be fewer pages in total); in practice, this advantage would probably disappear with more users (if I have 10,000 leaderboard entries, I still have 100 pages to go through).

If absolutely and truly necessary, I suppose I could look into a solution that builds up a cached leaderboard as the user flips through the pages (e.g., every time they query a page, it gets cached). I could then limit the user to only refreshing the data of that particular leaderboard every so often. However, that would be a bit complex from the coding standpoint (can be done, but certainly far less straightforward than relying on the GetLeaderboard query)

Leaderboards and Statistics

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 · 2018-01-11T22:15:30Z

brendan answered Jan 11, '18

Having an entry in the leaderboard for every player is actually the common pattern, but you are quite right in thinking that you'll always want to find ways to optimize your backend calls - in part to prevent any issues with call rates to the service, but also because you need to be concerned about the fact that the device may not have a good internet connection 100% of the time (going through a tunnel, etc.) and that if you make a lot of calls, you'll drain the player's battery fast, which can irritate your players.

In terms of how many entries you show to a player at a time, that's going to be down to what you think is best, in terms of your visuals. For mobile, 20 per page sounds like a good target, particularly if you're presenting a rich set of info for each player, using their profile data. Ideally, you'd query for the max number of players (100) at a time, so that you have that as your "cache", allowing the player to page up or down at least a bit before you need to re-query.

And yes, showing the player their own score as the default is always a good idea, since it's more personal to the user than the set of players at the top (though they'll obviously want to be able to see that as well).

We'll also be providing more leaderboard options in the future - keep an eye on our announcements via our blog and in the Game Manager for news on the latest updates.

3

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.

corporate commented · Jan 11, 2018 at 10:25 PM

Hi Brendan -

Thanks a lot for this! Do I understand you correctly that, from PlayFab’s perspective, the outlined use case would not raise issues in terms of call frequency?

In practice, I don’t think a lot of people would spend too much time flipping through leaderboards, but you never know! And yes, I would be presenting users’ position, score, DisplayName, and FB picture if available.

0 ·

brendan corporate commented · Jan 12, 2018 at 02:25 AM

As long as on a per-player basis, you're not issuing dozens of calls per minute on average over the lifetime of the session, you should be fine. I'd throttle the rate at which players can page through the listing, to make sure they can't deliberately mess with you (via the game interface, at least). Having the scores animate in is a good mechanic for that.

1 ·

corporate brendan commented · Jan 12, 2018 at 06:06 PM

Thank you, @Brendan! You've been so incredibly helpful throughout our development effort - honestly, if it wasn't for you, I don't think we'd have ever gotten our back-end off the ground! I'm a first-time developer, so having this support from PlayFab was a huge boon.

0 ·

question