Messages

16

General discussions / Re: Better keyboard handling

« on: April 19, 2014, 03:43:52 pm »

Thanks for the link.

After looking up tons of keyboard layouts I've come to the conclusion that named bindings for just the letters A-Z are completely safe across all keyboards, assuming the only other bindings used are QWERTY-location bindings for numbers, puncutation and control keys (ie no non-English letters), and assuming those named A-Z bindings fall back to location bindings on systems where the keys do not exist (which SO told me Windows does).

I don't think this is correct. As I wrote in my first post in this topic, French AZERTY keyboard have the letter M in the position of the semicolon on a QWERTY keyboard.

So, since you said that game uses a mix of named and location, do you happen to know if all of its number/punctuation mark bindings are location-based?  And what most other games like this do?

I did not express myself very well here. What I meant is that it is clear by the design of the shortcuts to be a mix of name and location. As I said, I don't know any game that actually implements this correctly. All the games I know implement either location keybinding, which makes shortcuts hard to memorize or named keybinding, which is even worse, and forces you to press key combinations for what was intended to be a simple keystroke on some keyboards. I don't know by heart what XWA does, but it does allow re-assignment, so it could be dealt with.

Here's some of the conflicts I found that might occur if someone used named binding for punctuation and/or numbers:

• On the "KazWin" keyboard, . and , are the same key
• On the Serbian keyboard, ; and , are the same key
• On Russian keyboards, 4 and ; are the same key
• On Russian (Typewriter) keyboards, 6 and , are the same key
• On most Central/South American keyboards, Q and @ are the same key
• I'm fairly sure I saw a keyboard whose number row had 1,2,3,4,6, but none of 5,7,8,9,0.  I can't remember which one this was now.

I also said that for this reason I would not suggest including named keybindings for anything beyond alphabet and numbers. There is no reason for their existence (you cannot easily memorize the keystroke, because a punctuation mark is not the beginning of a word), and it only leads to conflicts.
So apart from the last one (which seems really strange to me), those shouldn't be a problem. The only conflict I see thus far is the M / ; conflict, if M is bound by name and ; by location.

17

General discussions / Re: Better keyboard handling

« on: April 19, 2014, 10:49:50 am »

To sum up: I think named bindings for all latin keyboards would be nice, but I'm not sure it's possible without embedding a lot of extremely arbitrary and fragile rules into SFML.  Putting those rules into an extension might be a good idea though (maybe some extra methods in thor::ActionMap?).

EDIT: It's possible Windows virtual key codes already attempt to do this, so maybe SFML is already inheriting from Windows' built-in arbitrary rules.  No idea about Mac and Linux.  If all three do have something similar, I would be in favor of exposing it in SFML (in addition to scan codes and locations).

I agree. I wrote about named identifiers:
The operating systems keyboard event should provide those. If they need to be converted to location identifiers (most likely for asynchronous key handling), this should also be done by the operating system (but I don't know if it's possible).
So just to clarify: If it is not possible to do it via the operating system, I wouldn't propose to implement it in SFML. That would indeed induce a lot of headache.

P.S. I'm not sure about the claim that necessarily more people "need" to rebind all their keys if developers don't do named keybinding, but that probably depends heavily on the genre.  For the stuff I play (platformers, puzzle games, action games) I find the locations of the keys is infinitely more important than the letters that happen to be on them (eg, WASD have nothing to do with up/left/down/right, and no one minds).  I assume in strategy or simulation games where you have far more keys, there's more benefit to named binding.  Are those the use cases you're thinking of?

Yes, it is heavily depending on the genre. For a platformer the location is indeed the most important aspect.
Flight & Space sims are the most notorious ones in the other direction. There are games that have two or three function on every key (in combination with CTRL and ALT), and those are usually selected according to their name in order to ease memorization. Here's the example of X-Wing Alliance, which is an arbitrary mix of named and location binding.

18

General discussions / Re: Better keyboard handling

« on: April 18, 2014, 08:03:06 pm »

Since I can't find any recent discussions on this with the forum search...

