Godot ile yapay zekâ oyun geliştirme

Düzenlemeden önce proje sınırını tanımlayın

Sahibi olduğunuz bir proje dizini ve izin verilen değişikliklerin yazılı listesiyle başlayın. Ajanın ikinci bir uygulama oluşturmadan mevcut yapıyı genişletebilmesi için sahneleri, komut dosyalarını, varlıkları ve eklentileri envanterleyin. İlk proje durumunu geri alınabilir tutun ve hangi motor ikilisinin açtığını kaydedin.

Açık geçişleri olan ölçülü bir oynanabilir dilim seçin. Örneğin bir odaya giden ve kazanma ya da kaybetme üzerinden geri dönen başlık ekranı tekrarlanabilir bir test verir. Görsel kompozisyonu ve kontrolleri kimin inceleyeceğine karar verin; başarılı ayrıştırıcı veya modelin tamamlanma mesajı deneyimin tutarlı hissettirdiğini kanıtlamaz.

Çalıştırılabilir dosyayı ve desteklenen argümanları belirleyin

Godot'un kararlı CLI dokümantasyonu aşağıdaki komutları sağlar. GODOT_BIN ve PROJECT, Godot ayarları değil bu örnek için seçilen shell değişkenleridir; yer tutucu yolları mevcut çalıştırılabilir dosyanız ve projenizle değiştirin. Proje yolu project.godot içermelidir.

Ek bayraklarla komut dosyası yazmadan önce sürüm ve yardım çıktısını yakalayın. Böylece güncel çevrimiçi dokümantasyonda bulunan bir komutun kurulu derlemenizde bulunduğunu varsaymazsınız. Arızayı incelerken ikili kimliğini sonraki test sonuçlarıyla kaydedin ve sabit tutun. Bu örnek komutlar belgelenmiş CLI biçimlerini kullanır.

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

İçe aktarmayı, ayrıştırmayı ve gerçek oynamayı ayırın

Başsız içe aktarma bir varlık işleme sınırını kontrol eder. Ayrıştırma kontrolü bir komut dosyasını inceler. Normal başlatma oyuna ulaşır ve sahne bağlantılarını ve çalışma zamanı sorunlarını açığa çıkarabilir. Üçünü test geçti diye özetlemek yerine sonuçları inceleme kaydında ayrı tutun.

Aşağıdaki örnek komut dosyası yolu projenizde zaten var olmalıdır. Ayrıştırma kontrolü bilinçli olarak dardır: çalışan çarpışmaları, duyarlı girdiyi veya doğru kalıcılığı kanıtlayamaz. Bir düzenlemeden sonra değiştirdiği davranışı ve hemen öncesindeki ve sonrasındaki geçişi yeniden oynatın. Bu, üretilmiş yardımcı işlevler için çok sayıda yalıtılmış kontrol oluşturmaktan daha bilgilendirici olabilir.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

CLI araçlarını veya MCP'yi bilinçli seçin

Shell yetenekli bir ajan incelenmiş CLI dizisini çalıştırabilir. Godot MCP, kurulumu özel sayfasında açıklanan, proje tarafından sürdürülen ek bir araç arayüzüdür. Her iki durumda da operatör, yazmayı veya işlem başlatmayı onaylamadan önce hangi projenin hedeflendiğini bilmelidir.

Ajanın model sağlayıcı ayarlarını motor araçlarından ayrı tutun. Çalışan yerel bağlantı belirli bir modelin kullanılabildiğini veya ajanın uyumlu bir ağ geçidinin her özelliğini desteklediğini kanıtlamaz. Önce izin verilen en küçük okumayı, sonra geri alınabilir bir sahne değişikliğini ve yalnızca yetkili bir deney içinde eksiksiz oynanış döngüsünü oluşturun.

Arızalara yeterli sahne bağlamı verin

Bir etkileşim başarısız olduğunda ilgili sahne ağacını, komut dosyasını, giriş eylemini ve ilk anlamlı çalışma zamanı hatasını yakalayın. Beklenen geçişi ve gözlemlenen durumu açıklayın. Oyuncunun hareket edemediğini bildiren rapor, oyunun odaklanıp odaklanmadığını, girdinin algılanıp algılanmadığını ve oyuncu konumunun değişip değişmediğini söylemelidir.

