question

alexmerza avatar image
alexmerza asked

Shared Group Intended Usage and Optimization?

I'm trying to come up with the best usage of calls for a simple operation, adding users to a shared group.

Since PlayFab doesn't have a function that retrieves all shared groups a user has in common, I figured adding a "Groups" master index on individual users would be the best way to go about it. Now it's feeling a bit awkward and I feel like this is wrong due to the order of operations involved in simply adding a user.

This is the workflow:

- GetUserAccountInfo (we retrieve the playfabID for the user we want to add)

- AddSharedGroupMembers (request to add the playfabID to the sharedgroupID)

- GetUserData (we retrieve the current value of master index)

- UpdateUserData (we update the master index with the new group to join for the playfabID)

This feels like I'm making unnecessary calls to GetUserData, is there a way to retrieve the UserData and AccountInfo with the same call?

10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

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

Well first, we advise against adding users to the shared groups directly, as that gives the client full authority to update anything in the shared group (unless you turn off that API call via the API permissions model). But in general, shared groups are designed for sharing a relatively small amount of data between a few users - for sharing state of a turn-based asynchronous game, for example.

Most commonly, shared groups are created with predictable naming, so that they can be looked up without a master index table, but if your design precludes that, it would be best to keep that index, yes. I'm curious why it's necessary to look up the player's PlayFab ID in your model, though. Usually when creating a shared group, you already have the IDs of the players who will be part of it, through an async matchmaking process (using leaderboards) or a friends list.

Actually, starting from a top-level view of the actual feature would likely be best, as knowing the complete picture will give us a much better ability to provide guidance on the best approach. Can you give us a quick overview of your gameplay and what you'd like to use shared groups for?

2 comments
10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

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

alexmerza avatar image alexmerza commented ·

I swear I have replied to this, but I have no clue where my message went, so here's the second attempt at a reply.

We plan on using groups like a dynamic dns system. Our project aims to extend the pen and paper tabletop experience, so there's no competition happening that would tip the results in anyone's favor. The only thing people would be able to cheat in the system is the result of a rolled die (through packet modification) but that's a lot of work, for little reward.

So, people are able to create a campaign group and anyone is able to invite their friends to it. Any person in that group is then able to host a game as a GM and then the rest of the players are able to join into the game. The networking portion is going to be via p2p using the UE4's built-in network replication. When someone hosts the game, the group is updated with that player's external IP (they are responsible for their own port forwarding as we don't have NAT punch through yet) and when the session ends, the group data is modified once more to remove it. When others join, they use that group data's IP for a connection. This happens behind the scenes, they don't need to manually enter anything.

0 Likes 0 ·
brendan avatar image brendan alexmerza commented ·

So obviously, something that's actually similar to a DNS - being able to look up information which is being supplied by all players - isn't something we can support in Shared Group Data, since it would require all players being able to both read and write the same data space. If you're using Shared Group Data to store info on the session, you'll have a relatively small number of players per session - something like a dozen. What I would recommend is that you store the IDs for Shared Groups the player is in (and whether they're the GM or a player) in a Key/Value pair in player data.

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.