# Pahami jam di dalam loop game
Setiap frame yang dirender memberikan waktu berlalu yang baru kepada game. Dalam loop delta variabel, gerakan biasanya diperbarui sebagai position += velocity × frameTime. Saat frame stabil, kecepatan rata-rata mendekati nilai yang diinginkan, tetapi satu pembaruan bisa sebesar frame yang memicunya. Hitch bukan sekadar jeda visual: hitch mengubah jumlah waktu game yang dikonsumsi oleh pembaruan itu. # Bandingkan integrasi variabel dengan akumulator tetap
Loop timestep tetap menambahkan durasi setiap frame ke akumulator, lalu berulang kali memakai langkah seperti 16,667 ms. Simulasi menerima pembaruan yang sama besar, sementara renderer dapat berjalan dengan ritme berbeda. Sisa pecahan disimpan untuk frame berikutnya. Saat frame panjang muncul, loop tetap menjalankan beberapa pembaruan kecil untuk menghitung waktu yang berlalu. Ukuran langkah tetap stabil, tetapi dapat muncul lonjakan kerja pengejaran. | Render stabil | Satu pembaruan memakai setiap durasi normal | Langkah yang sama memakai waktu terakumulasi | Kedua jalur seharusnya mengikuti gerakan yang sama. |
| Frame panjang | Satu pembaruan besar dapat menggerakkan objek terlalu jauh | Beberapa pembaruan tetap mengejar waktu | Baca selisih bersama jumlah langkah pengejaran. |
| Frame rate berbeda | Ukuran pembaruan berubah mengikuti frame rate | Langkah simulasi tetap sama | Langkah tetap mengurangi ketergantungan pada render. |
| Batas delta | Waktu di atas batas diabaikan | Akumulator menerima seluruh durasi frame | Batasi hanya jika kehilangan waktu dapat diterima. |
# Lihat dampak sebenarnya dari spike frame
Pada 60 frame per detik, frame normal berdurasi sekitar 16,667 ms. Dengan spike tambahan 80 ms, satu frame menjadi sekitar 96,667 ms. Model variabel memakai seluruh durasi itu dalam satu pembaruan. Model tetap memakai kira-kira enam langkah 16,667 ms. Total waktu berlalu bisa sama, tetapi jalur yang ditempuh simulasi berbeda. # Baca selisih posisi bersama pengejaran
Selisih posisi adalah jalur variabel dikurangi jalur tetap. Ini menunjukkan seberapa jauh kebijakan integrasi terpisah, bukan model mana yang otomatis benar. Jumlah pengejaran menunjukkan pekerjaan tetap yang diperlukan dalam satu frame render. Selisih besar mengarah pada perbedaan gerak yang terlihat; banyak langkah mengarah pada kemungkinan masalah anggaran CPU. Keduanya terkait, tetapi bukan diagnosis yang sama. # Perlakukan pembatasan delta sebagai kebijakan
Batas dapat mencegah tab yang dijeda, breakpoint, atau hitch berat membuat karakter berpindah jauh atau tubuh fisik menembus geometri. Konsekuensinya, jam variabel tertinggal dari waktu nyata. Jika game harus mempertahankan waktu, gunakan akumulator tetap atau kebijakan pemulihan lain. Jika game harus membatasi lompatan dan tetap responsif, batas mungkin sesuai, tetapi waktu yang hilang harus disengaja. # Pilih loop berdasarkan tugas yang dilindunginya
| Fisika, tabrakan, atau gameplay deterministik | Timestep tetap | Langkah yang sama membuat simulasi kurang bergantung pada ritme render. |
| Gerakan visual sederhana tanpa state terakumulasi | Delta variabel | Pembaruan kecil dan biasanya tidak memerlukan antrean pengejaran. |
| Simulasi gameplay dengan render halus | Update tetap dengan interpolasi | Simulasi mempertahankan langkah sementara tampilan menyembunyikan pecahan gerak. |
| Pemulihan setelah berhenti berat | Kebijakan pengejaran terbatas | Cegah satu frame buruk menjadi pekerjaan simulasi tanpa batas. |
# Gunakan alur penyetelan yang dapat diulang
Mulai tanpa spike dan pastikan kedua jalur cocok. Tambahkan hitch berulang, lalu ubah frekuensinya untuk melihat apakah kesalahan visual bertambah atau stabil. Sesuaikan langkah tetap dan perhatikan jumlah pengejaran sebelum mengubah kecepatan. Terakhir, aktifkan batas dan bandingkan waktu simulasi variabel dengan waktu nyata. Urutan ini memisahkan penyebab selisih dari kebijakan yang digunakan untuk menahannya.
Hal yang tidak dapat dibuktikan percobaan ini
Laboratorium memakai durasi frame yang ditentukan dan kecepatan konstan, jadi ia menjelaskan perilaku waktu, bukan mengukur perangkat atau memvalidasi engine. Fisika nyata, pengambilan input, jaringan, interpolasi, dan anggaran frame dapat mengubah desain terbaik. Gunakan hasilnya sebagai hipotesis lalu periksa hipotesis itu di game yang sebenarnya.