Time Locked Items
Hi!
I'm developing a game where there are locked items given to the players that will automatically open after a certain period of time, similar to locked chests in the popular Supercell title Clash Royale.
I guess I have to create one catalog item for the chest given to the player, and write a variable in the custom data of the item instance to store the timestamp when the chest should open.
Is this a good approach? I couldn't find any good practice regarding this topic...
Another approach could be to create a "locked container" item and grant the player the key for that container when the time expires, but I think it's a bit more complicated.
Thank you!
Best Answer
Well, you definitely need to make the container a locked item (require a key), since otherwise a hacked client could open it whenever it wanted to by calling UnlockContainer. For when to allow the item to be opened, I would go with your plan of adding a timestamp to the chest. When the client detects that the time has passed, call a Cloud Script to which you pass the inventory item instance ID, have the script double-check the timestamp, add the key, and unlock the chest (using the instance ID version of the unlock call).
What if we want the server to detect when a given locked item timestamp is past due?
Is it possible to implement a "Scheduled Task" which periodically iterates over all players' timebound/locked items and then sends a push notification to those that are past due?
The problem with making the client authoritative about the lock countdown check is that the player would only be informed when the game is on.
If ever it is possible to make use of push notifications for that purpose, is it possible to then cancel a push notification that has been previously delayed or even change its timestamp?
What I'd suggest is that you have a Segment for users who haven't signed in within the last 24 hours (or possibly more - depends upon how aggressive you want to be), but make it a one hour block. So, haven't signed in for more than 24 hours, but less than 25. Then, have a scheduled task that iterates through that set of people every hour and sends a Push to them. You could use info about their inventory status to choose which Push you go with - "you have a container available", or simply "we miss you", etc. The >24 <25 logic ensures that the Push messages will target when the player last played (so, hopefully when they normally play), and will keep the Segment from growing too large (since it would take too long to process, then).
Thank you very much for the answer.
I'm thinking about using a regular item rather than a locked container, which will solve the problem of the client calling UnlockContainer as you mentioned before. Besides, the content of the chest is calculated by an algorithm and it's not fixed, so I don't think it's a good approach to make one container for each combination of possible results, or even to use drop tables.
I don't know if I'm right, but the approach would be very similar than with the locked container, storing the timestamp and code of the result of the chest in the custom data and then checking it in the client, calling CloudScript, make some counter-cheat checks and process the results.
Thanks!
Sounds like a good plan. And yes, you are correct - if your containers drop items which can't be represented with weighted values, you'll need to have distinct logic to manage that.
