Sign In Register

How can we help you today?

Start a new topic
Answered

privateData vs scriptData

In the Hearthstone tutorial we put a deck into the privateData instead of the scriptData and it says: 


"The deck will also be saved in privateData instead of scriptData because once the player’s deck gets bigger and if later you give your players a chance to make more decks the player’s details will get clogged, so we’ll leave the deck in privateData and retrieve it when we want to using an event."


Elsewhere in the documentation is says:


"scriptData values are stored against the player, and are available via API calls that return details about a player. 

The script data can be used to store information against a player that you want to show on a device....PrivateData values are only ever available through cloud code, they will never be transmitted to a device."


I have been advised that I should put small frequently accessed data into the player collection and large infrequently accessed data in a Runtime collection.


My question:


How do I decide what data should be stored in privateData vs scriptData?

For example, when I think about the 'Consumables' that the player will have in my game, I can come up with....


Extra lives, Boosts, Hard currency, Soft currency, Subscriptions, Collectable items such as Boosts and Avatars etc..


Do I begin by thinking, "OK, the hard currency and soft currency will go into the already created Currency1 and Currency2 documents in the Player collection. And then since the Boosts will be accessed frequently by the player, I will put those in the Player collection in scriptData and maybe Subscriptions into the privateData as well as any data that will not be downloaded to the device... and then for Avatars I will create a Runtime collection that will interface with the "goods" document and put active avatars in there."

For example..

“scriptData” : {“extraLives”: 3, “boosts”: [ {“earthBoost”: 3}, {“waterBoost”: 2},{“fireBoost: 1”] } },

“privateData” : {“Subscription”: "something in here" },

"goods": {"avatars" :{"lvl1_avis": ["beast1", "beast2"] }, "lvl2_avis": ["beast6", "beast7"] } }


I want to make good decisions about where my data is placed and not just put things willy-nilly into scriptData or privateData or its own Runtime collection. How do I make these decisions? Could you recommend a step by step process to this thinking?



Best Answer

For many of these, you could simply create virtual goods in the dashboard, and use GameSparks' system, rather than store them in a custom way (unless if you have a complicated levelling up system on them, I guess). GameSparks has a lot of ways it handles data for specific things, but you might still want to make a decision for custom data you store.


Don't get stuck too much on the "small and frequently accessed" thing. That's how I find it easy to think about this, but we also had a game with hundreds of thousands of players where we ignored that completely and didn't run into any problems.

To be honest, it's simpler to store something in the player collection (script data or privateData), so unless if it's a large-ish piece of data (like the progress of the player in each one of two hundred levels), we simply store them in the player collection.


Also note that something you store in scriptData or playerData is updated in whole, but you can do partial updates in your runtime collection ( https://docs.gamesparks.net/howtos/cloud-data/partial-updates ).


scriptData vs. privateData difference is purely based on whether you want that data to be downloaded with the players' details or not. The data in scriptData is included in the response when you request data for the player's friends, and in other places where you get the player details as well. For privateData, you can still access them in cloud code and return them to the client with your custom conventions.


For player collection / runtime collection, you might want to consider what queries you may want to run. For instance, if it's important to you to get a list or count of players who have "beast7" but no extraLives, then you should probably store those pieces of data in the same collection.




Answer

For many of these, you could simply create virtual goods in the dashboard, and use GameSparks' system, rather than store them in a custom way (unless if you have a complicated levelling up system on them, I guess). GameSparks has a lot of ways it handles data for specific things, but you might still want to make a decision for custom data you store.


Don't get stuck too much on the "small and frequently accessed" thing. That's how I find it easy to think about this, but we also had a game with hundreds of thousands of players where we ignored that completely and didn't run into any problems.

To be honest, it's simpler to store something in the player collection (script data or privateData), so unless if it's a large-ish piece of data (like the progress of the player in each one of two hundred levels), we simply store them in the player collection.


Also note that something you store in scriptData or playerData is updated in whole, but you can do partial updates in your runtime collection ( https://docs.gamesparks.net/howtos/cloud-data/partial-updates ).


scriptData vs. privateData difference is purely based on whether you want that data to be downloaded with the players' details or not. The data in scriptData is included in the response when you request data for the player's friends, and in other places where you get the player details as well. For privateData, you can still access them in cloud code and return them to the client with your custom conventions.


For player collection / runtime collection, you might want to consider what queries you may want to run. For instance, if it's important to you to get a list or count of players who have "beast7" but no extraLives, then you should probably store those pieces of data in the same collection.



Baris, this kind of information is so valuable to me, thank you so much for sharing your knowledge!

Login to post a comment