koobas.hobune.stream
Best approach for storing complex data structures and tables (iOS and WebPlayer)
Hello All,
More of an advice request than a straight question. I'm working on a branching narrative implementation for an adventure style game and have started looking for the best way to store the data.
I have:
NPC Dialog, Items, Collectables, Scenes and so forth all of which interlink. This would seem to lend itself to a traditional normalised database design, however I'm not sure how best to proceed..?
So far I've considered:
1) Have a web connection to a SQLServer database. Not too keen on this as it forces a web connection.
2) Use an embedded database such as SQLLite. Not too keen on this as it wont work on iOS (without a whole lot of work) and the web player wont read static files or allow me to ship additional plugin DLLs.
3) Use XML to store the data and (possibly) some kind of Linq -> XML to query.
Does anyone have any thoughts on this? Has any one implemented something similar?
Thanks in advance as always for any help.
Let me preface by saying, I've not done WebPlayer or iOS Unity work.
Have you considered using ScriptableObjects? You could make classes for each type of data you want to store and then just make assets for each instance you need. This way you don't have to deal with parsing the data into a format that can be used by your code since it already is. You also have you data in first-class assets and gain all the built-in Unity support for assets, including only including the ones that your scene actually references. You can also interlink directly from asset to asset (no need for name or id references).
I think the XML would work, and is easily expandable. You could also implement some kind of hash table (to retrieve objects quickly) once the file is local.
If the data is on an external server, can't you just download it to the local client and then access the file? You could the have unity read in the file into a hash table.
The only downside to hash tables is when you get over half full of elements (as more collisions and iterations occur), and when the hash table needs to be resized. Otherwise a hash table is super efficient on retrieving data. So in this case, just store the data into a hash table (which is most cpu intensive part of the procedure) and then retrieve the information during runtime.
