Як я повинен структурувати проектний документ? [зачинено]

Якщо проектний документ повинен бути суцільним рядком тексту з реальними реченнями, більше подібним до опису всієї гри, або я повинен структурувати її в прості точки? У чому переваги, і чи існує більше способів її структурування?

Не існує правил або галузевих стандартів; структуруйте документ таким чином, який буде найбільш корисним для людей, які бажають споживають цей документ, пам’ятаючи, яка мета вашого документа.

Особисто я б очікував, що в документі є частини, які краще підходять для використання "реальних пропозицій" для передачі вашої ідеї, а також частини, які краще підходять для написання у вигляді кульового списку функцій.

Хто ваша аудиторія? Якщо це лише ви, якщо це просто допоможе вам зосередити свої думки, зробіть все, що працює для вас. Якщо ви працюєте з іншими, запитайте їх, як вони вважають за краще бачити документ розбитим і як вони розраховують на його використання.

Я б очікував побачити прозовий опис важливих моментів гри: це головна концепція, стиль та почуття. Тоді я б очікував побачити розділ для кожної основної функції гри.

Не перебирайте деталі та статистику, пам’ятайте, що проектний документ, як правило, щось, що розвиватиметься впродовж життя гри, коли ви будуєте та повторяєте. Недоцільно думати, що ви напишете його один раз, вперед, і це буде ідеально, тому зосередьтеся на тому, що вам потрібно передати документ зараз, і як ви зможете найкраще донести це до конкретних споживачів цього документа.

Не має значення, чим займаються інші люди, ви хочете робити те, що найкраще працює для вашої команди.

In addition to what Josh has said in his answer, several people have shared their idea of what should go in a game design doc, which may help you decide what aspects are going to be useful in your own docs. Remember that these are professional designers, and what worked for them in the context of the traditional games industry is not necessarily right for you, so it's useful to try and work out why they use certain approaches and pick the ones that will help you the most.

• Damion Schubert's "How To Write Great Design Documents" (Powerpoint slides) (this is my favourite approach)
• Brenda Brathwaite's "Creating a Game Design Document"
• Mike Birkhead's "How I Document A Game"
• And finally... Erin Robinson's "5 Alternatives to a Game Design Doc"

There is one piece of information that I'd like to add: when documenting the actual design of the game (ie: the rules), provide clear explanations for why you're making a particular rule design choice.

One of the things you're more likely to forget when you go about implementing something is the exact reason why you added a particular rule. Also, one of the things you're very likely to do is to add rules and game elements just because other games have them, not because your game needs them.

By adding a section on exactly why a game element exists, it forces you to justify the use of that element in terms of the overall game design. And later on, it allows you to effectively evaluate whether a particular element is actually serving the needs you intended it to. If it's not, then you can remove it and replace it with something else that does serve those needs.

Even better, if you find the game isn't working out, and you want to replace multiple elements to make the game more fun, you can look back at your design document and understand why you choose those elements and what new elements need to accomplish. If the needs of your game design change, then you can update your list of what the game elements are supposed to do.

I like the way Level Up author uses to write his game design documents with drawing many cute shapes, characters and etc.

I highly recommend you take a look at this book Level Up!: The Guide to Great Video Game Design

With adding little drawings to your documents the others will pay attention to you more and you can be sure they will read your design documents

The structure of your game design document is completely up to you, but one I create tends to include (note that this works better for RPGs or other story-driven games):

Table of Contents - Very important, as once you have more complex games you will need to include an organization method

Description of the Game - A brief description of the game, giving some descriptions of game-play, along with platform and other important details

Story overview - Give an overview of your plot

Controls - List the controls you will be using in your game

Tech requirements - You can go into more detail about platform here

Game Flowchart - Show how your game's screens connect

Presentation - Give details about camera type, HUD, and other info the player will see

Player Character - Give information about your player, such as what they look like, backstory, and tools/weapons they may use

Combat - Describe how combat works (if applicable)

Game Levels - Give some examples of levels

Enemies - Give details about your enemies (attacks, looks)

Bosses - Information about specific bosses

NPCs - Describe AIs that don't attack your character

Music/SFX - What music and SFX need to be produced

Appendices - Place long lists here along with scripts and any other information

You may also want to create a more concise version of your game design document which is about one page, containing the following things:

Title and Concept Overview - Give a brief overview of what the game is like and what players will do

Platform - List the platform the game will be published on

Main Points - Give the very basic info about your game, such as it being an FPS, an MMO, and having a single-player mode

Summary - Summarize your plot, if any

Characters - Give some info about your characters