Bir Günde 3B Oyun: Yapay Zekâ Ajanlarıyla BOINGWARD

BOINGWARD, hiç durmadan zıplayan bir pogo sopasının üstündeki paslı bir robotla havada asılı platformlardan oluşan bir kuleye tırmandığın 3B bir mobil oyun. Zıplama tuşu yok: pogo her inişte kendiliğinden fırlıyor, sen sol başparmakla nereye ineceğini, sağ başparmakla nereye baktığını seçiyorsun.

Bu yazı oyunun ilk gününü anlatıyor. 4 Ekim 2026 sabahı 08.47'de ilk commit atıldı, akşam 18.06'da 148'inci. Arada iPhone'a kurulan bir sürüm, elle tasarlanmış bir parkur, kırktan fazla platform türü, madalyalar, başarımlar, yaklaşık bir kilometrelik bir tırmanış modu ve henüz açılmamış bir çevrimiçi yarış sunucusu çıktı. Kodu ben yazmadım; aynı anda çalışan birden çok Claude Code oturumunu yönettim, kararları verdim ve telefonda denedim. Oyun hâlâ geliştiriliyor ve mağazada değil; neyin hazır olup neyin olmadığını aşağıda ayrıca yazdım.

Daha önce Kalecik'i de aynı yöntemle yapmıştım. Bu sefer farklı olan, işin daha büyük olması ve ilk saatte motor değiştirmemizdi.

Başlangıç: bir tasarım paketi

Elimde kod yoktu, bir tasarım paketi vardı: ürün vizyonu, pogo fiziği, mobil kontroller, çok oyunculu yapı, seviye tasarımı, sanat yönü, ekonomi, arayüz akışı, performans bütçeleri ve yol haritası; her biri ayrı bir belge. En işe yarayanı "pazarlık edilemezler" listesiydi:

• Ana hareket pogo zıplaması. Klasik bir zıplama tuşu yok.
• Yarışı beceri belirler; kozmetikler fiziği asla değiştirmez.
• Sıralamalı yarışlarda oyuncular birbirine fiziksel olarak çarpmaz.
• Ödüllü reklam isteğe bağlı olur; her düşüşten sonra reklam yok.
• Paket, servis ya da ücretli SDK sessizce eklenmez; önce karar belgelenir.

Pakette bir de "bunu yapma" klasörü vardı: Fall Guys'a fazla benzediği için reddedilen eski konsept görselleri. Ajanlara yalnızca neyin hedef olduğunu değil, neyin hedef olmadığını da göstermek, sanat yönü tartışmasını baştan kısalttı. Ad da aynı titizlikle seçildi: Pogo Panic, HopBound ve Hopspire gibi adların zaten kullanıldığı görülünce BOINGWARD kaldı. Belgede açıkça yazıyor: aramada çıkmaması marka tescili anlamına gelmez, yayından önce ayrıca kontrol edilecek.

Neden Unity değil, Godot?

Paket Unity 6 ve C# için yazılmıştı. Aynı sabah, ilk commit'ten önce Godot'ya geçtik. Gerekçe, projenin kural dosyasına şöyle yazıldı: Unity'de bir proje aynı anda tek bir editörde açılabiliyor, toplu derleme döngüleri yavaş ve ikili sahne dosyalarıyla .meta dosyaları paralel çalışan ajanlar arasında birleştirme çakışması üretiyor.

Godot'da sahne, kod ve kaynaklar düz metin. Ajanlar editörü hiç açmadan komut satırından içe aktarma yapıp testleri koşabiliyor: godot --headless --path game -s tests/run_tests.gd. Bu, birden çok oturumun aynı projede çalışmasını mümkün kılan şeydi. Seçim Godot 4.7.2, statik tipli GDScript, Mobile renderer ve Jolt fizik motoru oldu.

Paralel oturumlar: herkesin kendi klasörü

İlk plan üç oturumdu ve her birinin sahip olduğu klasörler yazılıydı:

