On 6/8/2010 10:48 AM, Sean Hodges wrote:
On Tue, Jun 8, 2010 at 3:17 PM, Leigh McRae
<[email protected]> 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.
I looked at Raging Thunder 2 and it's a high quality game for sure of
significant size. They have handled the task switching perfect as far
as I can see but I can bet they didn't enjoy the experience :)
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.
No worries as you didn't sound patronizing and I am in no way
offended. I just wanted to be clear that I am no longer having a
problem and that we are at this point just discussing merits of the system.
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
<[email protected]> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
