Good solution, Nick, and team OUYA! I must admit, I agree that the system button is incredibly overloaded, but it's hard to disagree that this is the best way. Thanks!
I've got an update on this, with some good and bad news.
As I was trying to implement this, I was working under the assumption the system button worked the same way as a normal button would. I discovered that because of the function overloading on it, the dev kit controllers send the up and down key events at the same time.
This means that our press and hold solution isn't going to work with these controllers.
But we came up with a solution we think will make everyone happy. We can fix that in the future runs of controllers with a controller firmware update, but to avoid leaving all of you with dev kit controllers behind, we're implementing a secondary method of differentiating system button actions: a double tap will open the system menu.
Dev kit controller: 1x short press -> 1x MENU keycode (passed to app) -> game menu 2x short press -> 2x MENU keycode (not passed to app)-> system menu
Retail controller: 1x short press -> 1x MENU keycode (passed to app) -> game menu 2x short press -> 2x MENU keycode (not passed to app) -> system menu 1x long press -> 1x HOME keycode -> system menu
I've got an update on this, with some good and bad news.
As I was trying to implement this, I was working under the assumption the system button worked the same way as a normal button would. I discovered that because of the function overloading on it, the dev kit controllers send the up and down key events at the same time.
This means that our press and hold solution isn't going to work with these controllers.
But we came up with a solution we think will make everyone happy. We can fix that in the future runs of controllers with a controller firmware update, but to avoid leaving all of you with dev kit controllers behind, we're implementing a secondary method of differentiating system button actions: a double tap will open the system menu.
Dev kit controller: 1x short press -> 1x MENU keycode (passed to app) -> game menu 2x short press -> 2x MENU keycode (not passed to app)-> system menu
Retail controller: 1x short press -> 1x MENU keycode (passed to app) -> game menu 2x short press -> 2x MENU keycode (not passed to app) -> system menu 1x long press -> 1x HOME keycode -> system menu
Thanks for the update Nick. As a dev I think this is a perfect solution. :) Will the long press be passed to the app, in order to pause if necessary? And would it be possible to manually check for 2x short press to handle necessary actions in app?
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.
In order to pass the MENU keycode to the app on 1 short press but not on 2 short presses, the keycode will have to be delayed until a timeout has occurred waiting for the second short press. Only then can you safely send the keycode for the 1 short press to the app. How long does it wait for the second press before realising it is only a single short press?
Thanks for the update Nick. As a dev I think this is a perfect solution. :) Will the long press be passed to the app, in order to pause if necessary? And would it be possible to manually check for 2x short press to handle necessary actions in app?
Long press on the retail controllers (and double taps on either) launch the system's menu, and will cause an onPause() event in your Activity that you can use to respond accordingly.
The single tap will just appear as a key event (keycode_menu)
A double tap always starts with a single tap. What makes it a double tap is that the first single tap is quickly followed by another tap. To determine if it a double tap and not a single tap, there must be a period of time waiting for the second tap.
I think what you are saying is that a double tap will not result in the keycode_menu key event being sent to the app. This means the key event must be delayed by the double tap time period in order for it to be detected as a single tap and not a double tap. Is that correct?
Sounds great! And it seems to me that single-press should always be passed and it will pause most games and bring up the menu, then if they happen to press again (within the time limit), it will load the system menu, leaving your game in the menu state that you wanted regardless of single or double press just in case they come back to the game.
tl;dr No matter what kind of press, you want to launch the in-game menu (in most cases)
A double tap always starts with a single tap. What makes it a double tap is that the first single tap is quickly followed by another tap. To determine if it a double tap and not a single tap, there must be a period of time waiting for the second tap.
I think what you are saying is that a double tap will not result in the keycode_menu key event being sent to the app. This means the key event must be delayed by the double tap time period in order for it to be detected as a single tap and not a double tap. Is that correct?
Precisely. When the system key is pressed, it holds onto the first press for 300ms.
We tested it internally quite a bit, and 300ms seemed like a good balance between usability, and latency for the menu keyevent, but we're definitely willing to tweak that based on feedback :)
A double tap always starts with a single tap. What makes it a double tap is that the first single tap is quickly followed by another tap. To determine if it a double tap and not a single tap, there must be a period of time waiting for the second tap.
I think what you are saying is that a double tap will not result in the keycode_menu key event being sent to the app. This means the key event must be delayed by the double tap time period in order for it to be detected as a single tap and not a double tap. Is that correct?
Precisely. When the system key is pressed, it holds onto the first press for 300ms.
We tested it internally quite a bit, and 300ms seemed like a good balance between usability, and latency for the menu keyevent, but we're definitely willing to tweak that based on feedback :)
Awesome, that answers my question Nick. :) Thanks a ton.
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.
If you're still questioning 300ms as the ideal duration, you can always have it be a user setting (similar to how PCs let you change the double-click time).
If you're still questioning 300ms as the ideal duration, you can always have it be a user setting (similar to how PCs let you change the double-click time).
Also a possibility :) (though it would most likely be included later on).
Sounds great. I would keep the double tap around for the long haul, and mention it in the system manual. A quick access double tap is great for "Generation Now" whom is too impatient to wait for a long press. Ok, so thats most of us here too lol.
Sounds great. I would keep the double tap around for the long haul, and mention it in the system manual. A quick access double tap is great for "Generation Now" whom is too impatient to wait for a long press. Ok, so thats most of us here too lol.
Yep, our plan was to keep the existing functionality and just add the long press to the firmware on the new controllers
Dev kit controller: 1x short press -> 1x MENU keycode (passed to app) -> game menu 2x short press -> 2x MENU keycode (not passed to app)-> system menu
Retail controller: 1x short press -> 1x MENU keycode (passed to app) -> game menu 2x short press -> 2x MENU keycode (not passed to app) -> system menu 1x long press -> 1x HOME keycode -> system menu
I'm glad that you've decided to stick with the "tap to pause, hold for home" behavior, butare we still going to get a customisable system menu? I know of a few systems (emulators, namely) that could use having both features, such as Mupen64, the N64 emulator that's currently being ported on OUYA. The N64 controller had a pause button in the middle and the system button is probably going to fill that role, but since it's an emulator, it's also going to need its own system menu. Having a customizable menu screen would certainly help integrating this in a consistant and elegant way with the system.
The real issue I'm having with the current state of the controller that haven't been mentianned at all in this thread is the lack of a select button, while is just as important, if not more so than the pause button as it serves as a major option button in many games (think about Legend of Zelda on the SNES where it's used to open the inventory, while pause simply opens the save menu). This is something OUYA devs could probably deal with, but emulator devs may have an harder time adapting to this, especially when the emulated console uses a more traditional input scheme because they can't change the button layout of the game they are meant to support. The touchpad might be a viable alternative, where one could check which side of it is being pressed, but I've been left under the impression that it works like a trackpad and does not actually sends the absolute position of the user's finger. Not leaving any way for the developpers to adapt conventional controller layouts for the ouya controller might prove problematic eventually.
PS : There should be some kind of fading when the Home/System/Ouya button is being held to let the user know that it actually does something. My brother spent months cluttering his iPhone's the RAM with minimised applications because he had to way to know that a double tap opens the system manager. It's wasn't even written in the instruction booklet. This should be made evident to the end-user, as few ever bother to read those and word of mouth isn't exactly the best way to teach users how to use your system.
Dev kit controller: 1x short press -> 1x MENU keycode (passed to app) -> game menu 2x short press -> 2x MENU keycode (not passed to app)-> system menu
Retail controller: 1x short press -> 1x MENU keycode (passed to app) -> game menu 2x short press -> 2x MENU keycode (not passed to app) -> system menu 1x long press -> 1x HOME keycode -> system menu
Dev kit controller: 1x short press -> 1x MENU keycode (passed to app) -> game menu 2x short press -> 2x MENU keycode (not passed to app)-> system menu
Retail controller: 1x short press -> 1x MENU keycode (passed to app) -> game menu 2x short press -> 2x MENU keycode (not passed to app) -> system menu 1x long press -> 1x HOME keycode -> system menu
As of today's OTA, this is officially in :D
WOOHOO!!!! Thanks nick. Time to go play with it.
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.
No matter what I try, it seems that OuyaController.getButton(OuyaController.BUTTON_MENU) will always return false no matter what. Am I the only one bothered with this issue ?
No matter what I try, it seems that OuyaController.getButton(OuyaController.BUTTON_MENU) will always return false no matter what. Am I the only one bothered with this issue ?
I'm using the latest 1.0.0 ODK.
The menu button's down and up events are going to happen faster than the majority of games are going to be polling. They happen directly after eachother, and there's no concept of "holding" the menu button. That means you'll either have to detect it when it's pressed in your onKey_ events, instead of passively with the getButton() call.
I'll update the controller docs to make that clearer, sorry!
Will there still be a way to customize the system menu, for those who need it?
The whole point of the changes they have made was to not require the app to make changes to the system menu. What need do you have to change the system menu?
Will there still be a way to customize the system menu, for those who need it?
The whole point of the changes they have made was to not require the app to make changes to the system menu. What need do you have to change the system menu?
As I said in a previous post, that would come pretty handy for emulators, who are likely to need both a start button and an external menu. Since you can't use the touchpad as a touch button just yet (I've been told that relative touch input would be added in the final firmware of the controllers), you can't keep the pause button for that. You'd need a way to use the same button both as a pause button for the game you're running and as a global menu for the emulator itself.
Will there still be a way to customize the system menu, for those who need it?
The whole point of the changes they have made was to not require the app to make changes to the system menu. What need do you have to change the system menu?
As I said in a previous post, that would come pretty handy for emulators, who are likely to need both a start button and an external menu. Since you can't use the touchpad as a touch button just yet (I've been told that relative touch input would be added in the final firmware of the controllers), you can't keep the pause button for that. You'd need a way to use the same button both as a pause button for the game you're running and as a global menu for the emulator itself.
Perhaps some emulators could use the triggers or L3/R3 for start and select? Just a thought.
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
Comments
Yep! We will most likely include the deviceId with the Intent :)
As I was trying to implement this, I was working under the assumption the system button worked the same way as a normal button would. I discovered that because of the function overloading on it, the dev kit controllers send the up and down key events at the same time.
This means that our press and hold solution isn't going to work with these controllers.
But we came up with a solution we think will make everyone happy. We can fix that in the future runs of controllers with a controller firmware update, but to avoid leaving all of you with dev kit controllers behind, we're implementing a secondary method of differentiating system button actions: a double tap will open the system menu.
1x short press -> 1x MENU keycode (passed to app) -> game menu
2x short press -> 2x MENU keycode (not passed to app)-> system menu
Retail controller:
1x short press -> 1x MENU keycode (passed to app) -> game menu
2x short press -> 2x MENU keycode (not passed to app) -> system menu
1x long press -> 1x HOME keycode -> system menu
Founder of ReachingPerfection.com
The single tap will just appear as a key event (keycode_menu)
Founder of ReachingPerfection.com
The real issue I'm having with the current state of the controller that haven't been mentianned at all in this thread is the lack of a select button, while is just as important, if not more so than the pause button as it serves as a major option button in many games (think about Legend of Zelda on the SNES where it's used to open the inventory, while pause simply opens the save menu). This is something OUYA devs could probably deal with, but emulator devs may have an harder time adapting to this, especially when the emulated console uses a more traditional input scheme because they can't change the button layout of the game they are meant to support. The touchpad might be a viable alternative, where one could check which side of it is being pressed, but I've been left under the impression that it works like a trackpad and does not actually sends the absolute position of the user's finger.
Not leaving any way for the developpers to adapt conventional controller layouts for the ouya controller might prove problematic eventually.
PS : There should be some kind of fading when the Home/System/Ouya button is being held to let the user know that it actually does something. My brother spent months cluttering his iPhone's the RAM with minimised applications because he had to way to know that a double tap opens the system manager. It's wasn't even written in the instruction booklet. This should be made evident to the end-user, as few ever bother to read those and word of mouth isn't exactly the best way to teach users how to use your system.
Founder of ReachingPerfection.com
The menu button's down and up events are going to happen faster than the majority of games are going to be polling. They happen directly after eachother, and there's no concept of "holding" the menu button.
That means you'll either have to detect it when it's pressed in your onKey_ events, instead of passively with the getButton() call.
I'll update the controller docs to make that clearer, sorry!