Her Ekranda Aynı Gemi

Bir günlük lider tablosu, ancak mağaranın aynı bölümünü uçmak eski küçük bir telefonda, 144 Hz'lik bir tablette ve masaüstü tarayıcısında eşit derecede zorsa adil olur. İşte bunun için ne gerektiği ve neyi eşitleyemediğim.

Geliştirici günlüğü · 20 Eylül 2026 · tüm yazılar

Günlük mağara yazısı, her oyuncu için dünyayı aynı yapmakla ilgiliydi. Bu ise adaletin diğer yarısıyla ilgili: gemiyi aynı şekilde davranmaya zorlamak. Bir cihazın oyunun oynanışını değiştirebileceği iki ayrı yol var ve bunların iki ayrı düzeltmeye ihtiyacı var. Biri ekranın ne sıklıkla yenilendiği. Diğeri ekranın ne kadar büyük olduğu.

Birinci sorun: kare hızı

Geminin bir konumu ve bir hızı var. Her karede, yerçekimi veya itme gücü hızı değiştirir ve hız da konumu değiştirir. Bunu yazmanın bariz yolu şudur:

vy += accel * dt;     // update velocity
py += vy * dt;        // then move by the NEW velocity

Zararsız görünüyor ama ince bir şekilde yanlış. İkinci satır, geminin karenin tamamını zaten kare sonu hızıyla kat etmiş gibi davranıyor. Gemi hızlanıyorsa, bu her karede accel × dt²'nin yarısı kadar fazla gider. Sorun şu ki kare uzunluğu olan dt her cihazda farklıdır, dolayısıyla bu fazlalık da farklıdır ve gemi her yenileme hızında biraz farklı bir yörüngede uçuyordu.

Bunu yarım saniye boyunca basılı tutulan bir itme gücüyle ölçtüm. Kesin cevap 225 piksel. Eski entegrasyon yöntemi 144 Hz'de 228, 60 Hz'de 232 ve 30 Hz'de 240 veriyordu. Üç cihaz, aynı girdiden üç farklı mesafe.

Çözüm, karenin öncesi ve sonrasındaki hızın ortalamasını kullanan yamuk kuralı:

const vyPrev = vy;
vy += accel * dt;
py += (vyPrev + vy) * 0.5 * dt;   // average speed over the frame

Sabit bir ivme için bu, kare uzunluğu ne olursa olsun kesindir. Aynı girdi programını tekrar oynatmak artık 12 ile 144 Hz arasında 0.000 piksellik bir sapma veriyor. Daha önce 4,1 pikseldi. Bir test her iki yarıyı da doğruluyor: yeni entegrasyon yönteminin tüm yenileme hızlarında uyuştuğunu ve eskisinin gerçekten farklılaştığını, böylece biri bunu geri alırsa lider tablosu sessizce kaymak yerine test başarısız olur.

İki dürüst çekince

Bu, yenileme hızları arasındaki puan farkını kapatmadı. Bunu bekliyordum. Simüle edilmiş bir pilot, bundan sonra bile 144 Hz'de 60 Hz'den yaklaşık üçte bir daha yüksek puan alıyordu. Bu fark fizikle ilgili değil. Bu bir girdi çözünürlüğü meselesi: bir başparmak yalnızca bir kare sınırında basılıdan bırakılmışa geçebilir, bu yüzden daha hızlı bir ekran gerçekten daha ince bir kontrol sağlar. Hiçbir entegrasyon yöntemi bunu düzeltemez ve her karede girdisini ters çeviren bir bot, bunu bir insana kıyasla abartır. Fizik yarısı artık kesin ve geri kalanı donanımın bir özelliği.

60 Hz'de çok hafif bir zayıflatma. Yarım saniyelik bir tırmanış artık 232 yerine 225 piksel kat ediyor. Bunu telafi etmeden bıraktım. Gerçek cihaz testi gemiyi bir gün ağır bulursa, kaldıraç itme gücü sabiti olur, yaklaşık %3 daha fazlası eski yarım saniyelik manevrayı geri getirir. Bu arada, itme gücünün oyuncu geri bildirimi üzerine daha önce iki kez değiştirildiğini söylemek için iyi bir an; o hikaye, ona dokunma konusunda neden dikkatli olduğumun sebebi.

İkinci sorun: ekran yüksekliği

Saniye kare başına piksel cinsinden yerçekimi, 375 puan yüksekliğindeki bir telefonda ve 520 puan yüksekliğindeki bir tablette çok farklı şeyler ifade eder. Sabitler aynı olsaydı, aynı tırmanış tablette ekranın çok daha küçük bir kısmını geçerdi ve oyun daha ağır hissettirirdi.

