Basically, i need after a certain time, to reset all items and upload a new catalog. This happens when a player find an answer according to the clues he bought with his virtual currency. When that s done, i need to reset the catalogs' items for a new contest.
I set up the clues under items.
The best thing to do for your different areas would be to have all items in a single Catalog, while you separate our the items for each area using Stores. That's the way the system was initially designed, so it'll be the easiest model to use - particularly if you have in-app purchases and you're on mobile.
As far as revoking all items from all users, there is no single operation which could do this. I can think of a few options:
1. We are about to release bulk actions for user segments, so it's possible you could write a script to revoke items from the user inventory (or modify their uses remaining, if they're consumable). However, this would be dependent upon the user having very few items overall, since there is no API for "remove all item from this user". Also, it's important to note that bulk actions are performed across the user base over time. It's not possible to update potentially millions of rows simultaneously.
2. So, I'd strongly consider an architecture that allows you to store the information about the user's inventory as data. You could still take advantage of the catalog and purchasing systems, but you would need to make all your items consumables, and whenever someone buys something, add it to their stored data (User Read Only Data) and consume the item from inventory. You would store the data in as few keys as possible (using JSON), with the data being tagged for the contest version. The currently active contest version would then be in Title Data, so that when the player loads the game, you check the Title Data first, then get their User Data and delete it if it's outdated. That would limit what you could do with the items, since they wouldn't be true item instances anymore, but it would give you a way to instantly update all users to the new contest version (you'd also want to have checks on the data in Cloud Script, where you evaluate their completion status, so that you can prevent people from trying to cheat by changing their clock).
So, according to your 2 options, i am going to do the second one. I already set the catalog with 6 stores holding 30 items each. I get the way you explained for the items management by the purchase/consume/store data.
Here is the step where i have a hard time to understand:
"You would store the data in as few keys as possible (using JSON), with the data being tagged for the contest version.The currently active contest version would then be in Title Data, so that when the player loads the game, you check the Title Data first, then get their User Data and delete it if it's outdated.".
I see all the API calls that i have to make but i do not get how to tag and how to check the version in the Title Data.
I still did not dive in the Cloud Script yet but i am reaching it.
Ok it s more clear for me now. I also have another question concerning the catalog. If i have 6 different areas for 6 different contests but all accessible in the same app, is it possible to upload only one store without having to upload the whole entire catalog? My point is that wouldn t it change the catalog version for all 6 stores? If yes then i will have a problem since the contests are not linked and at anytime one can be done and restart while the others keep going.
What I was saying above is that if you're completely updating the catalog items - not just the specifics of pricing - you'll be creating a distinct CatalogVersion for each revision, moving to the new CatalogVersion via the Title Data checks. Within each catalog, you can update each store independent of any other store via the Game Manager or the API calls (such as https://api.playfab.com/Documentation/Admin/method/SetStoreItems).
What I mean is that you'll use Title Data as your version control for the catalog. So, upload CatalogVersion "1" and set a Title Data Key to indicate that "1" is the current catalog the title is using, so that you can check that from the client and any Cloud Script calls. Then, when you want to switch to the new catalog, upload it as CatalogVersion "2", set the Title Data to "2", and then you can get rid of CatalogVersion "1". On the client, keep track of the catalog version last used (which should be in the data you saved). When it changes, you'll know to wipe the data on the items and start fresh (with appropriate checks in a Cloud Script that's called when the user wants to purchase new items, or use old ones).
2 People are following this question.
