Player versus the World game including bulk push notifications

Question

question

Koen asked Apr 20, '17

Player versus the World game including bulk push notifications

Dear PlayFab,

We have some questions regarding a game we (probably) want to develop with PlayFab. It's a Player versus the World game where there's an event every day with winners and losers (obviously). At the end of the event all players must receive a push notification with their status (win/lose). Note: costs are not a problem, we just need to know what we can expect with large amount of players.

We probably want to use the Player Statistics to determine winner and losers (and for leaderboards of course). I have several questions and I'll give them an identifier for convenience.

1: We want to use the Title Data to store information about upcoming events (which the app will use to schedule local notifications). This data should also contain whether the event is active. This data will be updated by an admin manually after each event. How much time does it take to guarantee that every player/server has access to the latest Title Data data?

Let's say we use CloudScript to submit our score, it receives an event ID and the player's score. It should retrieve the Title Data to check if the event is still active, if so update the player's Statistic. Is it possible that the CloudScript receives outdated data and therefore writes unwanted data? If so, what's the overlap time? Seconds, minutes, hours, days?

2. We want to use Player Statistics for the data of the events, how long is a leaderboard archive available in the GameManager? Or when are archives reset?

3. After an event all users must receive a push notification. A (Scheduled) Task seems appropriate for this, except that the (Free) limit states it has a processing rate of 10 players per second. This is too slow for our purposes. Is it possible to speed up this processes and how much does it cost for certain amounts of players (1K, 10K, 100K, 500K, 1M, 2M etc?)

4. We will need Segments to place players in a Winner orLoser Segment in order to send send push notifications (and up their all-time statistics). When are Segments updated? What are the moments when the Segment rules are checked against a player/all players?

For example; if we update a Segment in the GameManager and hit Save, are all players checked for this new/updated Segment immediately, if so, how much times does this take to take effect for lots of players (100K, 500K, 1M etc)? Or is a Segment checked when a player updates their statistic? Are Limits involved here and if so, how much will this costs (approximately)?

5. How can we localize push notifications when sent via the GameManager?

We hope this is not too much for a question post and we hope to hear from you soon.

Push Notifications Leaderboards and Statistics scheduled tasks

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 · 2017-04-20T23:47:19Z

brendan answered Apr 20, '17

Well, ideally these would be separate posts, so that folks searching on any one of these topics later would be able to find them more easily, but I'll go ahead and address each here:

