ArticlePDF Available

Game-Scrum: An Approach to Agile Game Development

Authors:

Abstract and Figures

The use of agile methodologies for developing games has become very common. However, such methodologies must be adapted to the team reality and to the particularities of the game development. Since there are few agile methodologies that specifically address the problems found in game development, this paper aims at inves-tigating some alternatives and suggests an approach to guide people who are starting in this area. The proposed methodology, named Game-Scrum, has been applied in the development of a game for teaching software engineering. The results from its application are also discussed in the paper.
Content may be subject to copyright.
Game-Scrum: An Approach to Agile Game Development
Andr´
e Godoy
Ellen F. Barbosa
Instituto de Ciˆ
encias Matem´
aticas e de Computac¸˜
ao (ICMC-USP)
PO. Box 668, Zip Code 13560-970 – S˜
ao Carlos (SP), Brazil
Abstract
The use of agile methodologies for developing games has become
very common. However, such methodologies must be adapted to
the team reality and to the particularities of the game development.
Since there are few agile methodologies that specifically address
the problems found in game development, this paper aims at inves-
tigating some alternatives and suggests an approach to guide people
who are starting in this area. The proposed methodology, named
Game-Scrum, has been applied in the development of a game for
teaching software engineering. The results from its application are
also discussed in the paper.
Keywords:: Game Development, Agile Methodologies, Scrum,
XP, Educational Game
Author’s Contact:
andregodoy@grad.icmc.usp.br
francine@icmc.usp.br
1 Introduction
The recent advances in technology enabled the development of in-
creasingly more complex and realistic games, but the cost of pro-
duction of a top-level game has reached millions [Wikia 2009],
leaving publishers more and more risk averse. This creates a de-
mand in the use of techniques and methods to ensure that a game
can be developed with as minimal as possible delays and mistakes.
Such techniques and methods should also facilitate the process of
discovering “the fun” – a important factor for the success of a game.
Although some people may already have knowledge in software de-
velopment, there are specific features of game development that can
prevent the success of great games. This results in major problems
in project management, rising the already high costs and causing
delays. The use of a methodology focused on game development
may help to avoid those problems. In this way, the use of some
iterative method is increasing in this industry [Gregory 2008], and
agile methodologies have become popular.
Unfortunately, there are few works in the current literature on ag-
ile methodologies oriented to game development, and the existing
ones have not been effectively used in practice. The objective of
this paper is to present an approach of an agile methodology based
on Scrum and eXtreme Programming for game development, and
review two existing agile methodologies with this same orientation.
This paper is organized as follows. Section 2 will see some of the of
agile methodologies most known, and section 3 will review some
proposals specific for games available today. Section 4 will deal
with the most common problems in game development, while an
approach to solve some of these problems will be threated in sec-
tion 5. Section 6 will describe and analise the application of the
suggested approach while developing an educational game.
2 Agile Methodologies
As the methodologies discussed in the sections below are based pri-
marily on Scrum and XP, this section will deal on these methodolo-
gies in order to distinct their practices from the approach suggested
section 5. According to Abrahamsson [Abrahamsson et al. 2003],
the main characteristics of agile methodologies are: cooperation,
simplicity, adaptiveness and being incremental.
Within these characteristics, the Agile Manifesto [Beck et al. 2001]
brings together the main values of various agile methodologies,
which are important to understand an approach to game develop-
ment based on an agile methodology. Through these values we can
notice that the focus of agile methods is on the product, rather than
the process used. Thus, we avoid unnecessary documentation, there
is flexibility to accept and react to changes, and also the customer
collaboration in monitoring the development.
One of the best known agile software development is eXtreme Pro-
gramming (or XP), which is proposed by Beck [Beck 1999] and
whose fundamental beliefs are based on five principles or values
[Teles 2006]: communication, courage, feedback, respect and sim-
plicity. Its practices were designed aiming to satisfy these values,
with complete freedom to use them or not. Who defines what and
how practices will be applied in the project is the coach, that is also
the project leader and responsible for helping to maintain the dy-
namics and facilitate the process for the team, providing resources
and coordinating activities, thus ensuring that his team correctly
applies the practices defined.
Scrum [Schwaber and Beedle 2001] is another agile methodology
also based on short iterations called sprints. In the sprints, the back-
logs must be delivered, which are a set of atomic requirements de-
signed to be done at each iteration. The backlogs should be priori-
tized according to customer value, production cost, risk and knowl-
edge required to produce it or other parameters. The Scrum Master
act as a servant leader to the Team, which is responsible for the de-
velopment. There is alsso the Product Owner, who gives the feed-
back of the project. The iterations are accompanied by four kinds of
meetings: one for planning, one for accompaniment, one for review
what was done and one for inspect the process, people and tools.
Discover soon what in the game will provide the “fun factor” en-
ables the team to focus on developing and improving it over a much
larger part of the project - greatly increasing the likelihood of suc-
cess of the game. A simple solution to this problem is adopt it-
erative methodologies, in which the agile ones are based. These
methodologies allow to receive an early feedback of the features
implemented, thus improving them if necessary is easier. Another
advantage is to facilitate communication and cooperation among all
those involved in the game creation.
3 Problems in Game Development
The problems found in software development in general are well
known, but very little is known about the real issues affecting the
gaming industry. According to Petrillo [Petrillo et al. 2008] in the
literature, the main problems reported are related to scope, planning
and crunch time (a term used for periods of extreme work overload,
occurring usually closer to deadlines). After a survey of games
postmortems with teams and projects of varying sizes, it was dis-
covered that the vast majority of problems encountered was related
to management problems.
Part of these problems are often associated with the multidisci-
plinary team. Although multidisciplinarity creates an environment
that encourages creativity it may end up creating a division between
“the artists” and “the developers”, resulting in difficulty to get an
effective communication among all team [Petrillo et al. 2008]. An-
other point is the difficulty in determining certain elements like the
fun of the game, which has no efficient technique that describes
when this goal is achieved [Petrillo et al. 2008].
Some techniques for solving these problems are suggested by Kan-
ode and Haddad [Kanode and Haddad 2009], such as the use of
iterative methods, building prototypes and creating a pipeline to the
SBC - Proceedings of SBGames 2010
Computing Track - Short Papers
IX SBGames - Florianópolis - SC, November 8th-10th, 2010
292
artistic content of the game. For a detailed info about these sug-
gestions, please refer to Kanode and Haddad’s work [Kanode and
Haddad 2009]. Part of the problems commonly encountered can be
solved by applying the methodology proposed in the next section.
4 Related Work
Very little is said about agile methodologies specifically focused
on game development. Most of the existing initiatives use some
derivation of the waterfall method [Flood 2003] or, more recently,
some iterative method [Gregory 2008]. Some proposals involving
existing agile methodologies include eXtreme Game Development
[Demachy 2003] and Game Unified Process [Flood 2003].
4.1 eXtreme Game Development
eXtreme Game Development [Demachy 2003], or XGD, is an adap-
tation of XP for game development. According to Demachy, its
focus is on how to adapt XP to game design and creation of mul-
timedia content and how to automatically test specific elements of
the game, like the “fun factor”. Some adaptations from XP include
to add multimedia content in continuous integration; make tests for
multimedia content; consider the team as a whole and use UML to
describe the elements of game design and interaction and commu-
nication between game designers, programmers and even artists;
The methodology clarifies some adaptations from XP to XGD, but
does not address, however, how to work with multidisciplinary
teams. It only recommends the vision of the team as a whole, and
suggests paired work for artists such as pair programming is used
for developers in order to accomplish this. Also, it does not discuss
the results of applying the methodology in the projects mentioned.
4.2 Game Unified Process
Game Unified Process [Flood 2003] is a methodology that com-
bines the RUP (Rational Unified Process) model and techniques of
XP and was developed primarily to address issues of problems in
game development using the waterfall model. Although considered
to be a heavy process, RUP adopts a methodology that enables the
occurrence of fewer changes in the software, while the XP provides
practical ways to avoid over-documentation.
Of the preliminary conclusions that Flood obtained from the appli-
cation of his methodology, we emphasize two: the focus on a rapid
cycle of XP with a focus on long cycles of RUP that has brought
benefits to the development team, despite the difficulties of the team
in order to adopt the style of development of an agile methodology;
and the recognition that the creation of content in game develop-
ment is iterative, leading Flood to suggest this methodology also
for artists and designers. Despite the positive feedback, the team
result was compared with the waterfall method, which is not rec-
ommended as a method for game development, as Flood comments
in his proposal. Also, how to handle with artists in iterations is not
discussed.
5 Game-Scrum
According to Schwaber [Schwaber 2009], Scrum is a framework
focused on project management - how to divide and coordinate the
tasks so that everything can be done without impediments, under
which you can use any other agile practices. In this view, XP would
be more focused on the engineering of the project - which tech-
niques are best to complete tasks efficiently. Game-Scrum uses
these two methodologies as basis, adapting them with the experi-
ence of professionals and focusing in people with little or no ex-
perience in game development. As project management is a major
falling point in game development, is emphasized that the team un-
derstand the iterations and meetings of Scrum, since these details
will not be covered in this part, but remain important to the success
of the project.
During the stages of development of an agile methodology, all the
iterations have approximately the same distribution of the basic
steps for developing a software. But according to Keith [Keith
2010], the distribution of work in game development is not equally
distributed during its iterations. To support this reality, Game-
Scrum is divided into three phases, discussed below.
5.1 Pre-production
In this phase the game must be “discovered”, that is, what really are
the game objectives and what would be the “fun factor” in it. Here
the game concept will be improved, the programming language,
platform and others definitions. As Kanode and Haddad state [Kan-
ode and Haddad 2009], “great pre-production reduces the need to
find that elusive element of ‘fun’ during the production stage, and
allows the team to focus on implementing the game, rather than
experimenting with it”.
This phase defines the direction that the Production phase will take,
without stifling the creativity that might emerge there. Here the
work will be to find the ideal game concept and design, often
through trial and error. For this to be accomplished, brainstorming
is recommended in order to develop ideas and aggregate new ones.
Developing a prototype also will help to preview the “fun factor”
that the game or a portion of it can offer. The prototype must pro-
vide a basic and simplified navigation for the user and the features
required to test. Usually, the code produced is not used again, and
the prototype is discarded.
5.1.1 Game Design Document
The creation of the game design document is an important step to
be accomplished in the pre-production phase of the game, being
responsible for guiding the project’s scope (and thus the entire de-
velopment and testing of the game). A poor game design docu-
ment may result on feature creep, and as a consequence, delays and
missed milestones may also occur.
Although there is no standard way to build a game design docu-
ment, Schuytema [Schuytema 2008] states that this document must
have a comprehensive description of the game in all its aspects, so
that the development team can build it. While describing the items,
objects and characters in the game, it should be documented not
only what they do, but also what they affect, how they interact and
their role and behavior in the game. Despite the efforts to make the
document fairly complete, the document still may change. How-
ever, one should evaluate the risks of changes and if the deadlines
can still be met.
As this document will be later translated to a Product Backlog in the
production phase, for small games it may be optional, translating
the requirements directly as a Product Backlog. This may save time
from the team as they go faster to the production, but may also
increase risks of feature creep or not a very entertaining game.
5.2 Production
At this stage, one should already have a well defined project scope,
and thus a good idea of what the game is really about and what
actually should be done. Here the game design document should
be translated in a product backlog. And at each iteration the most
important backlogs remaining should be divided in smaller pieces
and have its tasks defined, if not already.
For teams composed with many artists, it is needed to think in a
better approach. Very often an artistic task is usually performed by
several specialists working in some kind of production line. For
instance, the modeler delivers his work to the animator, who passes
it to the sound designer and so on. Keith [Keith 2010] suggests
the use of Kanban for those responsible for creating artistic game
content. This allows that at the end of a sprint there is still work that
is under development, unlike Scrum, which requires that all work
be done at the end of a iteration. The goal is to achieve a continuous
flow in content creation.
Another practice suggested by Keith is time-boxing, limiting the
time available to complete a particular task, taking into account the
importance of the artifact being produced and its usefulness in the
game. For teams composed for only developers or with few artists,
SBC - Proceedings of SBGames 2010
Computing Track - Short Papers
IX SBGames - Florianópolis - SC, November 8th-10th, 2010
293
Figure 1: The development of EngReq’s prototype
once it is known what to build in the game, it is recommended to
apply the Scrum management and XP techniques that best fit in the
team reality.
5.3 Post-Production
After the game be completed, playtesting helps to ensure the qual-
ity and the fun of the game. But here we will focus on the feedback
provided by the whole process, creating a postmortem. The post-
mortems are important because they allow to know the strengths
and weaknesses of the development process used, problems that
occurred and suggestions for improvements. Through this feedback
one can get a better estimate for future projects and could make the
necessary adjustments to the process with greater assertiveness.
Myllyaho [Myllyaho et al. 2004] describe the benefits and ad-
vantages of postmortems analysis, and also talks about the
postmortems available in Gamasutra’s website (http://www.
gamasutra.com/). As described in their work, usually post-
mortems provides a summary of the project description, identify-
ing the lessons learned in the three aspects: ‘the good’, containing
a list of good solutions, improvements, suitable tools, etc., includ-
ing areas of project management, communication, marketing and
engineering practices; ‘the bad’, with a list of key issues and prob-
lems and the main cause of them; and ‘the ugly’, for a list of critical
issues that absolutely must be corrected.
Also, the postmortems typically include the following game project
metrics in addition to the experiences: publisher and developer;
number of full-time developers, part-time developers, and contrac-
tors; length of the development, and release date; game platforms,
and development hardware and software used.
Although the approach proposed by Game-Scrum do not bring new
elements to the game development, its innovation is to join together
several suggestions with the same goal. This allows to create a
systematic method to develop a game, having not only practical
references from those working in the area, but also the support of
researchers confronting experiences with the knowledge available
in literature.
6 Example of Application
For the sake of illustration, in this section Game-Scrum is applied
to the development of EngGame, an educational game composed of
several minigames in the domain of software engineering. The first
of these minigames, called EngReq, aims to assist in learning about
the requirements document for students of software engineering.
Although not quite worked, the idea of EngReq already existed, but
was necessary to develop the game from that idea.
6.1 The Pre-Production
So, in the first brainstorming it was discussed the idea of presenting
several minigames themed in different ages for the player, each ad-
dressing a specific part or concept of software engineering. EngReq
would occur in the stone age, and the player’s objective would be
Figure 2: The appearance of the final game
of helping the people of his community to accept the requirements
needed for a particular task that the community wishes to conclude,
and rejecting them if they are not a valid requirement.
After, a prototype was made as a way of testing the ideas discussed
during the brainstorming, and if was possible to create a game about
software engineering that does not happens inside an office. In the
prototype (Figure 1), it was made a drawing to represent the idea
of the scenario of the game, and some screen transitions and the
presentation of requirements for the player. It was discovered that
although it seemed to be a good idea at first, the elaboration of tasks
with similar requirements of a software system in the stone age was
very difficult, so it was decided in another brainstorming that the
game would occur in middle age.
As it was a simple minigame that would to be developed over a rel-
atively short period, it was not written a game design document. As
though the game is composed of minigames that although having a
certain chronological sequence in sense of ages, they would not be
connected in their stories. So, as the minigame idea was also very
clear to the team, the requirements of this minigame were described
directly as a product backlog.
6.2 The Production
In the end of pre-production, EngReq was a minigame very simi-
lar to a quiz, where the inhabitants of a village in the middle ages
presents, in they opinion, what a determined system would require.
The role of the player is, according the requirements shown, rank
them between functional or non-functional requirement, or reject
them if is not a requirement at all. A hotel system was adapted to
the minigame, and there was the possibility of adding new systems
through adding new text files in a specific sub folder of the game.
EngReq was developed in C++ with SDL to display multimedia
content on screen. To accompany the development of this project
used the site urlwww.xp-dev.com, a website with free repository
with tools focused on agile development.
The game’s development was through a small team without artistic
skills. For this reason, the design of scenery and characters has been
outsourced, but even so it was applied the model of iterations, where
the designer met regularly with the developers and both parties tried
to be as clear as possible in presenting their ideas. The end result of
EngReq can be seen in Figure 2.
6.3 The Post-Production
With EngReq ready for beta testing, a questionnaire was designed
and applied to undergraduate and graduate students, as well as
to software engineering professors to evaluate the game. Thus,
through their answers we could analyze the effectiveness of the
minigame. The questionnaire used a Likert scale with five levels
where the answer ‘A’ corresponds to ‘totally agree’ and ‘E’ corre-
sponds to ‘totally disagree’. There where 11 closed questions and
has also 4 open questions, where they can give their opinion about
the minigame, its strengths and weaknesses, and suggestions of im-
provements. The questionnaire was applied to five undergraduate
SBC - Proceedings of SBGames 2010
Computing Track - Short Papers
IX SBGames - Florianópolis - SC, November 8th-10th, 2010
294
students, six graduate and two teachers.
From the answers, it was clear that the audience believed that the
game was tailored to its proposal, but the gameplay was a bit tir-
ing. It was suggested to increase the number of requirements avail-
able and show a limited amount of them randomly. The answers
also showed that the minigame has the correct concepts about soft-
ware engineering, even not appearing to be about this subject. One
point to improve was the feedback given to the player, where the
questionnaire participants suggested decrease the response time of
feedback, showing it to the player right after his choice instead of a
screen at the end of the game.
A postmortem of EngReq was produced with the feedback of the
project. As the first application of this methodology, there were
several issues that could be solved with more practice. But some of
them included the different schedules of classes between the team,
what delayed the project and could not be solved easily. Even so,
the project could be considered as successful.
7 Conclusion and future work
The environment of game development with increasing costs and
high mutability of the requirements, makes essential to know as
sooner as possible whether the investment will return. Knowing
what brings “fun” to the game and work it well is a pre-requisite
to the it’s success. But in traditional development, most of this
discovery occurs only in late development, when much time and
money already has been invested and there are great risks in making
changes. An iterative methodology allows to have features ready
soon and thus discover and work the “fun” of the game is easier,
while an agile process lets you focus on what really matters.
There are few alternatives for agile methodologies focused on the
needs of an environment of game development, where the multidis-
ciplinary teams are common and there is a need to find the “fun
factor”, that is not easily quantified. The Game-Scrum tries to
solve specific problems of game development by assimilating sug-
gestions from professionals of the industry and confronting it with
researchers of the area. Some of the approaches made by Game-
Scrum may be summarized as follows:
Artistic content: allowing to have work undone at the end of
an iteration, and assembling a production chain were the first
asset must be done in this iteration, and the next ones over the
following iterations.
Project scope: making use of techniques like brainstorming,
prototyping and the game design document as part of pre-
production facilitates the discovery of the “fun” of the game,
and iterations enable to evolve this factor. Also, these tech-
niques may reduce the amount of feature creep in the game.
Project management: using the framework of Scrum to de-
velop games makes a strong process as base of Game-Scrum.
As in Scrum itself, the constant evaluation of the feedback of
the project helps to improve it each time it is applied.
Team organization: suggesting some alternatives to improve
organization, under which the team may choose based on its
strengths and weakness those who best suit to the team’s cul-
ture and preferences.
Even proving good practices during the game’s development,
Game-Scrum is not able solve all of its problems. There may still
be some feature creep, as some ideas only arise in later develop-
ment. Also, in spite of brainstorming be used to aggregate ideas in
order to avoid feature creep, it may lead to the opposite problem of
cutting features and enlarge scope if not well done.
Although Game-Scrum have been tested with the development of
EngReq, it is needed to mature the suggested methodology. The
postmortem of the minigame suggested that the approach have
potential, and the experience learned may improve the results of
the next minigame. Future work on this subject include apply
Game-Scrum in projects of the Fellowship of the Game (http:
//fog.icmc.usp.br/), a group of undergrad students at Uni-
versity of S˜
ao Paulo focused in developing games. With several
ongoing projects, the first step will be to coach the team, applying
Game-Scrum to its projects and analyze the postmortems. Collect-
ing this feedback will help to refine and improve Game-Scrum, until
it becomes able to solve most problems in game development with
unexperienced or experienced teams.
Acknowledgements
The authors would like to thank the Brazilian funding agencies
(FAPESP, CAPES and CNPq) and the University of S˜
ao Paulo (Pro-
grama Aprender com Cultura e Extens˜
ao) for their financial sup-
port. Also, to God, for making all things possible.
References
ABRAHAMSSON, P., WARSTA , J., S IP ONE N, M. T., AND
RONKAINEN, J. 2003. New directions on agile methods: a com-
parative analysis. In ICSE ’03: Proceedings of the 25th Inter-
national Conference on Software Engineering, IEEE Computer
Society, Washington, DC, USA, 244–254.
BEC K, K. , BE EDL E, M., VAN BENNEKUM, A. , CO CKB URN,
A., CUNNINGHAM, W., FOWLE R, M., GRENNING, J., HIGH-
SM ITH , J., HUN T, A., JEFF RIES, R., KERN , J., MARICK,
B., MART IN , R. C. , ME LLO R, S., SC HWAB ER, K ., SUTH ER -
LA ND, J ., A ND THOMAS, D., 2001. Agile manifesto. http:
//www.agilemanifesto.org. Retrieved in October 2009.
BEC K, K. 1999. Extreme Programming Explained: Embrace
Change, first ed. Addison-Wesley Professional.
DEM ACH Y, T., 2003. Extreme game development: Right on time,
every time. http://www.gamasutra.com/resource_
guide/20030714/demachy_pfv.htm. Retrieved in July
2010.
FLO OD, K., 2003. Game unified process. http:
//www.gamedev.net/REFERENCE/ARTICLES/
ARTICLE1940.ASP. Retrieved in July 2010.
GRE GORY, D ., 2008. Building a mindset for rapid iteratioon part
1: The problem. http://www.gamasutra.com/view/
feature/3645/. Retrieved in July 2010.
KANODE, C. M., AND HAD DAD , H. M. 2009. Software engineer-
ing challenges in game development. In ITNG, IEEE Computer
Society, S. Latifi, Ed., 260–265.
KEI TH, C., 2010. Kanban for video game develop-
ment. http://www.infoq.com/presentations/
kanban-video- game-dev. Retrieved in July 2010.
MYL LYAHO , M., SALO, O., K ¨
A¨
ARI ¨
AINEN, J., HYY SA LO, J .,
AN D KOSK EL A, J., 2004. A review of small and large post-
mortem analysis methods.
PETRILLO, F., PIMENTA, M., TRINDADE, F., AN D DIETRICH, C.
2008. Houston, we have a problem...: a survey of actual prob-
lems in computer games development. In SAC ’08: Proceedings
of the 2008 ACM symposium on Applied computing, ACM, 707–
711.
SCHUYTEMA, P. 2008. Design de games: uma abordagem pr´
atica.
Cengage Learning.
SCHWABER, K., AND BE EDLE, M . 2001. Agile Software Devel-
opment with Scrum, first ed. Alan R. Apt.
SCHWABER, K., 2009. Scrum guide. http://www.
scrumalliance.org/resources/598. Retrieved in
July 2010.
TEL ES, V. M., 2006. Extreme programming. http://
improveit.com.br/xp. Retrieved in October 2010.
WIKIA, 2009. Video game industry. http://vgsales.
wikia.com/wiki/Video_game_industry. Retrieved
in July 2010.
SBC - Proceedings of SBGames 2010
Computing Track - Short Papers
IX SBGames - Florianópolis - SC, November 8th-10th, 2010
295
... Moreover, according to a survey by McKenzie et al. [15], although many studios claimed that they are applying agile methodology in their gaming projects, they are in reality not following the key agile practices as intended. Godoy and Barbosa [16] proposed a game development methodology, called Game-Scrum, that is based on Scrum, an agile methodology that utilizes short iterations, called sprints. Game-Scrum [16] has three main stages, namely pre-production, production, and post-production [17]. ...
... Godoy and Barbosa [16] proposed a game development methodology, called Game-Scrum, that is based on Scrum, an agile methodology that utilizes short iterations, called sprints. Game-Scrum [16] has three main stages, namely pre-production, production, and post-production [17]. The goal of the pre-production stage is to create and establish the game concepts and requirements related to the game's story, mechanics, and design. ...
... The applicability of Game-Scrum was shown using a game for teaching software engineering. Although Game-Scrum seems promising, Godoy and Barbosa [16] stated that more studies and applications following this methodology are required and that their methodology is still not mature enough. ...
Article
Full-text available
With the increase in market needs, game development teams are facing a high demand of creating new games every year. Although several methodologies and tools were introduced to support the game development life cycle, there is still a lack of evidence that these techniques improve game requirements understandability among development teams. The use of models in requirements engineering is considered a promising approach to support requirements elicitation, negotiation, validation, and management. In the context of game development, game designers argue that models are hard to learn and would restrict their creativity. In this paper, we introduce a novel use case-based game modeling approach that extends the standard UML use case diagram. The proposed technique allows for better representation of game-related requirements and promotes a common understanding of game requirements among game development teams. Our approach is implemented in a tool, called game use case modeling, and its applicability is demonstrated using four well-known games, Super Mario Bros, Tetris, Just Dance, and The Walking Dead. Moreover, in order to assess the perceived understandability, learnability, and usefulness of the proposed approach, we have conducted a survey involving 29 participants from the game development community. Results indicate a very satisfactory agreement regarding the added value of the proposed approach and a willingness of adoption by the game development community.
... Por otra parte, es posible como se mencionó anteriormente, emplear metodologías ágiles que se adaptan bastante bien a entornos cambiantes, equipos multidisciplinares y con altas cuotas de incertidumbre, por lo que metodologías con mayor trayectoria y multitud de casos de éxito como Scrum y XP, son altamente usadas en la industria del videojuego (Osborne et al., 2014), sin embargo su aplicación conlleva ciertos inconvenientes como los descritos por Politowski et al. (2016) donde refieren acerca de objetivos poco realistas, problemas de comunicación con implicados internos y externos que no estén familiarizados con la metodología escogida y en algunos casos la dificultad de adopción de estas metodologías para grupos altamente creativos como dibujantes o guionistas como se menciona en Godoy y Barbosa (2010). ...
... As one of Agile methodology, scrum shows many beneficial out-come to the company since it can reduce the time of production. Several authors [12,13,14,15] had implemented this method by following the cycle of the iteration itself. The result shows that the was recommended and play a big part in developing the games. ...
Conference Paper
Full-text available
Many methodologies are being used in software development, not only software can follow the process, but now games could follow the cycle of processes. Starting from the traditional waterfall model to agile methodology, many game developers are trying to produce the methodologies that could solve their problem in game development. In this paper, the type of methodologies will be shown on current game development. Also, this paper would suggest agile methodologies especially scrum over others in game development, and the reason behind that will be explained. Besides that, there are proposed game development methodologies that could solve the problem of game development by involving three phases, including the pre-production phase, production phase, and post-production phase. In the production phase, the sub-steps will have four sub-steps such as design, development, testing and review and the sub-steps will cycle as long as a result are unsatisfied.
... The relatively low number of survey respondents has meant that there are insufficient numbers needed to generalize the survey. However, other studies focused on the challenges that the game industry faces are consonant with those expressed by the NZ community [28,27,8]. Further, the context and conditions of the industry in NZ are comparable with other surveys conducted in Finland, Austria, and Brazil [17,22,31]. Hence in general, the doubt that a game studio is truly agile when they think they are but are experiencing issues agile was intended to solve, can be reasonably but cautiously substantiated. ...
Conference Paper
Full-text available
Applying current software engineering practices in the game development industry is a rapidly growing but under researched area. Whether game development studios align to traditional software engineering practices such as agile methodologies to develop their games is not known. It is also unknown how studios perceive their own adherence to such agile development practices. Furthermore, struggling start-up studios could benefit from implementing development practices based on the experiences of established studios. Hence, an exploratory survey was conducted to determine the practice of, and perception of agile game development in New Zealand. The results show that while studios universally state and perceive that they use the agile framework Scrum and sometimes Kanban, their actual practices often differ from these frameworks in key areas. Furthermore, studios collectively overestimated their level of adherence with Scrum. This has general implications for related academic studies as well as for the game industry's own evaluation and improvement of their practices.
... Dentre aqueles que indicaram utilizar alguma metodologia, observa-se um maior uso de metodologias ágeis, com 26 participantes (35,62%) indicando Scrum e 21 participantes (28,77%) indicando Kanban. Estudos tem explorado Scrum e seus benefícios durante a produção de jogos [14,19,22], e alguns tem apontado a maior utilização desta metodologia pelos desenvolvedores [21,28,32]. Ainda sim, 26 participantes (35,62%) apontaram não utilizar nenhuma metodologia/processo definido e oito participantes (10,96%) afirmaram desconhecer ou não saber responder que metodologia/processo/práticas utilizam. ...
Conference Paper
In 2018, the game industry made about 137,9 billion dollars worldwide in a very competitive market, since each day new games are launched. Games can be created by large development companies; or by small teams with few resources, which pursue innovation and originality in games, commonly referred to as indie games. Regardless of the size of the organization and/or team, the complexity of the development related to the production of such software is similar. In order to deliver high quality games, the practitioners carry out software tests during the production of their indie games. These tests aim to analyze the specific characteristics of this type of software, such as the degree of entertainment and playability aspects. However, there still no consensus about how the test activities are performed during the development process of indie games. This paper presents a survey to identify the test practices during the development of indie games, aiming to understand how these activities are performed. As a result, we identified that developers worry about the execution of tests during the development of indie games, focusing on techniques that consider more than one inherent aspects of the game. Within the aspects that these developers focus on, we can name: the identification of bugs, verification of playability aspects and degree of entertainment of the game.
... Agile software development methods such as Scrum can be applied to game development. 92 In this study, the videogames are continuously tested with final users providing valuable feedback that will drive the next steps in the development. This iterative process requires active collaboration between health professionals, videogame designers and developers, and final users. ...
Article
Background: The design of meaningful and enjoyable Exergames for fitness training in older adults possesses critical challenges in matching user's needs and motivators with game elements. These challenges are often due to the lack of knowledge of seniors' game preferences and technology literacy as well as a poor involvement of the target population in the design process. Objective: This research aims at describing a detailed and scrutinized use case of applying human-centered design methodologies in the gamification of fitness training routines and illustrates how to incorporate seniors' feedback in the game design pipeline. Materials and Methods: We focus on how to use the insights from human-centered inquiries to improve in-game elements, such as mechanics or esthetics, and how to iterate the game design process based on playtesting sessions in the field. Results: We present a set of four Exergames created to train the critical functional fitness areas of older adults. We show how through rapid prototyping methods and multidisciplinary research, Exergames can be rigorously designed and developed to match individual physical capabilities. Moreover, we propose a set of guidelines for the design of context-aware Exergames based on the lessons learned. Conclusion: We highlight the process followed; it depicts 19 weeks of various activities delivering particular and actionable items that can be used as a checklist for future games for health design projects.
Conference Paper
Full-text available
RESUMO Por ser uma área multidisciplinar, existem divergências sobre se os jogos são produtos de arte que contém software ou produtos de software que contém arte. O problema com ambos os pontos de vista é que os aspectos importantes da produção geralmente podem ser subestimados. Este artigo apresenta um processo de desenvolvimento de jogos que pretende combinar processo de desenvolvimento de software com base no processo Scrum com processo de desenvolvimento artístico para fornecer um processo melhor equilibrado. O processo proposto também foi adaptado para equipes com dedicação de tempo parcial e com membros atuando em mais de um papel no processo, como acontece em projetos independentes ou indie. Palavras-chave: Scrum, criação de jogos, desenvolvimento de jogos, elementos artísticos. 1 INTRODUÇÃO Pesquisando em documentos de post-mortem de projetos de diferentes tamanhos, um time de pesquisadores [1] descobriu que a maior parte dos problemas no desenvolvimento de jogos está relacionada a problemas de gerenciamento. Por se tratar de uma área multidisciplinar que envolve a participação de profissionais de artes, som, diferentes profissionais de computação, game designer, entre outros, a comunicação e a coordenação de atividades entre as pessoas de diferentes backgrounds pode ser um desafio. Uma forma de coordenar as atividades é através da adoção de um processo de desenvolvimento. Um processo de desenvolvimento pode ser descrito como um conjunto de atividades, artefatos criados e usados pelas atividades e papéis responsáveis pela execução das atividades. Existem, na literatura, algumas propostas de criação de processos de desenvolvimento e propostas de guias sobre características que os processos de desenvolvimento devem seguir [1][2][3]. Muitos desses trabalhos relatam adaptações feitas em modelos de processos de desenvolvimento de software para a área de jogos e alguns como [3] apresentam os resultados da aplicação do processo proposto em empresas já estabelecidas e com equipes dedicadas. Poucos tratam das necessidades e desafios da adaptação de processos de jogos para equipes não dedicadas e esse é o principal diferencial desse trabalho. Utilizar um processo pode ser desafiador especialmente para pequenas empresas ou desenvolvedores indie. Existe sempre o medo que o processo torne o trabalho burocrático. Isso faz com que muitas empresas trabalhem com procedimentos "artesanais" criados a partir de necessidades vistas ao longo do tempo, ou até mesmo sem padrões que garantam a qualidade do produto [4]. A multidisciplinaridade da área de jogos traz também outro desafio na proposição de um processo de desenvolvimento. Os processos criativos e de produção usados por artistas são, muitas vezes, muito diferentes dos utilizados por desenvolvedores de software. Mas o projeto do jogo como um todo precisa permitir que essas atividades das diferentes áreas estejam integradas. Assim, o processo proposto por esse trabalho também visa aliar atividades de processos artísticos dentro de ciclos iterativos de desenvolvimento comumente definidos em processos de desenvolvimento de software ágeis como o Scrum. O processo proposto também toma como base outra diferença em comparação com os processos já definidos. Esse projeto define como público alvo as empresas independentes (indie) e os grupos não formais de desenvolvedores de jogos. Projetos indie são, por definição, projetos criados sem o suporte financeiro de grandes corporações. Nesse cenário, as equipes desses projetos indie são definidas por esse artigo como equipes mais reduzidas, podendo ter as empresas funcionários com dedicação de tempo parcial para o projeto, ou mesmo como projetos indie dos quais participam voluntários sem alocação fixa onde muitos têm outros empregos e utilizam o tempo livre para desenvolver seus projetos. Tais tipos de baixa dedicação de tempo dos membros da equipe criam novos desafios para o respeito a um processo de desenvolvimento, dificultando algumas práticas comuns em grandes/médias empresas. Por exemplo, pode não ser possível, em uma equipe indie, fazer uma reunião diária em horário determinado com toda a equipe. 2 TRABALHOS RELACIONADOS Em [4] foi proposta uma metodologia para o desenvolvimento de jogos, baseada em metodologias ágeis e prototipação denominada Origame. O Origame divide o processo geral em três fases: Design e Projeto, Produção e Implementação. Embora o processo Origame seja bem estruturado e sirva como um ótimo guia sobre os tipos de artefatos produzidos em cada fase do desenvolvimento, esse processo não define de forma satisfatória as atividades relacionadas ao desenvolvimento de software e não define claramente como atividades artísticas e de desenvolvimento se retroalimentam. Em [3], foi feita uma adaptação na metodologia Scrum para ser aplicada em projetos de jogos. Essa adaptação ocorreu a partir da análise de problemas encontrados no decorrer da aplicação do Scrum em uma empresa de desenvolvimento de games. Essa adaptação também propõe a criação de um papel novo (Game Design Master), um artefato novo (Game Design Wiki) e uma reunião adicional ao Scrum (Weekly Game Design Meeting). Em muitos aspectos as conclusões encontradas pelos pesquisadores se assemelham às desta proposta como a separação dos times de artes e desenvolvimento com reunião de interação entre seus trabalhos e a manutenção de um GDD enxuto. Entretanto, a principal diferença é que o processo proposto tem um foco maior *
Article
Full-text available
Any problem is a problem until a solution is designed and implemented. This paper reports on a workshop that highlights preliminary work done by the working group on Gamification in the scope of European Network for Academic Integrity (ENAI), which aims to explore the possibility of developing and testing a gamified learning module on academic integrity values. In this paper, the group aims to look at proposing steps we are currently using to develop storyboards of scenarios for the first phase of the project, which were presented at the 6th International Conference Plagiarism Across Europe and Beyond 2020 held virtually in Dubai as a workshop. The study also presents updated findings and scenarios drawn from the workshop conducted and audience feedback, in the following sections that pave the way for the future stages of the gamification process. This serves as a guide to academics and researchers in academic integrity who may wish to study gamification and apply it to develop their own modules for their learning modules.
Article
The rapid growth of Information Technology led to the development of a multitude of smartphone systems worldwide. As a result, the number of educational institutions offering courses in areas such as programming and software engineering increased. However, traditional processes for software development did not keep pace with changing technologies. In the last few years, software development became more dynamic and iterative, requiring stakeholders to work as a team and deliver higher quality projects in less time, by using methods such as Agile Development (e.g., Scrum and Extreme Programming (XP)). Although some institutions approach this content in graduation courses, many students and professor are indifferent towards it, resulting in low enthusiasm and practice. This article presents the real case of a classroom activity to teach Scrum concepts by using Lego blocks. At the end of the classes, students were asked to rate the effectiveness of the activity. The results showed that dynamic games and palpable activities are more effective than theoretical or video lessons.
Article
Full-text available
Post-mortem analysis (PMA) is an empirical study method in software engineering. It is an important, but often forgotten, way of gathering empirical knowledge. PMA is ideally performed either soon after the most important milestones and events or at the end of a project, both in s uccessful and unsuccessful software development projects. The benefit is that post-mortems can often reveal findings more frequently and differently than project completion reports alone. This paper reviews PMA as a project based learning technique, and discusses how such a technique can be used to perceive the different settings of software development projects. In this study, two techniques were used to gain information about the post-mortems: firstly an extensive literature search was carried out on software engineering and management literature, and secondly post-mortem sessions were held in small software development projects. Based on the findings, we present a general post- mortem analysis process as an example from a formal framework, used for identifying innovation possibilities based on lessons learnt. Different PMA techniques are affected by the size of the project, as well as the scope and density of the PMAs: previously post-mortem reviews have been suggested to be used after the average- sized or large projects; and recently some agile methods have proposed using team reflection techniques with small teams, for instance to adjust the processes at end of each iteration (release). Furthermore, we conclude from our findings that PMA is worthwhile in small and medium-sized software development projects for which lightweight versions of PMA can be tailored.
Conference Paper
Full-text available
This paper presents a survey of problems found in the development process of electronic games. These problems were collected mainly from game postmortems and specialized litterature on game development, allowing a comparison with respect to well-known problems in the traditional software industry.
Conference Paper
Full-text available
Agile software development methods have caught the attention of software engineers and researchers worldwide. Scientific research is yet scarce. This paper reports results from a study, which aims to organize, analyze and make sense out of the dispersed field of agile software development methods. The comparative analysis is performed using the method's life-cycle coverage, project management support, type of practical guidance, fitness-for-use and empirical evidence as the analytical lenses. The results show that agile software development methods, without rationalization, cover certain/different phases of the software development life-cycle and most of them do not offer adequate support for project management. Yet, many methods still attempt to strive for universal solutions (as opposed to situation appropriate) and the empirical evidence is still very limited. Based on the results, new directions are suggested In principal, it is suggested to place emphasis on methodological quality - not method quantity.
Conference Paper
In software engineering (SE), video game development is unique yet similar to other software endeavors. It is unique in that it combines the work of teams covering multiple disciplines (art, music, acting, programming, etc.), and that engaging game play is sought after through the use of prototypes and iterations. With that, game development is faced with challenges that can be addressed using traditional SE practices. The industry needs to adopt sound SE practices for their distinct needs such as managing multimedia assets and finding the ldquofunrdquo in game play. The industry must take on the challenges by evolving SE methods to meet their needs. This work investigates these challenges and highlights engineering practices to mitigate these challenges.
New directions on agile methods: a com-parative analysis
  • P Warsta
  • J Siponen
  • M T And Ronkainen
References ABRAHAMSSON, P., WARSTA, J., SIPONEN, M. T., AND RONKAINEN, J. 2003. New directions on agile methods: a com-parative analysis. In ICSE '03: Proceedings of the 25th Inter-national Conference on Software Engineering, IEEE Computer Society, Washington, DC, USA, 244–254.
Design de games: uma abordagem prá. Cengage Learning
  • P Schuytema
SCHUYTEMA, P. 2008. Design de games: uma abordagem prá. Cengage Learning.
Agile manifesto Extreme Programming Explained: Embrace Change, first ed Extreme game development: Right on time, every time Game unified process Building a mindset for rapid iteratioon part 1: The problem Software engineer-ing challenges in game development
  • K Beck
  • M Beedle
  • A Van Bennekum
  • A Cockburn
  • W Cunningham
  • M Fowler
  • J Grenning
  • J High-Smith
  • A Hunt
  • R Jeffries
  • J Kern
  • B Marick
  • R C Martin
  • S Mellor
  • K Schwaber
  • J Suther-Land
  • D And Thomas
  • K Beck
  • D Gregory
BECK, K., BEEDLE, M., VAN BENNEKUM, A., COCKBURN, A., CUNNINGHAM, W., FOWLER, M., GRENNING, J., HIGH-SMITH, J., HUNT, A., JEFFRIES, R., KERN, J., MARICK, B., MARTIN, R. C., MELLOR, S., SCHWABER, K., SUTHER-LAND, J., AND THOMAS, D., 2001. Agile manifesto. http: //www.agilemanifesto.org. Retrieved in October 2009. BECK, K. 1999. Extreme Programming Explained: Embrace Change, first ed. Addison-Wesley Professional. DEMACHY, T., 2003. Extreme game development: Right on time, every time. http://www.gamasutra.com/resource_ guide/20030714/demachy_pfv.htm. Retrieved in July 2010. FLOOD, K., 2003. Game unified process. http: //www.gamedev.net/REFERENCE/ARTICLES/ ARTICLE1940.ASP. Retrieved in July 2010. GREGORY, D., 2008. Building a mindset for rapid iteratioon part 1: The problem. http://www.gamasutra.com/view/ feature/3645/. Retrieved in July 2010. KANODE, C. M., AND HADDAD, H. M. 2009. Software engineer-ing challenges in game development. In ITNG, IEEE Computer Society, S. Latifi, Ed., 260–265.
a survey of actual prob-lems in computer games development
  • Houston
Houston, we have a problem...: a survey of actual prob-lems in computer games development. In SAC '08: Proceedings of the 2008 ACM symposium on Applied computing, ACM, 707– 711.