Content uploaded by Vinicius Cardoso Garcia
Author content
All content in this area was uploaded by Vinicius Cardoso Garcia
Content may be subject to copyright.
Game Development Guidelines: Practices
To Avoid Conflicts Between Software and
Design
Tiago Lemos de A. Machado¹, Geber L. Ramalho², Carina F. Alves², Vinicius C. Garcia²,
Luiz F. Araujo¹, Vamberto Lemos¹, Vinicius Cavalcanti F. Gomes¹, Anderson P. Silva¹, Gutenberg
Xavier da S. Barros¹
¹C.E.S.A.R – Centro em Estudos de Sistemas Avançados do Recife
²Centro de Informática - Universidade Federal de Pernambuco
Abstract
The game process is guided traditionally by the Game
Design Document, a document which contains all the
necessary info to support the team through the game
development process. The Game Design Document
contents is insufficient, starting a conflict between game
designers and programmers. This work aims to study the
game development process and recommend guidelines to
reduce the conflicts between the Design and the Software
development phases.
Keywords: digital entertainment, electronic games,
process and software development methodologies, game
design
Authors’ contact: {tiago.machado, luiz.francisco,
vamberto.lemos}@cesar.org.br
{glr, cfa, vcg}@cin.ufpe.br
{vinicius.fabrino, dinhoaps, gutenbar}@gmail.com
1. Introduction
The game development process involves three main
phases: game design, where the main concepts of the
game are defined; game production (including both
programming and sound and graphic art); and game test
and refinement. The design phase generates the Game
Design Document (GDD), the most important asset to the
production phase.
At the beginning of the game industry, the development
process was rather experimental and ad-hoc. As the
consumer market became more exigent and time-to-
market harder, it was necessary to improve development
process. Various processes have been proposed to the
code programming [Bakie R.T., 2005], and some
processes for the game design [Schell 2008] and art
creation [Fullerton et al. 2007]. However, to our
knowledge the literature has not yet discussed in depth the
relationship between the design and the production
phases.
The lack of processes, or at least, good practices,
in-between design and production is an issue indeed.
Nowadays, if the same GDD is sent to N different
production teams, it is highly probable that one will get N
different games. In fact, the task of extracting information
of the Game Design Document to support the software
implementation is still very time-consuming and generate
conflicts, due to misinterpretations and ambiguities of the
GDD.
This study aims to get a better understanding on
the cooperation between game designers and
programmers, including the conflicting views, as
well as, to suggest some guidelines to improve
productivity.
The rest of the paper is organized as follows. Section 2
discusses related works, sections 3 presents the
methodology, section 4 explains the guidelines obtained
as results of this work. Finally, section 5 concludes the
paper.
2. Related Work
Some efforts have been made in order to facilitate the
information flow of the design and software phases,
Souza and colleagues [Souza L. et al. 2009] work
exclusively in identify incoherencies in the GDD,
suggesting an extra effort in the development and
evaluation of techniques which can describe the GDD
content in a better way.
Other researchers [Calele et al. 2005] focused in
investigating the difficulty of collecting requirements for
games through the available information in the GDD. The
author mentions that depending on who is responsible for
the activity of analyzing the document, the requirements
can result in different games. The study took as basis a
session dedicated to dealing with problems in the
development of the Game Developer Magazine [Game
Developer Magazine 2009]. One of the alternatives
SBC - Proceedings of SBGames 2010
Computing Track - Short Papers
IX SBGames - Florianópolis - SC, November 8th-10th, 2010
288
proposed to reduce such problems is greater investment in
pre-production to create resources like prototypes and
game architectures to help in the task of identify the game
requirements. Later the author publish a complementary
work, focused in maps the user response face to Non-
Funtional Requirements [Calele et al. 2006].
As in the gaming industry, the film industry also has its
processes governed by a document: the screenplay
[Bergan 2007]. The passage of the information described
in the screenplay for what is seen on screen occurs with a
higher investment in a stage of pre-production, advocated
as necessary in developing games [Calele et al. 2005]. In
this stage several resources are generated such as
storyboards and art concepts that enable the movie
director and production crew evaluating the best ways to
record each of the scenes contained in the screenplay.
Another study [Alves et al. 2007] addresses the
challenges of creating the GDD and its implications for
the Requirements Engineering. Throughout the study, a
game was used as example to discuss the difficulties to
generate a coherent GDD. The GDD can be compared to
a requirements document. However, it has many creative
elements as part of its content that create conflicts when
these info need to be turned in software code. Another
problem is that the GDD is not as standardized as the
requirements document or the screenplays [Bergan 2007],
what implies in more conflicts because it increases the
number of different interpretations.
The results of these works suggest that there are a great
interdependence between game design and software
implementation. But we can observe that authors
preferred to concentrate the analyze in the GDD content
or in the Requirements stage. The originality of our
approach is to focus on the design-software conflicts.
3. Methodology
The methodology of the study was divided into the
following phases.
3.1 Literature Study and Semi Structured Interview
This phase involved research of studies related to game
development in the areas of Software Engineering and
Design Methodologies. Based on the studies we defined a
small set of issues for a number of semi-structured
informal interviews. The objective was to extract opinions
regarding how the research’s subjects consider that could
be good alternatives to solve conflicts of the GDD Vs
Software Game implementation. This study was
conducted in three game companies of Porto Digital
[Porto Digital 2010] and through a UFPE group of game
development [UFPE 2010]. The result was the generation
of a survey based entirely on knowledge acquired with the
interviews and the literature study.
3.2 Survey
The survey was generated to reach a greater number of
participants. We collected quantitative data related to
conflicts in the game development process of the national
or international game industry and of the members of the
research centers.
3.3 Analysis Methods
For our data analysis, was used a mixed methodology:
based on both qualitative and quantitative methods. This
principle of analysis has been well accepted in generating
alternatives for production software [Sedig et al 2001].
The qualitative analysis was generated entirely from the
views provided by participants in the survey. We used the
assistance of NVivo software [NVIVO 2009] to facilitate
the catalog of the qualitative data provided by the
research participants of the semi structured interview. We
opted to follow the free node coding technique discussed
in the literature [Flick 2004] to define the quotations
characteristics based on the patterns between the created
nodes. The quantitative analysis was based on the entire
sample and the data auxiliary sample groups (national
industry, international industry, university).
3.4 Characteristics and Experience of Participants
38 people participated in the quantitative study, all
involved in some way with the production of electronic
games, whether in academia or industry. The vast
majority of participants [Table 1] focus on activities
related to Design (26%) and Programming (34%).
Table 1: The quantitative data related to the role of participants
3.5 Profile of Participants
As for the experiment, the vast majority of participants
has between 3 and five years of experience (32%) or less
than one year (29%). Almost half of that percentage are
the more experienced members of our research, with more
Role
N
%
Game Designer
10
26
Producer
5
13
Programmer
13
34
Artist
4
11
Software Engineer
3
8
Other
3
8
SBC - Proceedings of SBGames 2010
Computing Track - Short Papers
IX SBGames - Florianópolis - SC, November 8th-10th, 2010
289
than 5 years of experience in the game industry (13%).
The other 26% of participants has between 1 and 3 years
of experience.
4 Guidelines
The results of the study are presented in the form of a set
of guidelines [Sommerville and Sawyer 1997]. Guidelines
are widely used in the gaming industry to solve Design
problems. An example of the efficiency of use of
guidelines in game design is the study developed to guide
designers in developing games for Augmented Reality
(AR) [Wetzell et al. 2008]. The use of guidelines in
Software Engineering is also very extensive and active in
almost all areas. In the book Requirements Enginnering -
A Good Practice Guide [Sommerville and Sawyer 1997].
The authors describe a several guidelines to improve the
requirements practice in software companies..
4.1 Guidelines Presentation
The guidelines will be presented according to an
adaptation of the structure showed by [Sommerville and
Sawyer 1997]. It also includes techniques presented in the
Disney Creativity Strategies [Mycoted 2010] related to
content media creation.
4.2 Guidelines List
This section presents the guidelines to minimize the
conflicts between the design and development phase.
#1.Game Designer Participation during all the
Process.
One of the most recurrent replies from participants was
related to the importance of having the Game Designer's
presence during all the phases of the development
process. Approximately 82% of all the participants agreed
that designer´s presence is vital to ensure the success of
the project as reveals the following quotations:
"Yes, there are critical moments... Preparation
of prototypes (evaluation of prototypes and what you aim
with it) for example…
"the presence of game designer is fully necessary in the
beginning (to evaluate planning) and in the end (to
evaluate fine adjustments, balancing …)
#2. Game Overview
From the elements that compose a GDD [Schell 2008] the
overview of the game was considered the most important
artifact in the early stages of developing the game.
Approximately 97% of participants of the survey defined
the game overview as the most significant item [Table 2]
to start the game development.
"... If this view is not clear, problems will surely come
later on ... "
"Game Designer (or those responsible for Game
Design) should act proactively to ensure that the
overview of the concept becomes increasingly clear and
uniform in the minds of everyone involved in the project
life cicle…
Table 2: Focus on Overview (High Concept) of the Game as the
most important item for the beginning of
development process
Game High Concept
97%
Characters
55%
Items
30%
Level Design
30%
Game Flow
82%
Game Controls (Commands)
85%
Art Line
30%
Screens (menu, game title, game over, etc.)
30%
Soundtrack
3%
Sound Effects
6%
Game Rules
88%
Score Rules
61%
Competitors Study
21%
References (books, movies, etc.)
48%
Theme (Philosophical Idea)
27%
Genre (Puzzle, Action, RPG)
73%
Another
12%
Global sample = 38 participants
# 3. Create Direct Communication Channel With The
Game Designer
Although all the details contained in a GDD and all care
in subsequent revisions of the text that compose it is
common in many situations that the programming team
has doubts about implementing some specific
functionality of the game. Many of the survey’s
participants (approx. 87% of the global sample) indicated
that the best way to solve those doubts is headed directly
to the Game Designer. Many claim that the search for him
occurs through the normal tools of communication like
instant messenger softwares, emails and VoIP.
".. It would be interesting to have a system to
manage the requests / changes to the GDD. Hence the
G. Designer works on the basis of requests from
developers…
SBC - Proceedings of SBGames 2010
Computing Track - Short Papers
IX SBGames - Florianópolis - SC, November 8th-10th, 2010
290
#4. Preplanning for Conflict Resolution
The production of the game software as well as the
production of other types of software is permeated by
conflicts. For the technical part, these conflicts often arise
because of insufficient technology to treat any particular
requirement, or by failures of implementation the same or
incomplete documentation. A key problem indeed,
according to participants of the survey concerns the
experience that the game design is proposed to offer. To
reduce this kind of conflict, the participants pointed two
ways: focus on production or focus on design.
Focus on production - this approach makes all the
decisions of conflict based on issues relating to meeting
deadlines and verification of the stakeholders.
"Normally it follows the GD. But who decides is the
producer because he is ... who controls the planning and
priorities of the team."
Focus on Design - this approach makes decisions based
on the experiences which the game intends to offer to
the player.
"The document is constantly adjusted because of
reasons such as cost and scope, but the power of
decision is always of the Game Designer. The Game
Designer is in charge of deciding what is best for the
game. "
5. Conclusion
In general, considering the data obtained from the study,
the practices to reduce conflicts between software and
design must receive a higher investment in preliminary
game process phases, particularly to align all the team
view related to the game project. The presence of Game
Designer during all the process is encouraged as the
investment in methodologies which focus on associate
game design contents with game software components.
Further, an effort in the creation or adoption of tools that
increases the communication among the team is also
necessary, to maintain designers and programmers
working in a strong collaborative way.
References
ALVES, C. RAMALHO, G. DAMASCENO, A. 2007.
Challenges in Requirements Engineering for Mobile
Games Development: The Meantime Case Study. Univ.
Fed. De Pernambuco, Recife;
BAKIE, R.T.. A Brief History of Video Games. Introduction to
Game Development. 2005.
BERGAN, RONALD. Guia Ilustrado Zahar cinema / Ronald
Bergan; Tradução: Carolina Alfaro. – Rio de Janeiro: Jorge
Zahar Ed. , 2007.
CALELE D, NEUFIELD E., SCHNEIDER K., 2005.
Requirements Engineering and the Creative Process in the
Video Game Industry, Proceedings of the 13th IEEE
International Conference on Requirements Engineering,
p.240-252, August 29-September 02, 2005
[doi>10.1109/RE.2005.58]
FLICK, U. 2004. Uma introdução à pesquisa qualitativa. 2.ed.
Porto Alegre: Bookman, 2004. 312 p.
FULLERTON, T., FURMANSKI, T., and VALANEJAD, K.
2007. Journey of discovery: the night journey project as
"video/game art". In Proceedings of the 2007 ACM
SIGGRAPH Symposium on Video Games (San Diego,
California, August 04 - 05, 2007). Sandbox '07. ACM,
New York, NY, 55-63.
DOI=http://doi.acm.org/10.1145/1274940.1274954
GAME DEVELOPER MAGAZINE, 2009, www.gdmag.com
MYCOTED, 2010, www.mycoted.com. [Accessed 12 July
2010].
NVIVO, 2009,
http://www.qsrinternational.com/products_nvivo.aspx.
Acessado em: Novembro 2009.
PORTO DIGITAL, 2010, www.portodigital.org/ [Accessed 12
July 2010].
SCHELL, J., 2008. Art of Game Design: A Book of
Lenses.Burlington: Elsevier.
SEDIG K, KLAWE M., WESTROM M., 2001. Role of
interface manipulation style and scaffolding on cognition
and concept learning in learnware, ACM Transactions on
Computer-Human Interaction (TOCHI), v.8 n.1, p.34-59,
March 2001
SOUZA, L.J. ; NEVES, A. M. M. ; COUTINHO, S. G.2009
Análise de Documento de Game Design:
Interpretação e Resultados Gerados.In: SBGames
2009, 2009, Rio de Janeiro. Anais do SBGames 2009,
2009. v. 1.
SOMMERVILLE, I. SAWYER, P.1997. Requirements
Engineering: A Good Practice Guide
(Paperback). Wiley (April 28, 1997).
UNIVERSIDADE FEDERAL DE PERNAMBUCO – UFPE,
2010, www.ufpe.br [Accessed 12 July 2010].
WETZEL, R., McCALL, R., BRAUN, A., and BROLL, W.
2008. Guidelines for designing augmented reality games. In
Proceedings of the 2008 Future Play, Toronto, Canada.
Future Play '08. ACM, New York, NY, 173-180.
SBC - Proceedings of SBGames 2010
Computing Track - Short Papers
IX SBGames - Florianópolis - SC, November 8th-10th, 2010
291
