I agree. This seems in line with how the other consoles handle it. Most games will watch for a system key and implement a pause, but its really up to the developer.
But it will depend upon how Ouya has it implemented. If it pushes the app to the recent application list to bring up the system menu, then Android typically tombstones the app.
It's my understanding that Android is at least going to onPause your activity when any sort of dialog is shown over it. If I'm wrong and there's a way to work around this, definitely let me know! (without having to modify the firmware to change the Activity lifecycle :-S eek)
How about: home button press = pause home button hold = OUYA menu
Add me to the agree pile on this one, but at a system level, it should actually be:
home button press = Android menu key home button hold = OUYA menu
This would make porting easier, I assume, and since OUYA doesn't currently use the menu key for anything, this would be a great use for it that devs can easily wrap their heads around.
(I don't have a dev kit, but I assume that the "OUYA menu" in this context is actually OUYA's implementation of the Android home key. Correct me if I'm wrong)
But I think we can go one step further. For certain games and apps, the system-level OUYA menu may be good enough as a pause function, so neither a game-specific pause function nor menu is always required. In these cases case, a dev likely wouldn't want to force the user to hold down the button before something happens (which would impact usability), so perhaps the ODK can give devs a flag in the XML manifest which indicates if the android menu key is not mapped to anything, and in those cases simply pressing the home button would to go straight to the OUYA menu.
This give devs flexibility to *not* use it as a pause/start button, especially if they plan to use face buttons for inventory menus or other "psudo-pause" functionality, while still lining up with user expectations about what the home button does (we don't want nothing to happen when a user presses it).
How about: home button press = pause home button hold = OUYA menu
Add me to the agree pile on this one, but at a system level, it should actually be:
home button press = Android menu key home button hold = OUYA menu
This would make porting easier, I assume, and since OUYA doesn't currently use the menu key for anything, this would be a great use for it that devs can easily wrap their heads around.
(I don't have a dev kit, but I assume that the "OUYA menu" in this context is actually OUYA's implementation of the Android home key. Correct me if I'm wrong)
But I think we can go one step further. For certain games and apps, the system-level OUYA menu may be good enough as a pause function, so neither a game-specific pause function nor menu is always required. In these cases case, a dev likely wouldn't want to force the user to hold down the button before something happens (which would impact usability), so perhaps the ODK can give devs a flag in the XML manifest which indicates if the android menu key is not mapped to anything, and in those cases simply pressing the home button would to go straight to the OUYA menu.
This give devs flexibility to *not* use it as a pause/start button, especially if they plan to use face buttons for inventory menus or other "psudo-pause" functionality, while still lining up with user expectations about what the home button does (we don't want nothing to happen when a user presses it).
If we were to do this, the easiest way to have that happen is with something called "fallbacks". I can declare in our keychar map file that if a menu button press isn't consumed, that it will do a secondary action (in this case, the home or OUYA menu button). See: http://source.android.com/tech/input/key-character-map-files.html
I would also point out that making it use Android's menu key (rather than just defining another arbitrary controller button) would give some standardization to developers, and generally discourage them from using the button as another action button.
Of course, nothing actually stops anyone from mapping the menu key to whatever they want, but it makes it a pseudo-system-level button which promotes proper UX design (which was the original purpose of Android's menu key, afterall).
If we were to do this, the easiest way to have that happen is with something called "fallbacks". I can declare in our keychar map file that if a menu button press isn't consumed, that it will do a secondary action (in this case, the home or OUYA menu button). See: http://source.android.com/tech/input/key-character-map-files.html
Oh, sure. That makes way more sense than putting it in the manifest. It would actually allow for the button to be a menu button in one mode of a game (single player), but the system button in another (multiplayer).
My background is in AIR development, so I've only scratched the surface of how Android is designed.
Add me to the agree pile on this one, but at a system level, it should actually be:
home button press = Android menu key home button hold = OUYA menu
This would make porting easier, I assume, and since OUYA doesn't currently use the menu key for anything, this would be a great use for it that devs can easily wrap their heads around.
Actually, I don't think it makes it easier or harder. Ouya already has a custom controller class that maps that button to a constant referring to "SystemButton".
It's not very likely that developers will look at the keyboard input APIs as well as the OuyaController class. In fact, I'd go out on a limb and say it should be discouraged.
@nick It might be what android does by default and that might make sense on phones, but OUYA is a console first and an android device second, no? ;)
Unfortunately it's also how many of the components work internally within Android as well. Changing the lifecycle of apps isn't something to take lightly, I'm afraid.
Unfortunately it's also how many of the components work internally within Android as well. Changing the lifecycle of apps isn't something to take lightly, I'm afraid.
Hmm.. So if memory is low when the system menu pops up, the game's process is subject to possible termination?
Unfortunately it's also how many of the components work internally within Android as well. Changing the lifecycle of apps isn't something to take lightly, I'm afraid.
Hmm.. So if memory is low when the system menu pops up, the game's process is subject to possible termination?
Which may require the system menu to just exist in memory at all times so it doesn't need to steal any resources from any running processes :-X
Which may require the system menu to just exist in memory at all times so it doesn't need to steal any resources from any running processes :-X
I suppose that might work.
The only issue I see with this is, great care will need to be taken to ensure that the menu doesn't grow with each iteration of Ouya's OS or some decision needs to be made (sooner than later, preferably) how much RAM they'll always reserve for services like this. A nightmare situation is a future update of the OS that breaks applications because they are expecting to have more RAM than what's actually available because the memory resident services now take up more memory.
I don't think it's necessary (or wise) to keep the system in active memory, although perhaps disk caching (or "page filing," whatever) would be required in order to allow apps to use all available memory *and* allow the system menu to be accessible at all times.
As for the risk of app termination, can't you set an Android app to resist termination when backgrounded (when bringing up the system menu)? And likewise, can't the system be designed to override that resistance when the user asks it to (when you "quit" to the main menu)?
Basically, I don't see it as impossible for the OUYA system to (by default) avoid the pitfalls of Linux/Android-style multitasking, in favor of a more console-style model.
I think with 1GB of memory it's highly unlikely that your game will be thrown out of memory. Would be nice though if it was a certainty - so we could ommit state saving code (making it takes some times and is prone to bugs). Although if we want to release our games outside of OUYA (for Android tablets for example) we would need that code anyway, so I don't mind either way.
Displaying a DialogFragment will *not* pause the underlying activity. The fragment runs inside the activity. This might be a possible solution for a menu. If you want people to be able to extend it, that could be more difficult.
So basically you would need a FragmentActivity for us to extend that has a default implementation of a key listener for the menu button. That listener would create the DialogFragment and call fragment.show(...).
I could see something like every game would simply extend OuyaGame or some such where OuyaGame is a FragmentActivity with the necessary abstract classes and interfaces for us to use system menu.
Displaying a DialogFragment will *not* pause the underlying activity. The fragment runs inside the activity. This might be a possible solution for a menu. If you want people to be able to extend it, that could be more difficult.
So basically you would need a FragmentActivity for us to extend that has a default implementation of a key listener for the menu button. That listener would create the DialogFragment and call fragment.show(...).
I could see something like every game would simply extend OuyaGame or some such where OuyaGame is a FragmentActivity with the necessary abstract classes and interfaces for us to use system menu.
The system menu is meant to be within a console-level context, not something that's implemented across individual apps. If we were going to implement that at the superclass level, we'd probably modify the Activity class itself.
Tapping the touch pad seems perfectly fine for me.
But maybe a lot of you are intending to use it for other things, I've always just seen it as something that was thrown in to make it easier to port smartphone games.
But maybe a lot of you are intending to use it for other things, I've always just seen it as something that was thrown in to make it easier to port smartphone games.
I get where you're coming from, and I'm sure a majority of games will not use the touchpad for gameplay, but I'm certain that there will be games which make use of it in gaming context, like drawing a code on a door, Okami/Zelda style, but also there will be apps that need a virtual keyboard, and games which use RPG-style inventory screens, where the touchpad will be useful (and marketable). Furthermore, not all of those games will use those elements while the game is paused (think: ZombiU).
The touchpad is the one control element which is wholly unique to OUYA, and if encouraged, could lead to innovative game design, so I am strongly opposed to promoting the touchpad for a pause button as a standard practice, simply because it will limit the imagination of developers.
And worse, anyone who does wants to use the touchpad for gameplay purposes will then be forced to come up with their own fragmented pause implementation.
We all know that there's a general expectation among users that a controller's main face button is usually "jump" or "interact," that the right trigger is usually "fire" (etc., etc.), but users also know that there are many exceptions. On the other hand, there is no more standardized control expectation than that the "start button" (or equivalent) is reserved specifically to pause the game, and users will expect it to work the same way in practically *any* game.
It's too late to add one now, of course, but the system button "press/hold" solution is the next best thing. It's elegant, lines up with user expectations, and doesn't take control options away from the developer or demand that they solve the problem themselves (or teach players what to do) each time.
If OUYA really wants to be a accessible gaming platform, it can't allow janky non-standard fragmented implementations be the norm.
Forgive me if I'm being a little too passionate about this, but can you imagine if the Wii U didn't have start/select buttons, and developers responded by using the touchscreen to pause every game? This is a legitimately big deal. :-)
but also there will be apps that need a virtual keyboard
Just a small note, the OUYA has a virtual keyboard that's controlled entirely by standard joystick controls, and it works far better than using the touchpad to move a mouse around.
Tapping the touch pad seems perfectly fine for me.
But maybe a lot of you are intending to use it for other things, I've always just seen it as something that was thrown in to make it easier to port smartphone games.
Well.. as it is right now, the touchpad isn't really ideal for anyone expecting to do that. It's more like the kind you have on your laptop.
And consequently, it's not really responsive enough, nor does it support multi-touch. Gestures would probably need to be re-implemented as well. With that in mind, I don't think porting most modern mobile apps is going to be trivial or yield an intuitive experience. Like a laptop touchpad, it's currently best suited for navigating menus and UI elements.
Fair enough, but I just listing potential examples. My point was to discourage any practice which would make it harder for devs to get creative with the control inputs available to them.
I think with 1GB of memory it's highly unlikely that your game will be thrown out of memory. Would be nice though if it was a certainty - so we could ommit state saving code (making it takes some times and is prone to bugs). Although if we want to release our games outside of OUYA (for Android tablets for example) we would need that code anyway, so I don't mind either way.
The primary concern is what happens to service connections (such as networking) if the process terminates. Does the player in a FPS get thrown out just by bringing up the system menu? Mobile apps can typically recover from a situation like this because there aren't many games that require a persistent network connection. (Words with friends, for example, is asynchronous)
Of course, this could probably be resolved by having a main network service running all the time, and connecting/disconnecting to it managed through the ODK.
@nick It might be what android does by default and that might make sense on phones, but OUYA is a console first and an android device second, no? ;)
Unfortunately it's also how many of the components work internally within Android as well. Changing the lifecycle of apps isn't something to take lightly, I'm afraid.
Not trying to underplay the difficulty of the task. Merely pointing out that regardless, it's the right thing to do.
Emil "AngryAnt" Johansen Game developer, AI specialist, Unity expert http://AngryAnt.com
I'm not a Developer, I'll just be a user, but coming up with a common way to pause should be a priority, since there is an oversight of a pause button (I think the atari 2600 was the last console not to have a controller with out a pause button) either controller would pause buttons should be made, the press and hold Ouya button (Best Idea) or some common pause button amongst developers, should be chose..... ( I could only imagine explaining to my kids and wife, that each game pasues differently...) Great Luck!!
It might just work out best to put pause functions as part of whatever menu system you use. I think that would generally default to the O or U button. Another option would be to dedicate clicking a stick to it since a lot of games don't use that, but I think tying pause to a function of the game (the menu) is cleaner since it allows for it to be bound wherever while remaining constant among games. You have to learn the menu command anyway, so having it pause works nicely.
The touchpad is the one control element which is wholly unique to OUYA, and if encouraged, could lead to innovative game design, so I am strongly opposed to promoting the touchpad for a pause button as a standard practice, simply because it will limit the imagination of developers.
Good point!
As for the hold/press solution, as long as you don't unpause your game when going to the home menu if the game is already paused. ;p
Comments
But it will depend upon how Ouya has it implemented. If it pushes the app to the recent application list to bring up the system menu, then Android typically tombstones the app.
It's my understanding that Android is at least going to onPause your activity when any sort of dialog is shown over it. If I'm wrong and there's a way to work around this, definitely let me know! (without having to modify the firmware to change the Activity lifecycle :-S eek)
home button press = Android menu key
home button hold = OUYA menu
This would make porting easier, I assume, and since OUYA doesn't currently use the menu key for anything, this would be a great use for it that devs can easily wrap their heads around.
(I don't have a dev kit, but I assume that the "OUYA menu" in this context is actually OUYA's implementation of the Android home key. Correct me if I'm wrong)
But I think we can go one step further. For certain games and apps, the system-level OUYA menu may be good enough as a pause function, so neither a game-specific pause function nor menu is always required. In these cases case, a dev likely wouldn't want to force the user to hold down the button before something happens (which would impact usability), so perhaps the ODK can give devs a flag in the XML manifest which indicates if the android menu key is not mapped to anything, and in those cases simply pressing the home button would to go straight to the OUYA menu.
This give devs flexibility to *not* use it as a pause/start button, especially if they plan to use face buttons for inventory menus or other "psudo-pause" functionality, while still lining up with user expectations about what the home button does (we don't want nothing to happen when a user presses it).
See: http://source.android.com/tech/input/key-character-map-files.html
Of course, nothing actually stops anyone from mapping the menu key to whatever they want, but it makes it a pseudo-system-level button which promotes proper UX design (which was the original purpose of Android's menu key, afterall).
My background is in AIR development, so I've only scratched the surface of how Android is designed.
Game developer, AI specialist, Unity expert
http://AngryAnt.com
It's not very likely that developers will look at the keyboard input APIs as well as the OuyaController class. In fact, I'd go out on a limb and say it should be discouraged.
The only issue I see with this is, great care will need to be taken to ensure that the menu doesn't grow with each iteration of Ouya's OS or some decision needs to be made (sooner than later, preferably) how much RAM they'll always reserve for services like this. A nightmare situation is a future update of the OS that breaks applications because they are expecting to have more RAM than what's actually available because the memory resident services now take up more memory.
As for the risk of app termination, can't you set an Android app to resist termination when backgrounded (when bringing up the system menu)? And likewise, can't the system be designed to override that resistance when the user asks it to (when you "quit" to the main menu)?
Basically, I don't see it as impossible for the OUYA system to (by default) avoid the pitfalls of Linux/Android-style multitasking, in favor of a more console-style model.
So basically you would need a FragmentActivity for us to extend that has a default implementation of a key listener for the menu button. That listener would create the DialogFragment and call fragment.show(...).
I could see something like every game would simply extend OuyaGame or some such where OuyaGame is a FragmentActivity with the necessary abstract classes and interfaces for us to use system menu.
But maybe a lot of you are intending to use it for other things, I've always just seen it as something that was thrown in to make it easier to port smartphone games.
The touchpad is the one control element which is wholly unique to OUYA, and if encouraged, could lead to innovative game design, so I am strongly opposed to promoting the touchpad for a pause button as a standard practice, simply because it will limit the imagination of developers.
And worse, anyone who does wants to use the touchpad for gameplay purposes will then be forced to come up with their own fragmented pause implementation.
We all know that there's a general expectation among users that a controller's main face button is usually "jump" or "interact," that the right trigger is usually "fire" (etc., etc.), but users also know that there are many exceptions. On the other hand, there is no more standardized control expectation than that the "start button" (or equivalent) is reserved specifically to pause the game, and users will expect it to work the same way in practically *any* game.
It's too late to add one now, of course, but the system button "press/hold" solution is the next best thing. It's elegant, lines up with user expectations, and doesn't take control options away from the developer or demand that they solve the problem themselves (or teach players what to do) each time.
If OUYA really wants to be a accessible gaming platform, it can't allow janky non-standard fragmented implementations be the norm.
Forgive me if I'm being a little too passionate about this, but can you imagine if the Wii U didn't have start/select buttons, and developers responded by using the touchscreen to pause every game? This is a legitimately big deal. :-)
And consequently, it's not really responsive enough, nor does it support multi-touch. Gestures would probably need to be re-implemented as well. With that in mind, I don't think porting most modern mobile apps is going to be trivial or yield an intuitive experience. Like a laptop touchpad, it's currently best suited for navigating menus and UI elements.
Of course, this could probably be resolved by having a main network service running all the time, and connecting/disconnecting to it managed through the ODK.
Game developer, AI specialist, Unity expert
http://AngryAnt.com
As for the hold/press solution, as long as you don't unpause your game when going to the home menu if the game is already paused. ;p