Birisi bana tasarım dökümanını resmin formatını ne olduğunu söylemesin

BİR İNSANIN DÜŞÜNCESİ

Önceki sayfalarda tasarım dökümanın da kullanılacak sevdiğin formatı tanıttım. Bu bunların endüstrinin standart formatı olduğu anlamına gelmiyor. Büyük tasarım dökümanları benim kinden çok farklı format kullanmış olabilir. Bu farklılık hem içerik de yapıda gerçekleşmiş olabilir. Fakat eğer benim yapılandırdım şekilde tasarım dökümanını hazırlarsınız size gülmezler ve aptal muamelesi yapmazlar. Burada daha önce belirttiğim gibi önemli olan yapmak istediklerinizi okuyucuya tam olarak aktarmanızdır. Tasarım dökümanı hazırlarken önemli olan sizin en açık ve sizin bu dökümanı onların en çok hoşlanacağı tarzda sunmanızdır.
Tasarım belgesinin formatının projeden projeye değişmesinin sebebi oyunların standart tasarım formunda olmamasıdır. Oyuncular filmler senfoniler farklıdır. Örneğin bir yemek kitabı yazarıyla, roman yazarın sitili çok farklı olacaktır. Dolayısıyla bir nişancı oyunu olan Halo’nun yapısıyla strateji oyunu olan “rise of nations” oyunun yapısı dolayısıyla dökümanı farklı olacaktır. Oyunları kullanıcıya yaşadıkları deneyimler gerçekleştirdi işler keskin biçimde birbirinden çok farklı olduğu için tasarım dökümanları da farklı olacaktır. Oyunla birlikte birçok belirgin türler veya oyun tipleri vardır. Bir tür için verilen bir tasarım formatı örneğin birinci kişili nişancı standartlaştırılabilir. Bunun için bir standart yazılabilir. Fakat nişancının şekli formu değişir. Yeni oyun siteleri ve mekaniği, zemin mekaniği kullanırsa bölgenin yapısıyla bu değişikliklere uyum sağlamak zorundadır.

.

KÖTÜ TASARIM BELGELERİ

Daha önce tavsiye ettiğim gibi daha önce başarılı olmuş profesyonel oyun belgelerini elde etmeniz size faydalı olacaktır. Bu belgeler size endüstrinin sizlerden ne beklediğini hangi özellikleri yazmanızı beklediğini gösterecektir. Yine de dikkatli olmalısınız. Elde ettiğiniz belki kötü bir belge de olabilir. Birçok belge bu kapsamdadır. Tecrübeli kişilerin bile yazdığı çok kötü belgeler olmuştur ve ben bu şekilde birçok kötü belgeyle karşılaştım. Bu belgeleri yazan kişilerin niye başarısız olduklarını ve neyi amaçlamaya çalıştıklarını anlamaya çalıştım.

Çok ince veya çok yuvarlak belgeler

İnce, az sayfaya sahip olan bu belgeler 30 sayfayı geçmez. Eğlenceli oyun tasarımcıları örneğin çok tecrübeli oyun tasarımcılarından bu anlamda başarısız eserler görebilirsiniz. Şöyle saçma bir tanımlama yapmışlardır ki oyun eğlenceli olmalıdır, geri dönüt keskin olmalıdır. Bu belgelerde diğer oyunlarla birçok karşılaştırma yapılmıştır. Bu oyun süper mario 64’e benziyor veya oyundaki kontrol şeması Qauke oyunu gibidir diye benzetme vardır. Bu tür benzetmeler faydalı olabilir eğer bunlar tasarım belgesinde ayrıntılı olarak anlatırsa. Birde benzetme olarak da bunların ismini verirse sorun olmaz. Ama sadece bu şekilde derse bu yeterli olmayacaktır.

