Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualMratthew

Posted 21 April 2013 - 11:27 AM

I find my documents tend to change from game to game to accommodate the design focus and the team I'm working with.

 

Like any writer, I start with a creative document (most of the time I use a Microsoft Office Outlining [View>Outline] ) like point form or a story web or even a collage just to get the ideas someplace for me to recall and rework them if need be.

 

Next I move onto my design brief. This is a document that works like the conversation you have with people when they ask you what you're working on. If you start this part as part of a development blog then you can actually answer people with the link to this document. Make sure this document lives up to its description. One paragraph or two and don't worry if people compare your game to other games at this point. (Only worry if they compare it to bad games ;)

 

Last is the main document, start with focusing on parts of the game you can't or won't be building. Its important your team has direction first. Then shift gears and work towards the areas of the game that will be earlier milestones (as you indicated your game would have a focus on how the AI reacts). Next focus on the parts of the game that have any emotional connection with the player and then "finish" the document for the dev team so that when they ask "Can I read the design document?" you won't need to tell them its a work in progress. No design document is ever really finished. Even post launch changes are encouraged. But having a document with a beginning, middle and end for the dev to keep as their bible is important. All members of development should have access to all aspects of this design document because a game is entirely interconnected and having all the teams eyes scouring the design for early bugs is important.

 

Once you are in development, make your document illustrated. Keep it updated by inserting all the concept art, screenshots, videos and fan art, so that the dev team always has a reason to look back at it. This keeps your document the end all be all go to for anyone on the team. Teach you team how to navigate it and tricks to search and narrow down answers to questions they may have along the way. If you've done it right your team will have days where they don't seem like they've gotten anything done and when you ask they'll say, I spent a bunch of time reading through the design document. JLW is right, Chris Taylor's template is where I started as well. Hope this helps.


#1Mratthew

Posted 21 April 2013 - 11:26 AM

I find my documents tend to change from game to game to occomadate the design focus and the team I'm working with.

 

Like any writer, I start with a creative document (most of the time I use a Microsoft Office Outlining [View>Outline] ) like point form or a story web or even a collage just to get the ideas someplace for me to recall and rework them if need be.

 

Next I move onto my design brief. This is a document that works like the conversation you have with people when they ask you what you're working on. If you start this part as part of a development blog then you can actually answer people with the link to this document. Make sure this document lives up to its description. One paragraph or two and don't worry if people compare your game to other games at this point. (Only worry if they compare it to bad games ;)

 

Last is the main document, start with focusing on parts of the game you can't or won't be building. Its important your team has direction first. Then shift gears and work towards the areas of the game that will be earlier milestones (as you indicated your game would have a focus on how the AI reacts). Next focus on the parts of the game that have any emotional connection with the player and then "finish" the document for the dev team so that when they ask "Can I read the design document?" you won't need to tell them its a work in progress. No design document is ever really finished. Even post launch changes are encouraged. But having a document with a beginning, middle and end for the dev to keep as their bible is important. All members of development should have access to all aspects of this design document because a game is entirely interconnected and having all the teams eyes scouring the design for early bugs is important.

 

Once you are in development, make your document illustrated. Keep it updated by inserting all the concept art, screenshots, videos and fan art, so that the dev team always has a reason to look back at it. This keeps your document the end all be all go to for anyone on the team. Teach you team how to navigate it and tricks to search and narrow down answers to questions they may have along the way. If you've done it right your team will have days where they don't seem like they've gotten anything done and when you ask they'll say, I spent a bunch of time reading through the design document. Hope this helps.


PARTNERS