Best method to save data

Solar2D General Questions/Discussion
#1

Hi,

I’m writing a game where the user places objects on a map and would like to temporarily save the progress each time an object is placed/removed on the map. Up to now I’ve been updating a table containing the information and used GGData to save the progress.

I am however wondering if it is the most efficient way to do it. I’m thinking of using SQLite database instead, or writing to a file.

Which one of the three alternatives would you recommend? What are the pros and cons of each?

I think I will still use GGData for the persistent saving. What do you think?

I can imagine that up to a couple of thousands objects can be saved; with some parameters for each (life points, status, level, coordinates…)

#2

hi,

both nosql and sql methods should work fine but i kinda prefer sqlite3 for my local storage needs myself

dont know ggdata, though i looked it up on github right now

doesnt sound to me like you need the benefits of fast sql lookups and sorting though so anything goes really :slight_smile:

#3

Databases are great when you have lots of data and you want to work with a subset of that data. What level of reading and filtering to you plan to do? 

If you’re just saving a state that you might need to read the entire thing back in, I’m not sure how the overhead of a database will be of any assistance to you. 

Flat files are pretty efficient in the grand scale of things.

Rob

#4

I’m going to do a lot of reading (mostly single rows) and a lot of updates.
I think I will go for Database in that case.
I didn’t find anything on encryption, or any way to make the database not editable by users. Is that possible?

#5

There is no definite way of making your database tamper proof. This is especially true if the database is stored locally where it can be accessed by the users. There are, however, some means of making your data harder to read or tamper with.

I’ve generally just stored any local data in json format and encrypted those strings with salt. If a user tampers with the encrypted string, then the app can’t decrypt the string anymore, so the app knows it has been tampered with.

So, yeah. It can be done, but it isn’t always necessary (or even advisable) and there is always the possibility that the users will try to (or even succeed in) tampering with your data.

#6

If you do go the non-database route, I have a module that I use in my own apps that I open-sourced at https://github.com/schroederapps/corona-settings. I don’t imagine it’s all that different from ggdata or any number of other solutions under the hood, but I do like to think it’s easy to use and it has some built-in tamper-proofing if that’s a concern.

#7

hi,

both nosql and sql methods should work fine but i kinda prefer sqlite3 for my local storage needs myself

dont know ggdata, though i looked it up on github right now

doesnt sound to me like you need the benefits of fast sql lookups and sorting though so anything goes really :slight_smile:

#8

Databases are great when you have lots of data and you want to work with a subset of that data. What level of reading and filtering to you plan to do? 

If you’re just saving a state that you might need to read the entire thing back in, I’m not sure how the overhead of a database will be of any assistance to you. 

Flat files are pretty efficient in the grand scale of things.

Rob

#9

I’m going to do a lot of reading (mostly single rows) and a lot of updates.
I think I will go for Database in that case.
I didn’t find anything on encryption, or any way to make the database not editable by users. Is that possible?

#10

There is no definite way of making your database tamper proof. This is especially true if the database is stored locally where it can be accessed by the users. There are, however, some means of making your data harder to read or tamper with.

I’ve generally just stored any local data in json format and encrypted those strings with salt. If a user tampers with the encrypted string, then the app can’t decrypt the string anymore, so the app knows it has been tampered with.

So, yeah. It can be done, but it isn’t always necessary (or even advisable) and there is always the possibility that the users will try to (or even succeed in) tampering with your data.

#11

If you do go the non-database route, I have a module that I use in my own apps that I open-sourced at https://github.com/schroederapps/corona-settings. I don’t imagine it’s all that different from ggdata or any number of other solutions under the hood, but I do like to think it’s easy to use and it has some built-in tamper-proofing if that’s a concern.