Oyun Tasarım Dokümanı Şablonu: Tek Sayfadan Başlayıp Büyüt
Summary
Etkili bir oyun tasarım dokümanı şablonu beş bloktan oluşur: fikir özeti, tasarım ilkeleri, temel döngü, sistem listesi ve açık sorular. Tek sayfadan başla ve yalnızca bir oyun testi bir mekaniğin gerçek olduğunu kanıtladığında büyüt. Lore'u oyunu değiştirdiği yerde tut, geri kalanını Codex'e taşı. Her oyun testinden sonra belgeyi güncelle. Açık sorular ve değişiklik günlüğü, çoğu şablondan daha fazla iş görür.
Bir oyun tasarım dokümanı şablonu önce tek sayfaya sığmalı ve ancak oyun bunu hak ettiğinde büyümeli. Beş bloktan başla: fikir özeti, tasarım ilkeleri, temel döngü, sistem listesi ve açık sorular. Hikâye, bölüm notları ve ayrıntılı veri listeleri ancak bir oyun testi mekaniğin gerçek olduğunu kanıtladığında eklenir. Aşağıda masaüstü RPG ve bağımsız video oyun projelerinde kullandığımız şablonu ve her bölümün nerede çürümeye başladığını bulacaksın.
Çoğu oyun tasarım dokümanı neden üçüncü haftada ölür?
Sorun çoğunlukla hırstır. Biri boş bir dosya açar, bir forumdan 20 bölümlük bir taslağı yapıştırır ve test edilmemiş mekanikler için haftalarca kutu doldurur. Üçüncü haftaya gelindiğinde oyun ilerlemiştir ama belge ilerlememiştir. Kimse açmaz, kimse de bunu kabul etmez.
Game Dev Beginner'ın GDD rehberi sorunu açıkça adlandırır: çok büyük ve aşırı ayrıntılı belgeler ağır bir ön emek ister, neredeyse her zaman eskimiş olur ve tasarım hâlâ değişirken insanı kısıtlar. Çözüm aşamalandırmaktır. Önce tek sayfalık bir belge yaz, oyun şekil aldığında on sayfalık sürüme geç ve tam sürümü yalnızca içerik üretilirken hazırla.
Bu aşamalandırma video oyun ekiplerinden çok masaüstü RPG tasarımcıları için daha önemlidir. Bir TTRPG tasarımcısı çoğu zaman aynı anda yazar, sistem sorumlusu ve oyun testçisidir. Bekleyen bir mühendis yoktur. Belgenin tek bir işi vardır: dördüncü seansla kırkıncı seans arasında kendinle çelişmeni engellemek.
Yalnız çalışıyorsan 40 sayfalık şablondan uzak dur. Onu sürdüremeyeceksin. Standart tanım bile GDD'yi yaşayan bir belge olarak tanımlar; yani kimse onun ilk gün bitmiş olmasını beklemez.
İnsanların gerçekten açtığı bir şablonda neler olmalı?
İlk ayın büyük kısmını beş blok kapsar. Her birini, tüm sayfayı iki dakikada okuyabilecek kadar kısa tut.
Fikir özeti. İki cümle. Oyunu kimin oynayacağı, oyuncunun ne yapacağı ve oyunu zaten sahip olduğu en yakın oyundan neyin ayırdığı.
Tasarım ilkeleri. Sonraki her kararın sınandığı üç ya da dört ifade. "Her dövüş kalıcı bir bedel ödetir" bir ilkedir. "Eğlenceli ve sürükleyici" bir ilke değildir.
Temel döngü. Oyuncunun tekrar tekrar yaptığı şey. Bir zindan tarama oyununda bu keşfet, seç, riske gir, harca olabilir. Siyasi bir kampanyada ise entrika, kaldıraç, sonuç ve yan etki olabilir.
Sistem listesi. Yalnızca isimler, her biri için tek satır. Henüz sayı yazma.
Açık sorular. Sayfanın en faydalı bölümü ve şablonların çoğunun atladığı bölüm. Neyi bilmediğini yaz ve tarihini at.
Belgenin altına bir değişiklik günlüğü de ekle, haftada bir satır bile olsa. Bir oyun testi bir fikri öldürdüğünde, ölümü ve nedenini kaydet. Yoksa gelecekteki sen aynı fikri yeniden deneyecektir. Günlük kısa olmalı. Her girdide üç bilgi yeter: tarih, ne değiştiği ve neden değiştiği. Kendine şunu sor: Bu değişikliği birkaç ay sonra anlamak için ne kadar bağlama ihtiyacım var? Cevap çoğu zaman tek cümledir. Gerekçen uzayıp bir paragrafa dönüşmeye başladıysa, muhtemelen o gerekçe kendi bölümünü hak eden ayrı bir tasarım kararıdır.
Tasarım ilkeleri itiraz edebilecek şekilde nasıl yazılır?
Bir ilke, bir şeyi veto ederek yerini kazanır. İlkenin reddedeceği bir özelliği adlandıramıyorsan, o ilke bir süstür.
Her ilkeyi bir kesme listesiyle sına. En çok bağlandığın üç özelliği al ve her birinin hangi ilkeye hizmet ettiğini sor. Hiçbir ilkeye hizmet etmeyen özellik "belki sonra" rafına gider ve bu rafın uzun olmasına izin verilir. Sürecin en zor saati budur ve herhangi bir şablon bölümünden daha fazla değer taşır.
Bir kampanya ayarından somut bir örnek: Merkezinde bir salgın olan bu ayarda birinci ilke, kaynakların görünür olmasıdır. Her şifalı kaynak masada takip edilir. İkinci ilke, fraksiyonların farklı tedaviler istemesidir; hiçbir tek tedavi her şeyi çözmez. Üçüncü ilke, haritanın küçülmesidir; hikâye ilerledikçe seyahat pahalılaşır. Şimdi bir dirilme büyüsü önerisi geliyor. Birinci ilke bunu reddeder. Karar kırk dakikalık bir tartışma yerine on saniyede verilir.
Bilmeye değer bir şey daha: İlkeler pazarlama sloganı değildir. İçe dönüktürler ve serttirler, bu yüzden biraz hoş olmayan gelebilirler. Bu sorun değil. Bir ilkeyi yazmanın en kolay yolu, ekibinden iki kişinin itiraz edeceği bir cümle seçmektir. Herkesin kabul ettiği bir ilke henüz iş görmüyordur. Asıl değerini ekipte bir gerilim çıktığında gösterir: iki kişi farklı yönlere çekildiğinde ilke hangi tarafın haklı olduğunu söyler.
Lore bir GDD'de nereye aittir ve nerede işin önüne geçer?
Lore, en hızlı büyüyen ve en az okunan bölümdür. Çoğu belge onu sonda bir "Hikâye" başlığına gömer ya da tüm dosyayı yutmasına izin verir. İkisi de işe yaramaz.
Malzemeyi ne yaptığına göre ayır. Oyunu değiştiren lore, örneğin bir görevin kilidini açan bir fraksiyon kini ya da bir sınıfı şekillendiren bir lanet, etkilediği sistemlerin içinde yaşar. Yalnızca atmosfer katan lore ise hiçbir tasarım kararı için açılması gerekmeyen ayrı bir Codex sayfasında durur. Test basit: paragrafı silmek bir mekaniği, bir zarı ya da bir oyuncu seçimini değiştirmiyorsa, o paragraf Codex'e aittir.
Bu ayrım kanonu da korur. Bir gerçek iki yerde yaşarsa, iki yer zamanla birbirinden uzaklaşır. Her gerçek için tek bir ev seç ve diğer her yerden oraya bağlantı ver. Kanon bir sözdür ve her tutarsızlık o sözü bozar.
Lore'u Codex'e koyarken basit bir etiket sistemi işini kolaylaştırır. Her girdiye "oyunu etkiler" ya da "atmosfer" etiketi ver. Böylece bir sistemi değiştirdiğinde hangi lore parçalarının da kontrol edilmesi gerektiğini tek bakışta görürsün. Etiketler sıkıcı görünür, ama bir kampanyanın ortasında yanlış bir bağlantıyı yakalamanın en ucuz yoludur.
Anlatı ağırlıklı oyunlar tasarlayanlar genellikle kısa bir zaman çizelgesi sayfası ve bir "kim neyi biliyor" listesi ekler. İkisi de ucuzdur. Geç gelen bir sürpriz doğru şekilde oturması gerektiğinde, bu iki sayfa oturumların baştan yazılmasını önler.
Şablonunu hangi araç tutmalı: Notion, Obsidian ya da düz bir belge?
Araç, belgenin zaten çalıştığın yerde durup durmamasından daha az önemlidir. Hiç açmadığın bir sekmede duran belge ölü bir belgedir. Bir aracı değiştirmenin maliyeti genellikle kurulumda değil, geçişte ortaya çıkar. Sayfaların bağlantıları bozulur, şablon ayarları kaybolur ve ekip hangi sürümün geçerli olduğunu tartışmaya başlar. Bu yüzden ilk günden tek bir ev seç ve ona sadık kal. Araç seçimi bir kez yapılır; belgenin kendisi ise her oyun testinden sonra güncellenir.
Küçük ekipler için varsayılan seçim çoğunlukla Notion'dır. Sayfalar birbirine bağlanır, veritabanları fraksiyonları ve öğeleri tutar ve işbirlikçilerin kurulum yapmasına gerek kalmaz. Kontroller, oyun döngüsü, bölüm tasarımı ve kurallar için bölümleri olan hazır bir Notion GDD şablonu de var. Dezavantajı, bağımlılık riski ve gerekmeyen şeyler için veritabanı kurma cazibesidir.
Obsidian, belgesini diskte düz Markdown dosyaları olarak tutmak isteyen yalnız tasarımcıya uygundur. Geri bağlantılar burada gerçek iş görür: bir fraksiyonu göründüğü her sahneye bağlarsan bedavaya bir tutarlılık kontrolü elde edersin. Proje yıllarca sürerse ve sağlayıcı ortadan kalkarsa da dayanır.
GitBook, belgenin herkese açık ya da yarı açık olması gerektiğinde işe yarar; örneğin bir oyun testi grubu ya da crowdfunding destekçi sayfası için. Bir oyun jam'i için düz bir Google Doc yeterlidir. Bir yayıncı istemedikçe karmaşık izin modeli olan araçlardan uzak dur.
Hangisini seçersen seç tek bir kural koy: her oyun testinin sonunda, kimse eve gitmeden önce belge güncellenir. On dakika, istisnasız.
Prototip oyun testlerini geçtikten sonra neyi eklersin?
Üç ya da dört gerçek oyuncuyla yapılan seanslardan sonra tek sayfalık belge bir sonraki katmanı hak eder. Bölümleri bu sırayla ekle ve yalnızca acı kendini gösterdiğinde.
Sistem ayrıntısı. Sayılar, uç durumlar ve formüller. Bir sistemi kilitlerken yaz, önceden değil. Masaüstü RPG için aksiyon ekonomisi, hasar aralıkları ve kaynak maliyetleri buraya girer, kural metni de olduğu gibi. Video oyun için mühendislerin okuyacağı veri listelerini ekle.
İçerik listeleri. Öğeler, düşmanlar, fraksiyonlar, lokasyonlar. Her girdi için tek satır kullan ve yanına hangi ilkeye hizmet ettiğini yazan bir not ekle. Hiçbir ilkeye hizmet etmeyen satırlar kesilmek için adaydır.
Arayüz ve akış. Masaüstü RPG için karakter kâğıdı düzeni, dijital oyun için ekran akışı. Metinle tarif etmeden önce elle çiz.
Üretim notları. Kilometre taşları, kapsam, riskler, ilk sürümde neyin olduğu ve neyin olmadığı. DriveThruRPG ya da Itch.io'da satmayı planlıyorsan, sayfa metnin ve fiyat varsayımların da burada başlar.
Tanıtım ya da pazarlama bölümü ayrı bir okuyucu için ayrı bir belgedir. Yayıncılar ve destekçiler pazar bağlamı ile benzersiz satış noktaları ister. Oyun testçilerin ise kurallara ihtiyacı vardır. İkisini karıştırmak ikisine de hizmet etmeyen bir dosya üretir.
Üç ya da dört seansın ardından kendine üç soru sor ve cevaplarını açık sorular bölümüne yaz: Hangi kural masada hiç kullanılmadı? Hangi karar oyuncuları en çok düşündürdü? Hangi soruya kimse cevap veremedi? Bu üç cevap, bir sonraki sürümün kapsamını neredeyse kendiliğinden belirler.
Yapay zekâ bir oyun tasarım dokümanı yazmanda yardımcı olabilir mi, nerede yetersiz kalır?
Sıkıcı kısımların taslağında yardımcı olur, önemli kısımlarda ise yetersiz kalır. Bir modelden sistem listeni uç durumların yer aldığı bir listeye genişletmesini istersen bir dakikada makul bir ilk geçiş alırsın. İlkelerini seçmesini istersen, her oyunun kulağa benzeyen ilkeler alırsın. Hızlı üretir. Kararlar yine de bir insanın gözünden geçmelidir.
Pratik kullanımı tutarlılık kontrolüdür. Codex'i ve sistem listesini ona ver, sonra iki sayfanın nerede çeliştiğini sor. Novelcrafter gibi uzun anlatı kitabı etrafında kurulmuş araçlar bu tür çapraz kontrol için tasarlanmıştır. Çıktıyı bir karar olarak değil, bir şüpheliler listesi olarak gör ve her işaretli noktayı kendi sayfalarında kontrol et.
Bir model tutarlılık kontrolünde işe yarayabilir, ama dünyanın kuralları hakkında kendinden emin konuşmaya da meyillidir. Bu yüzden her önerisini kendi kanonuna karşı oku. Modelin söylediği bir şey yeni bir gerçek gibi duruyorsa, önce onu Codex'te ara. Bulamazsan, bu bir öneridir, kanon değildir.
Bir kural kesindir: açık sorular bölümünü model asla yazmaz. O sayfa, neyi bilmediğinin dürüst listesidir ve bunu devretmek tüm noktayı yok eder.
Neyi atlamalı, neyi tutmalısın?
Tam uzunluktaki şablonu, bir mekanik en az üç gerçek seansı atlatana kadar atla. Beş gerçek insanı sayamıyorsan "hedef kitle" denemesini atla. Döngüsünü bulmamış bir oyun için ayrıntılı gelir modeli bölümlerini atla. Bir çalışma arkadaşına sesli okumayı hayal edemediğin her bölümü atla.
İlkeleri, açık soruları ve değişiklik günlüğünü tut. Bu üçü işin büyük kısmını yapar. Yalnızca bunlardan oluşan ve haftada bir güncellenen bir belge, Mart'tan beri kimsenin açmadığı cilalı 30 sayfalık bir dosyadan daha iyidir.
Atlamak kaybetmek anlamına gelmez. Bir bölümü atladığında onu "daha sonra" başlığıyla bir kenara koyabilirsin. Önemli olan bunu bilinçli yapmaktır. Sessizce atlanan bölümler, aylar sonra kimse hatırlamadan belgenin tutarlılığını bozar.
Oyun tasarım dokümanı şablonu, ne karar verdiğin ve neden verdiğin konusunda gelecekteki kendine verdiğin bir sözdür. Sözünü tutabileceğin kadar kısa tut.