1. Yes, games in our service use Title Data to store info on events - that way you can give players notice of upcoming events, control when they start/stop, and have the info on what the changes are for the event. Since Title Data serves all players simultaneously it is, of course, sharded and cached. In general, the update time from when you edit a Title Data key/value pair to when all endpoints are updated is along the lines of a few seconds, at most. If you want to server very large data to all players though, I would recommend using the Content service, as it is a CDN and will reduce access time for players (as it's globally distributed). If you were to do that, you would maintain a master "lookup" of the current data version in Title Data, and use that to inform the client of what data to access from Content (always version data in CDNs - otherwise, you have to wait on the TTL for the data to update).

2. We haven't defined a retention period for the S3-stored leaderboard archives as of yet, but if you need them for more than 30 days, we should probably discuss your use case and potentially make sure that any usage period you want to make sure is valid long-term is part of your contract.

3. The rate at which we can process players is tied to the amount of compute resource applied to this. For the free tier, that's necessarily pretty low (it still costs us a non-zero amount). We're actually about to update our pricing page and provide a detailed overview of where we've landed (we got a lot of good feedback from the update we posted after GDC). For a title that's going to have millions of MAU, we should definitely have a direct conversation so that we can work out the best price for you overall (taking all the features you need into account), rather than pricing each thing individually (which would likely end up with a higher total, since it would be a piecemeal comparison).

4. The segments for a player are updated whenever there's a PlayStream event for that player which is part of any segment filter. There's also a re-evaluation which occurs when running a Task, to ensure that the segment is up-to-date for non-events (like 'hasn't played in N days'). And yes, when you change a segment definition, it is re-evaluated. The time for that re-evaluation is going to vary, depending on the total number of players. And yes, under a custom agreement, we can certainly provide more "processing units" for a title.

5. We'll be providing more localization tools integrated with PlayFab in a future update. For now, since the text of the Push is defined in the PlayStream Action, you would want to have separate segments for each localization.

6

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.

Koen commented · Apr 21, 2017 at 06:28 AM

Thanks for the detailed answers.

1. Good to hear it's seconds at most, that's just what we need since we don't want large amount of data.

2. 30 days is way more than we need, we just need to make sure it doesn't disappear after a few days for example. How does the limit 'Leaderboard version history retention length' work? We have another game that has multiple leaderboards with some of them 1 or 2 archives that are available for download, but the Limits page's usage in the past 24 hours doesn't show any data. Is this limit tied differently to the leaderboards?

3. Any ETA on the pricing page update? We'll discuss this internally, if we want to contact you directly what is the best course of action?

4. Re-evaluation time depends on the total number of players, you have any approximation for like 100K vs 500K vs 1M players (only up one statistic and send a push notification)? Matter of minutes would be fine, we just need to make sure 1M players doesn't take hours to complete.

5. Is it by any chance already possible to use 'keys' in the push notification and add localization files built into the app that are used to localize? If not, then we'll stick to English for the time being.

0 ·

brendan Koen commented · Apr 21, 2017 at 08:29 AM

For leaderboards, the limit is for revision iterations, not retention period. So the default free limit is one revision back from the current leaderboard revision. AGain, we'll be posting the new pricing soon, and we'll have more details on everything. If what you actually meant was how many revisions back you can get, that's something we can work on a custom contract for you to specify.

We're working on the finalized pricing update actively, and hope to have it available as soon as possible. Sorry that it's taking as long as it is, but we're trying hard to make sure we're striking the balance between simple and equitable.

For 4, re-evaluation of segment without any segment enter actions is faster, so that conflates the concepts somewhat. But yes, re-evaluation of 1M players would not take more than a few minutes.

For 5 (localization), we have defined some profile and event based keys that we'll be rolling out as part of our tournaments solution (the one we demonstrated at GDC, if you got the chance to see it), but that wouldn't allow you to swap out 100% of the text of a Push Notification, so I'd suggest using multiple segments for now, if you want to have localization.

0 ·

Koen brendan commented · Apr 21, 2017 at 09:45 AM

For 4, segment re-evaluation: re-evaluation for 1M players would not take more than a few minutes (let's say 5 for convenience). Is that without enter actions or with the 2 stated before (up statistic and send push notification)? Can we say that it takes 5min per 1M players (so 10min for 2M, 15min for 3M etc)?

When updating a segment in the GameManager you can see a spinning loader icon before showing the number of matched players. Is that the time it takes to complete the re-evaluation including the enter and left actions?

0 ·

Show more comments

Koen commented · Apr 24, 2017 at 08:51 AM

@Brendan I can't seem to reply on your last comment so I'll reply here.

If I understand correctly, if we change a segment definition the re-evaluation process is really fast but no enter/exit events are fired at that time: "If you change a segment definition, you'll get the set of players who are already in that segment."

Does this mean that it's possible to change a segment definition (with completely different conditions) and that - at that time - the segment will contain players that shouldn't be in there? So if we run a scheduled task on the updated segment, the wrong players will receive the task actions?

Or is it that only players that are still in the segment are in there and others are removed (since the conditions weren't met anymore), but those that were removed don't receive the exit event?

0 ·

brendan Koen commented · Apr 24, 2017 at 04:05 PM

When you change a segment definition, that evaluation occurs immediately and yes, it's very fast. Also, when you run a scheduled task, there's a check that the segment is up-to-date, so the player segments will be correct when the task runs.

If you change the definition of a segment, that can change the set of players in the segment, but it does not run an exit action on any player. As stated above, segment enter/exit actions specifically occur as the result of a player event. In the case of changing a segment so that a player no longer belongs to it though, it especially makes no sense to fire an exit action, as the player wasn't a member of the new segment definition at all.

0 ·

question