Should the design document be a continuous line of text, with real sentences, more like a description of the entire game, or should I structure it in simple points? What are the benefits, and are there more ways of structuring it?
closed as primarily opinion-based by Alexandre Vaillancourt♦ Feb 6 '18 at 13:52
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
There are no rules or industry standards; structure the document in the way that will be most useful to the people who will consume that document, keeping in mind what the purpose of your document is.
Personally I would expect there to be portions of the document that are better suited to using "real sentences" to convey your idea, as well as portions that are better suited to being written as a bullet-point list of features.
Who is your audience? If it's just you, if this is just supposed to help you focus your thoughts, do whatever works for you. If you are working with others, ask them how they'd prefer to see the document broken down and how they would expect to use it.
I would expect to see a prose description of the salient points of the game: it's main concept, style and feeling. I would then expect to see a section for each major feature of the game.
Do not go overboard with detail and statistics, remember that a design document is typically something that will evolve over the lifetime of the game as you build and iterate. It's impractical to think that you'll write it once, up front, and it will be perfect, so focus on what you need the document to convey now and how you can best convey that to the specific consumers of that document.
It doesn't matter what other people do, you want to do what works best for your team.
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.
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