Castle Paradox

[Rinku]

i'm posting this excerpt from my livejournal. i write most of my game design notes there, so if you like this you know where to find more (link's in my signature). also, ohr monthly and reasonably septaweekly are still up at http://heroists.cjb.net/septa/ and there's still a bunch of stuff there.

~

design documents for games notes

my aim is to collect my knowledge of design documents for games here.


*on why one should have one at all*

a game needs a design document just as a building needs a blueprint: both fall without one.

it's possible to keep the blueprint in your head, but only for very simple games, and also only for things like mud huts or perhaps wooden cabins. but for skyscrapers and complex games, you need to put it on paper because it's too big to keep in your short term memory all at once, so you need the written part as a que -- the main part still remains in the head but the written part operates sort of as handles to coffee mugs.

when more than one or two people are working on a game it is particularly important to have a full design document because the other members of the team can't go inside the head of the designer when they need to know something about the game -- well they can but it would save a lot of talk (just like a faq saves a lot of repeat answering of questions). again compare to architecture: the construction team needs the blueprint to be fully accurate and complete because they can't build the building based on what's in the architect's head.

the purpose of the document is as a tool to make the game, and though it's indispensable for most good games it shouldn't be written as if it were an 'end in itself'. it should be clear but it doesn't have to be written well or to have perfect spelling, and it doesn't have to be written so it'd make sense to any random person, it's written so it makes sense to the people who will be making the game. if abbreviation and shortcuts can be used without any loss of meaning, that's fine.


*on the importance of measurements*

many design documents i've seen have just been summarys rather than blueprints, i dislike that because they tend not to be specific, and not to use actual numbers and measurements. blueprints for houses don't say 'this side of the house is longer than that side of the house' or 'you won't bonk your head on the ceiling', they say 'this wall is 6.700 meters long' and 'the ceiling is 3 meters above the floor'.


*on format*

the way i like to write design documents is to use html files. i have one index page, which links to most of the other html files. the index page also includes a changelog for what was added to the design document (and once the game begins production, what parts are and are not implemented).

i keep the data and the process aspects seperate: i usually have two columns in the index page, one for data (story, graphics, music, conceptual art, etc.) the other for process (gameplay).

i also, in alterpoint, tried the idea of writing an abstract: a relatively short description of the game, equivalent to those abstracts in scholarly papers. the abstract is an abstract-level description of the game, short, i'd guess around 5%-10% of the design document's size.


*on what should be in it*

everything. if there are monsters, there should be a complete list of them, with narrative descriptions and information that's important about them, in numbers. if there is dialogue, and if the designer is writing it, the complete dialogue can be in the design document word for word. but all data files that will be needed (music files or etc.) should be mentioned and given filenames in the document.


*on its ability to change*

but all of that detail doesn't mean you shouldn't change any of it once it's written: if while making the game you want to add or remove or change something, you can do that, but first change it in the design document, then in the game. i.e. the design document isn't a static document on paper, it changes as the designer's vision of the game changes. it might change drastically between its first 'finished' version (i.e. the version at which you begin game production) and the final version of the document when the game is released.


*on what shouldn't be in it*

the data and the code itself shouldn't be in the design document: only plans for what data and what code will need to be made goes in it. conceptual art can be used to illustrate the design document if it helps, but actual game art shouldn't be in it. this is because it's important to keep a good distinction between plan and production, otherwise you might not know whether you're working on the game itself or working on its design.

the exception, as mentioned, is dialogue, the reason being that dialogue can be thought of either as part of the game design or as part of the game production -- depending on if the game designer is also the writer. (dialogue refers both to what characters say to eachother and to what the game says to the player, i.e. as instructions or narration.) another related note is that dialogue/text is kind of hard to summarize; with text it's often just as easy to write the data itself ('player, you have been selected to join the human defense force') as it is to describe that data ('now the game tells the player that he or she has been selected to join the human defense force').


*time spent writing it and its value relative to production*

i actually think that the time spent designing the game and writing the design document should be at least equal to the anticipated production time. if a game is going to take a year of hard work to make, it needs a year of hard work to write its design document as well (for a total of 2 years). if anything, the design time can be longer. the novel 'ender's game' for example (one of the best novels ever written), was planned in detail for over a year and then written in two weeks. there are other similar examples.

designing a game and producing a game are both equally important but the design part is way too often undervalued; sometimes a team has a vague idea of a game and gets to work immediately, and since they don't know what they're making it fails to be good or even to be finished.

if a game is going to be original and super-great, it's at the design stage that this is determined. an average production team with a great design can produce a near-great game, but a great design team with an average design gets you a game that's really polished and pretty but still average.


*should a game be designed by a team or by one person in the cases where a team produces the game*

i think now that good games benefit from suggestions by the people who will be making the game, so that ideally the team should be selected before the design document is begun, and everyone on the team would periodically look over the design document as it's being written and make suggestions, so that when it's time to begin production everyone on the team is familiar with the design document and probably each has added to it in some way.

but even though these suggestions are great, the designer should still always be one person, who has the final say on what goes into the design or not. the lead designer has to be ruthless about what is good and isn't good for the game, and can't accept any suggestions unless he/she really thinks the suggestion works, even if he/she stands at times alone against a tidal wave of opposition.

the design document should also probably name everyone on the team and name each of their domains: who will be responsible for making what. it has to be as clear as possible here, so everyone knows what their job is, and so there's no overlap in duties. this would cut out the majority of bickering before it has a chance to arise in the production stage.


*timeline?*

the design document also may or may not have a timeline -- if the game is commercial it should definately have one, but non-commercial independent games probably also work best with timelines, it's just that there is now no penalty for breaking that timeline (except wasted time). or the timeline might be seperate from the design document (in one videogame company i visited as a field trip in high school -- absolute entertainment, makers of 'a boy and his blob' -- the timeline was on a wall, as a huge chart many square feet in size, with every game element having a due-date, and a checkbox, organized by each person's name).


*storyboards?*

no, no storyboards. storyboards work for movies and for comics and for tv shows, but applying them to games, even though it's done a lot professionaly and is even taught at most game design schools, is silly because games aren't supposed to be linear, and using storyboards traps them into being linear.

the exception might be for the introduction to the game and the ending(s) to the game. those having storyboards are okay, especially if you plan to use full motion video for them.
_________________
Tower Defense Game

[TMC]

Wow, that's really helpful. I have to have a look at your LJ, rinku.
_________________
"It is so great it is insanely great."