Genel bakış

Aplomb’da tavandan sarkan bir yapıyı dengeliyorsun. Parçaları kollara asarken nereye koyacağını ve hangi sırayla ilerleyeceğini düşünmen gerekiyor. Kol fazla eğilirse parçalar kayıp tepsiye dönüyor. Sonra başka bir sıra deneyebiliyorsun.

Kısa bölümlerde deneyerek öğrenilen, sakin bir bulmaca yapmak istedim. Yanlış bir hamlenin ardından oyuna devam edip dengeyi yeniden kurabiliyorsun. İlerledikçe yeni kurallar geliyor. Hepsi aynı ağırlık ve mesafe ilişkisi üzerine kuruluyor.

Bu projede yaptıklarım

• Bölüm tasarımı: 84 bölümü tasarladım. Her bölümde oyuncunun ne öğrenmesini istediğimi, mekanikleri hangi sırayla tanıtacağımı ve zorluğun nasıl ilerleyeceğini belirledim.
• Test ve iyileştirme: Çözücü, bölüm editörü ve bot testleri geliştirdim. Testlerde gördüğüm sorunlara göre 15 bölümü değiştirdim. Ardından bölümleri hem tek başına hem de oyunun başından itibaren ilerleyerek yeniden test ettim.
• Ürün kararları: Booster’ları, ödülleri ve mağazayı tasarladım. Analitik olaylarını kurdum. Önizleme için bir A/B testi planlayıp botlarla karşılaştırdım. Bu testin verisini SQL ve Excel’le inceledim.
• Geliştirme: Oyun kurallarını ve araçları Unity’de C# ile yazdım. Arayüzü ve görselleri de hazırladım.

Veriyi nasıl topladım?

Geniş ölçekli oyuncu testine erişimim olmadığı için bölümleri, farklı oynama davranışlarını modelleyen botlarla test ettim. Botların hangi varsayımlarla çalıştığını sonuçlarla birlikte paylaştım. Tasarım değişikliklerini aynı koşullarda karşılaştırdım. Bu sonuçlar bot testlerinden geliyor. Gerçek oyuncuların aynı değişikliklere nasıl tepki vereceğini henüz bilmiyorum.

Oynanış

Bir parçanın kolu ne kadar çektiğini ağırlığı ve merkeze uzaklığı belirliyor. Örneğin merkezden iki kanca uzaktaki 3’lük parça, karşı tarafta üç kanca uzaktaki 2’lik parçayı dengeliyor. Ağırlığı görünen bir parçayı kancanın üzerinde tutunca kolun nasıl eğileceğini görebiliyorsun. Ağırlığı “?” ile gizlenen parçalarda bu önizleme yok.

Oyun ekranındaki öğeler

Bu ekran 44. bölümden. Numaralar, aşağıda anlattığım parçaları ve booster’ları gösteriyor.

1 2 3 4 5 6 7 8 9 10

1. 1Asılı yapı. Tavandan sarkan, birbirine asılı kollardan oluşan yapı. Bölümü bitirmek için bütün kolları aynı anda yatay tutmak gerekiyor.
2. 2Tepsi. Asılmayı bekleyen parçalar burada duruyor. Bir parçayı sürükleyip kancaya bırakıyorsun. Kayan parçalar da buraya dönüyor.
3. 3Parça. Üzerindeki sayı ağırlığını gösteriyor. Merkezden uzağa astıkça kolu daha güçlü çekiyor.
4. 4Kol. Merkezinden asılı çubuk. İki tarafı eşit çekildiğinde yatay duruyor. 6. bölümden itibaren fazla eğilirse üzerindeki parçalar kayıyor.
5. 5Kanca. Parçaları ve alt kolları astığın halkalar. Merkeze uzaklığı, asılan ağırlığın kol üzerindeki etkisini belirliyor.
6. 6Alt kol. Başka bir kola asılan kol. Ana kolu, üzerindeki parçaların toplam ağırlığı kadar çekiyor. Önce kendi içinde dengelenmesi gerekiyor.
7. 7Gizli parça. Ağırlığı “?” ile gösteriliyor ve asılınca ortaya çıkıyor. Cam sergisinde, 37. bölümde tanıtılıyor.
8. 8Booster’lar. Terazi, gizli bir parçanın ağırlığını gösteriyor. Kilit, bir kolu üç yerleştirme boyunca sabit tutuyor. Geri Al ise az önce kayan parçaları geri getiriyor. Kilit ve Geri Al 8. bölümde, Terazi 37. bölümde açılıyor.
9. 9Pirinç sayacı. Bölüm bitirerek kazandığın oyun içi para. Sayaca dokununca mağaza açılıyor.
10. 10Galeri düğmesi. Sergileri, salonları, bölüm seçimini ve ayarları açıyor.

Oyun döngüsü

1. BakHangi kol hangi yöne eğik?
2. TartParçayı kancanın üstünde tut, kolun tepkisini gör.
3. AsParçayı bırak. Kol dengeye yaklaşabilir veya parçalar kayabilir.
4. DüzeltKayan parçalar tepsiye döner, sıra yeniden kurulur.

Kayma olduğunda o koldaki parçalar tepsiye dönüyor. O denemeyi artık kaymasız bitiremiyorsun, ama bölüme devam edebiliyorsun. Oyuncunun hatanın ardından sırayı yeniden düşünüp başka bir yol denemesini istedim.

Tamamladığın bölüm, galeride küçük bir asılı yapı olarak kalıyor. Bir serginin 12 bölümünü bitirince yeni salona geçiyor ve 150 pirinç kazanıyorsun. Her bölümü en az bir kez kaymadan tamamlarsan salonun ışığı yanıyor. Booster kullanmış olman buna engel değil.

Bölüm tasarımı

84 bölümü, her biri 12 bölümden oluşan yedi sergiye ayırdım. Her sergi için ayrı bir malzeme ve tasarım odağı seçtim. Bazılarında yeni mekanikler tanıttım. Son sergide ise daha önce öğrenilen mekanikleri, daha dar bir kayma toleransıyla bir araya getirdim.

Serginin ritmini planlamak

Her bölüme başlamadan önce oyuncunun orada ne öğrenmesini istediğimi yazdım. Yeni kuralı kısa bir bölümde tanıtıp sonraki bölümlerde eski kurallarla birleştirdim. “Duvar” dediğim zor bölümlerde bu öğrenmeyi sınadım. Arkasından daha rahat bir bölüm koyarak oyuncuya öğrendiğini kullanabileceği bir nefes alma alanı bıraktım. Cam sergisinden beş örnek:

Öğretici bölümlerin daha kolay tamamlanmasını, duvar bölümlerinin ise daha çok uğraştırmasını hedefledim. Aşağıdaki oran ve süreleri başlangıç hedefi olarak belirledim. Bunlar gerçek oyuncularla doğrulanmış değerler değil. Orta zorluktaki bölümlerle nefes alma bölümleri arasındaki farkı planlamak için kullandım.

İlk sergide bölümün ne öğrettiğine öncelik verdim. Örneğin 6. bölümün puanı 5,2, ama kaymayı ilk kez tanıttığı için onu öğretici bölüm olarak değerlendiriyorum. Süre hedeflerini de gerçek oyuncularla test edebildiğimde yeniden gözden geçireceğim.

Bölümleri tasarlamak ve düzenlemek

Her bölüm için öğretmek istediğim şeyi, bir araya getireceğim mekanikleri ve sergideki yerini belirledim. Sonra çözücü ve bot testleriyle kontrol ettim. Bot sonuçları hedefimden uzaksa düzeni yeniden ele aldım.

Yazdığım bölüm editöründe kancaları, ağırlıkları, alt kolları ve kural kartlarını düzenleyebiliyorum. Bir değişiklikten sonra dengeli yerleşimlerin ve güvenli sıraların nasıl değiştiğine bakıyorum. Bölümü oyunda da açıp anlatmak istediğim kuralın hâlâ anlaşılır olup olmadığını kontrol ediyorum.

1. Kur: Kancaları, ağırlıkları ve alt kolları, bölümde öğretmek istediğim kurala göre yerleştiriyorum.
2. Kontrol et: Çözücünün bulduğu dengeli yerleşimlere ve kaymasız sıralara bakıyorum. Yaptığım değişikliğin hangi seçenekleri açıp hangilerini kapattığını karşılaştırıyorum.
3. Oyna ve düzelt: Kaydetmeden önce bölümü oyunda açıyorum. Öğelerin okunabilirliğini ve hamlelerin ekranda nasıl karşılık bulduğunu kontrol ediyorum. Bot sonucunu da hedefimle karşılaştırdıktan sonra bölüm dosyasını kaydediyorum.

Zorluk puanını nasıl kullanıyorum?

Çözücü, kaç yerleşimin dengede kaldığını ve bunların hangi asılış sıralarında kaymadığını hesaplıyor. Gizli ağırlık, yem parça, kart ve alt kol gibi öğeleri de hesaba katarak bir zorluk puanı veriyor. Bu puanla bölümleri karşılaştırıp uygun olmayan adayları eliyorum. Oyuncunun bir kuralı anlayıp anlamadığını görmek içinse başka kontrollere ihtiyacım var.

Formülün katsayılarını başlangıçta ben seçtim. Bunları gerçek oyuncu verisinden çıkarmadım. Puanı bu yüzden bot sonuçları ve bölümün öğretim amacıyla birlikte değerlendiriyorum. 42. bölümde bu üçüne birlikte bakmak kararımı değiştirdi.

int hidden = def.Tray.Count(p => p.Hidden);
int decoys = Math.Max(0, n - target);
int cards = def.Constraints?.Count ?? 0;
int depth = MobileState.FromDef(def).MaxDepth;
result.D = Math.Log((double)result.P / result.S, 2)
           + 3.0 * (1.0 - result.R)
           + 1.5 * hidden
           + 1.0 * decoys
           + 1.5 * cards
           + 1.0 * (depth - 1)
           + 1.0 * freeCount;
result.Band = BandFor(result.D);
result.Publishable = result.S >= 1 && result.R > 0 && result.D <= 12.0 && !truncated;

public static bool TeachesWeighNearPivot(LevelDef def)
{
    foreach (var hidden in def.Tray.Where(p => p.Hidden))
    {
        bool nearSafe = false, farSlips = false;
        foreach (int hook in def.Root.Hooks)
        {
            var st = MobileState.FromDef(def);
            st.Pieces[hidden.Id].Revealed = true;
            var r = st.Preview(hidden.Id, st.Root.Id, hook);
            if (!r.Available) continue;
            if (Math.Abs(hook) == 1 && !r.WouldSlip) nearSafe = true;
            if (Math.Abs(hook) >= 2 && r.WouldSlip) farSlips = true;
        }
        if (nearSafe && farSlips) return true;
    }
    return false;
}

Öğretimi korumak

İlk bölümdeki el işareti, çözücünün bulduğu güvenli hamleyi gösteriyor. Kayma, gizli ağırlık, kart ve rüzgâr ilk kez geldiğinde kısa bir ipucu çıkıyor. Oyuncu bütün parçaları asıp dengeyi bulamazsa 4,5 saniye sonra asılı parçaları taşıyabileceğini hatırlatan bir mesaj gösteriyorum.

Kâğıt sergisindeki beklenen çözüm sıralarını otomatik testlere çevirdim. Örneğin 6. bölümde ağır parçayı en uca asınca kayma olmalı. Bir düzenleme bunu ortadan kaldırırsa test başarısız oluyor. Bakır’ın giriş bölümü de boştaki kol olmadan çözülememeli. Keçe’de kartları kaldırınca çözüm sayısının artmasını kontrol ediyorum. Bu son test kartların birlikte etkili olduğunu gösteriyor. Her kartı ayrı ayrı ölçmüyor.

Zorluk eğrisi

Grafikte, 15 bölümde yaptığım değişikliklerden sonraki zorluk puanları var. Renkler zorluk bantlarını, noktalar ise duvarın hemen ardından gelen nefes alma bölümlerini gösteriyor. Zorluğu sürekli artırmak istemedim. Yeni serginin kuralını tanıtırken ve zor bir bölümün ardından öğrenileni pekiştirirken baskıyı azalttım.

42. bölüm: sorun, karar, sonuç

42. bölümde iki gizli parçayı asimetrik bir kolla birleştirmek istedim. Bölüm orta banttaydı ve tamamlama hedefim %80’di. Bot testinde ise yalnızca %7’si bitiriyordu. Deneyimli profil bile %3’te kalıyordu. Puan bu sorunu göstermediği için yerleşime daha yakından baktım.

Eski düzen

Botların %7’si geçiyordu

Yeni düzen (oyunda)

Botların %82’si geçiyor

Sorun: ağırlığı öğrenmek ve doğru sırayı bulmak

Gizli 4’lük parçanın son yerleşimde gidebildiği tek kanca +3’tü. Orada 12 birim çekiyor, kayma eşiği ise 6. Erken asınca kol kayıyor. Üstelik iki “?” parçasından hangisinin ağır olduğunu asana kadar bilmiyorsun. Her dengeli yerleşimde 24 sıranın yalnızca 4’ü kaymadan bitiyordu.

Eski düzende parçayı merkeze yakın bir kancada tartıp sonra taşımak veya geri almak mümkündü. Botlar, ağırlığı öğrenmeyle yerleştirme sırasının birlikte zorlaştığı bu düzende takılıyordu. Ben de bu iki kararı yeniden ele aldım. İnsanların aynı yerde zorlanıp zorlanmadığını bu testle öğrenmiş olmadım.

Değişiklik: daha fazla güvenli seçenek

Sağa +1 kancası ekledim ve gizli 4’lük parçayı 3 yaptım. İki gizli parçayı ve asimetrik kolu korudum. Bölümün Terazi’ye gerek kalmadan çözülebilmesini ve orta banttaki yerine yaklaşmasını istedim. Kaymasız sıraların payı 4/24’ten 16/24’e çıktı.

Son yerleşim 3 → −2, 2 → −1, 2 → +1, 2 → +3. Bu gösterim parçaların hangi kancalara gittiğini anlatıyor. Ağırlıkları öğrendikten sonra kullanabileceğin kaymasız sıralardan biri şöyle:

Bu sıranın hiçbir adımında mutlak tork 6’yı aşmıyor. Çözücünün bulduğu yerleşimi güvenle kurabildiğimizi buradan görebiliyoruz. Gizli ağırlıkları nasıl keşfedeceğimizi ise bu sıra tek başına anlatmıyor.

Sonuç ve öğrendiğim şey

İlk karşılaştırmada eski ve yeni düzeni aynı bölüm testiyle ölçtüm. Her düzen için üç bot profili ve üç ayrı rastgele seed kullandım. Her profil her seed’de 300 kez çalıştı. Bu, profil başına 900, düzen başına 2.700 koşu demek. İki düzen birlikte 5.400 koşudan oluşuyor. Tablodaki yuvarlanmış yüzdeler bu ölçüme ait. Çözücünün bulduğu 6 dengeli yerleşimde ağırlıkların dağılımı aynı. Üç ayrı 2’lik parça yer değiştirdiği için çözücü bunları ayrı sayıyor.

Puan 7,5’ten 8,3’e yükseldi, ama botların tamamlaması da %7’den %82’ye çıktı. Yeni kanca olası yerleşim sayısını artırdığı için formül daha yüksek puan veriyordu. Botlar ise artan güvenli sıralar sayesinde daha kolay bitiriyordu. Bu bölümde yalnızca seçenek sayısına bakmanın yetmediğini gördüm. Oyuncunun hangi bilgiyi ne zaman edindiği de zorluğu etkiliyor.

Sonra hata olasılığını, sabrı ve önizlemeye dikkati ayrı ayrı değiştirip tekrar test ettim. Yedi ayarda eski düzenin karma tamamlaması %6,8–7,5, güncel düzeninki %82,0–82,9 arasındaydı. Artış üç profilin her birinde görüldü. Değişiklik, denediğim bot ayarlarında da işe yaradı. Gerçek oyuncular üzerindeki etkisini henüz ölçmedim.

Test ve iyileştirmeler

Bölümlerdeki tasarım varsayımlarımı botlarla sınadım. Önce her bölümü ayrı ayrı, sonra 84 bölümlük ilerlemeyi test ettim. Böylece beklemediğim sıkışmaları bulup değişikliklerin sonucunu aynı koşullarda karşılaştırabildim.

İlk testte gördüğüm sorunlar

İlk testte 12 bölüm, tamamlama hedefinin 10 yüzde puanından fazla altında kaldı. 46 bölüm ise hedefin bu kadar üstündeydi. Rahat veya orta olmasını istediğim bazı bölümler, botları duvar bölümlerinden daha çok zorluyordu.

• 42 ve 70: İkisi de orta banttaydı. Hedefim %80 iken bot sonuçları %7 ve %8 oldu.
• 14, 15 ve 17: Rahat bölüm hedefim %88’di. Sonuçlar %36–45 arasında kaldı.
• 12: İlk serginin finali. Sırayla oynama testinde buraya ulaşan bot koşularının %51,7’si bu bölümde sona eriyordu. Başlangıç grubunun %47,6’sı 13. bölüme ulaşıyordu.
• 68, 78 ve 84: Duvar olarak tasarladığım bu bölümler, hedefimin çok üzerinde tamamlanıyordu.

15 bölümde yaptığım değişiklikler

