Geliştirme Günlüğü: Özellik Kesmenin Gerçek Maliyeti

Bir oyunun kalitesini belirleyen şey çoğu zaman içine koyduğunuz özellikler değil, koymamaya karar verdikleriniz oluyor. Bu yazıda kesme kararının nasıl verildiğini, hangi sinyallerin "bu özellik gitmeli" dediğini ve silme işleminin kodda, tasarımda ve ekip motivasyonunda bıraktığı gerçek faturayı anlatıyoruz.

Amaç bir başarı hikâyesi değil. Amaç, aynı kararı sizin de daha az acıyla verebilmeniz için işlemin adımlarını açık yazmak. Kart Üçlüsü gibi bir kart oyunuyla Thornguard: Tower Defense gibi bir kule savunma oyunu, kapsam baskısını çok farklı yerlerden hissettirir; ikisini yan yana koyunca kesme kararının genel bir kas olduğu, türden bağımsız çalıştığı görülüyor.

Kesme kararı başarısızlık değil, muhasebe işlemidir

"Bu özellik çalışmadı" cümlesi genelde yanlış kurulur. Doğrusu şudur: bu özelliğin sağladığı fayda, kalan ömrü boyunca üreteceği bakım maliyetinden küçük. Fayda tarafında oyuncunun aldığı şey vardır: daha iyi bir karar anı, daha net bir geri bildirim, daha uzun bir oturum. Maliyet tarafındaysa yalnızca yapım süresi yok; test yüzeyi, arayüzde kapladığı yer, dengelemeye eklediği değişken sayısı, lokalizasyon metni, kayıt dosyası formatındaki alan ve gelecekteki her yeni özelliğin bu özellikle uyumlu olma zorunluluğu var.

Bu tabloyu bir kere yazdığınızda karar duygusal olmaktan çıkar. "Emek verdik" bir fayda kalemi değildir; geçmişe ait ve geri alınamaz bir harcamadır. Karar anında hesaba katılmaması gereken tek kalem odur.

Özelliğin hangi olgunlukta kesildiği her şeyi değiştirir

Kesme kararının maliyeti, özelliğin yaşına göre kabaca üçe ayrılıyor:

• Kâğıt aşaması: Fikir belgede, belki bir mockup var. Maliyet neredeyse sıfır. Buradaki tek risk, fikri savunan kişinin ikna edilmeden susturulması; o zaman fikir üç ay sonra farklı bir isimle geri gelir.
• Prototip aşaması: Oynanabilir ama çirkin bir sürüm var. Kesmenin maliyeti hâlâ düşük, kazancı en yüksek. Prototipin varlık sebebi zaten "kesilebilir olmak".
• Üretim aşaması: Sanat, ses, arayüz, kayıt formatı ve denge tabloları özelliğe bağlanmış. Burada kesmek bir çıkarma ameliyatı. Karar hâlâ doğru olabilir ama artık bedava değil.

Pratik sonuç şu: bir fikri en geç prototip aşamasında sınamak, kesme maliyetini onda birine indiriyor. "Önce düzgün yapalım, sonra bakarız" yaklaşımı, kesme kararını üretim aşamasına iteleyerek kararın kendisini pahalılaştırıyor.

Bir özelliğin gitmesi gerektiğini gösteren dört sinyal

Karar verirken baktığımız işaretler, sezgiden çok gözlemlenebilir şeyler:

1. Açıklama gerektiriyor. Özelliği anlatmak için iki cümleden fazlası gerekiyorsa, oyuncu onu öğrenmek için harcayacağı bütçeyi başka bir yerde harcamayı tercih eder. Kart oyunlarında bu duvara özellikle çabuk çarpılır; ekranda zaten kural, sembol ve sayı yoğunluğu vardır.
2. Var olan bir sistemin kararını tekrarlıyor. Oyuncuya sunduğunuz iki mekanik aynı soruyu soruyorsa ("şimdi mi harcayayım, sonra mı?"), biri gereksizdir. Kule savunmada bu, ekonomi ve yükseltme sistemlerinin birbirinin kopyası hâline gelmesiyle olur.
3. Test edilmesi oynanmasından uzun sürüyor. Bir özelliğin regresyon testi her sürümde on beş dakika alıyor ama oyuncu ona oturum başına on saniye dokunuyorsa, denklem kapanmıyor.
4. Dengeyi kilitliyor. Zorluk eğrisinde bir ayar yaptığınızda bu özellik yüzünden üç yerde daha düzeltme gerekiyorsa, özellik artık bir içerik değil, bir kısıt. Zorluk eğrisini ölçüm altyapısı olmadan nasıl okuduğumuzu telemetri olmadan zorluk eğrisi yazısında ayrıntılandırmıştık; kesme kararlarının çoğu tam olarak o gözlemlerden çıkıyor.

Dördünden ikisi aynı anda geçerliyse, özelliği savunmak zorlaşıyor.

Silmenin faturası: kodda kalan izler

Bir özelliği "sildik" demek, kodun temizlendiği anlamına gelmiyor. En sinsi kalem kayıt dosyası. Oyuncular o özelliğin bulunduğu sürümle oynadıysa, diskte artık o alanları içeren kayıtlar var ve yeni sürüm onları okuyabilmek zorunda. Yani özellik oyundan çıkar, ama sürüm göçü kodu yıllarca kalır:

