question

Actually, maybe yes.  There are leaderboards that rank ties with the same positions.  Here is an example I found without much searching on the internet.  Obviously there is still a order to which person comes first in the tie, such as the first person to finish a match.  I think what the OP may be suggesting is that there needs to be 2 pieces of data: the rank position and the sort order position.  It would be friendly for the GetLeaderboard call to pass both back, but they can also write their own function to calculate rank position since the score data is already being returned.

I think it is pretty common to display leaderboards like the OP wants.  Our studio has made games that display leaderboards in this way in the past.  I would vote for including it in PlayFab.

Exactly - the order players appear in the list is their position, which is exactly what our leaderboards do, as well.

The main issue with the proposal is around how to determine when players have tied scores. I know that sounds trivial, but consider that both scenarios of storing this information with the leaderboard and calculating it on the fly are error-prone:

a) If you tried to store the value with the leaderboard entry, that would require iterating through the following entries to find all duplicate scores and updating them. Scores updates while this is done would introduce errors.

b) If you iterated backwards to find all matching scores, in order to return an indication of the "calculated position", changes made to the leaderboard while the code is doing that would again introduce errors.

In both cases, this becomes especially bad when you take into account titles with very narrow ranges of scores, causing many players to have matching entries. And even without that, we do have to design for titles having millions of users (and so, millions of entries), making this much more likely to occur.

Now, the example found is for the Masters Tournament, rather than a video game. Personally, I have not seen this used in the video games I commonly play, but I wouldn't be surprised if some did what Wayne suggests and calculated the display based upon matching scores. That would really be the best way to go. It is true that players at the top and bottom of the displayed list may not have the correct indication of position if they're tied with people who are above/below the loaded values, but the error there is lower risk than the errors mentioned above.

That said, @Wayne, if you have a proposed design for a better solution which would avoid the errors I mentioned, feel free to let us know and I can talk through this with the engineering team.

I don't have a solution at this time.  Leaderboards can be challenging to engineer at large scale.  In the past, we usually tried to bin down to small set sizes so post-processing the data to get it to display the way you like is easier.

Brendan, I don't know what you are using as your backend DB, but this ranking is sometimes possible directly in the query (SQL Server), or when it's not, it's still possible like in MySql :

SET @prev_value = NULL;
SET @rank_count = 0;
SELECT id, rank_column, CASE
    WHEN @prev_value = rank_column THEN @rank_count
    WHEN @prev_value := rank_column THEN @rank_count := @rank_count + 1
END AS rank
FROM rank_table
ORDER BY rank_column

You probably have a NoSql DB and I don't know them very well, but perhaps there is builtin procedures that does the job ?

That query works, if you're reading the full table, but in the case of a large-scale database, you have to skip to the starting point for the read. That then means you have the same problem I described above, when doing the calculation locally - you can't tell what the first player in the list should be in the display, without reading back through the scores "above" the top one in the listing.