Merancang untuk kinerja berarti mengikuti sejumlah praktik terbaik saat Anda membangun permainan Anda. Dibandingkan dengan menemukan dan memperbaiki masalah kinerja di kemudian hari dalam proses pengembangan, merancang untuk kinerja lebih awal dapat menghemat banyak waktu dan usaha.
Perangkat kelas bawah
Perangkat kelas bawah, terutama perangkat seluler, memiliki keterbatasan memori yang parah dan rentan terhadap kerusakan akibat kesalahan memori (OOM):
Jika Anda ingin mendukung perangkat kelas bawah, pilih setidaknya satu perangkat "baseline", uji permainan Anda di atasnya sepanjang proses pengembangan, dan perhatikan dengan saksama laju bingkai dan penggunaan memori. Saat Anda menemukan area bermasalah dalam permainan Anda, gunakan area tersebut untuk mengidentifikasi batasan perangkat Anda.
Misalnya, Anda mungkin menguji permainan dengan statistik debug Render (ShiftF2) dan Summary (ShiftF2) diaktifkan. Jika laju bingkai mulai menurun di area yang sangat ramai, Anda dapat memeriksa angka Draw (scene) dan menentukan bahwa Anda perlu tetap di bawah 1.000 panggilan gambar dan 1.000.000 segitiga agar permainan berjalan dengan baik di perangkat baseline Anda.
Atau Anda bisa memeriksa Konsol Pengembang (F9) dan mencatat bahwa penggunaan memori sedikit tinggi kecuali Anda mengaktifkan streaming. Memahami batasan perangkat dengan jelas dapat membantu Anda tetap di bawahnya saat Anda terus membangun permainan Anda.
Emulator perangkat di Roblox Studio berguna untuk memeriksa rasio aspek dan kontrol, tetapi tidak akurat untuk penggunaan memori; ketika Anda menguji permainan di Studio, itu menjalankan server dan klien, sehingga penggunaan memori jauh lebih tinggi.
Roblox tidak memiliki akses ke seluruh memori perangkat. Sebagian dari memori tersebut dibutuhkan untuk sistem operasi dan aplikasi lainnya.
Secara lebih umum, mengujicoba di berbagai perangkat dapat membantu Anda memeriksa bahwa permainan sesuai dengan harapan visual dan kinerja Anda pada berbagai tingkat kualitas grafis. Untuk contoh yang jauh lebih rinci tentang bagaimana Anda bisa berpikir tentang mengoptimalkan permainan Anda untuk perangkat seluler kelas bawah, lihat Optimisasi Membangun dan Pemrograman di Dunia Nyata.
Streaming dan teleportasi
Instance streaming memungkinkan Roblox untuk memuat dan membongkar konten 3D secara dinamis dan merupakan pilihan yang hebat untuk sebagian besar tempat, terutama yang lebih besar. Streaming meningkatkan waktu bergabung, mengurangi jejak memori, dan meningkatkan laju bingkai.
Misalnya, saat Anda mengaktifkan Workspace.EnableSLIMAvatars dan mengatur properti LevelOfDetail model dunia Anda ke SLIM, Anda dapat menciptakan dunia dengan ruang sosial dan acara ramai yang tetap terlihat padat sementara menyelaraskan dengan berbagai kemampuan perangkat. Untuk informasi lebih lanjut, lihat SLIM dan Tingkatkan kinerja.
Pertimbangkan untuk memecah tempat yang besar menjadi beberapa yang lebih mudah dikelola dan menggunakan teleportasi untuk memindahkan pemain di antara keduanya. Pendekatan ini dapat mengurangi waktu bergabung awal, tetapi menyebabkan waktu bergabung tambahan saat pemain teleportasi dari tempat ke tempat. Manfaat penggunaan memori bervariasi tergantung pada ukuran tempat dan apakah Anda telah mengaktifkan streaming.
Bahkan tanpa mempertimbangkan kinerja, Anda mungkin menemukan bahwa memiliki beberapa tempat menyederhanakan proses pengembangan, terutama jika Anda secara teratur menambah konten baru ke permainan Anda atau merupakan bagian dari tim yang lebih besar.
Material dan duplikasi
Material bawaan menggunakan jauh lebih sedikit memori dibandingkan tekstur kustom, tetapi mungkin tidak cocok dengan visi artistik Anda. Cobalah untuk menggunakan material kapan pun memungkinkan untuk menghemat anggaran memori untuk tekstur yang merupakan bagian utama dari permainan Anda.
Saat Anda membuat aset, ubah mereka menjadi paket. Membuat paket menjadi bagian dari alur kerja Anda membantu menghindari masalah umum dari aset ganda dengan ID yang berbeda, yang dapat merugikan kinerja.
Ketika Anda menambahkan mesh dan tekstur, gunakan dan gunakan kembali daripada mengimpor salinan duplikat. Dengan mengubah ukuran, memutar, dan menumpuk, Anda dapat membuat lingkungan yang kaya dan bervariasi yang memerlukan sangat sedikit panggilan gambar. Untuk informasi lebih lanjut, lihat Hapus tekstur duplikat.
Transparansi
- Hindari nilai transparansi lain selain 0 (terlihat) dan 1 (tidak terlihat). Ketika Anda menggunakan transparansi parsial, berhati-hatilah untuk menghindari overdraw transparansi tinggi.
Pemrograman
Setiap kali memungkinkan, tulis kode berbasis peristiwa daripada perhitungan per bingkai. Pada 60 FPS, total anggaran untuk setiap bingkai adalah 16,67 milidetik (ms). Bahkan perhitungan per bingkai yang tampaknya sepele dapat menggunakan sebagian besar dari anggaran tersebut.
Temukan cara untuk memecah kode yang berjalan lama menjadi potongan yang lebih bisa dikelola. Jika sepotong kode memerlukan 100 ms untuk dieksekusi dan Anda menjalankannya setiap bingkai, permainan Anda hanya dapat berjalan pada 10 FPS. Jika Anda memutuskan untuk hanya menjalankan kode sekali per detik di permainan yang otherwise berjalan pada 60 FPS, 59 dari bingkai Anda tiba setelah 16,67 ms... dan kemudian satu setelah 100 ms, yang menyebabkan jeda yang mengejutkan.
Sebaliknya, selidiki bagaimana Anda dapat memecah kode tersebut. Mungkin Anda bisa melakukan 5 ms pekerjaan per bingkai, gunakan task.wait(), dan memiliki perhitungan yang selesai setiap 20 bingkai sambil tetap menjaga 60 FPS. Multithreading, kadang-kadang disebut Parallel Luau, juga dapat membantu.
Gunakan metode RBXScriptConnection:Disconnect() untuk menghentikan fungsi agar tidak dipanggil secara tidak perlu saat event berikutnya terjadi.
Jangan memanggil metode yang sama setiap kali Anda membutuhkan nilai. Panggil metode sekali, simpan nilai, dan kemudian tulis ulang nanti sesuai kebutuhan.
Jangan menyimpan semuanya di ReplicatedStorage. Klien memuat semua yang ada di kontainer ini. Sebaliknya, gunakan ServerStorage untuk apa pun yang tidak perlu diakses klien.