This chapter proposes and experiments alternatives to replace or optimize the use of the game design document (GDD). The creation and development of a game is accomplished by relying on the GDD, which contains all the information, such as the script, mechanics, and relevant details, so the team can use as a guide. There is no exact formula for creating a GDD, and several formats are proposed and used nowadays. Information misinterpreted or misunderstood at different levels of responsibility can create irreparable problems after the start of production. This chapter proposes the use of analog prototyping associated with benchmarking techniques and agile development as efficient alternatives to GDD, which are tested in the development of the game Forsaken Dungeons, created by one of the authors.
TopIntroduction
This chapter analyses a set of methods used as efficient and economic alternatives to GDD topics and digital prototyping, to increase the team efficiency, organization and communication. The game design goals and topics are commented on (CRAWFORD: 1982, 49-50): ‘A game must have clearly defined goal. This goal must be expressed in terms of the effects that it will have on player. It is not enough to declare that a game will be enjoyable, fun, exciting or good; the goal must establish the fantasies that the game will support and the types of emotions it will engender in its audience. (…)Once you have settled on your goal, you must select a topic. The topic is the means of expressing the goal (…)’
To achieve the goal of developing a game based on the efficiency and economically principles it is assumed that a coordinated set of development techniques and documents are valuable among which we mention benchmarking; analog and paper prototyping; user retention and monetization documents. In addition, it is important to apply agile and vertical improvement techniques during the project development.
The game designer can be defined as the professional who determines the gameplay basic guidelines of the product and the development methods that will be used to produce the final product by the development team (ROUSE: 2001, 18) states that ‘at its most elementary level, game design consists of inventing and documenting the elements of a game.’
Jesse Schell shows that the game designer must cultivate many skills, ranging from knowledge in technical writing to mathematics (Schell, 2008: 2-4). The designer will use every skill he has to communicate the ideas and to reach the conclusion of the project with minimum expenses and maximum result.
The first phase of a game development starts before programming, art, marketing or any other subject related to game development. The game designer is responsible for planning the product development strategies, goals and topics, before even involving other professionals. (CRAWFORD. 2016, pg. 51) says that ‘during this phase it is critical that you commit little to paper and above all, write no code! (…) You will generate during this phase a great variety of specific implementation ideas for your game. They will not all fit together neatly (…). Indulge yourself in creating implementation ideas, but be prepared to winnow the ruthlessly during design.’
To Ernest Adams, ‘a game is designed by creating a concept and identifying an audience in the concept stage, fleshing out the details and turning abstract ideas into concrete plans in the elaboration stage, and adjusting the fine points in the tuning stage (…).’ (ADAMS: 2009, 62). Rouse points that ‘in many ways, developing a game is all about understanding your limitations and then turning those limitations into advantages.’ (ROUSE: 2001, 47-54)
The construction of a digital game depends on the teamwork of a diverse crew with a wide range of technical skills. One of the most delicate parts of development is the efficient and cost-effective use of each member effort. The team must seek a scenario where the professionals work with functional independence and their performances are not limited by product scope, harmonizing each personal set of skills in order to create a coherent product. As observes Rouse, the development team must be organized to divide the product in parts and build the game incrementally. ‘Instead of working a little bit on all the different components of the game, you should try to complete one system before moving on to the next. Work on the most basic and essential systems first, and then build the systems that depend on that system. This allows you to implement a system, test it out, see if it ‘feels’ right, and only then move on to the next system.’ (ROUSE: 2001, 254)
Tracy Fullerton (2008: 188) points out ‘if you try to design the entire game at once, you might become confused and overwhelmed. There are so many elements in a typical game that it is difficult to know where and how to start. What we recommend is that you isolate the core gameplay mechanics and built out from there.’