Game Design Document
|
My week has entirely been focusing on the Game Design Document for the game we are making, Ambient Pressure. Though I was, initially, fairly confused regarding its layout, it came together easier the more time I spent on it. I’ve had to rewrite several times because of a change of approach, and truth to be told I still feel that I might want to change things in it. But then again, I have been told that the document is bound to change over time anyway, so I guess that is a given.
When creating the layout, I’ve had the intention to satisfy the need of the group; if any member of the group, at any point, is unsure of anything, the Design Document should be their guide. As such, I have attempted to be as clear, simple and concise as possible, without going too much into detail. It is designed for the team in order to clear any misunderstandings. The Game Design Document should be:
With this in mind, I separated all parts of the document into the building stones of the game: Avatar, Enemies, Levels, etc as well as categories for anything that did not logically fit into those, such as Game Modes, GUI and Game Rules. All intended to simply search and understanding.
A flowchart describing the hierarchy system of all the screens in the game.
Being a document for the entire team, it was vital that both programmers, graphical artists and level designers could read and understand the entirety of it. It includes several bullet point lists to show not only what artifacts need to be completed, but also what all of these different parts mean. It includes tables to show differences between the states of each enemy, and between enemies as well. It includes flow charts to describe the the reaction of every action. However, noted as it shall, bodies of texts are not excluded. Neither should they, as in many cases detail can only be achieved accurately when properly described. As a rule of thumb, most justifying of design choices were written in bodies, as well as introduction texts of any artifact. This makes each chapter easy to grasp and understand, and if the group at any point come to question part of the design, the justifying text will accurately describe the design choice without being confusing.
However, it is not finished. Still there are questions to answer – some of these can only be seen when testing. In many ways, the document feels incomplete. But, finding no workaround, I decided to go this way in order to simplify it. Designed this way, the document will be easy to change should the need come at any point. And I think that is what is going to make it useful in the long run.
David Crosson  |
