"E Tuşuna Bas" Dedi, Dünya YıkıldıKafayı yiyecektim arkadaşlar. Basit bir oyun projesinde, ilk açılış tutorial'ını yazıyordum. "Başlamak için E tuşuna basın" yazdım, geçtim. Testlerimde sorun yok, her şey harika. Ta ki Fransız bir arkadaşım "oyun açılmıyor" mesajı atana kadar. Meğerse sorun şuradaymış: Onun klavyesi AZERTY!
Kodun İçinde Kaybolan TuşOyun motorunda (Unity kullanıyordum) input'u şöyle almıştım, saf ve temiz:
C#:
if (Input.GetKeyDown(KeyCode.E)) {
StartGame();
}QWERTY'de E harfi, AZERTY'de E tuşunun üzerinde değilmiş! O tuş AZERTY'de başka bir karaktere (sanırım 2 veya &'ye) denk geliyor. Yani tutorial ekranında büyük harflerle "E'YE BAS" yazarken, AZERTY kullanıcısı hangi fiziksel tuşa basacağını bilemiyor. Klavye düzeni hard-coded olarak KeyCode.E'ye bağlı kalmıştım. Şaka gibi ama oyunun girişini kilitlemişim.
Çözüm: "E" Değil, "Etkileşim"StackOverflow'da bile tam aradığımı bulamadım, biraz kafa patlattım. En temiz çözüm, spesifik bir harfe değil, sistemin atanabilir giriş tuşuna bağlamak. Ya da tutorial'da "Etkileşim Tuşuna Basın" yazıp, o tuşun ne olduğunu Input Manager üzerinden kullanıcının kendi belirlemesine/öğrenmesine izin vermek.
Sonuçta, KeyCode.E yerine, önceden tanımlanmış bir "Interact" aksiyonunu kontrol etmek çok daha iyi. Örneğin, yeni sistemde:
C#:
if (Input.GetButtonDown("Interact")) {
StartGame();
}Ve bu "Interact" aksiyonunu, proje ayarlarında hem E (QWERTY) hem de AZERTY'deki karşılığı gibi alternatif tuşlarla tanımlamak.
Alınacak Büyük DersLocalization (yerelleştirme) sadece metinleri çevirmek değilmiş. Klavye düzeni, tarih formatı, para birimi... Hepsi bu kapsama giriyormuş. Bir daha asla KeyCode ile direkt harf tuşlarını hard-code'lamayacağım. Her zaman rebindable (yeniden atanabilir) input sistemleri kurmanın ne kadar kritik olduğunu acı bir şekilde öğrendim.
Siz de böyle "benim makinemde çalışıyordu" deyip, farklı bir klavye/coğrafyada patlayan saçma sapan hatalar yaşadınız mı? Input handling konusunda önerebileceğiniz daha temiz yöntemler var mı?