Memilih Laju Bingkai untuk Animasi Sprite

Jumlah bingkai dan kecepatan pemutaran adalah keputusan berbeda

Siklus berjalan dengan 4 bingkai yang diputar pada 8 bingkai per detik memerlukan setengah detik per siklus. Siklus berjalan dengan 8 bingkai pada 8fps memerlukan satu detik penuh, dua kali lebih lama, pada kecepatan pemutaran yang sama. Jumlah bingkai menentukan banyaknya detail gerakan di dalam loop; kecepatan pemutaran menentukan seberapa cepat loop berulang. Anda dapat memiliki siklus terperinci 12 bingkai yang diputar terlalu lambat untuk terlihat berjalan, atau siklus sederhana 2 bingkai yang diputar pada irama tepat dan tetap menyampaikan gerakan dengan jelas, karena persepsi gerak manusia lebih mementingkan waktu daripada detail.

Secara praktis penting karena dua pengaturan saling mengimbangi pada anggaran gambar tetap. Jika hanya mampu menggambar 4 bingkai serangan, tidak harus animasi buruk — sesuaikan kecepatan dan waktu tahan (dibahas nanti) hingga 4 bingkai terbaca benar, bukan menganggap perlu lebih banyak untuk masalah waktu.

Seperti apa rasanya 8, 12, dan 24fps

Angka menunjukkan seberapa sering bingkai ditampilkan berubah, terpisah dari laju render game.

• 8fps — bingkai baru kira-kira setiap 125ms. Gerakan bertahap jelas; setiap pose terlihat cukup lama untuk dikenali satu per satu sebelum pose berikutnya muncul. Terasa disengaja, berbobot, atau sengaja retro, bukan halus.
• 12fps — bingkai baru kira-kira setiap 83ms. Laju tradisional "on twos" dari animasi gambar tangan (menggambar konten baru setiap dua bingkai film 24fps). Cukup halus untuk terasa mengalir pada kebanyakan aksi game, tetapi tetap murah untuk digambar.
• 24fps — bingkai baru kira-kira setiap 42ms, sesuai laju bingkai film. Gerakan terasa sepenuhnya halus tanpa tahapan yang terlihat. Membutuhkan kira-kira dua kali konten bingkai 12fps untuk mengisi durasi sama, atau jumlah bingkai sama yang diputar dalam setengah waktu.

Tidak satu pun benar secara objektif. Pilihan tepat bergantung pada hal yang dianimasikan dan kesan yang ingin disampaikan, sehingga bagian berikutnya membagi menurut gerakan, bukan memberikan satu angka untuk seluruh game.

Mengapa game retro menggunakan fps rendah — dan mengapa kini menjadi pilihan gaya

Konsol dan PC awal yang menganimasikan pada 6–10fps bukan pertama-tama membuat pilihan artistik; mereka bekerja dalam batas memori yang ketat. Setiap bingkai tambahan berarti data sprite tambahan yang harus muat dalam ROM kartrid atau RAM sistem, yang keduanya diukur dalam kilobyte. Studio yang menganimasikan karakter pada 24fps, bukan 8fps, membutuhkan sekitar tiga kali anggaran bingkai untuk setiap gerakan dalam game, dikalikan seluruh karakter, dan anggaran tersebut biasanya tidak tersedia. Jumlah bingkai rendah merupakan akibat langsung batasan itu, dan animator menjadi sangat mahir memilih bingkai terpenting di dalamnya.

Batasan itu pada dasarnya sudah hilang kini — penyimpanan dan memori bukan pembatas jumlah bingkai game 2D. Memilih 8fps sekarang merupakan keputusan gaya yang disengaja, biasanya meniru tampilan era itu atau gerakan bertahap yang memang sesuai gaya karya. Penting mengetahui alasan proyek Anda karena "FPS rendah karena retro" dan "FPS rendah karena anggaran bingkai habis" memberi hasil sama lewat penalaran berbeda, dan hanya satu merupakan batasan yang bebas diabaikan.

Laju yang disarankan menurut gerakan

Anggap ini sebagai titik awal, bukan aturan. Satu-satunya pengujian yang benar-benar menentukan adalah melihat putaran animasi pada skala dan kecepatan game sebenarnya — angka yang terlihat tepat dalam program animasi dengan pratinjau besar bisa terlihat sangat berbeda ketika tinggi sprite hanya 48 piksel di layar yang bergerak.

Bingkai tahan dan durasi

Tidak semua bingkai memerlukan durasi layar sama. Bingkai tahan adalah pose yang ditampilkan lebih lama daripada bingkai sekitarnya — persiapan sebelum pukulan, puncak lompatan, sesaat sebelum ayunan pedang mengenai sasaran. Menahan pose sedikit lebih lama daripada laju seragam memberi penonton waktu memahami antisipasi sebelum bagian cepat terjadi, suatu bentuk easing: gerakan jarang linear, begitu pula waktunya seharusnya.

Dalam praktik, animasi serangan sebenarnya bukan N bingkai pada FPS konstan — melainkan bingkai persiapan ditahan 150ms, dua bingkai transisi cepat masing-masing 40ms, bingkai benturan ditahan 100ms, dan bingkai pemulihan ditahan 200ms. Kebanyakan sistem animasi memungkinkan durasi per bingkai, bukan satu laju global, karena alasan ini. Jika alat hanya mendukung laju tetap, Anda dapat meniru jeda dengan menduplikasi bingkai yang ingin ditahan, sehingga menempati dua atau tiga tick, bukan satu.

FPS animasi bukan FPS game

Game dapat dirender pada 60 atau 120fps sementara animasi sprite diputar pada 12fps — angka-angka ini tidak berkaitan. Loop render game tetap menggambar setiap bingkai; sistem animasi menentukan seberapa sering beralih ke bingkai sprite berikutnya dalam loop itu, biasanya dengan melacak waktu yang berlalu dan beralih ketika ambang tercapai, bukan mengikat perpindahan bingkai pada setiap tick render. Mencampuradukkan keduanya merupakan kesalahan umum bagi pemula animasi sprite yang sebelumnya menganggap framerate sebagai satu hal saja.

Pemisahan ini memungkinkan game dengan kamera dan respons input 60fps sangat mulus tetap menampilkan animasi karakter 8fps bertahap sebagai gaya, dan alasan target framerate game tidak perlu mengubah waktu animasi sprite — jika perlu, sistem animasi salah menghubungkan keduanya.

Letaknya dalam mesin umum

• Unity — kolom sample rate pada jendela Animation menetapkan bingkai per detik untuk seluruh klip; keyframe individu pada timeline tetap dapat ditempatkan dengan jarak tidak merata untuk membuat penahanan dalam laju itu.
• Godot — AnimatedSprite2D dan SpriteFrames memungkinkan pengaturan fps per animasi dan, secara terpisah, pengali durasi per bingkai untuk menahan bingkai tertentu.
• Khusus/tidak bergantung engine — sebagian besar animator sprite buatan sendiri melacak akumulasi waktu terhadap array durasi per bingkai, bukan satu konstanta fps. Ini pendekatan paling fleksibel jika Anda menulis sistem sendiri.

Pertanyaan yang sering diajukan