Pengembangan game dengan AI

Mulai dengan loop game kecil yang lengkap

Target awal yang berguna adalah satu aktivitas dengan awal dan akhir yang dapat diamati: mulai ronde, bergerak atau memilih, menghadapi tantangan, mencapai menang atau kalah, lalu restart. Tentukan apa yang dilihat pemain pada setiap transisi sebelum meminta agen menulis file. Layar judul yang dipoles tidak membuktikan bahwa loop bekerja.

Pilih satu platform target dan sekumpulan kecil perangkat input. Perlakukan level tambahan, jaringan, dan konten prosedural sebagai cakupan berikutnya. Ini membuat prototipe yang gagal dapat didiagnosis: Anda dapat membedakan aturan collision yang rusak dari fitur yang belum selesai, alih-alih terus memperluas prompt.

Pilih alur kerja, kemudian engine

Untuk proyek 2D kecil yang orisinal, mulai dengan mengevaluasi CLI Godot yang terdokumentasi untuk loop inspect-edit-run. Unity adalah titik awal yang berguna ketika proyek atau tim yang ada sudah bergantung pada alur kerja editornya. Kemampuan Anda memelihara hasil harus memandu pilihan sebesar prototipe pertama.

Bandingkan pekerjaan yang diperlukan untuk mereproduksi kegagalan di mesin Anda. Titik awal terbaik adalah yang struktur proyek, prasyarat build, dan error-nya dapat Anda jelaskan. Agen tidak menghapus tanggung jawab atas upgrade engine atau paket pihak ketiga.

Pisahkan akses model dari alat engine

Agen memiliki dua koneksi berbeda: layanan model yang menghasilkan penalaran dan edit, serta alat lokal yang memeriksa atau mengoperasikan proyek. Godot MCP dan Unity MCP berada di sisi alat. Menginstal salah satunya tidak memilih penyedia model atau membuktikan integrasi gateway.

Pilih koneksi model di client agen dan koneksi engine di pengaturan alatnya. Verifikasi masing-masing secara independen dengan operasi kecil. Jika path proyek lokal salah, perbaiki path tersebut; mengubah endpoint model tidak akan membuat scene yang dimaksud muncul.

Buat brief pertama dapat diuji

Sebutkan scene, aksi pemain, transisi status, dan perilaku persistensi yang diperlukan. Minta implementasi terkecil yang memenuhi persyaratan tersebut serta daftar eksplisit keputusan yang belum terselesaikan. Gunakan brief ilustratif di bawah sebagai titik awal dan ganti cakupannya dengan game yang benar-benar Anda inginkan.

Catat brief awal tanpa perubahan. Saat menambahkan persyaratan, beri label sebagai perubahan cakupan. Saat menjelaskan kegagalan atau mengedit file sendiri, beri label sebagai intervensi. Ini mempertahankan perbedaan antara satu prompt awal dan banyak iterasi model serta alat yang mungkin mengikutinya.

Deliver one original 2D room with start, play, win/loss, and restart states.
Use project-owned placeholder art. Preserve the chosen engine version.
Record each edit, tool result, failed check, and human intervention.
Stop before downloads, purchases, uploads, or publishing.
Report unfinished requirements with their reproduction steps.

Kerjakan perubahan yang dapat ditinjau

Setelah scaffold awal, minta satu perilaku pada satu waktu: gerakan, lalu collision, kemudian transisi akhir ronde. Tinjau file yang berubah dan jalankan jalur penerimaan yang sama setelah tiap perubahan. Pertahankan keadaan proyek yang diketahui bekerja sebelum menambahkan paket eksternal atau mengubah pengaturan impor.

Agen harus menerima error yang relevan, konteks scene, dan perilaku yang diamati, bukan hanya permintaan untuk mencoba lebih keras. Saat gejala yang sama bertahan setelah edit berulang, berhenti dan isolasi batasnya. Resource impor yang hilang dan referensi node yang salah memerlukan perbaikan berbeda meskipun keduanya menghasilkan scene kosong.

Perlakukan aset dan lokalisasi sebagai input produksi

