Guide to Writing a Game Design Document

Jukka Haltsonen GUIDE TO WRITING A GAME DESIGN DOCUMENT GUIDE TO WRITING A GAME DESIGN DOCUMENT Jukka Haltsonen Bachelor’s thesis Fall 2015 Information Technology Oulu University of Applied Sciences ABSTRACT Oulu University of Applied Sciences Information Technology, Software Development Author: Jukka Haltsonen Title of thesis: Guide to Writing a Game Design Document Supervisor: Kari Laitinen Term and year of completion: Fall 2015 Pages: 23 + 1 appendix An important part of game design is writing a Game Design Document. Game Designers, who are just starting their careers, and are new to the game industry, are usually not familiar with the documentation process. The purpose of this thesis was to create an example Game Design Document, and a guide about writing one, for Oulu Game Lab to use as a part of their coaching. When this work was begun, it was already known that the game industry does not have any standards for the Game Design Documentation. Several game design related books and web articles were studied, and compared with each other and with personal experiences, to find the most uniform information about writing a Game Design Document. The found information was then used to create the guide. Concurrently with the research, a design of a game was begun and a Game Design Document was written. The work led to a conclusion that a perfect template for the Game Design Docu- ment cannot be created, but the guide works as a good basis for a designer to create a template that suits his needs. The example Game Design Document was not finished during the timeframe of this thesis. For it was found during the research that the processes of designing a game, and writing a Game Design Document are iterative in nature, and need the effort of the whole development team to be completed. Keywords: Game Design, Game Industry, Documentation 3 TIIVISTELMÄ Oulun ammattikorkeakoulu Tietotekniikka, ohjelmistokehitys Tekijä: Jukka Haltsonen Opinnäytetyön nimi: Guide to writing a Game Design Document Työn ohjaaja: Kari Laitinen Työn valmistumislukukausi ja -vuosi: Syksy 2015 Sivumäärä: 23 + 1 liite Dokumentointi on olennainen osa pelinkehitystä, mutta nuorilla pelisuunnitteli- joilla ei useimmiten ole tietämystä dokumentoinnin tarpeellisuudesta, taikka siitä miten se tulisi toteuttaa. Tämän opinnäytetyön tarkoituksena oli tuottaa esimerkki pelisuunnitteludokumentista, sekä opas pelisuunnitteludokumentin laati- misesta, Oulu Game Labin käytettäväksi osana valmennustaan. Tätä työtä aloitettaessa oli jo tiedossa, ettei pelialalla ole olemassa standardeja pelisuunnitteludokumentaatiolle. Työssä tutkittiin useita pelisuunnitteluun liittyviä kirjoja sekä nettiartikkeleita, joita vertailtiin keskenään sekä henkilökohtaisten kokemusten kanssa. Näin löydettiin yhdenmukaisin tieto pelisuunnitteludoku- mentaation kirjoittamiselle. Tämän tiedon perusteella laadittiin opas. Tutkimuk- sen kanssa samanaikaisesti, aloitettiin pelin suunnittelu sekä pelisuunnitteludokumentin kirjoitus. Työssä tultiin siihen johtopäätökseen, ettei pelisuunnitteludokumentille voi luoda täydellistä mallipohjaa, mutta tehty opas toimii hyvänä alkuna suunnittelijalle, hänen omiin tarpeisiin sopivan pohjan laatimiselle. Esimerkkiä pelisuunnitteludokumentista, ei saatu valmiiksi asti opinnäytetyön puitteissa. Sillä tutkimuksen aikana todettiin, että pelin suunnittelu sekä pelisuunnitteludokumentin kirjoittaminen, ovat luonteeltaan iteratiivisia prosesseja. Näin ollen, ne tarvitsevat koko kehitystiimin työpanoksen valmistuakseen. Asiasanat: Pelisuunnittelu, Peliala, Dokumentaatio 4 CONTENTS ABSTRACT 3 TIIVISTELMÄ 4 TABLE OF CONTENTS 5 1 INTRODUCTION 6 2 WHY DO WE NEED DOCUMENTS? 7 3 TYPES OF DESIGN DOCUMENTS 8 3.1 High Concept Document 8 3.2 Character Design Document 11 3.3 World Design Document 11 3.4 Flowboard 12 3.5 Story and Level Progression Document 12 3.6 The Game Script 13 4 QUALITIES OF A GOOD DESIGN DOCUMENT 14 5 CASE STUDY: ANGRY MOBS 19 5.1 Overview 19 5.2 Gameplay and Mechanics 19 5.3 Characters 20 5.4 Game World 20 5.5 User Interface 20 6 SUMMARY 21 REFERENCES 22 APPENDICES 24 5 1 INTRODUCTION Writing a Game Design Document (GDD) is a relevant part of game design, but still many designers do not write one at all, or write it badly. Often the reason for this is that the designers do not have the knowledge of how this kind of document should be written. In many cases, this leads to disorderly and incoherent design, which unfortunately often leads to the failure of the whole project. The idea for this thesis came from Oulu Game Lab’s need to guide new game designers in writing a GDD. There does not exist any kind of standard for the Game Design Document. The structure of the document is affected by the nature of the game being designed, the designer’s personal writing style and the game studio’s preferences. How- ever, all GDDs have some similarities and generally well-tried ways. The aim of this thesis was to create a guide how a GDD should be written, based on the aforementioned generally valid rules. The guide also needed to include an example GDD. For that purpose, a game was designed and the game’s design document was written following the guide. 6 2 WHY DO WE NEED DOCUMENTS? It is common knowledge around game industry that no one ever reads design documents. Then why should such documents exist then? “The documents record decisions made and agreed upon orally; they create a paper trail. More important, the process of writing a document turns a vague idea into an explicit plan. Even if no one reads it at all, an idea written down is a decision made, a conclusion reached. If a feature of a game is not described in writing, there’s a good chance that it has been overlooked and that someone will have to make it up on the fly—or, worse, that each part of the team will have a different idea of what they intended to do.” (1, p. 55.) Schell (2, p. 382) gives two reasons for documents to exist: memory and com- munication. The design of a game is full of decisions that define the game. How it works and why? It is very likely that the designer will not remember them all. If the designer records his design decisions, he will be spared from solving the same issues again at a later time. The design decisions have to be communicated to the development team, and with documents this can be done effectively. When the design is in written form, the other members of the team can review it and will be likely to find problems with it, or have ideas for improvements. (2, p. 383.) 7 3 TYPES OF DESIGN DOCUMENTS It is a common misconception that the Game Design Document has tens or even hundreds of pages, all combined in one giant tome, and the more pages there are, the better the document. This used to be the way back in the day, but nowadays it is more common to split the design into several smaller documents. (1, p. 58). Of course, there may still be hundreds of pages in total, but quantity does not automatically mean quality. More about the subject can be found in Chapter 4. Qualities of a Good Design Document. Several kinds of design documents exist. Which ones should be used and what kind of information they should contain is mostly up to the designer to deter- mine. For a rookie designer, this task may be too overwhelming, though. To help in this endeavor, this section introduces the types of design documents Ad- ams (1, p. 55) considers to be some of the most common ones. 3.1 High Concept Document “A game concept is a description of a game detailed enough to begin discussing it as a potential commercial product—a piece of software that the public might want to buy” (1, p. 67). According to Adams (1, p. 56), the high concept document is like a résumé. Its purpose is to get a hearing from someone, usually from an investor. It explains a game concept in a short manner; not more than two to four pages. The document should include at least the following nine key points (1, p. 67): 1) High Concept Statement High concept statement describes in just a few sentences what the game is about. References to other media that utilize similar ideas, can be used. (1, p. 67, p. 83.) 8 2) Player role The description of the player’s role in the game. Is the player pretending to be someone or something? Is there more than one role? How does the player’s role help to define gameplay? If the player has an avatar character, it should be described briefly. (1, p. 67, p. 83.) 3) Gameplay The primary gameplay mode is the one that should be described in this section, along with any competition modes the game will support (single- or multiplayer; competitive or co-op). (1, p. 68.) Adams (3) describes a gameplay mode as “a particular way of playing a game”, which consists of three elements: Perspective, interaction model and gameplay. Perspective Means of perceiving the game world. Defined by a camera looking at 2D or 3D space from a particular point of view. Interaction model Means of influencing the game world. The most common ones are the avatar-based model (used in most action games and platformers) and the omnipresent model (used in most board and war games). Gameplay The challenges the player faces and the actions he/she can take to over- come those challenges. If one of these elements changes significantly during the play, then the player moves into another gameplay mode. The primary gameplay mode is the one in which the player is going to spend most of the time. (3.) 9 4) Genre In which genre the game belongs or, if the game is a mix of genres, which fea- tures it contains from the different genres to which it belongs? If the game does not fit into any existing genre, an explanation of why not, is required.

Load more