Oyun Tasarım Dokümanı Şablonu: Tek Sayfa Yeterli mi?

Bir oyun tasarım dokümanı şablonu tek sayfaya sığmalı ve oyun bunu hak ettikçe büyümeli. Yedi bloktan başla: fikir cümlesi, çekirdek döngü, oyuncu fiilleri, dünya, sistemler, kapsam ve açık sorular. Hepsini bir akşamda doldurabilirsin. Bu ay bir prototipte test edemeyeceğin her şeyi kes. Bu yazının geri kalanı şablonun kendisi ve çoğu rehberin atladığı kısımlar.

Çoğu oyun tasarım dokümanı neden ikinci haftada ölür?

40 sayfalık bir GDD'yi düşün. Güzel bir kapak, bir içindekiler tablosu, kimsenin istemediği bir lore bölümü. İkinci haftaya gelindiğinde prototip sapmıştır ve doküman bir fosile dönüşmüştür.

Gerçek başarısızlık bu. Eksik bölümler değil, artık doğru olmayan bir dosya. GDD bir çalışma aracıdır, bir kutsal kitaptan çok bir değişiklik günlüğüne benzer. Doküman ile build birbirini tutmuyorsa kaybeden doküman olur ve insanlar onu açmayı bırakır.

Yani soru "bir oyun tasarım dokümanı neleri içermeli?" değil. Soru şu: "Dürüst tutacağım en küçük doküman hangisi?"

Tek sayfalık oyun tasarım dokümanı şablonu

Bu taslağı kopyala. Her blok ilk geçişte iki ila beş satır olsun, daha fazlası olmasın.

1. Fikir cümlesi. Bir yabancının tekrarlayabileceği tek cümle. "Gelgitin her gece haritayı yeniden yazdığı, birlikte oynanan bir liman kasabası."

2. Çekirdek döngü. Oyuncunun bir dakikadan kısa sürede tekrar tekrar yaptığı şey. Bunu fiillerden oluşan bir daire olarak çiz.

3. Oyuncu fiilleri. Beş ila sekiz eylem. Özellik değil, fiil: tırman, takas et, saklan, çatallan, onar.

4. Dünya. Yer, ruh hali ve her zaman doğru kalan üç kural. Hava durumu da bir kuraldır.

5. Sistemler. Fiilleri ilginç kılan iki ya da üç mekanizma. Ekonomi, gizlilik, üretim, döngüyü taşıyan her ne ise.

6. Kapsam. Ne çıkacak, ne kesilecek, ne ek hedef olacak. Her birinin yanına bir tarih koy.

7. Açık sorular. Henüz bilmediğin şeylerin dürüst listesi. Sayfadaki en değerli blok bu.

Sayfada eksik olanlara dikkat et: gelir modeli, pazarlama planı, karakter geçmişi bölümü. Bunlar prototip döngünün çalıştığını kanıtladığında yazılacak ayrı dosyalarda durmalı. Yayımlanmış şablonların çoğu bunlarla başlar ve tam da bu yüzden o dokümanlar hiç bitmez.

Bir ekibin onay vermesi gereken daha uzun bir yapıya ihtiyacın varsa, GitBook'un oyun tasarım dokümanı yazma rehberi klasik bölüm listesini anlatıyor. Tek sayfalık bir versiyondan başlayıp prototipler ilerledikçe ayrıntı eklemek de doğru içgüdü.

Çekirdek döngü bölümü gerçekte ne söylemeli?

Sıfatları atla. Döngüyü zamanlayıcılı bir cümle olarak yaz.

40 saniye hurda ara -> hurdayı rıhtıma taşı -> bir yükseltme için takas et -> gelgit döner, harita değişir -> tekrarla

Şimdi bunu yüksek sesle oku. Bir adım ölü geliyorsa ilk prototip göreviniz bulundu demektir. Her adım iyi görünüyor ama oyuncunun neden geri döndüğünü söyleyemiyorsan döngüde bir neden eksiktir. Bunu paragrafların altına gömmek yerine açık soru olarak ekle.

Sevdiğim bir test var: döngü cümlesi tek satır metne sığmalı. Bir paragraf gerekiyorsa iki döngü vardır ve aslında iki oyun tasarlıyorsun demektir.

Bir de şunu dene: döngüyü bir arkadaşına sözlü anlat, kağıda bakmadan. Anlatırken unuttuğun adımı fark edersen, o adım muhtemelen tasarımda yeterince netleşmemiştir. "Sonra bir şey oluyor" diyorsan, o "bir şey" bir sonraki açık soruya dönüşmeli. Döngü kağıt olmadan anlatılabildiğinde sağlamdır. Anlatamadığın bir adım varsa, o adım sayfada da bulanık duruyordur.

Hangi bölümleri pişmanlık duymadan kesebilirsin?