Genelde bu belgelerin yarısı oyun arka hikayesiyle geçer. Genelde bu arka plandaki hikaye çok zayıf veya çok fakir geliştirilmiş olabilir. Oyunun geliştirilmesi hususuyla bağlantısı teğet geçmiş de olabilir. Böyle ince belgeler aynı zamanda menülerin nasıl çalıştığı ile ilgili olarak çok fazla ayrıntı verir. Oyundaki dahili menüleri değil sistem menüleri ile oyuncu ne tür bir oyun oynamak isteyecek, ayarları nasıl yapacak ve ötesi.
Birçok model yapılmıştır ve seçenekleri dikkatli bir şekilde listelenmiştir. Seçeneklerin oyunu nasıl etkileyeceği detaylarda genelde çok az tarif edilmiştir bu yüzden oyunun kendisi az tanıtılmıştır. Bugün yani sistem menüsünün tanıtılması şu açıdan önemlidir: oyun oynarken tasarımcı şunu bilmelidir ki hangi seçenekler önemlidir oyuncu farklı oyun seçeneklerini seçtiğinde ne olacak. Oyun tasarımının en zor bölümü değildir veya ilk olarak masaya yatırılması gereken kısım kısım değildir
Zar gibi ince tasarım belgesi genelde kendisini oyun tasarımcısı olarak düşünen tasarımcılar tarafından yazılır. Oyun dahil olacak oyuncular şu tarzda tarif edilebilir ”orman dünyası” çok sıcak yapışkan bir yerdir ve burada garguflax maymunları sallanır ve oyuncuya işkence ederler. Burada yazarın geri dönüp eksik kalan kısımları daha sonra tamamlayıp tamamlamadığı açık değildir. Oyunun nasıl çalıştığını açıklayacağı zamanı boşa geeçen zaman olarak görür. Birisi boşlukları doldurur ve güzel bir hale dönüştürür oyunu diye düşünür

Böyle çok yuvarlak belgelerden birinde ”oyunculara birçok silahlar verilecek. Örneğin Gargantuan Kaboomun verdiği zarar iki kattır. Diğer silahların özel etkileri vardır. Barboon Harpoon oyuncuları ve düşmanları uzaktan güzel bir kamera efekti ile öldürecektir. Diğer silahlar eğlenceli ve hoş olacaktır. Yuvarlak tasarımcı bu silahların tarifini yeterince yapmamış gerekli ayrıntıları vermemiştir. Geri kalanı okuyucunun hayaline bırakmıştır. Elbette okuyuculara geri kalan silahların eğlenceli ve güzel olduğunu söylemiştir. Tasarımcı bu kadar az ayrıntının oyun geliştirmesi için yeterli olacağını düşünmüştür. Bu düşünce de yanlıştır

Tersine bu ince ve yuvarlatılmış belgeler oyunu geliştirmek isteyen geliştiricilerin projeyi alıp kendi istedikleri gibi yapmalarına olanak sağlar. Diyorum ki bu bir avantajdır. Genelde müdürün, yöneticinin fikirleri bu ince dökümanlara eklenmiştir ve bunlar da oyunu çok sıkıcı uygulanabilir bir oyun yapmaktan çıkarmıştır. Siz bu boşlukları doldurarak değiştirebilirsiniz. Sorun 6 ay sonra, oyunu geliştirdikten sonra müdürün bu benim yazdığım değil demesidir.

Arka Plan Cildi