Simpan manifest aset dengan sumber, izin, identitas penulis atau alat, modifikasi, dan penggunaan yang dimaksud. Tinjau sprite pada skala gameplay, termasuk transparansi, alignment frame, kontras, dan kecocokan collision. Gambar yang tampak masuk akal tidak otomatis menjadi sprite sheet yang dapat digunakan.

Buat string yang dihadapi pemain dapat dituju dengan pengenal stabil. Sediakan konteks terjemahan dan lindungi argumen pemformatan. Gambar, audio, font, dan teks terjemahan masing-masing perlu ditinjau sebelum distribusi. Catat pengeluaran pembuatan gambar secara terpisah dari pekerjaan coding model teks; lisensi aset maupun lisensi engine tidak membuktikan hak atas setiap file dalam proyek.

Buktikan setiap status deliverable secara terpisah

Demo yang dapat dimainkan memerlukan seseorang menyelesaikan loop yang dimaksud. Ekspor memerlukan artefak yang dibuat. Ekspor yang diuji juga memerlukan peluncuran artefak tersebut di platform target. Pengajuan dan rilis Steam adalah status platform berikutnya. Gunakan label tersebut secara tepat saat membagikan progres.

Pertahankan identitas build, input pengujian, screenshot dari gameplay nyata, dan kegagalan yang tersisa. Capture browser harus menunjukkan gameplay yang berubah setelah input, bukan sekadar layar pemuatan. Executable Windows yang diekspor di OS lain tetap memerlukan verifikasi Windows. Lihat panduan Steam untuk persyaratan akun dan penjadwalannya yang terpisah.

Apa yang ditunjukkan contoh Playco tentang alur kerja

Kisah pelanggan OpenAI pada 3 September 2026 menjelaskan Playco menggunakan Astra di Playbot, sebuah IDE yang terhubung dengan engine game. Tim tersebut mengiterasi fondasi grey-box sebelum membuat prototipe bertema. Ini adalah kisah pelanggan yang diterbitkan vendor, bukan benchmark APIsRouter.

Pelajaran praktisnya adalah bentuk alurnya: tetapkan mekanik gameplay, lalu ubah presentasi sambil mempertahankan baseline bersama. Pisahkan preferensi kreatif dari perbaikan cacat agar Anda dapat melihat hasil setiap iterasi. Baca kisah asli untuk hasil yang dilaporkan, bukan memperlakukannya sebagai prakiraan untuk game Anda.

Periksa prototipe Godot lokal

Switchyard adalah puzzle sirkuit tiga ruangan kecil yang dibuat dalam proses pengembangan Codex lokal. Proyek sumber mencakup pergerakan karakter, switch, pintu, sel yang dapat dikoleksi, penyelesaian ruangan, kalah dan restart, pengaturan, serta progres yang dipersistenkan. Pemeriksaan engine otomatis menjalankan loop gameplay dan proses terpisah membuka kembali penyimpanan. Screenshot di bawah adalah capture viewport Godot aktual, bukan concept art.

Run yang dicatat menggunakan Godot 4.5.1. Identitas model dan penagihan API tidak dapat diamati, jadi ini tidak disajikan sebagai benchmark performa atau biaya Astra. Sumber dan PCK yang dapat diunduh menunjukkan proyek lokal; PCK memerlukan Godot. Build Windows mandiri, ekspor browser, playtest manusia, dan rilis Steam tetap merupakan pekerjaan terpisah. Contoh ini menunjukkan artefak konkret yang perlu diminta dari agen sebelum membuat klaim deliverable.

Pilih panduan berikutnya berdasarkan bottleneck

Mulai dari pemilihan engine jika lingkungan belum diputuskan, halaman setup MCP jika discovery alat gagal, atau panduan debugging jika proyek terbuka tetapi berperilaku salah. Gunakan panduan biaya ketika perbaikan berulang mendominasi pengeluaran; memperkecil cakupan mungkin lebih penting daripada mengganti model.

Panduan ini menyediakan alur kerja berbasis sumber dan contoh ilustratif, bukan peringkat engine yang terukur. Eksperimen Astra yang ditautkan menjelaskan bukti yang diperlukan untuk kasus spesifiknya. Untuk proyek Anda sendiri, pilih langkah berikutnya yang menyelesaikan blocker konkret dan pertahankan hasilnya sebelum memperluas game.

Pertanyaan umum