HİZMET 6: Oyun Yapımı: Mobil Casual, Giydirme & Tarayıcı Oyunları

Bir oyunun maliyeti kod satırıyla değil, oynanabilir hâle gelene kadar biriken kararlarla belirlenir: kaç varyant çizilecek, skor neye göre verilecek, satın alma sunucuda mı doğrulanacak, çocuk kullanıcı varsa hangi ekran hangi kapının arkasında duracak. Bunların hiçbiri motor seçmekle çözülmez. Ben oyunu bir yazılım ürünü gibi ele alıyorum: içerik hattı, skor matematiği, sunucu doğrulaması ve yayın uyumu tek bir mühendislik problemi olarak kuruluyor.

Bu kalem tek fiyatla anlatılamıyor, bu yüzden aralık olarak veriliyor. Basit bir tarayıcı oyunu ile çok dilli, mağazada yayınlanan, satın alma doğrulaması ve çocuk uyumu gereken bir yapım arasında kat kat fark var. Aşağıdaki sayıların hepsi yayınlanmış kendi oyunumdan ve sitemde çalışan oyun hub'ından ölçüldü.

Neden Bu Hizmet?

Casual oyun yapımında en sık görülen hata, işin görselden ibaret sanılmasıdır. Oysa oyunu ayakta tutan şey görünmeyen taraftır: varyantların elle sayılmadan üretilmesi, skorun tutarlı olması, satın almanın istemciye sorulmaması, ve mağazanın çocuk politikalarına uyulması. Bunlar sonradan eklenmez; sonradan eklenmeye çalışıldığında yeniden yazılır.

Mimari Yaklaşımım

1) İçerik Hattını Otomatikleştirmek

Giydirme oyununda içerik hızla büyür: her manken, her kategori, her renk varyantı çarpan etkisi yaratır. Bu sayılar koda elle yazılırsa ilk içerik güncellemesinde yanlışa döner. Bu yüzden varyant tabloları varlık taramasından üretilip koda gömülür — sayı bir insanın hatırladığı değil, diskteki dosyaların ölçüsüdür.

Sprite tarafı da normalize edilir: tek biçime çevrilmiş, paketlere bölünmüş bir kütüphane hem yükleme süresini hem de paket boyutunu öngörülebilir kılar.

2) Skoru Matematiğe Bağlamak

Bir kombin skoru "güzel göründü" ile verilemez; oyuncunun ilerlemeyi anlaması için kuralın tutarlı olması gerekir. Skorlama ayrı bir katmandır: serbest modda dört kategoriden, yarışma modunda tema uyumu eklenerek beş kategoriden puan toplanır ve sonuç 0-100 aralığına normalize edilir. Üzerine kademeli bir nadirlik çarpanı biner.

Bu ayrım önemli: iki modun kategori sayısı farklı olduğu için ham puanlar doğrudan karşılaştırılamaz. Normalizasyon olmadan yarışma sıralaması sessizce bozulur.

3) Satın Almayı Sunucuda Doğrulamak

İstemci "satın aldım" diyorsa bu bir beyandır. Doğrulama sunucuda, platformun kendi imzasıyla yapılır; doğrulanan işlem atomik bir kayıtla yazıldığı için aynı fiş ikinci kez ya da başka bir hesapta kullanılamaz.

Hata durumları ayrıştırılır: gerçekten geçersiz bir fiş ile yapılandırma hatası engellenir, geçici ağ ya da sunucu hatasında ise oyuncu mağdur edilmez. Bu ayrım yapılmazsa ya sahtekârlık geçer ya da parasını ödeyen oyuncu ürününü alamaz.

4) Yayın Uyumunu Baştan Kurmak

Çocuk kategorisinde yayın yapan bir oyunda satın alma ve reklam ayrı mekanizmalardır. Satın alma girişi, dışına dokunarak kapatılamayan bir ebeveyn doğrulamasının arkasındadır: rastgele üretilen bir toplama sorusu, yanlış cevapta yeni soru, geçen doğrulama kısa süre önbellekli.

Reklam tarafında ise koruma farklıdır: reklam bileşeni başlatılmadan önce onay akışı çalışır ve istekler çocuğa yönelik muamele bayrağıyla gönderilir. Bu ikisini aynı kapının arkasında sanmak, denetimde en sık düşülen hatadır.

Sağladığım Çözümler

Yayınlanmış Oyunumdan Ölçülen Sayılar

Aşağıdakiler teklif metni için üretilmiş tahminler değil; mağazada yayınlanmış kendi oyunumun ve sitemde çalışan oyun hub'ının kodundan ölçülmüş değerlerdir.

Fiyat Neden Aralık?

Bu kalemde tek bir rakam vermek dürüst olmazdı. Alt uç, tek dilli ve mağaza dışı bir yapımı; üst uç ise çok dilli, seslendirmeli, satın alma doğrulaması ve çocuk uyumu gereken bir mağaza yapımını karşılar. Aradaki farkı üreten kalemler şunlardır:

Kullandığım Teknolojiler

Flutter ve Flame, Dart, yerel-öncelikli kalıcılık ve bulut senkronu, sunucusuz fonksiyonlar, StoreKit ve Play Developer API ile satın alma doğrulama, ARB tabanlı yerelleştirme, nöral seslendirme hattı, bağımlılıksız JavaScript ve Web Worker, otomatik ekran taşma matrisi.

Bilerek Yapmadıklarım

Proje Çıktıları

Kime Uygun?

Bir oyun fikrini mağazada yayınlanabilir bir ürüne çevirmek isteyen; mevcut oyununda skor tutarsızlığı ya da satın alma sahteciliği yaşayan; çok dilli yayına çıkmak isteyip RTL tarafında zorlanan; çocuk kategorisinde yayın yapacağı için politika uyumundan emin olması gereken; ya da sitesine gerçek oynanan hafif oyunlar eklemek isteyen ekipler için uygundur.

Neden Ben?

Yukarıdaki sayıların hepsi yayınlanmış kendi oyunumdan ölçüldü — varyant sayısı da, skor tavanları da, test sayısı da. Oyunu yalnız yazmadım; mağaza sürecinden, çocuk politikası denetiminden ve üç dilli yayından da geçirdim. Anlattığım her mekanizmanın çalışan bir karşılığı var.

Bunun bir yan faydası şu: hangi kararın maliyeti nereden çıkardığını tahminle değil, yaşayarak biliyorum. Fiyat aralığının alt ve üst ucunu ayıran kalemleri yukarıda tek tek yazmamın sebebi de bu.

Sonuç

Oyun yapımı görsel bir iş değil, kararların biriktiği bir mühendislik işidir. İçerik hattı otomatik değilse ilk güncellemede bozulur; skor normalize değilse sıralama sessizce yanlışlar; satın alma sunucuda doğrulanmıyorsa gelir sızar. Amaç oynanabilir bir yapı çıkarmak değil, büyüdüğünde ayakta kalan bir yapı çıkarmak.