I don't think "named identifiers" can be part of a true solution to international keyboard handling, because any alphanumeric key we're familiar with may not exist on other keyboards, as shown back on page 1 by exploter's Armenian keyboard example:

So even if we wanted to let the programmer bind "missile" to the "m" key or "group 7" to the "7" key, we can't even guarantee there is an m key or a 7 key at all, much less agonize over how to locate it.

To use Flash's terminology: "named keybinding" is simply not possible in general (not even for number keys!), so you need to use "location keybinding" and "named display" for everything.

That is correct, and I have to admit that was a stupid oversight on my part.
However, I already stated that it should be made absolutely clear that if the developer uses named keybindings, he should also offer the possibility to customize keys. So people with a non-latin keyboard would have to customize keys.
Therefore, I still think named keybindings make sense. If you don't allow named keybindings, you only increase the number of people who have to customize.
With named keybindings => everybody without a latin keyboard needs to reassign keys.
Without named keybindgs => everybody without a qwerty keyboard needs to reassign keys.

19

General discussions / Re: SFML Game Development -- A book on SFML

« on: December 19, 2013, 10:18:58 am »

The publisher has a $5 E-Book Bonanza, so right now it's only 5$ at http://www.packtpub.com/
Thought people might be interested.

20

General discussions / Re: Better keyboard handling

« on: November 30, 2013, 10:11:29 pm »

They should only be provided for the letters and numerics, possibly some additional keys, like Esc or the F-Keys. The reason for the need for named identifiers does not apply to the symbol keys, and the programmer is discouraged from using a symbol as a named identifier

So what should I do for keys with punctuation marks, or other symbols? Choose the most "standard" symbol, or define no key code for them?

As I said, IMO there should be no named key definitions for those keys. There should however be location definitions for them (example with semicolon key).
The reason for the need of named keys is so that keys can be bound according to a named patter (e.g. 't' for target, 'm' for missile, etc.). This reason does not exist for symbolic keys. They are chosen because of their location. If you allowed programmers to do named keybindings on symbolic keys, we would end up with games that have nonsensical key assignments on foreign keyboards. Furthermore, the second problem I mentioned would get much bigger, because there would be even more possible overlap between named and location keybindings.

21

General discussions / Re: Better keyboard handling

« on: November 30, 2013, 07:47:59 pm »

Well, I addressed it indirectly, when I said:
They should only be provided for the letters and numerics, possibly some additional keys, like Esc or the F-Keys. The reason for the need for named identifiers does not apply to the symbol keys, and the programmer is discouraged from using a symbol as a named identifier

So if a programmer, who has no idea of a French keyboard, uses a numeric named identifier, because '3' is the key for "triple awesome", it should work on a French keyboard as well. I understand that this is problematic to implement, because without this, one could simply use the character the operation system returns for that key, but that would be " on an Azerty keyboard. The only solution I see (that doesn't involve a hardcoded key schema for every available keyboard) is to ask the OS for both key and shift+key and compare with both (internally), and hope there is no strange keyboard out there that puts numeric keys on other modifiers.

Regarding the key description text, I would just use whatever the operation system provides. If a user does the keybinding himself, he can live with the description " or Shift-".

22

General discussions / Re: Better keyboard handling

« on: November 30, 2013, 04:16:58 pm »

Hi guys,

I registered for this topic, because it is IMO very important, and almost all games do it wrong. Right now, I'm using only the Audio module of SFML (hope that will change, though). Therefore, I don't know how keyboard handling works currently. I hope I can contribute nevertheless, as I have thought much about this topic. In my opinion we should first try to find out how it should be done, before we determine if it is possible to do it like that. Therefore I want to begin with the gamer's perspective.

The Gamer's Perspective