• Lider: pogo fiziği, entegrasyon, testler, dışa aktarma ayarları.
• B: dokunmatik girdi, kamera, arayüz, titreşim, ayarlar.
• C: parkur, görsel stil, ses.

Her oturum kendi git worktree'sinde, kendi dalında çalıştı ve yalnızca kendi klasörlerine dokundu. project.godot ya da pogo ayar dosyası gibi ortak dosyaları yalnızca lider değiştirebildi; diğerleri ihtiyaçlarını raporlarına yazdı. Aradaki bağlantı küçük sözleşmelerle kuruldu. Örneğin girdi düğümü yalnızca iki şey sunuyor: get_move() ile çubuğun yönü ve consume_look_delta() ile kamera sürüklemesi. Pogo da bounced, state_changed ve respawned sinyallerini yayıyor. Kamera ekibi pogonun içini bilmeden, pogo ekibi dokunmatik ekranı bilmeden çalışabildi.

Gün ilerledikçe oturum sayısı arttı: performans, çok oyunculu ağ, platform kiti, bölüm tekrarı, başarımlar, seviye listesi ve maskot animasyonları ayrı dallarda geliştirilip ana dala birleştirildi.

Bir pürüz de çıktı: birden çok oturum aynı Mac'te tam test paketini aynı anda çalıştırınca işlemci doluyor ve zamanlamaya duyarlı ağ testleri rastgele düşüyordu. Çözüm basitti: test betiği makine genelinde bir kilit alıyor, aynı anda yalnızca bir tam test çalışıyor, diğerleri sırasını bekliyor.

Gün boyunca neler oldu

Saatler commit kayıtlarından; dallarda yazılan işlerin saatleri birleştirme saatinden önce olabilir.

Saat	Ne oldu
08.47	Godot temel commit'i: pogo fiziği, testler, deney sahnesi
09.11	iOS dışa aktarma ayarı; hata ayıklama sürümü iPhone 15 Pro Max'e kuruldu
09.38	Parkur, pogo, kamera, arayüz ve ses tek sahnede birleşti
10.01	İlk platform kiti (9 parça)
10.29	Çok oyunculu çekirdek: sürümlü protokol, yetkili yarış sunucusu, botlar
11.23	Özel açılış ekranı
13.40	Kontrol noktaları yalnızca pedine inince sayılıyor
14.17	Bölüm tekrarı: bir bölümdeki bütün denemeler aynı anda oynatılıyor
14.27	Başarımlar ve istatistik servisi
15.38	İkinci platform kiti: 24 tür daha
16.48	Hava numaraları: durum makinesi, ödül, çuvallama
16.58	Seviye listesi ve madalya süreleri
17.34	Ana menü
17.39	Tırmanış modu: elle kurulmuş, yaklaşık 1 km'lik tek bir kule
18.06	Gün içindeki son commit

Testler, "çalışıyor" demek için tek kanıt

Kural dosyasındaki en önemli cümle bence şu: "Bir özellik çalıştırılmadan çalışıyor deme. Yalnızca telefonda doğrulanabiliyorsa tam olarak bunu söyle." Ajanlar çok hızlı kod yazıyor; hızlı yazılan kodun gerçekten çalıştığını gösteren tek şey testler.

Günün sonunda depoda 33 test dosyası ve 15 ayrı test paketi vardı: fizik, arayüz, iki platform kiti, parkur, ağ, tekrar, başarımlar, tırmanış, seviyeler, menü, performans ve maskot animasyonları. Toplamda yaklaşık 26.800 satır GDScript. Hepsinin üstünde bir kontrol daha var: aynı fizik testi saniyede 30, 60 ve 144 karede çalıştırılıyor ve sonuçların birebir aynı olması bekleniyor. Bunun nasıl yapıldığını pogo fiziği yazısında anlattım.

En çok işe yarayan testler parkur botları oldu. Bot, gerçek pogo fiziğiyle her atlamayı tek tek deniyor; bir platform botla bile ulaşılamıyorsa parkur yanlış. Bu bölümü seviye tasarımı yazısında ayrıntılı yazdım.