Bu yüzden sabitler, oyunun hissinin ayarlanıp test edildiği en büyük iPhone'un yatay yüksekliği olan 440 puanlık bir referans yükseklike göre tanımlanır. Başka herhangi bir ekranda yerçekimi, itme gücü ve son hız hepsi H / 440 ile çarpılır. Koridorun yarı boşluğu da yükseklikle ölçeklendiği için, her yörünge referans yörüngeyle geometrik olarak benzerdir: saniyede geçilen koridor oranı aynı, bir duvardan diğerine geçme süresi aynı, hissedilen tepki aynı. Daha büyük bir ekran piksel cinsinden daha dik bir ivme alır, daha küçük olan ise kasıtlı olarak daha yumuşak bir ivme alır.

Bu, tüm gelecekteki kod için bir kuralla birlikte gelir: dikey hareket hakkında akıl yürüten her şey orana dayalı olmalıdır. Son hızın bir kesri, yüksekliğin bir kesri. Geminin hızıyla karşılaştırılan ham bir saniyede-piksel sabiti asla kullanılmaz, çünkü o sayı yalnızca bir cihazda doğrudur. Bir sabit sayı kaçınılmazsa, aynı ölçekle çarpılır.

Web sürümü de aynı kuralı izler. Tarayıcı derlemesi, tuvalini o referans telefonla aynı boyutlara, 956'ya 440'a sabitler, bu yüzden tarayıcıdaki oyun onun piksel ve fizik açısından tam bir kopyasıdır. Daha önceki bir web derlemesinin kendi ayrı his çarpanı vardı, bu yalnızca farklı bir sınırın neden olduğu yumuşaklıkla mücadele etmek için vardı ve sınır eşleştiğinde kaldırıldı.

Üçüncü sorun: ekran genişliği

Yükseklik dikey eksendir. Genişlik yatay eksendir ve daha inceliklidir. Engeller, dünyada sabit mesafelerle yerleştirilir. Mağara, ekran genişliği için bir çarpan içeren bir hızda kayar. Yani daha geniş bir ekranda aynı engeller ekran açısından daha hızlı geçer ve her birine tepki vermek için sahip olduğun süre genişlikle orantılı olarak azalır.

Bu gerçek bir sızıntıydı. Yaklaşık 1280 puan genişliğindeki büyük bir Android tablet, paylaşılan mağarayla küçük bir telefondan yaklaşık 1,75 kat daha hızlı karşılaşıyordu. Bu yüzden genişlik, her platformda 956 puanla sınırlandırılmıştır, bu da yatay konumdaki en geniş iPhone'un genişliğidir. Bundan daha geniş bir cihaz sol ve sağda siyah bantlar alır. iPhone'larda bir etkisi yoktur ve yalnızca büyük Android cihazları ile masaüstü tarayıcılarını sınırlar.

Sınırın düzeltmediğim bir kalıntısı var. Oyuncunun çarpışma yarıçapı genişlikle ölçeklenirken koridor yükseklikle ölçeklenir, bu yüzden daha kare bir tablette gemi, boşluğa göre bir telefondakinden biraz daha küçüktür, yaklaşık %20 daha hoşgörülü. Bunu düzeltmek isabet kutusunu değiştirmek anlamına gelir, bu da kendi oyun testini gerektiren bir his değişikliğidir ve hoşgörülü yönde hata yapar, bu yüzden bekleyebilir.

Adaleti iddia etmek yerine test etmek

Bunların hiçbiri oynarken görünmez. Birkaç piksellik sapmayı hissedemezsin ve kimse aynı mağarayı altı cihazda aynı anda oynamaz. Bu yüzden her iddianın onu yeniden oynatan bir testi vardır: fizik testi, 12 ile 144 Hz arasındaki kare hızlarında sabit bir girdiyi entegre eder ve bir mağara testi gerçek üreticileri altı cihaz boyutunda yeniden oynatıp sonucu bayt bayt karşılaştırır. Deneyimlerime göre, test edilmeyen bir adalet özelliği çoktan sessizce bozulmuştur.

Kısacası, TUNL ekranlar arasında üç ayrı şekilde adildir (kare hızı, yükseklik ve genişlik), her birinin farklı bir nedeni, farklı bir düzeltmesi ve farklı bir kalıntısı vardır. Sonucu sahip olduğun herhangi bir cihazda, bugünün mağarasında kendin görebilirsin.

Bugünün mağarasını oyna