Yuvarlatılmış özel belge yazarlarının aksine karakterin önceden başına gelenlerin hikayesini tasarlayanlar bu belgeyi hazırlarken çok zaman harcarlar. Bu kitaplara belge demek zordur. bu 300-400-500 sayfalık belgeler sorgulanamaz denemez. Orada çok bilgi var.
Bu belgelerde yapılan ilk hata zayıf yetersiz içindekiler tablosu sunmalarıdır. Tasarım belgesinde iyi düzenlenmişse içinde bilgi ve iyi içindekiler tablosu vardır. Fakat ikisinin de olmaması çok büyük bir hata olur.
Problemler “War and Peace” gibi uzun oyunun olduğu zaman daha şiddetleniyor. Oyun tasarım belgesinde içindekiler kısmının yazılması birinci sebebi takım üyelerinin üzerinde çlışacakları bölümler hakkında hızlıca bakıp bilgi almalarını sağlamaktır. Eğer bir yazılımcı yapay zekanın bir kısım düşman karşısında nasıl hareket edeceğini bilmek isterse bu bilgiye kolayca ve hızlıca ulaşmak ister.
Eğer bu bilgiyi bulamazsa başka bir şey yapabilir. Benzer olarak grafik tasarımcı oyunda kendisi için verilen alana ait yazı ve nesneler hakkında fikir sahibi olmak istediğinde bunların tarif edildiği yere hızlıca ve kolayca ulaşmak isteyecektir. Tasarım belgeleri hikaye gibi okunmazlar. Hiçbiri baştan başlayıp sonda bitirilmezler. Öncelikli olarak tasarım belgeleri referans materyalleridir ve eğer takım üyeleri aradıkları bilgiye kısa sürede kolayca ulaşamazlarsa bu işten vazgeçmeye eğilimlidirler.
Yine de birisi eğer birisi bu arkaplan to hikayesi koca cildinde bir şey aramaya başladığında başka bir şey bulacaktır ama oyun hakkında herhangi bir bilgi yoktur bu kitapta. Sadece oyunun hikayesi ve 500 sayfa oyun bilgisayar oyunlarının kullanacağı arka plan hikayesinden daha fazlasıdır
Oyundaki bütün karakterler, karakterlerin arkadaşları ve bununla ilgili öyle bir dakikada anlatan belgeler de vardır. Bunları böyle bir dakikaya sıkıştırmak çok ilginç olabilir fakat sonunda okuyucu bunları okuduğunda oyunun nasıl bir işleyişinin olduğu nasıl ilerlediği hakkında çok az bir fikri olur. Bu yaklaşım genelde oyun gelişimini tasarımını bilmeyen bir hikaye yazarı veya interaktivite bilgisi olmayan kısa yazılar yazarın yaptığı iştir. Kişi yazısına kendi ilgi alanlarını yazar ve bunu hikayenin merkezine otuttur. Bu anlamda oyun tasarımında bunu tartışmak bazı durumlarda uygun olabilir. Fakat en öncelikli olarak bir tasarım belgesinin oyunun tasarımını içermesi beklenir ve bu da oyunun hikayesinden farklıdır. Hatırlayın bir oyun yazarken en çok neyi dikkate almamız gereken şey oyuncu ne yapacak sorusudur. Gerçi bu ciltler ağırlık olarak çok belirgindir ve bazı kapitalistleri etkileyebilir ama bu öyle bir döküman da çalışacak programcı ki bu döküman onun tek rehberidir oyunu tasarlarken oyunun ne yaptığını yazmak önemlidir.

Aşırı Yüklenmiş Belge

