Załóżmy, że mam grę, która używa elementów sterujących WASD na układzie QWERTY. Próba użycia tych formantów, powiedzmy, na układzie Dvorak, nie jest idealna (odpowiednik <A:HQWERTY). Oczywiście chciałbym użyć tych samych fizycznych kluczy, których używałby QWERTY ( ,aoew DVORAK).
Wymyśliłem kilka możliwych rozwiązań:
- Zmuś użytkownika do korzystania z QWERTY
- oczywiście nie jest idealny, szczególnie dla międzynarodowych użytkowników
- Zmień skróty na podstawie układu klawiatury (WASD ->, aoe)
- zmusza mnie do tworzenia map układów dla każdego obsługiwanego układu (automatyczny)
- najłatwiejszy dla użytkownika, jeśli jest więcej skrótów niż tylko WASD
- Zmuś użytkownika do samodzielnego zdefiniowania skrótów
- Bardziej elastyczne
- Irytujące, jeśli jest wiele skrótów
- Może być używany w połączeniu z drugą opcją
- Użyj kodów dostępu do sprzętu
- spójny na wszystkich klawiaturach?
Jak zwykle zajmuje się tego typu rzeczami?
Należy zawsze daje graczowi możliwość zmiany ich kluczowych zadań. Tak to jest „zwykle obsługiwane”: pozwól graczowi je zmienić. Niektórzy gracze ustawiają klawiaturę na QWERTY podczas gry, ponieważ tego właśnie oczekuje większość gier. Niektórzy pozostawiają je na obecnej klawiaturze i polegają na możliwości zmiany klawiszy.
źródło
W przypadku, gdy nie możesz nasłuchiwać kodów skanowania (jak na przykład podczas tworzenia gry flash), możesz utworzyć powiązanie klawiszy, które działa dla jak największej liczby układów. Większość układów klawiatury jest bardzo podobnych, z kilkoma wyjątkami.
Układy klawiatury zgodne z ISO 9995 (to większość) są uporządkowane w następujący sposób:
Zasadniczo czarne klawisze są bezpieczne w użyciu.
źródło
Większość dużych gier budżetowych (z międzynarodowym dystrybutorem) będzie działać od razu, używając ZQSD zamiast WASD dla układów azerty. Przyzwoita gra wprowadzi również układ na pierwszym poziomie, inne pozwolą graczowi odkryć go za pomocą ekranu dostosowywania. Strategię implementacji można wykryć, prosząc system operacyjny o zmianę układów. Albo gra używa skancodów (pozycji) wewnętrznie i mapuje je na kody klawiszy (symbole) podczas wyświetlania okien dialogowych konfiguracji i monitów; lub używa kodów dostępu wewnętrznie i wykrywa układ przy uruchomieniu lub przy pierwszym uruchomieniu.
Pierwsza strategia (scancodes wewnętrznie) jest bardziej niezawodna, ale wymaga nieco ostrożności, aby zapobiec przeciekaniu abstrakcji. Pamiętaj o ponownym przypisaniu skancodów do kodów podczas prezentacji kluczy użytkownikowi (w samouczkach, podpowiedziach i oknach dialogowych dostosowywania). Nadal będziesz musiał spojrzeć na kody klawiszy podczas wprowadzania tekstu (na przykład pozwalając graczowi wpisać swoją nazwę). Jeśli chcesz obsłużyć więcej tekstu, skorzystaj z obsługi wprowadzania tekstu na platformie, która jest poza zakresem silnika gry (obsługuje martwe klawisze, blokadę klawiszy, kopiowanie i wklejanie, zaawansowane metody wprowadzania ...).
Przy przenoszeniu gry, która nigdy nie używała scancodów (co nie jest w przypadku przyzwoitego silnika, ponieważ skancody są również bliżej sprzętu i szybciej), druga strategia może być bardziej praktyczna. Można mapować skancody do kodów za pomocą funkcji SDL2 SDL_GetKeyFromScancode i SDL_GetScancodeFromKey lub odpowiedników specyficznych dla platformy. Jeśli użyjesz również pętli zdarzeń SDL2, funkcje te pozostaną dokładne między przełącznikami układu. Unikaj funkcji takich jak GetKeyboardLayout () w systemie Windows; nie ma gwarancji, że będziesz w stanie znaleźć układ na znanej liście.
źródło