This looks like it’s going to be happening! Go back it over on Kickstarter and let’s make this project awesome.
https://www.kickstarter.com/projects/bentristem/your-ideal-rpg-make-a-complete-role-playing-game-iFlying Katsu commented
Ah, forgot to mention in my last comment, that another reason to opt for database backend is to further protect game data from the prying eyes of your players. It's still not a completely protected method though (if you can access it, then presumably so can they), and it requires internet access which is not always a great idea.Flying Katsu commented
In my experience, database backend is really only necessary if you need to load content from a server (like your own patches/updates or user-to-user interactions). Exactly which database protocol to use depends on what kind of data relationships you want to store, how often you need to read/write data, and how consistent you need the data read/writes to be.
For most other cases, saving to local files is usually enough. Popular formats are JSON or XML, for which you can usually find serializers (think "translators") included in your programming language or environment packages. These formats are good for nested data which would otherwise be split across several tables (or files) if stored in a database-like format.
Another popular format is CSV or TSV, which are pretty easy to write your own parsers for (and your environment may have built-in parsers for these as well). Unlike JSON or XML, the CSV and TSV formats are similar to most database formats, which makes them easy to edit (as with a spreadsheet app) or load into an existing database.
If you're concerned about users tampering with the local files, there are ways to encrypt files as hex or binary, but anyone determined enough to try can still unencrypt them. One way around this is to store salted hashes of your data files in a validation file, and check for matching hashes when loading from the files.Flying Katsu supported this idea ·