Bazı tasarımcılar tasarım belgesinde tüm ayrıntıların tarif edileceğini düşünür. Evet doğrudur bazı tasarımcılar yuvarlak tasarım belgelerinde oyun hakkında yeterli bilgi, detay vermezler fakat aynı zamanda oyun hakkında çok aşırı ayrıntı vermek tasarımcı için zaman kaybıdır. Çünkü bunu okuyacak tasarımcı gerekli bilgi almak için dökümanın sonuna kadar okumak zorundadır. Bu da vakit kaybıdır. Aşırı döküman yazmak şöyle bir ilizyona yol açabilir Aslında belli ögeleri nesnelere fazla vakit ayırıp asıl odaklanması gerekenlerin atlandığını düşündürebilir.
Oyununuz belli hareketleri yapan birçok karakterle doludur. Örneğin oyun kasaba halkıyla doludur ve bunlar etrafta yürürler, otururlar, kalkarlar birbirleriyle konuşurlar ve uyurlar. Bu belgede bu davranışları yapay zeka kısmında tarif etmiştir. Doğru hazırlanmış bir belge bu hareketleri animasyonları bölümlere ayırmıştır. Oturmayı kalkmaktan, ayakta durmaktan yürümeyi konuşmaktan ayırma gibi. Belki bu gerekli değildir ve bu yüzden iyi animasyoncular ve artistler sanatçılar tasarımcının yapabildiğinden daha iyi yaparlar. Fakat bazı tasarımcılar bu tasarıma belgesine bakmak ve eşsiz animasyon karelerini listelemek isterler. Bu biraz saçma çünkü tasarım belgesi düzeyinde kaç tane animasyon karesine ihtiyaç duyulacağını bilmek mümkün değildir. Bu tür bir karar ancak oyunun üretim aşamasında ayarlanabilir. Aynı zamanda bu kadar ayrıntıya girmek animatörün moralini bozacak, kendi işini çok fazla karışıldığını düşünecektir. Daha da ötesi tasarım belgesi oyun tasarımına yapışacak ve sanat belgelesini etkileyecektir.
Diğer örnek benim veriyi dengeleme dediğim şeydir. Bunlar silahlar, nesneler, karakterler hakkında gerçek bilgileri vermektir. Tasarım belgesi ne tür farklı silahların ve karakterlerin olduğunu listelemedir. Örneğin bir silah atış sayısı bir atış mesafesi atış doğruluğu gibi bilgileri içerir. Daha da ötesi tasarım belgesi, verilen silahın kalitesini tarif etmek isteyebilir. Örneğin çift barelli silah kısa atış mesafesi ve düşük doğrulukla hatice der atış eder fakat geniş bir alanda büyük zarara yol açar. Yine de silahların özelliklerini ayrıntılı tarif etmek tasarım belgesinde çok faydalı bir şey değildir. Örneğin atış doğruluğu eşittir 2 ifadesinin pek bir anlamı yoktur. Çünkü iki burada neyi ifade etmektedir, belli değildir. Bu değerler oyun tasarlanırken kullanıcının oynayacağı oyunda tasarımcının beklenen etkileri ayarladığı kısımdır.

Animasyondaki küçük detaylar verideki dengeyi ayarlama belgeye ait değildir.Kod belgeye ait değildir. Algoritmayı tasarım belgesinde yazan tasarımcı bundan çok uzaktır. Bu tasarımcı isterse programcı olsun fark etmez burda kod olmamalıdır. Tasarım belgesinde böyle şeyler olmaz. Belgede kod bulunmamalıdır, yalancı kodlar da bulunmamalıdır. Bunlar belgeyi şişirecek ve asıl içermesi gereken bilgilerden uzaklaştıracaktır. Bazı if then else gibi mantıksal açıklamalar faydalı olabilir. Bu tür örnekler kodu yazacak kişilere yardımcı olabilir. Bu tür örnekler kodi alan kişilere yardımcı olur tasarımcının olabilecek tüm durumları yazması oyun açısından gerekli desteği sağlayacaktır yazılımcıya. Fakat c++ tarzı bir yazımı andırırsa bu yazılımcının işini yapmak olur.

Çok şişirilmiş tasarım belgesinde faydalı bilgi varsa eğer şişirilmiş bu bilgilerin arasında kalacaktır ve görünmeyecektir, takım üyeleri bu bilgiyi bulamayabilirler. Yazar herşeyi önceden planladığını ve takım üyelerinin bu anlamda şanslı olduğunu düşünebilir. Bu kadar aşırı ilgi detay gerçekten ne iş yaptığını bilmeyenler için etkileyici olabilir sadece o işi yapan işini bilen ekip için çok fazla bir yazı olacaktır.

Olmayacak vaatlerle dolu belge

Bu tip tasarım belgeleri çok büyük fikirlerle dolu ve etkileyici bir oyununu ifade eder. Maalesef yazılan şeyler teknik imkanlarla yapılabilecek şeyler olmayıp aynı zamanda bir buçuk yıl içerisinde 20 kişilik bir ekiple yapılamayacak senaryolar yazmıştır. Sonuç olarak bu tür belgeler çok fantastik eğlenceli ama gerçekliği ve fizibilitesi yani yapılabilirliği olmayan ve geliştirme takımına hadi alın yapın tarzında dayatılan belgelerdir.