Arama aracım ağırlık, kanca, alt kol, sabit yük ve rüzgâr değişikliklerini tek tek ve ikişerli deniyor. Çözücü geçersiz adayları eliyor, botlar kalanları oynuyor. Hedefime yaklaşan seçenekler arasında bölümün öğretmek istediği kuralı koruyanı seçtim. 12 bölümü kolaylaştırdım. Fazla kolay kalan üç duvarı da zorlaştırdım.

Grafik ve tablolardaki yüzdeleri yuvarladım. 14. bölüm üst sınırda kaldı. 15. bölüm hâlâ fazla kolay, 47. bölüm ise fazla zor. Bot sonucunun hedefe yaklaşması, bölümün gerçek oyuncular için iyi olduğu sonucunu vermiyor.

Yeniden testten sonra

• Hedefinin çok altında kalan bölüm sayısı 12’den 1’e indi. Kalan bölüm 47. Hedefi %80, sonucu %68.
• Zorluk puanıyla bot tamamlama sıralaması arasındaki ilişki −0,50’den −0,65’e çıktı. Sıralama bu bot modelinde daha tutarlı hâle geldi. Gerçek oyuncuların zorluk deneyimini bununla doğrulamış olmadım.
• Sırayla oynama testinde 13. bölüme ulaşma %47,6’dan %81,8’e çıktı. Oyunu bitirme oranı da %0’dan %14,2’ye yükseldi.
• Bırakmanın en yüksek olduğu bölümler artık çoğunlukla planladığım duvarlar: 20, 36, 12, 68 ve 24. Cam sergisinde 47. bölüm, serginin duvarından hâlâ biraz daha zor.

Bu ilk değişiklikleri oyunun bölüm dosyalarına işledim. Grafikler, aynı bot modeliyle yaptığım ilk karşılaştırmayı gösteriyor. Ardından seçtiğim bölümleri farklı davranış ayarları ve yeni rastgele seed’lerle tekrar kontrol ettim. O çalışmayı aşağıda ayrı anlattım.

Önizleme: botlarla A/B testi

Önizleme, parçayı bırakmadan önce kolun nasıl eğileceğini gösteriyor. Bu yardımı kapatınca botların sonuçlarının nasıl değiştiğine baktım. Deneyin grup atamasını, ölçümlerini ve analiz akışını da bu karşılaştırmayla kontrol ettim.

Hipotez ve deney planı

Önizleme kapanınca daha fazla kayma olmasını, Geri Al ihtiyacının artmasını ve ilk sergiyi bitirmenin zorlaşmasını bekledim. Ana ölçüm olarak 13. bölüme ulaşmayı seçtim. Ekonomiyi kontrol etmek için de pirinçle satın alınan Geri Al sayısını izledim.

• Grup ataması: 10.000 botu, kimliklerinden hesaplanan sabit bir değerle iki gruba ayırdım. Kontrol grubunda önizleme açık, deney grubunda kapalıydı.
• Analiz: Planı testi çalıştırmadan önce yazdım. İki taraflı test ve α = 0,05 kullandım. %95 güven aralıklarını bot kimliği düzeyinde hesapladım. Tamamlama oranlarında normal yaklaşım, deneme başına oranlarda 2.000 tekrarlı bootstrap, ortalamalarda Welch testi kullandım. Bootstrap örneklemesini de bot kimliği düzeyinde yaptım.
• Veri kontrolü: Önce iki grubun da önizlemeyi kullandığı bir A/A testi yaptım. 50/50 dağılımından küçük sapmalar beklenebilir. SRM kontrolünde ki-kare p < 0,001 çıkarsa grup atamasını incelemeden sonucu kullanmıyorum.

A/A testinde gruplarda 5.021 ve 4.979 bot vardı. SRM sorunu veya metriklerde anlamlı fark görülmedi. O koşuda grup ataması ve analiz akışında belirgin bir sorun sinyali bulmadım. Bu kontrol, botların insanlara benzediğini göstermiyor. Ana A/B testinde gruplar 4.984 ve 5.016 bottan oluştu.

Farkı, önizleme kapalı grubun sonucundan açık grubun sonucunu çıkararak hesapladım. Oran farkları yüzde puanı cinsinden. Tablodaki yüzdeler ve ortalamalar yuvarlanmış, farklar ise yuvarlanmamış değerlerden geliyor. Bütün sonuçlar bot simülasyonuna ait.

Bunu nasıl yorumladım?

Önizlemeyi kapatınca deneme başına kayma yaklaşık 2,5 katına çıktı. Pirinçle alınan Geri Al da bot başına 0,30’dan 2,44’e yükseldi. İlk sergiyi bitirme oranı 1,4 yüzde puanı düştü. Bu farkın güven aralığı −2,9 ile +0,1, p = 0,07. Sonuç, küçük bir düşüşle de sıfıra yakın bir farkla da uyumlu. İki ayarın aynı olduğunu buradan söyleyemiyorum.

Bot modelinde önizlemeyi kapatmak, hamle seçiminde kayma riskine verilen ağırlığı azaltıyor. Bot, önizleme kapalı olsa da hamlenin dengeye etkisini koddan hesaplayabiliyor. Dolayısıyla burada ölçtüğüm şey, bu karar modelinde kayma riskini dikkate almanın etkisi. Gerçek oyuncuların önizleme olmadan nasıl düşündüğünü aynı şekilde temsil edemiyorum.

Önizlemeyi varsayılan olarak açık bırakmaya karar verdim. Botlarda kayma ve Geri Al ihtiyacı arttı, ama ilk sergiyi bitirme üzerindeki sonuç belirsiz kaldı. Daha fazla booster tüketilmesini tek başına olumlu bir ürün sonucu olarak görmedim. Bu kararı bot sonuçları ve öğretim hedefimle verdim. Gerçek oyuncularda bir iyileşme ölçmüş olmadım.

// Remote Config can switch the preview off (preview_enabled); then the bot can't look at it either.
bool watching = Tuning.PreviewEnabled && rng.NextDouble() < p.PreviewAttention;

// Firebase A/B Testing splits real players on its own servers. Bots get the same kind of split:
// a bucket from a hash of the experiment name and the player id, so a player never changes group.
public static int Bucket(string experiment, int playerId)
{
    uint h = 2166136261;
    foreach (char c in experiment + ":" + playerId) { h ^= c; h *= 16777619; }
    return (int)(h % 100);
}

İlk plan ve uyguladığım analiz

İlk planı testi çalıştırmadan önce, 8 Ekim’de yazdım. Grup atamasında h2:<bot kimliği> için FNV-1a değerinin 100’e göre kalanını kullandım. 0–49 önizleme açık, 50–99 kapalı gruba gidiyor. Seed 20261008, güncel 84 bölüm ve %30 acemi / %50 sıradan / %20 deneyimli karışımıyla çalıştım. Bölüm başına en fazla iki oturum var. İlk planda ortalamalar için de bootstrap yazmıştım. Uygulamada ortalamalar için Welch testi, deneme başına oranlar için bot kimliği düzeyinde 2.000 tekrarlı bootstrap kullandım. Bu yöntem değişikliğini burada açıkça belirtiyorum.

SQL ve Excel

Önizleme A/B testinde 10.000 bot toplam 402.495 deneme yaptı. Sonuçları üç tabloya aktarıp SQL’le inceledim. Aşağıdaki sorgular SQLite’ta çalışıyor.

• players: Her satır bir botu gösteriyor. Grubu, profili, geçtiği bölüm sayısı, bıraktığı bölüm, kayma sayısı, pirinçle aldığı Geri Al ve kazandığı veya harcadığı pirinç burada.
• attempts: Her satır bir bölüm denemesi. Bölüm numarası, kaçıncı deneme olduğu, kazanma durumu, kayma ve Geri Al sayısı burada.
• levels: Her bölümün sergisi ve zorluk bandı burada. Bantlar tabloda tutorial, easy, medium ve wall olarak kayıtlı.

1. Önizleme kapatılınca ne değişiyor?

-- Önizleme açık ve kapalı gruplar nasıl karşılaştırılıyor?
SELECT ab_group,
       COUNT(*) AS bots,
       ROUND(100.0 * SUM(CASE WHEN levels_cleared >= 12 THEN 1 ELSE 0 END) / COUNT(*), 1) AS reached_13_pct,
       ROUND(1.0 * SUM(slips) / SUM(attempts), 3) AS slips_per_attempt,
       ROUND(AVG(undo_bought), 2) AS undo_bought_avg
FROM players
GROUP BY ab_group
ORDER BY ab_group DESC;

Sorgu ne yapıyor? players tablosunu önizleme açık (h2_preview) ve kapalı (h2_no_preview) olarak ayırıyor. Her grupta bot sayısını, 13. bölüme ulaşma oranını, deneme başına kaymayı ve pirinçle alınan ortalama Geri Al’ı hesaplıyor. CASE WHEN, en az 12 bölüm geçen botları 1, diğerlerini 0 sayıyor.

Ne gördüm? Önizleme kapanınca kayma 2,5 katına çıktı. Pirinçle alınan Geri Al 0,30’dan 2,44’e yükseldi. 13. bölüme ulaşma ise %82,6’dan %81,2’ye, yani 1,4 puan düştü. Bu küçük farkı A/B testi kısmında istatistiksel olarak da inceledim. Sonuç belirsiz kaldı.

2. Botlar hangi tür bölümde bırakıyor?

-- Botlar oyunu hangi tür level'da bırakıyor? (önizleme açık grup)
SELECT l.band,
       COUNT(*) AS bots_quit
FROM players p
JOIN levels l ON l.level = p.stopped_at_level
WHERE p.ab_group = 'h2_preview' AND p.finished = 0
GROUP BY l.band
ORDER BY bots_quit DESC;

Sorgu ne yapıyor? Önizlemesi açık grupta oyunu bitirmeyen botları seçiyor. JOIN ile bıraktıkları bölümü levels tablosunda buluyor. Sonra her bantta kaç botun bıraktığını sayıyor.

Ne gördüm? Bırakan 4.294 botun 3.212’si, yani %75’i bir duvarda bıraktı. Oyundaki 84 bölümün 11’i duvar. Rahat bölümlerde bırakan bot neredeyse yok. Baskının duvarlarda toplanmasını istemiştim. Bu modelde sonuç o plana yaklaştı.

3. Bir bot ne kadar pirinç kazanıyor, ne kadar harcıyor?

-- Bir bot ortalama ne kadar pirinç kazanıyor, ne kadar harcıyor? (önizleme açık grup)
SELECT bot_profile,
       COUNT(*) AS bots,
       ROUND(AVG(brass_earned)) AS earned_avg,
       ROUND(AVG(brass_spent)) AS spent_avg
FROM players
WHERE ab_group = 'h2_preview'
GROUP BY bot_profile
ORDER BY earned_avg;

Sorgu ne yapıyor? Önizlemesi açık gruptaki botları profillerine göre ayırıyor. Her profil için kazanılan ve harcanan pirincin ortalamasını hesaplıyor.

Ne gördüm? Sıradan profil ortalama 1.798 pirinç kazanıp 17’sini harcadı. Deneyimli profil 2.237 kazanıp 1 harcadı. Bu modelde pirinç, harcandığından çok daha hızlı birikiyor. Ekonomi kısmındaki riskin sayısal karşılığı da bu. Botların yalnızca Geri Al satın aldığını, Kilit ve Terazi kullanmadığını burada hesaba katıyorum.

Excel çalışma kitabı

Aynı veriyi Excel’de de inceledim. Players sayfasında her satır bir botu gösteriyor. Diğer sayfaları buradan hesapladım. COUNTIFS ile koşullara uyan satırları saydım, AVERAGEIFS ile ortalamalarını aldım. AB test sayfasında iki grubun genel sonucunu ve profil kırılımlarını karşılaştırdım. Acemi botlarda 13. bölüme ulaşma %71,9’dan %67,8’e indi. Funnel sayfası her bölüme başlayan bot sayısını, Economy sayfası ise sergi başına pirinci gösteriyor.

Funnel!D2 · level’a başlayan bot = bir önceki level’ı geçen bot (önizleme açık)
=COUNTIFS(Players!B:B, "h2_preview", Players!D:D, ">="&(A2-1))
AB test!G3 · A3’teki profilde pirinçle alınan ortalama Geri Al (önizleme açık)
=AVERAGEIFS(Players!I:I, Players!B:B, "h2_preview", Players!C:C, A3)

Bu bölümdeki bütün tablolar bot verisinden geliyor. İnsan katılımcıların sonuçlarını içermiyor.

Analitik ve ürün kararları

Bölüm ve ekonomi kararlarını ileride oyuncu verisiyle inceleyebilmek için Firebase Analytics, Crashlytics ve Remote Config’i kurdum. Bu sayfada paylaştığım sonuçlar yerel bot testlerinden geliyor. Firebase’de toplanmış gerçek oyuncu sonuçları yok.

Veriden karara

Bu tablo, kurduğum ölçümlerle ileride sorabileceğim soruları ve deneyebileceğim değişiklikleri gösteriyor. İki olayın birlikte görülmesi, birinin diğerine neden olduğunu kanıtlamıyor. Yeterli oyuncu verisi toplayabilirsem bu soruları gözlem ve uygun deneylerle inceleyeceğim.

private void Quit(string reason)
{
    var s = Session.State; var d = Session.Current;
    if (s == null || d == null) return;
    if (s.HangCommands == 0 && s.RemoveCommands == 0 && s.MoveCommands == 0) return;
    Analytics.Track("level_quit",
        ("level_id", d.Id), ("duration", Round(Session.LevelSeconds)), ("slips", s.SlipCount),
        ("abs_tau_state", Math.Abs(s.Torque(s.Root))), ("hung", s.HungCount),
        ("t_since_last_slip", _lastSlipAt < 0 ? -1f : Round(Session.LevelSeconds - _lastSlipAt)), ("reason", reason), Fps(), SlowShare(), FpsTarget());
}

Test ayarlarını yönetmek

Remote Config’ten önizlemeyi, gizli parçanın açılma gecikmesini, kayma eşiği payını, değerlendirme isteğini, FPS’i ve deney grubunu yönetiyorum. Fiyatlar ve bölüm düzenleri buradan değişmiyor. Gelen değerler belirlediğim güvenli aralıklarda tutuluyor. Uygulanan ayarı config_applied ile kaydediyorum.

public static bool PreviewEnabled => GetBool(KeyPreviewEnabled);
public static float RevealDelaySeconds => Clamp(GetFloat(KeyRevealDelay), 0.2f, 1.2f);
public static int SlipThresholdBonus => (int)Clamp(GetInt(KeySlipThresholdBonus), 0, 4);
public static bool ReviewPromptEnabled => GetBool(KeyReviewPromptEnabled);

// The bonus only raises a threshold that is already on: a level without slipping stays without it.
public static int SlipThresholdFor(int levelThreshold) => levelThreshold > 0 ? levelThreshold + SlipThresholdBonus : 0;

Ekonomi ve para kazanma

Mağazadaki booster’lar, parçayı senin yerine doğru kancaya asmıyor. Geri Al, kaymanın ardından toparlanmayı sağlıyor. Terazi, bilinmeyen ağırlığı gösteriyor. Kilit de kısa süreliğine kaymayı önlüyor. Bunlar bölümün zorluğunu etkilediği için ekonomiyi bölüm tasarımıyla birlikte ele aldım.

Kazanma ve harcama

Bir bölümü ilk kez tamamlayınca 20 pirinç kazanıyorsun. O bitiriş kaymasızsa +10, booster’sızsa +5 ekleniyor. Sergiyi ilk kez tamamlamanın ödülü +150. Aynı bölümü tekrar oynayarak bu para ödüllerini yeniden alamıyorsun. Yeni oyuncu 3 Geri Al, 3 Kilit ve 2 Terazi ile başlıyor. Her booster, kendi açılma bölümüne kadar bekliyor.

Kaymasız bitirmekle booster kullanmadan bitirmek ayrı koşullar. Kilit kullanıp hiç kaymazsan +10’u alabilirsin, ama +5’i alamazsın. Kaydıktan sonra Geri Al kullanırsan iki ek ödülü de alamazsın. Galerinin ışığı ise kaymasız bitirişi gösteriyor. Booster kullanılıp kullanılmadığını göstermiyor.

Satın alma ve reklam

Tablodaki fiyatları proje için referans olarak belirledim. Gerçek satın alma davranışıyla doğrulamadım. Başlangıç paketi ilk açılıştan itibaren mağazada görünüyor. Terazi ise 37. bölümde açılıyor. Paketin bu kısmının yeni oyuncuya ne kadar değer sunduğunu ayrıca değerlendirmem gerekiyor.

• Ödüllü reklam: Oyuncu isterse reklam izleyerek 1 Terazi kazanabiliyor. Günlük sınır 5. Zorunlu reklam yok.
• Değerlendirme isteği: Sergi tamamlanınca gösteriliyor. En fazla üç kez çıkabiliyor ve iki istek arasında en az 30 gün geçmesi gerekiyor.
• Satın alma kontrolü: İşlem kimliğini kaydediyorum. Aynı işlem ikinci kez ödül vermiyor. Satın almayı geri yükleme akışı da var.

