Control Schema, Menus Especially

[sparr]

One area where the GP2X suffered (in terms of handing to a friend and expecting to be wowed instead of wtfed) was that every game used inconsistent controls in menus. Sometimes B is 'yes' and X is 'no, sometimes X is 'yes' and A is 'no', sometimes start is 'yes', sometimes start is 'quit', sometimes L+R+Select+Start is 'quit', sometimes vol++vol- is 'menu' and sometimes it is 'quit'.

It would be very very nice if there was some sort of standard for this on the Pandora. Sure, plenty of games will ignore it, but if even half of the popular games were consistent it would ease new users into the platform a lot more smoothly.

I don't think that there should ever be a single button for 'quit', that just begs to be hit accidentally. I am not a fan of hot-button menu systems in general, being more in favor of "use the arrows to highlight an item" types, but I can live with consistent hot-buttons.

Thoughts? Suggestions? Links to the other nine people who already had this idea that I didn't find by searching?

 

[lulzfish]

Maybe make the left button "no" or "cancel" since it's further from the hand?
Also, the touchscreen will help this slightly since you can just press the buttons with your fingernails.

 

[sparr]

I am a fan of the left or bottom button as no/cancel and the right button as yes. This mirrors the Nintendo "standard".

We cannot rely on touch screen support when a large number of early release apps are likely to be gp2x ports (due mostly to the overlapping community) or low-requirement non-mouse PC games (where ENTER=next and ESC=cancel). A standard as proposed here would hopefully be picked up by some porters along the way.

 

[lulzfish]

And left joydisc for movement, right joydisc for camera action, as used by numerous other consoles with dual joysticks?

 

[zacaj]

Also, the menu button is there, so that's not a problem. In my opinion, rght should byes and den should be no

 

[Butterman]

I'm used to the right button being no and the bottom being yes. This is more logical, because you're more likely to be pressing the yes button and that is the area where your finger/thumb will rest.

You could say it leads more to accidental pressing, well, stop being so stupid and pressing the wrong buttons idiot.

EDIT: Either way, this is how the menus in TINCS will operate

 

[PokeParadox]

I'm used to the right button being no and the bottom being yes. This is more logical, because you're more likely to be pressing the yes button and that is the area where your finger/thumb will rest.

You could say it leads more to accidental pressing, well, stop being so stupid and pressing the wrong buttons idiot.

EDIT: Either way, this is how the menus in TINCS will operate

This is opposite to what feel natural to me... but then I've always had a Nintendo console as my main console: A is Accept B is back
The physical locations of the buttons are imprinted on my head from my NES!

A good compromise would be a setting to swap ok/cancel

 

[Nilsiboy]

the problem (which has been discussed a LOT in the button layout threads) is that there's the Nintendo way of putting A at the right and B at the bottom, and the XBOX way of doing it exactly the other way around...
So actually, A is Accept and B is Back on both of them
I don't think there's a way to standardize this without throwing off one of the two groups, and that's not even counting the PSX crowd, where there's no consistent standard (sometimes X is accept and O back, sometimes the other way around, sometimes triangle is back...)

IMHO a good way would be to just show what which button will do in relevant situations (like menus), because there's certainly no lack of screen real estate on the Panda

 

[Butterman]

We should hold a poll in the general chat, what everybody prefers. Then, we just keep the results of these polls about, devs would be stupid to not follow what the general Pandora population want.

 

[Pleng]

the problem (which has been discussed a LOT in the button layout threads) is that there's the Nintendo way of putting A at the right and B at the bottom, and the XBOX way of doing it exactly the other way around...
So actually, A is Accept and B is Back on both of them
I don't think there's a way to standardize this without throwing off one of the two groups...

The only way I can think of would be to have the buttons assigned to specific functions at firmware level (psudo-buttons), and allow the user to select his preferred layout.

Programs supporting the protocol could then simply refer to the psudo-buttons

For example instead of coding:

CODE

if joypad button(y) pressed then



the following would be used
CODE

if joypad button(accept) pressed then

 

[lulzfish]

Sorry for all the editing. Apparently this was already discussed in an earlier design thread, and A is accept, B is back, with the

X
A B
Y

arrangement that apparently it's using.

http://www.gp32x.de/board/index.php?showtopic=43762

And apparently the right joydisc is for mouse control. Weird.

 

[greendots]

The best option for buttons is to let software control everything.

If some one wants to change the location of the buttons to snes style it would still be possible and not mess anything up. A global variable could be set to tell the layout of the buttons and what the user wants to do.

Hopefully it will be in the SDK and OS.

 

[Butterman]

Sorry for all the editing. Apparently this was already discussed in an earlier design thread, and A is accept, B is back, with the

X
A B
Y

arrangement that apparently it's using.

http://www.gp32x.de/board/index.php?showtopic=43762

And apparently the right joydisc is for mouse control. Weird.



Perhaps this should be posted somewhere, as long as everybody follows these rules, we won't have any problems with consistency.