How do you work? [Possible guidelines of design documents]
Author
[What is this thread goal?]
I try to improve my GD quality and workflow with a general work template.
Answer Template (recommendable):
[What is wrong]
- Topic that is abolutely wrong and should be changed entirely. Criticize here. Please argumentate your choice and, possibly, give a workaround for it.
[What is right]
- Topic that is somehow good but can be improved. Share with us your possible inonvations.
How do I work?
- Concept document (Establish a vision)
o Game setting
o Gameplay vision
o Real life concepts which we want emulated
o Central elements of gameplay
o Concepts from other games
o Bad implementations of each concept – explain the flaw
o How are you going to fix the flaw
o New concepts/implementations introduced
- Working Procedures (general or area specific guidelines or checklists to be used during the development process. A QA document for game designers).
o Put everything on paper. Cut to minimum, no redundancy. This leads to much clear concepts, possibly not overlaying.
o Design systems to make the work equally spread over programmers, designers and artists. (A data driven engine maybe?)
- GDD (the actual game design document)
o Design Objects
* Menus
• Menu elements
* Environment/Static Objects
* Gameplay objects (including theoretical ones)
o Behaviors (for all gameplay objects)
* States
* State flow
* Input
* Output
o Gameplay levels of choice (military and economic strategy and tactics are instanced levels of choice for a RTS genre)
o User Interface
* Controls
* Camera
* HUD
o Level design
* LD palette
* Gameplay loops
* Uniqueness of each level interaction
- Assets requirements table (the actual assets that should be created for a game object – very useful for producers)
o Visual
o Audio
o Game specific
- Game constants (it’s great to have all game constants in a single place so you can chance them easily. The GDD should reference them by name and never by value – i.e. player movement speed, hurt player movement speed…)
Feedback greatly appreciated. :)
PS: Sorry for look but somehow the html codes are not working.
[Edited by - Codman on April 7, 2006 4:34:22 AM]
having written a number of templates for various game design tasks I have to say that they can be a sword that cuts two ways. on the one hand they do make the process faster and easier, but on the other hand a too-concise template leads to your designers just filling in the data thereby possibly omitting important stuff simply because it wasn´t mentioned in any of the categories.
personally I prefer more open templates that force you to create a lot of the structure yourself, since only then the structure of the doc will fit your project.
personally I prefer more open templates that force you to create a lot of the structure yourself, since only then the structure of the doc will fit your project.
Author
I know that. Notice I try to use only very generic chapters so creativity has no constraints (or at least just a few) - you can make minor changes accorgingly to project :)
The term workflow implies that you want to know what order the various steps to design a game should be done in, but your template doesn't have any numbers, is it supposed to be in any kind of order? Also what do you mean by game setting, and I don't see any steps having to do with designing the plot and characters?
I describe a suggested workflow for designing the concept document of a story-based game in my book-in-progress about how to design games, but it's nothing like your template.
I describe a suggested workflow for designing the concept document of a story-based game in my book-in-progress about how to design games, but it's nothing like your template.
as a general list of things to think about it seems pretty useful, although especially your concept workflow doesn´t seem very production oriented. Most of my concepts are not so much describing "visions", but rather outlining the key elements of a game in such a way that a bunch of managers (who are usually to be classified as non-gamers, and in some cases as non-computer-people) will understand what it´s about in less than five sentences.
Or that they´ll understand it by only reading the summary at the beginning and by looking at the colorful pictures (which happens more often than not).
In addition to that the people who are going to be involved in production should be able to do rough effort estimations based on the concept, so at least some amount of detail regarding required assets should be there (levels, general level design principles, graphical themes, required and optional technology, etc.)
Or that they´ll understand it by only reading the summary at the beginning and by looking at the colorful pictures (which happens more often than not).
In addition to that the people who are going to be involved in production should be able to do rough effort estimations based on the concept, so at least some amount of detail regarding required assets should be there (levels, general level design principles, graphical themes, required and optional technology, etc.)
I would say with the concept document that you want to pay more attention to selling the game - you need to provide information on format, target audience, etc. - since there's a high likelihood the audience will be management/marketing who care about these sort of things a good deal more than the gameplay elements (sad as that is!).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
