Processo de Teste para Projeto de Portabilidade de Jogos Digitais em Dispositivos Móveis – Uma Experiência Prática na Indústria Luana Lobão1, Marcos Gabriel2, Gisele Macedo1, Arilo Dias Neto3 1
Instituto de Desenvolvimento Tecnológico – (INDT) Caixa Postal 7200 – 69048-660 – Manaus – AM – Brasil 2
Samsung Instituto de Desenvolvimento para a Informática da Amazônia (SIDIA) Caixa Postal 880 – 69075-830 – Manaus – AM – Brasil. 3
Instituto de Computação – Universidade Federal do Amazonas (UFAM) Caixa Postal nº 6.200 – 69.077– 000 – Manaus – AM – Brasil
Abstract
1. Introdução
This paper describes the practical experience in applying a testing process for planning and executing a porting project of a commercial game. Since the adoption of structured activities for planning and execution of functional and exploratory testing activities was possible to obtain positive results, for example, found failures about functionality workflow, performance and API that were previously mapped by modeling process of gameplay of game. In this paper was described the main results of the process and the problems encountered.
O cenário da indústria de jogos no Brasil está vivendo um momento de constante evolução. Hoje, o mercado brasileiro é considerado o quarto mercado consumidor do mundo em jogos. Pesquisa feita pelo IDC aponta um crescimento de 78% nas vendas de smartphones em 2012 comparadas com o ano de 2009 [IDC 2013]. Segundo um mapeamento feito pelo BNDES (Banco Nacional de Desenvolvimento Econômico e Social) relacionado à Indústria Brasileira e Global de Jogos Digitais, o desenvolvimento de jogos para a plataforma mobile vem mostrando forte tendência no aumento das vendas [BNDES 2014] com o passar dos anos.
Resumo Este artigo descreve a experiência prática em aplicar um processo de teste para planejamento e execução de um projeto de portabilidade de um jogo comercial. A partir da adoção de atividades bem estruturadas de planejamento e execução de testes funcionais e exploratórios, foi possível obter resultados positivos como, por exemplo, a rápida e precisa identificação de falhas de fluxo de funcionalidade, desempenho e API que foram encontradas a partir de testes previamente mapeados pelo processo de modelagem de gameplay do jogo. Neste artigo estão descritos os principais resultados obtidos a partir da aplicação do processo, suas atividades e os problemas observados. Palavras-Chave: Processo de Teste de Software, Qualidade do Processo, Processo de Apoio, Gerência de Riscos, Teste para Jogos, Modelagem de Processo, Ferramentas de Teste. Authors’ contact: {luana.lobao,gisele.macedo}@indt.org.br
[email protected] [email protected]
Em contrapartida a esta crescente tendência de comercialização de jogos em dispositivos móveis estão os Processos de Desenvolvimento de Jogos. Diversos estudos apontam que a maioria dos projetos de desenvolvimento de jogos não usa uma metodologia de desenvolvimento e, como consequência, muitos acabam fracassando sem antes virar um produto [Petrilho 2008][Bethke 2003][Callele; Neufeld; Shneider 2005]. Isso se deve ao fato de que a natureza de desenvolvimento de jogos é complexa, pois toda a sua etapa de criação e produção é multidisciplinar, ou seja, existem profissionais que fazem o enredo da história, outros o som, a arte, outros definem a jogabilidade e outros cuidam do desenvolvimento do algoritmo [Blow 2004]. Mediante as questões mostradas anteriormente, é importante assegurar a qualidade desse tipo de produto antes de ir para as mãos de seus consumidores (os jogadores). É essencial que os aspectos funcionais e não funcionais de um jogo digital em um dispositivo móvel sejam testados antes que o produto final chegue ao mercado. Além disso, existem características referentes a plataforma que precisam ser verificadas. Muitas vezes um jogo é desenvolvido para mais de uma plataforma e necessita ser testado em todas as plataformas por conta das características específicas de cada uma.
Neste contexto, o objetivo deste trabalho é contribuir com a experiência prática na definição e execução de um processo de teste para um projeto de portabilidade de um jogo comercial. Projeto esse de portabilidade da plataforma Windows Phone para Android e IOS. Na Seção 2 é possível ver o contexto do jogo. Na Seção 3 é possível ver todo o processo de teste que foi criado e executado no jogo piloto. Na Seção 4 é possível ver os resultados da experiência no contexto das falhas encontradas. Na Seção 5 são mostradas as conclusões e os benefícios da execução do processo.
2. Contextualização O projeto de jogo em questão a ser discutido neste relato de experiência se tratava de um projeto de portabilidade entre plataformas. O jogo existia para a plataforma móvel Windows Phone e estava sendo portado para outras duas plataformas móveis, Android e IOS. A ideia era portar o framework Sparta [Sparta 2014] feito em XNA [XNA 2014] para Monogame [Monogame 2014], além de portar partes do jogo que estavam em XNA para Monogame.
quem está jogando. O jogador precisa ter domínio sobre os controles e comandos. Essa classe de jogo envolve ações de curta duração e atividades causa-eefeito e é subdivida em dois subgêneros: jogos de tiro (shooters) e jogos de plataforma. O jogo que está sendo discutido neste artigo é sub-classificado como jogo de plataforma, onde o jogador precisa saltar e desviar de obstáculos através de ações que requerem atenção e precisão com os controles [Villas 2005]. Nesse jogo, o personagem conta com três tipos de comandos que faz com que ele dê um salto com apenas um tap1 no celular, dê um salto duplo com dois taps e faça manobras giratórias quando o usuário segura o tap. O jogador precisa utilizar esses comandos e fazer o personagem passar por plataformas e obstáculos a fim de conseguir passar da fase com o maior número de moedas, sem perder vida e com no máximo três estrelas. O objetivo do jogo é vencer três ilhas e, ao final do jogo, receber uma medalha de acordo com a quantidade de estrelas ganhas por fase. Na Figura 1 é possível ver partes do jogo, como as ilhas, a indicação das fases de uma ilha disponível no jogo, imagens do gameplay das três ilhas e a tela de pontuação.
O jogo piloto é classificado como jogo de ação, onde a principal característica é exigir atenção e habilidade de
Figura 1: Jogo Piloto.
3. Processo de Teste Aplicado ao Projeto de Portabilidade do Jogo Piloto O processo de teste desenvolvido para o projeto de portabilidade do jogo foi baseado na estratégia Exploratória de teste. Essa estratégia divide a atividade de teste em cinco elementos [Bach 2003]:
1
Exploração do Produto: esse elemento tem como objetivo principal ajudar o testador a entender os propósitos e funções do produto que está sendo testado. Ou seja, compreender os tipos de dados processados, as potenciais áreas de instabilidade do produto, dentre outras
Tap é a ação de pressionar ou tocar na tela do dispositivo.
características. É a partir dessa compreensão que o testador será capaz de fazer uma boa exploração no produto; Design de Teste: o objetivo principal deste elemento é determinar “o que será testado” com base na observação feita na atividade anterior (exploração do produto); Execução de Teste: responsável pela execução dos testes que foram identificados. É nessa fase que o produto é executado e a partir da execução é observado o comportamento; Heurística: são guias que ajudam o testador a decidir o que testar e como testar;
Resultados passíveis de revisão: as saídas, ou seja, os resultados observados no teste exploratório precisam ser reproduzíveis. Todo e qualquer testador precisa explicar e reproduzir qualquer resultado que tenha encontrado durante uma seção de teste exploratório.
Na Figura 2 é possível ver as etapas do processo de teste criado. Esse processo foi organizado em 6 etapas. Elas são: Identificação de GamePlay, Modelagem de GamePlay, Verificação de Gameplay, Execução de Testes, Cadastro de Falhas e Geração de Resumo de Falhas. Todos os detalhes dessas etapas serão discutidos nas seções seguintes. Cada etapa conta com uma série de características que ajudam a entender o que é a etapa de teste, por quem é executada, ferramentas de apoio e quais os resultados são esperados com a execução, por exemplo:
Responsável: papel do profissional responsável por executar a etapa de teste; Ferramenta usada: ferramenta utilizada para apoiar a execução da etapa de teste;
Objetivo: explicação sobre o objetivo da etapa de teste a fim de auxiliar a equipe de teste na execução da etapa; Resultado Esperado: explicação sobre o(s) resultado(s) esperado(s) com a execução da etapa de teste;
Além das 6 etapas, é possível ver, na Figura 2, a representação do ciclo de como as atividades aconteciam. Como se tratava de um projeto de portabilidade, as funcionalidades não sofreriam alterações, ou seja, 100% do que estava sendo executado no Windows Phone deveria ser executado no Android e IOS. Portanto as fases de Identificação de GamePlay, Modelagem de GamePlay e Verificação de Gameplay ocorreram apenas uma vez. As fases que variavam eram Execução de Testes, Cadastro de Falhas e Geração de Resumo de Falhas. A cada geração de release de teste eram executadas essas 3 etapas de teste. Enquanto houvessem falhas graves de gameplay que interferiam a jogabilidade do jogo, essas 3 etapas eram executadas continuamente.
Figura 2: Processo de Teste Executado.
3.1 Identificação de GamePlay A primeira etapa realizada se chama “Identificação do gameplay” do jogo, ou seja, do design de jogabilidade [Villas 2005]. O termo gameplay serve para identificar os requisitos ou aspectos estruturais e funcionais de um jogo [Hayashi 2013]. Essa etapa foi pensada com o mesmo objetivo do elemento “Exploração do Produto” do teste Exploratório. Logo, essa etapa serviu para dar uma base ao time de teste sobre o que era o produto, ou seja, projeto piloto. Com a identificação do gameplay, foi possível o planejamento dos testes, ou seja, a estruturação de atividades para que a execução fosse feita seguindo um roteiro planejado. Essa tarefa foi executada pelo líder de teste junto aos desenvolvedores do projeto. Essa etapa foi de extrema importância para o processo de teste, pois o resultado serviu de entrada para a atividade de modelagem do gameplay, a atividade seguinte. A execução dessa atividade resultou na identificação:
Da estrutura e regras do jogo; Dos comandos que faziam o personagem interagir com o ambiente; Dos obstáculos que causavam a morte ou perda de vida do personagem; Das regras de pontuação e vitória do jogo; De quais ações resultariam em uma baixa, média, boa e ótima pontuação no jogo; Das características externas ao jogo que poderiam interferir em seu funcionamento (interrupções do celular, por exemplo); Do fluxo de menus e funcionalidades associadas.
É importante ressaltar que essa etapa só foi necessária por conta de problemas no processo de desenvolvimento e teste da versão para Windows Phone. O processo de desenvolvimento contou com pouca documentação das regras, consequentemente o processo de teste estava
insuficiente e não refletia na verificação de 100% das funcionalidades do jogo. Por conta dos erros de processo no projeto “original”, essa fase foi necessária para planejamento e execução do processo de teste no projeto de portabilidade para IOS e Android. 3.2 Modelagem de GamePlay Após essa fase de identificação do que seria o jogo, foi feita a tarefa de “Modelagem de gameplay”. Essa etapa tem basicamente o mesmo objetivo do elemento “Design de Teste” do Teste Exploratório e consistiu em criar um mapa mental (em ingles, mind mapping) visual de como o jogo funcionava. Aqui foi definido o que seria testado. Na Figura 3 é exibido um exemplo de como o gameplay ficou modelado. Essa modelagem foi feita utilizando a ferramenta Free Mind [Freemind 2014] e foi feita pelo líder de teste com o suporte do testador.
comportamentos esperados do jogo fossem mapeados, escritos e de que ele atuasse como um guia na execução de Teste, pois o projeto não tinha uma documentação de requisitos padrão. Como se trata de um Processo de Teste para um projeto de portabilidade, observou-se que nenhuma das funcionalidades das versões das novas plataformas deveria ser diferente da versão do jogo em Windows Phone. Essa etapa foi importante para o processo, porque o antigo projeto de teste, para Windows Phone, estava mal especificado. Portanto, a etapa de modelagem serviu basicamente para dar uma direção correta para a equipe de teste, sobre o que deveria estar funcionando no jogo. Além disso, a organização em forma de mind map ajudou a equipe de desenvolvimento a identificar os defeitos.
A ideia de fazer esse passo de modelagem foi fazer com que todos os elementos de tela, fluxos e
Figura 3: Modelagem de Gameplay.
3.3 Verificação de Gameplay
3.4 Execução de Testes
Após a fase de modelagem do jogo, foi feita uma etapa de “Verificação do gameplay”. Neste momento o jogo foi executado em seu fluxo normal na plataforma Windows Phone. O foco principal dessa atividade era executar o jogo na plataforma “original” (Windows Phon), a fim de encontrar ajustes ou de garantir que a modelagem que seria executada nas outras plataformas, IOS e Android, estava coerente. Basicamente, essa etapa tinha dois propósitos: validar o modelo da etapa anterior e ajudar o testador a adquirir experiência prática de jogador explorando o gameplay do jogo na plataforma que ja possuía o jogo. Essa atividade foi executada tanto pelo líder de teste como pelo testador.
Etapa também inspirada na estratégia exploratória [Whittaker 2009]. Essa etapa servia para executar o projeto piloto nas plataformas IOS e Android a fim de colher resultados e observar o comportamento do jogo. Portanto, a execução foi feita levando em consideração aspectos mapeados das funcionalidades do jogo, características de performance de cada plataforma testada e falhas registradas na fase anterior. Essa fase contou com a execução dos testes por parte do líder de teste e do testador. Nessa etapa a equipe de teste estava bem preparada, pois contava com conhecimento prático de todo o gameplay do jogo por conta das etapas anteriores.
De forma prática, os testes foram feitos de forma manual seguindo uma espécie de checklist de validação. Esse checklist se baseava no mind map gerado na Seção 3.2, chamada de Modelagem do Gameplay. Esse checklist de validação foi utilizado para validar se existiam objetos em cena que estavam “quebrando” a física do jogo, validar se a interação entre o personagem do jogo e objetos disponíveis em cena estava correta, validar se todas as ilhas poderiam ser concluídas com qualquer pontuação, validar se era possível “zerar” o jogo, ou seja, concluir todas as ilhas com pontuação máxima (3 moedas), dentre muitos outros testes. Esse checklist era baseado nas “Heurísticas” mencionadas na Seção 3, que serviam para planejar hipóteses que viriam a ser validadas durante o funcionamento do jogo. A heurística utilizada para a confecção do checklist de validação foi a SFDPO, criada por James Bach:
S (structure): ajuda a entender “o que o produto é”, do ponto de vista de que arquivos ele usa, como foi construído, por exemplo; F (function): ajuda a entender “o que o produto faz”, quais as funcionalidades, quais os tratamentos de erros que o produto realiza, que tipo de interface o produto possui, por exemplo; D (data): ajuda a entender “quais dados o produto processa”, ou seja, qual a saída produzida pelo produto quando lê determinado tipo de dado, por exemplo. P (plataform): ajuda a entender “qual plataforma o produto depende”, ou seja, qual sistema operacional o produto é compatível, se há alguma configuração especial para o ambiente, dentre outros. O (operations): ajuda a entender “como o produto será usado”, ou seja, quem vai usar o produto, onde e como o produto será usado, com qual frequência será usado, dentre outros.
Além da execução dos testes exploratórios em forma de checklist seguindo a heurística SFDPO foram feitos seções de Play Testing no jogo. Estas seções serviam para validar a jogabilidade. Esse tipo de teste valida se o jogo está funcionando de forma adequada e intuitiva para o jogador [Shultz et. al. 2005]. Executando Play Testing foi possível validar se o jogo estava fácil ou difícil de ser concluído, validar se era fácil aprender a jogar, validar se os controles do jogo estavam intuitivos e se as dicas eram suficientes para deixar o jogador seguro ao jogar, validar se a tela do usuário estava sem controles que poderiam causar alguma confusão no jogador e principalmente validar se o jogo estava divertido. 3.5 Cadastro de Falhas Com o resultado da execução, as falhas foram cadastradas na ferramenta Jira. Essa ferramenta permite
a gerência e acompanhamento do ciclo de vida de pendências (issues) em um projeto. Essas pendências podem ser relativas a uma nova funcionalidade, uma sugestão de melhoria, uma falha, uma tarefa ou outras. É importante observar que todas as falhas cadastradas eram reproduzíveis, logo em cada falha eram registradas:
As pré-condições necessárias para a reprodução da falha; O passo a passo para reproduzir a falha; Imagens ou vídeos de como a falha era reproduzida.
No Jira, as falhas foram documentadas pelo líder e pelo testador levando em consideração a severidade (Critical, Major, Minor e Trivial) e plataforma (IOS e Android). As severidades das falhas eram consideradas conforme abaixo:
Critical: falhas que faziam o jogo fechar automaticamente. Essas falhas são conhecidas como “crash”. Essas falhas interrompiam o ato de jogar e o jogo não conseguia recuperar o estado anterior; Major: falhas que impactavam diretamente alguma funcionalidade. Ou seja, algo estava ocorrendo no jogo da forma que não deveria, por exemplo. Essas falhas interferiam no ato de jogar; Minor: falhas relacionadas a problemas pequenos que não interferiam no ato de jogar mas eram percebidas pelos jogadores; Trivial: falhas relacionadas a pequenos erros de interface que não interferiam no ato de jogar.
Além disso, as falhas referentes a melhorias e novas features eram separadas. Os status válidos das falhas no processo de gerenciamento de defeitos eram: Aberto, para as falhas encontradas; Reaberto, para falhas anteriormente fechadas, mas reabertas em uma futura release; Resolvido para aquelas falhas que foram corrigidas (desenvolvedores); Fechado, para as falhas validadas pela equipe de teste na versão corrente. As falhas também foram documentadas com o resultado esperado e com os passos de reprodução dos casos de teste que a identificou. Além disso, as falhas foram selecionadas e definidas a partir das categorias abaixo:
Desempenho: relacionadas a interrupções de sistema como eventos de background, SMS, ligação, uso de dados, uso de memória, gestos repetitivos; Funcionalidade: relacionadas às regras de pontuação, ação do personagem com relação aos objetos que causam danos ou não, interface do usuário, tradução (idioma inglês e português), fluxo do jogo, ou seja, todos os requisitos funcionais do gameplay.
Vale a pena ressaltar que a maioria das falhas reportadas ocorria apenas nas versões portadas e não na original, excetuando algumas melhorias que foram sugeridas e que ocorriam também na versão para Windows Phone.
e quatro versões candidatas para IOS. Um resumo geral das falhas encontradas por plataforma pode ser visto na Tabela 1. Com isso, concluiu-se que a versão em Android sofreu mais modificações e permaneceu mais instável do que a versão para IOS. Tabela 1. Resultados Gerais dos bugs registrados
3.6 Geração de Resumo de Falhas Finalmente, após a documentação das falhas da versão corrente, o líder com o suporte do testador faziam um resumo da execução e das falhas para a equipe de desenvolvimento. Esse relatório continha basicamente a descrição da falha encontrada e um relato do testador sobre a experiência com o jogo e sua fluência na plataforma testada. As informações compartilhadas nesse relatório eram:
Descrição resumida das funcionalidades testadas; Identificador da versão testada; Plataforma testada (Android ou IOS); Modelo do aparelho; Resolução do aparelho; Identificador do testador; Lista de defeitos; Comentários gerais sobre a experiência da jogabilidade. Normalmente para identificar pontos de melhoria no gameplay; Métricas de execução, por exemplo: o Funcionalidade com mais defeito; o Funcionalidade com menos defeito; o Defeitos reabertos; o Novos Defeitos;
O principal objetivo dessa etapa era informar todos do projeto, ou seja, desenvolvedores e gerente de projetos, sobre a situação de falhas e melhorias do jogo. Os números gerados na fase de execução, cadastro de falhas e geração de resumo de falhas podem ser vistos nos resultados.
4. Resultados Ao final dos testes executados do jogo, foram registrados um total de 68 issues do Android e IOS. Das issues relacionadas ao projeto de portabilidade (Android e IOS) 88,24%, ou seja 60 isssues, eram realmente falhas a serem corrigidas, cerca de 4,41% eram melhorias e 7,35% foram respondidos pelos desenvolvedores como não sendo falhas, mas sim comportamento esperado. Destes 60 issues que foram classificadas como falha, cerca de 10%, que representam 6 falhas, ocorriam tanto na plataforma Android como IOS, aproximadamente 25% ocorriam apenas na plataforma IOS e 65% das falhas ocorriam apenas na plataforma Android. Ao todo foram analisadas oito versões candidatas para Android
Plataforma
Total de falhas
%
IOS
15
25
Android
39
65
IOS e Android
6
10
Os resultados encontrados no projeto, levando em consideração as categorias definidas no processo de registro de falhas, podem ser acompanhados na Tabela 2. Foi observado que dentre os problemas reportados, 69,12% estavam relacionados à funcionalidade, e destes, a maioria afeta subcategorias essenciais em um jogo: UI, jogabilidade e fluxo de funcionalidade (caminho feliz). Do total de problemas relacionados ao desempenho (19,12%), a maioria destes ocorreu por conta de ações externas ao jogo, ou seja, interrupções do sistema (eventos de background) como bloqueio e desbloqueio do celular, recebimento de ligação e mensagem, uso do jogo com vários aplicativos abertos ao mesmo tempo, comportamentos estes que acontecem de forma constante quando se trata de um smartphone. O restante não era falha (7,35%) ou era melhoria (4,41%) e não está representado na Tabela 2. Tabela 2. Resultados por Categoria
Categoria
Desempenho
Funcionalidade
Subcategoria Memória Eventos de Background Eventos repetitivos Fluxo UI Jogabilidade Som Idioma
Total de falhas 3 8
%
19,12
2 15 17 9 5 1
69,12
Analisando os problemas a partir da severidade das falhas, foram obtidos os resultados mostrados na Tabela 3. Pode ser observado que 30% das falhas possuíam severidade Major e Critical e a grande maioria dessas falhas estava relacionada ao uso de memória, interrupções de sistema, eventos repetitivos, fluxo de funcionalidade e jogabilidade, características essas essenciais em um aplicativo de jogo. Tabela 3. Resultados por Severidade
Categoria
Severidade
Total de falhas
%
Desempenho
Funcionalidade
Trivial Minor Major Critical Trivial Minor Major Critical
0 5 3 5 11 26 8 2
8,33 5 8,33 18,33 44,66 13,33 3,33
5. Conclusões Analisando a literatura de desenvolvimento de jogos segundo Flood (2013) e Petrillo (2008), pode ser concluído que muitos documentos de postmortems reportam resultados similares a esse projeto piloto. Postmortem é um documento escrito após o término de um projeto de desenvolvimento de jogo. Nesse documento são descritas as experiências e as sugestões de melhorias para futuros projetos. Geralmente é relatado o que deu certo e o que deu errado no projeto do jogo. Os principais problemas encontrados na indústria de jogos são:
Prazo extrapolado; Existência de muitas falhas; Requisitos incompletos; Falta de recursos; Expectativas irreais; Falta de planejamento; Mudança de requisitos; Orçamento extrapolado;
Muito dos problemas encontrados nesse projeto foram relacionados à grande quantidade de falhas e a complexidade dos mesmos em serem resolvidos. Com a adoção do processo de teste apresentado neste relato, a equipe de teste obteve os seguintes benefícios práticos:
Rapidez na documentação do gameplay com a etapa de “Identificação do Gameplay” e “Modelagem do Gameplay”. Essa etapa foi necessária porque a documentação feita para o projeto do jogo em Windows Phone continha falhas na especificação do jogo e do teste; Agilidade no processo de correção e priorização de falhas. Esse benefício foi observado por conta da modelagem de teste. O formato da modelagem em mind map ajudou o time de desenvolvimento a identificar os possíveis locais aonde os defeitos estavam; Mapeamento de fluxo de falhas a partir de fatores externos ao jogo (interrupções do sistema). Foi constatado que esse tipo de falhas relacionado a fluxo ocorria de forma mais frequente em telas de loading (exemplo: abertura do jogo, fluxo do menu para fase, fluxo da fase para o menu, fluxo de fase para
fase) ou quando o jogo era configurado para mudo; Muitas falhas relacionadas à API utilizada para portabilidade (monogame) foram encontradas devido aos testes de desempenho executados. Com isso, os desenvolvedores tiveram que fazer modificações no código nativo da API (Monogame) a fim de minimizar o impacto das falhas no jogo;
O objetivo do projeto de portabilidade era de servir como um chamariz para a segunda versão do jogo que seria lançado para as três plataformas citadas. E, devido a um otimismo excessivo em relação à plataforma, o projeto foi estimado com um cronograma comprimido. Com o resultado dos testes mostrando graves problemas de desempenho, que resultavam em “crashes” ou atrapalhavam a experiência do jogador foi possível identificar a instabilidade em que o jogo se encontrava nas novas plataformas. Sendo assim, o resultado dos testes somado ao fato de algumas correções gerarem uma grande quantidade de side effects fez com que fosse percebida a impossibilidade da entregar de um produto viável no prazo estabelecido. Após muitas idas e vindas de versões candidatas e da priorização de outros projetos, foi decidido com o time gerencial e de desenvolvimento que o projeto de portabilidade deveria ser cancelado. Dentre todos os problemas citados, o principal motivo foi pelo fato de que muitas falhas encontradas fugiam do domínio da codificação do jogo e seria perda de tempo continuar corrigindo código de fontes externas (API do monogame) para tentar entregar o jogo ao mercado.
6. Referências ATLASSIAN. Jira (2014) “Bug and Issue Tracker”, http://www.atlassian.com/software/jira, acessado em abril de 2014. BETHKE, E. (2003) “Game Development and Production. Plano: Wordware Publishing”, acessado em abril de 201. BLOW, J. (2004) “Game Development: Harder thank you think”. Queue, ACM, New York, USA, v. 1, n. 10, p. 2837. BACH, J. (2003) “Exploratory Testing Explained”, http://www.satisfice.com/articles/et-article.pdf, acessado em abril de 2014. BNDES (2014) “Relatório Final – Mapeamento da Indústria Brasileira e Global de Jogos Digitais”,http://www.bndes.gov.br/SiteBNDES/bndes/bn des_pt/Galerias/Arquivos/conhecimento/seminario/semin ario_mapeamento_industria_games042014_Relatorio_Fi nal.pdf, acessado em abril de 2014. CALLELE, D.; NEUFELD, E.; SHNEIDER, K. (2005) “Requirements engineering and the creative process in the video game industry. In: 13th IEEE International Conference on Requirements Engineering”. DC, USA: IEEE Computer Society.
SHULTZ, C.; BRYANT, R. AND LANGDELL, T. (2005) “Game Testing All In One”. United States: Thomson/Course Technology. States: Thomson/Course Technology. CODEPLEX PROJECT HOSTING FOR OPEN SOURCE SOFTWARE (2014) “Code Talks – Let your voice be heard”, https://www.codeplex.com/, acessado em abril de 2014. FREEMIND (2014) “Features” http://freemind.sourceforge.net/wiki/index.php/Main_Pag e, acessado em abril de 2014. FLOOD, L. (2003) “Game unified process”, http://www.gamedev.net/page/resources/_/technical/gene ral-programming/game-unified-process-r1940, acessado em abril de 2014. HAYASHI, S. (2013) “Psicologia dos Games”. In II Congresso de Design do Amazonas. IDC (2013) “Mercado brasileiro de celulares”, http://www.idcbrasil.com.br/releases/news.aspx?id=1458 , acessado em abril de 2014. VILLAS, R. (2005) “Mercado de Jogos”. In: Azevedo, E. (Ed.), Desenvolvimento de Jogos 3D e Aplicações em
Realidade Virtual, pp. 1-28. Elsevier: Campus. Rio de Janeiro. MONOGAME – WRITE ONDE, PLAY EVERYWHERE (2014) “One framework for creating powerful cross-platform games”, http://www.monogame.net/, acessado em abril de 2014. PETRILLO, F. (2008) “Práticas Ágeis no Processo de Desenvolvimento de Jogos eletrônicos”, http://www.lume.ufrgs.br/handle/10183/22809, acessado em abril de 2014. SPARTA GAME FRAMEWORK (2014) “Speed up game production”, http://indtspartagameframework.codeplex.com/, acessado em abril de 2014. XNA GAME STUDIO LIBRARY (2014) “Gerring Started with XNA Game Studio Development”, http://msdn.microsoft.com/en-us/aa937791.aspx, acessado em abril de 2014. WHITTAKER, J. A. (2009) “Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design”. Addison-Wesley Professional, 2009.
