Button mapping conventions


_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,390
Age
43
Location
Brussels, Belgium
One frequent complaint is that different games / applications / emulators use different button mappings.

Let's try to agree on a mapping that makes sense, and then let's try to use that mapping consistently and change the default mapping in our applications if needed.
 
One frequent complaint is that different games / applications / emulators use different button mappings.

Let's try to agree on a mapping that makes sense, and then let's try to use that mapping consistently and change the default mapping in our applications if needed.
I agree.

Main point are, IMO, 2 button mapping, that are, Action / Cancel.

There are 2 schools basically,

Action = {B}, Cancel = {X} => Used by minimenu for example

or

Action = {X}, Cancel = {A} => I tend to used that one

Also, for run & jump, I tend to use

Jump = {X}, Action/Fire = {B}

For driving games

Accelerate = {X}, Brake = {B}
 
Standards are always good, even if few people adhere to them.

How about abstracting it so a dev can refer to a key as:

  • up/forward
  • down/backwards
  • left
  • right
  • menu
  • start/enter
  • back/cancel
  • action 1 / fire
  • action 2 / jump
  • action 3

...and the user can map physical keys to those symbolic actions
 
Standards are always good, even if few people adhere to them.

How about abstracting it so a dev can refer to a key as:

...and the user can map physical keys to those symbolic actions

I would extend that to suggest including a way for the dev to display the user's key binding at run time.   Perhaps by providing  functions in the abstraction layer to show the correct monochromatic key graphic for that binding at a given screen location, size and colour?

- Neelix

EDIT:  I'd also suggest providing a way for the user to override the bindings on a per-program basis.
 
Last edited by a moderator:
For ideally we should have something in the os:

Confirm Selection: B

Cancel: X

and the dev would assign actions rather than physical buttons.

An OS app would be used to remap the different actions to the physical buttons.

This is kind of what I do in Penjin...almost.
 
@Neelix, @Binky:

I think you are missing the point.

Don't forget most of the time it's a Port, not an original game, and it's not always easy to alter the port (and more if it's an Engine with commercial data).

So the point is: what default config should be made so you just pick a game and you are not lost with the buttons actions.
 
Last edited by a moderator:
ABXY are maybe a bit hard to standardize. What about the other buttons? I use this:

START (and P if available): pause game

SELECT: game menu

ESC (and Q if available): quit or back (like X or A or SELECT)

F1 (and H if available): help

ENTER: confirm/action (like B or X)
 
Oh... that would be a ton of work.


I use the A button a lot for action/shooting. Feels more natural to me than X.


But maybe that's because I have big hands and fingers...
 
Is it possible to remap keys without modifying the program? I'm pretty sure some PNDs remap keys before launching and then restore the old configuration when quitting; is this also possible in a way which allows multi tasking?

If this is possible then I suggest this:

Add information about the key mapping to the pnd xml file. Like "X"->"Shoot".

Then, maybe in the same file, add information about remappings, like "X" becomes "Y".

When launching a pnd those remappings are applied to it automatically.

When launching it for the first time (e.g. no remappings but it doesn't say "no remappings" explicitly in the xml file) display a graphical utility which shows which key does what by default, lets users change it and then saves it to the xml file (obviously not the one in the pnd itself but in appdata).
 
You can already remap keys by a file in appdata. For SDL apps iirc. So if someone would write a nice little buttonmapper tool it could be included into every pnd or simply launch to generate those files.
 
Back
Top