Kapal yang Sama di Setiap Layar
Papan peringkat harian hanya adil jika terbang di ruas gua yang sama sama sulitnya di ponsel kecil lama, tablet 144 Hz, dan browser desktop. Berikut apa yang dibutuhkan untuk itu, dan apa yang tidak bisa saya samakan.
Tulisan tentang gua harian membahas membuat dunia identik untuk setiap pemain. Tulisan ini membahas separuh lain dari keadilan: membuat kapal berperilaku identik. Ada dua cara terpisah sebuah perangkat bisa mengubah cara game dimainkan, dan keduanya butuh dua perbaikan terpisah. Satu adalah seberapa sering layar menyegarkan. Yang lain adalah seberapa besar layarnya.
Masalah satu: frame rate
Kapal memiliki posisi dan kecepatan. Setiap frame, gravitasi atau dorongan mengubah kecepatan, dan kecepatan mengubah posisi. Cara yang jelas untuk menulis itu adalah:
vy += accel * dt; // update velocity
py += vy * dt; // then move by the NEW velocityTerlihat tidak berbahaya, tapi ini salah secara halus. Baris kedua berpura-pura bahwa kapal sudah menghabiskan seluruh frame bergerak pada kecepatan akhir frame-nya. Jika kapal sedang berakselerasi, ini melampaui sebesar setengah dari accel × dt² di setiap frame. Masalahnya adalah dt, panjang frame, berbeda di setiap perangkat, jadi pelampauan itu juga berbeda, dan sebuah kapal terbang dengan jalur yang sedikit berbeda di setiap refresh rate.
Saya mengukurnya dengan dorongan yang ditahan selama setengah detik. Jawaban tepatnya adalah 225 piksel. Integrator lama memberikan 228 pada 144 Hz, 232 pada 60 Hz, dan 240 pada 30 Hz. Tiga perangkat, tiga jarak berbeda, dari input yang sama.
Perbaikannya adalah aturan trapesium, yang menggunakan rata-rata kecepatan sebelum dan sesudah frame:
const vyPrev = vy;
vy += accel * dt;
py += (vyPrev + vy) * 0.5 * dt; // average speed over the frameUntuk akselerasi konstan itu tepat, berapa pun panjang frame-nya. Memutar ulang jadwal input yang identik sekarang memberikan penyimpangan 0,000 piksel di rentang 12 hingga 144 Hz. Sebelumnya 4,1 piksel. Sebuah tes memastikan kedua hal: bahwa integrator baru sepakat di semua refresh rate dan bahwa yang lama memang benar-benar berbeda, jadi jika seseorang mengembalikannya, tes akan gagal alih-alih papan peringkat diam-diam bergeser.
Dua catatan jujur
Ini tidak menutup celah skor antara refresh rate. Saya sudah menduganya. Seorang pilot simulasi masih mencetak skor sekitar sepertiga lebih tinggi pada 144 Hz dibanding 60 Hz setelahnya. Celah itu bukan fisika. Itu resolusi input: ibu jari hanya bisa berubah dari menahan ke melepas pada batas frame, jadi layar yang lebih cepat benar-benar memberikan kontrol yang lebih halus. Tidak ada integrator yang bisa memperbaiki itu, dan bot yang membalik inputnya setiap frame melebih-lebihkan itu dibanding manusia. Separuh fisika sekarang tepat, dan sisanya adalah properti dari perangkat keras.
Ini adalah pelemahan yang sangat sedikit pada 60 Hz. Kenaikan setengah detik sekarang mencakup 225 piksel, bukan 232. Saya membiarkan itu tanpa kompensasi. Jika pengujian di perangkat nyata suatu saat menemukan kapal terasa lamban, tuasnya adalah konstanta dorongan, sekitar 3% lebih banyak akan memulihkan manuver setengah detik yang lama. Ini momen yang baik untuk mengatakan bahwa dorongan sudah diubah dua kali sebelumnya berdasarkan masukan pemain, dan cerita itu adalah alasan saya berhati-hati menyentuhnya.
Masalah dua: tinggi layar
Gravitasi dalam piksel per detik kuadrat berarti hal yang sangat berbeda pada ponsel setinggi 375 poin dan tablet setinggi 520 poin. Jika konstantanya sama, kenaikan yang sama akan melintasi bagian layar yang jauh lebih kecil di tablet, dan game akan terasa lebih berat.
Jadi konstanta didefinisikan terhadap tinggi referensi 440 poin, tinggi lanskap iPhone terbesar, tempat rasa game disetel dan diuji. Di layar mana pun lainnya, gravitasi, dorongan, dan kecepatan terminal semuanya dikalikan dengan H / 440. Karena setengah celah koridor juga berskala dengan tinggi, setiap lintasan secara geometris mirip dengan yang referensi: fraksi koridor yang dilintasi per detik sama, waktu yang sama untuk berpindah dari satu dinding ke dinding lain, respons yang dirasakan sama. Layar yang lebih besar mendapat akselerasi piksel yang lebih curam, dan yang lebih kecil mendapat yang lebih lembut, secara sengaja.
Ini disertai aturan untuk semua kode masa depan: apa pun yang bernalar tentang gerakan vertikal harus berbasis rasio. Sebuah fraksi dari kecepatan terminal, sebuah fraksi dari tinggi. Tidak pernah konstanta piksel-per-detik mentah dibandingkan dengan kecepatan kapal, karena angka itu hanya benar di satu perangkat. Jika sebuah literal tidak terhindarkan, ia dikalikan dengan skala yang sama.
Versi web mengikuti aturan yang sama. Build browser membatasi kanvasnya menjadi 956 kali 440, jejak yang sama dengan ponsel referensi itu, jadi game di browser adalah salinan piksel dan fisika yang tepat darinya. Build web sebelumnya memiliki pengali rasa terpisahnya sendiri, yang hanya ada untuk melawan kelembekan yang disebabkan oleh batas yang berbeda, dan itu dihapus setelah batasnya cocok.
Masalah tiga: lebar layar
Tinggi adalah sumbu vertikal. Lebar adalah sumbu horizontal, dan ini lebih halus. Rintangan diberi jarak pada jarak tetap di dunia. Gua bergulir dengan kecepatan yang mencakup faktor untuk lebar layar. Jadi pada layar yang lebih lebar, rintangan yang sama lewat lebih cepat dalam istilah layar, dan waktu yang kamu miliki untuk bereaksi terhadap masing-masing berkurang sebanding dengan lebar.
Ini adalah kebocoran nyata. Tablet Android besar dengan lebar sekitar 1.280 poin menghadapi gua bersama sekitar 1,75 kali lebih cepat daripada ponsel kecil. Jadi lebar dibatasi hingga 956 poin di setiap platform, lebar iPhone terlebar dalam lanskap. Perangkat yang lebih lebar dari itu mendapat bilah hitam di kiri dan kanan. Ini tidak berpengaruh pada iPhone dan hanya membatasi perangkat Android besar serta browser desktop.
Batasnya memiliki sisa yang belum saya perbaiki. Radius tabrakan pemain berskala dengan lebar sementara koridor berskala dengan tinggi, jadi pada tablet yang lebih persegi, kapal sedikit lebih kecil relatif terhadap celah dibanding di ponsel, sekitar 20% lebih memaafkan. Memperbaikinya berarti mengubah hitbox, yang merupakan perubahan rasa yang membutuhkan playtest-nya sendiri, dan ini salah ke arah yang memaafkan, jadi bisa menunggu.
Menguji keadilan alih-alih menegaskannya
Tidak ada satu pun dari ini yang terlihat saat bermain. Kamu tidak bisa merasakan beberapa piksel pergeseran, dan tidak ada yang bermain gua yang sama di enam perangkat sekaligus. Jadi setiap klaim memiliki tes yang memutarnya ulang: tes fisika mengintegrasikan input tetap pada frame rate dari 12 hingga 144 Hz, dan tes gua memutar ulang generator sungguhan pada enam ukuran perangkat dan membandingkan hasilnya byte demi byte. Properti keadilan yang tidak kamu uji, menurut pengalaman saya, sudah diam-diam rusak.
Singkatnya, TUNL adil di antara layar dengan tiga cara terpisah (frame rate, tinggi, dan lebar), masing-masing dengan penyebab, perbaikan, dan sisa yang berbeda. Kamu bisa melihat hasilnya sendiri, di perangkat apa pun yang kamu miliki, di gua hari ini.