FYI - Kindle Hibernate and Android Camera Bug Work Arounds
Hey, Gang. Well, after having my game, Metrop-A-Stomp, rejected from the Kindle Fire for not properly using the hibernate option, I decided to take a day and dig in. Here are some of my findings that will hopefully be helpful to others.
Hibernate Works on Kindle...well kinda.
You can create a rule that will use Hibernate on Kindle as you would with a Nook app. I had it setup to simply Pause the game when the Hibernate button is pressed. This didn't fully work in my case because 1) My music tracks kept playing even when paired with a pause music behavior on hibernate button and 2) It reveals that Android camera bug something fierce.
How I worked around it.
1) I created an actor that had two behaviors when Hibernate button is pushed: Pause Game and Stop Music. If you don't have background music in that particular scene, then you can skip that last part. If you use a pause music behavior, you're okay unless the user has a lock screen setup on their Kindle. With a normal pause music behavior, the music will end up playing under the lock screen. Assuming this may get you rejected if spotted by an eagle eyed reviewer, I went with the super cautious approach below.
2) Next, I created a special Hibernate Pause scene so that the player would know that it isn't the standard pause screen. In my case, my pause screens used translucent backgrounds which showed up the camera bug as well. Basically, my Hibernate Pause screens are a black screen with the game logo and a continue button. The continue button unpauses the game and starts playing a specified music track when pressed. If your BG music really is just BG music as in my game, having it start over here isn't so bad.
3) If you are using your Hibernate Pause as I described above, you will need to create a copy for each level/scene that needs a specific music track playing. Ex. I have a mini intro and a level that have one continuous track that plays over them. Each of these levels can use the same Hibernate Pause menu because its the same music launched when the user hits continue. I had to create other pause menus for the main game, opening menus, etc. because they all use different music tracks.
This got me around the hibernate issue, but is, as you can imagine, a major pain in the butt and doesn't work in all circumstances. Ex. In my main game's story intro, the whole soundtrack is a "music" file that syncs to picture. If a user hibernates here, they are going to end up listening to a music track when they come back, not the real soundtrack. I'm okay with this because it is likely a very rare occurrence.
Okay, now on to the Android camera bug.
How I worked around it.
I first need to caveat that my game doesn't have any moving cameras except for my opening menus which swish in a t-bar kind of motion. So, like everyone else has been seeing, whenever you pause Android (I'm testing on a Kindle), the camera origin gets set up in random places for any scene that is bigger than the actual camera size and with a camera origin other than 0,0. This is 99% of my levels and many other folk's as well. Here's a way I got around it that was pretty simple: constrain your camera origin.
For Non-moving cameras
1) Setup up two real scene variables in your scene called Lock_X and Lock_Y or something similar. Set these to whatever values you are using for your camera's X and Y origin.
2) Create a hidden actor with two constrain behaviors. Set the first to constrain CurrentScene-Camera-Origin-X to Lock_X and the second to CurrentScene-Camera-Origin-Y to Lock_Y. Plop that into any given scene. No rules required, just use the constraints.
3) Now whenever you pop back into your scene, it will snap back to wherever you set it no matter where the bug throws it. You may see it wrong for a split second, but nothing that will really hamper game play.
4) I should note that if you are using pause menus that are translucent, you will see the android bug through the background, but it will still be fixed when you unpause your scene. A opaque pause screen BG will fix that issue.
5) You can also skip step one and just manually set values in the constrain behaviors and adjust the prototype for each scene you put it into.
For basic moving scenes.
My menus are setup with four screens arranged in a "T" shape in a scene that is 3 screens wide by 2 tall. The lower left and right thirds are blank, but never seen. When a user picks a menu option, the camera pans to that location (interpolates for 1 second) and stops. I hope you can picture that or this explanation may not make sense.
1) Setup up two real scene variables in your scene called Lock_X and Lock_Y or something similar. Set these to whatever values you are using for your camera's starting X and Y origin.
2) Create a boolean scene attribute called Cam_Move_OK or whatever you want. Set this to false.
2) Create a hidden actor with two constrain behaviors in a rule. The rule should be: When Cam_Move_OK = False, Constrain CurrentScene-Camera-Origin-X to Lock_X and constrain CurrentScene-Camera-Origin-Y to Lock_Y.
3) Now your scene is locked down like in the first example.
4) When you need to trigger a move, (in my case, user pushes button and camera pans on menu), make whatever is triggering the move do three additional things:
a. On BLANK, set Cam_Move_OK to True
b. Set Lock_X and Lock_Y to target camera origin coordinates
c. Set timer for after X time, set Cam_Move_OK to false.
What this step does is unconstrains your camera for a set amount of time and lets it move. Once it is done moving, it locks it down in that position so that the bug will be fixed when coming back from pause.
Now, I know this workaround for moving scenes will not work for everybody, especially if your camera is very dynamic, but if you are doing something simple (Pan to the left over the course of a second. etc.) it should work for you.
I apologize if this post is more confusing than helpful. I guess the main take aways are hibernate works on Kindle sorta, and constraining your camera can easily fix the Android pause camera bug.
Hibernate Works on Kindle...well kinda.
You can create a rule that will use Hibernate on Kindle as you would with a Nook app. I had it setup to simply Pause the game when the Hibernate button is pressed. This didn't fully work in my case because 1) My music tracks kept playing even when paired with a pause music behavior on hibernate button and 2) It reveals that Android camera bug something fierce.
How I worked around it.
1) I created an actor that had two behaviors when Hibernate button is pushed: Pause Game and Stop Music. If you don't have background music in that particular scene, then you can skip that last part. If you use a pause music behavior, you're okay unless the user has a lock screen setup on their Kindle. With a normal pause music behavior, the music will end up playing under the lock screen. Assuming this may get you rejected if spotted by an eagle eyed reviewer, I went with the super cautious approach below.
2) Next, I created a special Hibernate Pause scene so that the player would know that it isn't the standard pause screen. In my case, my pause screens used translucent backgrounds which showed up the camera bug as well. Basically, my Hibernate Pause screens are a black screen with the game logo and a continue button. The continue button unpauses the game and starts playing a specified music track when pressed. If your BG music really is just BG music as in my game, having it start over here isn't so bad.
3) If you are using your Hibernate Pause as I described above, you will need to create a copy for each level/scene that needs a specific music track playing. Ex. I have a mini intro and a level that have one continuous track that plays over them. Each of these levels can use the same Hibernate Pause menu because its the same music launched when the user hits continue. I had to create other pause menus for the main game, opening menus, etc. because they all use different music tracks.
This got me around the hibernate issue, but is, as you can imagine, a major pain in the butt and doesn't work in all circumstances. Ex. In my main game's story intro, the whole soundtrack is a "music" file that syncs to picture. If a user hibernates here, they are going to end up listening to a music track when they come back, not the real soundtrack. I'm okay with this because it is likely a very rare occurrence.
Okay, now on to the Android camera bug.
How I worked around it.
I first need to caveat that my game doesn't have any moving cameras except for my opening menus which swish in a t-bar kind of motion. So, like everyone else has been seeing, whenever you pause Android (I'm testing on a Kindle), the camera origin gets set up in random places for any scene that is bigger than the actual camera size and with a camera origin other than 0,0. This is 99% of my levels and many other folk's as well. Here's a way I got around it that was pretty simple: constrain your camera origin.
For Non-moving cameras
1) Setup up two real scene variables in your scene called Lock_X and Lock_Y or something similar. Set these to whatever values you are using for your camera's X and Y origin.
2) Create a hidden actor with two constrain behaviors. Set the first to constrain CurrentScene-Camera-Origin-X to Lock_X and the second to CurrentScene-Camera-Origin-Y to Lock_Y. Plop that into any given scene. No rules required, just use the constraints.
3) Now whenever you pop back into your scene, it will snap back to wherever you set it no matter where the bug throws it. You may see it wrong for a split second, but nothing that will really hamper game play.
4) I should note that if you are using pause menus that are translucent, you will see the android bug through the background, but it will still be fixed when you unpause your scene. A opaque pause screen BG will fix that issue.
5) You can also skip step one and just manually set values in the constrain behaviors and adjust the prototype for each scene you put it into.
For basic moving scenes.
My menus are setup with four screens arranged in a "T" shape in a scene that is 3 screens wide by 2 tall. The lower left and right thirds are blank, but never seen. When a user picks a menu option, the camera pans to that location (interpolates for 1 second) and stops. I hope you can picture that or this explanation may not make sense.
1) Setup up two real scene variables in your scene called Lock_X and Lock_Y or something similar. Set these to whatever values you are using for your camera's starting X and Y origin.
2) Create a boolean scene attribute called Cam_Move_OK or whatever you want. Set this to false.
2) Create a hidden actor with two constrain behaviors in a rule. The rule should be: When Cam_Move_OK = False, Constrain CurrentScene-Camera-Origin-X to Lock_X and constrain CurrentScene-Camera-Origin-Y to Lock_Y.
3) Now your scene is locked down like in the first example.
4) When you need to trigger a move, (in my case, user pushes button and camera pans on menu), make whatever is triggering the move do three additional things:
a. On BLANK, set Cam_Move_OK to True
b. Set Lock_X and Lock_Y to target camera origin coordinates
c. Set timer for after X time, set Cam_Move_OK to false.
What this step does is unconstrains your camera for a set amount of time and lets it move. Once it is done moving, it locks it down in that position so that the bug will be fixed when coming back from pause.
Now, I know this workaround for moving scenes will not work for everybody, especially if your camera is very dynamic, but if you are doing something simple (Pan to the left over the course of a second. etc.) it should work for you.
I apologize if this post is more confusing than helpful. I guess the main take aways are hibernate works on Kindle sorta, and constraining your camera can easily fix the Android pause camera bug.
Answers
I set up the actors as described.. maybe it works on the Kindle but not the Nook I'm using. Maybe others will have better luck
I had tried the same thing with the camera and it didn't work -- however, maybe I did something a little different, so I'll try again.
-I saw in another thread you were thinking of using .9.92 because there were issues with this rule in .9.94
Which version did you end up using to build your accepted game?