Industri game tidak berhenti dan berkembang semakin cepat setiap hari. Seiring dengan pertumbuhan industri, kompleksitas pengembangan juga tumbuh: ada lebih banyak kode dan lebih banyak bug di dalamnya. Oleh karena itu, proyek game modern memerlukan perhatian khusus pada kualitas kodenya. Hari ini kita akan berbicara tentang salah satu cara untuk membuat kode Anda lebih baik - analisis statis, serta bagaimana PVS-Studio membantu dalam praktiknya dalam pengembangan proyek game besar (dan tidak hanya).
" Hal terpenting yang telah saya lakukan sebagai programmer dalam beberapa tahun terakhir adalah secara agresif melakukan analisis kode statis. Bahkan yang lebih berharga daripada ratusan bug serius yang telah saya cegah adalah perubahan pola pikir tentang cara saya melihat keandalan dan kode perangkat lunak. kualitas. "- John Carmack
Kami telah bekerja sama dengan pengembang game besar selama bertahun-tahun dan selama ini kami telah berhasil melakukan banyak hal menarik dan berguna untuk industri game. Ini tidak mengherankan mengingat daftar klien kami dari industri game. Kami memberikan dukungan aktif kepada klien kami: kami membantu mereka mengintegrasikan PVS-Studio ke dalam proses pengembangan mereka sendiri, memperbaiki kesalahan yang ditemukan oleh penganalisis, dan bahkan membuat fitur khusus untuk dipesan.
Selain itu, kami melakukan banyak pengembangan independen penganalisis ke arah GameDev, dan juga mempopulerkan PVS-Studio dengan memberi tahu orang-orang tentang bug menarik yang ditemukan di berbagai video game.
Tentu, bukan tanpa cerita menarik. Beberapa cerita ini akan dibahas dalam artikel ini.
PVS-Studio dan Unity
Salah satu cara kami mempromosikan produk kami adalah dengan menulis artikel tentang mereview proyek open source. Semua orang mendapat manfaat dari artikel ini: pembaca dapat melihat kesalahan yang menarik dalam proyek yang sudah dikenal dan mempelajari sesuatu yang baru untuk dirinya sendiri, kami mendapat kesempatan untuk menunjukkan karya PVS-Studio dalam kode nyata, dan pengembang proyek dapat mempelajari kesalahan dan memperbaikinya sebelumnya.
Perkenalan serius pertama kami dengan Unity dimulai pada tahun 2016, ketika pengembang mesin game ini merilis kode sumber dari beberapa komponen, pustaka, dan demo ke dalam repositori resmi mereka. Secara alami, kami tidak dapat melewati kasus yang "enak" dan ingin menulis artikel tentang memeriksa kode yang telah diatur.
Kemudian kami menemukan bahwa kode Unity3D (pada saat itu mesin disebut demikian) memiliki kualitas yang sangat tinggi, namun, di dalamnya kami berhasil menemukan cukup banyak kesalahan serius untuk menulis artikel .
Dua tahun kemudian, peristiwa lain terjadi - kali ini pengembang Unity merilis kode mesin itu sendiri dan editor untuk membuka akses. Dan seperti sebelumnya, kami tidak bisa lewat dan mengecek kode sumber mesin. Dan untuk alasan yang bagus: kami juga menemukan beberapa kesalahan menarik .
Namun menulis artikel itu jauh dari segalanya. Kami terus mengerjakan PVS-Studio, dan GameDev adalah salah satu area terpenting untuk pengembangan bagi kami. Oleh karena itu, kami ingin pengembang game Unity mendapatkan analisis terbaik dari proyek mereka.
Salah satu langkah untuk meningkatkan kualitas analisis project Unity bagi kami adalah menulis anotasi untuk metode yang ditentukan dalam Unity Scripting API.
Anotasi metode adalah mekanisme khusus yang digunakan di PVS-Studio. Ini memungkinkan Anda untuk menyediakan penganalisis semua informasi yang dibutuhkannya tentang metode tertentu. Ini ditulis dalam kode khusus oleh pengembang penganalisis itu sendiri (yaitu, oleh kami).
Informasi ini bisa sangat berbeda. Misalnya: bagaimana suatu metode dapat memengaruhi parameter yang diteruskan ke sana, apakah metode itu dapat mengalokasikan memori dan apakah ia mengembalikan nilai yang harus diproses. Dengan demikian, anotasi memungkinkan penganalisis untuk lebih memahami logika metode, sehingga memungkinkan penganalisis mendeteksi kesalahan baru dan yang lebih kompleks.
Kami telah menulis berbagai macam anotasi berbeda (misalnya, untuk metode dari namespace Sistem), dan kami senang melengkapinya dengan anotasi metode dari Unity Scripting API.
Kami mulai menambahkan ke daftar anotasi dengan penilaian. Ada berapa metode? Mana yang harus diberi anotasi terlebih dahulu? Ada banyak metode secara keseluruhan, dan kami memutuskan untuk memulai dengan menjelaskan metode yang paling sering digunakan.
Pencarian metode populer dilakukan sebagai berikut: pertama, kami mengumpulkan kumpulan proyek dari GitHub yang menggunakan kapabilitas Unity, dan kemudian, menggunakan utilitas yang ditulis sendiri (berdasarkan Roslyn), kami menghitung panggilan metode yang menarik bagi kami. Hasilnya, kami mendapat daftar kelas, metode yang paling sering digunakan:
- UnityEngine.Vector3
- UnityEngine.Mathf
- UnityEngine.Debug
- UnityEngine.GameObject
- UnityEngine.Material
- UnityEditor.EditorGUILayout
- UnityEngine.Component
- UnityEngine.Object
- UnityEngine.GUILayout
- UnityEngine.Quaternion
- ...
Selanjutnya, tetap memberi anotasi metode kelas-kelas ini. Kami membuat proyek pengujian dan menggali dokumentasi untuk mendapatkan informasi sebanyak mungkin tentang metode ini. Misalnya, kami mencoba meneruskan null sebagai berbagai argumen untuk melihat bagaimana program berperilaku.
Selama pemeriksaan tersebut, informasi menarik yang tidak terdokumentasi ditemukan secara berkala - dan kami bahkan menemukan beberapa bug menarik di mesin. Jadi, saat menjalankan kode seperti ini:
MeshRenderer renderer = cube.GetComponent<MeshRenderer>();
Material m = renderer.material;
List<int> outNames = null;
m.GetTexturePropertyNameIDs(outNames);editor Unity itu sendiri langsung mogok (setidaknya dalam versi 2019.3.10f1). Tidak mungkin, tentu saja, seseorang akan menulis kode seperti itu, tetapi fakta bahwa editor Unity dapat "dihancurkan" dengan menjalankan skrip seperti itu adalah menarik.
Jadi, anotasi sudah ditulis. Setelah memulai analisis, kami segera menemukan pemicu baru. Misalnya, penganalisis mendeteksi panggilan aneh ke metode GetComponent :
void OnEnable()
{
GameObject uiManager = GameObject.Find("UIRoot");
if (uiManager)
{
uiManager.GetComponent<UIManager>();
}
}Peringatan penganalisis: V3010 Nilai kembali dari fungsi 'GetComponent' diperlukan untuk digunakan. - TAMBAHAN SAAT INI UIEditorWindow.cs 22
Metode GetComponent bahkan dengan namanya menyiratkan kembalinya nilai tertentu. Masuk akal untuk mengasumsikan bahwa nilai ini harus digunakan. Sekarang (berkat anotasi baru) penganalisis mengetahui bahwa panggilan "orphan" ke metode ini mungkin menunjukkan kesalahan logis, dan memperingatkan Anda tentang hal itu.
Ini jauh dari satu-satunya pemicu yang muncul di rangkaian proyek pengujian kami setelah penambahan anotasi baru - Saya tidak akan mengutip sisanya agar artikel ini tidak terlalu besar. Hal utama adalah sekarang pengembangan proyek Unity menggunakan PVS-Studio memungkinkan Anda menulis kode yang lebih aman dan lebih bersih tanpa bug.
Jika Anda ingin membaca lebih detail tentang pekerjaan kami dengan anotasi untuk metode Unity, Anda dapat melakukannya di artikel kami: Bagaimana penganalisis PVS-Studio mulai menemukan lebih banyak kesalahan dalam proyek Unity .
Unreal Engine 4
Ketika, pada tahun 2014, pengembang Unreal Engine 4 merilis kode sumber engine ke publik, kami tidak dapat menyiasati proyek ini dan juga menulis artikel tentangnya . Pengembang mesin menyukai artikel tersebut dan memperbaiki bug yang kami temukan. Tetapi ini tidak cukup bagi kami, dan kami memutuskan untuk mencoba menjual lisensi penganalisis kami ke Epic Games.
Epic Games tertarik untuk meningkatkan mesinnya menggunakan PVS-Studio, jadi kami menyetujui perjanjian: kami memperbaiki kode Unreal Engine kami sendiri sehingga penganalisis tidak mengeluarkan peringatan apa pun untuk itu, dan orang-orang dari Epic Games membeli lisensi kami dan sebagai tambahan beri kami penghargaan atas pekerjaan yang kami lakukan.
Mengapa Anda perlu memperbaiki semua peringatan? Intinya adalah bahwa manfaat maksimum dari analisis statis dapat diperoleh dengan mengoreksi kesalahan segera setelah muncul . Saat Anda memeriksa proyek Anda untuk pertama kalinya, sebagai aturan, Anda mendapatkan beberapa ratus (dan terkadang ribuan) peringatan. Di antara semua peringatan penganalisis ini, peringatan yang dikeluarkan untuk kode yang baru ditulis dapat dengan mudah hilang.
Sekilas, masalah ini dapat diselesaikan dengan cukup mudah: Anda hanya perlu duduk dan melewati seluruh laporan, secara bertahap memperbaiki kesalahan. Namun, metode ini, meski lebih intuitif, bisa memakan waktu. Metode menggunakan file penekan jauh lebih nyaman dan lebih cepat.
Menekan file adalah fungsi khusus dari PVS-Studio, yang memungkinkan Anda untuk "menyembunyikan" pemicu penganalisis dalam file khusus. Dalam kasus ini, peringatan tersembunyi tidak akan muncul di log berikutnya: mereka dapat dilihat secara terpisah.
Setelah menerima sejumlah besar pemicu setelah pemeriksaan pertama, Anda dapat menambahkan semua pemicu yang terdeteksi ke file penahan dalam beberapa klik, lalu saat berikutnya Anda memeriksa dengan penganalisis, Anda akan menerima log bersih tanpa satu pun pemicu.
Sekarang peringatan lama tidak lagi dicatat, Anda dapat dengan mudah melihat peringatan baru segera setelah muncul. Kami menulis kode -> memeriksanya dengan penganalisis -> melihat peringatan baru -> memperbaiki kesalahan. Ini adalah cara Anda mendapatkan hasil maksimal dari penganalisis Anda.
Pada saat yang sama, jangan lupa tentang alarm yang ada di file penekan: mereka sama seperti sebelumnya, mereka mungkin berisi peringatan tentang kesalahan serius dan kerentanan. Oleh karena itu, ada baiknya untuk kembali ke peringatan ini secara berkala dan mengurangi jumlahnya.
Skenario ini nyaman, tentu saja, tetapi pengembang di Epic Games ingin kodenya segera diperbaiki, dan mereka menyerahkannya kepada kami.
Dan kami harus bekerja. Setelah memeriksa kode proyek, kami menemukan 1821 peringatan satu tingkat Level_1 dan Level_2. Penguraian sejumlah peringatan membutuhkan pekerjaan serius, dan untuk memfasilitasi seluruh proses ini, kami menyiapkan analisis kode berkelanjutan di server CI kami.
Terlihat seperti ini: setiap malam versi Unreal Engine 4 saat ini dikompilasi di server kami, dan analisis secara otomatis diluncurkan segera setelah pembuatan. Jadi, ketika orang-orang kami bekerja di pagi hari, mereka selalu memiliki laporan penganalisis baru, memungkinkan mereka untuk melacak kemajuan dalam mengoreksi peringatan. Selain itu, sistem seperti itu memungkinkan untuk memeriksa stabilitas build kapan saja dengan menjalankannya secara manual di server.
Seluruh proses memakan waktu 17 hari kerja. Jadwal untuk mengoreksi peringatan adalah sebagai berikut:
Faktanya, bagan ini tidak sepenuhnya mencerminkan pekerjaan kami. Setelah kami memperbaiki semua peringatan, kami menunggu dua hari lagi hingga mereka menerima permintaan penarikan terbaru kami. Selama ini kami terus mengecek secara otomatis Unreal Engine versi terbaru, yang selanjutnya terus diisi ulang dengan kode baru. Dan apa yang kamu pikirkan? Selama dua hari ini PVS-Studio menemukan empat kesalahan lagi dalam kode! Salah satunya sangat serius dan berpotensi menyebabkan perilaku yang tidak jelas.
Tentu saja, kami juga memperbaiki kesalahan ini. Sekarang para pengembang Unreal Engine hanya memiliki satu hal yang tersisa: mengonfigurasi analisis otomatis mereka dengan cara yang sama seperti yang kami lakukan. Sejak saat itu, mereka mulai melihat peringatan setiap hari yang dikeluarkan untuk kode yang baru ditulis. Ini memungkinkan mereka untuk memperbaiki bug dalam kode bahkan pada saat mereka muncul - pada tahap paling awal pengembangan .
Anda dapat membaca lebih lanjut tentang cara kami mengerjakan kode Unreal Engine di blog resmi Unreal Engine atau di situs web kami .
Analisis berbagai game
Apakah saya menyebutkan bahwa kami memeriksa berbagai proyek sumber terbuka dan menulis artikel tentangnya? Jadi, kami hanya memiliki banyak artikel serupa tentang proyek game! Kami telah menulis tentang game seperti VVVVVV , Space Engineers , Command & Conquer , osu! dan bahkan (artikel yang sangat kuno) Doom 3 . Kami juga telah mengumpulkan 10 bug paling menarik dari industri video game.
Kami juga mungkin telah memeriksa sebagian besar mesin open source yang terkenal. Selain Unity dan Unreal Engine 4, proyek seperti Godot , Bullet , Amazon Lumberyard , Cry Engine V berada di bawah pengawasan kami.dan banyak lagi.
Bagian terbaik dari semua ini adalah banyak bug yang kami jelaskan kemudian diperbaiki oleh pengembang proyek itu sendiri. Senang rasanya merasakan bahwa alat yang Anda kembangkan membawa manfaat yang nyata, terlihat, dan nyata bagi dunia.
Anda dapat melihat daftar semua artikel kami, dengan satu atau lain cara yang terkait dengan pengembangan video game di halaman khusus blog kami.
Kesimpulan
Sekian artikel singkat saya. Saya berharap Anda mendapatkan kode yang bersih dan berfungsi dengan benar tanpa bug dan kesalahan!
Tertarik dengan topik analisis statis? Apakah Anda ingin memeriksa kesalahan pada proyek Anda? Coba PVS-Studio .
Jika Anda ingin berbagi artikel ini dengan audiens berbahasa Inggris, silakan gunakan tautan terjemahan: George Gribkov. Bagaimana analisis kode statis membantu dalam industri GameDev .