SharedGroupData Limits and usage,Hi!

Question

question

vince asked Aug 22, '16

SharedGroupData Limits and usage,Hi!

Hi,

We're working on a game that involves trading and have been using SharedGroupData to stock some information. It seems we've hit some kind of unknown limit, because some trades are now just not showing up at all.

Here's how we use the SharedGroupData: Users have a collection of objects that they can trade. Each object has a unique id, and right now we have about 100 unique objects in our game. Players can trade objects in a one-for-one exchange; they put the object they want on a wishlist, and offer another object for trade.

Eventually, each object can have a SharedGroupData, that is created only when someone wants to trade that object, and that is the "Market" for that object. When a users offers an object for trade, we first look at his wishlist to see if there's a trade already available for that trade/wish combination. If not, we stock the trade/wish information in the market.

It's been working fine for awhile, but recently as more trades have been happening in our beta test, it has sometimes been impossible to create new SharedGroupData. We put an object for trade, and the SharedGroupData never receives the information. But it seems to work on other objects, which is why we think we might have hit some limits. Can you tell us what we can do in our situation?

Thank you!

,

Shared Group Data

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 · 2016-08-22T19:42:17Z

brendan answered Aug 22, '16

Yes, we limit titles to 10 Shared Group Data objects per player currently, and 100 Key/Value pairs per Shared Group Data (https://community.playfab.com/questions/722/208954138-SharedGroups-Limits.html).

Also though, I'd like to confirm your usage model, to make sure it's not causing you problems. Shared Group Data was specifically designed for scenarios where you want to share data among a small number of users - less than 100. Too many people trying to access the same data at the same time can create delays and even timeouts, which we'd prefer to avoid. Also, how are you "stock"ing the information on trades in your market? Could you please review the response on this thread, as well (https://community.playfab.com/questions/3843/use-shared-group-data-for-a-live-event-system.html)? Again, I simply want to make sure you have all the information needed to effectively design your data model, so that you can enable the features you need.

Also, a question: What's the reasoning for not using the existing trading functionality (https://api.playfab.com/Documentation/Client#Trading) to set up the trades? I do understand the need to share those trades in some way with other players - we'll be providing the means to do that in an upcoming update - but as a base, that functionality manages the escrow of items, so that you don't wind up with item duplication exploits or failed trades that cause items to be "lost".

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 2 · 2016-08-22T21:47:05Z

vince answered Aug 22, '16

Thanks Brendan.

What does "10 Shared Group Data objects per player" means exactly? Does it mean each specific user has access to 10 SharedGroupData? Or that each PlayFabID in our game gives us another 10 SharedGroupData available?

For how we stock the data, each SharedGroupData is a Market about a specific object. In this SharedGroup we stock the PlayFabID of the user and whether it is an Offer or Wish. When a player makes a new Offer, we check in his Wishes list to see if another user has a corresponding wish for the offer he is making. This is all invisible to the user, they will never know what is happening in the market (the wish/offer list), and will be only notified when a trade is successful.

What we want to accomplish is:

1- Check to see if there is an available Offer/Wish pair that can be traded right away when the user makes a new offer

2- If there is no current Offer/Wish compatible, stock the information so that another user can later trade with the previous because he has a compatible Offer/Wish

Example: User1 wants to trade his Object1 for an Object2, but no user wants to trade their Object2, so his wish is stocked in Market1 as User1->Offer and in Market2 as User1->Wish. Later, User2 wants to trade his Object2 for an Object1. First we check to see if there's an offer in Market1, and there is with User1. Then we check in Market2 if there is a Wish with the same User1. If there is a trade compatible, we make the trade.

We are actually using the trading functionality when the offer/wish pair has been found, but we could not find a simple way to "stock" the offer/wish list in the long term if there are no current trades available, which is why we used the SharedGroupData. We're open to suggestions about how we could improve on this.

Thank you!

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 3 · 2016-08-22T22:59:24Z

brendan answered Aug 22, '16

I see. So in your design, you're trying to put every user who is offering a trade for a certain ItemId into a single Shared Group Data? That's definitely not going to work. As I said, Shared Group Data is for small sets of players - not your entire player base. Aside from the fact that you would be limited to only 100 players offering a given ItemId, you're going to run into problems with both access (too many people trying to access the same Shared Group Data at the same time), as well as collisions (multiple people claiming the same trade at the same time).

We are planning on providing a way to query for open trades (in our existing trade system) in a future update, though I'm afraid I don't have a date for that right now. Your best bet if you want to implement this right now would be to use an external data table to store the information you need on available trades. There are a few database options which are accessible via Web API calls (Azure table storage, AWS DynamoDB, MongoDB via mLabs), so any of those would be usable via Cloud Script.

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.

question