On Tue, Jun 8, 2010 at 3:17 PM, Leigh McRae <leigh.mc...@lonedwarfgames.com> wrote: > > Well this really depends on the game. For smaller scale games the time to > load from scratch is so short you might not realize that the game is > actually being restarted.
Some examples of the games I was referring to are "Armageddon Squadron" and "Raging Thunder 2", both produced by Polarbit: http://www.polarbit.com. I would consider them both large scale games, but I guess the meaning is relative. > The framework is what it is and we can discuss this to the cows come home. > The original point was knowing the order of all the calls and now it's > clear enough that I can work with it. Apologies, I didn't mean to sound patronising. I'm merely interested in this kind of topic, particularly with extreme conditions such as the game state handling that you described. I also found the earlier discussion between you and Mark very informative. > Oddly enough on BlackBerry I just have to pause my game when being put into > the background and I resume when put back into focus. I don't loose my > OpenGL context and I am not forced to do anything. The end user experience > is better as there are no forced loads. I would have thought a newer API > would be easier for the developer. I agree losing the OpenGL context can involve a bit of work, I'm not familiar with BlackBerry development so I can't make comparisons. The Rokon game engine tends to handle this by wrapping a SurfaceView and keeping track of the context during the lifecycle: http://code.google.com/p/rokon/source/browse/trunk/OpenGL/GLSurfaceView.java?spec=svn25&r=25. This seems to be effective, but it does leave you wondering why the context lifetime isn't looked after for you by default. > > >> > > > On 6/8/2010 4:49 AM, Sean Hodges wrote: >> >> There are a lot of large successful games available on Android, and >> they all appear to be using the activity lifecycle without much >> problem. I would start by taking a look at how they work. >> >> My experience is that a game might "pause" when I leave to answer a >> phone call or run another app. When I return, the app offers to resume >> gameplay, and very occasionally an app will present a "loading" screen >> as the game is re-loading its state. The resume time never takes long >> (if it is needed at all), which suggests that most existing mobile >> games strive to ensure there is not a lot of game state to save. This >> is the common case, and the one mobile gamers are used to. >> >> The worst case for the end user is if the game developer has worked >> around the app lifecycle to keep their game in memory, and it causes >> incoming phone calls to become unresponsive or drop completely. >> Adhering to the activity lifecycle is the most efficient way to make >> sure that this doesn't happen. The key is not to think of the activity >> lifecycle as a set of unwieldy rules forcing you to do this and >> that... Think of it as the environment that you are working in. You >> are writing for a multitasking OS running on a range of devices, most >> of which have very limited resources, and many require real-time >> interruptions such as phone calls and text messages. The requirements >> on how you store and retrieve your state is how Android handles the >> resources, a bit like how OpenGL restricts how you handle textures to >> meet resources of the graphics card. >> >> I agree with Frank, Mark and String; if your >> onSaveInstanceInstanceState() is going to take a long time to >> complete, then you need to reduce the amount of data you are trying to >> store. Perhaps if you describe the kind of content you are dealing >> with (e.g. textures, 3D map data, etc), you might get some suggestions >> on how to handle them more efficiently within Android. >> >> >> >> On Tue, Jun 8, 2010 at 4:38 AM, Leigh McRae >> <leigh.mc...@lonedwarfgames.com> wrote: >> >>> >>> The common case is where an activity is put into the background and isn't >>> killed for memory. Forcing an Activity to save it's state when it's not >>> required is a waste of resources on a resource scarce platform. >>> >>> >>> On 6/7/2010 10:38 PM, Frank Weiss wrote: >>> >>>> >>>> Hmm. I'm trying to grok how a world simulation that needs lots of memory >>>> is a common case instead of an extreme case for a handheld mobile >>>> device. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Android Developers" group. >>>> To post to this group, send email to android-developers@googlegroups.com >>>> To unsubscribe from this group, send email to >>>> android-developers+unsubscr...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/android-developers?hl=en >>>> >>> >>> -- >>> Leigh McRae >>> www.lonedwarfgames.com >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Android Developers" group. >>> To post to this group, send email to android-developers@googlegroups.com >>> To unsubscribe from this group, send email to >>> android-developers+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/android-developers?hl=en >>> >> >> > > -- > Leigh McRae > www.lonedwarfgames.com > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
