When to save game on mobile and what events to use?

My mobile game has a working 'save game' routine that I call manually by pressing a button my debug menu.

However, like normal mobile games this needs to be called automatically when when certain things happen, for example:

1. The focus changes and the games becomes a background app?
2. The game 'requests' to quit?
3. Periodically every x seconds?
4. When the game is paged out?
5. Something else

This must be a well trodden path, so what is the standard for this and what events does unity support to tie into this?

Thanks.

Just to clarify again: I'm not asking when to save as a general concept, but instead specific to a mobile game's lifecycle which adds additional times when saves should be performed like suspend, sleep, quit etc. I'm specifically asking for those who have done this before for iOS & Android and not general speculation.

 

Well, every game is going to be different on what and when it needs to save. Check the docs for various callbacks, such as OnApplicationPause, OnApplicationFocus and OnApplicationQuit: https://docs.unity3d.com/ScriptReference/MonoBehaviour.html

 

Ok thanks. To your knowledge are those 3 events the ones that cover the standard cases for mobile devices?

 

I don't think there is a standard case, is more my point. Some games need to save on level completion, some after every move, some not at all and others periodically.

 

You're missing the point of my question slightly again. I'm not asking about when to save as a generic concept for a game, but specifically for mobiles that have to deal with being paged out, sleeping, suspending and quitting etc. Because all mobile games have to deal with these things, there must be a generic set of event points that should be covered for a Unity mobile game, ie a standard response to these. I'm simply asking what those standard set of circumstances are and the usual Unity events that cover those so a save can be performed.

You alluded to that with the 3 events you mentioned: OnApplicationPause, OnApplicationFocus and OnApplicationQuit

But on iOS, apps are suspended but don't quit unless you make a setting change, so OnApplicationQuit wont be of any use then. So what can be used for an app suspension or sleep. There are similar issues with a Windows Store app.

OnApplicationFocus seems to work differently on iOS v Android too.

I'm asking for a proven set of standard times to save and corresponding events that work for these mobile unique situations.

 

Player prefs works on android to actually save.

When to save how to tell what’s going on if the app is open, am I running? If the app is able to run in the background has permissions then you can do a save after x amount of time of inactivity.

so a lot of mobile games when you are inactive and return to the game after say a phone call they have a special screen to handle it. See MKX mobile. Now MKX mobile was based off mortal kombat x which was made on unreal, but the mobile version has ported into unity, for ease of use with unity ad services. I played the hell out of this game suspecting it was made in unity to find that it was made in unity as given away when attempting to view an ad in offline mode. However; a lot of the right thing to do in unity is displayed in this game. Including how they handle mobile shaders etc. the game also minimises into the aforementioned splash screen. Which I think is based on a timer. Because you can minimise and maximise the app really fast without calling the inactive splash screen. It only ocurrs after prolonged inactivity as the app runs in the background. It also drain the hell out of battery.

I might add to this both versions of MKX iOS and Android are quite different, available on different stores and there is a time delay when updating the game. This is probably indicating that there may be something vastly different going on, code wise - in how much information about your device the app is able to get and use for its code executions. So I would speculate there is not a one size fits all here. And it’s going to have some platform specific content.

 

I'm with Grozz. You're looking for the precise number of angels that can dance on the head of a pin. While there may be people out there willing to tell you what they think their angel count is, it's not like your game will get better as a result.

Instead, the more value can be added to your program with simple economics: don't ever allow more than X amount of progress to be lost in your game. Realize that X will vary if your game is casual or if your game is some giant MMO with permadeath. Use your intuition from playtest to decide what X means in your game context.

Remember, there will never be ZERO chance of loss of progress; phones can just crash or run out of battery. The closer you move X to zero, the more work you will do. Your choice to do this is purely another economic one.

 

Not at all. I'm asking a very specific question related to ~3 distinct mobile specific events.

It's really that simple and you're overthinking my question and like Grozz answering something I've not even asked.

 

You’ll need to identify your operating system.

get list of processes. I have done this before on PC for an auto play script I made to demonstrate how YouTube views can be scammed with a vpn combo. By opening internet and going to link watching for set time and leaving.

so I would hazard a bet you search for ways to get a list of android processes in c#. So when you are running in the background you’ll know if you get further data from the currently active processes. Who knows maybe you’ll discover a malware you didn’t know about doing this.

 

I usually save on purchase/equip/use item, also at the end of play session

 

I get that. Grozz and I are telling you that this:

... doesn't exist.

Now this question:

Grozz has told you what those events are.

This. Doesn't. Exist. Every game is engineered to suit its needs.

 

In a perfect world the only non-game specific standard would be to save on ApplicationPause/Focus because it will be called before an app close (force close on iOS or Application.Quit() on Android) if the close is triggered by the user.

BUT, your game will have crashes, and these events won't be called upon a crash. So knowing that, you must save at strategic moment, where its game-specific (like it has been said, purchase/equip/consume/completion.)
Just ensure that your serialization process is optimized, low on the GC and fast.

 

I would actually suggest against saving the game state in any of the OnApplicationQuit/OnApplicationPause/OnApplicationFocus callbacks. The reasoning is this:

• OnApplicationQuit does not get called on mobiles;
• OnApplicationPause/OnApplicationFocus look like what's needed but they aren't. Any heavy IO operations in these callbacks might cause ANRs on weaker devices. This is not counting the fact these callbacks are already used by many plugins (notifications, ads etc), so adding another heavy operation just increases chances to get the ANR. As mentioned above, your game will crash sometimes, so saving data only in these callbacks would lead to players losing their data.

In my experience, best thing you can do is having a changed flag for your game state. You should set it whenever the game state changes and needs to be saved. Than you save it and reset this flag in LateUpdate. You can also set minimum time between the save operations to avoid saving on each frame.

Hope this helps.

P.S. There are no specific Unity callbacks or standard ways to save data.