Как я могу обрабатывать различные раскладки клавиатуры?

Допустим, у меня есть игра, которая использует элементы управления WASD на макете QWERTY. Попытка использовать эти элементы управления, скажем, на макете Dvorak не идеальна (эквивалентно <A:Hна QWERTY). Очевидно, я хотел бы использовать те же физические ключи, что и QWERTY ( ,aoeна DVORAK).

Я придумал несколько возможных решений:

• Заставить пользователя использовать QWERTY
  • очевидно, не идеально, особенно для международных пользователей
• Изменить ярлыки на основе раскладки клавиатуры (WASD ->, Aoe)
  • вынуждает меня делать макеты карт для каждого поддерживаемого макета (автоматизируемый)
  • самый простой для пользователя, если есть больше ярлыков, чем просто WASD
• Заставить пользователя самостоятельно определять ярлыки
  • Более гибкий
  • Раздражает, если есть много ярлыков
  • Может использоваться совместно со вторым вариантом
• Используйте аппаратные коды клавиш
  • одинаково для всех клавиатур?

Как обычно обрабатываются такие вещи?

Слушайте коды сканирования. Как это сделать, зависит от вашей ОС, которую вы не указали. В Windows вы можете получить скан-код для данного кода виртуальной клавиши от WM_KEYDOWN и друзей с помощью MapVirtualKey . Коды сканирования основаны на физическом ключе и не зависят от макета.

Быстро прочитайте http://www.altdevblogaday.com/2011/10/02/i-never-managed-to-go-left-on-first-try/ .

Так что, как сказал Ник Болас, вы можете и должны позволить пользователям обойти это. Но просто заставить его работать прямо из коробки не сложно, и ваши пользователи это оценят.

Обратите внимание, что вы (вероятно) неправильно обрабатываете ввод символов, как подавляющее большинство разработчиков игр. Убедитесь, что для текста вы всегда используете WM_CHAR (или эквивалент в других ОС), а не WM_KEYDOWN для ввода текста. Совершенно неверно полагать, что при нажатии клавиши «а» вам следует вводить «а» в элемент управления вводом текста из-за использования «мертвых» клавиш в некоторых макетах. Вы также можете поддерживать IME (или эквивалент ОС) для рынков Восточной Азии, которые имеют гораздо больше символов, чем может уместиться на клавиатуре, и для печати требуется специальный интерфейс. Работа с IME в игре - это боль (а вообще работа с ней - боль), но, на мой взгляд, стоит увеличить привлекательность вашего продукта для гораздо более широкого круга рынков. Опять же, WM_KEYDOWN никогда не будет использоваться для текста, никогда.

Вы всегда должны давать игроку возможность изменять свои ключевые назначения. Вот как это обычно делается: пусть игрок поменяет их. Некоторые игроки устанавливают на клавиатуре QWERTY, когда играют в игры, потому что именно этого ожидает большинство игр. Некоторые оставят их на своей текущей клавиатуре и полагаются на возможность смены клавиш.

В случае, если вы не можете прослушивать коды сканирования (как, например, при разработке флеш-игры), вы можете сделать привязку клавиш, которая работает для максимально возможного числа макетов. Большинство раскладок клавиатуры очень похожи, за небольшим исключением.

Раскладки клавиатуры в соответствии с ISO 9995 (это большинство) расположены следующим образом:

В основном черные клавиши безопасны в использовании.

Большинство больших бюджетных игр (с участием международного дистрибьютора) будут работать «из коробки», используя ZQSD вместо WASD для азербайджанских макетов. Приличная игра также представит макет на первом уровне, другие позволят игроку обнаружить его через экран настройки. Стратегию реализации можно определить, попросив ОС переключить макеты. Либо игра использует сканкоды (позиции) внутри и отображает их на коды клавиш (символы) при отображении диалогов и подсказок конфигурации; или он использует внутренние коды и обнаруживает макет при запуске или при первом запуске.

Первая стратегия (внутренние коды) более надежна, но требует некоторой осторожности, чтобы не допустить утечки абстракции. Не забудьте переназначить коды сканирования в коды клавиш при представлении ключей пользователю (в учебных пособиях, приглашениях и диалогах настройки). Вам все равно нужно будет смотреть на коды клавиш при вводе текста (например, позволить игроку ввести свое имя). Если вам нужно обрабатывать больше текста, чем это, посмотрите на использование поддержки ввода текста на платформе, которая выходит за рамки игрового движка (обрабатывает мертвые клавиши, capslock, копирование, вставку, расширенные методы ввода…).

При портировании игры, в которой никогда не использовались сканкоды (что не имеет места при достойном движке, поскольку сканкоды также ближе к оборудованию и быстрее), другая стратегия может оказаться более практичной. Вы можете сопоставить коды сканирования с кодами клавиш, используя функции SDL2 SDL_GetKeyFromScancode и SDL_GetScancodeFromKey или их эквиваленты для конкретной платформы. Если вы также используете цикл событий SDL2, эти функции останутся точными во всех параметрах компоновки. Избегайте таких функций, как GetKeyboardLayout () в Windows; нет никакой гарантии, что вы сможете найти макет в известном списке.