You'd probably have to assign that yourself. If one of the action buttons is free, I'd recommend that. Otherwise, if your game doesn't use the Touchpad, you may be able to get away with having the user swipe the touchpad to pause the game.
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
Killa Maaki kind of nailed it. In our game, double tapping the touch pad will be pause. There is no classic style "Start" button to do a standard pause screen. There is only the Ouya button similar to the Xbox system button.
Currently, pressing the home button within an app will open the orange OUYA menu.
Next week I'm actually working on something related to this: In this orange menu, we plan on providing an API to add an additional item on the menu for your game (E.g. "Game Menu"/"Game Options") that will bring you back to your app, so you can show your own pause menu/options.
The downside to this of course is an extra button press. We'd of course like to find a way to avoid every game having a different method of pausing, so if you guys have any other ideas, let me/us know! :)
Idea. What if you add combination features to the buttons. E.g O + Back = Menu, Y + Back = Select, U + Back = Restart. Or something like that. That should be doable, right?
Button combinations are likely too complicated and not intuitive at all. They could do anything, but it should keep the user experience uniform across all games and applications. I feel like the exclusion of a Start button is a fairly big oversight when it is so widely used in game development as a pause button.
Just give us an option that when the OUYA menu is on whether to pause or not, since multiplayer games shouldn't pause, but all others can without issue. Access to settings should be in this menu (as previously mentioned) to be consistent across all games. For my game, other things like L1, D-Pad, RS will pause the game also, but mainly to access things like inventory and abilities.
If we made the OUYA button pause your game and bring up our menu how well would that work for you guys?
For my particular game, that would work if I could somehow customize what options appear in the overlay menu (for example, if the player is in the middle of a multiplayer match and they press the guide button, I'd like to stick some kind of 'Leave Match' option in the menu that pops up)
Additionally I'd like to be able to customize whether the game should actually pause or not (in a multiplayer game, if the client is paused the server could detect that it's idle and boot it from the room. I've had this issue with pausing my game in the Unity Editor before.)
Post edited by Killa_Maaki on
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
How about: home button press = pause home button hold = OUYA menu
This is what i was thinking it wouldn't be to different than the xbox hold to shut off the controller or console... Those options could be accessible from the ouya menu after holding it down.
Aggro Tactics - A tactical strategy virtual board game built with Unity3D 4.0, designed around the concept of Threat/Aggro inspired by the mechanics of chess and a customizable party like in table top games.
My game needs constant access to the pause menu, to equip items and stuff, so I'm gonna bind it to the "Y" button (the top face-button) - I've played lots of console games with an in-game menu bound to that button, and it leaves the other three face buttons for easy access to normal gameplay.
Functionality-wise the touchpad would work better to bring up an in-game pause menu, since my game isn't using it, but I have no idea how I'd get that idea across to the user. Not without an extra screen specifically telling them about it along with a picture of the controller, anyways, and I'd rather not ever come right out and tell the player anything if I can help it.
How about: home button press = pause home button hold = OUYA menu
Just as a development note (mostly for myself) in this scenario: Currently, I think the system button outputs a single scancode whether held or pressed, so this wouldn't just be a simple modification of a KCM file.
Android did however have the feature where you hold the home button to get the Recent Applications dialog, so it should still be possible (with some firmware code) if we were to go this route.
I'm actually going to use the Touchpad for my pause menu (it's an FPS, so no special touchpad controls), and I already have a tutorial implemented so I can go ahead and explain that the user should tap the touchpad to bring up the in-game menu.
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
How about: home button press = pause home button hold = OUYA menu
Just as a development note (mostly for myself) in this scenario: Currently, I think the system button outputs a single scancode whether held or pressed, so this wouldn't just be a simple modification of a KCM file.
Android did however have the feature where you hold the home button to get the Recent Applications dialog, so it should still be possible (with some firmware code) if we were to go this route.
I vote that it is definitely worth the effort. A standard across the board is extremely important and the home button is really the only thing that can be guaranteed to not really be used for in-game input.
Aggro Tactics - A tactical strategy virtual board game built with Unity3D 4.0, designed around the concept of Threat/Aggro inspired by the mechanics of chess and a customizable party like in table top games.
So perhaps the firmware could do this: Keep track of some time elapsed value while the system button is pressed. When this time exceeds 1 second, automatically pop up the OUYA system menu. Otherwise, if the button is released and it hasn't been a full second yet, send a button press event to the game/application. This frees up the game to do whatever it wants with the button (since it's handled as a standard button press as far as game code is concerned), and still allows the user to pop up the built-in OUYA menu without too much trouble.
Are you listening, OUYA devs? I think we can agree this should absolutely be implemented, preferably as soon as possible.
Post edited by Killa_Maaki on
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
How about: home button press = pause home button hold = OUYA menu
Given the hardware is mostly complete, this is ideal.
Given what nick has been saying though, it sounds very doable even though it will require more work than a few lines of code.
The user experience should absolutely be king here, so whatever is most intuitive for the player should be what we do, not what's most convenient for Boxer8 or the Game Developer's specific game.
How about: home button press = pause home button hold = OUYA menu
I like this solution as well. I would of preferred a pause button but in the absence of that we do need a consistent method across all games of getting into the game menu.
It would be painful for user to have to learn a new button or button combo for every game.
I agree with bluecollarart's suggestion. Especially, as Balbi noted, adding another button at this point is pretty difficult to do. And as a few have mentioned, there's no need to burden the end users with every developer's idea of what "pause" means.
From the ODK perspective, there really wouldn't be a change at all here. The OS would just be watching for the press and hold, open the Ouya menu, and absorb the next "press and release" to go back to the game's implemented pause menu.
Most paused game logic watches for pause and release.
The only thing that we would really need to know is if the pause menu "tombstones" the app (and will trigger the oncreate event when the application comes back into focus). Since most games are run on an update/render loop, it probably would be good to know if we need to resurrect resources and bring the state back.
For multiplayer games that need a persistent connection to a server, it's not a good idea to halt the app on "system menu", but in a singleplayer game, we'd need a callback of some kind so we can pause the game when it happens.
So perhaps the firmware could do this: Keep track of some time elapsed value while the system button is pressed. When this time exceeds 1 second, automatically pop up the OUYA system menu. Otherwise, if the button is released and it hasn't been a full second yet, send a button press event to the game/application. This frees up the game to do whatever it wants with the button (since it's handled as a standard button press as far as game code is concerned), and still allows the user to pop up the built-in OUYA menu without too much trouble.
Are you listening, OUYA devs? I think we can agree this should absolutely be implemented, preferably as soon as possible.
I mostly agree. I believe holding the system button should issue an event to the button press API anyway.
In practice, there are going to be few cases where the player isn't expecting a pause to occur as they're trying to navigate to the system menu. Otherwise, the player has to remember to do a tap to pause. Then a press and hold.
An event happening when the button is down would be ideal so we can just go ahead and pause the button. Whether the system menu pops up after it being held should be inconsequential to us developers.
For multiplayer games that need a persistent connection to a server, it's not a good idea to halt the app on "system menu", but in a singleplayer game, we'd need a callback of some kind so we can pause the game when it happens.
Depending upon how the application is managed by Ouya's version of Android, there might not be much choice here. Typically when applications move away from focus, their state is serialized, and the application's thread is terminated. When it's resurrected, a resurrection method is called with the serialized state, and it's the developer's burden to return things back to the way things were that Dalvik wasn't able to do automatically.
I understand the concern though. You don't want someone to drop out of a game because they hit the system menu and the app thread terminates.
This would be a good reason to have an OuyaActivity (as I've mentioned in another thread). Then the system menu could be part of the app itself, and not force tombstoning to occur.
Or maybe this has been thought of, and networking is being handled in a way that prevents it from dropping when going to the system menu (such as a background service that handles connectivity and the app merely subscribes to it).
How about: home button press = pause home button hold = OUYA menu
Great idea, I think this is the second most ideal solution to adding a pause button as it gives everyone a button to use to pause universally, keeping the intuitiveness of pausing, reducing player confusion between games, and still gives the system menu some space to have a universal position too.
For multiplayer games that need a persistent connection to a server, it's not a good idea to halt the app on "system menu", but in a singleplayer game, we'd need a callback of some kind so we can pause the game when it happens.
I think that the system menu should be called regardless of what happens, but whether it pauses the game or not should be a different thing, like with how Xbox Guide button on Xbox 360 or the PS button on PS3 works. When players press it, the game decides whether it should pause the game as well or not, and this usually depends on whether it's multiplayer or not.
You can usually tell because in the Xbox Guide, it doesn't take up the entire screen, and in PS3, the XMB has a semi-transparent background so you can see what's happening and both have in-game audio continuing.
This might cause problems for the power of the device though as it would probably require some permanent reserve to keep the full system menu function available at any time. If this is the case, perhaps there could be two different menus, one normal and one simplified (like when the PS button is used during a PS1/PS2 game on PS3), depending on whether the game can be paused or not?
In this orange menu, we plan on providing an API to add an additional item on the menu for your game (E.g. "Game Menu"/"Game Options") that will bring you back to your app, so you can show your own pause menu/options.
I think that the system menu should be called regardless of what happens, but whether it pauses the game or not should be a different thing, like with how Xbox Guide button on Xbox 360 or the PS button on PS3 works. When players press it, the game decides whether it should pause the game as well or not, and this usually depends on whether it's multiplayer or not.
These in combination would work the best, in my opinion
Launch and shut down, yes, maybe suspend if that is supported (I would not expect it to be on a console). An overlay system menu accessible on home button hold? Sure, but it should not pause my game.
Button up/down events for the home button should obviously also be sent to my game in order for me to add pause or other behaviour to it.
I should also receive an event when the overlay menu is shown or hidden. This would allow me to for instance, optionally also pause while the overlay menu is shown or in a multiplayer game indicate when a players view is obstructed.
Emil "AngryAnt" Johansen Game developer, AI specialist, Unity expert http://AngryAnt.com
SamJ
Posts: 18Member
Comments
If one of the action buttons is free, I'd recommend that.
Otherwise, if your game doesn't use the Touchpad, you may be able to get away with having the user swipe the touchpad to pause the game.
Android Specialist
OUYA
Next week I'm actually working on something related to this:
In this orange menu, we plan on providing an API to add an additional item on the menu for your game (E.g. "Game Menu"/"Game Options") that will bring you back to your app, so you can show your own pause menu/options.
The downside to this of course is an extra button press. We'd of course like to find a way to avoid every game having a different method of pausing, so if you guys have any other ideas, let me/us know! :)
That should be doable, right?
Just give us an option that when the OUYA menu is on whether to pause or not, since multiplayer games shouldn't pause, but all others can without issue. Access to settings should be in this menu (as previously mentioned) to be consistent across all games. For my game, other things like L1, D-Pad, RS will pause the game also, but mainly to access things like inventory and abilities.
home button press = pause
home button hold = OUYA menu
Additionally I'd like to be able to customize whether the game should actually pause or not (in a multiplayer game, if the client is paused the server could detect that it's idle and boot it from the room. I've had this issue with pausing my game in the Unity Editor before.)
Founder of ReachingPerfection.com
Functionality-wise the touchpad would work better to bring up an in-game pause menu, since my game isn't using it, but I have no idea how I'd get that idea across to the user. Not without an extra screen specifically telling them about it along with a picture of the controller, anyways, and I'd rather not ever come right out and tell the player anything if I can help it.
Currently, I think the system button outputs a single scancode whether held or pressed, so this wouldn't just be a simple modification of a KCM file.
Android did however have the feature where you hold the home button to get the Recent Applications dialog, so it should still be possible (with some firmware code) if we were to go this route.
Founder of ReachingPerfection.com
Keep track of some time elapsed value while the system button is pressed. When this time exceeds 1 second, automatically pop up the OUYA system menu.
Otherwise, if the button is released and it hasn't been a full second yet, send a button press event to the game/application.
This frees up the game to do whatever it wants with the button (since it's handled as a standard button press as far as game code is concerned), and still allows the user to pop up the built-in OUYA menu without too much trouble.
Are you listening, OUYA devs? I think we can agree this should absolutely be implemented, preferably as soon as possible.
Given what nick has been saying though, it sounds very doable even though it will require more work than a few lines of code.
The user experience should absolutely be king here, so whatever is most intuitive for the player should be what we do, not what's most convenient for Boxer8 or the Game Developer's specific game.
It would be painful for user to have to learn a new button or button combo for every game.
From the ODK perspective, there really wouldn't be a change at all here. The OS would just be watching for the press and hold, open the Ouya menu, and absorb the next "press and release" to go back to the game's implemented pause menu.
Most paused game logic watches for pause and release.
The only thing that we would really need to know is if the pause menu "tombstones" the app (and will trigger the oncreate event when the application comes back into focus). Since most games are run on an update/render loop, it probably would be good to know if we need to resurrect resources and bring the state back.
In practice, there are going to be few cases where the player isn't expecting a pause to occur as they're trying to navigate to the system menu. Otherwise, the player has to remember to do a tap to pause. Then a press and hold.
I understand the concern though. You don't want someone to drop out of a game because they hit the system menu and the app thread terminates.
This would be a good reason to have an OuyaActivity (as I've mentioned in another thread). Then the system menu could be part of the app itself, and not force tombstoning to occur.
Or maybe this has been thought of, and networking is being handled in a way that prevents it from dropping when going to the system menu (such as a background service that handles connectivity and the app merely subscribes to it).
You can usually tell because in the Xbox Guide, it doesn't take up the entire screen, and in PS3, the XMB has a semi-transparent background so you can see what's happening and both have in-game audio continuing.
This might cause problems for the power of the device though as it would probably require some permanent reserve to keep the full system menu function available at any time. If this is the case, perhaps there could be two different menus, one normal and one simplified (like when the PS button is used during a PS1/PS2 game on PS3), depending on whether the game can be paused or not?
Launch and shut down, yes, maybe suspend if that is supported (I would not expect it to be on a console). An overlay system menu accessible on home button hold? Sure, but it should not pause my game.
Button up/down events for the home button should obviously also be sent to my game in order for me to add pause or other behaviour to it.
I should also receive an event when the overlay menu is shown or hidden. This would allow me to for instance, optionally also pause while the overlay menu is shown or in a multiplayer game indicate when a players view is obstructed.
Game developer, AI specialist, Unity expert
http://AngryAnt.com