Below are some notes about GS functionality that I've had difficulties to deduce. I've had to determine some of the features experimentally, so please correct me if I got something wrong.
Collections
Metacollections/metadata collections are for storing static data and can be only modified through the NoSQL view. They can be read from cloud code but cannot be written to.
Runtime collections can be read and written to from cloud code at runtime. Calling Spark.runtimeCollection("CollectionName") creates a new empty runtime collection named script.CollectionName if it doesn't exist.
System runtime collections (lacking an offical better name) are collections like player and event collections that are managed by the service, store runtime data but cannot be accessed from cloud code. This begs the question what are the event collections needed for if you can't access them?
Live, Preview and Snapshots
Live and preview run different configs including any cloud code scripts, events etc. Making changes to cloud code or creating a new event only changes preview, and you'll need to create a new snapshot and publish it from the Overview tab to apply the preview changes to live config.
Live and preview use different database data sets, so modifying collections in preview has no effect on the live collections.
When you publish a new config to live, the earlier live runtime collections are preserved.
In unity, you can choose between preview and live config using the Development build flag in GameSparks settings
Best Answer
C
Customer Support
said
over 7 years ago
This is exactly right.
Your question about System Collections:
They are visible in the NoSQL Explorer for a couple of reasons:
1. It allows the developer to debug player accounts / challenges
2. You can modify the scriptData and privateData of a player from NoSQL
Shane
2 people have this question
1 Comment
Customer Support
said
over 7 years ago
Answer
This is exactly right.
Your question about System Collections:
They are visible in the NoSQL Explorer for a couple of reasons:
1. It allows the developer to debug player accounts / challenges
2. You can modify the scriptData and privateData of a player from NoSQL
Jussi Härkönen
Below are some notes about GS functionality that I've had difficulties to deduce. I've had to determine some of the features experimentally, so please correct me if I got something wrong.
Collections
Live, Preview and Snapshots
This is exactly right.
Your question about System Collections:
They are visible in the NoSQL Explorer for a couple of reasons:
1. It allows the developer to debug player accounts / challenges
2. You can modify the scriptData and privateData of a player from NoSQL
Shane
2 people have this question
Customer Support
This is exactly right.
Your question about System Collections:
They are visible in the NoSQL Explorer for a couple of reasons:
1. It allows the developer to debug player accounts / challenges
2. You can modify the scriptData and privateData of a player from NoSQL
Shane
-
Design issues with user events
-
Using NoSQL
-
Runtime Collections vs Metadata Collections
-
Anonymous authentication from browser app
-
Modules
-
Movement With Unity
-
Problem with url parameters for downloadables
-
Querying NoSql GameSparks database
-
Challenge accesType
See all 2487 topics