public static bool ShouldAsk(PlayerProfile profile, LevelReward reward, DateTime utcNow)
{
    if (profile == null || reward == null || reward.ExhibitionBonus <= 0) return false;
    if (!Tuning.ReviewPromptEnabled || profile.ReviewPrompts >= MaxPrompts) return false;
    return profile.ReviewPromptUtc == null || (utcNow - profile.ReviewPromptUtc.Value).TotalDays >= MinDaysBetween;
}

Simülasyonda görünen ekonomi riski

Sırayla oynayan 4.000 bot ödül kazanıyor ve Geri Al kullanıyor. Gerçek para harcamıyorlar, Kilit ve Terazi de kullanmıyorlar. Aşağıdaki tablo bu davranış modelini gösteriyor. Gerçek harcamanın alt sınırı veya insan oynama süresi olarak yorumlamıyorum.

Ortancaları, ilgili sergiyi tamamlayan botlar üzerinden hesapladım. Bu nedenle bütün başlangıç grubunu temsil etmiyorlar. Botlar 6.451 kez Geri Al kullandı. Bunların 1.170’i pirinçle ödendi. Oyunu bitirenlerin ortanca bakiyesi 3.950, yaklaşık 98 Geri Al’a yetiyor.

Bu senaryoda pirinç hızlı birikiyor. Ödüllerin Geri Al ihtiyacına göre fazla olup olmadığını yeniden incelemem gerekiyor. Başlangıç stokunu ve booster kullanımını değiştirerek başka varsayımları da deneyebilirim. Botlar gerçek para harcamadığı için bu tabloyla paket talebi veya gelir tahmini yapmıyorum.

Teknik ayrıntılar

Bölüm editörü, çözücü ve botlar aynı kural kodunu kullanıyor. Böylece editörde gördüğüm dengeyle oyundaki denge aynı hesaptan geliyor. Araçları, değişiklik yapıp sonucunu hızlıca kontrol edebilmek için bu şekilde kurdum.

public static int Torque(Arm arm)
{
    int t = arm.Wind;
    foreach (var kv in arm.Slots)
    {
        var s = kv.Value;
        int w = s.IsPiece ? s.Piece.Weight : TotalWeight(s.Arm);
        t += w * kv.Key;
    }
    return t;
}

public static bool WouldSlip(int threshold, int torqueBefore, int torqueAfter)
{
    if (threshold <= 0) return false;
    int before = System.Math.Abs(torqueBefore);
    int after = System.Math.Abs(torqueAfter);
    return after > threshold && after > before;
}

