Jump to content

View more

Image of the Day

Adding some finishing touches...
Follow us for more
#screenshotsaturday #indiedev... by #MakeGoodGames https://t.co/Otbwywbm3a
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Anyway to saving a game before game is killed?

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Nusakan   Members   


Posted 09 March 2013 - 09:48 PM

Hi folks,


I am in a situation  where I need to make sure that when a player kills the game  and restart it doesn't loose the game content. This is need it in order to reduce cheating.


Let me clear this a bit more. I am doing a protect the base sort of game, where you are responsible of protecting the base. The scoring will be based on how many virtual days you can protect your base from the attacking A.I models. For this reason I would like to show Game Over scene when the player's base is captured. They have to start from day one to play the game again once the nasty Game Over is displayed.


The problem is that  the game will be  auto saved  every time player completes a day successfully. I need this save mechanic in order to give a player the option of continuing the game later on. This is where the problem comes in. If players  know that they are in a situation where the Game Over is unavoidable, they can simply kill the game and start over from the last saved day. They can keep repeating this until they pass the day. So my question is , "Is there a way that allows me to save the game before killing the game or shutting down the IOS device.(iPhone &iPad) or do you have another idea that could be used"


Many Thanks.

#2 turch   Members   


Posted 11 March 2013 - 07:25 AM

Take a look at the iOS Application States.


applicationWillTerminate: looks like the obvious choice but it is not guaranteed to be sent to applications which run in the background. Your best bet would be applicationDidEnterBackground:


Basically, when your app is backgrounded, write out that it is in the background state. When it is foregrounded, write out that it is in the foreground state. When your app launches, check whether the background flag is set - if so, the app was killed while in the background - either by the os, the user, or lack of power. It's not ideal, but is the best you can do on an iOS device - since an application can go from "not running" to "terminated" without executing any code, you can only rely on background / foreground.


You should get applicationDidEnterBackground: called for every situation except for sudden power loss / destruction.

Edited by turch, 11 March 2013 - 08:28 AM.

#3 NGB_82   Members   


Posted 29 March 2013 - 11:28 PM

Just adding onto turch's suggestion,


Try keeping the game's data file open during play and writing small bits of data into it periodically. You can probably do this at run-time without too much of a performance hit if you make sure there is an appropriately sized buffer. This will also allow you to do any pre-termination cleanup quickly because you are not writing out to the whole file, at once, just before the OS kills your app.


You would also want to do a quick integrity check of the data when first loading it and have it backed up for the worst case scenarios.

Edited by NickGomes, 29 March 2013 - 11:30 PM.

#4 PoliticalChaos   Members   


Posted 03 April 2013 - 08:40 AM

Yeah Demon Souls and Dark Souls do this as well.


If you are comfortable enough with multi-threading you might want to look into that. Just have a separate thread constantly checking for changes in the game and then saving the important ones to some file. You can have whatever threshold you want to determine if this is important to the game; remember the player doesn't always have to be brought back right to where they left off. As long as the variables that are most important have been saved you can just send them back to the last known checkpoint or however your progression system has been setup. This way you are not constantly writing to some file your latest position data every frame.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.