I’m planning how to save progress in my new game. There might be a large number of levels. Each level will store a few integers like score, time, star rating etc.
Is there a limit on how many files can be saved with sys.save()?
I’m tossing up having a small number of files with a lot of data, or one file per level. I like the idea of using many files, because the save time would be constant irrespective of which level the player has reached.
This is probably an OS/platform thing, so limits would be based on whatever resources the user has available in general. Probably not a big enough limit for you to worry about, but keep in mind OS operations add up in time.
Yeah, that makes sense. It would be interesting to hear people’s experience with this on various platforms, which approach Defold devs tend to take.
Until now I haven’t had to deal with more than a handful levels, and then it doesn’t really matter too much. With this game, which if proven popular, could easily have hundreds, maybe even thousands of levels. I’m trying to avoid having to change structure once it becomes big and plan for this now.
I suppose the next step is to test on device to see which becomes a problem first; many files or large files. In the meantime, if anyone has any experience to share I’d be delighted to hear it!
Our games have a ton of game related data files but most of them are in the bundle.
For saves in appdata we don’t use a ton of files, maybe 10 per profile and just whatever the user is at is saved so not many files are necessary.
You can optimize the size of your save data by not saving raw tables and instead using a custom binary data format. You could serialize then zip your save data on saving/loading too. If you give more specifics on what you are considering using / how big you expect your save files to be we can give better suggestions.
x 1,000
I would use a single file for saving the progress. Of course, the configuration settings are in a separate file. At least this is my approach, still not tested with Defold but tested in previous games (on Nintendo DS).
Even if this means possibly saving a table with 1000 entries? I have also used a single file previously, but with much less data.
Probably there is something I am missing… Why are you worried about a table with 1K entries? Could there be any problem with lua or Defold I am not aware? 
All progress in my game is a unique table with a lot of subtables… For a hundred of levels with these data for each levels:
level_name = {
is_unlocked,
is_unlockable,
played,
cleared,
highscore ,
apple_num,
played_num,
cleared_num,
perfect_num,
failed_num,
won_challenges = {},
just_won_challenge,
invitations = {}
}
I see no problem on Android, Mac, PC, Switch…
I strongly recommend anyone with a similar question, to actually test it too, to see what the bottlenecks actually are.
Also, I suggest actually making a quick calculation to see what’s reasonable:
1 level:
10 numbers (64 bit) = 10 * 8 = 80 bytes + type overhead
let’s round it up to 160 bytes
Each table will also have some overhead.
Let’s round it up to 200 bytes per level.
Each save file has a max size of 512kb.
512kb = 512*1024 = 524288 bytes
Finally, 524288 / 200 = 2621 levels
Ofc, the actual numbers needs verification, but you can easily create a function that creates such a table, that you can then save/load.
That’s great! Then it seems likely that it’s safe to store progress in one file.
I don’t understand if @Mathias_Westerdahl is suggesting that having many files is a better option than a unique large file…
My example was for using 1 save file, containing a large Lua table.
Yes, that was clear! But what is your suggestion? Is it better to use one single large file (below the limit of 512kB) or many small files?
Not sure anything is “better” here, but personally, I wouldn’t keep 1000’s of save files around.
Thanks guys. This has been a niggle for a while, and I feel much more confident one file is the way to go now.