A triple question about DS map-based saving

[DBabicius]

Hello, fellow game developers!

I'm facing a curious, yet - I hope - not uncommon dilemma.

For a while, I've been making a puzzle/arcade game for both Steam and Mobile stores. The game has three modes, and in two of them achieving a high score is the player's primary task. The player scores points by collecting certain objects of different values.

Now, lately I've been saving high scores and other game-related values to INI files. I know it's a poor choice, since INI files are quite easy to manipulate by anyone with basic Notepad skills. Also, I created a system where a corresponding INI file would be opened and the new high score saved not instantly after the play ends, but every time the player collects an object that grants them additional points, effectively achieving a new record. For example: if the player's previous high score was 1000 points, and they beaten it by reaching 1001 points and then collected 3 more objects each worth 10 points, the INI file would be opened and a new record saved 4 times: when they reached 1001 points, then 1011 points, 1021 points and 1031 points. I went with this system, so that if for some reason the device runs out of battery or something (not necessarily the game) crashes before the run ends, the player would still have their high score saved.

I hope my description was clear enough. Now these are 3 questions that bother me before switching to DS-based saving.

1. I could afford the aforementioned logic of saving high score multiple times throughout the run as opposed to one single time at its end mostly because INI files are so quick to work with, and opening/closing them had no negative effect on the game's performance. May the same be said about DS map-based saving (I mean, all the stuff including creating a new DS-map, saving the score to it, transforming the DS map contents to a JSON, writing the JSON to a file and then possibly both closing the file and deleting the DS map)?

2. If the aforementioned option is viable, should I create a corresponding DS map only at the beginning of the run and then delete it at its end, or should I create and delete a DS map every time a fresh high score is recorded?

3. And finally, the question that gives me the most headache, and it's mostly related to game design. Would you say that the added value of saving high score so often is rather... minuscule? I mean, if the player finishes the run, their score will be saved all the same, so maybe saving the score so often just for the sake of the few cases, where something goes wrong and crashes, is a bit too much and most players don't see it as a must? In your opinion, what are the usual conventions of the industry regarding this dilemma?​

I'm grateful for your advice, and I apologize for my English.

 

[NightFrost]

1. There should be no performance hit.
2. Since you're saving frequently after new high score threshold is hit, and the structure of the DS won't change, it might be less work just to create it once and use as necessary.
3. Personally I would say it is using dev time for a relatively small gain. In the industry there's deadlines, which gives a total dev time, each dev hour carries a cost in money, and each feature must be fitted into available hours. Features might be "too expensive" due to dev hours they would take, or not "cost effective" due to number of dev hours versus the impact on players (how many affected, how large the effect). Ultimately the cost-effectiveness here is up to your decision. (Note: I don't work in the industry, so take with varying amounts of salt.)

 

[Hyomoto]

I like @NightFrost's answers but why not complicate things:
1. There is definitely a performance hit. As a general rule of thumb, it's best to limit file usage, but as long as it's not every frame you are probably okay.
2. I have no idea how you are saving high scores, but it's probably best to have the list in memory. You can just save/load the list as needed, but it seems relatively pointless to create and destroy the list while the program is still running.
3. The last bit depends on the game. Time is the most valuable of player resources and the one most often manipulated, wasted and disregarded by modern game design. Because while you might have saved the high score, if the game crashes and the player loses their progress it's not likely that the high score will be much consolation. The loss of progress, the loss of time is something you can't give them back. It's why so many games rely on wasting the player's time to sell microtransactions. In general you are probably just fine with only saving their score, at most, between levels, and that's assuming they can continue from that point. Otherwise you might as well just save it when the game is over. @NightFrost has given a reasonable industry reason why, but when you look at it from a player perspective the value added is also exceedingly low. You'd definitely do better putting that time into preventing crashes in the first place than putting in a just-in-case for when they do.

 

[DBabicius]

@NightFrost, @Hyomoto, thank you! These are some very useful bits of advice. At least now I know that storing high score every time it is update during the play is not crucial. Perhaps, if the app crashes due to non-app related reasons (battery runs out etc.), the user is less likely to blame the game...

I'll leave this topic unsolved just for a while, just in case somebody has more insights on the issue.