Допустим, у меня есть игра, которая использует элементы управления WASD на макете QWERTY. Попытка использовать эти элементы управления, скажем, на макете Dvorak не идеальна (эквивалентно <A:Hна QWERTY). Очевидно, я хотел бы использовать те же физические ключи, что и QWERTY ( ,aoeна DVORAK).
Я придумал несколько возможных решений:
- Заставить пользователя использовать QWERTY
- очевидно, не идеально, особенно для международных пользователей
- Изменить ярлыки на основе раскладки клавиатуры (WASD ->, Aoe)
- вынуждает меня делать макеты карт для каждого поддерживаемого макета (автоматизируемый)
- самый простой для пользователя, если есть больше ярлыков, чем просто WASD
- Заставить пользователя самостоятельно определять ярлыки
- Более гибкий
- Раздражает, если есть много ярлыков
- Может использоваться совместно со вторым вариантом
- Используйте аппаратные коды клавиш
- одинаково для всех клавиатур?
Как обычно обрабатываются такие вещи?
Вы всегда должны давать игроку возможность изменять свои ключевые назначения. Вот как это обычно делается: пусть игрок поменяет их. Некоторые игроки устанавливают на клавиатуре QWERTY, когда играют в игры, потому что именно этого ожидает большинство игр. Некоторые оставят их на своей текущей клавиатуре и полагаются на возможность смены клавиш.
источник
В случае, если вы не можете прослушивать коды сканирования (как, например, при разработке флеш-игры), вы можете сделать привязку клавиш, которая работает для максимально возможного числа макетов. Большинство раскладок клавиатуры очень похожи, за небольшим исключением.
Раскладки клавиатуры в соответствии с ISO 9995 (это большинство) расположены следующим образом:
В основном черные клавиши безопасны в использовании.
источник
Большинство больших бюджетных игр (с участием международного дистрибьютора) будут работать «из коробки», используя ZQSD вместо WASD для азербайджанских макетов. Приличная игра также представит макет на первом уровне, другие позволят игроку обнаружить его через экран настройки. Стратегию реализации можно определить, попросив ОС переключить макеты. Либо игра использует сканкоды (позиции) внутри и отображает их на коды клавиш (символы) при отображении диалогов и подсказок конфигурации; или он использует внутренние коды и обнаруживает макет при запуске или при первом запуске.
Первая стратегия (внутренние коды) более надежна, но требует некоторой осторожности, чтобы не допустить утечки абстракции. Не забудьте переназначить коды сканирования в коды клавиш при представлении ключей пользователю (в учебных пособиях, приглашениях и диалогах настройки). Вам все равно нужно будет смотреть на коды клавиш при вводе текста (например, позволить игроку ввести свое имя). Если вам нужно обрабатывать больше текста, чем это, посмотрите на использование поддержки ввода текста на платформе, которая выходит за рамки игрового движка (обрабатывает мертвые клавиши, capslock, копирование, вставку, расширенные методы ввода…).
При портировании игры, в которой никогда не использовались сканкоды (что не имеет места при достойном движке, поскольку сканкоды также ближе к оборудованию и быстрее), другая стратегия может оказаться более практичной. Вы можете сопоставить коды сканирования с кодами клавиш, используя функции SDL2 SDL_GetKeyFromScancode и SDL_GetScancodeFromKey или их эквиваленты для конкретной платформы. Если вы также используете цикл событий SDL2, эти функции останутся точными во всех параметрах компоновки. Избегайте таких функций, как GetKeyboardLayout () в Windows; нет никакой гарантии, что вы сможете найти макет в известном списке.
источник