void PieceDfs(List<Arm> arms, Dictionary<Arm, int> lever, int i, int placed)
{
    if (result.Solutions.Count >= maxSolutions || ++nodes > DfsNodeBudget) { truncated = true; return; }
    if (placed + (n - i) < target) return;
    foreach (var a in arms)
    {
        int t = Math.Abs(TorqueEngine.Torque(a));
        if (t > suffixWeight[i] * lever[a]) return;
    }

public static int Initial(string remoteMode, string saved, int ramMb)
{
    if (remoteMode == ModeSmooth) return Smooth;
    if (remoteMode == ModeSaver) return Saver;
    if (saved == ModeSaver) return Saver;
    return ramMb > 0 && ramMb < LowMemoryMb ? Saver : Smooth;
}

public static bool TooSlow(int target, FrameStats window) =>
    target > Saver && window != null && window.TotalSeconds >= WindowSeconds &&
    (window.AverageFps < target * MinAverageShare || window.SlowShare > MaxSlowShare);

Arayüz ve görseller

Arayüzde ağırlık ve mesafe ilişkisini kolay okunur tutmaya çalıştım. Ağırlık parçanın üzerinde yazıyor. Gizli parçayı “?” ve kesik çerçeveyle, kilitli kancayı kilit işaretiyle gösteriyorum. Kayma riski belirdiğinde kol kırmızıya dönüyor ve kısa bir görsel tepki veriyor. Bu işaretlerin ne kadar anlaşılır olduğunu oyuncu gözleminde kontrol etmek istiyorum.

Pirinç jetonu Blender’da modelledim. Arayüzü ve simgeleri Figma’da tasarladım.

Kâğıt, mürekkep ve beş renk

Görsellerde düz renkler, dış çizgisiz şekiller ve hafif bir kâğıt dokusu kullandım. Işık sol üstten geliyor ve yumuşak bir gölge bırakıyor. Krem rengi zeminin üzerinde ipler, yazılar ve kancalar mürekkep siyahı. Parçalar kırmızı, kobalt, sarı, siyah ve beyaz olabiliyor. Şekilleri beyaz çizdim, renklerini oyun veriyor. Böylece altı şekli beş renkte göstermek için tek bir görsel set yeterli oluyor.

• Kâğıt #F3EDE2
  Zemin
• Mürekkep #1C1B1A
  İp, yazı, siyah parça
• Pirinç #B8944A
  Kol, jeton
• Kırmızı #D7301F
  Parça, kayma uyarısı
• Kobalt #1F4FA3
  Parça
• Sarı #E9B824
  Parça
• Beyaz #FAF7F0
  Parça

Ağırlık sayısı nereye yazılır?

Ağırlık sayısı her hamlede okunuyor. Ama sayıyı görselin tam ortasına koymak her şekilde işe yaramıyor. Üçgenin geniş kısmı altta, damlanın gövdesi de aşağıdaki yuvarlakta. Her şeklin içine sığan en büyük dairenin merkezini hesaplayıp sayıyı oraya yerleştirdim. Ağırlık arttıkça sayı büyüyor, ama bu dairenin dışına taşmıyor. Renkli parçalarda beyaz, beyaz parçada mürekkep rengi kullanıyorum. Kontrastın en düşük olduğu sarıda ise tam beyaz var.

İlk sette bir hilal de vardı. İnce gövdesinde sayı kenardan taşıyordu. Yerine yarım daire, fasulye, baklava ve altıgeni denedim. Baklavayı seçtim. Üst köşesinden asılıyor ve sayı tam ortasına oturuyor.

Yedi salon, yedi malzeme

Her sergide kolların malzemesi değişiyor: önce pirinç, ardından ahşap, bakır, cam, keçe, taş ve neon. Ahşapta dalgalı damarlar, taşta benekler, camda üstte parlak bir kırılma çizgisi, neonda beyaz bir çekirdek var. Kol görselini 9-slice olarak kestim. Uzatınca yalnızca ortası esniyor, uçların yuvarlaklığı korunuyor. Salonların kâğıt zemini de malzemeye göre hafifçe renk değiştiriyor.

• Kâğıt
• Ahşap
• Bakır
• Cam
• Keçe
• Taş
• Neon

Simgeler, pirinç jeton ve uygulama simgesi

Arayüz simgelerini Figma’da, 24 birimlik bir ızgara ve 2 birim kalınlığında çizgilerle tasarladım. Aynı simge koyu bir düğmede beyaz, açık zeminde mürekkep rengi olabiliyor. Oyunun para birimi olan pirinç jetonu Blender’da modelledim. Uygulama simgesinde ise pirinç bir kol ile kırmızı ve mavi iki parça kullandım.

• Pirinç jetonBlender
• Uygulama simgesi

Galeri ve katalog

Tamamlanan bölüm, galeride oyuncunun kurduğu asılı yapı olarak kalıyor. Kaymadan tamamlanan bölümler salonun ışığını yakmaya katkı sağlıyor. Kazanılan pirinç harcanabiliyor, yapı ise yerinde duruyor. Galeride tekrar oynamak için görünür bir hedef bırakmak istedim.

Katalog, asılan şekillerin sayısını ve açılan malzemeleri gösteriyor. Galeride geçirilen süreyi ve ziyaret edilen salonları ölçmek için kayıtlar ekledim. Oyuncu verisi geldiğinde bunlarla galeriye gösterilen ilgiyi inceleyebilirim. Galerinin oyuna geri dönmeyi artırıp artırmadığını anlamak için ayrıca bir hipotez ve test gerekecek.

Menü, ipucu ve kural kartları 10 dilde kullanılabiliyor. Sayılar ve temel bulmaca ilişkileri değişmiyor. Uzun çevirilerin küçük ekranda okunmasını ve renk dışındaki işaretlerin fark edilmesini de kontrol etmek istiyorum.

Sıradaki adımlar

Gerçek oyunculara ulaşıp ağırlık ve mesafe ilişkisini, taşıma ve sökme seçeneklerini nasıl öğrendiklerini ve ilk kaymaya nasıl tepki verdiklerini oynanış testlerinde gözlemlemem gerekiyor.

Genel bakış

Mozaik Blast’ta aynı renkteki karoları patlatarak bir çini desenini tamamlıyorsun. Amaç, tahtayı boşaltmak değil. Patlattığın karo, altındaki hedef kareyle aynı renkteyse o kare boyanıyor. Bu yüzden yalnızca en büyük grubu bulmak yetmiyor. Grubun nerede durduğuna ve patlamadan sonra hangi seçeneklerin kalacağına da bakman gerekiyor.

Görsellerde İznik çinilerinden esinlendim. Her bölümde başka bir motif ortaya çıkıyor. Desenin adım adım tamamlanmasını, oyuncunun ilerlemesini görebileceği bir hedef olarak kullandım.

Bu projede yaptıklarım

• Bölüm tasarımı: Dört temaya yayılan 100 bölümün tamamını Unity’de geliştirdiğim bölüm editörüyle tasarladım. Desenleri, renk havuzlarını, engelleri ve hamle bütçelerini belirledim. Yeni kuralları tanıtan bölümlerle nefes alma bölümlerinin sırasını planladım.
• Test ve iyileştirme: Bölüm editörünü ve bot simülasyonunu geliştirdim. 100 bölümün doğrulama raporunu inceledim. Botların sonuçlarına göre Servi ve Kelebek’i değiştirdim. Kilim’de hamle bütçesini ve iki oyun kuralını A/B karşılaştırmalarıyla sınadım. Altın ekonomisi ve devam teklifleri için oyunu baştan oynayan botların verisini SQL ve Excel’le inceledim.
• Ürün kararları: Öğretim akışını, can ve altın varak ekonomisini, devam tekliflerini ve ölçüm olaylarını tasarladım. Remote Config ayarlarının sınırlarını ve ne zaman uygulanacağını belirledim.
• Geliştirme ve görseller: Oyun kurallarını Unity’de C# ile yazdım. Karoları Blender’da hazırladım. Renklerin yanında farklı çiçek şekilleri kullanarak ayırt edilmelerini kolaylaştırmaya çalıştım.

Bir bölüme nereden başlıyorum?

Önce bölümde hangi kararı öne çıkarmak istediğimi ve temanın neresinde duracağını belirliyorum. Sonra editörde desen, engel, renk ve hamle ayarlarını yapıyorum. Taslağı oyunda deniyor, botlarla ölçüyor ve gerektiğinde değiştiriyorum. Tamamlama oranının yanında bölümün öğretmek istediği karara da bakıyorum.

Sonuçların kaynağı

Geniş ölçekli oyuncu testine erişimim olmadığı için bölümleri, farklı oynama davranışlarını modelleyen botlarla test ettim. Botların varsayımlarını sonuçlarla birlikte paylaştım ve değişiklikleri aynı koşullarda karşılaştırdım. Bu sonuçlar bot testlerinden geliyor. Gerçek oyuncular üzerindeki etkisini henüz doğrulamadım.

Oynanış

Bir hamlede ne oluyor?

1. Grubu seç: Yan yana duran, aynı renkte en az iki karoya dokunuyorsun. Yatay ve dikey komşular bir grup oluşturuyor. Çapraz komşular sayılmıyor. Geçersiz bir dokunuş hamle harcamıyor.
2. Deseni boya: Patlayan karonun rengi, altındaki hedefle eşleşirse o kare tamamlanıyor. Kalan hedefleri karelerin çevresindeki taramadan ve üstteki küçük desen önizlemesinden takip edebiliyorsun.
3. Yeni yerleşimi oku: Boşalan yerlere karolar düşüyor ve yenileri geliyor. Büyük bir grup patlattığında, dokunduğun karede bir power-up oluşuyor.
4. Deseni tamamla: Bütün hedefleri boyarsan kazanıyorsun. Hamlelerin biterse ek hamleyle devam edebilir veya denemeyi bitirebilirsin.

Oyundaki 100 bölümde de boyanan hedefler korunuyor. Daha sonra yanlış renkte bir grup patlatmak, tamamladığın kareleri bozmuyor.

Büyük grupların karşılığı

Komşu power-up’lar birlikte kullanılabiliyor: iki Fırça satır ve sütunu birlikte değiştiriyor, iki Kova kapasiteyi 24 kareye çıkarıyor, iki Mühürün alanı dört adımlık yarıçapa genişliyor. Büyük grup kurmak kadar, power-up’ları yan yana getirmek de bir planlama seçeneği.

Oyun döngüsü ve ilk adımlar

Haritadan bir bölüm seçiyorsun. Deseni ve hamle sınırını görüp tahtaya geçiyorsun. Kazanınca altın varak alıyor ve sonraki bölümü açıyorsun. Tamamlanan mozaik haritada ilerlemenin bir parçası olarak kalıyor.

Oyun içinde şu döngüyü kurdum: kalan hedeflere bak → doğrudan boyama ile power-up hazırlama arasında seçim yap → patlat → yeni yerleşimi değerlendir. Gelen karolar her denemede değiştiği için aynı desen farklı sorunlar çıkarabiliyor. Başlangıçta bu kararları sade tutuyorum. İlerledikçe engeller ve hamle sınırı, birkaç hamle sonrasını düşünmeyi gerektiriyor.

Kuralları nasıl tanıtıyorum?

İlk harita düğümünü ve ilk geçerli grubu işaretliyorum. İlk hamlede dokunulabilecek alan sınırlı. Ardından hedef kartı açılıyor. Power-up açıklamaları ilk oluştuklarında, engel ipuçları da ilgili engelin ilk bölümünde geliyor. Bütün kuralları başlangıçta tek ekrana yığmak istemedim.

Bu öğretim akışı oyunda var, ama botlar onu okumuyor. Kuralları baştan biliyorlar. Dolayısıyla botların bölümü tamamlaması, açıklamaların bir oyuncu için anlaşılır olduğunu göstermiyor.

Bölüm tasarımı

Her bölüme bir amaçla başlıyorum: bir kuralı tanıtmak, öğrenilenleri birleştirmek, power-up planlamasını öne çıkarmak veya nefes aldırmak. Sonra hedeflerin komşuluğuna, engellerin düşüşü nasıl değiştirdiğine ve power-up’ların erişebildiği alanlara bakıyorum. Dağınık hedeflerde Kova, merkezde toplanan hedeflerde Mühür daha değerli olabiliyor. Hamle bütçesini bu yerleşimle birlikte ayarlıyorum.

100 bölümü dört temaya ayırdım. Yeni kuralları önce daha rahat hamle bütçeleriyle tanıtıyor, sonra önceki mekaniklerle birleştiriyorum.

Plandaki amaç tahtaya nasıl yansıyor?

Hedef deseni ve oynarken gelen karolar

Bölüm dosyasında hedef deseni, engeller, renk havuzu ve hamle sınırı var. Normal karolar ise rastgele geliyor ve patladıkça yenileniyor. Tasarladığım tek bir bölüm bu yüzden birçok farklı tahta oluşturabiliyor. Testlerde seed kullanarak koşulları yeniden kurabiliyorum. Yine de tek bir başlangıç, bölümün bütün olasılıklarını temsil etmiyor.

Engeller kararı nasıl değiştiriyor?

• Kil: Örttüğü kare boyanamıyor. Yanındaki grup patladığında bir katman kırılıyor. Çift katlı kil için bunu iki kez yapmak gerekiyor. Kili kaldırmak hedefi tamamlamıyor: açılan kareyi sonra doğru renkle boyamalısın.
• Kafes: İçindeki karo aynı renkli gruba katılıyor, ama ilk patlamada yalnızca kafes kırılıyor ve karo yerinde kalıyor. Kafes kırılana kadar düşüşü de durduruyor. Bu yüzden bir hamle bazen doğrudan boya kazandırmak yerine sonraki hamlenin yolunu açıyor.
• Yosun: Hedefe erişimi kapatıyor. Devam eden bir hamlede hiç yosun temizlenmezse komşu bir normal karoya yayılıyor. Yosun temizlemek o hamlede büyümeyi durduruyor. Hedefe odaklanmakla yayılmayı kontrol etmek arasında seçim gerekiyor.

Zorluğun ritmi

Zorluğu sürekli artırmak istemedim. Dalga’da (7) hata paylı botun tamamlama oranı %41,6, sonraki Güneş’te (8) %84,2. Mahzen’den (31, %43,1) sonra Fener (%85,5), Kuru Havuz’dan (81, %38,1) sonra Lale Tarlası (%85,6) geliyor. Zor bölümlerin ardından baskıyı düşüren nefes alma bölümleri yerleştirdim.

Grafikteki tasarım hedefi, bölüm dosyasına yazdığım bot tamamlama hedefi. Gerçek oyunculardan ölçülmüş bir standart değil. Botun sonucu bu çizgiye yakınsa, hamle bütçesi bu modelde hedeflediğim zorluğa yakın çalışıyor.

Bölüm editörü ve çalışma akışım

100 bölümün tamamını Unity içinde geliştirdiğim bölüm editörüyle tasarladım. Önce bölümün rolüne ve öğretmek istediği karara bakıyorum. Sonra desen, engel ve hamle bütçesini buna göre değiştiriyorum. Editör ayrı bir pencerede açılıyor: solda bölüm kütüphanesi, ortada tahta, sağda ayarlar ve tasarım planı var. Taslağı botlarla ölçüyor, kaydetmeden oyunda deniyor ve seçtiğim hâlini raporuyla birlikte kaydediyorum.

Plan notları ayrı bir tasarım tablosundan geliyor. Tahtayı değiştirdiğimde otomatik güncellenmiyorlar. Örneğin Servi’nin eski planında 22 hedef yazıyor, güncel tasarımda ise 24 hedef var. Son kontrolü güncel tahta sayacı ve kayıtlı rapor üzerinden yapıyorum.

Bir bölümü nasıl düzenliyorum?

1. Amacını belirliyorum. Unity’de Mozaik Blast → Level Editor menüsünü açıp bölümü seçiyorum. Rolü, zorluk ayarı ve öğretmek istediği karar aynı ekranda duruyor. Değişiklikten önce bot testini çalıştırıp sonucu “Referans yap” ile saklıyorum.
2. Deseni ve engelleri ayrı düzenliyorum. Hedefleri renk fırçalarıyla, kil, çift katlı kil, kafes ve yosunu engel katmanında boyuyorum. Bir katmanı silerken diğeri korunuyor. Sürükleyerek boyadığım alanı tek adımda geri alabiliyorum.
3. Bütçeyi ayarlayıp yeniden ölçüyorum. Tahta boyutu, renk havuzu, hamle sınırı ve boyanan kareleri koruma ayarı aynı panelde. Üç bot profili varsayılan olarak 1.000’er koşu oynuyor. Referansla koşu sayısı veya seed uyuşmazsa editör puan farkını göstermiyor. Karşılaştırmada oyun kurallarını da sabit tutuyorum. Hamle önerisi önce 300 koşuluk ölçümlerle bir bütçe arıyor, ardından tam testi çalıştırıyor. Öneriyi oyunda deneyip değerlendiriyorum.
4. Hangi karelerin kaldığına bakıyorum. Isı haritası, hata paylı botun kaybettiği koşularda boyayamadığı hedefleri gösteriyor. Yüzdeler yalnızca kaybedilen koşular üzerinden hesaplanıyor. Renk koyuluğu her haritanın en yüksek değerine göre ayarlandığı için farklı bölümlerin renklerini doğrudan karşılaştırmıyorum.
5. Taslağı oyunda deniyorum. “Oyunda dene” ile bölüm dosyasını değiştirmeden oyun sahnesine geçiyorum. Hedef önizlemesini, desenin okunmasını ve power-up’ların davranışını burada kontrol ediyorum. Play Mode’dan çıkınca can, altın ve ilerleme kaydı önceki hâline dönüyor.
6. Bölümü ölçümüyle birlikte kaydediyorum. Güncel test yoksa botlar kayıttan önce yeniden çalışıyor. Dosyada koşu sayısı, seed, kurallar, tarih ve üç profilin sonucu tutuluyor. Tasarım veya kurallar değiştiğinde eski rapor işaretleniyor. Bölümü JSON, referans ve son ölçümü CSV olarak dışa aktarabiliyorum. Kütüphanedeki işaretlerle hangi raporun uygun, eski veya düzeltme bekliyor olduğunu görüyorum.

Karar verirken kullandığım basit hesaplar

Sonuçları okurken bu beş hesaba bakıyorum. Editör bunları otomatik hesaplıyor. Aşağıdaki örnekler Servi ve Kelebek’in bot ölçümlerinden.

Bot sonuçlarını nasıl okuyorum?

Editörün “yayına uygun” etiketi, bölümün belirlediğim bot kontrollerini geçtiğini söylüyor. Hata paylı profil hedefin en fazla 5 yüzde puan uzağında olmalı. Hedefi %85’in altında olan bölümlerde rastgele profil %15’i geçmemeli. Bu etiketi, gerçek oyunculardaki zorluğun veya eğlencenin doğrulandığı şeklinde kullanmıyorum.

Hedef odaklı ve hata paylı botların tamamlama oranı arasındaki farka “beceri payı” adını verdim. Fark 3–8 puan dışındaysa bölümü inceliyorum, ama bu tek başına kaydı engellemiyor. Kolay giriş bölümlerinde, hedef %85 veya üzerindeyse, 3 puanın altı için uyarı da verilmiyor.

Bu akışı kullanarak Servi’nin hedef yerleşimini ve Kelebek’in hamle bütçesini düzenledim. Sorunları, denediğim seçenekleri ve önce–sonra sonuçlarını Bot verisiyle iyileştirmeler kısmında gösteriyorum.

Editörün gösterdiği bir sınır

Isı haritasında bir sınır fark ettim: simetrik desenlerin sağ tarafı düzenli olarak daha sıcak çıkıyor. 73. bölüm Mozaik Zemin’de kafesli sol alt köşe kayıpların %16’sında, sağ alt köşe %50’sinde boş kalıyor. Botlar gruba her zaman en soldaki kareden dokunuyor ve power-up orada oluşuyor. Bu davranış farkı etkileyebilir. Bu yüzden sağdaki kareyi doğrudan tasarım sorunu saymıyorum. Editör, dokunma konumuyla ilgili bu notu haritanın altında gösteriyor. Farklı dokunma konumlarını denemek sıradaki işlerimden biri.

Hangi ayarı neden değiştiriyorum?

Bütün bölümlere bakmak

Ayrı dengeleme menüsünde bir temayı, seçtiğim bölümleri veya 100 bölümün tamamını inceleyebiliyorum. Hamle bütçesi aramak, mevcut bütçeye ince ayar yapmak ve bütçeyi değiştirmeden doğrulamak ayrı işlemler. Grafikteki 3 Ekim raporu, o tarihteki 100 bölümün bütçeyi değiştirmeden doğrulanmasına ait. Servi ve Kelebek’in sonraki değişiklikleri bu raporda yok. CSV’de hedef, eski ve yeni hamle sınırı, üç profilin tamamlama oranı, hata paylı botun kalan hamleleri, kayıplardaki ilerleme, grup büyüklüğü ve power-up kullanımı var. Bu sayede bir bölümü komşularıyla birlikte değerlendirebiliyorum.

Kaydetmeden önce kontrol ettiğim şeyler

• Desen ve erişim: Hedef renkleriyle renk havuzu uyumlu mu? Boyutu küçültürken hedef veya engel kaybettim mi? Kapalı hedefler ve önizleme anlaşılır mı?
• Öğretim ve ritim: Bölüm hangi kararı öne çıkarıyor? Engeller, power-up hazırlama alanı ve hamle bütçesi bu kararı destekliyor mu? Önceki ve sonraki bölümle baskı farkı nasıl?
• Ölçümün güncelliği: Son düzenlemeden sonra botları yeniden çalıştırdım mı? Koşu sayısı, seed ve oyun kuralları karşılaştırmaya uygun mu? Kazanan ve kaybeden ortalamalarını ayrı mı okuyorum?

Editör tahta boyutunu 4–10, hamle sınırını 1–99 arasında tutuyor. Hedefsiz bölümü kaydetmiyor. Dosya editör dışında değiştiyse üzerine yazmıyor. Havuzda olmayan bir hedef rengi veya planın rolüne uymayan bot hedefi için uyarı veriyor. Bölümün anlaşılır olup olmadığını ve tasarım amacını koruyup korumadığını ise oyunda deneyerek kontrol ediyorum.

25. bölüm: Kilim

Kilim, ilk temanın son bölümü. 9×9 tahtada dört renk, 35 hedef kare ve 33 hamle var. Engel yok. Yedi yatay renk şeridi kullandım. Oyuncunun, tanıdığı power-up’ları kullanırken grubun konumuna da dikkat etmesini istedim.

Aynı power-up, farklı konum

Mühür bütün tahtayı boyamıyor. İki adımlık elmas alanı desenin ortasında 13, sol kenarında 9 hedef kareye erişiyor. Şemada bütün hedefler henüz boyanmamış. Oyun sırasında gerçek kazanç, o anda kalan hedeflere bağlı.

Power-up, büyük grubun dokunulan karesinde oluşuyor. Bu yüzden 13 karoluk bir grup bulduktan sonra neresine dokunacağını da seçmen gerekiyor. Renk şeritleri Fırça’yla büyük grup hazırlamaya alan bırakıyor. Merkezdeki hedefler ise Mühürün konumunu değerli kılıyor.

Kilim’in 33 hamlelik bütçesini 31 ve 35 hamleyle karşılaştırdım. Oranları, test ayarlarını ve neden 33 hamleyi koruduğumu Botlarla A/B testi kısmında gösteriyorum.

Test ve dengeleme

Üç bot profili kullandım. Hamleleri farklı seçiyorlar, ama hepsi oyunun aynı tahta modelini ve kurallarını kullanıyor. Sonuçlarını ayrı raporluyorum. Animasyonları, öğretim ekranlarını ve ekonomi akışını bu testte oynamıyorlar.

Üç profil de normal bir grubu tek bir dokunma konumuyla temsil ediyor. Grup içindeki bütün power-up yerleşimlerini karşılaştırmıyor. Kilim’de gösterdiğim 13 ve 9 karelik konum farkı bu yüzden ayrıca geometrik olarak incelendi. Bot sonuçları, power-up yerleştirme becerisini bütünüyle temsil etmiyor.

100 bölümün kontrolü

3 Ekim doğrulamasında bölüm ve profil başına 1.000 koşu var: 100 × 3 × 1.000 = 300.000 koşu. Seed 1234. Test sırasında hamle sınırları değiştirilmedi. Sonraki düzenlemelerde Servi 27’den 31 hamleye ve 22’den 24 hedefe, Kelebek 30’dan 31 hamleye geçti. Bu yeni tasarımları ve ölçümlerini Bot verisiyle iyileştirmeler kısmında ayrı gösteriyorum.

3 Ekim raporunda hata paylı bot, her bölümde hedefin en fazla 4,4 yüzde puan uzağında kaldı. Bu, planladığım ritmin bu botla kurulabildiğini gösteriyor. Oyuncuların zorluğu nasıl algılayacağını, eğlenip eğlenmeyeceğini veya geri dönüp dönmeyeceğini henüz bilmiyorum. Raporun hesaplama süresini de oyuncunun bölüm süresi olarak kullanmıyorum.

Tekrarlanabilirlik ve kalite kontrolü

Yeni Kilim testini, oyun kaynaklarının değiştirilmemiş kopyalarıyla çalıştırdım. Önce 1, 7, 25, 26, 51, 76 ve 100. bölümlerde üç profilin 150’şer koşusunu mevcut Unity kaydıyla karşılaştırdım. 21 karşılaştırmanın kazanma sayıları eşleşince alternatiflere geçtim.

Projede 131 testin geçtiği bir kalite kontrol kaydı da var. Tahta kuralları, engeller, power-up’lar, bölüm okuma ve ekonomi gibi alanları kapsıyor. Bu testler kuralların doğru çalışmasını kontrol ediyor. Bölümün oyuncuya nasıl hissettirdiğini değerlendirmek için ayrıca gözlem gerekiyor.

Unity kaydıyla eşleşen kazanma sayıları

Her hücre, seed 777 ile yapılan 150 koşuda kazanılan oyun sayısını gösteriyor. 21 değerin tamamı Unity kaydıyla eşleşti. Bu 3.150 kontrol koşusu, Kilim deneyindeki 16.200 koşuya dahil değil.

Bot verisiyle iyileştirmeler

Servi’de kaybedilen koşularda sık sık boş kalan bir hedef fark ettim. Kelebek’te ise iki bot profili arasındaki fark açılmıştı. İki bölümü de tasarım amaçlarını koruyarak değiştirmek istedim. Seçenekleri ölçtüm, oyunda denedim ve tercih ettiğim hâllerini kaydettim.

Bunlar botlarla ölçülmüş tasarım düzenlemeleri. Gerçek oyuncuların tamamlama oranı, eğlencesi veya oyuna geri dönmesi üzerindeki etkisi henüz doğrulanmadı.

20 · Servi: nefes alma bölümünün son hedefi

Sorun

Servi’yi zor bir bölümün ardından nefes aldırmak için tasarladım. Bot hedefi %86 ve sonuç buna yakındı. Ama ısı haritasında ağacın en alt karesi öne çıktı: hata paylı botun kaybettiği 135 oyunun %44’ünde bu kare boş kalmıştı. Kaybeden botlar hedeflerin ortalama %92’sini boyuyordu. Bölümün büyük kısmı tamamlandığı hâlde son hedefin sık sık aynı yerde kalması, yerleşime yeniden bakmamı sağladı.

Değişiklik

Gövdenin altına iki mercan kare ekleyip üç karelik bir kök yaptım. En alttaki hedef artık yanındaki hedeflerle aynı grupta boyanabiliyordu. Hamle önerisi bütçeyi 27’den 31’e çıkardı. Taslağı oyunda açıp kökün küçük hedef önizlemesinde okunabildiğini kontrol ettim ve kaydettim.

Sonuç ve karar

Hata paylı bot hedefin 2,9 puan üstüne çıktı. Bir nefes alma bölümü için bu payı kabul ettim. Desen ve hamle bütçesi birlikte değiştiği için artışı yalnızca köke bağlayamıyorum. Haritada kökün sağ ucunun daha sıcak çıkmasını da doğrudan kötü yerleşim olarak yorumlamıyorum. Botun dokunma konumu bu farkı etkileyebilir.

97 · Kelebek: dersi koruyup bütçeyi değiştirmek

Sorun

Kelebek’in bot hedefi %54. Hata paylı bot %50,0’da, hedef odaklı bot %62,4’te kalıyordu. Aralarındaki 12,4 puan, inceleme için kullandığım 3–8 puan aralığının dışındaydı. Bu yüzden bölüme yeniden baktım. Bu farkın gerçek oyuncuların hata yaptığında nasıl hissedeceğini gösterdiğini söyleyemem.

Denediğim seçenekler

İlk fikrim, ortadaki yosunu gövdenin üst ucuna taşımaktı. Ortadaki yosun iki kanada da yayılabiliyordu. Taşıdıktan sonra hamle önerisini çalıştırdım ve sonuç iyi göründü. Ancak araç aynı anda bütçeyi 30’dan 31’e çıkarmıştı. Ek hamle tek başına yeterli mi diye yosunu eski yerine koyup yalnızca bütçeyi 31 yaptım.

Sonuç ve karar

31 hamleli iki seçeneğin hata paylı bot sonuçları çok yakındı. Yalnızca bütçeyi değiştirmek de hedefi ve profil farkı aralığını karşılıyordu. Yosunun iki kanada yayılabilmesi, bölümde öğretmek istediğim kararın parçasıydı. Bu yüzden yerini koruyup hamle sınırını 31 yaptım. Kayıtlı sürümde bot hedefin 2,5 puan üstünde, profil farkı 6,5 puan. Bu ölçüm yosunun yerinin hiç etkisi olmadığını kanıtlamıyor.

İki örnekte de profil başına 1.000 koşu, seed 1234 ve aynı oyun kuralları var. Bu editör testinde aynı seed, her koşunun aynı başlangıç tahtasıyla eşleşmesini garanti etmiyor. Hamle seçimi ve oyun uzunluğu rastgele sayı akışını değiştirebiliyor. Sonuçları bu ayarlardaki bot karşılaştırmaları olarak okuyorum. Isı haritasının yüzdeleri de yalnızca kaybedilen koşulara ait.

Kayıtlı raporların ayarları

İki raporda da profil başına 1.000 koşu ve seed 1234 var. Spawn bias %30. Power-up eşikleri 7, 10 ve 13, Kova kapasitesi 8, Mühür yarıçapı 2. Kalan hamle yalnızca kazanılan, hedef ilerlemesi yalnızca kaybedilen koşuların ortalaması. Aşağıdaki değerler hata paylı profile ait. Bu raporlar seçilen tasarımları gösteriyor. Önceki bütün alternatiflerin ham koşu kayıtlarını içermiyor.

Botlarla A/B testi

Kilim’de üç soruya baktım: kaç hamle olmalı, boyanan kareler korunmalı mı ve yeni karolar hedeflere ne kadar yardım etmeli? Her karşılaştırmada ilgili ayarı değiştirip diğer kuralları sabit tuttum. Aynı bot profilleri alternatifleri oynadı. Gerçek oyuncuları iki gruba ayıran canlı bir test yapmadım.

Hipotez ve test planı

Ana ölçümüm, hata paylı botun tamamlama oranının Kilim için seçtiğim %60 hedefine yakınlığıydı. Hedef odaklı ve rastgele botları da izledim. Amacım yalnızca oranı yükseltmek değildi. Her koşulda profil başına 900 koşu var. Desen, renk havuzu ve power-up kuralları aynı. İlgili deneyde yalnızca hamle, boyama veya yeni karo ayarı değişiyor.

1. Hamle bütçesi: 31, 33 veya 35?

Sınadığım fikir: 33 hamle, ilk temanın sonunda power-up planlamak için yeterli alan bırakabilir. 31 hamlede bot hedefin altında, 35 hamlede üstünde kalabilir.

Mevcut 33 hamlelik sürümü, 31 ve 35 hamleyle aynı senaryo seed’lerinde tekrar ölçtüm. Desen, renk havuzu, power-up kuralları ve spawn ayarı sabit kaldı. Her seçenek için profil başına 900, üç profilde toplam 2.700 koşu var.

Kararım: 33 hamleyi korudum. Hata paylı botun %62,1 sonucu, %60 tasarım hedefine yakın. 31 hamlede %54,6, 35 hamlede %71,3 çıkıyor. İlk temanın sonunda power-up planlaması isteyen bir kapanış hedeflediğim için en yüksek oranı seçmedim.

33 hamlede kaybeden hata paylı bot, desenin ortalama %92,1’ini tamamlıyor. Kalan hedeflerin konumuna bakmak için bunu bir işaret olarak kullanıyorum. Bu veri oyuncunun ne kadar hayal kırıklığı yaşadığını veya ek hamle almak isteyip istemediğini ölçmüyor. Kazanan botlarda ortalama 7,38 hamle kalıyor. Bu ortalama yalnızca kazanılan denemelerden hesaplanıyor.

Bu, alternatiflerin yerel karşılaştırması. Mevcut raporu bir önce–sonra iyileştirmesi olarak sunmuyorum ve test için oyunun bölüm dosyasını değiştirmedim.

2. Tamamlanmış kareler korunmalı mı?

Sınadığım fikir: Boyanan kareler korunursa bot kalan hedeflere odaklanabilir. Koruma kalkarsa aynı bütçede bitirmek zorlaşabilir. Bu yüzden tamamlama oranıyla birlikte kaybedilen koşulardaki hedef ilerlemesini de ölçtüm.

Mevcut sürümde doğru boyanan kare korunuyor. Alternatifte yanlış renkle yapılan sonraki patlamalar bu ilerlemeyi bozabiliyor. Bu değişiklik, hedefin yanında “daha önce yaptığımı koruma” yükü de ekliyor.

Kararım: Boyanan kareleri koruyan kuralı sürdürdüm. Koruma kalktığında hata paylı botun tamamlama oranı %62,1’den %0,3’e, kayıplardaki ilerlemesi %92,1’den %63,0’a indi. Aynı bütçe ve bot puanlamasıyla bu seçenek Kilim’i çok zorlaştırdı. Alternatif kurala göre botun hamle puanlarını veya bütçeyi yeniden ayarlamadım. Dolayısıyla bu testten, üstüne boyamanın her oyunda kötü olduğu sonucunu çıkarmıyorum.

3. Yeni karolar hedeflere ne kadar yardım etmeli?

Sınadığım fikir: Yeni karolar için kullandığım %30 hedef rengi desteği, botun sonucunu tasarım hedefine yakın tutabilir. Bu desteği kaldırıp %60’a çıkardığımda ne değiştiğine baktım. Hata paylı botla birlikte rastgele botu da izledim.

Mevcut ayarda %30 hedef rengi desteği, yani spawn bias var. Bir sütunda eksik hedef rengi bulunuyorsa yeni karonun rengi %30 olasılıkla bu renklerden seçiliyor. Diğer durumda normal renk havuzu kullanılıyor. Bu ayar, %30 kazanma desteği veya işe yarayan bir grup garantisi vermiyor.

Kararım: Kilim’de %30 ayarını korudum. Desteği kaldırınca hata paylı bot %51,1’e düşüyor. %60’a çıkarınca %73,3’e ulaşıyor. Mevcut ayar %60 tasarım hedefine yakın ve rastgele bot %0,1’de kalıyor. Üç seçenekte de rastgele hamleler aynı başarıya ulaşmıyor. Oyuncunun adalet veya kontrol hissini ise bu testle ölçmedim.

Deneyin kapsamı

Altı koşul ölçtüm: 31, 33 ve 35 hamle, 33 hamlede üstüne boyama, 33 hamlede %0 ve %60 hedef rengi desteği. Her koşulda profil başına 900, toplam 2.700 koşu var. Deneyin tamamı 16.200 benzersiz koşudan oluşuyor. Mevcut sürüm üç karşılaştırmada ortak, bu yüzden tekrar sayılmıyor.

Üç seed bloğunda 300’er koşu kullandım. Hamle ve boyama karşılaştırmaları aynı başlangıç senaryolarıyla çalışıyor. Yeni karo kuralı değiştiğinde ise aynı seed aynı tahtayı garanti etmiyor. Test ayarlarını ve örneklemeden gelen belirsizliği aşağıda gösteriyorum.

Altı koşulda üç profilin sonuçları

Test ayarları ve belirsizlik

Seed blokları 1729, 8675309 ve 20261009. Her blokta 300 koşu var. Her koşunun seed’i blok + deneme × 104729. Deneme numarası sıfırdan başlıyor. Her oyun ayrı bir simülatör çağrısı olduğu için önceki oyunun rastgele sayı tüketimi sonraki başlangıcı değiştirmiyor. Hamle ve boyama karşılaştırmaları aynı başlangıçları kullanıyor. Spawn kuralı ve profillerin farklı seçimleri sonraki tahtaları değiştirebiliyor.

Bütün koşullarda 9×9 tahta, 35 hedef ve dört renk var. Power-up’lar açık, splash kapalı. Eşikler 7/10/13, Kova kapasitesi 8, Mühür yarıçapı 2. Hata paylı bot mevcut sürümde 559/900 (%62,1) kazanıyor. %95 Wilson aralığı yaklaşık %58,9–65,2. Bu aralık, bot koşuları ve senaryoların örneklenmesinden gelen belirsizliği gösteriyor. Gerçek oyuncu davranışını temsil etmiyor.

Kalan hamle yalnızca kazanılan, hedef ilerlemesi yalnızca kaybedilen koşuların ortalaması. Power-up oluşturma ve kullanma bütün koşular üzerinden hesaplanıyor. Eski 100 bölüm raporundaki saniye, oynama değil hesaplama süresi. Oradaki Kilim %60,2 ile bu deneydeki %62,1 farklı seed yöntemleri kullanıyor. Aradaki fark bir tasarım iyileşmesi değil.

SQL ve Excel

Altın varak ekonomisine ve devam tekliflerine bakmak için 4.000 botla oyunu baştan sırayla oynadım. Oyunun kendi tahta ve bot kodunu kullandım. Servi’de editörün kayıtlı sonucu birebir eşleşti.

• 4.000 bot: %70’i hata paylı, %30’u hedef odaklı. Aynı bölümde art arda 3–8 kez kaybeden bot oyunu bırakıyor.
• Hamleleri bittiğinde desenin en az %80’i boyanmışsa ve altını yetiyorsa bot, 30 altınla bir kez devam ediyor. Bu kuralı ben seçtim. Modelde reklam, can bekleme süresi ve satın alma yok.
• Toplam 434.900 deneme oynandı. 4.000 botun 2.910’u 100. bölümü bitirdi.

Veriyi üç basit tabloya koyup SQL’le sorular sordum. Sorgular SQLite’ta çalışıyor.

• players: her satır bir bot: profili, kaç bölüm geçtiği, oyunu bıraktıysa hangi bölümde bıraktığı, kazandığı ve harcadığı altın.
• attempts: her satır bir deneme: bölüm, kazanıp kazanmadığı, devam alınıp alınmadığı, teklif anında desenin yüzde kaçının boyandığı, kazanılan ve harcanan altın.
• levels: her bölümün adı, teması ve türü.

1. Ek hamle almak denemeyi kurtarıyor mu?

-- Altınla alınan continue attempt'i kurtarıyor mu?
SELECT CASE WHEN offer_progress >= 90 THEN '90-99%' ELSE '80-89%' END AS painted_at_offer,
       COUNT(*) AS continues,
       ROUND(100.0 * SUM(won) / COUNT(*), 1) AS won_pct
FROM attempts
WHERE continued = 1
GROUP BY painted_at_offer;

Sorgu ne yapıyor? Ek hamle alınan denemeleri continued = 1 ile seçiyor. CASE WHEN, teklif anında desenin en az %90’ı boyanmışsa “90-99%”, diğer durumda “80-89%” grubuna ayırıyor. Her grupta kaç kez ek hamle alındığını ve bunların yüzde kaçının kazanmayla bittiğini hesaplıyor.

Ne gördüm? Desenin en az %90’ı boyanmışken alınan devamların %54,8’i kazanmayla bitiyor. %80–89 aralığında bu oran %32,5. Aynı 30 altının sağladığı sonuç, kalan hedeflere göre değişiyor. Teklif penceresinde boyanan kare sayısını zaten gösteriyorum. Bu ölçüm, karar verirken ilerlemenin görünür olmasını neden önemsediğimi destekliyor.

2. Botları en çok hangi bölümlerde kaybediyoruz?

-- Botları en çok hangi level'larda kaybediyoruz?
SELECT l.level,
       l.name,
       l.tier,
       COUNT(*) AS bots_quit
FROM players p
JOIN levels l ON l.level = p.stopped_at_level
WHERE p.finished = 0
GROUP BY l.level, l.name, l.tier
ORDER BY bots_quit DESC
LIMIT 5;

Sorgu ne yapıyor? Oyunu bitirmeyen botları bıraktıkları bölüme göre grupluyor. JOIN, levels tablosundan bölümün adını ve türünü getiriyor. En çok bot kaybedilen beş bölüm listeleniyor.

Ne gördüm? İlk beşin hepsi zor olarak planladığım bölümler: Kum Saati, Labirent, İki Lale, Zincir ve Kuru Havuz. Bu modelde botlar birkaç ardışık kayıptan sonra bırakıyor ve ek hamle alabiliyor. Sonuç bu varsayımlara bağlı. Gerçek oyuncular başka nedenlerle de bırakabilir.

3. Kazanılan altının ne kadarı devam etmek için gidiyor?

-- Her temada kazanılan altının ne kadarı continue'a gidiyor?
SELECT l.theme,
       SUM(a.gold_earned) AS gold_earned,
       SUM(a.gold_spent) AS gold_spent,
       ROUND(100.0 * SUM(a.gold_spent) / SUM(a.gold_earned), 1) AS spent_pct
FROM attempts a
JOIN levels l ON l.level = a.level
GROUP BY l.theme_no, l.theme
ORDER BY l.theme_no;

Sorgu ne yapıyor? attempts tablosunu levels ile JOIN’leyip her temada kazanılan ve devam etmek için harcanan altını topluyor. Harcananı kazanılana bölüp yüzdeye çeviriyor.

Ne gördüm? Çini Atölyesi’nde kazanılan altının %61’i, Bahçe’de %96’sı devam etmek için harcanıyor. Bu senaryoda sona doğru altın birikmiyor, neredeyse kazanıldığı kadar harcanıyor. Botlar koşulları sağladıklarında her zaman devam etmeyi seçiyor. Bu bir satın alma veya gelir tahmini değil.

Excel çalışma kitabı

Aynı koşuyu Excel’e de aktardım. Players sayfasında her bot, Continues sayfasında her devam işlemi ve sonucu ayrı bir satır. Continue sayfasında iki profilin sonuçlarını ayrı gösteriyorum. Levels sayfasında başlayan ve bırakan botlar, Economy sayfasında tema başına kazanılan ve harcanan altın var. Hesaplar COUNTIFS ve SUM formülleriyle yapılıyor.

Continue!B2 · teklifte desenin %80–89’u boyanmışken alınan continue sayısı
=COUNTIFS(Continues!E:E, ">=80", Continues!E:E, "<=89")
Levels!G2 · bu level’da oyunu bırakan bot sayısı
=COUNTIFS(Players!E:E, A2)

Bu kısımdaki bütün tablolar bot verisinden geliyor. Gerçek oyuncu sonucu değil. Koşu 12 Ekim 2026’da, seed 20261012 ile yapıldı.

Analitik ve ürün kararları

Botlarla tahta tasarımını karşılaştırabildim. Ürün kararları içinse oyuncunun öğretimden, bölümden ve devam teklifinden nasıl geçtiğini görmem gerekecek. Bu nedenle hamlelerin bitmesini, devam seçimini, öğretim adımlarını ve ekonomi hareketlerini kaydeden olaylar ekledim. Aşağıdaki tablo, veri geldiğinde neye bakacağımı gösteriyor. Henüz elde edilmiş oyuncu sonuçları yok.

level_end olayında sonuç, deneme sayısı, bölüm süresi, kullanılan ve kalan hamleler, boyanan hedef yüzdesi ve altın ya da reklamla devam sayıları tutuluyor. out_of_moves ise hangi devam seçeneklerinin gerçekten sunulduğunu kaydediyor. Böylece teklif hiç gösterilmeyen denemeyle, gösterilip seçilmeyen denemeyi ayırabiliyorum.

Oyuna geri dönme, gelir veya satın alma oranı için henüz oyuncu sonucu yok. Veri geldiğinde önce kayıtların doğru çalıştığını kontrol etmek, ardından bölüm bazında hipotez kurmak istiyorum. Kilim’in hamle sınırını Remote Config ile değiştirebiliyorum. Boyama ve hedef rengi desteği deneyleri içinse yeni bir oyun kuralı sürümü hazırlamak gerekiyor.

Ekonomi ve para kazanma

Oyunun para birimi altın varak. Bölüm kazanarak, ödüllü reklam izleyerek veya mağazadan paket alarak varak kazanılabiliyor. Ek hamle ve can doldurma için harcanıyor. Tablodaki değerler varsayılan oyun ayarları. Bu fiyatların oyuncu verisiyle doğrulandığını söylemiyorum.

Bölümleri dengelerken ek hamle ve satın alma olmadan tamamlanıp tamamlanmadıklarına bakıyorum. Ekonominin, temel bölümdeki bir sorunu örtmesini istemiyorum. Ücretleri ve reklam sınırlarını Remote Config ile değiştirebiliyorum. Bir değişiklikten önce neyi sınayacağımı ve hangi ölçüyü korumak istediğimi belirlemem gerekiyor.

Teknik ayrıntılar

Kodun yapısı

Oyunu Unity 6’da C# ile yazdım. Kuralları, ekranda nasıl gösterildiklerinden ayırdım. Geliştirici araçları da bu kuralları kullanıyor. Bir kural değiştiğinde oyun, botlar ve editör aynı kodla çalışmaya devam ediyor.

Bir bölüm: harflerden oluşan küçük bir dosya

Her bölüm küçük bir JSON dosyasında duruyor. Hedef desenini harflerle tutuyorum: T turkuaz, K kobalt, M mercan, S safran, Z zümrüt, nokta ise boş kare. Engeller ayrı bir katmanda aynı biçimde yazılıyor. spawnColors, tahtaya gelen karoların renklerini belirliyor. Servi’de safran yok. target ise hata paylı botun tamamlama hedefi. Bölümü editörden veya dosyadan, kural koduna dokunmadan değiştirebiliyorum.

{
    "name": "Servi",
    "moves": 31,
    "spawnColors": [0, 1, 2, 4],
    "rows": [
        ".......",
        "...Z...",
        "..ZZZ..",
        "..ZZZ..",
        ".ZZZZZ.",
        ".ZZZZZ.",
        "..ZZZ..",
        "...M...",
        "..MMM.."
    ],
    "target": 0.86
}

Bir dokunuşun kodu

Bir gruba dokunulduğunda Blast sonucu hesaplayıp tahtaya uyguluyor. Hamle sayacı, kazanma, kaybetme ve yosun yayılması da burada belirleniyor. Preview aynı hesabı tahtayı değiştirmeden yapıyor. Botlar seçenekleri bununla değerlendiriyor. Böylece testteki kuralla oyundaki kural aynı kalıyor.

public BlastResult Preview(int x, int y) =>
    State == GameState.Playing ? Resolve(x, y, previewResult) : null;

public BlastResult Blast(int x, int y)
{
    if (State != GameState.Playing) return null;
    var result = Resolve(x, y, moveResult);
    if (result == null) return null;

    MovesLeft--;
    MoveNumber++;
    Apply(result);
    RecountPainted();

    if (PaintedCount >= TargetCount) State = GameState.Won;
    else if (MovesLeft <= 0) State = GameState.Lost;
    else
    {
        if (result.MossDestroyed == 0) SpreadMoss(result);
        ShuffleUntilPlayable(result);
        if (!HasAnyMove()) State = GameState.Lost;
    }
    return result;
}

Ekranda: aynı sonucu sırayla oynatmak

Ekran kodu kuralları yeniden hesaplamıyor. Dokunuşu modele iletiyor, gelen sonucu animasyonları yöneten sınıfa veriyor. Temizlenen karolar, boyanan kareler, engel hasarı, power-up’lar, düşüş ve yosun bu sonuçtan okunup sırayla oynatılıyor.

public void Play(BlastResult result)
{
    int width = board.Layout.Width;
    if (columnReady.Length < width) columnReady = new float[width];
    System.Array.Clear(columnReady, 0, width);

    float step = result.IsToolTap ? tuning.ToolStep : tuning.RippleStep;
    float gatherEnd = ClearTiles(result, step);
    RevealCreatedTool(result, gatherEnd);
    RecolorByBrush(result, step);
    HitObstacles(result, step);
    PaintCells(result, step);
    ActivateTools(result, step);
    ShakeForGroup(result);
    SendCollectables(result, step);
    DropTiles(result);
    ApplyShuffle(result);
    SpreadMoss(result);
}

Aynı kuralın oyunda ve testte kullanılması

Patlama, boyama, düşüş, engeller ve power-up’lar aynı tahta modelinde hesaplanıyor. Botlar da bu modeli kullanıyor. Sabit seed’ler ve CSV raporlarıyla bir değişikliği yeniden ölçebiliyorum.

Bölüm düzenleme ve dengeleme araçlarının çalışma akışı Bölüm editörü kısmında. Bu araçların ortak tahta modelini kullanması, editörde gördüğüm bir kuralın oyun ve bot ölçümünde farklı uygulanmasını önlemeye yardımcı oluyor.

Oynanışı etkileyen küçük kurallar

Yeni bir karo geldiğinde %30 olasılıkla, o sütunda eksik kalan hedef renklerinden biri seçiliyor. Diğer durumlarda normal renk havuzu kullanılıyor. Desenin sonuna yaklaşırken doğru rengi bekleme ihtimalini azaltmak istedim. Power-up türünü de grup büyüklüğü belirliyor: 7 ve üstü Fırça, 10 ve üstü Kova, 13 ve üstü Mühür oluşturuyor.

int SpawnColor(int column)
{
    if (Rules.SpawnBias > 0f)
    {
        biasedSpawnPool.Clear();
        for (int y = 0; y < Height; y++)
        {
            int cell = Index(column, y);
            int target = targets[cell];
            if (target >= 0 && painted[cell] != target && Array.IndexOf(spawnColors, target) >= 0) biasedSpawnPool.Add(target);
        }
        if (biasedSpawnPool.Count > 0 && random.NextDouble() < Rules.SpawnBias)
            return biasedSpawnPool[random.Next(biasedSpawnPool.Count)];
    }
    return spawnColors[random.Next(spawnColors.Length)];
}

Remote Config değerlerinin güvenli uygulanması

Remote Config ile bölümün hamle sınırını, genel hamle katkısını, can ve ekonomi değerlerini değiştirebiliyorum. Sayıları izin verilen aralıklarda tutuyorum. Örneğin bölümün hamle sınırı 1–99 arasında kalıyor. Yeni ayarlar devam eden tahtayı değiştirmiyor, harita akışında uygulanıyor.

Bu altyapıyı deneyleri kontrollü uygulayabilmek için hazırladım. Henüz bir büyüme sonucu ölçmedim. Reklam ve satın alma akışlarını da Unity editöründe sahte servislerle kontrol edebiliyorum.

Arayüz ve görseller

Görsellerde çiniden esinlendim. Turkuaz arka plan, kobalt çerçeve ve sırlı seramik gibi parlayan kabartmalı karolar kullandım. Karoları, engelleri ve power-up’ları Blender’da hazırladım. Arayüz ve arka planı Figma’da tasarladım. Aşağıdaki görseller oyunun kendi dosyalarından.

Beş renk, beş çiçek

Her renge ayrı bir çiçek verdim. Unutma beninin yuvarlak yaprakları, çan çiçeğinin sivri yaprakları, gülün katları, papatyanın ince yaprakları ve nilüferin yandan görünüşü birbirinden ayrılıyor. Karoların yalnızca renkle tanınmasını istemedim. Renkleri ayırt etmekte zorlanan veya ekranı güneş altında gören birinin de şekilden yararlanabilmesini amaçladım.

Hedef kareyi renk dışında da göstermek

Doğru renkteki bir grup patladığında altındaki hedefler boyanıyor. Sonraki yanlış renk, tamamlanmış kareyi bozmuyor. Bekleyen hedefi göstermek için karonun çevresinde kalan şeride çapraz tarama ekledim. Boyanınca tarama kalkıyor ve zemin sırlı yüzeye dönüyor. Böylece kalan hedefleri renk dışında bir işaretle de takip edebiliyorsun.

Engeller ve power-up’lar

Engelleri ve power-up’ları karolarla aynı kamera ve ışıkta hazırladım. Birlikte durduklarında aynı görsel sete ait olmalarını istedim. Kildeki çatlak tek darbeyi, üst üste katmanlar çift darbeyi çağrıştırıyor. Kafesin içindeki karo gruba katılabildiği için rengini görünür bıraktım. Yosuna yayılan, canlı bir görünüş verdim. Pirinç ve krem rengindeki Fırça, Kova ve Mühür çiçeksiz bir karonun üzerinde duruyor. Böylece simgeleri öne çıkıyor.

• KilBir darbe
• Çift katlı kilİki darbe
• KafesKaroyu yerinde tutar
• YosunYayılır
• Fırça7–9 karelik grup
• Kova10–12 karelik grup
• Mühür13+ karelik grup

Render kalitesini düzeltmek

İlk görsellerde parlamalar sert ve tırtıklıydı. Yükseklik haritasının 8 bitlik basamakları, fazla pürüzsüz sır ve küçük ışık kaynakları buna katkı yapıyordu. Haritayı daha yüksek hassasiyetle yumuşattım, kabartmayı alçalttım, sır yüzeyini hafifçe matlaştırdım ve ışıkları büyüttüm. Görselleri iki kat çözünürlükte hazırlayıp oyun boyutuna küçülttüm. Kilde yüzeyin üzerinde duran çatlak çubuklarını gerçek oluklara çevirdim. 19 görseli yeniledim. Boyutları ve içe aktarma ayarları değişmediği için kapladıkları doku belleği artmadı.

Önce

Sonra

Önce

Sonra

Arayüz parçaları

Butonları, rozetleri, çerçeveleri, panelleri ve simgeleri Figma’da tasarladım. Lacivert dış çizgi, koyu alt ton ve hafifçe kaydırılmış açık yüzeyi hepsinde kullandım. Butonlara bir de parlama çizgisi ekledim. Panel, çerçeve ve butonları 9-slice kestim, böylece uzadıklarında köşeleri bozulmuyor. Aynı paneli diyaloglarda, mağazada ve üst bilgi alanında kullanıyorum.

• Ana buton
• Ödüllü reklam
• Harita rozeti
• Kilitli rozet
• Çerçeve
• Panel
• Can
• Altın varak
• Kilit
• Ayarlar
• Reklam izle

• Lacivert #1B2E5E
  Dış çizgiler
• Kobalt #2F63C6
  Çerçeve, reklam butonu
• Yeşil #47C65E
  Ana buton
• Safran #FFC93C
  Rozet, kilit, altın
• Mercan #F2545B
  Can
• Turkuaz #2DB7AF
  Arka plan

Ekran düzeni ve diller

Hamle sayısını büyük bir dairede, hedef deseni hemen yanında tutuyorum. Tahtanın altındaki yeniden başlatma ve haritaya dönüş seçenekleri, oynanış alanının dışında.

Menü, ipucu ve teklif metinleri 7 dilde var: Türkçe, İngilizce, Fransızca, İtalyanca, Almanca, İspanyolca ve Portekizce. Uzun metinleri, küçük ekranda hedef önizlemesini ve renk dışındaki işaretleri gerçek cihazda kontrol etmek istiyorum. Oyuncuların bunları nasıl okuduğunu da ayrıca gözlemlemek gerekecek.

Sıradaki adımlar

Gerçek oyunculara ulaşıp hedef desenin, doğru renk kuralının ve power-up’ların ne kadar anlaşılır olduğunu oynanış testlerinde kontrol etmem gerekiyor.

Genel bakış

Crumble Crew, beş gruba ayrılan 50 bölümlük bir yıkım bulmacası. Alttaki üç renkli butondan birini seçerek hedefindeki blokları kaldırıyorsun. Desteği giden yapı çöküyor. En çok bloğu yıkan hamle her zaman en iyi seçim değil. Yanlış sırayla ilerlersen son bir blok ayakta kalabiliyor.

Kısa bir kararın ardından çöküşü rahatça izleyebileceğin bir oyun yapmak istedim. Her grupta tek bir yeni blok kuralı tanıtıyor, sonra onu önceki kurallarla birleştiriyorum. Bölümün hangi kararı istediğine, bu karar için ekranda neyin görünmesi gerektiğine ve zor bölümlerin arasında nerede nefes aldıracağıma odaklandım.

Bu projede yaptıklarım

• Bölüm tasarımı: 50 bölümün tamamını geliştirdiğim editörde tasarladım. Onar bölümlük beş grubun yeni bloğunu, öğretim bölümlerini ve finalini planladım.
• Test ve iyileştirme: Bölüm kontrol aracı ve 50 davranış profili kullanan bir bot testi yazdım. Veriyi SQL ve Excel’le inceledim. Gördüğüm sorunlara göre 7 bölümü değiştirip testleri yeniden çalıştırdım.
• Ürün kararları: Analitik olaylarını ve ölçülerini belirledim. Remote Config ayarlarına sınırlar koydum. Oyunda reklam veya satın alma yok. Veriyi ilerleme, öğrenme ve performansı incelemek için kullanmayı planladım.
• Geliştirme ve görseller: Çöküş kurallarını Unity’de C# ile yazdım. Blokları Blender’da modelledim, arayüzü Figma’da tasarladım.

Veriyi nasıl topladım?

Geniş ölçekli oyuncu testine erişimim olmadığı için bölümleri, farklı oynama davranışlarını modelleyen botlarla test ettim. Botların varsayımlarını sonuçlarla birlikte paylaştım. Değişiklikleri aynı koşullarda karşılaştırdım. Bu sonuçlar bot testlerinden geliyor. Gerçek oyuncular üzerindeki etkisini henüz doğrulamadım.

Oynanış

Her buton yalnızca kendi rengindeki blokları yıkıyor. Üzerindeki sayı, o anda kaç bloğa vuracağını gösteriyor. Desteği giden bloklar düşüyor. İki blok yüksekliği veya daha fazla mesafeden düşen normal bloklar parçalanıp alttakileri de ezebiliyor. Hamleyi geri alamıyorsun ve sıradaki buton görünmüyor.

Oyun ekranındaki öğeler

4. bölümden bir ekran. Numaralar, burada sözünü ettiğim öğeleri gösteriyor.

1 2 3 4 5

1. 1Kalan hamleler. Her nokta bir hamle. Bu ekranda iki hamle kaldı.
2. 2Bölüm adı ve menü. Menü oyunu duraklatıyor: devam etmek, bölümü yeniden başlatmak ya da ana sayfaya dönmek.
3. 3Yapı. Bölümün kendisi: zemine ya da birbirine dayanan renkli bloklar. Bütün bloklar yıkılınca bölüm biter.
4. 4Hedefteki bloklar. Butona bir kez dokununca vuracağı bloklar parlıyor. Burada kırmızı 6’nın yıkacağı iki ayak. İkinci dokunuş onları yıkıyor.
5. 5Butonlar. Ekranda hep üç buton var. Rengi hangi blokları yıkacağını, sayısı kaç bloğa vuracağını söylüyor. Kullanılanın yerine sıradaki geliyor.

Oyun döngüsü

1. BakHangi blok neyi taşıyor?
2. SeçBir renge dokun, hedefler parlasın.
3. Vurİkinci dokunuş blokları yıkar.
4. İzleDesteği giden her şey çöker.

Hamleler bitince kaç bloğun ayakta kaldığı görünüyor. Bölümü tek dokunuşla yeniden başlatabiliyorsun. Geri alma yok ve sıradaki buton gizli. Oyuncunun kaybettikten sonra başka bir sıra denemesini istedim.

Bölüm dışında ilerleme bir patikadan takip ediliyor. Her bölüm sıradakini açıyor, her on bölümde yeni bir blok geliyor. Bütün bölümler bitince patikanın sonunda “Yakında” kutusu çıkıyor. Reklam ve satın alma eklemedim. İlerlemenin karşılığı yeni yapılar ve bloklar.

Bölüm tasarımı

50 bölümü onar bölümlük beş gruba ayırdım. Her grup bir yeni blokla başlıyor. Önce kuralını tanıtıyor, sonra eski bloklarla birleştiriyor ve bir finalle kapanıyor. Eski blokları oyundan çıkarmıyorum. Son bölümde çelik, bukalemun ve çift renkli bloklar birlikte kullanılıyor. Yeni bir blok fikri geldiğinde bir grup daha ekleyebilmek için katalog ve bölüm seçimini buna uygun kurdum.

Her grubun ritmini önce planlamak

Her gruba yeni bloğu tanıtan iki kısa bölümle başlıyorum. Ardından ipuçlarını kaldırıp yapıları büyütüyorum. Grubun finalinde öğrenilen kararları birlikte kullanmak gerekiyor. Öğretim bölümlerinde en fazla üç buton ve üç hamle var. Çelik grubundan dört örnek aşağıda.

Zorluk ölçüsünü nasıl kullanıyorum?

İlk baktığım şey, denenen hamle sıralarından kaçının kazandırdığı. Kazandıran yol azaldıkça hata payı daralıyor. Bu sayı çözüm alanını anlatıyor. Bir insanın bölümü ne kadar zor bulacağını tek başına söylemiyor. Tek çözümü açıkça görülen bir bölüm, birkaç yanıltıcı yolu olan bölümden daha rahat okunabilir.

Yanlış seçeneklerin ne kadar cazip göründüğünü de bu puandan anlayamıyorum. Bu yüzden bot sonucuna ve bölümün grup içindeki görevine birlikte bakıyorum. 14. bölüm Pyramid’de bunlar farklı şeyler söyledi ve tasarımı yeniden ele aldım.

Tasarım kuralları ve kontrol aracı

Normal bölümlerde hamle sırasının önemli olmasını, plan yapmanın işe yaramasını ve doğru yolun okunabilmesini istedim. Yazdığım çözücü bütün hamle sıralarını deniyor. Bu hedeflere uymayabilecek bölümleri işaretliyor, sonra tasarımı oyunda inceliyorum. Öğretim bölümlerini bu kurallardan ayrı tutuyorum. Onlarda önce yeni bloğun davranışını göstermek istiyorum.

// Öğretici bölümlerde amaç kuralı göstermek; tasarım kuralları yalnızca normal bölümlere uygulanır.
if (r.index < TutorialLevels || r.def.tutorial) return;

if (r.greedy.won) r.warnings.Add("En büyük sayıyı seçen bot kazanıyor");
if (r.myopic.won) r.warnings.Add("Sadece bu turu düşünen bot kazanıyor: uzun vadeli plan gerekmiyor");
if (!r.greedy.won && r.greedy.percent > NearMissPercent && !r.greedy.onlyArmoredLeft)
    r.warnings.Add($"En büyük sayıyı seçen bot kıl payı kaybediyor (%{r.greedy.percent}): kayıp haksız hissettirebilir");

// İlk hamleler: kazandıran hamle gözden kaçacak kadar zayıf görünmemeli, ikinci karar da önemli kalmalı.
if (bestWinningImmediate < maxImmediate * HiddenMathRatio)
    r.warnings.Add($"Kazandıran ilk hamle anlık olarak çok zayıf görünüyor ({bestWinningImmediate} blok, en iyi anlık {maxImmediate}): gizli matematik riski");
if (!standingOk)
    r.warnings.Add($"Doğru ilk hamlelerden sonra ayakta kalan yapı %{MinStanding}-{maxStanding} aralığında değil: ikinci karar önemsizleşebilir");
if (winnable == r.firstMoves.Count)
    r.warnings.Add("Her ilk hamle kazanılabilir: ilk karar önemsiz");

• En büyük sayıya basmak yetmemeli. Hep en büyük sayılı butona basan bir oyuncu bölümü geçebiliyorsa araç bölümü işaretliyor. Normal bir bölümde bu, hamle sırasının önemini yitirdiği anlamına geliyor.
• Plan yapmak işe yaramalı. Her hamlede o an en çok bloğu yıkan seçeneğe gitmek bölümü geçirmeye yetiyorsa araç işaretliyor. O zaman ileriyi düşünmeye gerek kalmıyor.
• Kolay yollar kıl payı kaybettirmemeli. En büyük sayıya veya anlık en büyük yıkıma giden yol, yapının %90’ından fazlasını yıkıp kaybediyorsa araç uyarıyor. Böyle bir kayıp tekrar deneme isteği de uyandırabilir, haksızlık da hissettirebilir. Bot verisi bu duyguyu söylemiyor. Uyarıyı tasarımı incelemek için kullanıyorum.
• Doğru ilk hamle okunabilmeli. Kazandıran ilk hamle, ilk bakışta en iyi görünen seçeneğin yarısından az blok yıkıyorsa araç uyarıyor. Destek ilişkileri bu seçimi açıklıyor olabilir. Bu yüzden yalnızca sayıya bakıp reddetmiyor, yapıyı oyunda inceliyorum.
• İki karar da önemli olmalı. Her ilk hamle kazandırıyorsa ilk karar önemsizleşiyor. Doğru ilk hamlelerin hiçbiri yapının %30–70’ini ayakta bırakmıyorsa ikinci karar önemsizleşebiliyor (bukalemunlu bölümlerde üst sınır %90). Araç iki durumu da işaretliyor.

50 bölümün tamamı bu kontrolden uyarısız geçiyor. Ama çözücü bütün buton sırasını baştan biliyor. Oyuncu ise yalnızca ekrandaki üç butonu görüyor. Balcony’deki bilgi tuzağını çözücü kaçırdı, bot testi ortaya çıkardı.

Yeni bir bloğu öğretmek

Zorluk eğrisi

Sütunlar güncel bölümlerin çözüm alanını gösteriyor. Renkler öğretim, normal ve final bölümlerini ayırıyor. Bot testinden sonra yedi bölümü değiştirdim. 10 Ekim’de kataloğu yeniden kontrol ettim: 50 bölümün de çözümü var. Taranan durumlarda başlangıçta desteksiz blok, sıfır hedefli buton veya aynı blokları hedefleyen iki seçenek bulunmadı. Bunlar kural kontrolleri. Oyuncuların hissettiği zorluk henüz ölçülmedi.

Gruplara iki kolay öğretim bölümüyle başlıyorum. Zorluk dalgalanarak artıyor ve finalde yükseliyor. Aradaki düşüşleri de planladım. Zor bir bölümün ardından nefes alma bölümü geliyor. Yeni gruba geçince de yeni kuralı deneyebilmen için baskıyı düşürüyorum.

Bölüm editörü

50 bölümün tamamını Unity’de geliştirdiğim editörle tasarladım. Yapı, buton sırası, hamle bütçesi ve tasarım notu aynı yerde duruyor. Önce bölümdeki kararı belirliyorum, sonra yapıyı kuruyorum. Kontrolleri çalıştırıp taslağı kaydetmeden oyunda açabiliyorum. Aşağıda bu akışı 20. bölüm Viaduct üzerinden gösteriyorum.

1. Kur: Yapıyı ızgarada boyuyor, butonları ve hamle sayısını diziyorum.
2. Kontrol et: Canlı kontrol bütün hamle sıralarını deniyor. Kaçının kazandırdığını ve hangi tasarım kuralının tutmadığını hemen gösteriyor.
3. Oyna ve düzelt: Bölümü kaydetmeden oyunda açıp çöküşün nasıl göründüğüne ve yapının telefonda rahat okunup okunmadığına bakıyorum.

Editörde bir bölümün adımları ve ekran görüntüleri

1. Bir şekille başlıyorum. Köprü, vinç, saat kulesi… Bölümlerin adı da buradan geliyor. Şekil kadar önemli olan, oyuncunun orada neye karar vereceği: hangi ayağı önce kesecek, çatıyı mı indirecek temeli mi?
2. Yapıyı çiziyorum. Üstteki paletten blok türünü ve rengini seçip ızgarada sürükleyerek boyuyorum. Sağ tık siliyor, Alt tuşuyla tıkladığım blok fırçam oluyor. Yapı ızgaraya sığmazsa ızgarayı soldan, sağdan ya da üstten genişletiyorum. Desteği olmayan blok kırmızı çerçeveyle işaretleniyor. Bölüm açılır açılmaz bir şeyin düşmesini istemiyorum.

   

3. Butonları diziyorum. Her butonun bir rengi ve bir sayısı var. İlk üçü bölüm açıldığında ekranda oluyor, diğerleri sırayla geliyor. Yani butonların sırası da bulmacanın bir parçası. Bir butonun üzerine geldiğimde ilk hamlede hangi bloklara vuracağını ızgarada görüyorum. Oyuncunun kaç hamle hakkı olacağını da bu aşamada belirliyorum.

   

4. Canlı kontrole bakıyorum. Sağdaki panel her değişiklikte yenileniyor ve bana şunları söylüyor: bütün hamle sıralarından kaçı kazandırıyor, en kısa çözüm hangisi, hep en büyük sayıya basan ya da sadece o hamleyi düşünen bir bot kazanıyor mu, her ilk hamle yapının ne kadarını ayakta bırakıyor. Tutmayan bir şart varsa hemen altında uyarı olarak çıkıyor.

   

5. Sayılar tutana kadar değiştiriyorum. İşin en uzun kısmı bu, çünkü tek bir blok bütün bölümü değiştirebiliyor. Yukarıdaki 20. bölümde 81 hamle sırasından yalnızca biri kazandırıyor. Ortadaki iki ayaktan sağdakinin en alt bloğu mavi. Onu sarıya çevirdiğimde bu sayı 7’ye çıkıyor ve hep en büyük sayıya basan bot da kazanmaya başlıyor, yani final için koyduğum planlama hedefi tutmuyor (resimde). Aynı şeyi soldaki ayağın ortasındaki blokta yaptığımda ise hiçbir sıra kazandırmıyor. İkisini de oyunu açmadan, bloğu boyadığım anda görüyorum.

   

6. Benzer bölümlere bakıyorum. Karar yapısı başka bir bölüme çok benziyorsa editör adını gösteriyor. Bölümlerden birini değiştirebiliyor veya aralarını açabiliyorum. Farklı görünen iki yapının aynı bulmacayı tekrar etmesini istemiyorum.
7. Oyunda deniyorum. Kural kontrolü tasarım hedeflerimi karşılıyor, keyifli olup olmadığını söylemiyor. “Oyunda dene” tuşu bölümü doğrudan oyunda açıyor. Çöküş güzel görünüyor mu, yapı telefon ekranında rahat okunuyor mu, ona bakıyorum.

   

8. Sıraya koyuyorum. Bölümü listede yukarı aşağı taşıyıp difficulty curve’deki yerine oturtuyorum. Listede her bölümün yanındaki nokta kontrolden geçip geçmediğini gösteriyor. Build alırken bütün bölümler bir kez daha denetleniyor.

   

Canlı kontrol çözüm olup olmadığını ve seçeneklerin birbirini tekrar edip etmediğini gösteriyor. Bütün buton sırasını biliyor. Oyuncunun görebildiği üç butonla nasıl karar vereceğini ise bu araç tek başına değerlendiremiyor. Bunun için davranış profilli botlara ve oyundaki görsel kontrole bakıyorum.

14. bölüm: sorun, karar, sonuç

Pyramid, çelik grubunda üç hamlelik bir bölüm. 27 sıradan 2’si kazandırıyor: önce kırmızı 9, sonra sarılardan biri, en son mavi 8. Başlangıçta yalnızca üç buton görünüyor. Diğerleri kullanılan butonun yerine geliyor. İlk bot testinde iki veya üç hamle ileriyi hesaplayan profillerin yalnızca %2’si ilk denemede kazanıyordu. Anlık hamleye bakanlarda bu oran %55’ti. Plan yapmayı desteklemek istediğim bölümde sonuç tersine dönmüştü.

Sorun: kazanan yolun son parçası ekranda değildi

Eski sırada mavi 8, ikinci hamleden sonra görünüyordu. Ekrandaki butonlarla plan yapan bot, gördüğü en iyi devamı seçip kaybediyordu. Anlık hamleye bakan bot için kırmızı 3 ve sarı 3 eşit görünüyordu. İkisi de yapının %9’unu yıkıyordu. Botların yarısı sarıyı seçiyor, sonra açılan mavi 8’e basıp kazanıyordu. Kazanan yolu bulmalarını planlarından çok bu eşit seçim belirliyordu.

Değişiklik: haritaya dokunmadan sırayı değiştirmek

Kazanan devamın ekrandaki bilgiyle görülebilmesini istedim. Plan yapmak işe yaramalı, yalnızca o an en çok bloğu yıkmak yeterli olmamalıydı. Çözüm alanını da korumak istedim: yine 27 sıradan 2’si kazandırmalıydı.

Sıradaki kırmızı 3 ile mavi 8’in yerini değiştirdim. Yapı aynı kaldı. Mavi 8 artık ilk hamleden sonra görünüyor. Sarıdan sonra kullanıldığında bütün yapıyı indireceği hesaplanabiliyor. Hemen mavi 8’e basmak ise kazandırmıyor. Sarıdan önce kullanıldığında yapının %22’si ayakta kalıyor ve son hamle yetmiyor.

Bu değişikliği seçmeden önce iki adayı daha aynı testten geçirip eledim:

• Kırmızı kirişin en sağdaki bloğunu sarıya çevirmek. Plan yapan botların ilk denemede kazanma oranı %62’ye çıktı, ama kazandıran sıra 27’de 1’e düştü ve bölüm kâğıt üzerinde zorlaştı. 14. bölüm bir final değil, bu yüzden eledim.
• Sarı 3’ü sarı 1 yapmak. Kazandıran sıra yine 27’de 1’e düştü ve plan yapan botlar (%16) o anki hamleye bakanlardan (yaklaşık %25) hâlâ daha az kazanıyordu. Sorunu çözmüyordu.

Sonuç ve öğrendiğim şey

Plan yapan profillerin ilk denemede kazanma oranı %2’den %42’ye çıktı. Kazandıran sıra sayısı 27’de 2 olarak kaldı. Bütün profiller birlikte değerlendirildiğinde oran %22’den %28’e yükseldi. Açılışta hâlâ iyileştirilecek yer var. Bu değişikliği, çözüm alanını daraltmadan plan yapmayı daha iyi desteklediği için seçtim. Testin kapsamını Botlarla A/B karşılaştırmaları kısmında anlatıyorum.

Test ve dengeleme

İki ayrı test kullandım: bölümdeki kararları incelemek için tek tek bölüm testi, simülasyondaki ilerlemenin nerede durduğunu görmek için sırayla oynama testi. Bu kısımdaki sonuçlar, yedi değişiklikten önceki başlangıç ölçümü. Güncel katalog kontrolünü ve önce–sonra karşılaştırmalarını bundan ayrı gösteriyorum.

Bot profilleri ve test yöntemi

Planlama derinliği, hata eğilimi, hafıza ve sabır ayarları farklı 50 bot profili hazırladım. Her bot oyunun kendi kural kodunu kullanıyor. Yalnızca ekranda görünen üç butonu biliyor, sıradakini göremiyor. Profiller aşağıdaki özelliklerde ayrılıyor:

• Düşünme derinliği. Bir, iki ya da üç hamle ileriyi hesaplıyor.
• Dalgınlık. İki seçenek birbirine yakın göründüğünde ne sıklıkla yanlışını seçiyor.
• Büyük sayı merakı. Üzerinde büyük sayı olan butona basmaya ne kadar meyilli.
• Hafıza. Kaybettiren açılışı bir sonraki denemede ne kadar hatırlıyor, sıradaki butonları aklında tutup tutmuyor.
• Sabır. Aynı bölümde art arda kaç kez kaybedince oyunu bırakıyor.

Her profil oyunu 20 kez oynadı. Testi, rastgele oluşturduğum dört ayrı 50 profillik grupla tekrarladım. Toplam 4.000 koşu var: dört grup × 50 profil × 20 tekrar. Grupları değiştirerek bulguların profil karışımına ne kadar bağlı olduğuna baktım. Davranış ayarlarını ben seçtim. Gerçek oyuncu verisiyle henüz ayarlanmadıkları için bu botları tasarımdaki sorunları aramakta kullanıyorum.

Tek tek bölüm testinde dört grup × 50 profil × 20 tekrar, her düzen için 4.000 koşu oluşturuyor. Sırayla oynama testinde ise 4.000 bot oyuna başlıyor. Sonraki bölümlere daha azı ulaşıyor. Bunlar aynı davranış varsayımlarının tekrarları. 4.000 insan katılımcı yok. Excel özeti ilk sırayla oynama testine ait, sonraki düzenlerin ham kayıtlarını içermiyor.

İlk testte gördüğüm sorunlar

Zorluk puanı ile botların deneme sayısı çoğunlukla aynı yönde değişti. Sıra korelasyonu 0,89, tam örtüşme 1 olurdu. Daha çok şey öğrendiğim örnekler ise bu ilişkiye uymayan bölümlerdi:

• Çözüm sayısına göre orta, botta zor. Fountain’da (44) 27 sıradan 2’si kazandırıyor. Aynı çözüm oranına sahip bölümlerde botların başarı başına deneme değeri 3–4 iken Fountain’da 9,5. Kaybettiren iki açılış, kazandıran seçeneğe çok benziyor. Çözüm sayısı bu benzerliği göstermiyor.
• Kontrol aracının göremediği tuzak. Balcony’de (5. bölüm) doğru çözüm, henüz ekranda olmayan bir butona bağlı. Ekrandakine bakarak en iyi hamleyi yapan bot bile ilk denemede kaybediyor. Botların yalnızca %3’ü ilk denemede geçiyor. Kontrol aracı bütün butonları baştan bildiği için bunu görmüyordu. Bu, oyunun beşinci bölümünde ilk denemeyi etkileyen bir bilgi tuzağı. Erken ilerlemede özellikle incelemek istediğim bir nokta.
• Plan yapmanın ters teptiği bölüm. Pyramid’de (14) anlık hamleye bakan botların %55’i ilk denemede kazanıyor. İki veya üç hamle ileriyi hesaplayanlarda oran %2. Bölümün plan yapmayı desteklemesini istediğim için buton sırasına yeniden baktım.
• Erken bir duvar. Crane (10. bölüm) ilk grubun finali. Sırayla oynama testinde Crane’e ulaşan botların %46’sı oyunu burada bırakıyor. İlk grubun finali olduğu için bu darboğazı, sonraki bölümlerden önce ele aldım.
• Ortadaki bölüm finalden zor. Ship (28. bölüm), grubunun finalinden bile fazla deneme istiyor ve grubun temposunu bozuyor.
• Takılıp kalınan bölümler. Robot’ta (47. bölüm) botların %10’u, son bölüm Skyline’da (50. bölüm) üçte biri 30 denemede bile çözemiyor.

İlk düzende 50 bölümün başarı başına deneme grafiği

Her sütun bir bölümü gösteriyor. Yüksekliği, toplam denemenin bölümü geçen bot sayısına bölünmesiyle hesaplanıyor. Grafik değişikliklerden önceki tasarımlara ait.

SQL ve Excel

Yedi bölümü değiştirmeden önceki sırayla oynama testinde, 4.000 bot koşusunda toplam 126.873 deneme oynandı. level_start ve level_end kayıtlarını üç tabloya aktarıp SQL’le inceledim. Sorgular SQLite’ta çalışıyor.

• players: her satır bir bot. Kaç hamle ileriyi düşündüğü lookahead, kaç bölüm geçtiği, oyunu bitirip bitirmediği ve bıraktıysa hangi bölümde bıraktığı: stopped_at_level.
• attempts: her satır bir deneme: bölüm, kaçıncı deneme olduğu, kalan blok sayısı ve kazanıp kazanmadığı. Kazandıysa won 1, kaybettiyse 0.
• levels: her bölümün numarası ve adı.

1. Botları en çok hangi bölümde kaybediyoruz?

-- Botları en çok hangi level'da kaybediyoruz?
SELECT p.stopped_at_level AS level,
       l.name,
       COUNT(*) AS bots_quit
FROM players p
JOIN levels l ON l.level = p.stopped_at_level
WHERE p.finished = 0
GROUP BY p.stopped_at_level, l.name
ORDER BY bots_quit DESC
LIMIT 5;

Sorgu ne yapıyor? Oyunu bitirmeyen botları alıyor ve bıraktıkları bölüme göre gruplayıp her bölümde kaç bot bıraktığını sayıyor. JOIN, bölüm numarasının yanına levels tablosundan adını getiriyor. En büyük beş sayı listeleniyor.

Ne gördüm? En çok bot Crane’de, 10. bölümde bırakıyor: 1.149 bot. Bu, Crane’e ulaşan 2.520 botun %45,6’sı. Crane ilk grubun finali. Bu yüzden ilk incelediğim yer oldu. İkinci sıradaki Balcony’de (5. bölüm) sonradan bir bilgi tuzağı buldum.

2. Kayıplar kıl payı mı?

-- Kaybedilen attempt'lerin ne kadarı kıl payı (1–2 blok kaldı)?
SELECT a.level,
       l.name,
       COUNT(*) AS losses,
       ROUND(100.0 * SUM(CASE WHEN a.blocks_left <= 2 THEN 1 ELSE 0 END) / COUNT(*), 1) AS near_miss_pct
FROM attempts a
JOIN levels l ON l.level = a.level
WHERE a.won = 0
GROUP BY a.level, l.name
HAVING COUNT(*) >= 100
ORDER BY near_miss_pct DESC
LIMIT 5;

Sorgu ne yapıyor? Yalnızca kaybedilen denemelere bakıyor: won = 0. Her bölümde kaybı sayıyor. CASE WHEN, 1–2 blok kalan kaybı 1, diğerlerini 0 sayıyor. Toplamı kayıp sayısına bölüp yüzdeye çeviriyor. HAVING, 100’den az kaybı olan bölümleri dışarıda bırakıyor, çünkü az veriyle yüzde yanıltıcı olur.

Ne gördüm? Kite’ta kayıpların %95’i, yalnızca 1–2 blok kaldığında oluyor. Bu kadar yaklaşmak yeniden deneme isteği de uyandırabilir, haksızlık da hissettirebilir. Hangisinin yaşandığını bot verisi söylemiyor. Oynayan birini izlemek gerekiyor.

3. Plan yapan bot Pyramid’de kazanabiliyor mu?

-- Pyramid'de (14. level) plan yapan botlar ilk attempt'te kazanıyor mu?
SELECT p.lookahead,
       COUNT(*) AS bots,
       ROUND(100.0 * SUM(a.won) / COUNT(*), 1) AS first_try_win_pct
FROM attempts a
JOIN players p ON p.player_id = a.player_id
WHERE a.level = 14 AND a.attempt_no = 1
GROUP BY p.lookahead
ORDER BY p.lookahead;

Sorgu ne yapıyor? Pyramid’in (14. bölüm) ilk denemelerini alıyor. Botun ne kadar ileriyi düşündüğü players tablosunda olduğu için iki tabloyu JOIN’le birleştiriyor ve sonucu lookahead değerine göre ayırıyor. won 1 ya da 0 olduğu için SUM(won) kazanan sayısını veriyor. Bunu bot sayısına bölüyor.

Ne gördüm? Anlık hamleye bakan botların %58,7’si ilk denemede kazanıyor. İki veya üç hamle ileriyi hesaplayanlarda oran yalnızca %2. Bu ilerleme verisi de Pyramid’de plan yapmanın tersine çalıştığını gösterdi. Buton sırasını bu yüzden değiştirdim.

Excel çalışma kitabı

Veriyi Excel’de de inceledim. Attempts sayfasında her deneme bir satır. Levels sayfası, COUNTIFS ile bu satırlardan bölüm sonuçlarını hesaplıyor. Örneğin bölüm numarası ve ilk deneme koşulunu birlikte sayarak başlayan bot sayısını buluyorum. Segment sayfasındaki sarı hücreye bölüm numarası girince ilk denemede kazanma oranı, botun planlama derinliğine göre yeniden hesaplanıyor.

C2 · level’a başlayan bot: o level’da 1. attempt’i olan satırlar
=COUNTIFS(Attempts!C:C, A2, Attempts!D:D, 1)
K2 · near miss: kaybedilip 1–2 blok kalan attempt’lerin kayıplara oranı
=IFERROR(COUNTIFS(Attempts!C:C, A2, Attempts!E:E, 0, Attempts!G:G, "<=2")/J2, 0)

Excel çalışmasındaki bölüm özeti

Tablo, yedi değişiklikten önceki sırayla oynama testinin 50 bölümlük özeti. 4.000 başlangıç ve 126.873 deneme var. Bir bölümü tek başına başlatan testten farklı olarak burada yalnızca o bölüme ulaşmış botlar bulunuyor. Bütün satırları görmek için tabloyu kaydırabilirsin.

Ulaşma oranını 4.000 başlangıca göre hesaplıyorum. Bırakma ve ilk denemede kazanma oranlarında ise o bölüme ulaşan botları kullanıyorum. Başarı başına deneme hesabında toplam denemeyi geçen bot sayısına bölüyorum. Geçemeyenlerin denemeleri de bu toplama dahil. Kıl payı kayıp oranı, bir veya iki blok kalan kayıpların bütün kayıplara bölünmesi. Çalışma sayfasındaki “oyuncu” kimliklerinin tamamı bot koşularına ait. Başlangıç ve kazanma sayılarını COUNTIFS ile buluyorum.

Bot verisiyle iyileştirmeler

Bir değişikliği yalnızca deneme sayısını düşürdüğü için seçmedim. Bölümün grup içindeki görevini koruması, çözülebilir kalması ve buton kontrollerinden geçmesi de gerekiyordu. Aşağıdaki yüzdeler önceki bot karşılaştırmalarının yuvarlanmış özetleri. Yeni oyuncu ölçümleri yok.

Yedi bölümde küçük değişiklikler denedim. Bazen bir veya iki bloğun rengini, bazen iki butonun sırasını değiştirdim. Önce kontrol aracını çalıştırdım. Sıfır hedefli veya aynı bloklara vuran butonlar olmamalı, en büyük sayıya basmak tek başına kazandırmamalıydı. Bu kontrolleri geçen taslakları botlarla yeniden ölçtüm. Bölümün rolünü koruyan seçenekler arasından tercih ettiğimi kaydedip nedenini tasarım notuna yazdım.

7 bölümde ne değişti?

Pyramid ve Robot’ta kazandıran sıra sayısı değişmedi. Pyramid’de plan yapan botlar daha çok kazanıyor. Robot’ta yanıltıcı açılışı kaldırınca başarı başına deneme değeri yarıdan fazla düştü. İki örnekte de çözüm alanını genişletmeden botların kararlarını değiştirebildim.

Yeniden testten sonra

• Crane’e ulaşıp oyunu orada bırakan botlar %45,6’dan %29’a indi.
• 11. bölüme ulaşan koşular %34’ten %47’ye, son bölüme ulaşanlar %2,6’dan %4,3’e çıktı.
• Darboğaz yer değiştirdi: botların en çok bıraktığı bölüm artık Aqueduct (18. bölüm). Buraya ulaşanların %35,6’sı oyunu bırakıyor.
• Balcony’de ilk denemede geçen botlar %3’ten %10’a çıktı. Oyunun beşinci bölümü için hâlâ düşük.

Crane ve Skyline’da buton sırası ile bir bloğun rengi birlikte değişti. Karşılaştırma yeni tasarımın bütününü ölçüyor. Farkı tek bir değişikliğe bağlayamıyorum. İlerleme oranları da botların sabır ayarından etkileniyor. Gerçek oyuncuların oyuna geri dönme oranını ölçmedim.

Botlarla A/B karşılaştırmaları

Bir butonu daha erken göstermek, çözüm alanını değiştirmeden plan yapmayı destekleyebilir mi? Pyramid’de bu soruya baktım. A eski sıra. B’de sıradaki kırmızı 3 ile mavi 8 yer değiştiriyor. Yapı, üç hamlelik bütçe, başlangıç butonları ve kurallar aynı.

B’yi seçtim. Plan yapan botların ilk denemede kazanma oranı 40 yüzde puanı arttı. Anlık hamleye bakanlarda %55’ten %4’e indi. Bu bot modelinde plan yapmak daha çok işe yarıyor. Bütün profillerde artış yalnızca 6 puan. Bu yüzden açılışı incelemeye devam edeceğim.

Bu test botlarla yapıldı. İnsan katılımcıları rastgele iki gruba ayırmadım. Yüzdeler önceki testin yuvarlanmış özetleri. 10 Ekim’de iki sırada da 27’de 2 çözüm olduğunu yeniden kontrol ettim. Bu kontrol, davranış yüzdelerini yeniden ölçmüyor. Oyuncuların dönüşümü, istatistiksel anlamlılık veya oyuna geri dönmesi hakkında bu karşılaştırmadan sonuç çıkarmıyorum.

Neden bir hamle daha eklemedim?

Zor bölüme bir hamle eklemeyi de kontrol ettim. Ama fazladan hamle, sıranın sonunda sıfır hedefli veya aynı hedefleri seçen butonlar açabiliyor. Bütçeyi artırmak bu yüzden tek başına geçerli bir çözüm değildi. Düzenlemeleri bölümün içinde yaptım. Remote Config ile değiştirdiğim bütçeleri de deneye almadan önce bu kontrolden geçirmem gerekiyor.

Analitik ve ürün kararları

Analitik olaylarını, oyuncu verisi geldiğinde araştırmak istediğim sorulara göre kurdum. Aşağıda neyi ölçeceğimi ve sonuca göre neyi inceleyeceğimi gösteriyorum. Henüz oyuncu sonuçları yok. Yerel bot dosyaları ile Firebase’e giden oyuncu kayıtlarını ayrı tutuyorum.

Ölçünün paydasını doğru kurmak

Deneme numarası cihazda saklanıyor. Bölüm sonu kaydında sonuç, kullanılan ve kalan hamleler, kalan bloklar ve süre var. Yeniden başlama ile başka bölüme geçişi ayrı çıkış nedenleri olarak tutuyorum. Hiç hamle yapmadan çıkılan bölümü oynanmış bölüm kaybı olarak saymıyorum. Uygulama kapanırsa başlangıcı olan ama bitişi olmayan bir kayıt kalabilir. Bu kayıtları ayrıca incelemek gerekiyor.

Aynı ölçü tanımlarını kullanarak ileride bot ve oyuncu sonuçlarını karşılaştırabilirim. Ancak iki grup eşdeğer değil. İlk ve yedinci gün geri dönüşünü ölçmek için tarihli oyuncu grupları ve yeterli gözlem süresi gerekiyor. Botların sonraki bölüme ulaşması bu soruyu cevaplamıyor.

Ekonomi ve ürün tercihleri

Crumble Crew’de reklam, uygulama içi satın alma, oyun içi para veya can sistemi yok. Bölümü çözüyor, kaybedince yeniden deniyor ve sonraki yapıyı açıyorsun. Her on bölümde yeni bir blok geliyor. Bu akışta ücretli devam seçeneği, bölümün temel zorluğunu değiştirmiyor.

Görünür ödül, yapının çökmesi ve patikada sonraki durağın açılması. Bu akışı tercih ettim. Oyuncuların geri dönüşünü artırdığını veya başka bir gelir modelinin kötü işleyeceğini ölçmedim. Analitik planını ilerleme, öğrenme ve performans üzerine kurdum.

Teknik ayrıntılar

Oyunla kontrol aracının aynı kuralları kullanması

Neyin düşüp kırılacağını ızgara modeli hesaplıyor. Fizik motoru bu sonucu enkazla gösteriyor. Blok yerdeyse, altında sağlam blok varsa veya aynı sırada en fazla iki hücre uzaktaki sağlam komşuya bağlıysa destek alıyor. Desteksiz bağlı bloklar birlikte düşüyor. Bir hücrelik düşüşte sağlam kalıyorlar. İki hücre ve üzeri düşüş normal blokları parçalayabiliyor ve alttakileri ezebiliyor. Yapı durana kadar hesap tekrarlanıyor. Özel blokların kuralları da bu modelin üzerine ekleniyor.

Editör ve kontrol aracı aynı ızgara modelini kullanıyor. Bölümler, sıralı katalogdaki ayrı veri dosyalarında duruyor. Arayüz Toolkit ile yazdığım editörde işlemleri geri alabiliyorum. Sürükleyerek boyadığım alan tek adım sayılıyor. Çizimden kısa bir süre sonra kontrol yeniden çalışıyor. Oyun derlenmeden önce eksik veya çözümsüz bölümler de taranıyor.

Remote Config ve sınırları

Remote Config ile genel olarak 0–2 hamle eklenebiliyor. Bölüm bütçesi ve test grubu değiştirilebiliyor, değerlendirme istemi açılıp kapatılabiliyor. Bütçe tasarlanan değerin altına inmiyor ve beş hamleyi geçmiyor. Öğretim bölümleri kendi bütçelerini koruyor. Eksik ayarda varsayılan değer kullanılıyor. Yeni ayar, sonraki bölüm açılırken uygulanıyor. Bu sınırlar sıfır hedefli butonu tek başına önlemiyor. Her aday bölüm kontrolünden de geçmeli.

Telefon bütçesi içinde çöküş efekti

Blender’da bloğun beş parçaya ayrılan bir kopyasını hazırladım. Enkaz için aynı parçaları bir havuzdan yeniden kullanıyorum. Telefonda aynı anda en fazla 100 parça etkin. Sınır dolunca yeni kırılmalarda toz efekti çıkıyor. Parçalar birbirine çarpmıyor. Böylece efektin maliyetini sınırladım. Bütün cihazlarda ölçülmüş bir FPS sonucu henüz yok.

Ekran sarsıntısı blok kütlesine ve düşme yüksekliğine göre değişiyor. Altı veya daha fazla blok çarptığında 0,05 saniyelik duraklama var. Son çöküş yarım saniye boyunca %35 hızda oynuyor. Android ve iOS’ta titreşim de darbeyi destekliyor. Bu efektlerle hamlenin sonucunu belirginleştirmek istedim.

Test kayıtlarının oyuncu analitiğine karışmaması

Botlar yerelde çalışıyor ve Firebase’e bağlanmıyor. Editör ve ölçüm modlarında analitik gönderimi kapalı. Ölçüm modunda Remote Config ve değerlendirme istemi de uygulanmıyor. Çökme raporlarına bölüm bilgisi ekleniyor. Böylece bot koşuları oyuncu oturumu olarak sayılmıyor.

Arayüz ve görseller

Arayüzü Figma’da, blokları Blender’da tasarladım. Butonlar ve blokların görünüşü, bölüm tasarımını da etkiledi. Oyuncunun ekrandan okuyabildiği bilgiye göre yapıları ve seçenekleri kurdum.

Üç buton, 81 ihtimal

Arayüzü Figma’da 1170 × 2532 boyutunda bir telefon ekranında çizdim. Altta her zaman üç buton var. Her biri ekranın dörtte biri genişliğinde ve başparmakla erişilebilecek alanda. Üzerlerinde yalnızca renk ve büyük bir sayı kullandım.

Üç buton, çözüm alanının boyutunu da belirliyor. Her hamlede üç seçenek var ve kullanılanın yerine sıradaki geliyor. İki hamlede en fazla 9, üç hamlede 27, dört hamlede 81 sıra oluşuyor. Zorluk puanını bu sıralardan kaçının kazandırdığına göre hesaplıyorum.

Butondaki sayı, o anda kaç bloğa vuracağını gösteriyor. Yapı değişince sayı da güncelleniyor. İlk dokunuşta hedefleri ayrıca işaretliyorum. Bu bilgiyi korumak için kontrol aracına iki kural ekledim: sıfır hedefli buton olmamalı ve görünen iki buton aynı blokları hedeflememeli. Editör ikisini de hata olarak gösteriyor. Güncel 50 bölümde bu hatalar bulunmadı.

Ekrandaki parçalar

Figma’da az sayıda parça çizdim ve farklı ekranlarda yeniden kullandım. Hamle butonları, blok renklerinin açık tonlarında. Koyu alt kenarları basılabilir bir kalınlık veriyor. Yeşil ana eylemleri, beyaz ikincil seçenekleri gösteriyor. Sol üstteki turuncu noktalar kalan hamleler. Harcanan hamle boş ve soluk bir daireye dönüyor. Beyaz hap biçimli görseli uzatıp renklendirerek bölüm etiketi, harita patikası ve ipucu balonu yaptım. Kart başlıklarında sarı şerit kullanıyorum.

• Kırmızı buton
• Mavi buton
• Sarı buton
• Ana buton
• İkincil buton
• Menü
• Hap
• Başlık şeridi
• Kart
• Kalan hamle
• Kullanılan hamle
• Tutorial eli

• Kırmızı #FF4D3A
  Blok ve buton
• Mavi #2B7CFF
  Blok ve buton
• Sarı #FFC41F
  Blok ve buton
• Yeşil #35A358
  Zemin
• Çelik #8C949E
  Çelik blok çerçevesi
• Gece mavisi #143A63
  Menü arka planı

Yapıyı kullanılabilir ekrana sığdırmak

Kamera yapıyı üst çubukla alttaki butonlar arasına sığdırıyor. Güvenli alanı ve geniş ekran kenar boşluklarını hesaba katıyor. Geniş köprülerle küçük kuleler böylece aynı oyun alanında gösterilebiliyor. Küçük ekranları ve uzun çevirileri yine gerçek cihazda kontrol etmek gerekiyor.

Şekli kuralını anlatan bloklar

Blokları Blender’da modelledim. Oyuncunun görünüşlerinden kurallarına dair bir ipucu almasını istedim. Her özel blokta farklı bir özellik kullandım:

• Çelik blok metal bir çerçeveyle sarılı: düşünce kırılmıyor.
• Bukalemun bloğun üstünde üç renkli bir çark var: her hamleden sonra son basılan butonun rengine dönüyor.
• Çapa blok çelik bir kelepçeyle tutturulmuş: altı boşalsa da düşmüyor.
• Çift renkli blok ortadan ikiye ayrılmış: kırmak için iki vuruş gerekiyor, her renge bir tane.

Oyun alanında çok az yazı kullandım. Butonlarda yalnızca renk ve sayı var. Dokuz dilde menü ve ipuçları değişiyor, bulmacanın kuralları aynı kalıyor. Yeni blokları iki kısa bölümde tanıtmayı hedefledim. Görsel işaretlerin bu öğretimi ne kadar desteklediğini oyuncu gözleminde kontrol etmek istiyorum.

Bloğun kırılan hali de Blender’da modellendi: blok önceden parçalara bölündü, oyunda kırıldığında bu parçalar etrafa saçılıyor. Parçaların nasıl savrulduğunu ve telefonu yormamak için nasıl sınırlandığını yukarıda, Teknik ayrıntılar kısmında anlattım.

Uygulama simgesi: 31 deneme

Uygulama simgesi için Blender’da 31 görsel denedim. Önce kırılmayı tek küple anlattım: köşesi kopmuş, çatlamış veya parçalanmış bloklar yaptım. Sonra üç oyun rengini taşıyan bir küp yığınına geçtim. Dizilişleri ve arka plan tonlarını değiştirdim. Seçtiğim görselde üst küp hafifçe kayık duruyor. Yığının çökebilecekmiş gibi görünmesini istedim. Siyah siluette de kontrol ettim. Renk olmadan üç küp hâlâ seçilebiliyor. Yazı logosunda da aynı renk ailesini kullandım.

Büyümeye hazır bölüm seçimi

Bölüm seçimi bir patika: her bölüm bir durak, sıradaki bölüm kilitli duruyor. Bütün bölümler bittiğinde patikanın sonunda bir “Yakında” kutusu çıkıyor, bitiş ekranı da “Yeni bölümler çok yakında!” diyor.

Patika, katalogdaki bölüm sayısına göre oluşuyor. Yeni bir grup eklediğimde bölümleri editörden kataloğa koymam yeterli. Bölüm seçimi ekranını yeniden düzenlemem gerekmiyor.

Sıradaki adımlar

Gerçek oyunculara ulaşıp üç butonla nasıl plan yaptıklarını, destek ilişkilerini ve özel blok kurallarını nasıl yorumladıklarını oynanış testlerinde gözlemlemem gerekiyor.