question

Jeremy Fish avatar image
Jeremy Fish asked

Tipping System grouping by object

Hi there,

We use PlayFab for player management of our game, which includes both a game client and a web portal where most users will be. Users can engage with game content, and we'd like to build in a tipping system and are wondering if PlayFab is a viable option for managing this. Looking through the forums and documentation, I'm not sure how we could implement, but I'm keen to find a way - hopefully with some help :)

Here's the general premise:

1. "GameSessions" are created (there may be hundreds a day), and while playing a game session other users can watch & engage.

2. Users can purchase virtual currency with real currency outside of a GameSession, and it's stored on their account.

3. Users can tip VC towards a GameSession, and so we need to store that GameSession_ID with each transaction / tip that is made.
4. At the end of a GameSession, we loop through all purchases with that GameSession_ID and note that total on the GameSession (GameSessions objects are handled outside of PlayFab).

The real goal is to have many purchases associated with an object, and then many of those objects with unique IDs (possibly enough to go over the item cap in a single day, if each object was it's own item). Having a reliable ledger of all those individual transactions (PlayFab) and being able to tie it back to a GameSession is also critical.

I was thinking of having a single "tip" item, and then storing the GameSession_ID in the ItemInstance CustomData - however, that raises a few questions:

1. Having variable tip amounts, rather than a fixed item price - I could solve this by having a "tip" item be just 1 VC, then you purchase multiple of them to add up to the custom tip total. Or would each ItemInstance happen for each QTY that a user purchased, so a 100 VC tip would result in 100 line-items...?

2. Once a GameSession is over, we can document the tip total then close out the GameSession - so we could clear out resources if necessary, i.e. if we instead had to have a unique item for each GameSession, maybe we could create the item with the GameSesion_ID tagged on it, total the purchases, store that data on the GameSession, then delete the item? We still face the 3K item limit though in an extreme case of having 3K simultaneous GameSessions...

3. How would we / can we loop through all transactions of the "tip" item to get the GameSession from the custom data? Maybe over a certain timeframe of when the transactions occurred? This would be required to document the total amount associated with a GameSession.

4. We need to be able to process hundreds of tips on hundreds of unique GameSessions daily, so I'm not sure IF we can loop through all those transactions IF this would prove difficult.

I'm open to any creative ideas that you may have, and appreciate any help!

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.

Rick Chen avatar image Rick Chen ♦ commented ·

There are limits to the amount of items a player can possess. You mentioned that you would have a unique item for each GameSession, can this unique item be deleted after? is the unique item only used for calculating the total purchase?

0 Likes 0 ·
Jeremy Fish avatar image Jeremy Fish commented ·

Hi Rick, thanks for your response!

I have an answer awaiting moderation (maybe it will post before this comment - I'm new to this forum system, whoops), but we are considering a slightly different structure now:

1. Have one "tip" item of 1 of our virtual currency, dB, set as a consumable.

2. Bundles of the tip item can be purchased (100 - 2000dB), or a custom amount can be chosen where we'll manually add that QTY of the item and deduct the currency accordingly. Purchases are tagged with the GameSession_ID in the custom data.

3. We watch those purchase events from the PlayStream, both exporting the data in an external ledger (for bottom-line reference) and firing a webhook on each event to store the total tip count & tip value on each GameSession

4. With various checks in place; every month we pay out Players based on the totals for each GameSession they were a part of.

Do you see any way we would run into limitations that way, or any way we can use PlayFab more efficiently? Would amount of items a player could process still be an issue?

0 Likes 0 ·

1 Answer

·
Jeremy Fish avatar image
Jeremy Fish answered

We're now looking at the following flow, but keen to hear if anyone has a better / more efficient idea:

  1. Purchase of virtual currency happens via Stripe or PayPal. We have to verify the purchase with the available PlayFab API.
  2. User tips on a GameSession with virtual currency (1 dB = $0.01), either a bundle (100/200/500/1000/2000dB) or a custom amount, where we add the 1dB item per however many pennies they choose to tip. We tag each purchase with custom data containing the GameSession_ID
  3. Purchase confirmations are fired in the PlayStream, triggering a webhook to the GameSession object, incrementing the tip count & the total tip amount. (Might need to check for proper incrementing / none missing or duplicated).
  4. Purchase confirmation events are saved every hour (PlayStream data export) in our own DB table, checking for redundancies.
  5. When the Game Session ends, after an hour we check all purchases for that GameSession in the PlayStream ledger and account for any difference between the GameSession object.
  6. The player who created the GameSession has their dB increased the corresponding amount.
  7. Every month, we use a mass payouts service (or build into our bank's API) to pay out all producers/artists.
  8. We keep the Purchase ledger stored in our DB for any future disputes.
7 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.

Rick Chen avatar image Rick Chen ♦ commented ·

Have you considered how the items purchased by players are dealt with? These items with individual custom data could fill up the player’s inventory and hits the limit.

The webhook solution sounds OK, however please be aware that for the webhook, we use "at least once" delivery semantics. This means that, for any given message we will retry until we get a positive confirmation from the receiver. This can create duplicates when the receiver fails to respond for some reason despite actually receiving the message. Please refer to this thread: Webhook sends data multiple times.

Please also note that the purchasing item API and the events could generate pricing meters. You could refer to this document: Pricing Meters and learn how PlayFab’s pricing works.

0 Likes 0 ·
Jeremy Fish avatar image Jeremy Fish Rick Chen ♦ commented ·

Hey @Rick Chen (or anyone else available to help)

We're in the process of implementing this and have run into a snag. We are attempting to process the playstream events from player_vc_item_purchased using an Azure Service Bus Queue, but we aren't quite sure how we can hook up the queue to an azure cloud function in PlayFab as there is very little documentation.

We have tried the following:

1. Hooking up via a webhook on the playstream event, but the URI endpoint has to be http/https rather than a queue endpoint.

2. Using a rule to fire an Azure Cloud Function on the playstream event, though we are not sure how to specifically set up a service bus queue here as it isn't an azure function queue. Maybe we can only hook up azure function queues here...?

We're keen to get some advice on how to best handle these events. We want to send directly to a service bus queue to deduplicate events, read custom data from them (id of various objects which each record their own revenue), find that ID and increment the revenue recorded. But if we can't hook up a service bus queue to playstream events, then we will need a new approach!

0 Likes 0 ·
Jeremy Fish avatar image Jeremy Fish commented ·

@Rick Chen We were thinking of having the items be consumable bundles, i.e. a 200dB tip would be a single bundle item containing 200x of the 1dB item, and both the item and the bundles would be consumable with say a 5-second timer. Do you see any potential flaws with this system? It seems to avoid the player inventory limit from my understanding, but please let me know if you think we might hit any other limits!

That all being said, I totally understand the potential to start generating pricing meters. Is there anything in this model in particular that you think could scale up unfavorably / disproportionately?

That is great info regarding the API, thank you! We'll definitely account for this with the ledger check at the end of a GameSession, and maybe we'll add in the storage of the event ID so that we can check for redundancies/duplicates on the fly.

On a final note @Rick Chen - do you see a more optimal way to set up this tipping system in PlayFab? Does it seem too clumsy to bend PlayFab to fit this model?

Thank you again for your help & insights here!

0 Likes 0 ·
Rick Chen avatar image Rick Chen ♦ Jeremy Fish commented ·

Thank you for elaborating the flow of purchasing items. I haven’t made any tipping system before, but I think the item purchasing and the webhook can work. For other parts, you could describe how you would use PlayFab feature to implement then I could give you some feedback.

You mentioned that after a game session, the player who created the game session has their dB increased by the total tip, the dB is also used for tipping. But every month you pay out Players based on the totals for each GameSession they were a part of. Have you consider a way to distinguish the dB amount to be paid such that you are not paying the users who bought their dB?

0 Likes 0 ·
Jeremy Fish avatar image Jeremy Fish Rick Chen ♦ commented ·

@Rick Chen you bring up a good point! We were thinking of creating a character on every player who is approved to stream/start a GameSession(GS) (this would be hidden from them, hopefully) and we would store any earned dB there. We would keep the two amounts separate, and probably offer those players the ability to spend the dB they purchased or earned back into our game economy, or withdraw (via our bank API/outside PlayFab) only earned dB on that hidden character.

The only part of the flow that I have left out of PlayFab is where we store the Revenue info for each GS. We are planning to have that in an Azure DB since it provides a bit more flexibility, so we would hit it with the webhook, check for redundancies, then at the conclusion of the GS consolidate against the ledger of events for that GS. We thought we could also transfer dB to the player running the GS via a trade or something, but we have cases where multiple Players might be on the GS and so we can't just do a 1:1 trade as the PlayFab API supports. If you think we could leverage something in PlayFab (we considered Group Data for a minute), I think that's the only part of the entire system that I haven't detailed here..

0 Likes 0 ·
Show more comments
Jeremy Fish avatar image Jeremy Fish commented ·

Sorry I meant great info regarding the Webhooks, not API :)

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.