Keybinding is backwards IMO
by Lance Hampton · in General Discussion · 06/18/2005 (4:00 pm) · 13 replies
I've been getting frustrated by the lack of options in binding keys in some games.
Every game I can think of at the moment assigns keys to functions.
Is there any reason it can't(or shouldn't) be done the other way, assign functions to keys.
In a highly contrived example, let's say that I'm a complete spaz. I want to make every number key throw a grenade because I don't want to accidentally not throw it. With most current systems you could bind at most two keys to that (through the interface anyway). If you were to bind the functions to the keys, then you could conceivably bind every key to throw-grenade.
Perhaps it's all just the emacs user in me that wants it this way but it seems like it would allow for much easier expansion of what's bindable through a normal in-game interface (just register functions as bindable perhaps as you wouldn't want a choice of *all* functions in the game).
One of the main reasons I'd like to see it done this way is that the interface could display a keyboard and show me which keys are available. I'm tired of looking at these longs lists of keys, changing one and finding out later I've overwritten something like moveforward.
Does emacs run Torque yet?
Every game I can think of at the moment assigns keys to functions.
Is there any reason it can't(or shouldn't) be done the other way, assign functions to keys.
In a highly contrived example, let's say that I'm a complete spaz. I want to make every number key throw a grenade because I don't want to accidentally not throw it. With most current systems you could bind at most two keys to that (through the interface anyway). If you were to bind the functions to the keys, then you could conceivably bind every key to throw-grenade.
Perhaps it's all just the emacs user in me that wants it this way but it seems like it would allow for much easier expansion of what's bindable through a normal in-game interface (just register functions as bindable perhaps as you wouldn't want a choice of *all* functions in the game).
One of the main reasons I'd like to see it done this way is that the interface could display a keyboard and show me which keys are available. I'm tired of looking at these longs lists of keys, changing one and finding out later I've overwritten something like moveforward.
Does emacs run Torque yet?
#2
As for your interface idea about showing a keyboard and letting the user bind functions to the keys is intriguing, but it comes with a whole slew of problems.
I'm in sweden so naturally I use a swedish keyboard, some keys are mapped quite differently from an english one. How would this be handled? What if someone used a completely different setup (like dvorak instead of qwerty)? If you're going to set up your interface screen and keep in mind all odd keyboard setups people may use it's going to get very difficult.
And "a long list of functions" is (hopefully) shorter than if you would have "a long list of all your keyboard keys". Add on mouse buttons, joysticks or gamepads and listing all the functions is probably the easiest way to handle it. The best solution would be to design your game so you don't need so many functions =)
There's really nothing stopping you from designing your interface so the user can bind all keys to the same function though.
The issue of overwriting is simple enough to fix; pop up a warning if you try to overwrite something.
06/20/2005 (5:06 am)
I agree with chris, binding keys to functions and functions to keys is exactly the same thing.As for your interface idea about showing a keyboard and letting the user bind functions to the keys is intriguing, but it comes with a whole slew of problems.
I'm in sweden so naturally I use a swedish keyboard, some keys are mapped quite differently from an english one. How would this be handled? What if someone used a completely different setup (like dvorak instead of qwerty)? If you're going to set up your interface screen and keep in mind all odd keyboard setups people may use it's going to get very difficult.
And "a long list of functions" is (hopefully) shorter than if you would have "a long list of all your keyboard keys". Add on mouse buttons, joysticks or gamepads and listing all the functions is probably the easiest way to handle it. The best solution would be to design your game so you don't need so many functions =)
There's really nothing stopping you from designing your interface so the user can bind all keys to the same function though.
The issue of overwriting is simple enough to fix; pop up a warning if you try to overwrite something.
#3
I suppose I've just been presented too many interfaces where binding one key has unbound another. The Dark Age of Camelot keybinding interface comes to mind, even though I can see all the bindings at once, it's too much to see and I frequently rebind a key I didn't mean to.
@Magnus - Damn your Swedish keyboards! This is a great point. I can't think of any way around it.
One of the major benefits I'd be looking for is being able to plan out the keyboard a bit better. Seeing the keyboard and what is currently bound would go a long way.
I guess, what it boils down to is which question you ask yourself:
1. Which key do I want to press to throw-grenade? (e)
2. What function do I want to execute when I press 'e'? (throw-grenade)
Both result in:
moveMap.bind( keyboard, e, throwGrenade );
Maybe I'm the only one that wants an interface that's phrasing the question the second way.
06/20/2005 (10:08 am)
@Chris - I know that at the code level keys and functions are bound together (not one to the other).I suppose I've just been presented too many interfaces where binding one key has unbound another. The Dark Age of Camelot keybinding interface comes to mind, even though I can see all the bindings at once, it's too much to see and I frequently rebind a key I didn't mean to.
@Magnus - Damn your Swedish keyboards! This is a great point. I can't think of any way around it.
One of the major benefits I'd be looking for is being able to plan out the keyboard a bit better. Seeing the keyboard and what is currently bound would go a long way.
I guess, what it boils down to is which question you ask yourself:
1. Which key do I want to press to throw-grenade? (e)
2. What function do I want to execute when I press 'e'? (throw-grenade)
Both result in:
moveMap.bind( keyboard, e, throwGrenade );
Maybe I'm the only one that wants an interface that's phrasing the question the second way.
#4
06/20/2005 (10:20 am)
You could make a user interface with all the possible keys on the left. All the possible actions on the right... Then code it up so the user can drag a key to an action or an action to a key to bind them (show it wil a line connecting them) ... Then you just allow them to bind multiple keys to 1 function.... but not multiple functions to one key.
#5
Move Forward: w, arrow_up
Move Backward: s, arrow_down
...
You want:
w: move forward
arrow_up: move forward
...
Ermm... The current method seems much more logical to me, though I suppose I could have adapted to it without realizing.
06/20/2005 (10:24 am)
@Lance: So instead of:Move Forward: w, arrow_up
Move Backward: s, arrow_down
...
You want:
w: move forward
arrow_up: move forward
...
Ermm... The current method seems much more logical to me, though I suppose I could have adapted to it without realizing.
#6
06/20/2005 (10:29 am)
@Mark; Actually I see Lances point, it's an interesting idea. But the trick would be to come up with a way to work out the interface. Chris' idea... well... sucks. Instead of having "a long lists of keys" we now have "a long lists of keys" AND "a long lists of functions".
#7
Sounded like such a good idea in my head though.
EDIT: Are you sure it's not a good idea ? I mean thinking about it... All of those functoins are going to be there anyway. This way is just easier to see them.
06/20/2005 (10:44 am)
@Mangus - Ya I know... Everyone tells me Im a good programmer but I should keep far away from anything graphical.... Sounded like such a good idea in my head though.
EDIT: Are you sure it's not a good idea ? I mean thinking about it... All of those functoins are going to be there anyway. This way is just easier to see them.
#8
Pros:
- it's very easy to logically group keys and plan a layout
- I'd get some easy kills on Magnus because he couldn't get everything bound correctly
Cons:
- beginners could easily leave out a basic function (like moveForward)
- Magnus might not buy my game
I know nothing about querying localization settings from inside Torque. My experiences from localization on the database and system end would lead me to believe it would be possible.
@Chris - sorry, but your idea sounds like a mess.
One last bit about my preferred method of binding functions to keys. It leaves you just one step from assigning macros to keys.
bind(1, zoom(90));
bind(2, zoom(45));
bind(3, zoom(22.5));
If you could start to bind parameters in those functions, it would offer a functionality not possible going the other way (which is more or less a static list of what functions can be bound).
06/20/2005 (10:54 am)
I want to say that I've seen what I want in action (Planetside perhaps?). Of course it was only for American keyboards as far as I know.Pros:
- it's very easy to logically group keys and plan a layout
- I'd get some easy kills on Magnus because he couldn't get everything bound correctly
Cons:
- beginners could easily leave out a basic function (like moveForward)
- Magnus might not buy my game
I know nothing about querying localization settings from inside Torque. My experiences from localization on the database and system end would lead me to believe it would be possible.
@Chris - sorry, but your idea sounds like a mess.
One last bit about my preferred method of binding functions to keys. It leaves you just one step from assigning macros to keys.
bind(1, zoom(90));
bind(2, zoom(45));
bind(3, zoom(22.5));
If you could start to bind parameters in those functions, it would offer a functionality not possible going the other way (which is more or less a static list of what functions can be bound).
#9
What do you mean here : "If you could start to bind parameters in those functions, it would offer a functionality not possible going the other way" ?
What is stopping you from binding a variable value ?
06/20/2005 (11:00 am)
Meh *shrugs* Sounded really good in my head. What do you mean here : "If you could start to bind parameters in those functions, it would offer a functionality not possible going the other way" ?
What is stopping you from binding a variable value ?
#10
@Lance: Getting the local is is probably not a problem, but figuring out how the keyboard for each local looks may be more complicated. I don't think there's any way to do this other than creating your own database with all possible keyboards. And as I touched on before; what about joysticks and gamepads etc?
I can't really think of any perfect way to handle your idea from a purely user interface design point of view (but then again I have no real reason to actually sit down and work with it. Last time I had to come up with a scheme for setting up keys in a game I only had 6 possible actions so it was never really a problem =).
06/20/2005 (11:13 am)
Quote:Are you sure it's not a good idea?Well, if the point of this was to get rid of having a long list of functions this would indeed be a bad idea, yes. You'd still have that list, and you'd have another list too. Would be easier to just do it the normal way but allowing the user to bind as many keys as he wants rather than restricting it to one or two keys per function.
@Lance: Getting the local is is probably not a problem, but figuring out how the keyboard for each local looks may be more complicated. I don't think there's any way to do this other than creating your own database with all possible keyboards. And as I touched on before; what about joysticks and gamepads etc?
I can't really think of any perfect way to handle your idea from a purely user interface design point of view (but then again I have no real reason to actually sit down and work with it. Last time I had to come up with a scheme for setting up keys in a game I only had 6 possible actions so it was never really a problem =).
#11
Umm... how is what you state different from what Torque does?
NOTE: On binding in Torque
1. All key binds bind a Key to a Function
2.
06/20/2005 (11:15 am)
bind(1, zoom(90)); bind(2, zoom(45)); bind(3, zoom(22.5));
Umm... how is what you state different from what Torque does?
moveMap.bind( keyboard, a, moveleft ); moveMap.bind( keyboard, d, moveright ); moveMap.bind( keyboard, w, moveforward ); moveMap.bind( keyboard, s, movebackward ); moveMap.bindCmd(keyboard, "1", "zoom(90);", ""); moveMap.bindCmd(keyboard, "2", "zoom(45);", ""); moveMap.bindCmd(keyboard, "3", "zoom(22.5);", "");
NOTE: On binding in Torque
1. All key binds bind a Key to a Function
2.
#12
bind( 1, "zoom(90)" );
Is legal and will work properly, I think. :\
06/20/2005 (12:33 pm)
IIRC, you can also bind a quoted section of code:bind( 1, "zoom(90)" );
Is legal and will work properly, I think. :\
#13
If you were binding functions to keys instead of keys to functions in the Options GUI, you'd just be one step away from binding functions with parameters, and possibly simple macros (although that opens up a whole new can of worms).
06/20/2005 (1:58 pm)
I've been talking about the binding that goes on in the options GUI. Yes it is identical in the code itself.If you were binding functions to keys instead of keys to functions in the Options GUI, you'd just be one step away from binding functions with parameters, and possibly simple macros (although that opens up a whole new can of worms).
Torque Owner Chris Labombard
Premium Preferred
In todays games the user interface that they present to the player is what is stopping players from doing htis, not the ability to bind keys to a function.