question

Karl Loveridge avatar image
Karl Loveridge asked

What glues catalog content to inventory?

I've now used Playfab for about a day, and the relationship between catalog items and the players inventory is a little murky.

In the tutorial video's I watched, they demonstrated how the player purchases content and immediately the players inventory reflected the purchase. They went through all those fancy tags and attributes. And it almost appeared that these attributes provided all the information for Playfab to drive the inventory automatically.

But this doesn't add up to me. It seems like my game code should be the "glue" of how to interpret a purchase and communicate this to the inventory. Could someone help clear this up for me?

Thanks in advance.

10 |1200

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

brendan avatar image
brendan answered

So, the way our payment provider integrations are designed to work, you specify items in the game catalog, and we coordinate with the purchase providers to confirm the payment and the item(s) purchased. That way, we control only putting items into the player inventory that were actually paid for. Allowing the client to be authoritative about this would mean that a hacked client could get any number of items for free, which I'm sure you don't want to have happen.

Now, it's also possible to just use our Grant... API calls to give things to player via server authoritative logic as well, but I don't believe that's what we're discussing, since you're specifically asking about purchases. But that said, if the above info doesn't make sense, can you let us know what your expectations are?

10 |1200

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

Karl Loveridge avatar image
Karl Loveridge answered

Ok. I just need to understand how to use this correctly. In my game there are three types of currencies:

Real money, Gold and Diamonds.

The main item players purchase with real money is diamonds (ie, a 50 diamond pack for $.99. or a 200 pack for $1.99). There also will be durables that can only purchased with real money which are yet to be implemented.

These transactions would be done very rarely (Unless my game is amazing addictive--which I hope it will be;)). So it makes sense to put these through the Playfab's catalog system.

But in my game the life cycle works like this: You have a inventory. You go play the game. You earn Gold. You deplete your inventory. After a game, you go to a store on a map. With the gold your earn, you purchase supplies to replenish your inventory.

If a player played for an hour, they would likely do about 20 or more micro-transactions using gold. From what I saw on the server side, these transactions would "pile up" on the server.

Two concerns: One, it seems risky and excessive to call Playfab every time the player hits the "buy" button when replenishing supplies. Risky because, what if the internet goes down or the communication is disrupted. Excessive, because I don't know how much storage the transaction costs on the server. But even if its tiny, isn't there a limit to how much data can be stored per player? How does Playfab "house clean" out old consumable transactions?

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.

Karl Loveridge avatar image Karl Loveridge commented ·

hmm. I posted a reply in the forum to this question and it disappeared after I said "Post Answer". Can't tell if its hidden until its reviewed or I missed some step on the reply button.

0 Likes 0 ·
brendan avatar image brendan Karl Loveridge commented ·

In order to deter spammers (which we've had problems with in the past), we use a reputation-based system. So posts from new users get sent to a moderation queue until they have earned some reputation in the system. That prevents a spammer from creating an account and posting all over our forums, then creating a new account when we ban that one.

0 Likes 0 ·
brendan avatar image brendan commented ·

Yes, that's a very common pattern for free-to-play games - a hard currency sold for real-world cash, and a soft currency that is earned through gameplay (which has a higher exchange rate, and which is more limited in the items it can purchase). In our service, the way this would work is that you would use receipt validation or the StartPurchase flow for real-money purchases of hard currency, and then PurchaseItem for purchases of catalog goods using virtual currencies. In all cases, the exchange occurs immediately and as a single operation. So, in the case of a lost connection, either the player fails to make the call to the service, or fails to get the response. In either case, you'll get an error from your HTTP library to let you know about this. For connection loss scenarios, it's a good idea to do an exponential backoff on retires, so that you're not burning through the player's battery on mobiles. Once you're able to talk to the service again, just check the player's inventory to see if the purchase was successful.

And you don't need to worry about storage for details of purchase operations - that's simply part of the core service.

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.