Telefonun söyledikleri

Bilgisayarda görülmeyen şeyi telefon gösterdi. iPhone 15 Pro Max'te oyun saniyede 60 kare tutuyordu ama kare süreleri düzensizdi: 95. yüzdelik dilim 23,4 milisaniye. Sebep, ekranın 120 Hz yenilenmesiyle 60 karelik sınırın çakışmasıydı; kareler 8, 17 ve 25 milisaniyelik aralıklarla karışık geliyordu. Yüksek yenileme kapatılınca aynı ölçüm 17,3 milisaniyeye indi. 120 karelik mod daha sonra fizik enterpolasyonuyla, ayarlardan seçilebilir olarak geri geldi. Kalecik'te 120 Hz'in telefonu ısıttığını görmüştük; o hikâye ayrı bir yazıda.

Benim payım

Ajanlar kodu yazdı ama yönü ben belirledim. Fall Guys'a benzeyen görselleri reddettim. Hava numaraları fikri benim bir cümlemden çıktı: "havalı hareket çekerse daha yüksek zıplasın." Ajan bunu riskli ve isteğe bağlı bir ödül sistemine çevirdi; numara tasarımı yazısında ayrıntısı var. Her ara sürümü telefonda denedim; çok oyunculu sunucu da telefonun internet paylaşımı üzerinden sekiz botla gerçek bir ağda sınandı. O testin bulduğu hatayı çok oyunculu yazıda anlattım.

Ne hazır, ne değil

Bir günde çok şey çıktı ama hepsi bitmiş değil. Dürüst liste:

• Oynanabilir: Spire parkuru, tırmanış modu, madalyalar, başarımlar, bölüm tekrarı, ayarlar.
• Kodda var, oyuncuya kapalı: Çevrimiçi yarış. Sunucu ve testler hazır; menüdeki düğme gizli.
• Yarım: Hava numaralarının fiziği ve animasyonu hazır, dokunmatik NUMARA düğmesi henüz girdiye bağlanmadı.
• Ölçülmedi: Herhangi bir Android cihazda performans ve iPhone'da beş dakikalık ısınma eğilimi.
• Mağaza: Oyun App Store ya da Google Play'de değil; menüler şimdilik yalnızca İngilizce ve Türkçe.

Güncel durumu BOINGWARD sayfasında tutuyorum.

Serinin diğer yazıları

1. Godot'da Pogo Fiziği: Kendiliğinden Zıplayan Karakter
2. Ölçülmüş Metriklerle Seviye Tasarımı ve Test Botu
3. Risk ve Ödül: Pogo Oyununda Hava Numaraları
4. Mobil Ağda Hile Kontrolü: Godot'da Sunucu Yetkili Yarış

Sık Sorulan Sorular

Bir oyun gerçekten bir günde yapılabilir mi?

Oynanabilir bir prototip, evet; mağazaya hazır bir oyun, hayır. BOINGWARD'ın ilk gününde çekirdek oynanış, iki mod ve çok sayıda test çıktı. Mağaza görselleri, cihaz testleri, dil desteği ve çevrimiçi modun açılması gibi işler hâlâ sürüyor.

Yapay zekâ ajanlarıyla oyun yaparken Unity mi Godot mu?

Birden çok ajanı aynı projede paralel çalıştıracaksanız Godot'nun düz metin dosyaları ve editörsüz test çalıştırma imkânı büyük kolaylık. Unity'de tek editör kilidi ve ikili dosya birleştirmeleri bu düzeni zorlaştırıyor. Tek bir oturumla çalışıyorsanız fark daha küçük.

Paralel Claude Code oturumları birbirinin işini bozmuyor mu?

Kurallar yoksa bozuyor. Burada işe yarayan üç şey oldu: her oturumun kendi worktree'si ve kendi klasörleri, ortak dosyaları yalnızca liderin değiştirmesi ve oturumlar arasındaki küçük, yazılı sözleşmeler. Aynı anda tek tam test çalıştıran kilit de rastgele düşen testleri bitirdi.