[Serializable]
public class SaveData
{
    public int version;
    public int coins;
    public int highestWave;
    // v2'de eklenip v4'te kaldirilan alan.
    // Silinemiyor: eski kayitlar hala bu alani iceriyor.
    public int legacyRelicPoints;
}

public static class SaveMigrator
{
    public const int Current = 4;

    public static SaveData Migrate(SaveData data)
    {
        if (data.version < 3)
        {
            data.highestWave = Mathf.Max(data.highestWave, 0);
            data.version = 3;
        }

        if (data.version < 4)
        {
            // Kesilen ozelligin bakiyesini geri odemek zorundayiz.
            data.coins += data.legacyRelicPoints * 10;
            data.legacyRelicPoints = 0;
            data.version = 4;
        }

        return data;
    }
}

Bu on beş satır, kesme kararının görünmeyen maliyetinin somut hâli. Özellik menüden kalktı, oyuncu onu bir daha görmeyecek, ama kod tabanında bir alan ve bir dönüşüm bloğu kalıcı olarak duruyor. Buna benzer artıkların iki oyun arasında paylaşılan katmanda birikmesi ayrı bir sorun; ortak araçların nerede yardım edip nerede ayak bağı olduğunu tek kod tabanı yazısında anlatmıştık.

Kodun yanında üç kalem daha var: silinen özelliğe gönderme yapan öğretici adımları, mağaza sayfasındaki ekran görüntüleri ve lokalizasyon dosyalarındaki artık metinler. Kesme kararı verirken bu dört kalemi bir kontrol listesi olarak yazmak, kararı iki gün geciktiriyor ama iki hafta sonra ortaya çıkacak tuhaf hataları önlüyor.

Kesince ne kazanılıyor, ne kaybediliyor?

Kazanç tarafı çoğu zaman tahmin edilenden büyük: arayüzde boşalan yer, kısalan öğretici, azalan denge değişkeni ve her sürümde kazanılan test süresi. Bir özelliği çıkardığınızda kalan özelliklerin her biri daha görünür oluyor; oyuncunun dikkati sabit bir bütçe ve o bütçeden bir kalem eksiliyor.

Kayıp tarafı ise daha az konuşuluyor ve gerçek. Üç şey kaybediliyor:

• Çeşitlilik. Kesilen özellik genelde "uzun vadeli oyuncu" için yapılmış olur. Onu çıkarınca oyun daha tutarlı ama daha ince olur.
• Ekipteki enerji. Bir şeyi üç hafta yapıp silmek moral olarak bedava değil. Bunun panzehiri kararı gerekçesiyle birlikte yazmak; "beğenilmedi" ile "test yüzeyi faydayı aşıyordu" aynı cümle değil.
• Öğrenilmiş bilgi. Özellik gidince onunla birlikte keşfedilen ayrıntılar da unutulur. Bu yüzden kesilen dalın adını ve kısa bir notunu saklamak, aynı fikri altı ay sonra sıfırdan denemekten ucuz.

"Ne kadar emek verdikten sonra vazgeçmek doğru?"

Dürüst cevap: sorunun kendisi yanlış kurulmuş. Doğru soru "ne kadar emek verdim" değil, "bundan sonra ne kadar emek gerekecek ve karşılığında ne alacağım". Batmış maliyet kararın girdisi değil.

Ama insanız ve bu soyut cevap masada işe yaramıyor. Pratikte işe yarayan iki kural şu:

1. Zaman kutusu koyun. Bir özelliğe başlarken "bu prototip üç gün sürecek, üçüncü günün sonunda çalışmıyorsa kesiyoruz" deyin. Kararı önceden vermek, karar anında duygusal olmayı engelliyor.
2. Kesme kriterini yazın. "Bu özellik, oyuncunun tur başına verdiği anlamlı karar sayısını artırmalı" gibi tek cümlelik bir başarı ölçütü. Ölçüt yazılamıyorsa özelliğin neden var olduğu zaten belirsizdir.

Bir de gecikmenin işareti var: bir özellik hakkında üçüncü kez "acaba kessek mi" tartışması yapılıyorsa, karar çoktan verilmiş ama söylenmemiştir. O tartışmanın kendisi bir sinyal.

Kararı yazıya dökmek

Her kesme kararı için tuttuğumuz not kısa: özelliğin adı, neden yapıldı, hangi ölçütle sınandı, ölçüt neden karşılanmadı, hangi kod ve içerik kalemleri temizlendi, hangileri kalıcı olarak kaldı. Beş satır. Bu notun iki faydası var: aynı fikir tekrar önerildiğinde tartışma sıfırdan başlamıyor, ve kesilen şeyin gerçekten kötü mü yoksa yanlış zamanda mı denendiği ayırt edilebiliyor.

Kapsam yönetimi çoğunlukla "az iş yapmak" diye anlaşılıyor. Bizim gözlemimiz tersi: kapsam yönetimi, yaptığınız işin hangisinin oyunda kalacağına erken karar verme disiplini. Kesmenin maliyeti sıfır değil, ama geç kesmenin maliyeti her hafta artıyor.