From a gamer's perspective, keys should sometimes be mapped according to their physical location (e.g. wasd) let's call this "location keybinding", and sometimes according to what is printed on the key (e.g. e for eject, t for target), let's call this "named keybinding". Almost no game has ever done this right, and this was especially problematic during DOS times with nonmappable keybindings. In many cases, the game used a combination of both for determining the layout of the keys. E.g. many flight simulators and space sims use the letter keys for named keybindings and the area around the enter keys for location keybindings. But all of those games use either only scancodes (thus mixing up the named keybindings on non-english keyboards, e.g. Auto-tracking becomes Ctrl-Q on an Azerty keyboard instead of Ctrl-A in Wing Commander 3), or only the characters that the keyboard produces, forcing Alt Gr-( and Alt GR-) on an Azerty keyboard to decrease/increase throttle, instead of the two keys next to Enter in some games.

If a game offers freely chosable keybindings, as soon as the user selects a key it should (obviously) reflect the location of this key (location keybinding). However, it would still be good if an appropriate default keybindings works equally well on all keyboards. Additionally, in the keybindings menu, it should be shown what is actually on the keyboard of the user (named display).

To sum up:

• A) Some keybindings should be done according to their physical location (location keybinding)
• B) Some keybindings should be done according to what is printed on the key (named keybinding
• C) The programmer should think about why he chooses that key and select the appropriate method
• D) If the keys are shown anywhere in the game, they should always display what the user sees on his keyboard (named display)
• E) If keys can be redistributed by the user, they should always reflect their physical location (location keybinding)

The Programmers Perspective

The programmer should always put the user first. Therefore, everything that is written above, remains. However, we now have an additional problem: The programmer himself might have a strange keyboard. Thus

• If he wants to do a location keybinding, how is he supposed to know what the location code for a specific location is?
• If he does a named keybinding, he could bind on a symbol that is hidden or does not exist on the user's keyboard
  

Proposal

A possible solution would be to offer to sets of identifiers, location and named identifiers.

A) Location identifiers need to be provided for every key. They could by default be named according to the Qwerty layout. (In all likelihood they would be constants evaluating to the scancode).

(Regarding 1.:) As a convenience for the programmers, alternative names for the most used keyboards could be used. Thus sf::Keyboard::location::semicolon would be equivalent to sf::Keyboard::location::colon, sf::Keyboard::location::Azerty::M and sf::Keyboard::location::Qwertz::OE. A programmer with an even more exotic keyboard would either have to google a picture of a Qwerty keyboard or write a little program that outputs the location identifier for a pressed key. This program could also be provided.

B) Named identifiers do not need to be provided for every key. They should only be provided for the letters and numerics, possibly some additional keys, like Esc or the F-Keys. The reason for the need for named identifiers does not apply to the symbol keys, and the programmer is discouraged from using a symbol as a named identifier that does not exist on a user's keyboard (regarding 2.).
The operating systems keyboard event should provide those. If they need to be converted to location identifiers (most likely for asynchronous key handling), this should also be done by the operating system (but I don't know if it's possible).

C) Additionally, there should be a function like toDescription(...) that takes both location and named identifiers and returns a descriptive text, that should reflect what the user can see on his keyboard. It should be trivial for named identifiers. For location identifiers, this can only be done by the operating system. It should theoretically be possible (the OS takes a scancode and gives a char), but I don't know if this functionality (simulate a keyboard event in order to receive the correct character according to the user's locale) is available on all operating systems

Problems:

This proposal has two problems:

• There is a minor problem because physical key locations differ as well - E.g the key left of backspace in Qwerty is located in the third row left of return in Azwerty and Qwertz. However, I think we can ignore this. There is no software solution to this problem.
• There is a major problem because of the overlapping of named and location identifiers. Say I write a game that uses sf::Keyboard::location::semicolon for "adjust throttle to enemy" and the named keybinding 'm' for "missile". Then a French user (hi Laurent) has a problem, because they evaluate to the same key on Azerty.

The only solution to the second problem that I can think of is that it needs to be emphasized in the documentation that if one uses both named and location identifiers in the same game, then the keys must be reassignable. However, an overlap will occur only in very few cases, and it is IMO still a preferrable alternative to the either - or approach taken by most games, where a reassignment (or the ability to memorize nonsensical key combinations) is needed on almost all foreign keyboards.