Leaderboard - Regional / Country Specific

Runtime Framework
, ,
1

Hello everyone,
We are trying to decide on which way to implement local / city / region based leaderboards. We are well aware that “THESE” leaderboards can be less populated and not too big, if there aren’t many users playing from same country but in social based game this intends to be less of the case.
These leaderboards do not expire, they are forever there.

Currently how we see it there are two ways we could go, or to approach it:

  1. Using new leaderboards for each country code
  2. Running custom query

Using approach 1) it was all fine, until we hit the limit. There is hardcoded limit within nakama runtime to not list more than 10 000 users.
This is a bit hidden feature, might worth to be put into documentation.
Limit can be found Rank Limit
So first approach is stuck here, as if user is 10001 it will not return his position in the rank leaderboard.
Again this can be solved by running custom query to get only user position in these cases where it is not within first 10k.

But we are already using custom sql query to approach solution 1) then why not go with solution 2) already using query which does both and does not have any user limits.

The cost is obvious constant hitting of the database, and non caching of the data. but that can be limited within user client or even within server side.

So real question is:

  • What do you think it is best way to be approached here option 1) or option 2) because same principle can be used for friends !?

The query we tried goes something like this:

select u.display_name, u.avatar_url, l.score from users u, leaderboard_record l
    where u.location = $1 and l.owner_id = u.id and l.leaderboard_id = $2 order by l.score desc
  1. Versions: Nakama {3.15}, {Docker},
  2. Server Framework Runtime language Lua
2

Hi @Eatos ,

A separate leaderboard for each country code is perfectly fine.

With regards to the 10,000 limit, you should use a combination of LeaderboardRecordsHaystack to get records around the user’s rank, and LeaderboardRecordsList to get the top X records where X <= 10000.

Note that LeaderboardRecordsList returns a nextCursor and previousCursor which can be used to paginate results, allowing you to effectively grab more than 10,000 records by batching the calls.

3

Thank you @tom for your replay.
We have ended up doing that, since we wanted to benefit for caching data and what we do is exactly like that.
Per region we have created global/ country specific leaderboards, and once user score it needs to be added, it is added to all of “his” leaderboards.
In client we wanted to always display first top 3, no matter where user is, and then if user is not within first searched query, we issue additional to search around user and get that view :slight_smile:

The only thing that is a bit suckish here is that we are doing two queries which could be tehnically done in 1 :frowning: so DB is getting hit twice.

4

The queries in Nakama are highly optimised so you shouldn’t encounter any issues using LeaderboardRecordList in conjunction with LeaderboardRecordHaystack, it is a very common pattern that we see a lot of games using frequently with very large leaderboards.