Merhaba. Kısa süre önce tek başıma ‘Sumbi’ adlı bir mobil oyun yaptım. Jeju haenyeo’larının denizden ürün toplama işinden ilham alan dikey bir roguelike. Tek bir nefesle denize girip deniz ürünleri topladığınız, biraz daha açgözlülük mü edeceğinize yoksa şimdi geri mi döneceğinize karar verdiğiniz bir oyun.
2 Temmuz’da tasarıma başladım, 9 Temmuz’da ilk build’i Google Play’e yükledim; oynarken eksik bulduğum kısımları sürekli düzelterek 19 Temmuz’da v1.1 build’ini de production’a yükledim.
Başından beri merak ettiğim şey yalnızca “Yapay zeka kodu ne kadar hızlı yazar?” değildi. Birden fazla yapay zeka modeline farklı roller verip onları tek bir geliştirme ekibi gibi çalıştırırsam, gerçekten yayımlanabilecek bir oyunu nereye kadar yapabilirim? Bunu denemek istedim.
Nasıl bir oyun?
‘Sumbi’ adını, haenyeo’ların dalıştan sonra su yüzüne çıkıp verdikleri ıslığa benzeyen nefes olan ‘sumbi sesi’nden alıyor.
Bir tur yaklaşık 10–30 saniye sürüyor. Tek elle haenyeo’yu hareket ettirerek daha derine iniyor veya çevredeki deniz ürünlerini topluyorsunuz. Topladıklarınızı eksiksiz götürebilmek için su yüzeyine sağ salim ulaşmanız gerektiğinden, biraz daha risk alıp almamayı ya da hemen geri dönmeyi sürekli tartıyorsunuz. Yüzeye çıktığınızda topladıklarınız hesaplanıyor; akciğer kapasitesini, paletleri, ağ torbasını ve gözlem yeteneğini geliştirip yeniden dalıyorsunuz.
Her turda üç yetenekten birini seçtiğiniz roguelike draft sistemi, 60 türden oluşan deniz ürünleri koleksiyonu, ekipman ve gelişim ağacı, haenyeo rütbe yükseltmeleri ve 100 metreye kadar uzanan bir nefes mağarası ekledim. Kontrolleri basit tuttum; ancak dalışları tekrarladıkça hedeflenen rekorların ve build’lerin değişmesini sağladım.
Yapay zekayı tek bir her şeyi yapan geliştirici olarak kullanmadım
Tek bir model tasarımdan uygulamaya ve kendi denetimine kadar her şeyi üstlenirse, kendi varsayımlarını kolayca doğru kabul edebiliyor. Bu yüzden rolleri şöyle ayırdım.
- Fable 5: Oyun yapısı ve özellik tanımı, ekonomi dengesi hedefleri, tamamlanma koşullarının tasarımı
- Opus 4.8: Flutter·Flame uygulaması, test yazımı, hata ayıklama
- Fable 5: İlk yazılan teknik şartnameyle uygulama sonucunu yeniden karşılaştırıp eksikleri ve regresyonları kontrol etme
- Codex GPT-5.5: Kodu ve değişiklikleri bağımsız olarak inceleyip edge case’leri belirtme
İş akışı genel olarak tasarım → uygulama → asıl tasarımcının yeniden doğrulaması → bağımsız kod incelemesi → otomatik testler ve pratik oynama şeklindeydi.
Deneyince, prompt’u havalı yazmaktan daha önemli olanın önce doğrulanabilir tamamlanma koşulları belirlemek olduğunu gördüm. “Gelişim hissini iyi yap” demek yerine ilk 10 dakikadaki satın alma sayısı, ilk rütbe yükseltmesine kadar geçen süre, hiçbir gelişim aralığında bir şey satın alınamayan sürenin uzayıp uzamadığı gibi şeyleri sayılarla tanımladım. Ardından ekonomi simülatörü ve testlerle doğruladım.
Şu anda 627 otomatik test var ve hepsi geçiyor. Flutter statik analizi de uygulama kodu, testler ve araçlar kapsamında hatasız geçiyor.
Yapay zekanın ikna edici biçimde yanıldığı örnekler
İlk tasarım doğrudan eğlenceli bir oyuna dönüşmedi.
İlk sürümde bir turda toplanabilecek hedef sayısı yalnızca 5–9’du. Toplama oyunu olmasına rağmen deniz boş görünüyordu. Kendim oynayınca bu yapıyı çöpe attım. Geliştikçe alanın daha zenginleşmesini ve toplanan yerlerde deniz ürünlerinin yeniden büyümesini sağlayacak şekilde değiştirdim. Belirli gelişim build’lerinde bir turda yaklaşık 40’a kadar ürün toplanabiliyor.
Gelişim ağacı da benzerdi. 290 düğüm vardı ama gerçek oynanış neredeyse düz bir çizgi gibiydi. Yapay zeka “290 düğüm” gereksinimini karşılamıştı; ancak seçim yapmanın eğlencesini üretmiş sayılmazdı. Sonunda üç uzmanlaşma yolunu ve kalıcı düğüm yapısını yeniden ayırdım.
Yapay zeka hızlı şekilde çok kod üretiyor; ama eğlenceyi ve öncelikleri garanti edemiyor. Oyunu bizzat oynayıp “bu eğlenceli değil”, “özellik çok ama sonraki hedef görünmüyor” diye net şekilde kesip atmak hâlâ insanın işi.
Görsel ve ses için de kendi pipeline’ımı kurdum
Haenyeo karakteri, deniz ürünleri, ekipman ve kart ikonları gibi ana görsel asset’leri GPT görüntü üretim API’siyle oluşturdum. Üretilen sheet’leri olduğu gibi kullanmadım; chroma key temizleme, kare hizalama, boyut standardizasyonu ve piksel kuantizasyonundan geçen bir düzeltme pipeline’ına soktuktan sonra kontrol ettim. Arka plan, kabarcıklar ve ışık huzmeleri gibi öğelerin çoğunu kodla çizdim.
Ses için dış asset toplamak yerine Dart koduyla WAV sentezledim. Dalış bittiğinde duyulan sumbi sesi, oyunun adıyla bir turun sonunun buluştuğu ana ses olarak konumlandı.
Yaptıktan sonra değişen düşüncelerim
Sıklıkla “Yapay zeka iyi yönlendirilirse iyi iş çıkarır” denir. Bu sefer bundan daha çok “yanıldığında yakalayacak bir yapı olmalı” dersini öğrendim.
Tasarımcıyı, uygulayıcıyı ve denetçiyi ayırdım; farklı bir modelin planı ve kodu agresif biçimde incelemesini sağladım. Son kararı sayılara, testlere ve gerçek oynanışa bıraktım. Bu yöntem, tek bir modelle uzun bir sohbet sürdürüp her şeyi ona bırakmaktan çok daha istikrarlıydı.
Yapay zeka hızlansa da tek kişilik geliştirmenin darboğazı ortadan kalkmadı. Bunun yerine darboğazın yeri kodlamadan karara kaydı. Neyi tutup neyi atacağıma, oyunun neden şu anda eğlenceli olmadığına karar vermek en uzun süren iş oldu.
Google Play
https://play.google.com/store/apps/details?id=com.kinderia.sumbi
Hâlâ tek başıma yaptığım bir oyun olduğu için pek çok eksiği var. Eğlenceli olup olmadığı, gelişim menüsünün fazla karmaşık olup olmadığı konusunda görüşlerinizi duymak isterim. Geliştirme yöntemi veya modellere göre rol paylaşımıyla ilgili sorularınızı da rahatça bırakabilirsiniz.
Henüz yorum yok.