See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/339697994

Requisitos não funcionais para Jogos Digitais

Article · September 2016

CITATIONS READS
0 780

3 authors, including:

Mario Madureira Fontes David de Oliveira Lemes

Pontifícia Universidade Católica de São Paulo (PUC-SP) Pontifícia Universidade Católica de São Paulo (PUC-SP)
16 PUBLICATIONS   36 CITATIONS    1 PUBLICATION   0 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Técnica OC2-RD2: estruturas narrativas em cursos de desenvolvimento de software View project

SCReLProg View project

All content following this page was uploaded by Mario Madureira Fontes on 04 March 2020.

The user has requested enhancement of the downloaded file.

SBC – Proceedings of SBGames 2016 | ISSN: 2179-2259 Art & Design Track – Short Papers

Requisitos não funcionais para Jogos Digitais

David de Oliveira Lemes∗ Terceiro autor Thiago Cazelatto Breves Mario Madureira Fontes

Pontifícia Universidade Católica de São Paulo, Departamento de Computação, Brasil

R ESUMO 2.1 Definindo um videogame

Este trabalho apresenta uma comparação de práticas conhecidas da O videogame é definido por Callele et al. [3] como “um pro-
área de engenharia de software com as práticas de gerenciamento duto de entretenimento multimı́dia que requer participação ativa do
aplicadas por equipes de desenvolvimento de jogos digitais no Bra- usuário” e como qualquer produto de entretenimento é supérfluo,
sil. Para tanto são expostas definições de jogos e de alguns requisi- ou nas palavras de Alves et al.: “ninguém tem obrigação de usar
tos não-funcionais que são de grande importância para a concepção um videogame”, portanto o jogo deve ser pensado de forma a atrair
deste tipo de software, assim como algumas das peculiaridades das público, ser pensado para agradar, como dito por Hassenzahl et al.
equipes que os desenvolvem e o método de documentação mais uti- [7], considerando elementos hedônicos como estilo, cores e música.
lizado na área de games. Callele et al. [3] ainda diz:
Palavras-chave: documentação, games, jogos digitais, requisitos O videogame possui uma parte software, com um con-
não-funcionais, software junto de requisitos funcionais para sua implementação,
uma jogo, com seus requisitos funcionais que criam o
envolvimento cognitivo do jogador, e um conjunto de re-
1 I NTRODUÇ ÃO
quisitos não funcionais que representam os estados emo-
A indústria de videogames (Utilizado como sinônimo para a ex- cionais induzidos ao jogador em cada estágio do jogo ou
pressão ”jogos digitais”) gira um faturamento de cerca de 100 por cada elemento do jogo.
bilhões de dólares ao ano [15] e esse faturamento é utilizado na
produção de grandes jogos comerciais que possuem grandes equi- A “parte software” é o que está por trás dos elementos de
pes de desenvolvimento ou jogos independentes que possuem em interação entre jogador e jogo, ou seja, a interface entre homem
sua essência uma equipe reduzida. As empresas dos jogos indepen- e máquina, que é definida por cálculos de comandos e retorno, seja
dentes tentam cada vez mais consquistar uma porção do mercado este visual (exibição das imagens na tela), sonoro (músicas, falas,
de jogos digitais. aúdios), sensorial (vibrações, choques), ou qualquer outro meio que
Seja em grandes empresas ou em pequenos estudios o jogo di- o equipamento, ou conjunto de equipamentos, onde o jogo está
gital é um software, como apontado por vários escritores da área sendo executado permita.
[1, 2, 3, 13, 14], mas seu processo de desenvolvimento difere bas- A “parte jogo” é o ambiente em que o jogador está imerso, que
tante de um software tradicional, fazendo com que os formatos de inclui sua motivação, seu objetivo, elementos narrativos, entre ou-
documentação tradicionais não funcionem tão bem na construção tros, e as regras às quais ele está preso. Em jogos de mesa a maior
de um software que é um jogo digital. parte desses elementos era passada ao jogador por meio de manuais
Portanto, para que os desenvolvedores realizem a documentação, de instrução e referências visuais, deixando o desenvolver do jogo
é necessário fazer adaptações ou buscar alternativas. Por conse- por conta de sua imaginação. Uma vez que os elementos do jogo
guinte, os novos estúdios que querem entrar neste mercado possuem são processados por computador, é possı́vel criar ambientes virtu-
dificuldade de acesso às informações dos processos e adaptações ais, narrativas que são contadas conforme a progressão do jogo,
utilizados pelos mais experientes, tendo que passar por todo o pro- alteração de estado em tempo real e maior quantidade e comple-
cesso de adaptação, que pode custar alguns anos de prática e fra- xidade de regras. Em jogos de mesa são comuns jogos por turno,
cassos comerciais. jogos para vários jogadores e jogos nos quais o ambiente se mantém
independente da atividade do jogador, barreiras que são facilmente
Diversas publicações [1, 2, 3, 10] tratam da documentação quebradas nos videogames (ou até mesmo invertidas, uma vez que
do processo desenvolvimento de software dos games como uma é mais frequente vermos games single player1 do que um multi-
elicitação de requisitos não-funcionais. Este trabalho aponta algu- player2 ).
mas principais diferenças entre o processo de extração de requisitos
A parte emocional é justamente aquilo que o game designer ima-
tradicional de software com o que é praticado por alguns estúdios
gina que o jogador deve sentir durante seu jogo, Callele et al. [3]
brasileiros.
dá como exemplos: apreensão ao se aproximar de uma sala des-
conhecida e a adrenalina de estar dirigindo a alta velocidade e en-
2 C ONCEITUAÇ ÕES contrar uma curva fechada a frente ou a felicidade de encontrar um
tesouro no final da sua jornada. Um jogo que não produz estas
A seguir serão expostas algumas definicões e considerações variações emocionais se torna monótono e desinteressante. Fuller-
dos jogos digitais e as equipes que os produzem, assim como ton [6] afirma que o game designer deve produzir um jogo que seja
comparações com os seus equivalentes na área de software tradi- rico emocionalmente, provoque empatia no jogador, e o impacte
cional, para que possamos entender melhor suas peculiaridades. individual e culturalmente.
Um conceito fortemente ligado a esses estados emocionais é
∗ e-mail: dolemes@pucsp.br o conceito de Flow definido por Csikszentmihalyi [4] como um
estado mental no qual o indivı́duo está completamente envolvido
1 Jogo para apenas um jogador.
2 Jogo para dois ou mais jogadores.

