Resuming From a "Cold" Start (Saving and Resuming app state)(Using System Events to Save App State)

Getting Started Newbie Questions
#21

Hi Lori,

In most cases, when the user “suspends” the app (presses the home button or turns off the device entirely) the app should remain in a backgrounded/suspended state (those two terms being the same thing in this context). The user would not typically expect the app to restart entirely upon being backgrounded, although that might be logical in some cases, which is why the non-default option exists in the build settings file.

Now about your questions:

  1. At any time, the OS reserves the right to quit/restart an app that is in the background. This usually happens because the user has opened several other apps since the suspension of that app, and/or the OS needs to allocate more memory toward the currently active app or toward apps that were opened more recently. That’s why, if saving state is important to your game, you should consider this very real possibility and handle the “applicationExit” state as mentioned in that tutorial.

  2. I guess I answered this one in #1. You don’t need to save state on the “applicationSuspend” state, only on the “applicationExit” state. In mirror image, you would then ignore reading/restore of that saved state info on the “applicationResume” state, and instead handle it on “applicationStart”.

Hope this helps,

Brent

#22

Would the “suspend” on applicationExit work the same as what I do when I suspend for pulling up an overlay screen?

Thanks

Lori

#23

Hi Lori,

Well basically yes… if you managed the state on exit, you could return the user to that point in the app, as if it never quit. I should warn you, however, that restoring the exact state can be difficult depending on the app, and if you’re using physics, it will probably be impossible to return the physics world to the exact state that it was frozen in (on pause or whatever). This is because there are countless forces and velocities going on under the Box2D hood… even ones so subtle that you can’t see them… and it would be practically impossible to return the physics world to that point with all of the same physical energies going on.

Brent

#24

So what do I do about keeping the players happy and having the ability to return to game play?    Just let them return to the “altered” state? 

Thanks

Lori

#25

Hi Lori,

Well, it depends on your game design. If your physical objects are more “predictable”, like you have a player moving at a specific linear velocity, you could store that velocity as part of the saved state and resume it when the game returns to that state. However, if you have something like a stacked tower of blocks that are under the influence of gravity and inter-block forces and friction, it may not behave exactly like it did when you saved the state.

What type of physics game are you making?

Brent

#26

It would be more in lign with tower of blocks.  It isn’t under the force of gravity so much as collisions.   I did notice that when I pause and resume for the overlay - it freezes and then when resume the objects take off from the position of their freeze.  I already save the number of moves and score etc during game play so i think I should be ok.

Thanks

Lori

#27

Would I put the system events in my build.settings or would I need them on each level?

Thanks,

Lori

#28

Hi Lori,

What system events in build.settings? I’m not sure I understand…

#29

The system events for applicationSuspend and resume.

#30

Hi Lori,

You should handle system events with a listener function and take the proper action. So basically, it’s not in build.settings, it’s somewhere in your main code.

Brent

#31

Thanks