Bu kanıta bağlı açıklaması olan küçük bir düzeltme isteyin. Uyguladıktan sonra aynı eylemi tekrarlayın ve yeniden başlatma ile sahne geçişlerinde regresyon inceleyin. Yalnızca hata kaybolduğu için düzeltmeyi kabul etmeyin; etkilenen özelliği devre dışı bırakmak gereksinim karşılanmadan hatayı silebilir.

Dışa aktarma önkoşullarını açıkça hazırlayın

Bir dışa aktarma eşleşen bir ön ayar ve kurulu dışa aktarma şablonları gerektirir. Derlemeden önce export_presets.cfg ve kaynak dahilini inceleyin. Dışa aktarma kimlik bilgilerini gizli tutun. Örnekteki ön ayar adı açıklayıcıdır ve projenizle eşleşmelidir; çıktı dizini önceden var olmalıdır.

Eksik şablonu veya ön ayarı, üretilmiş oyun mantığının yanlış olduğuna dair kanıt değil, ortam sorunu sayın. Hedef platform bulguları belirli bir derlemeye bağlansın diye dışa aktarma günlüklerini ve varlık hash'ini koruyun. Başarılı dışa aktarma önemli bir kontrol noktasıdır, ancak teslim edilen oyuncunun bir turu başlattığını veya tamamladığını kanıtlamaz.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

Hedefte bir teslim mini akışı çalıştırın

Dışa aktarılan oyunu desteklemek istediğiniz işletim sisteminde başlatın. Yeniden açıldıktan sonra başlatmayı, girdiyi, eksiksiz bir turu, yeniden başlamayı, ayarları ve kalıcılığı test edin. Her sonuç için varlık kimliğini, cihaz bağlamını ve gözlemlenen sonucu saklayın. macOS'ta oluşturulan dışa aktarma Windows davranışını kendi başına doğrulamaz.

Web hedefinde tarayıcı yüklemesini ve çalışma zamanı hatalarını da inceleyin, canvas'ı gerçek girdilerle çalıştırın. İçeriğin görünür olduğunu ve gerektiğinde hareket ettiğini doğrulayın. Yerel editör çalışmasının tarayıcı kaynak yüklemesini ve platform kısıtlarını kapsadığını varsaymak yerine amaçlanan barındırma yapılandırmasını test edin.

İncelenecek bir kaynak proje ve yerel yakalama

Yerel Switchyard örneği üç odalı bir Godot bulmacası, otomatik oynanış kontrolleri, kaydet-yeniden aç kontrolleri, ham günlükler, kaynak ZIP'i ve Godot PCK'si sağlar. Yerel yakalamaları gerçek çalışan projeyi iki görünüm boyutunda gösterir. Belgelenmiş komutları tekrarlamak, projeyi yalnızca ekran görüntüsüne bakarak değerlendirmekten daha güçlü bir kontroldür.

Proje, kesin üretim modeli doğrulanmamış bir Codex çalışmasında Godot 4.5.1 kullandı. Bu nedenle Astra karşılaştırması değil, yerel motor iş akışını gösterir. Tarayıcı dışa aktarması eksik dışa aktarma şablonları tarafından engellendi ve PCK bağımsız bir Windows çalıştırılabilir dosyası değildir. Sonraki geliştiricinin neyin test edileceğini bilmesi için bu sınırlar kaynakla birlikte kaydedilmiştir.

Döngüyü incelenebilir bir teslimle kapatın

Teslim, oynanabilir kapsamı, kaynak kimliğini, motor ve şablon sürümlerini, derleme talimatlarını, kabul edilmiş sonuçları ve çözülmemiş kusurları adlandırmalıdır. Test edilmiş varlıktan gerçek yakalamalar ve gönderilen varlıkların kökenini ekleyin. Yalnızca son üretilmiş kod dökümünü sunmak yerine düzeltme denemelerini ve manuel müdahaleleri koruyun.

Temel döngü kabul edildiğinde platform gönderimini düşünmeden önce varlıkları ve yerelleştirmeyi kendi içe aktarma ve oynanış kontrollerinden geçirin. Bu yürüyüş motor dokümantasyonuna dayanır; kurulu sürümünüzde uygulayın ve gerçek sonuçları saklayın. Sonraki geliştirme oturumu aynı bilinen durumdan başlasın diye yeniden üretim adımlarıyla kısa bir çözülmemiş sorunlar listesi tutun.

Sık sorulan sorular