XV SBGames – São Paulo – SP – Brazil, September 8th - 10th, 2016 789

SBC – Proceedings of SBGames 2016 | ISSN: 2179-2259 Art & Design Track – Short Papers

com a atividade que está exercendo, apresentando caracterı́sticas 3 D OCUMENTANDO UM game

como concentração intensa, perda da autoconsciência, distorção da A documentação e seu conteúdo é um ponto importante da
percepção temporal, etc. Estar no estado de Flow produz uma produção de um software, porém as peculiaridades dos jogos digi-
satisfação no indivı́duo pela execução da atividade, porém para tais abordadas na seção 2.2, como a grande quantidade de requisitos
alcançá-lo deve haver um equilı́brio entre o nı́vel de desafio que não-funcionais e multidisciplinaridade da equipe de produção, não
a tarefa representa e a habilidade que a pessoa tem para exercer estão previstas pelos modelos de documentação tradicionais. Na
esta tarefa. Naturalmente os nı́veis necessários para atingir a zona seção 3.1 será apresentado o GDD (Game Design Document ou
de Flow variam para cada indivı́duo, mas se manter nela depende, Documento de Game Design) que foi concebido especificamente
invariavelmente do equilı́brio entre estes dois elementos (desafio e para games e serão tratadas as particularidades da elicitação dos
habilidade) e é aı́ que se encontra um dos desafios dos desenvolve- requisitos no campo de desenvolvimento de games.
dores de games. Para manter esse equilı́brio e o jogador envolvido
na atividade de jogar o videogame, deve-se considerar, por exemplo, 3.1 Documento de Game Design
que, conforme o jogador avança no jogo, ele irá se acostumando
às mecânicas e melhorando suas habilidades, exigindo que o desa- Entre as peculiaridades dos games que possam justificar a adoção
fio que o jogo proporciona tenha que crescer de forma equivalente. de um novo formato de documentação podemos destacar a
Como mostrado no gráfico da figura a seguir, o desequilı́brio pode existência das regras que compõe a parte jogo do videogame que
jogar o indivı́duo no tédio ou na frustração, o que faria um jogador foram mencionadas na seção 2.1, isso se dá pois enquanto um soft-
abandonar um jogo, o que resultaria em um fracasso comercial. ware tradicional e seus requisitos normalmente são projetados com
o intuito de facilitar uma ou mais tarefas do usuário. Nos jogos
digitais, as regras, como foi apontado por Lemes [9, 10], existem
para desafiar o jogador. Outra justificativa é de que não existe uma
formalização da documentação dos requisitos não-funcionais que
são tão importantes para a concepção do game, já que normalmente
eles não possuem uma função tão vital para a concepção do soft-
ware tradicional.
Como apontado por Souza et al. [13], para documentar es-
sas peculiaridades do jogo digital e permitir a comunicação e en-
tendimento de uma equipe que, como foi exposta na seção 2.1,
pode conter membros de diversas áreas do conhecimento e diver-
sas experiências, surgiu o Documento de Game Design, um mo-
delo de documentação concebido para atender às necessidades da
concepção e desenvolvimento dos games. Entretanto, para atender
à grande variedade de estilos de jogos, esse documento acaba por
ser extremamente abrangente e não possuir um padrão fixo, abran-
gendo sessões sobre mecânica, roteiro, arte, fases, requisitos emo-
cionais, como o Flow, citados na seção 2.1, e até mesmo códigos de
trapaça. Tais sessões, durante a produção, podem ser preenchidas
ou deixadas de lado conforme a necessidade de cada game a ser
Figura 1: Gráfico de estados mentais. Csikszentmihalyi (1991) [4] documentado.
Entretanto, Souza et al. [14] questiona se o formato textual
proposto pelo GDD é o mais indicado para o entendimento da
2.2 Desenvolvedores de games informação por uma equipe tão multidisciplinar como a dos de-
senvolvedores de jogos, discutindo a viabilidade de se fornecer
Para atender a essa demanda de considerações a serem feitas du- especificações por meio de imagens e vı́deos. Sua pesquisa apontou
rante o desenvolvimento de um game são necessários profissio- para a necessidade de mesclar os formatos para dar maior clareza
nais de várias áreas do conhecimento, Callele et al.[2] aponta que aos conceitos registrados pelo documento.
uma equipe de desenvolvedores pode ser formada por cientistas da Lemes [10] ainda sugere que junto ao documento em texto, que
computação, engenheiros, artistas, músicos, designers e até mesmo ele chama de Documento de Projeto de Jogo [DPJ] se codifique
psicólogos. Vale citar que desenvolvedores independentes não po- um executável, que ele chama de Documento Executável de Jogo
dem contar com uma equipe muito grande e frequentemente aca- [DEJ], para que se possa validar as idéas escritas no DPJ, auxilie na
bam por reunir várias dessas competências em um único profissio- decisão de fazer corte de funções e ideias da concepção do game e
nal ou delegar algumas decisões ao consenso da equipe. ajude a gerar novas ideias, uma vez que ele torna real as abstrações
Uma equipe de desenvolvedores de software tradicional é ge- do documento escrito.
ralmente composta inteira ou quase inteiramente por profissionais
da área de Tecnologia da Informação. A vantagem dessa estrutura 3.2 Registro dos Requisitos
é que todos possuem uma linguagem comum e um certo entendi- Para um software tradicional os requisitos são primariamente as
mento do produto em que estão trabalhando. A equipe de desen- funcionalidades do produto a ser desenvolvido e, de uma maneira
volvedores de games não tem essa praticidade, sendo necessário secundária, requisitos não-funcionais como “fácil de usar” ou “bem
encontrar uma linguagem que alcance a todos os membros para que colorido”. Esses geralmente não constituem uma parte fundamental
eles possam trabalhar em conjunto e confiar na capacidade de todos das caracterı́sticas do software, mas sim um diferencial. Quem de-
para executarem suas tarefas para que, no final, possam unir todos fine esses requisitos geralmente é um cliente que está contratando
os elementos em um único produto. a equipe de desenvolvimento ou um representante deste, e eles são
Para alcançar um melhor entendimento entre os membros da obtidos pela equipe através de entrevistas, documentos descritivos,
equipe de desenvolvimento de jogos digitais, primeiramente deve- contratos, acordos, entre outros, ou seja, e equipe tem a quem re-
se possuir uma forma bem estabelecida de documentação e conhe- correr para elicitar os requisitos e tomar decisões de projeto.
cer a função e importância dos requisitos que nela se encontram. Já para os videogames, além das funcionalidades do software,
Portanto estes temas serão abordados na seção 3. como dito anteriormente, temos as mecânicas do jogo para definir

