Pengujian Game Otomatis dengan AI IDE + Engine MCP: Jalur Praktis

Pengujian otomatis dalam proyek game biasanya berjalan pada dua jalur: asersi unit / edit-mode di dalam repositori, dan pemeriksaan yang membutuhkan konteks engine langsung (scene, prefab, hierarki). Skrip UI yang direkam sering rusak saat tata letak berubah. Pendekatan yang lebih tahan lama: dari AI IDE (Cursor, Claude Code, dan sejenisnya), gunakan engine MCP sehingga model dapat membaca dan menulis pohon scene, komponen, dan skrip—mengubah niat pengujian menjadi langkah-langkah yang dapat diulang.

Apa yang Harus Diotomatisasi

Utamakan pekerjaan yang terstruktur, dapat diuji, dan dapat ditinjau dalam diff:

1. Smoke struktural — scene penting dimuat; prefab pemain/musuh memiliki komponen yang diperlukan; akar UI utuh
2. Audit konvensi — folder dan penamaan; tidak ada jalur node hard-coded yang dalam; API publik dan sinyal masih ada
3. Pembuatan kerangka pengujian — Unity Test Framework, scene pengujian Godot, stub unit-test Cocos
4. Pemeriksaan ulang setelah perubahan — setelah edit gameplay, jalankan kembali daftar periksa yang sama terhadap scene dan skrip

Farm perangkat, profiling mendalam, dan QA eksplorasi luas masih menjadi milik alat dan orang spesialis. Jalur MCP mempercepat pemeriksaan terstruktur di sisi editor.

Jalur yang Disarankan

1. Tulis niat sebagai daftar periksa

Bagikan daftar tersebut dengan manusia dan model. Contoh:

• Setelah pemuatan scene utama, Player ada dengan pergerakan yang diaktifkan
• Inventaris dimulai tertutup; saat terbuka, memblokir input dunia
• Prefab musuh memiliki collider + kesehatan, dengan sinyal/event yang diperlukan terhubung

Simpan dalam dokumen repositori seperti TESTING.md dan kembangkan bersama proyek.

2. Hubungkan engine MCP

Instal dan mulai MCP di proyek target; hubungkan dari AI IDE melalui localhost. Panduan:

• Unity MCP
• Godot MCP
• Cocos Creator: 3.x · 2.x

Jauhkan alat bantu pengujian dari build pemain yang dirilis.

3. Jalankan pemeriksaan dan buat kerangka pengujian dalam obrolan

Prompt harus mencakup jalur, ekspektasi, dan batasan:

Buka scene utama, daftar akar Hierarchy; konfirmasi Player dengan komponen gerak/kesehatan. Jika tidak ada, daftar kekurangannya—jangan diam-diam menciptakan sistem lengkap.

Buat draf asersi Test Runner untuk buka/tutup inventaris dengan pesan kegagalan yang dapat dibaca.

Model memeriksa status editor melalui MCP dan mengedit alat bantu pengujian; Anda meninjau diff, menjalankan pengujian secara lokal, lalu menggabungkan.

4. Hubungkan CI setelah stabilitas lokal

Hubungkan perintah yang sudah terbukti (Unity Test Framework, pengujian headless Godot, dll.) ke CI. Gunakan MCP di mesin pengembangan untuk menulis dan memelihara pengujian tersebut; CI menjalankan skrip di repositori untuk hasil yang dapat direproduksi.

Irama

Daftar niat → Audit read-only MCP → Buat/perbarui asersi → Hijau lokal → (opsional) CI
        ↑______________________________________________|
              Jalankan ulang setelah perubahan gameplay atau scene

Commit sebelum edit besar. Saat model menyentuh file pengujian, batasi ke jalur dalam daftar periksa agar diff tetap kecil.

Langkah Berikutnya

1. Masukkan 5–10 niat smoke ke dalam TESTING.md
2. Hubungkan MCP untuk engine Anda; jalankan satu audit scene read-only
3. Buat kerangka asersi pertama, lewati secara lokal, lalu pertimbangkan CI

Juga berguna: Godot MCP vs skrip manual, Alur kerja Unity MCP + Cursor.