Hmm this limits the posibilitys for development ... i like the idea of a card system if you want to customize the menu maybe include and inventory for fast access and another menu for other in game opions you could reserve d-pad up for the OUYA menu and the other d-pad buttons to switch between menus
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).
This is what I was talking about when I mentioned the unknowable difficulties of our favorite solution, but we already know from the unboxing video that the d-pad and triggers are still being finalized, and as far as I know, all it should take to change any embedded features is to flash a new firmware, which I'm sure wouldn't be easy once the controllers are all packed and ready to ship, but I suspect that even if the controllers are currently being manufactured, their firmware haven't been flashed yet. I'd like to think that it's not too late.
And again, it can still be done even in the 3 second window, without changing the controller's firmware.
I do agree with you that trusting every dev to put the OUYA menu in their own menus (without giving users a way to force the issue) is a bad idea, for all the reasons you cite.
Single press = game-specific pause menu Double press = OUYA menu
Surely a software-only solution can be devised where the call for the game menu on "key up" can be delayed by enough time to reasonably allow for the button to be pressed a second time, but short enough so that it wouldn't feel like there's a delay for the user if they only press it once.
Devs can be encouraged to put a link to the system menu in their own menus as well, so the double-press can simply be a way to *force* a game to go to the system menu.
And again, this would be a fallback situation, where if there's no game-specific menu, a single press would bring up the OUYA menu.
I still think press/hold is worth the trouble, but this can also work, and would also be a future-proof solution so a future controller can add a start button without breaking compatibility.
Lots of internal discussion over this topic! We really appreciate the input from this thread :)
Gotta love a team that takes what the community has to say to heart... and communicates that they are listening. All of your guys' effort is much appreciated. :) I think it is safe to say that everyone here wants to see this succeed. Thanks for all the time, effort, and dedication that you guys put into this.
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.
Lots of internal discussion over this topic! We really appreciate the input from this thread :)
Wonderful! I agree with GodlyPerfection, in that just having the team's ear on issues like this is a show of how open and engaged OUYA is, and how hard they are working to encourage and promote the dev community.
Lots of internal discussion over this topic! We really appreciate the input from this thread :)
Gotta love a team that takes what the community has to say to heart... and communicates that they are listening. All of your guys' effort is much appreciated. :) I think it is safe to say that everyone here wants to see this succeed. Thanks for all the time, effort, and dedication that you guys put into this.
Indeed! It's great to see that you guys are listening.
I'd like to add a little tweak to the "tap to pause, hold to bring up OUYA menu": Perhaps you could add some developer guidelines that state in your pause menu, you should add some text letting the user now how to access the system menu. Or (even better) have the OS present it's own little widget at one of eight (developer-selected) positions on screen that fades out after a few seconds (kind of like how the achievement notifications on Xbox appear).
What if a pause button was added in the consumer version of the controller and dev units have to hold/press? Kinda lame for devs, but just having the button itself is the most ideal and accessible solution to players, and since it's not in production yet, it's kinda not too late...
Indeed! It's great to see that you guys are listening.
I'd like to add a little tweak to the "tap to pause, hold to bring up OUYA menu": Perhaps you could add some developer guidelines that state in your pause menu, you should add some text letting the user now how to access the system menu. Or (even better) have the OS present it's own little widget at one of eight (developer-selected) positions on screen that fades out after a few seconds (kind of like how the achievement notifications on Xbox appear).
I am against this solution. leaving the dashboard menu fallback up to the developer means needing an extra step on the game certification process to ensure that the game allows to bring up the dashboard menu at any time. And of course, a glitch could prevent the player from accessing the dashboard at all.
What if a pause button was added in the consumer version of the controller and dev units have to hold/press? Kinda lame for devs, but just having the button itself is the most ideal and accessible solution to players, and since it's not in production yet, it's kinda not too late...
I don't think a major change on the controller is possible without delaying the console at this point. Also, if the consumer version ships with a different controller, games will not be ready for it at launch.
So what's the latest direction of that discussion?
I'm going to hazard a guess that some element of the discussion is "Wish we'd added that one extra button back at the beginning."
My guess is they're drawing straws to see who has to implement the long press system menu button while still passing the system button down event to the running application :)
My guess is they're drawing straws to see who has to implement the long press system menu button while still passing the system button down event to the running application :)
What does the system menu look like (I didn't order the dev kit, so I haven't seen it yet)? Would there be room for a game menu alongside the system menu? I.e. could the game supply menu items that should be added to the system menu in form of an XML file like the android files, or an interface the game could programmatically add menu items to.
If so, there would be no need for the game menu button in the system menu, cause it could contain one menu on the left (OUYA) and one on the right (game), or something similar.
I'm guessing some devs might find it limiting to have to use ordinary menu items, instead of fancy graphics for their menus. But most of the game supplied items should probably close the OUYA menu and send an event to the game. Thus they can add the most important choices (leave game, settings, help) to the initial menu, and use fancy looking menus for settings if that is chosen, etc.
What does the system menu look like (I didn't order the dev kit, so I haven't seen it yet)? Would there be room for a game menu alongside the system menu? I.e. could the game supply menu items that should be added to the system menu in form of an XML file like the android files, or an interface the game could programmatically add menu items to.
If so, there would be no need for the game menu button in the system menu, cause it could contain one menu on the left (OUYA) and one on the right (game), or something similar.
I'm guessing some devs might find it limiting to have to use ordinary menu items, instead of fancy graphics for their menus. But most of the game supplied items should probably close the OUYA menu and send an event to the game. Thus they can add the most important choices (leave game, settings, help) to the initial menu, and use fancy looking menus for settings if that is chosen, etc.
From what I gather, this seems to be the whole idea. Regardless, I think the dashboard menu could also have an API to customize styling so the menu can match the style of the game
But you guys are thinking too traditionally with menus. What about a menu system that requires images? Or an example model of the changes as the changes are being applied? Would there be options in the menu API for sliders, color picking, gallery style icon selection, option buttons, checkmarks, screen adjustment, etc. Every game is different so the menu should be handled in-game.
From what I understand, what the OUYA team is proposing was an option that says "In-Game Options" or something of the like and when you select that option, it closes the system menu and then sends an "In-Games Options selected" event for the game to respond to and do whatever it so chooses with said event. Basically the system menu would act as an extra screen in order to get to the In-Game menu.
And for those saying that if your menu is used extremely often then perhaps changing it to a different button is better, I disagree. The "pause" button has become a staple for important general access to settings. Sure more in-game instance related materials (like Elder Scrolls inventory/stats/etc.) work great on a different button, but what about a game where everything is centralized on the menu. For example an asynchronous game where the menu contains a list of each available game with very few settings that are in the corner for players to just tick when they need to while looking through the game list. It isn't a main menu, it is used to just change the state of the field to match the selected game's state for fluidity. This system is great for games that use very similar data from one game to another.
Here is a better example. An asynchronous chess game, where pressing pause allows you to pull up a list of games you are currently active in. Selecting a game shifts the pieces on the board behind the menu rather than having to go back to a main menu of sorts. Each game in the game list would provide details like the profile image of the opposing player, number of turns, the color you are playing as, perhaps icons representing pieces already taken, etc. A system menu modifications you guys are suggesting would be nearly impossible to replicate this perfectly for what the dev wants to achieve.
As for the system menu acting as a middle man, the system menu now becomes a HUGE extra step. In a game like above, I should be able to make a move, pull up the menu, select a game, make a new move in that game, and repeat for all games that I still have to move. The system menu makes this into a heavily convoluted process, when it should be quick and simple to swap between games quickly.
And that is just simple chess. Perhaps we increase its complexity to a tactics RPG. Now most buttons are probably tied to hotkeys. Sure, the menu is used often and would work great on a standard button. But in a more complex game, there are other actions that are used even more often than the menu itself and hence belong on the other buttons. Despite the frequent usage of the menu, it is the lowest on the usage list of actions that require a mapping and hence gets relegate to the start button because that is the least used button. So sure [U] can be used as a menu for a lot of games, but if each character in a tactical RPG has 4 standard actions it would make more sense to have those 4 face buttons hotkey to each action. The bumpers are used for switching characters in the queue (one for forward/one for back), the triggers for zooming in and out, the sticks to toggle two different settings (like switching focused team like allies or enemies; or switching between top down and perspective projection), the d-pad/left stick axis used for menu navigation, and the right stick axis for panning/orbiting. All that is left for the menu (that brings up your asynchronous game list) is what would be the pause button.
Going through the system menu turns what is supposed to be a fluid process of commit actions, pull up game list, select game, repeat... extremely cumbersome.
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.
And that is just simple chess. Perhaps we increase its complexity to a tactics RPG. Now most buttons are probably tied to hotkeys. Sure, the menu is used often and would work great on a standard button. But in a more complex game, there are other actions that are used even more often than the menu itself and hence belong on the other buttons. Despite the frequent usage of the menu, it is the lowest on the usage list of actions that require a mapping and hence gets relegate to the start button because that is the least used button. So sure [U] can be used as a menu for a lot of games, but if each character in a tactical RPG has 4 standard actions it would make more sense to have those 4 face buttons hotkey to each action. The bumpers are used for switching characters in the queue (one for forward/one for back), the triggers for zooming in and out, the sticks to toggle two different settings (like switching focused team like allies or enemies; or switching between top down and perspective projection), the d-pad/left stick axis used for menu navigation, and the right stick axis for panning/orbiting. All that is left for the menu (that brings up your asynchronous game list) is what would be the pause button.
Aren't tactics RPGs by law, turn-based, therefore denying any requirement for quick access to anything? Just saying, I have not heard or can even imagine a game actually focused on tactics that requires directly controlling several characters in real time.
The closest thing I can think of are RTS games, and the two good ones I can think of that are in consoles - Halo Wars and the N64 Command & Conquer - controll very well without resorting to the pause button for game-critical functionality.
But you guys are thinking too traditionally with menus. What about a menu system that requires images? Or an example model of the changes as the changes are being applied? Would there be options in the menu API for sliders, color picking, gallery style icon selection, option buttons, checkmarks, screen adjustment, etc. Every game is different so the menu should be handled in-game.
And you are assuming everything MUST be in the pause menu. Do you constantly adjust brightness, character styling, screen, during the game? If you don't want to use the menu functionality and implement your own, don't use the menu functionality ani implement your own. The dashboard menu would still be fine by firing events to the game to open custom-made menus.
Aren't tactics RPGs by law, turn-based, therefore denying any requirement for quick access to anything? Just saying, I have not heard or can even imagine a game actually focused on tactics that requires directly controlling several characters in real time.
The closest thing I can think of are RTS games, and the two good ones I can think of that are in consoles - Halo Wars and the N64 Command & Conquer - controll very well without resorting to the pause button for game-critical functionality.
And you are assuming everything MUST be in the pause menu. Do you constantly adjust brightness, character styling, screen, during the game? If you don't want to use the menu functionality and implement your own, don't use the menu functionality ani implement your own. The dashboard menu would still be fine by firing events to the game to open custom-made menus.
It isn't about whether or not the gameplay is in real time. We are talking user experience fluidity. As a user I should be able to quickly get to where I want to go with no unnecessary steps in between. The system menu is an unnecessary step in the process. If your end goal is to access something in the pause menu then every step should be along the shortest route to get to that goal. Sometimes when I leave the house I have to take out the trash... does it make sense for me to take out the trash every time I leave the house? Of course not. In this situation, sometimes I go to change the brightness of my game, why am I even touching the system menu? Going to the system menu is a step back rather than a step forward.
There are very few instances where the system menu relates to what is in-game. If you plan on staying in-game then going to the system menu doesn't make sense. XBL is a bit different because there is a friends list... sure sometimes I plan on going to the system menu to invite a friend and stay in game that is a global feature. But would it EVER make sense to go through the system menu to change the brightness in your game? Of course not. Like it wouldn't make sense to have to close the bathroom door before you go to sleep.
And I'm not assuming everything must be in the pause menu. I'm accounting for the cases where it doesn't make sense for options to be so segregated from the rest of the game. Options you talk about don't always need to be accessed in-game, sometimes they are put in the main menu. The only menu that my game requires regular access to while in game is the game list. The game list IS my pause menu. If you want to change things like brightness, audio, etc. those are rare used things that are in the main menu. In the game list there is the option to return to the main menu where you can change global options, log in/out, see leaderboards, etc. Not all games require pause menu access to those types of things. While in-game the pause menu is the game list because you go to the game list to change the board state so you can apply actions to that game, submit them and then switch without having to reload the in-game resources and hit huge loading screen every time.
People tie the menu to the start button in their minds, on the OUYA the start button should be standard across games. The only real standard would be the system button... but then we get into the concept of unnecessary steps towards an end goal where the system menu serves no progress towards the user's end goal of changing the game state. And we are assuming that all other options are tied to different functions in the game.
So to sum it up... in my game I have ONE menu accessible from in-game, that being the game list. I can see using a different button than start for a menu that you use more often than another one and relegate the least used menu to the start button... like in Skyrim where it has a spare button. But let's talk about Dark Souls. Every button in Dark Souls is tied to something. The menus are condensed into a single panel of options that is accessible by pressing the pause button (which never pauses anything in DkS). Does it make sense for me to have to go through the XBL guide to pull up that quick access panel? Of course not. One of the main PvP strategies is to hit Start/Equipment/Change Weapon/Leave Menu. It allows you to remain versatile while in combat. This ability to do this is gone if you ever have to go through the system menu. From that same panel you can access settings. Sure you rarely use it, but it works fine because when you pull up the panel it defaults to the far left... the most used menu. Here is an image for reference:
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 liked the single tap is the running app pause, and double tap is the ouya menu.
As this can be implemented. Where as the holding may not be doable with the hardware of the controller being done and the Bluetooth pairing stuff.
In many ways I feel like the Back button would be the intuitive way to pause once in a game. Of course the problem with that is the A buttonz(back) is very useful in game. In a platformer I would have A as jump and O as sprint. The over site of a pause button is pretty big. I also would have like a button to switch apps. it would be useful for chatting or the webpage in the background with the walk through. Though we do not have enough buttons as it is.
To reiterate. My vote is
Single home button press= pause app Double home button press = system menu.
I completely agree with GodlyPerfection on this. From a game-design point of view it ruins the flow and immersion of your game to switch to a system menu when just pausing to scratch your hand :P. In my humble opinion the press/hold method is best (especially when not using the sync. ingame). Second best would be press/doublepress. I think using another button than system-button is just plain wrong. System menu could work but we would have to be able to customize the feeling of this menu (layout, colours etc.).
But would it EVER make sense to go through the system menu to change the brightness in your game? Of course not. Like it wouldn't make sense to have to close the bathroom door before you go to sleep.
Actually, yes. I'd rather have the OUYA handle screen-related settings than having to configure it on every game I play.
But let's talk about Dark Souls. Every button in Dark
Souls is tied to something. The menus are condensed into a single panel
of options that is accessible by pressing the pause button (which never
pauses anything in DkS). Does it make sense for me to have to go through
the XBL guide to pull up that quick access panel?
Like I said earlier: the X360 start button is RIGHT NEXT to the face buttons. It's a clear choice as a menu button when not used. The OUYA menu will probably get really annoying if used too much, specially for people with small hands. If you're se desperate for buttons that you can't spare any of the 10 regular ones, use the touchpad.
@greeniekin : This double-tap would actually be a pretty easy work-around in terms of software design... ;-)
In more complex consideration: @chamberlin - regarding being overloaded: To put most BT headsets into "Pairing mode" this is often done by holding the pwr button while the device is off (ie, it turns on, after button up, not button down) The OUYA controller, it seems, has no idea if it was on or off before the button was pressed - try it! - hold the button down (with controller off) for 8 seconds (1 for on plus the 7 for off) and for that matter it wont even go into pairing!
* If the controller was off, it should turn on with a tap (1 sec like now is OK i guess) and pair after a 3-sec hold... PS3+XBX controllers wont turn off if you keep holding! * If the controller was on, it can pause(android "menu" button) on a tap, and sys-menu on 2-sec hold. The sys-menu's primary options can be power-off controller and power-off system, and then use the L1/R1 to change "Panels" like the XBX guide. I actually thought this was going to be your final plan anyway i think this should be the norm.
If the tap/hold method is introduced, it also means that you are bringing back the standardised android "Menu" button. That combined with the already accepted (A) as "back" will work a treat, and it really only means changing controller firmware to listen for button up instead of it's current button down status.
Btw is anyone else thinking there should be custom emoticons in these forums? rather than 135 different smileys, we'd be better off with some codes to represent the buttons... ... deleted rant ...
Actually, yes. I'd rather have the OUYA handle screen-related settings than having to configure it on every game I play.
Like I said earlier: the X360 start button is RIGHT NEXT to the face buttons. It's a clear choice as a menu button when not used. The OUYA menu will probably get really annoying if used too much, specially for people with small hands. If you're se desperate for buttons that you can't spare any of the 10 regular ones, use the touchpad.
You missed the point of that first quote... brightness was just an example. Any game wide setting that only needs to be set once... sure it would be nice to have OUYA do some of the global settings, but there are other settings in games that only need to be set once like controller sensitivity, auto-center, flight controls, button layout, etc.
The idea of using a centralized button is more familiarity for the user than anything. If someone wants to access a menu it is pretty much encoded into everyone's mind to check the center of the controller for the menu button. NES, SNES, PS1/2/3, Xbox, 360, Sega Saturn, Dreamcast, N64, Gamecube, etc, etc. All of their controllers put the menus on centralized buttons. The OUYA's controller has two centralized points of input... the touchpad and the system button. The touchpad is a new thing and fairly inaccurate. Something as important as a menu needs accuracy for optimal interaction.
And the system button is only difficult to access from the right side because of the right thumbstick. Using your left thumb the system button is easy to access across the D-Pad (where a lot of people rest their thumbs for accurate menu navigation). After doing a quick comparison of it and the 360 controller, it is actually much easier to access than the 360. The start button on the 360 is directly above and almost underneath the right stick with your right thumb and too difficult to touch regularly with your left thumb. Eventually muscle memory will find the OUYA's system button much quicker and easier to use with your left thumb than the 360's start with your right thumb.
The system button being the pause button is more natural than any of the other possibilities. And hence, if I had the choice, I would choose the system button over everything else on the controller for a menu.
Let me clear things up, I'm not saying that I would hate life if I had to go through the system menu or if I had to put it on another button. HOWEVER, here on the OUYA forums we are given a voice. It isn't very often that you have a voice during the development period with a chance to make something better. Most of the time you will here "it is too late to implement that". So there is no reason that we should "just settle" right now. If the time comes that we have to then so be it, I'm cool with that. But up until that point, I'm going to put my best thought forward and back up my reasoning. If I can't back up my reasoning then I will admit it, but I have strong feelings towards user experience.
A polished user experience makes the difference between a good product and a great product. If people can't get past your control scheme or make their way intuitively through your menus or have to jump through hoops to access something important or get lost when they shouldn't, then you've done something wrong and it doesn't matter how good your gameplay is. The details count... the minor annoyances add up like pennies in a water cooler jug. Before you know it, the cumulative annoyances will knock you out cold.
Sorry about these long posts... I tend to re-iterate myself as much as I can to visualize my point in as many ways as I can. ;) This was totally supposed to be a short post... lol.
EDIT: Also I'd totally be cool with double tap in place of hold if that is how it's got to be.
Post edited by GodlyPerfection on
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.
Indeed! It's great to see that you guys are listening.
I'd like to add a little tweak to the "tap to pause, hold to bring up OUYA menu": Perhaps you could add some developer guidelines that state in your pause menu, you should add some text letting the user now how to access the system menu. Or (even better) have the OS present it's own little widget at one of eight (developer-selected) positions on screen that fades out after a few seconds (kind of like how the achievement notifications on Xbox appear).
I am against this solution. leaving the dashboard menu fallback up to the developer means needing an extra step on the game certification process to ensure that the game allows to bring up the dashboard menu at any time. And of course, a glitch could prevent the player from accessing the dashboard at all.
Actually, I wasn't stating that the fallback should be in the developer's control. I meant that "instructions" for how to access the OUYA menu (holding the system button for a second or two) should be in each game's pause menu, either by the developer or by the OS.
The idea of using a centralized button is more
familiarity for the user than anything. If someone wants to access a
menu it is pretty much encoded into everyone's mind to check the center
of the controller for the menu button. NES, SNES, PS1/2/3, Xbox, 360,
Sega Saturn, Dreamcast, N64, Gamecube, etc, etc. All of their
controllers put the menus on centralized buttons.
Some of these controllers (NES, SNES, Playstation) also happen to have rubber buttons for start/select because those buttons are not supposed to be used constantly. Still, I have never heard someone complain when Final Fantasy puts the menu somewhere other than the start button.
The touchpad is a new thing and fairly inaccurate. Something as important as a menu needs accuracy for optimal interaction.
Be
creative. A touchpad allows for a lot more than a menu button or cursor. For
instance, you could swipe up to open the inventory, swipe down to open a
spells menu
The start button on the 360 is directly above and almost
underneath the right stick with your right thumb and too difficult to
touch regularly with your left thumb.
Tell that to the dozens of accidental pauses I've had playing Soul Calibur IV. And I don't think it's just me, SkullGirls has implemented a delayed pause because apparently pressing the start button on the X360 is too easy.
Eventually muscle memory will find
the OUYA's system button much quicker and easier to use with your left
thumb than the 360's start with your right thumb.
That seems to be a problem, not a solution, if you go by muscle memory, pausing with the left thumb becomes confusing because most controllers have layouts that either centers the start button or has the start button easier to be accessed from the right, so muscle memory will say to try to access the menu with the right thumb, not the left one.
A polished user experience makes the difference between a good product and a great product. If people can't get past your control scheme or make their way intuitively through your menus or have to jump through hoops to access something important or get lost when they shouldn't, then you've done something wrong and it doesn't matter how good your gameplay is. The details count... the minor annoyances add up like pennies in a water cooler jug. Before you know it, the cumulative annoyances will knock you out cold.
And that is my problem. I think putting gameplay on the pause menu is a bad practice and should be discouraged. Consoles of the past did this a lot, but they didn't have the luxury of having 10 buttons, 2 analogs and a D-Pad. Putting things like saving/loading and a few settings on the same place as your friends list and messages makes way more sense to me than putting a save function on an inventory screen. We should move forward and evolve, not stick with old habits because they're old habits. Additionally, OUYA's proposal of having the game menu as part of the dash menu saves development time, as you will just need to inform the dashboard what options do you need on the menu, rather than coding the entire menu yourself. So between saving development time and standardizing menus of 90% of the games and allowing 10% of the games to have an inventory on the pause screen, I stick with the 90%.
Therefore I stick with OUYA dash menu with additional options for the game menu and API for styling
I have never heard someone complain when Final Fantasy puts the menu somewhere other than the start button. [...]
Therefore I stick with OUYA dash menu with additional options for the game menu and API for styling
I don't get it, you don't like the proposal for using the system button as a pause button, but you also want to put the pause menu inside the system menu, which you can only get at... by pressing the system button...?
As for development time and standardization, you must see how ridiculous it will be for each developer to come up with their own pause/menu solution. What about games with no pause options? What about games, which when paused, want to display a full-screen stats screen for quick glance? There has to be a dedicated "start" button *available* to devs, so they can design their pause menus to look and function the way they want to. They can use it as a pause button, a menu button, or a grenade launcher if they want to. They could also have it do nothing at all if they decide, but not giving us a dedicated button limits what we can do by reducing the number of buttons available for in-game actions (since many devs will have to use a face button for it instead). It also makes porting games designed for a standard controller difficult, and has the almost assured potential to make many games control differently in an unnecessarily arbitrary way that is not expected by users, who will surely punish us (and OUYA) for it in their reviews.
And even if we forget all of those reasons, you yourself introduced an entirely new (and brilliant) argument against leaving it as-is, when you complained how easy it is to hit the start button in SoulCaliber. Imagine if the U button ("X" on the Xbox) were adopted as a makeshift "start" button?
I'm afraid I still don't see a reasonable argument against a pause button, unless I've missed something. The idea of overloading the system button with pause and system functions is automatically increasing the learning curve for your average joe, ie, our target customers. It is far less intuitive.
Arguments that it is easy to hit on accident are not proof that it should be removed entirely. Re-positioned? Sure. But it is millions of times more useful for people than it is troublesome.
There are certain conventions in games that people don't have to think about which contribute to a smoother experience overall, and navigating menus in a familiar way is definitely one of them.
I'm afraid I still don't see a reasonable argument against a pause button, unless I've missed something.
You are missing something. The controller does not include "start" or "select" buttons, and that won't be changed before the system's public release (it's too late to change the hardware design).
We're trying to convince the OUYA team to let the system button also be used as a start button (by implementing a "press/hold" solution or similar workaround), partly because we all agree with you that a start button of some kind is an absolute requirement for a games console, and also so that when they inevitably release an updated controller, they can simply add a physical start button without breaking compatibility.
I don't get it, you don't like the proposal for using the system button as a pause button, but you also want to put the pause menu inside the system menu, which you can only get at... by pressing the system button...?
Other consoles have both start and menu, and the menu button already pauses whenever the game can be paused, sometimes better, because I can open the menu during a loading process and have the game paused while the start button typically requires the player to wait until the game loads. Therefore, we have a "good" pause button and a "bad" pause button, thus removing the bad one is a natural choice.
What about games, which when paused, want
to display a full-screen stats screen for quick glance?
That could be easily solved with a styling API. Tell the dashboard not to dim the game's image and push the menu to the right while you show the stats on the left.
They could also have it do nothing at all if they decide, but not
giving us a dedicated button limits what we can do by reducing the
number of buttons available for in-game actions (since many devs will
have to use a face button for it instead).
It also makes porting games
designed for a standard controller difficult, and has the almost assured
potential to make many games control differently in an unnecessarily
arbitrary way that is not expected by users, who will surely punish us
(and OUYA) for it in their reviews.
Show me one single (serious) review that complains about an oddly-placed menu/inventory button on an otherwise good game. I've seen games with their gameplay-critical menus on the face buttons, shoulder buttons, start button... There's no such thing as an agreed standard to where the menu should be. It always boils down to what works best for the game's design. Again, games that would likely use a start menu for gameplay-related functions are at most around 10% of them.
And even if we forget all of
those reasons, you yourself introduced an entirely new (and brilliant)
argument against leaving it as-is, when you complained how easy it is to
hit the start button in SoulCaliber. Imagine if the U button ("X" on
the Xbox) were adopted as a makeshift "start" button?
When did I say I supported using the U button as a menu? Additionally, I have not had an accidental pressing of any of the X360 face buttons, ever.
Comments
And again, it can still be done even in the 3 second window, without changing the controller's firmware.
I do agree with you that trusting every dev to put the OUYA menu in their own menus (without giving users a way to force the issue) is a bad idea, for all the reasons you cite.
Single press = game-specific pause menu
Double press = OUYA menu
Surely a software-only solution can be devised where the call for the game menu on "key up" can be delayed by enough time to reasonably allow for the button to be pressed a second time, but short enough so that it wouldn't feel like there's a delay for the user if they only press it once.
Devs can be encouraged to put a link to the system menu in their own menus as well, so the double-press can simply be a way to *force* a game to go to the system menu.
And again, this would be a fallback situation, where if there's no game-specific menu, a single press would bring up the OUYA menu.
I still think press/hold is worth the trouble, but this can also work, and would also be a future-proof solution so a future controller can add a start button without breaking compatibility.
Thoughts?
We really appreciate the input from this thread :)
Founder of ReachingPerfection.com
I'd like to add a little tweak to the "tap to pause, hold to bring up OUYA menu": Perhaps you could add some developer guidelines that state in your pause menu, you should add some text letting the user now how to access the system menu. Or (even better) have the OS present it's own little widget at one of eight (developer-selected) positions on screen that fades out after a few seconds (kind of like how the achievement notifications on Xbox appear).
Game developer, AI specialist, Unity expert
http://AngryAnt.com
I don't think a major change on the controller is possible without delaying the console at this point. Also, if the consumer version ships with a different controller, games will not be ready for it at launch.
If so, there would be no need for the game menu button in the system menu, cause it could contain one menu on the left (OUYA) and one on the right (game), or something similar.
I'm guessing some devs might find it limiting to have to use ordinary menu items, instead of fancy graphics for their menus. But most of the game supplied items should probably close the OUYA menu and send an event to the game. Thus they can add the most important choices (leave game, settings, help) to the initial menu, and use fancy looking menus for settings if that is chosen, etc.
Founder of ReachingPerfection.com
The closest thing I can think of are RTS games, and the two good ones I can think of that are in consoles - Halo Wars and the N64 Command & Conquer - controll very well without resorting to the pause button for game-critical functionality.
And you are assuming everything MUST be in the pause menu. Do you constantly adjust brightness, character styling, screen, during the game? If you don't want to use the menu functionality and implement your own, don't use the menu functionality ani implement your own. The dashboard menu would still be fine by firing events to the game to open custom-made menus.
Founder of ReachingPerfection.com
As this can be implemented. Where as the holding may not be doable with the hardware of the controller being done and the Bluetooth pairing stuff.
In many ways I feel like the Back button would be the intuitive way to pause once in a game. Of course the problem with that is the A buttonz(back) is very useful in game. In a platformer I would have A as jump and O as sprint. The over site of a pause button is pretty big. I also would have like a button to switch apps. it would be useful for chatting or the webpage in the background with the walk through. Though we do not have enough buttons as it is.
To reiterate. My vote is
Single home button press= pause app
Double home button press = system menu.
Actually, yes. I'd rather have the OUYA handle screen-related settings than having to configure it on every game I play.
Like I said earlier: the X360 start button is RIGHT NEXT to the face buttons. It's a clear choice as a menu button when not used. The OUYA menu will probably get really annoying if used too much, specially for people with small hands. If you're se desperate for buttons that you can't spare any of the 10 regular ones, use the touchpad.
In more complex consideration: @chamberlin - regarding being overloaded:
To put most BT headsets into "Pairing mode" this is often done by holding the pwr button while the device is off (ie, it turns on, after button up, not button down) The OUYA controller, it seems, has no idea if it was on or off before the button was pressed - try it!
- hold the button down (with controller off) for 8 seconds (1 for on plus the 7 for off)
and for that matter it wont even go into pairing!
* If the controller was off, it should turn on with a tap (1 sec like now is OK i guess) and pair after a 3-sec hold... PS3+XBX controllers wont turn off if you keep holding!
* If the controller was on, it can pause(android "menu" button) on a tap, and sys-menu on 2-sec hold. The sys-menu's primary options can be power-off controller and power-off system, and then use the L1/R1 to change "Panels" like the XBX guide. I actually thought this was going to be your final plan anyway i think this should be the norm.
If the tap/hold method is introduced, it also means that you are bringing back the standardised android "Menu" button. That combined with the already accepted (A) as "back" will work a treat, and it really only means changing controller firmware to listen for button up instead of it's current button down status.
Btw is anyone else thinking there should be custom emoticons in these forums? rather than 135 different smileys, we'd be better off with some codes to represent the buttons...
... deleted rant ...
edit: ill make another thread for that and link it so we dont go off-topic
edit: the emoticon rant: http://forums.ouya.tv/discussion/213/emoticons-for-ouya-buttons
-=Hicsy=-
PM me Facebook
Founder of ReachingPerfection.com
Be creative. A touchpad allows for a lot more than a menu button or cursor. For instance, you could swipe up to open the inventory, swipe down to open a spells menu
Tell that to the dozens of accidental pauses I've had playing Soul Calibur IV. And I don't think it's just me, SkullGirls has implemented a delayed pause because apparently pressing the start button on the X360 is too easy.
That seems to be a problem, not a solution, if you go by muscle memory, pausing with the left thumb becomes confusing because most controllers have layouts that either centers the start button or has the start button easier to be accessed from the right, so muscle memory will say to try to access the menu with the right thumb, not the left one.
And that is my problem. I think putting gameplay on the pause menu is a bad practice and should be discouraged. Consoles of the past did this a lot, but they didn't have the luxury of having 10 buttons, 2 analogs and a D-Pad. Putting things like saving/loading and a few settings on the same place as your friends list and messages makes way more sense to me than putting a save function on an inventory screen. We should move forward and evolve, not stick with old habits because they're old habits. Additionally, OUYA's proposal of having the game menu as part of the dash menu saves development time, as you will just need to inform the dashboard what options do you need on the menu, rather than coding the entire menu yourself. So between saving development time and standardizing menus of 90% of the games and allowing 10% of the games to have an inventory on the pause screen, I stick with the 90%.
Therefore I stick with OUYA dash menu with additional options for the game menu and API for styling
I don't get it, you don't like the proposal for using the system button as a pause button, but you also want to put the pause menu inside the system menu, which you can only get at... by pressing the system button...?
As for development time and standardization, you must see how ridiculous it will be for each developer to come up with their own pause/menu solution. What about games with no pause options? What about games, which when paused, want to display a full-screen stats screen for quick glance? There has to be a dedicated "start" button *available* to devs, so they can design their pause menus to look and function the way they want to. They can use it as a pause button, a menu button, or a grenade launcher if they want to. They could also have it do nothing at all if they decide, but not giving us a dedicated button limits what we can do by reducing the number of buttons available for in-game actions (since many devs will have to use a face button for it instead). It also makes porting games designed for a standard controller difficult, and has the almost assured potential to make many games control differently in an unnecessarily arbitrary way that is not expected by users, who will surely punish us (and OUYA) for it in their reviews.
And even if we forget all of those reasons, you yourself introduced an entirely new (and brilliant) argument against leaving it as-is, when you complained how easy it is to hit the start button in SoulCaliber. Imagine if the U button ("X" on the Xbox) were adopted as a makeshift "start" button?
Arguments that it is easy to hit on accident are not proof that it should be removed entirely. Re-positioned? Sure. But it is millions of times more useful for people than it is troublesome.
You are missing something. The controller does not include "start" or "select" buttons, and that won't be changed before the system's public release (it's too late to change the hardware design).
We're trying to convince the OUYA team to let the system button also be used as a start button (by implementing a "press/hold" solution or similar workaround), partly because we all agree with you that a start button of some kind is an absolute requirement for a games console, and also so that when they inevitably release an updated controller, they can simply add a physical start button without breaking compatibility.
The menu button is a menu button, not a pause button
That could be easily solved with a styling API. Tell the dashboard not to dim the game's image and push the menu to the right while you show the stats on the left.
I'll rephrase: touchpad
Show me one single (serious) review that complains about an oddly-placed menu/inventory button on an otherwise good game. I've seen games with their gameplay-critical menus on the face buttons, shoulder buttons, start button... There's no such thing as an agreed standard to where the menu should be. It always boils down to what works best for the game's design. Again, games that would likely use a start menu for gameplay-related functions are at most around 10% of them.
When did I say I supported using the U button as a menu? Additionally, I have not had an accidental pressing of any of the X360 face buttons, ever.