question

bindin00 avatar image
bindin00 asked

Implementing team leaderboards using 'dummy users'

Hello,

To explain my use case: I'm trying to set up some sort of 'team leaderboard' functionality.

My plan was to create a 'dummy user', which would hold the stats of the team.

Each of these teams would have a 'dummy user' that holds their stats, so I could then just look up some leaderboard for team_stat_games_won, and the leaderboard would look up the team_stat_games_won statistic, which is only ever set for the 'team dummy user' accounts, so that seems like it would work.

To create these 'dummy user' team accounts, I would:
-Create a shared group, let the unique id be generated
-Use this unique id as the username, and register a new PlayFab user (the playfab username must be between 3-20 chars, question #1 is will the unique generated shared group id be between 3-20 chars? I couldn't find any info besides that it's unique. Question #2 also not sure if everything in the client API is included in the server API, but I was planning on using the client API register PlayFabUser on the server side to create this 'dummy user')

To update the team's statistics, I would:
-Attach a regular 'real user' to a 'team/dummy user' by setting some custom user data linking to either the shared group / dummy user playfab id.
-I could then update the team_games_won statistic for the player's team by looking up which team they were on(playfab dummy user id), and then update that statistic specifically.

-I would still be able to update player_games_won statistic for the actual 'real player'

Some additional notes:
- If the same statistics exist for both players + teams, half of the statistics taking up limit space are wasted.(blank team_ stats for real players, blank player_stats for 'dummy team players'. I guess this is fine for now)
-How would this approach affect my DAU? The 'dummy team users' would never be logging in, but their statistics would be updating frequently

I've heard that you are releasing a new 'clans/teams' feature sometime in Q1, however as of now we don't really need too much functionality in regards to teams, pretty much just the leaderboard stuff explained above (nothing like a shared inventory or anything like that),

Do you think the above approach is a good idea? Is it even possible? Or should I hold off on this and wait for your 'teams/clans' release that I'd assume is going to have some sort of leaderboard functionality.


Also @Brendan, the only use for the 'shared group data' in this example is to use the API to generate a key that I know will be unique (which I believe is the case when creating a shared group and not providing its ID . If no SharedGroupId is specified, a random identifier will be assigned.), I was wondering if this identifier is limited to between 3-20 characters, if this is the case I'm thinking I could use this as the Username field when trying to register a new 'dummy user' for the team.

Thanks for reading and building an awesome service,
-Dan

10 |1200

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

1 Answer

·
brendan avatar image
brendan answered

I'm sorry, but that's really not going to work. If you have a large number of players trying to write to a data element (a statistic, in this case) which is intended for a single user, you're a) going to have write collisions all over the place, causing errors, and b) your title is going to get throttled or possibly blocked, as that has the potential to cause a hashing issue on the data table.

We are indeed going to be releasing our guilds/clans/teams functionality next month, though guild leaderboards are going to be a V2 release later in the year. If you need what you're describing in the near-term, I'd have to recommend using an external data table.

3 comments
10 |1200

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

bindin00 avatar image bindin00 commented ·

To explain my use case a bit further:

There would not be a large number of players trying to write to the statistic.

Short example of how I'm thinking the stats would be updated.

1) There are 4 players in the game room, and the game has just ended.

2) The server then iterates over the players, updating their statistics as usual

3) The server then does some logic to determine if all 4 players belong to the same 'team'

4) If they do, then the "dummy team user's statistics are updated" (by the server, once)


I'm thinking with this set up the only time write collisions would occur is if say you have:

8 people on a team, in 2 rooms of 4, and they ended at the same time and tried to update the 'dummy team users' statistics. This could be handled by only allowing 1 full 'team room' at any given time, to make sure that data element will never be written to by multiple 'game rooms' at the same time.

With this updated info would you still recommend using an external data table? (The only short term need is the leaderboard functionality, nothing else)

0 Likes 0 ·
brendan avatar image brendan bindin00 commented ·

Yes, I would. Your assumptions for the case you describe include that you will have a relatively low number of concurrent players. What happens if your game takes off massively, and you have 2-300K concurrent users? 1M? Basically, your worst case (and best) when planning for backend server usage is overwhelming success. If your design won't scale to high concurrency numbers, you're guaranteeing a problem at the exact time you don't want to have any problems if you have a hit game.

0 Likes 0 ·
bindin00 avatar image bindin00 brendan commented ·

Sounds good, thanks for the info Brendan!

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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