In Nakama you could do a simple group active-inactive metadata via storage. But how do you handle a way to make a certain player demoted if they’re not playing for a certain amount of time?
Let’s say a person that is just promoted to admin went offline for 7 days, after 7 days that person would get demoted into a member. How do I schedule this? Who would need to kick off the events?
A cron job every day that would run through all the storage and then update it’s metadata activity time would do the trick. But using cron (in this case gocron) on nakama instance would make it run more than once if there are more than one machines, but I guess that’s fine since updating the storage in this way is idempotent?
Is there any other better alternatives?
@cloudAle I think we have since discussed this post separately to the forum thread but I do think its a good question to cover in the community.
Let’s say a person that is just promoted to admin went offline for 7 days, after 7 days that person would get demoted into a member. How do I schedule this? Who would need to kick off the events?
A group must always have at least one superadmin. This prevents the group from becoming abandoned without a way to promote another user to the superadmin first. It does not of course prevent player churn out where the user stops playing the game but does not leave the group. This is a common problem with group/guild based games. Usually you’d incentive the users via the game design to minimize this likelihood.
In your particular case if the current superadmin should be demoted how would you decide which other user should be “auto-promoted” to be superadmin?
But using cron (in this case gocron) on nakama instance would make it run more than once if there are more than one machines, but I guess that’s fine since updating the storage in this way is idempotent?
Is there any other better alternatives?
The usual approach with Nakama is to write the background logic as a server to server RPC function and execute it via a separate scheduler process that can call the RPC function as a HTTP request. In the Heroic Cloud we do this with our own scheduler which will run the desired logic for the game team against the server.
As you’ve noted I would not recommend trying to write code that is scheduled within the game server because it will execute once per server rather than once across servers. You could handle this case by making sure that the execution logic in your RPC is idempotent but that can be difficult depending on the game design.
In your particular case if the current superadmin should be demoted how would you decide which other user should be “auto-promoted” to be superadmin?
We’ll look into another co-admin who also not reaching threshold of last active play that we define. If we don’t find any, then we don’t demote (also would not demote superadmin if he’s the player left on the groups)
As you’ve noted I would not recommend trying to write code that is scheduled within the game server because it will execute once per server rather than once across servers. You could handle this case by making sure that the execution logic in your RPC is idempotent but that can be difficult depending on the game design.
As we discussed we decided to use the job that heroic team provided to call our clean up rpc