Böyle hayal dökümanları absürb fikirler içerir. Örneğin manhatın şehrinin tam olarak modellenmesi, oyuncuların burada oynaması. Örnek olarak 7 milyon kişinin gerçek zamanlı olarak modallenmesi ve yapay zeka tarafından çalıştırılması mümkün değildir. Hayalci yazar işte bu kadar kişiyi simüle edebilecek güçte bir bilgisayar var mı yok mu bunu düşünmez bile. Diğer bir husus ta kullanıcıların aralarında dinamik olarak yazdıkları karışık cümle yazılarına düzgün bir şekilde cevap vermesini beklemektir. Suçlu olan bu yazar araştırma şirketlerinin kelime işlemcilerin üzerinde 10 yılı aşkın sürederir çalıştığını ve bu işlemlerin gerçekten zor olduğunu ancak basit cümlelerin yapabileceğini duymak istemezler. Böyle hayalci bir belge ile karşılaşıldığında gereken şey bir gerçeklik kontrolü toplantısı ayarlamaktır. Toplantıya anahtar yazılımcıları,grafik tasarımcısı ve sizden bu işi yapmasını bekleyen yöneticinizi çağırın. Onlarla aynı odadayken kağıt üzerinde veya bir tahtada hızlı ve basit hesaplamalar yaparak bu işin neden pratik olmadığı yapılamayacağını kanıtlayın. Eğer yöneticiniz hala durumdaki gerçekliği kabul etmek istemiyorsa o zaman yeni bir iş aramanın zamanı demektir. Bu hayali belgeler genel ve özel yuvarlatılmış belge mantığıyla yazılan bu tür dökümanlar ayrıntıyı önemsemeyen olmayacak duaya amin diyen tasarımcı eserleridir.

Fosilleşmiş Belge.

Anlatılan belgeler aynı zamanda fosilleşmiş, çöpe gidecek belge olabilir. Gerçekten yukarıda anlattığımız problemleri taşıyan iyi belgeler çöpe atılmış belge olabilir çünkü yazar tasarımcı belgesini güncel tutmamış olabilir. Ben hiçbir orjinal oyun projesi bilmiyorum ki gelişme süreci içerisinde belirgin olarak değişmesin. Tasarım değişmiş ama belge değişmemiş ise o belge de çöp olur

Geliştirme takımında çalışan bir programcı düşünün, çöp olmuş bir belgeye baktığında aradığı bilgi güncelliğini kaybetmiştir ve o hala eski metni yazmaya çalışmaktadır. Bu değişikliklerden haberdar olan yazılımcı tasarım belgesinin güncel olmadığını fark edecektir. Bu da programcının zamanını boşa harcanması demektir. Bundan sonrada tasarım belgesine güvenmeyecektir bunun yerine programciya veya tasarımcıya soracaktır.

Wiki sistemleri dökümanları güncel tutmak için faydalı bir yöntemdir. Wiki ile birlikte takımdaki herhangi birisi web browser aracılığıyla kendine ait bölümü kolayca güncelleyebilir. Böylece tasarım belgesi güncelliğini korumuş olur. Yeni eklenmiş bir link veya bir nesnenin özelliği değiştiğinde bunu dökümanı yansıtabilir. Büyük projelerde belgeyi güncel tutmak başlı başına tam zamanlı iştir

Ağırlık sorunu.

Çoğu zaman tasarım dökümanlarının okunmadığı ve bir ağırlık yaptığından bahsedilir. Eğer dökümanınız çok kötü ise bu genelde doğrudur. Bir keresinde büyük bir oyun firmasında buradaki üreticilerin yaşadığı çok kötü tasarım belgesi tecrübesini duymuştum. İki tane yapmaya değer proje geldiğinde tasarım belgeleri masaya yatırılmıştı. Ağır gelen bir tanesi kabul edilmiş diğeri reddedilmişti. İş dünyasında çalışan biri olarak çok miktarda doların harcanacağı bir ortamda belgenizin kabul edilmesi için onun güçlü ve dolu olması gerekir. Etkileyici ve başdöndürücü olmalısınız. Bazıları dökümanı hiç okumaz, bazıları sadece içindekiler ve genel bakışı okur. Fakat herkes onu alır ve onun ağırlığına gücüne vurgu yapar.

Elbette çok kalın belgeler çok fazla bilgi içerirler ve bu bilgilerin birçoğu da kullanılmayacaktır. Bunlara örnek verilebilir daha önceden anlattığımız şekliyle bunlar arka plan hikaye örnekleri veya ölü belgelerdir. Tasarım belgesini, pratik sadece kullanılacak faydalı bilgilerle doldurmak Aynı zamanda bu veriyi etkileyici ve beğenir yapmanız gerekiren oldukça zordur. Birisi belgeye bir sürü akış diyagramı veya konuşma metinleri veya daha büyük yazı fontu kullanarak çok şüpheli hale getirebilir. Gerçekten büyük oyunlar sadece 10 sayfa uzunluğundadır. Bazıları böyle kısa basit oyun tasarımları kabul edildiğini ve büyük

danışmanı Mark Henry tasarım belgesi geliştirmeye başlarken yalnızca basit makro tasarım belgesinin yazılması tavsiye eder. Sadece belki belgenin yeterli olacağına gerisinin geliştirme aşamasında yazılacağını söyler. Daha önce söylediğim gibi bazıları ince tasarımların kabul edildiğini kalınların reddedildiğini görünce şaşırırlar.
Şükürler olsun ki son birkaç yılda yayıncılar ve geliştiricilerimiz büyük kalın belgelerden vaz geçmişlerdir. Tasarım kullanmaya başlamıştır. Birçok veri olduğunda bunları organize ederken veya birçok bilgiye de içiçe linkler bağlantılar sağlarken Wiki kullanılır. Daha az sayıdaki yayıncılar telefon kitabı tarzındaki tasarımlara para yatırırlar. Bu durumda prototip ve üst düzey grafiklere sahip belgeler önemli olmaya başlamaktadır. Allahtan böyle şişirilmiş belgelerin tercih edildiği dönemin sonuna yaklaşıyoruz

Belgenizi Okutma

Tasarım belgesi yazdıktan sonra en büyük zorluk o'nu okuyacak bir geliştirme takımı bulmaktır. Genellikle programcılar, artistler veya diğer tasarımcılar zamanlarını bir belgeyi dikkatlice okumaya harcamak istemeyeceklerdir. Bazıları da geçmişte okudukları kötü belgelerden dolayı sizin belgenizin detaylarını atlayacak ve sonuç kısmına gelerek belgenizin kötü kalitede olduğunu söyleyecektir. Belgenizi güncel tutarak sadece faydalı bilgileri, gerekli detay tablolarını koyarak belgenizi pratik uygulanabilir oyun elementler ile doldurmaya çalışın. Her bir bölümün öncesinde kısa ama yüksek kalitede özetler koyun. Okuyanlar ilk etapta farklı kaliteli kısımları okusunlar ve ihtiyaç duymadıkları kısımları es geçebilsinler. Ayrıca böyle özet kısımlar, ayrıntıya girmeden önce kişiye büyük resim hakkında bilgi verir. Eğer takım elemanları belgenizi gerçekten kaliteli bulursa ayrıntılara da bakacaklardır. geri kalanı da okusun istiyorsanız yazılan dökümanda okuyucuların güvenini kazanmak zorundasınız.
Diğer bir anahtar metod ise dökümanınızı okumak isteyen herkesin dökümana kolay ulaşabilmesini sağlamaktır. Bunu takımınızın kullandığı nesne/belge yönetim sistemi içerisinde tutun böylece ekip üyelerinizin en son versiyonuna kolayca ulaşabilmesini sağlamış olursunuz. Biz proje süresince sürekli olarak dökümanı güncelleyeceğimiz için dökümanınızın fosilleşmiş döküman olmasını engellemek için ne yapacaksınız? Kaynak kontrolü değerli olacaktır. Orijinal versiyonlarda ne gibi değişikliklerin yapıldığını izleyebilmek için. Ölü bir atı mahmuzlamayın fakat wiki sistemi dökümanın takım üyeleri arasında şirket interneti içinde dağıtılamsını sağlar böylece takımdaki geliştiriciler dökümanın son haline web browserları aracılığıyla ulaşırlar.
Son versiyonda bir değişiklik yaptığınız zaman takım arkadaşlarınızla bu değişikliği yaptığınızı bildirin ve nelerin değiştiğini açıklayınız. Böylece arkadaşlarınız kolayca değişiklikleri fark edecektir. Değişiklikler arkadaşlarınızın üzerinde çalıştığı belgeyle veya işle ilgili ise o zaman belgeyi internetten alarak ilgili güncellemeyi okuyacaklardır. Eğer hiç kimse yaptığınız değişikliklerden haberdar değilse bir güncelleme yapmanızın da bir önemi yoktur. Eğer insanlar güncelleme yaptığımızı bilmiyorsa hala eski versiyonları okuyor olacaklardır. Bu yüzden belgeye versiyon numarası vermeniz faydalı olacaktır. Bu versiyon numarasına tarihi ekle. Tarihi her sayfaya başlık olarak yazdır. Genellikle insanlar tasarım dökümanlarının ne kadar eski bir döküman olduğunu bilemezler ve böylece yenisine ihtiyaç duyup duymadıklarını bilemezler.

Dökümantasyon sadece bir başlangıçtır

Bazı tasarımlar veya bazı tasarımcılar döküman tasarlamanın oyun yapmak için yeterli olduğunu düşünürler. Gerçekten bazı firmalar tasarım dökümanı yazdırırlar ve kişileri başka tasarım dökümanları yazmaya yönlendirirler. Bu arada ilk yazdıkları uygulamaya başlanır. En iyi tasarım dökümanı da kabaca oyunun ana hatlarıdır. Bir fikrinin tavsiyesinden başka birşey değildir. Oyunun oluşturma sürecine dahil olmadan bir ana heykeli çıkmadan hiçkimse tasarlanan oyunu göremeyecektir. Yaptığı tasarıma sahiplenen bir tasarımcı proje süreci içinde işin içinde olmak isteyecektir. Bu süreç içerisinde oyunun en güzel en çekici bir oyun olması için gerekli değişiklikleri yapmak ve güncellemek isteyecektir ve buna da hazırdır. İlgili bir oyun tasarımcısı silahların gücünü, dengesini ayarlamak ve kontrollere ve seviyelere müdahale etmek isteyecektir. Oyunun akışının değişmediğini ve vizyonuna uygun geliştiğini görmek isteyecektir.
Eğer tasarımcı tasarım dökümanını yazarsa ve bunu başkalarının eline bırakırsa bunu alan kişiler bunu gerçekleştirirken kendi ilgi ve kendi sanatsal bakışlara göre değiştirmek isteyeceklerdir. Tasarım dökümanı onların kendi hareketlerini kendi düşüncelerini yapabilecekleri bir tahta gibi olacaktır. Orjinal tasarımcının istediği gibi olmayacaktır. Tasarım dökümanı belki oyun üretmesürecinin dahili bir parçasıdır ama gerekli olan herşey değildir. Proje üzerindeki yazarlığın anlamı iddia etmek için tasarımcı üretme süreci içerisine dahil olmalıdır. Hatta belki bir yönüyle tasarım belgesini yazmak bilgisayar oyunu tasarımının en kolay kısmıdır. Gerçekten tasarım belgesini almak en kolayıdır zorlu oyun deneyimleriyle oyunu yazmak oluşturmaksa oldukça zordur