Çoğu oyun tam hazırlanmış bir tasarım dokümanıyla başlamaz. Bazen bir cümleyle, bazen bir atmosferle, bazen küçük bir mekanik fikriyle başlar. Bu ilk enerji değerlidir ama kontrolsüz büyürse proje daha ilk haftalarda taşınamayacak kadar ağırlaşır. Bu yüzden ilk iş özellik listesi yapmak değil, oyuncuya verilen vaadi netleştirmektir: Oyuncu ne yapacak, hangi baskıyı hissedecek ve yarın tekrar girmek için hangi sebebi olacak?
Oynanabilir ilk sürüm, bitmiş oyunun küçük kopyası değildir. Bir iki önemli soruya cevap veren bir test aracıdır. Oyuncu temel aksiyonu uzun açıklama olmadan anlayabiliyor mu? İlk dakika içinde anlamlı bir tercih yapıyor mu? Bu tercihin sonucu başarı veya hata olarak okunabiliyor mu? Bu sorular basit görünür ama aylarca menü, hikâye ve yan özellik üretip oyunun omurgasını test etmeme riskini azaltır.
Önce oyuncunun yaptığı fiili bul
Sağlıklı tasarım konuşmaları fiillerle başlar. Hareket et, nişan al, takas yap, inşa et, savun, ele geçir, kaç, birleştir, geliştir. Bir oyun fikri, tekrar tekrar yapılacak ana aksiyon belli olduğunda üretilebilir hale gelir. Strateji oyununda bu aksiyon sınırlı kaynağı nereye harcayacağına karar vermek olabilir. Bir bulmaca oyununda örüntüyü denemek, hata görünce yeni çözüm aramak olabilir.
Ana aksiyon netleşince bunu kanıtlayacak en küçük durumu yazmak gerekir. Bütün dünyayı tasarlamaya çalışmak erken aşamada genelde zarar verir. Bir oda, küçük bir harita, tek bir koridor, tek bir üretim zinciri veya geçici bir gri kutu seviye yeterlidir. Amaç güzel görünmek değildir. Amaç kararı görünür hale getirmektir. Karar sade versiyonda sıkıcıysa, görsel cilayla uzun süre taşınamaz.
Çirkin olabilir, ama dürüst olmalı
İlk build geçici görseller, basit arayüz ve kaba sayılarla hazırlanabilir. Fakat prototip yalan söylememelidir. Gerçek oyun zaman baskısına dayanıyorsa prototipte zaman baskısı olmalıdır. Kaynak kıtlığı önemliyse kıtlık hissedilmelidir. Bilgi okumak oyunun merkezindeyse bilgi gerçekten ekranda olmalıdır. Zor kısmı erteleyen prototip rahatlatıcı geri bildirim verir ama doğru yön göstermez.
Ekipler bazen zayıf kararları gelecek planlarının arkasına saklar. “Tam ilerleme sistemi gelince eğlenceli olacak” ya da “yirmi birim eklenince derinleşecek” denir. Bazen bu doğrudur, ama tehlikeli bir bahistir. Küçük prototipte final oyunun geriliminin izleri görünmelidir. Tam olmak zorunda değildir; test edilecek kadar dürüst olmalıdır.
Geri bildirimi al, ama oyunu teslim etme
Build oynanabilir olduğunda projeye duygusal olarak bağlı olmayan birkaç kişiye gösterin. Her kuralı anlatmakla başlamayın. Nerede duraksadıklarını izleyin. Talimat okumadan ne denediklerine bakın. Hedefin ne olduğunu sandıklarını, neyin haksız hissettirdiğini ve sırada ne yapmak istediklerini sorun. En değerli geri bildirim çoğu zaman doğrudan öneri değil, tasarımcının kaynağına inebileceği bir kafa karışıklığıdır.
Buna rağmen her yorumu emir gibi almak doğru değildir. Oyuncular sürtünmeyi ve hayal kırıklığını iyi tarif eder, fakat ürün yönünü korumak onların sorumluluğu değildir. Ekip belirtiyle reçeteyi ayırmalıdır. Üç kişi arayüz yavaş diyor olabilir; çözüm animasyon süresi, bilgi hiyerarşisi, sunucu yanıtı veya eksik kısayol olabilir. Şikâyet gerçektir, ama çözüm hâlâ ekibin işidir.
Karar günlüğü tut
Basit bir karar günlüğü, projenin aynı tartışmayı tekrar tekrar yaşamasını engeller. Bir mekanik neden seçildi, bir özellik neden çıkarıldı, test build neyi kanıtladı, hangi konu sonra tekrar açılacak? Bunları tarih atarak yazmak yeterlidir. Bürokrasiye dönüşmesi gerekmez. Altı hafta sonra bir sayı neden değişti ya da bir menü neden sadeleşti diye sorulduğunda cevap kaybolmamış olur.
Fikirden oynanabilir sürüme giden yol gösterişli değildir. Küçük ve disiplinli kesintilerden oluşur. Vaadi tanımla, ana aksiyonu bul, en küçük dürüst versiyonu yap, insanların oynayışını izle, gerçek karar üreten şeyi koru ve yalnızca final hayalini süsleyen fazlalığı çıkar. Bir fikir, ancak bu noktadan sonra geliştirilebilir bir ürüne dönüşür.