question

Richard McKinney avatar image
Richard McKinney asked

WriteEvents, limits and offline play

Our game allows offline play. When you come back online, I send batches of events with WriteEvents to send all of the events you would have sent while you were offline. For any reasonable volume, this is sure to hit the EntityEventsPer15Seconds limit, and often also hits EntityEventsPer5Minutes. I'm seeing this constantly in our Playstream.

I've got some backoff to handle the throttling, with more coming next patch, but I'd rather there be a better way to handle this than hammering through the events every so often. Let's say a player just played 50 levels offline and now gets an internet connection. There would be, at minimum, 50 level start and level end events, along with whatever other events you have inbetween. Is there any good way to get those sent through without hitting those limits and not being able to get them through without multiple 5 minute throttles and likely take multiple sessions to catch up?

I know when I have a big bundle to send. I could make new events that are aggregates, but that's a messy thing to have to handle in every query. Are there any other recommendations for wanting to get these big event bundles off the client as fast as possible?

Thanks!

limitsanalytics
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

It really depends upon what you need those events for, ultimately. If you only need them for analytics and they don't have to be processed in PlayStream (to trigger rules, etc.), your best bet is to just make them telemetry events and send them up as fast as you like.

If they have to be PlayStream events, you will need to do some form of throttling in order to avoid hitting the limits.

Presumably you're aggregating the delta for anything else though, yes? So you only update any given data key or statistic once when the player comes back?

10 |1200

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

Seth Du avatar image
Seth Du answered

Offline play is not the classical scenario that PlayFab is designed for. If the client has cached plenty of data offline, the thing you need to do is to reduce the quantity of data that is required to sync with PlayFab when it comes online. Offline play cannot guarantee the security of the data, you will get cheating anyway.

My suggestion here is only caching the current level the player is playing and preventing players from entering the next level. Notify the player that current level data will be saved and synced after the client comes online, then return to the login page.

If your game doesn’t care about cheating or fairness between players. You may only send the latest level or any other information (VC changes, items changes) to PlayFab after the client comes online.

Here is some threads you may refer to:

https://community.playfab.com/questions/16224/how-would-i-handle-a-virtual-currency-online-and-o.html

https://community.playfab.com/questions/10328/offline-progression-buff.html

10 |1200

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

Richard McKinney avatar image
Richard McKinney answered

Ah, great, so telemetry events won't hit the same limits then? I'll burst through telemetry and self-throttle the ones I want going through playstream then. That should be a good start.

Thanks SethDu, yeah, I'm trying to handle all of the cases in a client wrapper to enable offline support for non-critical systems. Profile updates shouldn't be a problem for us, since those will be aggregated, and I think moving more things to telemetry events will give us the breathing room we need.

10 |1200

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

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.