XV SBGames – São Paulo – SP – Brazil, September 8th - 10th, 2016 790

SBC – Proceedings of SBGames 2016 | ISSN: 2179-2259 Art & Design Track – Short Papers

No entanto, existem grandes divergências quanto à forma esco-

lhida para realizar a documentação. Por exemplo, os membros da
JoyMasher escrevem textos, sejam fisı́cos ou digitais com rabis-
cos em uma folha A3. A Manifesto Games usa quadros de ideias,
fluxogramas e apresentações em PowerPoint. O estúdio Aiyra usa
Wikis com textos e fotografias que são um misto de formatos como
apontado por Souza et al. [14] conforme abordado na seção 3.
A documentação depende da necessidade e do escopo dos proje-
tos e da forma que a equipe trabalha. Por outro lado, é importante
citar que todos os estúdios acreditam em plataformas colaborati-
vas5 , e toda a equipe pode modificar o conteúdo da documentação
seja qual for o formato.
Adrian, do estúdio Aiyra, ressaltou que devido ao fato dos
estúdio brasileiros trabalharem com projetos de escopo reduzido
e desenvolvimento com prazos apertados, o formato original do
GDD, abordado na seção 3, foi deixado de lado em prol de pla-
taformas mais dinâmicas como Wikis.
Afinal, como apontando não apenas por Adrian, mas por Souza
Figura 2: Exemplo de especificação visual. Souza et al. (2010) [14]
et al. [14] e Salazar et al. [12] em seus trabalhos, produzir um
GDD completo costuma levar muito tempo e gerar um texto muito
grande, difı́cil de ser lido e de ter os requisitos rastreados.
e requisitos não-funcionais de grande importância para o sucesso
do game como produto comercial. Um produto de game tem de
ter uma identidade visual bem definida, divertir e entreter o jogador
e até de ensinar e treinar, no caso de jogos educativos como Mer-
cadinho do Seu Biu3 da Manifesto Games, ou ainda passar uma
mensagem, no caso de serious games como Darfur is Dying4 que
[6] cita em seu trabalho, como boas alternativas de mercado, prin-
cipalmente para desenvolvedores independentes.
Para as equipes de desenvolvimento de games o cliente é ge-
ralmente o jogador, o público-alvo, então, como apontado por [1],
seu desenvolvimento deve ser voltado para o mercado consumidor.
Graças a isto os desenvolvedores, não têm acesso ao cliente, não
têm de quem extrair os requisitos, tornando a elicitação um pro-
cesso altamente criativo. Desde o momento da concepção, decisões
de projeto, funcionalidades, regras, restrições, tudo está nas mãos
da equipe e suas decisões impactarão no sucesso e retorno finan-
ceiro que o game proporcionará, por esta razão pesquisas de mer-
cado, decisões de marketing e o apelo dos requisitos não-funcionais
são tão importantes.
Para tomar decisões de documentação e extração de requisitos
Figura 3: Imagem do jogo Oniken. Dias et al. (2012) [5]
experiência é um fator que facilita o processo e aumenta as chan-
ces de sucesso do produto. Portanto na seção 4 serão apresentadas
algumas práticas dos desenvolvedores brasileiros que já possuem
experiência no mercado de desenvolvimento de games. 4.2 O método de trabalho
Quanto ao método de trabalho todos os estúdios de games questio-
4 E STUDOS DE CASO nados pelo autor afirmaram usar adaptações de metodologias ágeis,
principalmente SCRUM6 , uma escolha feita levando em conta a
Nesta seção apresentam-se as ideias coletadas das entrevistas com
proposta de curtos ciclos iterativos, repetindo as várias etapas do
os estúdios Aiyra, Manifesto Games e Joymasher. Apresenta-se,
processo de desenvolvimento, desde a concepção até o teste, para
também, uma reflexão e comparação dos principais métodos de
cada porção desenvolvida em cada iteração. Vicente Filho, da Ma-
documentação e de trabalho de desenvolvimento de software reali-
nifesto Games, ressalta que esta caracterı́stica vai ao encontro dos
zado pelos estúdios. A transcrição das entrevistas pode ser acessada
interesses do desenvolvimento de game, que está constantemente
no link: http://bit.ly/29I7KRj.
necessitando de ajustes e testes de qualidade, que, de acordo com
esta metodologia, vão acontecer a cada iteração.
4.1 A documentação
No entanto, a metodologia, como foi originalmente proposta,
Todos os estúdios questionados mantêm alguma forma de apresenta algumas dificuldades para os desenvolvedores e são devi-
documentação do jogo e salientam a importância de mantê-la para das, grande parte, ao fato de que ela foi pensada para o desenvol-
manter a ordem no projeto e para manter uma visão comum do jogo vimento de um software tradicional. O maior exemplo disso são as
por toda a equipe. Adrian Laubisch do Estúdio Aiyra cita que o pro- User Stories, que se tornam difı́ceis de se escrever quando se leva
jeto pode facilmente virar um caos se não estiver documentado. em consideração as mecânicas e os requisitos não-funcionais dos
3 Jogo sobre empreendedorismo, vencedor do Desafio Universtiário 5 Ferramentas através das quais é possı́vel produzir um documento em

