I'm fairly new to GameSparks, so forgive me if this is a bit basic. I've ready the docs and combed through the forums, but I'm still unclear as to the best options for dealing with custom data sets.
I have a setup where a player has multiple types of persistent data objects in their account. If I was doing this as a a straight DB application I would have something like this...
Building (type, id, level, bonuses)
Character (name, id, level, xp, etc)
Weapon (child of character 0 name, id, stats)
In this case is it best to use the mongo or nosql engines and just make my own custom data structure and attach these under player or is there an advantage to forcing this into an existing system like virtual goods for building, multiple player profiles, virtual goods for weapons, etc.
I will have a number of custom 'fields' but the custom property implementation seems to be a bit overly complex to add custom options to an item or an item instance. Once a user builds a building, a virtual good appears to be fairly limiting compared to a custom data store/object.
How do other people handle this type of structure so that the core benefits of the platform are being leveraged?
You're wise to intuit that the virtual goods may be too limiting. I'm sure you can shoehorn them to work to your purposes, but for anything not simple, it's definitely preferable to set it up as a custom collection (or collections).
I'm by no means an expert on this stuff but I can share how I do it on our fairly large f2p mobile game in development.
We have a runtime collection called 'playerState.' Each doc holds all the custom data for a particular Gamesparks player. The _id of each doc is the Gamesparks playerId so that the system and custom collection and be cross referenced.
The fields are basically major pieces of the player's 'state' in the game (e.g. character, inventory, etc). We also have an 'updated' field that stores the last (server) update to each of the fields (character, inventory). Then we have a SyncEvent that the client passes the last updated timestamps on the client, so the server only has to grab (through mongodb aggregation) the fields which were updated/out of date. This saves having to send the whole doc every time the app launches/gets out of sync.
We also have a lot of helper methods to update/retrieve from the playerState. It boils down to creating a basic query object (find the playerState doc where the _id equals the Spark.getPlayer().getPlayerId()), that can be appending with the specific details of the update you're trying to achieve. Note it also has to update the last updated timestamps of the fields that were updated.
Hopefully that was helpful in some capacity. Let me know if you have a specific question about something and I'll try and point you in the right direction.
Thank you. That is the route I think I will take. I'll keep basic good and user authentication using the core service, but augment it with custom collections that can fill in extra detail, aggregate data, and also handle updates as you suggested.
I appreciate the feedback.