I'd just like to underline a big difference in areas often treated as one in this discussion: The standard of a pause button and the built-in functionality of one.
I'm all for designating one tap on the OS button to be the standard pause button. However, under no circumstances would I be ok with the OS deciding for me what a proper response to that would be. Leave that up to my app to figure out.
This is exactly how it's done on other consoles. There is no OS level enforcement of a pause function. There is, however an agreed upon standard for which button should pause the game and this is enforced in the console certification process.
Since OUYA AFAIK will not have a certification process, this standard will become tougher to maintain. However if the alternative is having the OS arbitrarily decide for me how my app should pause, I'll gladly take whatever noise is added by apps not following the standard.
Post edited by AngryAnt on
Emil "AngryAnt" Johansen Game developer, AI specialist, Unity expert http://AngryAnt.com
If I recall, Nintendo didn't enforce a pause standard back in the day. Ghostbusters on the NES pauses with select, Ultimate Mortal Kombat on the SNES requires a cheat code to enable pausing. Still, pausing with start was widespread, unless the game design has a good reason to do differently or the developers being dumbasses by reinventing the wheel for no reason.
I'd just like to underline a big difference in areas often treated as one in this discussion: The standard of a pause button and the built-in functionality of one.
I'm all for designating one tap on the OS button to be the standard pause button. However, under no circumstances would I be ok with the OS deciding for me what a proper response to that would be. Leave that up to my app to figure out.
This is exactly how it's done on other consoles. There is no OS level enforcement of a pause function. There is, however an agreed upon standard for which button should pause the game and this is enforced in the console certification process.
Since OUYA AFAIK will not have a certification process, this standard will become tougher to maintain. However if the alternative is having the OS arbitrarily decide for me how my app should pause, I'll gladly take whatever noise is added by apps not following the standard.
I agree 100% with this. If it's a 3-5 second hold of the system button to bring up the system menu, I don't care. Let me detect when the system button is pressed in and released so I can do whatever I want with it.
Here's what I want as a developer and as clear as I can make it: Treat the system button like any other boolean button on the controller. This way I can use it how I see fit. If it happens to open the System Menu after holding for X seconds (still the best solution to no dedicated start button, which is fine), I don't care Give me a way to determine if the system menu is still up on my screen
With the above information, I can tailor my game's user experience to how I want it. At no point should the OUYA system tell my game what to do (exception being force quit of course).
I'd just like to underline a big difference in areas often treated as one in this discussion: The standard of a pause button and the built-in functionality of one.
I'm all for designating one tap on the OS button to be the standard pause button. However, under no circumstances would I be ok with the OS deciding for me what a proper response to that would be. Leave that up to my app to figure out.
This is exactly how it's done on other consoles. There is no OS level enforcement of a pause function. There is, however an agreed upon standard for which button should pause the game and this is enforced in the console certification process.
Since OUYA AFAIK will not have a certification process, this standard will become tougher to maintain. However if the alternative is having the OS arbitrarily decide for me how my app should pause, I'll gladly take whatever noise is added by apps not following the standard.
I'm going to echo this as well... the talk of our own pause menu showing up in the OUYA system menu is something that I would not like. That is an unnecessary middle man step and there are several cases where pause isn't exactly bring up a menu. Pulling up the system menu to access the game menu breaks the immersion of the game that you are playing.
As the two before me said, we just want a yes or no if the event has triggered, the rest should be up to us as developers.
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.
I think the fallback version is the most intuitive. But how would that work with using the OuyaController class as the event listener? A button event that must be consumed, or it falls back to displaying the system menu seems like a good idea to me.
A long hold, for instance 3 seconds, should force open the system menu. What if a game hangs, without spending too long on events or throwing runtime exceptions (seems relatively unlikely, but I've seen a lot of unlikely bad code. Could happen if it uses multiple threads for instance), then the user should be able to kill the game.
While I agree with AngryAnt for the most part, I agree with Balbi even more. As long as we're getting the messages and our app is unaffected by anything that happens in the menu (except for quitting).
I think holding the button for 3 seconds is quite long, one second would probably be plenty of time to set it apart from a press, or at the most 2 seconds.
Hi guys! We're following this discussion closely, and also having some spirited internal discussion about how this will work. Unfortunately adding a physical pause button is out of the question at this point, so we're focusing on software-only solutions.
Whatever the ultimate solution, we will avoid forcibly pausing the running game when the menu appears, or anything else that would break real-time networked games.
Using a long-press of the controller's system button is problematic, because that button already has several overloaded behaviors. A 3-second press will put it into bluetooth pairing mode, for example. We don't want to confuse players by having four different behaviors on the same button, geared off the length of the button press.
Our leading idea is for the system button to trigger a non-blocking system menu, which will include a "game options" item to open the game's own menu, if it has one. Games could also map another controller button to their menu if they want direct access. Our interface guidelines recommend the U button for this.
We're very open to feedback on this approach, or suggestions for alternatives. Thanks!
Personally I strongly disagree with having the game options in the system menu. I'd rather have the situation switched with the in-game menu taking priority with an option for the system menu and the system menu being the fallback if the developer doesn't choose a response.
Having to go through a system menu to pause a game or access options is an unneeded and immersion/flow breaking system. Pause menus should be seamless and have priority. I know i would be using the game menu way more often than the system menu.
And programming a button for direct access limits button options and breaks standardization and hence user familiarity and expectation.
The touchpad is unreliable for consistent input so that isn't really an option. There has got to be a better way. I can't stress how much i am against having my players going through the system menu.
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.
Does the three second press bluetooth pairing mode serve a purpose if the controller is already paired and connected to a console?
I understand your fright of adding multiple functions, but ps3 got away with it pretty well, no?
I just tested it... It does not. I don't think it triggers anything for 7 seconds. i think it would still be completely possible for the holding for system option.
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.
Our leading idea is for the system button to trigger a non-blocking system menu, which will include a "game options" item to open the game's own menu, if it has one. Games could also map another controller button to their menu if they want direct access. Our interface guidelines recommend the U button for this.
Not really a fan of this solution, as it pulls the user out of the game into an OUYA-specific menu, and then requires the odd behaviour of hitting another button to get to where you actually want to go. For games that involve a fair amount of popping out to a menu (RPGs for example), this could be very confusing for end-users.
Having to sacrifice a primary button to double as a menu button is equally problematic, not only for the lost button, but since it could lead to differing behaviour between games (games that are fine w/ the system menu solution use it, others require the U button).
Personally I strongly disagree with having the game options in the system menu. I'd rather have the situation switched with the in-game menu taking priority with an option for the system menu and the system menu being the fallback if the developer doesn't choose a response.
Personally I strongly disagree with having the game options in the system menu. I'd rather have the situation switched with the in-game menu taking priority with an option for the system menu and the system menu being the fallback if the developer doesn't choose a response.
Wouldn't this make the player stuck in the game if the developer hasn't done things right? I suppose it could be something that has to be done right before the OUYA team puts it up on the store. I dunno it sounds like it could lead to technical difficulties but I'm not an expert.
Whatever the ultimate solution, we will avoid forcibly pausing the running game when the menu appears, or anything else that would break real-time networked games.
Could it be optional if the game suspends or not when the home menu is brought up? Remember that a lot of the time the player doesn't actually want to do anything in a menu but just pause the game, and pausing the game (as in freezing the action in some way) must be doable with a single press without going through menus. Imagine fighting a boss and then having to pause the game and dying while going through menus. ;)
Our leading idea is for the system button to trigger a non-blocking system menu, which will include a "game options" item to open the game's own menu, if it has one. Games could also map another controller button to their menu if they want direct access. Our interface guidelines recommend the U button for this.
The U button seems like an odd choice to me, as O and U are the buttons I'd map the most common actions to. I'd rather put pause on the Y button.
Not really a fan of this solution, as it pulls the user out of the game into an OUYA-specific menu, and then requires the odd behaviour of hitting another button to get to where you actually want to go. For games that involve a fair amount of popping out to a menu (RPGs for example), this could be very confusing for end-users.
If a game involves a lot of menu management, it probably shouldn't use controller's home button for it. It's location isn't meant for ease of access, people with small hands might find themselves stretching their thumbs a lot trying to push it.
Using a long-press of the controller's system button is problematic, because that button already has several overloaded behaviors.
I understand that there may be technical hurtles to the "press/hold" solution, but it's the *only* thing that makes sense.
The interface guidelines do recommend the U button for a pause/menu function, and I've learned since entering this discussion that the U button is already mapped to the Android MENU key by default, but I think this is a bad approach, and that the guidelines should be changed.
I think there is already a 90-95% consensus around the "press/hold" solution, and even if it turns out it would be considerably more difficult for the OUYA team to implement than we first imagined, I think that for the health of the platform, for the benefit of the users, and (importantly) for the sanity of the developers, it is absolutely necessary to consider this solution in spite of its apparent difficulty.
At some level, it's not fair for us to complain, because we don't know how hard it would be to implement, but this issue is important enough for us to ignore those (valid) concerns and continue to make a fuss about it.
And while I'm certain that I'm ignorant of the actual difficulties, I can already think of a few ways to solve the problem:
~ Perhaps you could suspend the bluetooth pairing function while the controller is on, or when it's currently linked to a powered console, If the user needs to enter bluetooth pairing mode while the system is on, advise them to do a battery pull.
~ Or, perhaps you can change it so that holding "SYSTEM" and "U" (aka: the blue button) together for 3 seconds starts up the bluetooth pairing function, so that it isn't ever triggered by accident.
~ And of course, perhaps you could increase the hold to 8 seconds instead of 3 (it could probably be as high as 15 seconds and not impact user experience by much, since they don't have to do it very often).
But if none of those things are possible, even at 3 seconds there is time enough for a shorter (if less ideal) interval for the system menu. A user is very unlikely to *hold* when they mean to *press,* so the system menu could pop up after just 1 second and it wouldn't be confused with a quick press/release.
This isn't perfect because Bluetooth pairing mode would suddenly occur if the user forgets to stop holding the button after they get to the system menu, but we've all already recognized that no solution is without it's problems, and frankly, even with this potential issue, it's *still* the least bad solution. Mention it in the manual, and after accidentally doing this once or twice, most users will be trained to avoid it easily.
And I don't want to get catty, but I cannot stress enough how wrong-headed the "leading idea" of embedding the game menu in the system menu or asking devs to assign a face button to pause their game is.
It disappoints me not because it's a bad idea (although it is), it disappoints me because it's merely the easiest short-term way for OUYA to get out of this jam they've put themselves in. It's not a dev- or user-friendly solution, and it's not sustainable, because many games are going to both want all those buttons for their game, and don't want to use the system menu to pause their game
Team OUYA, *now* is the time to do this right. Now is the time to work harder to fix this than may seem fair or proper. Now is the time to take the long view. There are plenty of other seemingly more important things which can wait. This is a basic issue for a video game console, it can't have a janky non-standard solution.
The reason I am so passionate about this (and giving OUYA a hard time about it, apologies!) is because when the system is released, it is going to be subject to *intense* scrutiny by the games press.
I can imagine Kotaku or Polygon or Joystiq allowing for a few missing or unfinished features at launch, but this is the kind of basic blunder that they will *not* be kind about, and it will hurt the platform immediately out of the gate.
Not really a fan of this solution, as it pulls the user out of the game into an OUYA-specific menu, and then requires the odd behaviour of hitting another button to get to where you actually want to go. For games that involve a fair amount of popping out to a menu (RPGs for example), this could be very confusing for end-users.
If a game involves a lot of menu management, it probably shouldn't use controller's home button for it. It's location isn't meant for ease of access, people with small hands might find themselves stretching their thumbs a lot trying to push it.
Yeah, a lot of RPG's today use one of the face buttons to go to a pause/inventory menu, while the pause button just pauses the game without any menu.
+1 For press and hold, despite the controller pairing concerns it may be the best solution short of an extra button. We need a standard pause menu button which doesn't break game immersion.
If defined like any other button in the odk, a later controller iteration could include an extra physical button without breaking software.
Yeah, a lot of RPG's today use one of the face buttons to go to a pause/inventory menu, while the pause button just pauses the game without any menu.
It was just an example; while it might suit some games (that don't need every face button), it won't necessarily suit all of them, and the result will be an inconsistent placement of menus, with some dedicating a button, and others going through the system menu.
Yeah, a lot of RPG's today use one of the face buttons to go to a pause/inventory menu, while the pause button just pauses the game without any menu.
A lot of RPGs today also have the luxury of a start button that's as easily accessible as any of the face buttons. The start button on the X360 is so accessible I've lost count how many times I paused in Soul Calibur by accident. Several games on the Final Fantasy and Resident Evil games use one of the face buttons for the menu.
Although, if an additional button is to be suggested as the menu button, it should be Y. U is most likely to be used for action functions - that's the button every SNES platformer uses for fire/attack!
How about a middle-ground solution: have the pause button open the ouya's menu, however have it always open on the game's own menu by default, leaving the OUYA's dashboard menus accessible by pressing L1/R1, and allow the menus to be styled using something like a CSS file, so the menus won't feel out of place in the game
Personally I strongly disagree with having the game options in the system menu. I'd rather have the situation switched with the in-game menu taking priority with an option for the system menu and the system menu being the fallback if the developer doesn't choose a response.
Wouldn't this make the player stuck in the game if the developer hasn't done things right? I suppose it could be something that has to be done right before the OUYA team puts it up on the store. I dunno it sounds like it could lead to technical difficulties but I'm not an expert. 9
That is definitely not the way I would go, but I would find it a far better solution than the leading idea of system menu -> game menu. Just trying to emphasize that going through the system menu to get to the in-game menu is definitely trying to climb a wall that you can just walk around. There are tons of problems... but I'd rather that than system to game... *shivers*
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.
+1 For press and hold, despite the controller pairing concerns it may be the best solution short of an extra button. We need a standard pause menu button which doesn't break game immersion.
If defined like any other button in the odk, a later controller iteration could include an extra physical button without breaking software.
If a hold cannot be used, could it simply give a button event? If the event is not consumed, the OUYA menu pops up. If it is, the game can present its own menu, pause the game or handle it however they like? Then design guidelines could be that it should be used for pausing and presenting a menu, preferably with an item to access the OUYA menu.
I would much rather have a menu that allows me access to the system menu from a menu item, than a system menu that allows me access to the game menu from a menu item.
I'm also in the "press and hold" fan club. Not a fan of the system menu offering an app-provided menu item to go to an in-app menu. I'm currently developing Windows 8 games and the use of the Settings charm (the swipe menu from the right) to access game settings jolts the player out of the game experience.
If there is already press and hold on the system button to put the controller into pairing mode, could it be possible that press and hold will bring up the OUYA system menu and an option on that menu is "Pair controller" (or other wording) to put the controller into pairing mode?
If the controller is not paired: - press and hold for several seconds will initiate pairing. This is fine because the OUYA console will not be receiving any button events from the controller anyway.
If the controller is paired: - press and hold for several seconds will show the system menu. An option on this menu will be "Pair controller".
This will be along with the app receiving press and release events for the system button, and receiving notifications of the system menu being shown and removed. There should also be an API for detecting if a system dialog is currently visible.
+1 For press and hold, despite the controller pairing concerns it may be the best solution short of an extra button. We need a standard pause menu button which doesn't break game immersion.
If defined like any other button in the odk, a later controller iteration could include an extra physical button without breaking software.
I agree with this and with nobleRobot's sentiment. It's dissappointing the controller doesn't have a standard pause button. But it can still be added later on with a new controller. So for the moment just pressing the main button triggers a pause menu call (letting the game decide to pause or not). Then a later controller fix can add a new physical button.
Hi guys! We're following this discussion closely, and also having some spirited internal discussion about how this will work. Unfortunately adding a physical pause button is out of the question at this point, so we're focusing on software-only solutions.
Whatever the ultimate solution, we will avoid forcibly pausing the running game when the menu appears, or anything else that would break real-time networked games.
Using a long-press of the controller's system button is problematic, because that button already has several overloaded behaviors. A 3-second press will put it into bluetooth pairing mode, for example. We don't want to confuse players by having four different behaviors on the same button, geared off the length of the button press.
Our leading idea is for the system button to trigger a non-blocking system menu, which will include a "game options" item to open the game's own menu, if it has one. Games could also map another controller button to their menu if they want direct access. Our interface guidelines recommend the U button for this.
We're very open to feedback on this approach, or suggestions for alternatives. Thanks!
Right.. Forgot about the bluetooth pairing.
I imagine a lot of the users out there are used to long-hold of the system button to bring up the system menu (thanks Sony and Microsoft). Therefore to avoid interfering with bluetooth pairing, it's probably best to bring up that system menu right away so the users are not tempted to hold that button down longer than they need to.
With that in mind, it might be best to, at the very least, report the button press before throwing up the system menu.
At least with that, a pause screen can be brought up behind it simultaneously. As devs, we'll just have to get used to calling it "System/Pause".
~ Perhaps you could suspend the bluetooth pairing function while the controller is on, or when it's currently linked to a powered console, If the user needs to enter bluetooth pairing mode while the system is on, advise them to do a battery pull.
~ Or, perhaps you can change it so that holding "SYSTEM" and "U" (aka: the blue button) together for 3 seconds starts up the bluetooth pairing function, so that it isn't ever triggered by accident.
~ And of course, perhaps you could increase the hold to 8 seconds instead of 3 (it could probably be as high as 15 seconds and not impact user experience by much, since they don't have to do it very often).
But if none of those things are possible, even at 3 seconds there is time enough for a shorter (if less ideal) interval for the system menu. A user is very unlikely to *hold* when they mean to *press,* so the system menu could pop up after just 1 second and it wouldn't be confused with a quick press/release.
This isn't perfect because Bluetooth pairing mode would suddenly occur if the user forgets to stop holding the button after they get to the system menu, but we've all already recognized that no solution is without it's problems, and frankly, even with this potential issue, it's *still* the least bad solution. Mention it in the manual, and after accidentally doing this once or twice, most users will be trained to avoid it easily.
Bluetooth is bi-directional. As such, I suspect the controllers themselves are programmed directly with this functionality and can't be changed (i.e. there's no way of shutting it off without completely recalling and re-programming the controller. Which is probably not a realistic or cost effective thing to do this close to manufacturing and release).
At the end of the day, the whole pause issue is probably more of a big deal to certain developers than the actual people who play their games.
Will a player really dismiss a great game because they dislike the way it shares it's pause screen with the system menu? I somehow doubt that.
If the controller is not paired: - press and hold for several seconds will initiate pairing. This is fine because the OUYA console will not be receiving any button events from the controller anyway.
If the controller is paired: - press and hold for several seconds will show the system menu. An option on this menu will be "Pair controller".
This will be along with the app receiving press and release events for the system button, and receiving notifications of the system menu being shown and removed. There should also be an API for detecting if a system dialog is currently visible.
Because of the way bluetooth works, I suspect this isn't possible. The controllers and the consoles have their own independent blue tooth pairing mode so a secure "handshake" can be established. The controller is likely programmed to clear its pairing state (forgets about the console) and poll for a nearby bluetooth device when the system button is pressed and hold (which could be your tablet or your PC or your OUYA if they are also in pairing mode).
The console itself has no ability to override the behavior of that process on another device.
So even if the pairing is detected by the console, it can't tell the controller to not start it's pairing and re-poll.
Wouldnt it be great if the system button normaly brings the OUYA menu up and the dev can change this to his own created menu but is forced to include the OUYA menu in some way
Wouldnt it be great if the system button normaly brings the OUYA menu up and the dev can change this to his own created menu but is forced to include the OUYA menu in some way
I thought about that and was going to suggest that. But it's hard to "force" a custom screen to include the OUYA menu. The issue compounds when localization enters the equation.
If it were part of a certification process, then it could be added to the approval checklist. But as of yet, they've not really given an indication as to what their vetting process is going to be like, if they have one at all.
That said, it's probably good for the system to give the user a way of escaping the application independent of any developer code. You might want to escape at the title screen (which many developers wouldn't build "pause" logic into).
To build on your idea... One way it might work would be to allow the background of the system menu to be transparent or be customized in some way, and allow the font to change too. Then pop it up like a "toast" notification that displays the menu options horizontally, and exits out of the system menu state if the system button is pressed again, or the "up" or "down" direction is pressed on the left analog or d-pad. Then it would act like a Blu-ray menu, which might be a more appealing compromise.
Comments
I'm all for designating one tap on the OS button to be the standard pause button. However, under no circumstances would I be ok with the OS deciding for me what a proper response to that would be. Leave that up to my app to figure out.
This is exactly how it's done on other consoles. There is no OS level enforcement of a pause function. There is, however an agreed upon standard for which button should pause the game and this is enforced in the console certification process.
Since OUYA AFAIK will not have a certification process, this standard will become tougher to maintain. However if the alternative is having the OS arbitrarily decide for me how my app should pause, I'll gladly take whatever noise is added by apps not following the standard.
Game developer, AI specialist, Unity expert
http://AngryAnt.com
Here's what I want as a developer and as clear as I can make it:
Treat the system button like any other boolean button on the controller. This way I can use it how I see fit.
If it happens to open the System Menu after holding for X seconds (still the best solution to no dedicated start button, which is fine), I don't care
Give me a way to determine if the system menu is still up on my screen
With the above information, I can tailor my game's user experience to how I want it. At no point should the OUYA system tell my game what to do (exception being force quit of course).
As the two before me said, we just want a yes or no if the event has triggered, the rest should be up to us as developers.
Founder of ReachingPerfection.com
A long hold, for instance 3 seconds, should force open the system menu. What if a game hangs, without spending too long on events or throwing runtime exceptions (seems relatively unlikely, but I've seen a lot of unlikely bad code. Could happen if it uses multiple threads for instance), then the user should be able to kill the game.
Whatever the ultimate solution, we will avoid forcibly pausing the running game when the menu appears, or anything else that would break real-time networked games.
Using a long-press of the controller's system button is problematic, because that button already has several overloaded behaviors. A 3-second press will put it into bluetooth pairing mode, for example. We don't want to confuse players by having four different behaviors on the same button, geared off the length of the button press.
Our leading idea is for the system button to trigger a non-blocking system menu, which will include a "game options" item to open the game's own menu, if it has one. Games could also map another controller button to their menu if they want direct access. Our interface guidelines recommend the U button for this.
We're very open to feedback on this approach, or suggestions for alternatives. Thanks!
I understand your fright of adding multiple functions, but ps3 got away with it pretty well, no?
Game developer, AI specialist, Unity expert
http://AngryAnt.com
Having to go through a system menu to pause a game or access options is an unneeded and immersion/flow breaking system. Pause menus should be seamless and have priority. I know i would be using the game menu way more often than the system menu.
And programming a button for direct access limits button options and breaks standardization and hence user familiarity and expectation.
The touchpad is unreliable for consistent input so that isn't really an option. There has got to be a better way. I can't stress how much i am against having my players going through the system menu.
Founder of ReachingPerfection.com
Founder of ReachingPerfection.com
Having to sacrifice a primary button to double as a menu button is equally problematic, not only for the lost button, but since it could lead to differing behaviour between games (games that are fine w/ the system menu solution use it, others require the U button). Agreed.
Cheers! :9
The interface guidelines do recommend the U button for a pause/menu function, and I've learned since entering this discussion that the U button is already mapped to the Android MENU key by default, but I think this is a bad approach, and that the guidelines should be changed.
I think there is already a 90-95% consensus around the "press/hold" solution, and even if it turns out it would be considerably more difficult for the OUYA team to implement than we first imagined, I think that for the health of the platform, for the benefit of the users, and (importantly) for the sanity of the developers, it is absolutely necessary to consider this solution in spite of its apparent difficulty.
At some level, it's not fair for us to complain, because we don't know how hard it would be to implement, but this issue is important enough for us to ignore those (valid) concerns and continue to make a fuss about it.
And while I'm certain that I'm ignorant of the actual difficulties, I can already think of a few ways to solve the problem:
~ Perhaps you could suspend the bluetooth pairing function while the controller is on, or when it's currently linked to a powered console, If the user needs to enter bluetooth pairing mode while the system is on, advise them to do a battery pull.
~ Or, perhaps you can change it so that holding "SYSTEM" and "U" (aka: the blue button) together for 3 seconds starts up the bluetooth pairing function, so that it isn't ever triggered by accident.
~ And of course, perhaps you could increase the hold to 8 seconds instead of 3 (it could probably be as high as 15 seconds and not impact user experience by much, since they don't have to do it very often).
But if none of those things are possible, even at 3 seconds there is time enough for a shorter (if less ideal) interval for the system menu. A user is very unlikely to *hold* when they mean to *press,* so the system menu could pop up after just 1 second and it wouldn't be confused with a quick press/release.
This isn't perfect because Bluetooth pairing mode would suddenly occur if the user forgets to stop holding the button after they get to the system menu, but we've all already recognized that no solution is without it's problems, and frankly, even with this potential issue, it's *still* the least bad solution. Mention it in the manual, and after accidentally doing this once or twice, most users will be trained to avoid it easily.
And I don't want to get catty, but I cannot stress enough how wrong-headed the "leading idea" of embedding the game menu in the system menu or asking devs to assign a face button to pause their game is.
It disappoints me not because it's a bad idea (although it is), it disappoints me because it's merely the easiest short-term way for OUYA to get out of this jam they've put themselves in. It's not a dev- or user-friendly solution, and it's not sustainable, because many games are going to both want all those buttons for their game, and don't want to use the system menu to pause their game
Team OUYA, *now* is the time to do this right. Now is the time to work harder to fix this than may seem fair or proper. Now is the time to take the long view. There are plenty of other seemingly more important things which can wait. This is a basic issue for a video game console, it can't have a janky non-standard solution.
The reason I am so passionate about this (and giving OUYA a hard time about it, apologies!) is because when the system is released, it is going to be subject to *intense* scrutiny by the games press.
I can imagine Kotaku or Polygon or Joystiq allowing for a few missing or unfinished features at launch, but this is the kind of basic blunder that they will *not* be kind about, and it will hurt the platform immediately out of the gate.
If defined like any other button in the odk, a later controller iteration could include an extra physical button without breaking software.
Although, if an additional button is to be suggested as the menu button, it should be Y. U is most likely to be used for action functions - that's the button every SNES platformer uses for fire/attack!
How about a middle-ground solution: have the pause button open the ouya's menu, however have it always open on the game's own menu by default, leaving the OUYA's dashboard menus accessible by pressing L1/R1, and allow the menus to be styled using something like a CSS file, so the menus won't feel out of place in the game
Founder of ReachingPerfection.com
I would much rather have a menu that allows me access to the system menu from a menu item, than a system menu that allows me access to the game menu from a menu item.
If there is already press and hold on the system button to put the controller into pairing mode, could it be possible that press and hold will bring up the OUYA system menu and an option on that menu is "Pair controller" (or other wording) to put the controller into pairing mode?
If the controller is not paired:
- press and hold for several seconds will initiate pairing. This is fine because the OUYA console will not be receiving any button events from the controller anyway.
If the controller is paired:
- press and hold for several seconds will show the system menu. An option on this menu will be "Pair controller".
This will be along with the app receiving press and release events for the system button, and receiving notifications of the system menu being shown and removed. There should also be an API for detecting if a system dialog is currently visible.
So for the moment just pressing the main button triggers a pause menu call (letting the game decide to pause or not). Then a later controller fix can add a new physical button.
Check out Pig Eat Ball on Facebook!
I imagine a lot of the users out there are used to long-hold of the system button to bring up the system menu (thanks Sony and Microsoft). Therefore to avoid interfering with bluetooth pairing, it's probably best to bring up that system menu right away so the users are not tempted to hold that button down longer than they need to.
With that in mind, it might be best to, at the very least, report the button press before throwing up the system menu.
At least with that, a pause screen can be brought up behind it simultaneously. As devs, we'll just have to get used to calling it "System/Pause".
At the end of the day, the whole pause issue is probably more of a big deal to certain developers than the actual people who play their games.
Will a player really dismiss a great game because they dislike the way it shares it's pause screen with the system menu? I somehow doubt that.
The console itself has no ability to override the behavior of that process on another device.
So even if the pairing is detected by the console, it can't tell the controller to not start it's pairing and re-poll.
the dev can change this to his own created menu but is forced to include the OUYA menu in some way
If it were part of a certification process, then it could be added to the approval checklist. But as of yet, they've not really given an indication as to what their vetting process is going to be like, if they have one at all.
That said, it's probably good for the system to give the user a way of escaping the application independent of any developer code. You might want to escape at the title screen (which many developers wouldn't build "pause" logic into).
To build on your idea... One way it might work would be to allow the background of the system menu to be transparent or be customized in some way, and allow the font to change too. Then pop it up like a "toast" notification that displays the menu options horizontally, and exits out of the system menu state if the system button is pressed again, or the "up" or "down" direction is pressed on the left analog or d-pad. Then it would act like a Blu-ray menu, which might be a more appealing compromise.