Empreendedor de 2014 do Sebrae e publicado pelo mesmo no site que várias pessoas podem contribuir e editar (colaborar com) o conteúdo
http://www.desafio.sebrae.com.br (acessado 10/11/2015) 6 Metodologia ágil para desenvolvimento de software, pode ser lido mais
4 Jogo sobre a crise e terrorismo em Darfur no Sudão, pode ser jogado sobre a metodologia em http://www.desenvolvimentoagil.com.br/scrum/
em http://www.darfurisdying.com/index.html (acessado 12/01/2016) (acessado em 11/01/2016)

XV SBGames – São Paulo – SP – Brazil, September 8th - 10th, 2016 791

 SBC – Proceedings of SBGames 2016 | ISSN: 2179-2259 Art & Design Track – Short Papers

jogos, que, como apontado na seção 2, são elementos essenciais R EFER ÊNCIAS
para a concepção de um videogame, e mesmo os requisitos funcio- [1] C. Alves, G. Ramalho, and A. Damasceno. Challenges in re-
nais sofrem com o fato de terem de ser decididos unicamente pela quirements engineering for mobile games development: The
equipe de desenvolvimento. Miller [11] e Keith [8] abordam o uso meantime case study. In Requirements Engineering Confe-
do SCRUM no desenvolvimento de games assim como seus pontos rence, 2007. RE’07. 15th IEEE International, pages 275–280.
fortes e fracos. IEEE, 2007.
Como pode ser observado pelos relatos dos estúdios apontados [2] D. Callele, E. Neufeld, and K. Schneider. Requirements en-
nesta seção é importante manter o hábito de documentar o desen- gineering and the creative process in the video game industry.
volvimento do projeto de game, em prol da comunicação da equipe In Requirements Engineering, 2005. Proceedings. 13th IEEE
(como apontado nos seção 2 e 3) e da organização do trabalho. International Conference on, pages 240–250. IEEE, 2005.
Manter um método de trabalho ágil e iterativo, sendo SCRUM o [3] D. Callele, E. Neufeld, and K. Schneider. Emotional requi-
mais praticado, é importante para facilitar o desenvolvimento, uma rements in video games. In Requirements Engineering, 14th
vez que suas práticas convergem com as necessidades do processo IEEE International Conference, pages 299–302. IEEE, 2006.
de produção de um videogame. [4] M. Csikszentmihalyi. Flow: The psychology of optimal expe-
No entanto, vale ressaltar que cada equipe deve procurar os for- rience, volume 41. HarperPerennial New York, 1991.
matos de documentação e métodos de trabalho que melhor se ade- [5] D. Dias, P. Paiva, and T. Weiller. Oniken. digital game, june
quem as necessidades de seus membros e projetos e nunca se es- 2012. Acessado em 25 de dezembro 2015.
quecer de que eles são elementos que contribuem para o sucesso [6] T. Fullerton. Game Design Workshop: A Playcentric Appro-
comercial. ach to Creating Innovative Games. Elsevier Inc., second edi-
tion edition, 2008.
[7] M. Hassenzahl, A. Beu, and M. Burmester. Engineering joy.
C ONSIDERAÇ ÕES FINAIS
Ieee Software, (1):70–76, 2001.
Com base nos conhecimentos expostos no texto acerca de games, [8] C. Keith. Feedback: “top 10 pitfalls using scrum methodo-
seus requisitos, suas documentações e o relato de desenvolvedores logy for video game development”. website, september 2008.
atuando no mercado brasileiro, podemos tirar algumas conclusões Acessado em 25 de dezembro 2015.
quanto à concepção e desenvolvimento de um jogo digital. [9] D. d. O. Lemes. Games independentes - fundamentos meto-
Ao criar um jogo, o mercado consumidor deve ser seu foco, dológicos para criação, planejamento e desenvolvimento de
a partir dele o desenvolvedor deve pensar quais as caracterı́sticas jogos digitais. Master’s thesis, 2009.
e restrições que o produto deve ter, como ele deve progredir, e [10] D. d. O. Lemes. A técnica de programação exploratória
como ele deveria afetar o jogador emocionalmente. Para chegar (PXP) : projetos de criação e desenvolvimento de jogos di-
a essas conclusões, a equipe de desenvolvimento deve ser multi- gitais. PhD thesis, PUCSP, april 2015.
disciplinar e usar de empatia, se colocar no lugar do seu futuro [11] P. Miller. Top 10 pitfalls using scrum methodology for video
usuário e imaginar como cada requisito, funcional ou não, influ- game development. webpage, july 2008. Acessado em 25 de
enciará sua experiência, pensando em apelos visual, complexidade dezembro 2015.
das mecânicas e até mesmo que cores seriam mais adequadas para [12] M. G. Salazar, H. Mitre, C. L. Olalde, J. L. G. Sánchez, et al.
atingir o público-alvo. Proposal of game design document from software engineering
Documentar as decisões é importante, pois a documentação requirements perspective. In Computer Games (CGAMES),
mantém a ordem e o entendimento da equipe acerca do soft- 2012 17th International Conference on, pages 81–85. IEEE,
ware a ser desenvolvido. Embora existam alguns modelos para 2012.
documentação de softwares tradicionais e até mesmo modelos es- [13] L. Souza, C. Albuquerque, S. Fontes, M. Câmara, S. Counti-
pecı́ficos para jogos, como o GDD, os desenvolvedores não preci- nho, and A. Neves. Análise de documento de game design:
sam se apegar a um template, podem fazer aquilo que melhor con- Interpretação e resultados gerados. In VIII Brazilian Sympo-
vir à equipe, desde que possua uma linguagem que atinja a todos os sium on Games and Digital Entertainment, 2009.
membros, principalmente em uma equipe tão multidisciplinar como [14] L. J. Souza, A. F. Mittelbach, and A. M. Neves. Estudo de for-
a de desenvolvedores de jogos, usar imagens, mapas mentais, entre matos alternativos para documentação de game design. In IX
outros recursos, podem ser mais eficientes que um texto formal, Brazilian Symposium on Games and Digital Entertainment,
assim como combinar esses recursos pode ser uma boa prática. 2010.
[15] STATISTA. Video games revenue worldwide from 2012 to
Trabalhar de forma iterativa e incremental, sempre atualizando e
2015, by source (in billion u.s. dollars). website, 2015. Aces-
mantendo uma relação de complementaridade entre documentação
sado em 25 de dezembro 2015.
e código (assim como nos documentos DPJ e DEJ citados por Le-
mes [10]), testando e modificando o que for necessário, mesmo que
seja um conceito já estabelecido, é a forma mais indicada de se tra-
balhar em um projeto que está tão vivo e sujeito a modificações e
prazos apertados como um game.

T RABALHOS FUTUROS
Persiste a carência de uma forma melhor definida de se especifi-
car requisitos não funcionais, para que seja possı́vel padronizar este
processo no futuro da documentação dos jogos digitais, assim como
ainda se faz necessária uma metodologia de desenvolvimento fo-
cada em games, para que as futuras equipes de desenvolvedores não
precisem perder tempo de produção com a adaptação de uma meto-
dologia que foi concebida para o desenvolvimento de um software
tradicional e que não funciona tão bem com o desenvolvimento de
um jogo.

XV SBGames – São Paulo – SP – Brazil, September 8th - 10th, 2016 792

View publication stats