In our legacy system we give daily bonuses to players as a background task, that pushes the bonus into their inbox and optionally sends a push notification. During the port to Nakama I’ve created an S2S script to do the same that is externally called by a cron job.
I wonder if scheduled scripts would be better as an internal feature of Nakama.
The bonuses are designed to arrive during a two hour window in the afternoon/early evening based on the player’s location (timezone would also work).
The alternative is to use a third party (OneSignal?) to schedule push notifications. I don’t think this is the right approach for us, for the following reasons.
We can’t rely solely on push as many of our players play in the web browser on desktop, and others have push disabled.
I dislike having the push notifications scheduled externally and the bonus given on login as they can (and will) arrive at different times and cause confusion.
Also we are are currently using Firebase Cloud Messaging which suits our needs but doesn’t support localised scheduling (I don’t know if OneSignal do either).
We are hosting Nakama ourselves, so performance issues are very much our own problem and the script is carefully designed to minimise impact.
@DaveOak This is a great question. Sorry for the slow reply.
The bonuses are designed to arrive during a two hour window in the afternoon/early evening based on the player’s location (timezone would also work).
[…]
We can’t rely solely on push as many of our players play in the web browser on desktop, and others have push disabled.
I’m not sure I understand the inherent link between the prompt to let the player know to collect their daily reward and the grant of the reward itself.
Usually how we handle this in games we’ve worked on and how we know other game teams that use Nakama do is to have the daily reward execute when the app starts as part of the execution of some RPC function or after hook on the player’s GetAccount call.
This has two benefits:
It limits the amount of CPU / IO utilized to grant the daily reward to the player base.
If you were to execute this as a background job you’d have to process all user accounts and determine whether to skip those that have an outstanding reward to collect. This work is done for a portion of the player base that has already churned out of the game.
You can schedule a local notification or similar to act as the next prompt time for the player which actually eliminates the need for you to schedule a push notification with a remote service. This is a great solution at least for mobile.
Also we are are currently using Firebase Cloud Messaging which suits our needs but doesn’t support localised scheduling (I don’t know if OneSignal do either).
I’m not sure if One Signal supports localized push notifications either but it would give the flexibility to process the event at 7AM local time for the player (or noon or whatever time of day you want to prompt the player).
Sounds to me like your use case needs two fields stored in the use metadata "last_claim_time_unix" and "claim_time_interval_sec". Together you can use these fields to determine whether the daily reward has just occurred for the player and work out how many seconds until the next reward grant (if you decide that some rewards are not daily but after X number of hours).
Hope this helps. Let me know if I’ve missed some other criteria you need for your use case.
Thanks for the very detailed reply Chris. That makes perfect sense, but does rely on the ability to synchronise the delivery of the bonus with the push notification. I will investigate further with FCM as it seems an obvious requirement to schedule using local time.
@DaveOak I’m still not sure why you need to synchronize the push notification and the daily reward refreshed because the user will need to open the game to claim it after they’ve seen the push notification so its something that can be deferred until that point.
If they get the push notification, but the bonus isn’t available yet then they will be confused. Likewise if they received the bonus some time (hours) ago.
I’m talking in terms of getting the right timezone, not realtime precision
@DaveOak I understand that. They receive the push notification, open the game, the game fetches the player profile or similar (which shows there’s a daily bonus), and when the game renders the player can claim their reward. You can see the logic behind a daily reward system in these code examples:
Because the request is done on demand when the game starts up you will NOT leave the player in a position where they open the app but don’t yet see the daily reward to claim.
Thanks for the examples but I’m sorry, I don’t see how this solves the problem completely. The example (if I read it right) provides a bonus if you open the game after (local) midnight since the preceding bonus was claimed. Other than the time of day, this is a great fit for us, we give the bonus at 18:00 local time which is a simple change.
My problem is in scheduling the push notification to be at 18:00 local time, which is an issue with FCM. I think Firebase can do this but I haven’t dug deep enough yet. I’ll come back to it.
@DaveOak I believe what @novabyte is suggesting is not using push, but instead scheduling local notifications on the device. Since the proposed server functionality does not rely on the notification, it just becomes an informational feature on the client rather than driving game logic. Accounting for device local time also becomes trivial.
