For a game I am currently trying to develop, I am creating a in-game dating app, where the player can match with preloaded profiles. To make the game interesting, I plan to have a large amount of profiles to be matched with, each of those profiles having a rather rich data model (that will probably include reference to ressources, such as profile picture).
I am currently wondering how I should/could create the data for those profiles, knowing that I want the data model of the profile to be extensible (adding characteristics to the profile) and to be able to add profiles relatively easily. Profiles themselves will be static during runtime (beside the Player Profile that I would manage separately)
The ideas I had were:
Each profile is a Dictionnary kept in a separate Ressource –> huge number of files, difficult to extend, keep everything in Godot entities, probably the most straightforward?
All profiles stored in a singe Array of Dictionnary –> single Ressource, very difficult to extend, keep everything in Godot entities
Data stored in a CSV, with code to dynamically creates DatingProfile instances when needed –> seems the best solution to me because it can be easily extended and don’t clutter the Godot project with a huge number of files, but is it a good practice
As a rookie, I am probably missing something in how to do that (I guess many games have to store and manage the same amount of data - thinking about how RPG might keep data for all possible equipments), or am I overthinking this?
You can write an import plugin but you don’t need to. You can instead simply open the CSV file at startup and parse it into some dictionary structure.
Checkout youtube for godot load and save data godot dictionary, raw data theres a wrapper for sql light witch I used in cocos2dx. If you use that it would help you manage the data records better.Then you can issue commands in sql to do stuff.
If you have an import plugin made I don’t think so, but normally you would add extra files to the pack in your export settings under “Resources”, “Filters to export non-resource files/folders”
You would need a custom resource to create a plugin importer, they convert a file into a resource transparently, in your case a custom resource since “dating profiles” are not a base resource type in Godot. Making an importer is mostly busy-work filling in names, defaults, and what files it should open, but the core of reading the CSV file will have to be done no matter what so making an importer helps leaps and bounds dealing with these resources in-editor.
Embed a SQLite database. Scale that thousand-profiles-scope to ten million. Use code to generate them procedurally within SQLite from other tables containing the possible options, but do it on your computer, not the player’s; use indexes and all the pro stuff. Now you can generate new thematic sets after just a few minutes of entering new options in the tables. Hobbit names? French names? Christmas names? Halloween names? Anything.
You can use the same database to record all sorts of info about interactions with the dating profiles, and even simulate interactions between them to make them feel more connected; like a history of what they’re doing that doesn’t involve you. You can do this while it’s running, so now your limitation is gone, and instead you can build an ecosystem the player can see reacting to their decisions.
You’re gonna have to find a solution for the photos though. Maybe something where you can have like 25 faces, 25 hairs in five colors each, and so on, and then overlay them to make an exponentially large amount of different looks. SQLite can store the paths to those images, but the system to store them and put them together has to be Godot.
The winner for manual editing would be the CSV; the loser a custom resource. The best for storing images would be a custom resource; the other two can store paths. SQL wins at queries and filters, and storing interactions in real time. The resource would be the worst at extensibility; the other two just add an entry.