4-button Layout Question

[Prometheus]

If that's possible, and if someone were to develop such a thing - and if all software written for the system were to call upon it, obviously - that would be very good, and I'd imagine nobody would (or could?) have any issues with any given standards or lack thereof. Having a predefined set of layouts included, as well as an option to set up custom ones (similar to the way some emulators for home computers do things - i.e., "Press the button you'd like to use for 'OK' now:", and noting that input before proceeding through the rest) would be a nice feature, too, in my view.

 

[Frogboy]

Although, what would be a kind of neat way to develop "standard" controls is to have some kind of OS determined way of returning what buttons are supposed to do certain things. Then you just have to react to OK, cancel, back, etc, and they could be configured by a global program. It wouldn't even really have to be OS-centric, maybe could be installed some other way. What is the opinion on something like this?

If that's possible, and if someone were to develop such a thing - and if all software written for the system were to call upon it, obviously - that would be very good, and I'd imagine nobody would (or could?) have any issues with any given standards or lack thereof. Having a predefined set of layouts included, as well as an option to set up custom ones (similar to the way some emulators for home computers do things - i.e., "Press the button you'd like to use for 'OK' now:", and noting that input before proceeding through the rest) would be a nice feature, too, in my view.

This could be easiliy done with a couple of one or two line functions (or methods bundled in a class). Getting all the devs to use it would be the hard part.

 

[AnonymousTipster]

Although, what would be a kind of neat way to develop "standard" controls is to have some kind of OS determined way of returning what buttons are supposed to do certain things. Then you just have to react to OK, cancel, back, etc, and they could be configured by a global program. It wouldn't even really have to be OS-centric, maybe could be installed some other way. What is the opinion on something like this?

This would definitely be a good idea. We could simply have a text file in the flash memory describing certain commands 'OK, BACK etc' and their corresponding button indexes '1,2', therefore changing the settings in the OS would then change settings for all games and applications which chose to use them.
We could simply implement this by having a 'pandora.h' file, with a simple command
CODE

int GetPreferenceVariable(char* variableName){
//opens preferences file and tries to find a variable of the same name as variableName, and then returns the number associated with that variable
//Alternatively, the file could be parsed on startup and variable names and values stored in an array, so that we don't have to open and close a file every time we call this function.
}



This way, we could also use this to store not only preferred controls, but game-specific controls, such as Manual or Automatic for Racing games, and how sensitive you want the analog sticks to be with shooting games.

If that's possible, and if someone were to develop such a thing - and if all software written for the system were to call upon it, obviously - that would be very good, and I'd imagine nobody would (or could?) have any issues with any given standards or lack thereof. Having a predefined set of layouts included, as well as an option to set up custom ones (similar to the way some emulators for home computers do things - i.e., "Press the button you'd like to use for 'OK' now:", and noting that input before proceeding through the rest) would be a nice feature, too, in my view.

The only thing you'd need to make most developers use this is to make it standard from the start and make sure that initial tutorials covering controls use this method. Many coders will simply copy-paste the tutorial code to get them started. Once you've got the majority of early applications using the file, almost all others will follow.

 

[Exophase]

We'd never get all apps to use it. I don't really think that's the point - the more that use it, the better.

If the early developers agree to do something like this then peer pressure will probably kick in to encourage others to use it, and if it's simple enough then ports that get released could be patched by others willing to do this.

 

[Shiny]

This way, we could also use this to store not only preferred controls, but game-specific controls, such as Manual or Automatic for Racing games, and how sensitive you want the analog sticks to be with shooting games.

I'm a bit skeptical of this globally defined controls idea. I feel that game specific controls should be stored with the game itself because there is no general configuration suitable for every game.

And then there arises the possible complication that the game that you're playing relies on your keys to be mapped in a specific way in order to play comfortably (ex: north button + south button).

I would much rather have a standardized system to define controls on a per game basis, but that might be harder to implement.

 

[Chip]

This way, we could also use this to store not only preferred controls, but game-specific controls, such as Manual or Automatic for Racing games, and how sensitive you want the analog sticks to be with shooting games.

I'm a bit skeptical of this globally defined controls idea. I feel that game specific controls should be stored with the game itself because there is no general configuration suitable for every game.

And then there arises the possible complication that the game that you're playing relies on your keys to be mapped in a specific way in order to play comfortably (ex: north button + south button).

I would much rather have a standardized system to define controls on a per game basis, but that might be harder to implement.


I think the real aim of this discussion is to come up with a standard for menu controls, not in-game controls. Obviously you can't come up with a universal control scheme for the thousands of different games and apps that will run on Pandora. You can set a standard for how the user navigates the menus.

We can't (and shouldn't) force developers to use one common system, but if there is at least a guideline then hopefully the majority will follow it. Control consistency is a small thing, but it's small things like this that help make a system feel professional. Each console has it's own conventions that (nearly) all games follow for getting into, around, and out of the menu. Once you learn it you don't have to re-learn a different system for every game.

 

[AnonymousTipster]

If the file were to be used for other preferences, such as 'Automatic/Manual', then this would only be looked at when creating the person's profile. When the game creates a save file for the game on the first time a user plays it, the game can look in the flash preferences to see if there is some data there, if not, it will just use defaults. It's not supposed to completely negate all control preferences for all games, simply a utility to mean that, where useful, will save the user from configuring the same data many times.

That said, the main purpose of the file is simply to create a standard for navigating menus. If the application uses a non-standard type of navigation (maybe radial menu) then they can ignore the preferences and use what the developer feels is best.

 

[fusion_power]

