Debug game yang dibuat AI

Klasifikasikan kegagalan sebelum meminta perbaikan

Identifikasi langkah paling awal yang gagal: discovery project, impor, parsing atau kompilasi, startup scene, input pemain, status gameplay, ekspor, atau peluncuran target. Gejala berikutnya mungkin merupakan konsekuensi kegagalan pertama. Simpan versi engine, revisi project, target, dan reproduksi persis bersama.

Misalnya, scene yang tidak pernah dimulai tidak dapat menunjukkan apakah tombol restart berfungsi. Browser yang tidak dapat mengambil game package tidak dapat menguji controller. Arahkan error ke batas yang tepat sebelum mengubah kode; ini mencegah loop perbaikan mengumpulkan patch yang tidak terkait sementara prasyarat awal masih rusak.

Tangkap error engine bermakna pertama

Di Godot, gunakan panel debugger dan output runtime yang relevan. Di Unity, periksa error kompilasi dan runtime secara terpisah, lalu tunggu editor siap sebelum menafsirkan hasil play. Pertahankan stack atau lokasi yang mengidentifikasi script gagal serta operasi yang memicunya.

Kirim cuplikan terfokus beserta konteks scene atau objek yang relevan kepada agen. Hindari log besar tanpa pemisahan yang mengaburkan error pertama, tetapi simpan catatan lengkap secara lokal untuk pemeriksaan nanti. Redaksi kredensial dan data pribadi. Laporan berguna menyebutkan tindakan pemain, hasil yang diharapkan, dan laporan engine sebenarnya.

Kurangi reproduksi tanpa mengubah persyaratan

Mulai dari keadaan project yang dapat dipulihkan dan isolasi scene atau aksi terkecil yang masih menunjukkan cacat. Pertahankan controller, aturan collision, atau batas penyimpanan nyata yang terlibat. Menghapus sistem yang gagal sepenuhnya mungkin menghasilkan run bersih tetapi menghilangkan perilaku yang perlu diperbaiki.

Brief di bawah adalah template diagnostik orisinal. Isi detail yang diamati, jangan meminta model mengasumsikan penyebab. Minta satu penjelasan yang diusulkan dan perubahan dengan cakupan sempit. Setelah tes selesai, sambungkan kembali perjalanan pemain penuh agar perbaikan lokal tidak menyembunyikan transisi scene yang rusak.

Project revision: <record actual revision>
Engine and target: <record actual environment>
Steps: launch -> start round -> perform the failing action
Expected state: <specific result>
Observed state: <specific result>
First engine error: <relevant error and location>
Inspect the referenced scene and script before editing.
Propose one cause, make a scoped fix, then repeat these steps.
Preserve the required behavior and report any remaining failure.

Selidiki layar kosong secara berlapis

Tentukan lebih dahulu apakah engine dimulai dan scene yang dimaksud dimuat. Lalu periksa pemilihan kamera, dimensi viewport, visibilitas objek, posisi, dan overlay yang menutupi scene. Gunakan status engine dan capture nyata bersama-sama: gambar saja mungkin tidak menunjukkan scene pause, berada di luar kamera, atau kosong.

Terapkan input dan amati apakah status berubah meskipun tidak ada tampilan. Jika posisi berubah tetapi gambar tidak, fokus pada rendering atau referensi scene. Jika keduanya tidak berubah, selidiki startup dan input sebelum menyesuaikan artwork. Kaitkan setiap hipotesis dengan observasi agar agen tidak menulis ulang kedua sistem secara tidak perlu.

Lacak input melalui transisi gameplay

Ikuti aksi dari focus dan mapping ke handler, lalu ke status yang seharusnya berubah. Periksa status pause dan intersepsi UI sebelum menyalahkan matematika gerakan. Kegagalan restart dapat disebabkan handler yang hilang, referensi scene usang, atau status yang tidak pernah di-reset.

Setelah perbaikan, uji aksi dari lebih dari satu status yang relevan: peluncuran pertama, setelah menang, dan setelah kalah bila berlaku. Periksa handler duplikat atau objek usang yang hanya muncul setelah ronde berulang. Miniflow lengkap kecil dapat melokalisasi cacat siklus hidup ini lebih efektif daripada menguji tombol secara terpisah berulang kali.

Pisahkan pemuatan browser dari logika game

Untuk web export Godot, periksa panel network dan console browser sebelum mengedit kode gameplay. Pastikan HTML, JavaScript, WebAssembly, dan game package yang diekspor dimuat dari lokasi yang dimaksud. Bandingkan pengaturan hosting dengan dokumentasi web export resmi, termasuk persyaratan konfigurasi thread yang dipilih.

Pertahankan nama file pendamping yang diekspor konsisten dan uji artefak, bukan campuran file lama dan baru. Jika project yang salah muncul, periksa cache service-worker di browser uji. Kemudian uji input dan verifikasi konten bergerak. Canvas yang tidak kosong hanyalah pemeriksaan rendering awal, bukan bukti loop game bekerja.

Periksa kegagalan khusus ekspor pada target

Saat editor berfungsi tetapi build terdistribusi gagal, bandingkan pilihan scene startup, resource yang disertakan, konfigurasi, dan log target. Pertahankan hash artefak persis agar ekspor berikutnya tidak membatalkan catatan reproduksi. Uji dengan keadaan awal bersih sebelum mengandalkan save atau cache editor.

Jangan mengubah mekanik inti untuk menyelesaikan file terpaket yang hilang. Perbaiki batas packaging dan ulangi jalur penerimaan yang sama pada build target. Untuk artefak desktop, gunakan sistem operasi sebenarnya; untuk artefak browser, gunakan browser dan setup hosting yang dituju. Cross-export saja tidak menetapkan perilaku target.

Tutup perbaikan dengan hasil sebelum dan sesudah

Pertahankan reproduksi yang gagal, diff terbatas, dan aksi berulang yang sekarang menghasilkan status yang diharapkan. Tambahkan pemeriksaan regresi pada batas yang menyebabkan cacat, lalu ulangi loop game di sekitarnya. Catat koreksi manual dan permintaan yang dikonsumsi perbaikan yang tidak berhasil.

Contoh di sini adalah prosedur diagnostik, bukan kasus gagal-dan-diperbaiki yang diterbitkan. Gunakan untuk membuat laporan konkret dari project Anda. Saat gejala yang sama bertahan setelah proposal berulang, hentikan loop otomatis dan kumpulkan observasi yang hilang, alih-alih melakukan rewrite luas tanpa bukti baru.

Pertanyaan umum