Ad blocker interference detected!
Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers
Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.
What is the purpose of a game design document?Edit
The primary goals of a game design are to (1) excite and (2) inform the reader. First paragraph must excite the reader and make the reader want to read more of the first page. The first page must be interesting, concise, and informative, and must make the reader want to read the remaining pages. When the reader has finished reading the entire design, if the reader does not have a clear understanding of what you want the game to be, you have failed to communicate your vision of the game.
The game design document is also used to relay information to your content builders. A proper design document limits the downtime for production by answering a lot of questions that would come up and by ensuring that the team is communicating from the same source. You should be able to direct what projects need to go to who, and with enough documentation you can even predict the amount of time it will take your team to develop the module.
The final thing thing that the game design document does which may be the most important thing is fleshes out your ideas. If you attempt to start a project without having done this, you increase the odds of mistakes, and miscommunication from team members. Even if you're partaking in constructing a module solo, this document will save you time in the long run by limiting the amount of time you spend backtracking to add stuff in.
This is by no means a standard in the NWN2 community. It has been provided to the community however in hopes that people utilize it to flesh out their ideas and to help them advertise for getting a team together.
- Description - (Describe the server in one paragraph. This paragraph should be exciting and contain enough detail to get people to read further, but be concise)
- Overview with a bit more technical detail (Scripts, sub-systems, GUI's, Custom content no need to get specific but explaining how they relate overall is a good thing. Through the use of illustrations and word pictures, walk the reader through the main points of the gameplay, focusing on the important aspects of the game which need communicating since they would not be apparent or are a subtle aspect of the game).
Wrapping Up the BasicsEdit
After the reader has gone through the first section, s/he should have a clear idea of what the game looks like, how the story progresses, and how fun it will be to play this game. Properly done, this section should lightly touch on both technical and game play elements and give the reader a sense of knowing how they are going to approach playing the game. You should be able to use this first section as a reference point to help you fill out the rest of the document when it's finished properly.........?
Detailed Game DescriptionEdit
- Basic Concept -- What is the "high concept" of the game?
- Background Story - If applicable, tell the story of the game that leads into the beginning of the game, and tell the story that unfolds during game play.
- What is the tone? What is the basic narrative? What is the "heart" of the story? Is it a linear story?
- Objective - (Describe the main goal players are attempting to achieve)
- Gameplay - Describe the way the game works, from beginning to end (This can be as descript as you see fit. Keep in mind that your potential team members will reference this and more info is better than less.)
- Describe the opening scene when the game begins and what happens afterwards. If nothing happens until the user does something, describe what the user's options are and what happens as a result of all possible actions. Keep in mind that most games to some extent are controlled by the user. The hero doesn't automatically do anything; the user, when playing the game optimally, might cause the hero to do such-and-such an act, which would cause the computer-controlled enemy to do this, and the user's options are to do X and Y...
- Describe the racial relations between PC races if any.
- Describe your monster palette (main monsters, secondary, tertiary and how they relate to each other, if any relations exist)
- Primary - (Usually reserved for the main group/s of enemies and villains in the module)
- Secondary - (Secondary monsters would be integral to other parts of your module, but not part of the main groups)
- Tertiary - (Usually reserved for solitary creatures, animals and other unorganized or unimportant creatures)
- What is the basic interactive structure? (e.g. Chapters vs. Great Middle Section, Levels, etc.)
- What is the "heart" of the gameplay? (e.g. speed, actions, style, continuous, turnbased, etc.?)
- How does partying work (xp wise, will quests be given to all party members if one person gets it? Item rewards?)
- How do players enter encounters (triggers, pre-setup per area, are they respawning or one shot, etc?)
- How will quests be implemented in this module (Will they be class restricted, party implemented, one shot, repeating, story driven? Whatever the case be describe it in plain terms.)
- Primary (What are your main set of quests and their purpose?)
- Secondary (Do you have quests unrelated to the primary set, if so what are they?)
- Describe the difficulty of your module from beginning to end?
- Estimate how long it will take for a player to finish the module.
Summary of the DetailsEdit
By now, the reader should not feel as though they don't understand your direction. Not only can they figure how they would play the game, but if they have the basic building knowledge they should have a sound idea on how they would tackle implementing the systems you described above. This is the solidity of the design document. From this section you should be able to look back at the General Information Section and see a direct connection from one to the other. If you have differences in descriptions between the two sections, or one section has something the other lacks you should amend them until the first summarizes and the second describes the summary further..
The Extra DetailsEdit
- Characters (Describe the main or important NPC's of the world)
- List your Areas(Describe the areas of the world and what NPC's can be found there)
- Scripting and Subsystems (Describe what custom scripts you will need to create or will be using from the community.)
- GUI - (Describe any community GUI's you will be using, or any custom GU's you are planning)
- Custom GUI Details - (If you are creating custom GUI you should explain fully what you intend them to do, the original authors should have documented what GUI you have used of theirs.)
- Onscreen text messages: (Describe the messages you will use to inform players and DM's of happenings)
- Floating Text - (If using floating text describe how you intend it to be used)
- SendMessageToPC - (describe how you will make use of this function related to debugging, players and DM's)
- Conversations - (Describe any special conversations you will use or need)
- Art and Visual - (what art and visual effects will you be using)
- Sources for Art/Visuals - (give credit to those that deserve it)
- Sounds and Music (Describe what sounds and music will be used to provide ambience)
- Sources for Sound/Music(give credit where credit is due)
Hooray for Progress!!Edit
You should be done now and ready to present this to your team and reference this document if you ever forget what you need to do. By now the document should read smoothly, starting with a solid introduction, a more detailed description of your world and mechanics and finishing with a summary of the scripts, subsystems, and custom content that you need. Congratulations! You have finished the easiest part of the production process.