1
\$\begingroup\$

For standalone game, what's the best time to save game data, such as player's coins, level, skill data and so on?

Should the data be saved before quitting? Or whenever it changes? Or something else?

\$\endgroup\$
  • 1
    \$\begingroup\$ Why not let the player save by his own? \$\endgroup\$ – Ocelot Aug 21 '15 at 9:26
  • 1
    \$\begingroup\$ I see at least three other options : 1) as @Ocleot said, the user can save by his own 2) save every xxx seconds, and 3) save at 'important' moments of the game. What's nice with 3) is that you can prevent the possible slow-down of the saving if you do it while something very simple is happening in the game (a door opening / a non-playable cinematic moment / ... ). \$\endgroup\$ – GameAlchemist Aug 21 '15 at 10:21
  • \$\begingroup\$ 4) save on every change, this is viable if you treat your save file as a database where you can quickly write only what changed. It won't fit every game. 5) a combination of letting the player decide and saving automatically every xxx seconds. Which provides control to the user, but also covers for the case where the player forgot to save and there was a crash. Aside from those options consider that having auto saves to roll back to in case of a corrupted save is a good plus. \$\endgroup\$ – Theraot May 31 '17 at 17:04
5
\$\begingroup\$

Gameplay Design

Technically, it depends on the style of gameplay you are designing. In some game genres, it is almost explicitly expected to have certain "save types".

For instance, in online casual flash adventure/RPG games, you will often save every tiny change into a cookie so if the player accidentally (or intentionally) closes the browser, the game state persists. Another common alternative is frequent auto-saves that will be triggered by certain events such as you win/lose a battle or when the player returns to town.

In MMORPG (not what you're doing specifically), it is expected that all the characters' data is saved immediately with every change.

In casual platformers and shooters, you don't particularly need to save but it's expected that you let the player "unlock" content such as stages / worlds and achievements.

In some oldskul games, you'd let the player save when they want to. This is a feature that lends itself well to long "serious" games that require a substantial time investment like more classical RPG, Adventure, FPS and RTS games. Adding a quick save & quick load option too and possibly an auto-save in addition to that.

In roguelikes, you are expected to save at least when the player quits the game if not all the time but in this case, saving all the time is not a gameplay feature as much as it's a UX one in case of crashing. The gameplay feature is surprisingly the lack of a load button which boosts adrenalin in close call situations. This is a good example since having only one chance to do something can be considered a gameplay feature or a great annoyance depending on the person you ask and the gameplay context like a challenging rare boss fight or a bonus stage (where you can't save or load the game).

If your game is casual, as in you're not going to limit saves / lives for the sake of additional difficulty or to intensify suspense, then saving all the time is a virtue; that is assuming it doesn't hurt performance.

Performance

You don't have to heavily compensate on performance if you save data asynchronously. You request the disk (or http server) to write some data while you continue running the game. If the game has some kind of "game world" structure like cities -> stores, mazes -> levels -> rooms then you can get away with saving whenever the player enters or leaves a zone. Just remember that when you save asynchronously you still want to make sure the save went through, especially if the play decided to save the game. ;) If for some reason (disk space | online connection issue), you are unable to save, you may wanna notify the player the connection was lost or whatever is relevant in that case.

Also it is important to note you don't have to store everything in one file or one DB record. You can save information about the character incrementally. For example, if the character travels across your game worlds and visits many zones, you may want to keep track of visited zones. You don't have to store all that in one file. You can "touch" (create a tiny possibly empty file) inside a designated directory or add a row in a database. You don't have to write all the progress related data at once. The same thing with items, you can add or modify it on the fly with a local sqlite DB, or a designated file folder with one file for equipment, armor, weapons, etc or even one tiny file per item. Obviously, the more complicated it is, the harder it is to maintain so keep it simple.

\$\endgroup\$
0
\$\begingroup\$

If your game is addictive as I hope, and after 1 hour plaing, a black-out or a pc crash , make me loose all progress.. i regret you do not added an in game autosave. Basicaly you missed option 1.5 save sometime (time related, level changing)

\$\endgroup\$
0
\$\begingroup\$

I'd say the best thing to do would be to save game data when somethings changed as sometimes the game may end up force closing which would result in losing all your data

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.