Acımasız ol. Kesmeden önce kendine şunu sor: bu bölüm bu ay hangi kararı değiştirecek? Cevap yoksa bölüm ertelenmeli. Cevabı varsa ama kısa bir cümleye sığıyorsa, bölüm de kısa tutulmalı. Bu soru sadece bölümler için değil, fiiller için de işe yarar.

Tek başına ya da iki kişilik bir projedeysen bunların çoğunu ilk günden atabilirsin:

• Tam karakter biyografileri. Bir isim, bir istek, bir kusur tut. Karakter bir yapıda göründüğünde daha fazlasını yaz.

• Ayrıntılı bölüm tanımları. Odaları değil, bölüm kurallarını anlat.

• Platform ve gelir modeli bölümleri. Döngü çalışana kadar bekletin.

• Sanat rehberi. Üç referans görseli ve bir renk paleti. Hepsi bu.

72 saatlik bir jam oyunu yayımlıyorsan fikir cümlesi, döngü ve fiiller tüm dokümanındır. Bir yayıncın, konsol sertifikasyon yolun ya da gece yarısı sana soru soramayan yüklenicilerin varsa tam listeyi tutmak değer.

Unity oyun tasarım dokümanı şablonu PDF'i, mekaniklerin ve nesne davranışlarının bir ekip işin içine girdiğinde nasıl yazıya döküldüğü konusunda iyi bir referans. Bir kontrol listesi gibi değil, bir katalog gibi oku.

Dokümanı nerede tutmalısın?

Her gün düzenleyeceğin yerde. Bu açık gibi görünüyor ama kaç GDD'nin kimsenin fark edemediği bir PDF'te yaşadığını görünce şaşırıyorsun.

Başlıklar, görevler için bir veritabanı ve sürüm geçmişi sunan bir araç seç. Veritabanı destekli bir not uygulaması iyi çalışır, çünkü açık soruların ve kapsam listen çürüyen madde işaretleri olmak yerine takip edilen kayıtlara dönüşebilir.

Depodaki düz Markdown dosyası diğer güzel cevap. Kodun yanında durur, temiz biçimde farkları gösterir ve bir çekme isteğinde güncellemeyi kimse unutmaz. Bedeli, teknik olmayan ekip arkadaşlarının ona dokunmamasıdır.

Pratikte en iyi düzen, tek sayfalık dokümanı sabit bir adrese koymak ve her yeni oyuncu fiili eklendiğinde aynı yerden güncellemektir. Herkesin aradığı şey tek bir yer olmalı. Klasörler, dosya adları ve sürüm numaraları değil, tek bir ana sayfa. Bunu ilk hafta kurmazsan, üç ay sonra iki farklı GDD olduğunu fark edersin ve hangisinin doğru olduğunu kimse hatırlamaz.

Hangisini seçersen seç, tek sayfayı en üste koy ve daha derin dosyalara bağlantı ver. Sayfa haritadır. Dosyalar arazidir.

Motor yazdıklarını değiştirir mi?

Biraz, evet. Motor hangi fiillerin ucuz, hangilerinin pahalı olduğuna karar verir. Bu yüzden sistemler ve kapsam bölümlerin bunu açıkça söylemeli.

Büyük bir varlık hattı olan tam 3B bir motor kullanıyorsan kapsam her varlık kategorisi için bir satır gerektirir, çünkü takvimlerin öldüğü yer içeriktir.

Lisans hesaplarını takip etmek zorunda kalmayacağın açık kaynaklı bir motor istiyorsan kapsam bölümün daha sade olur: lisans satırı yok, ama hangi özellikleri kendin yazacağına dair gerçek bir not var.

Oyun sıkı mekaniklerle 2B ise döngü bölümü neredeyse her şeyi taşır. Küçük ve okunabilir dokümanlar küçük ve okunabilir oyunlara yakışır.

Buradaki amaç bir kazananı seçmek değil. "Motor ve araçlar" satırı atılacak bir satır değil. Motorun neyi kolaylaştırdığını, neyi zorlaştırdığını ve neyi asla inşa etmeyeceğini listelemeli.

Kendini üreten bir dünya için GDD nasıl yazılır?

Neredeyse her şablonun boşluğu burası. Her ağacı elle yerleştirdiğini varsayıyorlar.

Dünya bir prompt'tan üretildiğinde tasarım dokümanı şeklini değiştirir. Artık odaları belirtmiyorsun. Kısıtları belirtiyorsun: motorun üretebileceği her dünyada neyin doğru olması gerektiğini ve neyin değişebileceğini.

Tek sayfalık taslağa iki blok ekle:

• Dünya kısıtları. Asla bozulamayacak kurallar. "Her yerleşimin iki dakika yürüme mesafesinde suyu vardır." "Çıkmaz görev noktası yoktur."

• Prompt tohumları. Kullandığın tam promptlar, dokümanın parçası olarak saklanmış.