Such a "flexible Standard" sounds good. At least I would be happy if this stops things like "L+R+Start" etc for going into Menus. I never ever want a program that uses such a crap.
Good, that the Pandora has so many Buttons. AND the pandora has a nice "MENU" Button. This could be the Standard for all Emulators to go into the Emulator Menu. "Start", "Select" and the other Game controls are for Emulation itself. Big problem of the to few GP2X butons solved. ^_^

 

[greendots]

First I really like the idea of NSEW buttons...

I think it would be really easy to set up forward, back, accept buttons that the user could choose and would work in most all applications. Since pandora will run linux, global variable can be used to define what action the user would like to be assigned to each key. A program would be able to refer as the chosen letter. For example , "press <$ACCEPT> to continue" would display as "press X to continue". This is the easiest and best solution I think

(Woo first post... excited for pandora!)

 

[fusion_power]

N-S-E-W? Could be interesting. The first Handheld with a Compass rose 4-Button layout. Under the buttons could be a nice graphic (embossed part of the case) of a Compass/Wind rose, maybe:

http://en.wikipedia.org/wiki/Compass_rose

This really would make the Pandora a unique Handheld.

 

[squeakypants]

Well, there would have to be an easily accessed file with all those settings. Maybe just XML or something? That way you can use it in any language.

 

[kagato]

There seems to be two main schools of thought for button layout.

Using compass-rose terminology, either ESNW (SNES, PS), or SEWN (NeoGeo CD, XBox, Dreamcast):

On the right hand side are some ideas for the Pandora.

I think it's important to have obvious "yes" and "no" buttons. My examples have button 1 with a prominent green spot, and button 2 is red.

I initially thought symbolic numbers would be good (as illustrated)... but I'm starting to shy away from it, as writing instructions gets more ambiguous. (Saying "Press button 2" when there's a ".." button and an actual number 2 key could get confusing for some).

The compass rose is unique and clever, but doesn't map as well to "yes/no" options. "N" makes an obvious "no" but is in an unusual position for it, and none of "W", "S" or "E" make an obvious "yes". ("S" for "select", maybe? dunno)

The XBox layout probably makes the most sense. It uses letters (which is much easier to write than "press triangle"). "A" is green for yes and is right under your thumb, "B" is red for no. (though I'd color the letters rather than the button. And I'd be tempted to use "C" and "D" instead of "X" and "Y"; I don't really get the break in the alphabet there.)

 

[Chip]

The compass rose is unique and clever, but doesn't map as well to "yes/no" options.

For that matter, neither do A and B. Circle and X do a bit, but to be honest I never made the connection until this thread made me actually think about it. Besides, I'm sure Sony has some sort of legal stranglehold over using those particular shapes for video game controllers.

If you want to add some intuitivity to the compass controls, just add color like Xbox / Dreamcast. While the words for yes and no vary with language, I think the green=go and red=stop thing is universal. At least, I can't find reference to other countries using other colors in their stoplights with a 30 sec Google search.

 

[trooper]

What about W, X, Y, Z ?. X could = Exit or Back and Y could = Yes or Enter, Though it is similar to the Snes, DreamCast and Xbox symbols, It should be suitably different to not be treading on anyone`s toes.

Trooper

 

[kagato]

The compass rose is unique and clever, but doesn't map as well to "yes/no" options.
For that matter, neither do A and B.
True, but they do rank the button order (for anyone familiar with the roman alphabet at least) -- A is the first button, B is the second button.
Labeling buttons N,S,E,W doesn't give any button priority over any other. You could argue N would be the logical primary button, but it's not the most convenient position.

I agree that, regardless, the primary button should be green and the secondary button should be red. (After that it's not really important...)

Edit:
A and B could correspond to "Accept" and "Back".
But I guess S and E could correspond to "Select"/"Start" and "Exit"/"Escape"...
___N
W____E
___S

 

[JakeK]

Does it really matter? Seriously? I use to play my Xbox a lot and the buttons were different for each game. B wasn't always throw grenade etc.

Making a big issue about nothing, just choose a layout and whenever they need to be used you are told to press whatever. Trying to match up these buttons with a response similiar to what the button is labled is stupid.

All that is needed is "Press B to Accept or A to Decline." Simple.

I like the Xbox layout the best. NSEW just plain sucks, it isn't original and looks ugly.

I think you guys are underestimating the power of the human brain. If you plan to use one button for accept (whatever you want to call it) and another for decline (and again whatever) without telling the person on screen or through instructions then I think some brain power is lacking here.

Each button is meant to perform a different role than the other. You press it and it does whatever it is coded to do. It is that simple.

 

[Chip]

NSEW just plain sucks, it isn't original and looks ugly.

You may not like the aesthetics, but I'm pretty sure it is original. Do you know of a system that used this labeling scheme for the action buttons?

Each button is meant to perform a different role than the other. You press it and it does whatever it is coded to do. It is that simple.

I don't think you understand the point of the discussion. Nobody is trying to force the use of a particular button for a particular function at some low level. We're trying to come up with a convention to make menu navigation easier, and if possible a button labeling scheme to go along with it.

Whether you notice it or not, all consoles have a preferred set of buttons which the majority of games use for OK/enter and cancel/back. After a short time you become accustomed to those buttons and will instinctively use them in new games. This makes new games easier to learn and menus simpler to navigate.

 

[Squidge]

Whats wrong with just A B C D ? N S E W would just suck IMO. "Press A to continue, B to cancel" sounds much bettwe than "Press N to continue, S to cancel".

..A
C..B
..D

 

[Gaeryc]

Why cant the buttons be called:

.......chaka
pata........pon
........don

 

[#1 GameMaster]

Why cant the buttons be called:

.......chaka
pata........pon
........don

You haven't played Patapon have you? :huh: