Bir tasarım belgesini nasıl yapılandırmalıyım? [kapalı]


30

Tasarım dokümanı, gerçek bir cümle ile, oyunun tam bir açıklaması gibi, sürekli bir metin satırı mı olmalı yoksa basit noktalarda yapılandırmalı mıyım? Yararları nelerdir ve yapılandırmanın başka yolları var mı?


5
Josh'un cevabına kesinlikle katılmıyorum, ancak sadece 1 cevabı olan 35 dakika içinde bir soruyu cevaplandı olarak işaretlemek için biraz erken değil mi?
Kylotan

4
Evet katılıyorum. Sen edebilirsiniz hep daha sonra değiştirebilir, ancak bu her zaman çok Yanıtını size uzak değişiyor kişiye hayal kırıklığı oluyor. Ve daha da önemlisi, bazen bir cevabı seçmek, başkalarını kendi başlarına cevap vermekten caydırır ve bu da benimkinden çok daha iyi bir cevabı kaçırmanıza neden olabilir.
Josh

Tamam, cevap ver. Ama, muhtemelen yarın tekrar işaretleyeceğim, gerçekten yararlı buldum! Tabii ki, birisi bana daha da faydalı bir şey almadıkça;). Yine de bu ipucu için teşekkürler, bunu düşünmedim!
jcora

Ayrıca GDD'nizin yapısı hakkında daha fazla bilgi için bu makaleyi inceleyebilirsiniz. Bu gerçekten harika bir kaynak: active.tutsplus.com/articles/game-design/…
Daniel Sidhion

@Josh puanınız korkutma - kim bir cevap sizi yenmek için çalışacak;)
Tim Holt

Yanıtlar:


30

Kural veya endüstri standardı yoktur; Belgenin amacının ne olduğunu göz önünde bulundurarak belgeyi, bu belgeyi tüketecek kişiler için en yararlı olacak şekilde yapılandırın .

Şahsen, fikrinizi iletmek için "gerçek cümleler" kullanmaya daha uygun belgelerin bölümlerinin yanı sıra, bir madde işaretli özellikler listesi olarak yazılmaya daha uygun bölümlerin olmasını beklerdim.

Kitleniz kim? Yalnızca sizseniz, bunun sadece düşüncelerinizi odaklamanıza yardımcı olması gerekiyorsa, sizin için ne gerekiyorsa yapın. Başkalarıyla çalışıyorsanız, belgenin nasıl kırıldığını nasıl görmeyi tercih ettiklerini ve nasıl kullanmayı beklediklerini sorun.

Oyunun göze çarpan noktalarının nesnel bir tanımını görmeyi beklerdim: ana konsept, tarz ve his. Daha sonra oyunun her büyük özelliği için bir bölüm görmeyi beklerdim.

Ayrıntı ve istatistiklerle aşırıya kaçmayın, bir tasarım belgesinin, genellikle inşa ederken ve yinelendikçe oyunun ömrü boyunca değişecek bir şey olduğunu unutmayın. Önceden bir kez yazacağınızı düşünmek pratik değildir ve mükemmel olacaktır, bu nedenle belgeyi şimdi iletmek için neye ihtiyacınız olduğuna ve bu belgenin belirli tüketicilerine en iyi şekilde nasıl aktarabileceğinize odaklanın .

Başkalarının ne yaptığı önemli değil, ekibiniz için en iyi olanı yapmak istiyorsunuz.


Bir tasarım belgesi, özünde oyunun bir özetidir. aynı şekilde, bir kitap için bir taslak hazırlarsınız, gerçekten önemli olan tek şey, fikrinizi anlamak ve bunu yapmak için “ihtiyacınız olan” dır. hedef kitlenin amacını pekiştirmek istemem ve her alt bölümün bile farklı bir izleyici kitlesine sahip olmasına rağmen, bir proje planının ekip / yönetici için olması, vakaların / ERD'lerin programcılar için olması ve varlık tanımlarının sanatçılar için kullanılması. aynı genel konu hakkında olmanın yanı sıra birbirine uymayan bir şey yazabileceğiniz birkaç zamandan biri.
gardian06

24

Josh'un cevabında söylediklerine ek olarak, birkaç kişi bir oyun tasarımı belgesinde nelerin gitmesi gerektiği konusundaki fikrini paylaştı; bu, hangi yönlerin kendi belgelerinizde yararlı olacağına karar vermenize yardımcı olabilir. Bunların profesyonel tasarımcılar olduğunu ve geleneksel oyun endüstrisi bağlamında onlar için çalışanların mutlaka sizin için doğru olmadığını unutmayın, bu nedenle neden belirli yaklaşımları kullandıklarını ve size en çok yardımcı olacakları seçtiklerini denemek ve çalışmak yararlı olacaktır. .


Oyun tasarımı dokümantasyonunu ve nasıl yapıldığını araştırdım. İlk bağlantınız harikaydı. 'Kapsam' ile gerçekten iyi çalışıyor. Projenin temel kapsamını belirlemek ve kaba sözlerle oyunun kapsamı içinde ve dışında ne olduğunu açıklamak.
Wertilq

5

Eklemek istediğim bir bilgi var: Oyunun gerçek tasarımını belgelerken (yani: kurallar), belirli bir kural tasarım seçimini neden yaptığınıza dair net açıklamalar yapın .

Bir şeyi uygulamaya geçtiğinizde unutacağınız şeylerden biri, belirli bir kuralı eklemenin nedenidir. Ayrıca, yapmanız muhtemel olan şeylerden biri, diğer oyunların sahip olduğu için kurallar ve oyun öğeleri eklemek, oyunun ihtiyaç duyduğu için değil.

Bir oyun öğesinin tam olarak neden var olduğuna dair bir bölüm ekleyerek, bu öğenin kullanımını genel oyun tasarımı açısından haklı çıkarmaya zorlar. Ve daha sonra, belirli bir öğenin aslında sizin hedeflediğiniz ihtiyaçlara hizmet edip etmediğini etkili bir şekilde değerlendirmenize olanak tanır. Eğer değilse, o zaman çıkarabilir ve bu ihtiyaçları karşılayacak başka bir şeyle değiştirebilirsiniz.

Daha da iyisi, oyunun işe yaramadığını görürseniz ve oyunu daha eğlenceli hale getirmek için birden çok öğeyi değiştirmek istiyorsanız, tasarım belgenize tekrar bakabilir ve bu öğeleri neden seçtiğinizi ve hangi yeni öğelerin başarılması gerektiğini anlayabilirsiniz. . Oyun tasarımınızın gereksinimleri değişirse, oyun öğelerinin ne yapması gerektiği ile ilgili listenizi güncelleyebilirsiniz.


1

Seviye Yazarı yazarının oyun tasarım belgelerini birçok sevimli şekil, karakter vb. Çizerek yazmak için kullandığı yöntemi seviyorum.

Bu kitaba bir göz atmanı tavsiye ederim. Seviye !: Harika Bir Video Oyunu Tasarımı Kılavuzu

Belgelerinize küçük çizimler ekleyerek diğerleri size daha fazla önem verecek ve tasarım belgelerinizi okuyacaklarından emin olabilirsiniz.


0

Oyun tasarımı belgenizin yapısı tamamen size kalmış, ancak oluşturduğum bir eklemenin eğiliminde olduğunu (bunun RPG'ler veya diğer hikaye odaklı oyunlar için daha iyi çalıştığını unutmayın):

İçindekiler - Çok önemli, çünkü bir kez daha karmaşık oyunlara sahipseniz, bir organizasyon yöntemi eklemeniz gerekecek

Oyunun Tanımı - Platformun ve diğer önemli ayrıntıların yanı sıra oyunun bazı tanımlarını veren oyunun kısa bir açıklaması

Hikayeye genel bakış - Arsaınıza genel bir bakış verin

Kontroller - Oyunda kullanacağın kontrolleri listele

Teknik gereksinimler - Burada platform hakkında daha fazla ayrıntı girebilirsiniz

Oyun Akış Şeması - Oyun ekranlarının nasıl bağlandığını göster

Sunum - Kamera tipi, HUD ve oynatıcının göreceği diğer bilgiler hakkında ayrıntılı bilgi verin.

Oyuncu Karakteri - Oyuncuların hakkında, nasıl göründükleri, sahne arkası ve kullanabilecekleri araçlar / silahlar gibi bilgiler verin.

Mücadele - Mücadelenin nasıl yürüdüğünü açıklayın (varsa)

Oyun Seviyeleri - Bazı seviye örnekleri ver

Düşmanlar - Düşmanlarınız hakkında detaylı bilgi verin (saldırılar, bakışlar)

Patronlar - Belirli patronlar hakkında bilgi

NPC'ler - Karakterinize saldırmayan AI'leri tanımlayın

Müzik / SFX - Hangi müzik ve SFX'in üretilmesi gerekiyor?

Ekler - Kodları ve diğer bilgileri içeren buraya uzun listeler yerleştirin

Ayrıca, oyun tasarım belgenizin aşağıdakileri içeren yaklaşık bir sayfa olan daha özlü bir versiyonunu oluşturmak isteyebilirsiniz:

Başlık ve Konsept Genel Bakışı - Oyunun nasıl olduğu ve oyuncuların neler yapacağı hakkında kısa bir genel bakış

Platform - Oyunun yayınlanacağı platformu listele

Ana Noktalar - Oyununuz hakkında FPS, MMO ve tek oyunculu bir moda sahip olmak gibi çok temel bilgileri verin

Özet - Eğer varsa, arsa özeti

Karakterler - Karakterleriniz hakkında bilgi verin

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.