Game Design Document yani GDD aslında çok basit bir şeye yarıyor: ekip aynı oyunu mu yapıyor, onu kontrol etmeye. 70 sayfalık PDF olup kimsenin açmadığı anda belge var ama işlev yok.
Biz küçük ekip için yaşayan, kısa ama net belgeyi daha mantıklı buluyoruz. Kararı anlatacak kadar detay. Her toplantının tutanağı olacak kadar değil.
Bizdeki Ücretsiz araç: QUBU GDD Oluşturucu’yu aç, yapıyı kendi projen için doldur.
GDD içinde ne olmalı?
- Oyuncu vaadi.
- Core loop.
- Ana kararlar ve risk/ödül yapısı.
- Progression.
- Ekonomi: source, sink ve limitler.
- İçerik yapısı.
- Kontroller/UI durumları.
- Save, online ve teknik sınırlar.
- Analytics soruları.
- QA riskleri.
Önce oyuncu vaadini yaz
Feature saymadan tek paragraf yaz. Oyuncu kim, ne yapıyor, hangi baskı altında karar veriyor, ne hissedecek? Bu net değilse geri kalan belge genelde katalog oluyor.
Core loop’u fiillerle anlat
Keşfet → karar ver → harca → sonucu gör → toparlan gibi. Fiiller sistemi temiz gösteriyor. Tutorial, analytics ve UI tarafı da buradan daha kolay çıkıyor.
Sadece kuralı değil, nedenini de yaz
“Cooldown 12 saat” altı ay sonra kimseye bir şey anlatmayabilir. “Bölge sahipliğinin bir gece içinde birkaç kez el değiştirmesini önlemek için 12 saat” çok daha faydalı. Sayı değişir, gerekçe kalır.
Teknik sınırı sona bırakma
Save migration, server authority, offline davranış, düşük cihaz, controller desteği… Bunlar “kodcular sonra bakar” konusu değil. Tasarım kararını değiştiriyorsa GDD’de yeri var.
Kopyalanabilir GDD yapısı
1. Oyun özetin2. Oyuncu vaadin3. Hedef kitle ve platformn4. Core loopn5. Kontroller / kameran6. Progressionn7. Ekonomin8. Combat / etkileşim kuralların9. İçerik yapısın10. UI durumların11. Save / online mimarin12. Analytics soruların13. QA risklerin14. Başarı metriklerin15. Açık sorular
GDD ne kadar sık güncellenmeli?
Oyunun davranışıyla belge çelişmeye başladığında. Her cümleyi parlatmak için değil. Karar değiştiyse güncelle, varsayım bozulduysa güncelle, sistem arayüzü değiştiyse güncelle.
Sonuç
İyi GDD uzun belge değil, kullanılan belge. Bir tasarımcı, geliştirici veya QA aynı soruya baktığında aynı kurala ulaşabiliyorsa işini yapıyor demektir.
Bunu gerçek projede nasıl uygularız?
Ben bu konuyu doğrudan bir sonraki build’e bağlamayı tercih ederim. game design document şablonu için ayrı bir doküman yazıp unutmak yerine, tek bir feature veya oyuncu akışı seç. Önce mevcut davranışı kaydet. Sonra değişiklik yap. Sonra aynı ölçümü tekrar al. Bu kadar. Küçük deney daha az havalı görünüyor ama hangi kararın işe yaradığını gerçekten anlatıyor.
Örneğin önce bir “başlangıç durumu” kaydı açabiliriz: hangi build, hangi oyuncu grubu, hangi sistem ayarı, beklenen sonuç ne? Ardından kararın sahibini ve geri dönüş koşulunu yaz. Bir değişiklik kötü giderse “ne zaman geri alacağız?” sorusunun cevabı olay anında tartışılmamalı. Önceden belli olsun.
Mini karar günlüğü
| Alan | Ne yazacağız? |
|---|---|
| Problem | Oyuncu veya üretim tarafında ne bozuk? |
| Hipotez | Hangi değişiklik neden düzeltecek? |
| Risk | En pahalı yan etki ne? |
| Sinyal | İşe yaradığını hangi veri gösterecek? |
| Rollback | Hangi durumda eski davranışa döneceğiz? |
Yayınladıktan veya uyguladıktan sonra neye bakmalı?
İlk gün çok gürültülü olabilir. Birkaç yüksek sesli yorumla komple yön değiştirmek yerine davranış sinyalini, hata oranını ve qualitative feedback’i birlikte oku. Aynı sorun üç farklı kanalda görünüyorsa daha güçlü sinyal. Sadece tek yorum varsa backlog’a yaz, hemen mimariyi sökme.
Bir de “başarı”yı sadece pozitif metrik diye düşünmemek lazım. Bazen amaç hata oranını düşürmek, support yükünü azaltmak veya ekipte aynı işin iki kere yapılmasını önlemek. Game Design Document Nedir? Ücretsiz GDD Şablonu ve Doldurulmuş Örnek için doğru sonuç, konuya göre değişir. O yüzden başta hangi davranışı koruduğumuzu yazmıştık zaten.
Benim özellikle kaçınacağım şeyler
- Tek bir benchmark’ı evrensel doğru kabul etmek.
- Ölçmeden önce büyük refactor yapmak.
- Rollback yolu olmadan canlı değişiklik açmak.
- “Best practice böyle” deyip ürünün gerçek ihtiyacını unutmak.
- Başarısız denemeyi dokümantasyondan silmek. En faydalı not bazen o.
Kısacası, Türkçe template intent + gerçek QUBU bölüm örnekleri. Fakat bunu gerçekten değerli yapan şey örnek, ölçüm ve karar bağlamı. Yazıyı yayınladıktan sonra kendi proje ekran görüntümüzü veya küçük bir before/after tablosunu eklemek de bu yüzden iyi fikir.
Uygulama öncesi son kontrol
- Kapsam: Bu değişiklik tam olarak hangi oyuncu akışını veya üretim problemini etkiliyor?
- Veri: Değişiklikten önce elimizde karşılaştırabileceğimiz bir baseline var mı?
- Uyumluluk: Eski save, eski client, farklı platform veya eski config bu karardan etkileniyor mu?
- Sahip: Son karar ve rollback kimin sorumluluğunda?
- İletişim: Oyuncuya veya support ekibine açıklanması gereken bir davranış değişikliği var mı?
game design document şablonu hakkında sık yapılan yanlış çıkarım
Bir yöntemin başka stüdyoda çalışması onun bizim oyunda aynı sonucu vereceği anlamına gelmiyor. Tür, oyuncu davranışı, ekip büyüklüğü ve mevcut teknik borç sonucu değiştiriyor. Dışarıdaki örnek başlangıç noktası. Kararımızın kanıtı değil.
O yüzden son adım basit: küçük uygula, gözle, yaz. İyi gittiyse genişlet. Kötü gittiyse geri dön ve nedenini sakla. Bir sonraki feature’da o not muhtemelen işimize yarayacak.
Küçük bir örnekle karar akışı
Diyelim bir sistemde sorun görüyoruz. İlk gün direkt çözüm yazmak yerine önce bir cümle kuruyoruz: “Oyuncular X noktada beklediğimiz davranışı göstermiyor.” Sonra iki veya üç olası sebep çıkarıyoruz. Her sebep için gözlemleyebileceğimiz sinyal belirliyoruz. Böylece tartışma “bence” seviyesinden çıkıyor.
Değişiklik yaptıktan sonra sadece ortalamaya bakmıyoruz. Yeni oyuncu, eski oyuncu, farklı platform veya farklı build gibi segmentlerde ters sonuç var mı kontrol ediyoruz. Genel sayı düzelirken küçük ama önemli bir grup bozulabilir. Canlı üründe en can sıkıcı sürprizlerden biri bu.
Son olarak kararı kapatıyoruz: devam, geri al veya bir tur daha test et. Açık karar bırakmamak önemli. Yoksa üç hafta sonra kimse mevcut ayarın neden böyle olduğunu hatırlamıyor.