Bir tohumun pratikte nasıl göründüğü:

gelgit ortasında sisli bir liman kasabası, tek deniz feneri, dar merdivenler, çatılar arasında ip köprüler, henüz kimse görünmüyor

Bunu bir kod parçasını commit etmeye benzet. Ne zaman, neyden, hangi sonuca göre değiştiğini bilmediğin bir dünya, bir hafta sonra kendi kendine bozulmuş gibi görünür. Prompt'u kaydet, geri dönen sonucu kaydet ve neyi çatallayacağını not et. Prompt aynı anda hem spesifikasyonun hem de değişiklik günlüğünün olur. Çatalla, tek bir şeyi değiştir, ne olduğuna bak, sonra farkı dokümana yaz. Bu alışkanlık üretilmiş bir dünyayı üzerinde akıl yürütebileceğin bir şeye çevirir ve ekip arkadaşlarına, bir havaya değil, eleştirebilecekleri somut bir şey verir.

Bir uyarı: üretim kalitesi araçlara göre çok değişir ve bazı özellikler sektörün genelinde hâlâ beta aşamasında. Her tohumun yanına sürümü ve tarihi yaz; böylece bir sonucun tekrarlanabilir mi yoksa şanslı bir atış mı olduğunu bilirsin.

Yazmaya devam etmeden döngüyü test etmenin hızlı bir yolu

Yeni bir fikirde yürüteceğim akşam iş akışı şöyle:

1. Tek sayfayı 30 dakikada yaz. Üzerinde değişiklik yapma.

2. Fikir cümlesini ve üç dünya kuralını bir prompt'a çevir, alanın ilk geçişini üret.

3. Çekirdek döngüyü o alanda, elle ya da kaba bir prototipte yürüt.

4. Ölü hissettirdiği her adımı işaretle. Bunlar açık sorulara gider.

5. Bir fiili kes. Her zaman bir tane kes.

Bu akşam iş akışının en zor kısmı dördüncü adım. Ölü hissettiren bir adımı kabul etmek, kendi fikrine karşı dürüst olmak demek. Ama o notları dokümanda tutmak, aynı hatayı üç ay sonra yeniden yapmanı engeller.

Kesme, insanların atladığı kısım. Sadece büyüyen bir tasarım dokümanı bir dilek listesidir. Bir fiili çıkarmak kalanların daha fazla yük taşımasını zorlar ve gerçekte hangi sistemin iş gördüğünü genellikle ortaya çıkarır.

Doküman ikinci haftadan sonra nasıl canlı kalır?

Üç alışkanlık, hiçbiri kahramanca değil. Hepsi sıkıcı görünebilir, ama birlikte çalıştıklarında dokümanın kendi kendine yaşlanmasını engellerler. Her güncelleme küçük bir adımdır ve bir ay sonra geriye bakınca bir değişiklik günlüğü görürsün.

Her açık soruya tarih at. Üç haftadan eski ve hâlâ açıksa ya cevapla ya da ondan kaçındığını kabul et.

Dokümanı build ile aynı oturumda güncelle. Sonra değil. "Sonra" fosilin oluştuğu andır. Oturumun sonunda iki satırlık bir düzenleme bir dakika tutar.

En altta bir "öldürülen fikirler" listesi tut. Her ay aynı mekaniği yeniden tartışmanı engeller ve kaç şeyi "hayır" diyerek elediğini görmek garip bir şekilde motive edicidir.

Projeye yeni biri katıldığında önce ona tek sayfalık versiyonu ver ve nerede kafasının karıştığını izle. Her kafa karıştıran soru, dokümanda eksik bir satırdır.

Peki biz ne kullanırdık?

Yalnızsan ya da iki kişiysen, yedi bloklu tek sayfa ve bir prompt tohumu listesi ilk ay için yeterli. Bir ekibin varsa tek sayfayı ön kapı olarak tut ve sistemler ile içerik için ayrı dosyaları prototip gerektirdikçe ekle. Bir yayıncın varsa ona uzun versiyonu ver, ama güvendiğin versiyon olarak tek sayfayı koru.

Son bir kontrol daha öneriyorum. Tek sayfayı bitirdikten sonra her bölümün yanına "bunu kim okuyacak?" diye yaz. Cevabı bilmediğin bölüm, büyük ihtimalle kimse için yazılmamış bir bölümdür. Oyunu sen yapıyor olsan bile, bir ay sonra o sayfayı açan kişi biraz yabancı gibi düşünür. Sayfa o kişiye hitap etmeli.

Bu gece boş bir sayfa aç ve fikir cümlesini yaz. Tek cümle. Sonra zamanlayıcılı döngü. Bunu yarım saatte bitiremiyorsan fikir hâlâ bir hayal ve bir ay harcamadan önce bunu bilmek işine yarar.