UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO

SUL
DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS
CURSO DE CIÊNCIA DA COMPUTAÇÃO

AUGUSTO DE VARGAS VON GRAFEN

ENGENHARIA DE SOFTWARE NO PROCESSO DE DESENVOLVIMENTO DE

JOGOS

Ijuí
2019
 2

AUGUSTO DE VARGAS VON GRAFEN

ENGENHARIA DE SOFTWARE NO PROCESSO DE DESENVOLVIMENTO DE

JOGOS

Projeto de pesquisa apresentado como

requisito para aprovação na disciplina de
Trabalho de Conclusão de curso de Ciência da
Computação da Universidade Regional do
Noroeste do Estado do Rio Grande do Sul.

Orientador: Prof. Me Marcos Ronaldo Melo

Cavalheiro

Ijuí
2019
 SUMÁRIO

1 DADOS DE IDENTIFICAÇÃO DO PROJETO ...................................................... 4

2 TEMA.................................................................................................................... 4
2.1 ENGENHARIA DE SOFTWARE NO
PROCESSO DE DESENVOLVIMENTO DE
JOGOS ..................................................................................................................... 4
3 DELIMITAÇÃO DO TEMA .................................................................................... 5
4 FORMULAÇÃO DO PROBLEMA......................................................................... 5
5 JUSTIFICATIVA ................................................................................................... 6
6 OBJETIVOS ....................................................................................................... 10
6.1.1 OBJETIVO GERAL ..................................................................................... 10
6.1.2 OBJETIVOS ESPECÍFICOS ....................................................................... 10
7 EMBASAMENTO TEÓRICO............................................................................... 11
7.1 ENGENHARIA DE SOFTWARE .................................................................. 11
7.2 DESENVOLVIMENTO DE JOGOS ............................................................. 21
7.3 DESENVOLVIMENTO DE JOGOS E A
ENGENHARIA DE SOFTWARE ............................................................................. 25
8 METODOLOGIA ................................................................................................. 27
8.1 MÉTODO DE ABORDAGEM....................................................................... 27
8.2 TÉCNICAS DE PESQUISA ......................................................................... 27
9 CRONOGRAMA ................................................................................................. 28
10 PROPOSTA DE SUMÁRIO PARA O TCC ......................................................... 29
11 REFERÊNCIAS .................................................................................................. 30
 4

1 DADOS DE IDENTIFICAÇÃO DO PROJETO

Será desenvolvido pelo acadêmico de Ciência da Computação da Universidade

Regional do Noroeste do Estado, Augusto de Vargas Von Grafen e orientado pelo
professor Me. Marcos Ronaldo Melo Cavalheiro, o estudo de boas práticas utilizadas
no processo de desenvolvimento de jogos e sua relação com a engenharia de
software.

2 TEMA

2.1 ENGENHARIA DE SOFTWARE NO PROCESSO DE DESENVOLVIMENTO

DE JOGOS

O desenvolvimento de jogos, assim como o desenvolvimento de outros

softwares, apresenta desafios em seu processo como um todo e apesar de sua
importância, a falta de pesquisa sobre a engenharia de software voltada para jogos
deixa lacunas em aberto. Segundo Emerson e Thomas que em seus estudos
trabalharam para descobrir se o desenvolvimento de jogos é realmente diferente da
tradicional forma de desenvolvimento da engenharia de software, e assim como para
a maioria das questões, a resposta é de que há diferenças em certos aspectos, mas
também situações similares em outros. (MURPHY-HILL; ZIMMERMANN, 2014)
Ao contrário do software tradicional, o desenvolvimento de jogos tende a
trabalhar uma forma diferente de entrega para seus clientes, com seu foco mais
sobre o “sentir” do que sobre o “fazer”, criando uma diferença significativa na hora
de desenvolvimento do projeto, dimensionamento das prioridades, recursos e
investimentos. Outro fator relevante a ser considerado é a manutenibilidade, que
envolve os processos de testes, atualizações e revisões ao qual para manter um
público interessado a continuar consumindo tende a usar um viés diferente de
planejamento, um grande desafio diferentes do software convencional.
 5

3 DELIMITAÇÃO DO TEMA

A partir de documentações que descrevem pontos fortes e fracos na

implementação de jogos já finalizados (postmortem) por companhias de pequeno a
grande porte, propor novas ferramentas, métodos e processos que ajudem a
aumentar a velocidade, eficácia e qualidade na criação de jogos, minimizando os
riscos para o negócio.

4 FORMULAÇÃO DO PROBLEMA

O cenário de jogos vem crescendo gradualmente ao longo dos anos, e vem

ganhando grande importância no mercado de software no mundo. Junto deste
crescimento, os recursos necessários para o desenvolvimento de jogos, seja em
questão de orçamento, tamanho de código ou estrutura de equipe, aumentou e está
equivalente ou até excedente aos empreendimentos de software tradicionais (JR et
al., 2016).
Os jogos são, devido a sua grande expansão tecnológica, uma das formas mais
sofisticadas e complexas de software, fazendo com que a multidisciplinaridade se
faça presente perante a quantidade de profissionais, com competências distintas,
necessários nesse tipo de desenvolvimento (POLITOWSKI, 2017).
Deixando de ser apenas questão de diversão, os jogos vêm sendo utilizados no
auxílio do aprendizado nas escolas, centros médicos e em simulações que se
tornaram caras devido a sua aplicação. Desta forma há uma necessidade crescente
de estudos sobre a padronização ou boas práticas no processo de desenvolvimento
de jogos e que possa garantir qualidade e menos desperdício já que na maioria das
vezes, comparado ao desenvolvimento de software tradicional, esse ecossistema
necessita de maiores investimentos sendo ele humano e ou computacional
(KANODE; HADDAD, 2009).
Com base nisso o presente estudo se dará em responder a seguinte questão:
Existem boas práticas no processo de desenvolvimento de jogos que atendam as
mesmas questões no desenvolvimento de software tradicionais? Qual a relação
delas com a Engenharia de Software?
 6

5 JUSTIFICATIVA

Com uma história de aproximadamente 50 anos após o primeiro videogame

lançado, os jogos se tornaram um dos maiores meios de diversão existentes na
humanidade. Sendo uma das formas de mídia mais completas nos dias de hoje,
tendo como objetivo não só entregar entretenimento mas também novas formas de
criar, simular e ensinar processos que seriam custosos, difíceis ou impossíveis de
serem executados em realidade física e que motivariam desinteresse pela rotina
monótona em que estariam submetidos (AMPATZOGLOU; CHATZIGERORGIOU,
2007; VALIN, 2013;).
Desta forma, o mercado de jogos segue expandindo-se nacional e
internacionalmente, superando até o mercado do cinema e da música devido ao
crescente aumento tecnológico e a descentralização dos meios de jogos eletrônicos
por conta da ascensão dos dispositivos mobile. A partir daí, há uma expectativa de
gerar quase $90 bilhões de dólares para 2020 em comparação aos $78.61 bilhões
gerados em 2017 pela indústria de jogos, sendo um aumento significativo de 12% ao
longo de três anos. (BNDSGEDIGAMES, 2014; WEPC, 2019).
No Brasil em 2018, segundo o site NewZoo (2017) a indústria chegou a
arrecadar aproximadamente $1.5 bilhão de dólares nesse mercado, sendo o 13º do
ranking mundial. Além dos ganhos de mercado há também uma quantidade
significativa de público que consome esse tipo de conteúdo e retorna esses
resultados para a economia mundial, no cenário brasileiro isso equivale a um público
de 63.3 milhões em 2017 e 75.7 milhões em 2018, um aumento de 16,4% de um
ano para o outro. Com essa perspectiva podemos notar a importância do
desenvolvimento de jogos para o mercado (NEWZOO, 2018).
Em uma pesquisa efetuada por Standish Group foi constatado que 30% dos
projetos são cancelados antes mesmo de serem finalizados, além disso 53% dos
projetos tem o seu custo excedido em quase duas vezes o proposto inicialmente e
apenas 16% dos projetos são finalizados de acordo com o que foi estimado desde o
seu nascimento com a sua totalidade de funcionalidades planejadas. Os erros
causadores destas estatísticas por muitas vezes não são devidamente tratados e
acabam por se repetirem em novos projetos (CLANCY, 1995).
 7

Com isso, as formas de produzir um jogo vem se tornando diferentes do que

eram nos primórdios, o tamanho e a complexidade de desenvolvimento vem sendo
maiores com o passar do tempo e exigindo cada vez mais das equipes do projeto,
gerando custos e riscos cada vez maiores para as organizações desse tipo de
mercado. Esses aspectos de crescimento se dão através da própria indústria, onde
o público solicita diariamente por novos tipos de jogabilidade, mapas maiores e mais
bonitos, músicas de alta qualidade e de grandes produções, para que entreguem
maior imersibilidade resultando na continuidade e interesse de consumo por parte do
solicitante. Sendo necessário, ao contrário do que era, maior quantidade de pessoas
de áreas distintas no desenvolvimento e exigindo destes conhecimentos altamente
específicos em suas áreas de atuação, o que tornou o desenvolvimento de jogos
algo multidisciplinar e com maior complexidade (ALBINO; SOUZA; PRADO, 2014).
A partir disso, criou-se a necessidade de gerenciar as equipes e as etapas
existentes no desenvolvimento de jogos através de metodologias que entregassem
um processo de produção mais eficiente e que diminuíssem as grandes chances de
problemas durante o desenvolvimento, que como consequências podem resultar em
perda de tempo, investimento e podendo chegar ao cancelamento do projeto. Sendo
assim, estas metodologias embarcariam benefícios como a otimização de tempo,
custo e qualidade, recebendo como contrapartida a minimização da quantidade de
erros que poderiam se fazer presente no jogo (CLANCY, 1995).
Para auxiliar os desenvolvedores a evitar problemas durante o decorrer de seus
projetos, os postmortems, usados na indústria de jogos com foco em documentar as
experiências obtidas através de projetos já finalizados pelos próprios
desenvolvedores. Indicam aspectos positivos e negativos no ciclo de
desenvolvimento, sendo uma das únicas formas existentes para a coleta de
informações dessa espécie. Essa documentação se faz de suma importância, pois
induz que os membros das equipes reconheçam e lembrem-se do que aprenderam
durante os projetos que participaram, compartilhando individualmente suas
experiências com o time e também com times de outros projetos (HAMANN, 2013;
BIRK; DINGSOYR; STALHANE, 2002).
Apesar de sua relevância para o mercado, a pesquisa em âmbito acadêmico no
desenvolvimento de jogos se faz pouco presente. Em dois anos de pesquisa
efetuadas em 116 projetos de engenharia de software, JR et al. (2016) constataram
 8

que apenas três destes eram focados em jogos, número que representa uma
parcela de apenas 2,6% do todo, justificando assim uma necessidade inerente de
maiores estudos sobre o assunto. Esses mesmos números demonstram por outro
lado a grande importância que a engenharia de software tem nos processos de
desenvolvimento dos programas tradicionais, pois através de sua utilização geram-
se diretrizes definindo o que deverá ser feito para atender os objetivos do produto,
para que o mesmo chegue em seu estado final com o custo e tempo definidos
inicialmente, sendo a boa gestão algo fundamental e indispensável (HIRAMA, 2012).
No entanto, a aplicação da engenharia de software é dificultada, principalmente
para pequenas e novas empresas. As demandas solicitadas exigem alta
administração das organizações sobre o setor de tecnologia da informação quanto
aos prazos que não são atendidos, custos elevados para os projetos, sistemas
antigos que solicitam muita manutenção e a falta de profissionais qualificados na
hora do recrutamento. Os erros e falhas encontradas durante o uso do sistema, que
não tiveram a devida administração de metodologias da engenharia de software,
causa para os usuários além da perda de tempo, reclamações perante a
necessidade de correções e melhorias com alto custo de implementação e tempo.
Para os desenvolvedores a satisfação em relação a sua produtividade perante ao
seu conhecimento é relativamente baixa, sentem-se insatisfeitos com a qualidade
final do produto, inseguros devido a pressão geradas pelos orçamentos e prazos de
entrega mal planejados e que por fim acabam por criar resistência na hora de adotar
novas tecnologias afetando diretamente no desempenho de novas qualificações em
relação ao mercado (WAZLAWICK, 2013).
Desta forma, o presente trabalho justifica-se na necessidade de reunir maiores
formas de facilitar o processo de implementação e produção de jogos em geral.
Através do levantamento bibliográfico identificar boas práticas no desenvolvimento
de games, tais quais ferramentas, métodos, resolução de problemas e dados que
possam ser úteis para a comunidade desse tipo de desenvolvimento. Também
possibilitará maiores engajamentos para trabalhos futuros tanto para a área de
desenvolvimento quanto para a área da pesquisa que se faz pouco presente de um
modo geral (JR et al., 2016).
Este estudo será de suma importância para o acadêmico, pois possibilitará
agregar conhecimento sobre a relação da engenharia de software e o
 9

desenvolvimento de jogos. A definição do tema se dá por afinidade com a área de

qualidade do produto, a vontade de facilitar os processos para que haja menores
desperdícios de tempo e dinheiro, além de expandir o conhecimento sobre o
assunto.
Para as empresas do ramo o presente estudo trará formas e ferramentas que
poderão ajudar na velocidade do processo de desenvolvimento, contendo um breve
guia sobre metodologias que tiveram sucesso bem como quais práticas não são
aconselháveis perante ao cenário atual, podendo em decorrência desses aspectos
gerar novas formas de lucro e menores riscos para os projetos de antigas e novas
empresas. Desta forma também, ajudar na expansão do desenvolvimento de jogos
na região fortalecendo socioeconomicamente com a possibilidade de novas
empresas do ramo que em resultado irão contribuir na geração de novos empregos
e fontes de renda.
 10

6 OBJETIVOS

6.1.1 OBJETIVO GERAL

Reunir a maior quantidade de informações sobre projetos de desenvolvimento

de jogos e gerar uma proposta de guia para o desenvolvimento desse tipo de
aplicação, facilitando o trabalho árduo que necessita de grande experiência
específica.

6.1.2 OBJETIVOS ESPECÍFICOS

• Analisar os processos usados em projetos de desenvolvimento de jogos

disponibilizados após o seu encerramento (postmortem);
• Analisar ligação com os processos indicados na engenharia de software;
• Analisar resultados que deram e não deram certo nos projetos;
• Gerar documentação, com o intuito de entregar melhorias para os
futuros projetos de jogos de antigas e novas empresas;
 11

7 EMBASAMENTO TEÓRICO

7.1 ENGENHARIA DE SOFTWARE

O software tem papel fundamental na sociedade, pois é ao mesmo tempo em

que é um produto, este também é o veículo para distribuição do produto. Quando
trata-se de produto, este está representado pelo hardware, ou seja, pelo computador
e outros equipamentos, tais como tablets, celulares, etc. O software transmite e
transforma informações, que podem ser simples ou complexas. Já quando refere-se
a veículo de distribuição do produto, este atua como a base para o controle do
computador, a comunicação de informações, criação e controle de outros programas
(PRESSMAN; MAXIM, 2016).
Segundo Pressman e Maxim (2016, p. 4), a descrição de software consiste em:
(1) instruções (programa de computador) que, quando executadas,
fornecem características, funções e desempenho desejados; (2) estruturas
de dados que possibilitam aos programas manipular informações
adequadamente; e (3) informação descritiva, tanto na forma impressa
quanto na virtual, descrevendo a operação e o uso dos programas.

A principal diferença entre software e hardware está relacionada ao desgaste,

pois quando um componente do hardware se desgasta, este precisa ser substituído
por outra peça. Já no software não existe essa possibilidade, no qual cada defeito
representa um erro no projeto ou no processo, o qual foi traduzido em código de
máquina. Desta forma, as rotinas que envolvem manutenção, são
consideravelmente mais complexas nos softwares (PRESSMAN; MAXIM, 2016).
A engenharia é uma ciência que aplica o conhecimento das áreas de ciências
naturais e matemáticas com as vivências obtidas, bem como através das práticas
desenvolvidas em projetos reais. Assim, tem-se como especialidade a engenharia
de software que segundo Sommerville (2011, p. 5) “é uma disciplina de engenharia
cujo foco está em todos os aspectos da produção de software, desde os estágios
iniciais da especificação do sistema até sua manutenção, quando o sistema já está
sendo usado.” Ou seja, existe a preocupação não somente com os processos
técnicos do desenvolvimento de software, mas também com o gerenciamento de
projeto e desenvolvimento de ferramentas, metodologias e estudos para auxiliar a
produção.de software.
 12

Além disso, a maioria das pessoas tem o entendimento de que software é um

apenas um programa de computador, sendo este muito mais complexo. O autor
Sommerville (2011, p. 3) afirma que:
Engenharia de software não se trata apenas do programa em si, mas de
toda a documentação associada e dados de configurações necessários
para fazer esse programa operar corretamente. Um sistema de software
desenvolvido profissionalmente é, com frequência, mais do que apenas um
programa; ele normalmente consiste em uma série de programas separados
e arquivos de configuração que são usados para configurar esses
programas. Isso pode incluir documentação do sistema, que descreve a sua
estrutura; documentação do usuário, que explica como usar o sistema; e
sites, para usuários baixarem a informação recente do produto.

Segundo Rezende (2005 apud Carvalho; Chiossi, 2001) a engenharia de

software refere-se a uma área do conhecimento que engloba metodologias, métodos
e ferramentas para sua utilização desde o ponto de percepção do problema até a
etapa em que o sistema desenvolvido deixa de ser operacional, e passa a resolver
problemas oriundos ao processo de desenvolvimento e ao produto de software.
A engenharia de Software se faz de suma importância pelos seguintes motivos:
1) cada vez mais as pessoas dependem de sistema de software avançados,
confiáveis e ágeis; 2) na maioria das vezes é financeiramente mais barato a longo
prazo, no sentido de utilizar métodos e técnicas da engenharia de software para
sistemas de software, ao invés de se escrever programas como um projeto pessoal.
Sendo que, de forma geral o maior custo é mudar o software depois que ela entra
em processo de usabilidade (SOMMERVILLE, 2011).
Conforme Sommerville (2011), a abordagem sistemática utilizada na engenharia
de software, é retratada na maioria das vezes como, processo de software, sendo
este um conjunto de operações que geram um produto de software. O autor cita que
existem quatro ações essenciais comuns a todos os processos de software, sendo
elas:
1. Especificação de software, em que clientes e engenheiros definem o
software a ser produzido e as restrições de sua operação. 2.
Desenvolvimento de software, em que o software é projetado e programado.
3. Validação de software, em que o software é verificado para garantir que é
o que o cliente quer. 4. Evolução de software, em que o software é
modificado para refletir a mudança de requisitos do cliente e do mercado
(SOMMERVILLE, 2011, P. 5-6)
 13

7.1.1 MODELOS DE PROCESSO DE SOFTWARE

O modelo de software segundo Sommerville (2011) é uma visão simples do

processo de software. Onde o modelo indica apenas uma parte particular do
processo, informando somente dados parciais sobre ele. Ainda, conforme relata o
autor, existem variados tipos de processos de software, mas todos devem possuir
quatro atividades fundamentais para a engenharia de software. O primeiro está
relacionado a especificação de software, no qual a sua funcionalidade e restrições
precisam ser definidas. Em segundo, há o projeto e implementação de software, que
está relacionado a produção do software para atendimento das especificações
relatadas na etapa anterior. Em terceiro, tem-se a validação de software, o qual
envolve a aprovação para garantir sua funcionalidade e que atenda a demanda do
cliente. E por último, a evolução do software, que nada mais é do que a constante
melhoria do software para atender as necessidades de mudanças do cliente.
A escolha de um modelo de processo está diretamente ligada às características
do projeto. Desta forma, é de suma importância conhecer alguns modelos de
processos e em quais situações estes são aplicáveis. A seguir, serão apresentados
os principais modelos, são eles: modelo cascata, desenvolvimento incremental e
engenharia de software orientada a reuso.

7.1.1.1 MODELO CASCATA

O modelo em cascata é o mais antigo e mais amplamente usado. Segundo

Sommerville (2011), este modelo é chamado de modelo cascata devido ao
encadeamento entre as suas etapas. Este é processo focado a planos, ou seja, há o
planejamento e programação das atividades do processo antes de se iniciar.
Segundo NIELSEN e NODDER (2008), esta abordagem sequencial foi projetada
com o propósito de assegurar que nenhuma etapa seja esquecida antes que o
projeto passe para a próxima fase. Na teoria, elaborar todo o design antes de iniciar
o desenvolvimento propriamente dito, diminuiria a necessidade de retrabalho.
O modelo cascata possui cinco fases, denominadas como estágios: definição de
requisitos; projeto de sistema e software; implementação e teste unitário; integração
 14

e teste de sistema; e operação e manutenção, conforme ilustrado na Figura X. As

etapas são executadas em ordem sequencial e sistemática, no qual uma nova etapa
só pode ser iniciada após a finalização da anterior. Sendo assim, é fundamental que
especificação dos requisitos, pois somente ao final do projeto será possível analisar
uma mudança no processo (SOMMERVILLE, 2011).

Figura 1 - Modelo Cascata

Fonte: Sommerville, p. 20, 2011.

A seguir, a definição de cada fase do modelo cascata, segundo Sommerville

(2011).
• Análise e definição de requisitos: envolve o mapeamento dos
requisitos do sistema e usuários, definindo os serviços, restrições e
objetivos.
• Projeto de sistema e software: definição de uma arquitetura geral do
sistema (requisitos do sistema de hardware e software), através da
identificação e descrição da estrutura de dados.
• Implementação e teste de unidade: etapa em que o projeto de software
é realizado como um conjunto de programas. O teste unitário está
relacionado ao processo de codificar, no qual é necessário verificar se
casa unidade está funcionando adequadamente, conforme suas
especificações.
 15

• Integração e teste de sistema: as unidades individuais são integradas e

testadas, a fim de verificar se os requisitos foram atendidos. Após
finalizados os testes, o software está apto para ser entregue ao cliente.
• Operação e manutenção: etapa em que o sistema é instalado e
colocado em operação. A manutenção está ligada a correção de erros
que não foram identificados em fases iniciais e a adaptação de novos
requisitos, conforme sua identificação.
O processo de software envolve o feedback de uma etapa para a outra, não
sendo um modelo linear simples. Sendo que, os documentos gerados em cada
etapa podem ser alterados para demonstrarem as alterações realizadas em cada um
deles. Conforme afirma Sommerville (2011, p. 21):
Por causa dos custos de produção e aprovação de documentos, as
iterações podem ser dispendiosas e envolver significativo retrabalho. Assim,
após um pequeno número de iterações, é normal se congelarem partes do
desenvolvimento, como a especificação, e dar-se continuidade aos estágios
posteriores de desenvolvimento. A solução dos problemas fica para mais
tarde, ignorada ou programada, quando possível. Esse congelamento
prematuro dos requisitos pode significar que o sistema não fará o que o
usuário quer. Também pode levar a sistemas mal estruturados, quando os
problemas de projeto são contornados por artifícios de implementação.

Por fim, o autor retrata que o modelo em cascata deve ser utilizado apenas em
casos que existe a compreensão dos requisitos e estes possuem pouca
probabilidade de serem alterados durante o desenvolvimento do sistema. Entretanto,
este modelo reflete o tipo de processo usado em outros projetos de engenharia. Em
virtude da facilidade em utilizar modelos de gerenciamento comum para o projeto,
processos de software fundamentados no modelo cascata ainda são utilizados com
frequência (SOMMERVILLE, 2011).

7.1.1.2 DESENVOLVIMENTO INCREMENTAL

Segundo Sommerville (2011), o desenvolvimento incremental é fundamentado

na idealização de desenvolver uma implementação inicial, colocá-lo a disposição
dos usuários para avaliação e a partir disso, continuar a criar várias versões até que
um sistema adequado seja desenvolvido. As atividades de especificação,
desenvolvimento e validação são alternadas entre si, e não separadas, com
 16

feedback rápido entre todas as atividades. Na figura X, tem-se a representação

gráfica deste modelo.

Figura 2 - Desenvolvimento Incremental

Fonte: Sommerville, p. 22, 2011.

O desenvolvimento incremental de software é uma parte essencial das

abordagens ágeis, sendo melhor que o modelo cascata para a maior parte dos
sistemas de negócios, e-commerce e sistemas pessoais. Segundo Sommerville este
modelo (2011, p. 22) “reflete a maneira como resolvemos os problemas. Raramente
elaboramos uma completa solução do problema com antecedência; geralmente
movemo-nos passo a passo em direção a uma solução, recuando quando
percebemos que cometemos um erro.” Sendo assim, torna-se mais barata e fácil de
fazer mudanças quando se está em processo de desenvolvimento.
Conforme retrata Pressman (2016, p. 44) “o modelo incremental aplica
sequências lineares de forma escalonada, à medida que o tempo vai avançando.
Cada sequência linear produz “incrementos” entregáveis do software”.
O desenvolvimento incremental possui três vantagens em comparação ao
modelo cascata, são elas: 1) custo de acomodação das mudanças e quantidade de
análise e documentação é menor. 2) facilidade em obter feedback dos clientes sobre
o desenvolvimento do sistema. 3) entrega e implementação mais rápida de um
software útil ao cliente, mesmo com suas funcionalidades não finalizadas. Em
contrapartida, do ponto de vista do gerenciamento, o modelo incremental tem
 17

problemas. Primeiro, o processo não é visível e os gestores acabam precisando de

entregas regulares para mensurar o progresso. Logo, se o sistema é desenvolvido
muito rápido, economicamente não é viável gerar documentos que demonstrem
casa uma das versões do sistema. E por segundo, tem-se a estrutura do sistema, a
qual tem tendência a se desgastar com a inclusão de novos incrementos
(SOMMERVILLE, 2011).
Desta forma, conforme afirma Sommerville (2011, p. 22) “os problemas do
desenvolvimento incremental são particularmente críticos para os sistemas de vida-
longa, grandes e complexos, nos quais várias equipes desenvolvem diferentes
partes do sistema”. Ou seja, tais estruturas necessitam de uma arquitetura estável, e
com responsabilidade minuciosamente definidas, o qual deve ser planejado com
antecedência, não sendo favorável o desenvolvimento de forma incremental.

7.1.1.3 ORIENTADA A REUSO

O reuso de software está presente na maioria dos projetos de software, pois

quando se tem pessoas que sabem de projetos ou códigos semelhantes ao que é
solicitado, elas os buscas, realizam as modificações necessárias e as inserem nos
sistemas. O reuso informal ocorre independente do processo de desenvolvimento
utilizado. Ainda, os modelos voltados a reuso são dependentes de ampla base de
componentes reusáveis de software e de framework de integração para comportar
tais componentes (SOMMERVILLE, 2011).
Segundo Sommerville (2001, p. 23) “embora o estágio de especificação de
requisitos iniciais e o estágio de validação sejam comparáveis a outros processos de
software, os estágios intermediários em um processo orientado a reuso são
diferentes”. Este modelo está representado na figura abaixo.
Figura 3 - Engenharia de software orientada a reuso

Fonte: Sommerville, p. 23, 2011.

 18

A seguir, a definição de cada fase do modelo orientado ao reúso, segundo

Sommerville (2011).
• Análise de componentes: realizada a etapa de especificação de
requisitos, busca-se componentes para implementar tal especificação.
• Modificação de requisitos: os requisitos são analisados com base nas
informações sobre os componentes que foram encontrados. E assim,
estes são modificados para refletir os componentes disponíveis.
• Projeto do sistema com reuso: etapa em que o framework do sistema é
projetado ou algo que já existe é reutilizado.
• Desenvolvimento e integração: os softwares que não atendem
requisitos de especificação das empresas devem ser desenvolvidos, logo,
os componentes e sistemas COTS são incorporados para o que o novo
sistema seja gerado. Neste modelo, a integração se faz parte do
processo, ao invés de ser uma atividade isolada.
A engenharia de software orientada a reuso reduz a quantidade de software a
ser desenvolvido, e consequentemente, diminui os custos, riscos e pode chegar na
redução do tempo de entrega. Entretanto, esse modelo exige o comprometimento
com os requisitos, o que pode ocasionar em um sistema que não atenda às
solicitações dos usuários. Ainda, há possibilidade de perda quanto a evolução do
sistema, visto que os componentes com as novas versões reusáveis não estão sob
o controle da organização que faz o uso deste software (SOMMERVILLE, 2011).

7.1.2 METODOLOGIAS AGEIS

Na década de 90, novos métodos voltados a uma abordagem de

desenvolvimento ágil começaram a surgir, no qual os processos adotados buscam
se adaptarem às mudanças, visando o apoio a equipe de desenvolvimento em seu
trabalho (FAGUNDES, 2005).
As metodologias ágeis tiveram o seu desenvolvimento focado no esclarecimento
de fraquezas reais e perceptíveis da engenharia de software tradicional. O
desenvolvimento ágil possibilita benefícios relevantes, mas não é apropriado para
todos os projetos, produtos, etc. Além disso, este não é o oposto da prática de
 19

engenharia de software consistente e pode ser aplicado como uma filosofia de forma
geral para todos os trabalhos de software (PRESSMAN, 2016).
Conforme Sommerville (2011) o processo de desenvolvimento ágil é projetado
para desenvolver um software útil e de forma rápida. Na maioria das vezes, estes
são processos que se repetem, e suas especificações, o projeto, o desenvolvimento
e o teste são intercalados. O desenvolvimento e disponibilização do software não é
realizado de forma integral, mas sim em uma série de incrementos, e cada um desse
inclui uma nova funcionalidade do sistema.

7.1.3 EXTREME PROGRAMMING (XP)

Conforme Koppensteiner e Udo (2003), o método extreme programming (XP)

tem como foca a interação entre desenvolvedor e clientes, seu ambiente ideal é
fundamentado em uma equipe de 10 ou menos desenvolvedores com um cliente
dedicado localmente ao projeto e trabalha por meio de iterações curtas de três ou
menos semanas.
Segundo Pressman (2016, p. 72) a extreme programming (XP) “emprega uma
metodologia orientada a objetos como seu paradigma de desenvolvimento e envolve
um conjunto de regras e práticas constantes no contexto de quatro atividades
metodológicas: planejamento, projeto, codificação e testes”.
Figura 4 – O processo de extreme programming (XP)

Fonte: Pressman, p.72, 2016.

 20

De acordo com Ribeiro e Ribeiro (2015) o método XP é fundamentado nos

seguintes valores:
• Comunicação: a comunicação deve clara e objetiva entre todos os
integrantes da equipe e com o cliente.
• Feedback: realiza a identificação de erros de forma rápida e com
prioridades.
• Coragem: reescrever o código-fonte de um software tornando-o mais
simples e legível sem modificar o seu comportamento observável.
• Simplicidade: implementa apenas o básico e não antecipa as
funcionalidades.
• Propriedade coletiva: cada indivíduo desenvolve uma parte, mas todos
precisam se sentir parte do todo.
• Programação em par: reduz erros, criando soluções mais rápidas e
simples.

7.1.4 SCRUM

Segundo Pressman (2016),o método de desenvolvimento ágil Scrum foi

originado por Jeff Sutherlanf e sua equipe de desenvolvimento no início da década
de 90. Após, Schwaber e Beedle realizaram desenvolvimentos mais recentes neste
método. Conforme retrata Prikladnicki, Willi e Milani (2014), o Scrum é um framework
ágil que realiza o suporte ao gerenciamento de projetos complexos, bem como no
desenvolvimento de produtos. Este é conhecido com um framework que estabelece
um conjunto de práticas sutis e objetivas, bastantes utilizadas no desenvolvimento
de software.
Os princípios do Scrum são congruentes ao manifesto ágil e são utilizados para
servirem como norteadores para as atividades de desenvolvimento dentro de um
processo que possui as seguintes atividades estruturais: requisitos, análise, projeto,
evolução e entrega. Em cada atividade metodológica, ocorrem tarefas a serem
realizadas dentro de um padrão de processo chamado Sprint. O trabalho realizado
dentro de um Sprint é ajustado ao problema em questão e definido, e na maioria das
vezes alterado em tempo real, pela equipe de desenvolvimento Scrum (PRESSMAN,
2016).
 21

Figura 5 – Fluxo do processo Scrum.

Fonte: Pressman, p. 78, 2016

Assim, conforme descreve Pressman (2016, p. 79) “ o scrum engloba um

conjunto de padrões de processos enfatizando prioridades de projeto, unidades de
trabalho compartimentalizadas, comunicação e feedback frequentemente por parte
dos clientes”.

7.2 DESENVOLVIMENTO DE JOGOS

No processo de desenvolvimento de um jogo, as fases se dão de diferentes

formas de projeto para projeto, não havendo uma forma de bolo para a criação do
mesmo, sendo essa uma situação difícil de gerenciar. Segundo Chandler (2009) a
Figura 1 serve como modelo básico de produção, descrevendo objetivos triviais
destas fases onde uma depende da conclusão da outra para ter sucesso no seu
progresso. Sendo assim, pode-se notar que a especificação do projeto na pré-
produção é importante, visto que será a partir dele que o jogo terá uma estrutura
sólida para ser construído. A autora ainda trata que caso o projeto não defina um
plano de pré-produção, a sucessividade de encontrar problemas em grandes
quantidades durante o seu desenvolvimento é relativamente alta e ainda indica que
 22

eles poderiam ser evitados ou até resolvidos antecipadamente caso essa fase
existisse.
Figura 6 - Ciclo básico de produção de jogos.

Fonte: CHANDLER, p. 5, 2009

Pela perspectiva de Sloper (2002) o ciclo de vida do processo de

desenvolvimento de um game foi definido de forma mais ampla e com uma
nomenclatura diferente, mas que em suma demonstra os mesmos processos
anteriormente descritos pela autora. Olsen (2003) define em seu artigo os principais
envolvidos e suas respectivas funções, sendo eles: produtores que definem e criam
a documentação conceitual, designers de jogos aos quais desenvolvem a parte da
documentação técnica e do design do jogo e a equipe de desenvolvedores
constituída por programadores, engenheiros de áudio e engenheiros de qualidade
que são responsáveis pela implementação do jogo, conforme retrata a Figura 2.
Chandler (2009) ressalta que esse é um modelo que contém uma visão básica
do ciclo de produção de um jogo e que, principalmente, projetos com riscos muito
altos devem passar por iterativos processos de produção. Concernente a isso, a
autora afirma:
Se você quiser criar uma verificação de conceito funcional para um jogo -
um nível jogável totalmente polido -, deve incluir alguns ciclos de
desenvolvimento no processo de produção como um todo, com o primeiro
ciclo composto pela pré-produção, produção e teste de protótipo; a segunda
fase enfocando o principal conjunto de recursos e assets do jogo; e um
 23

terceiro ciclo criando e adicionando qualquer recurso e asset extra, como

níveis adicionais (CHANDLER, 2009, p. 5).

Figura 7 - Perspectiva do processo de desenvolvimento de jogos e responsáveis envolvidos.

Fonte: Adaptada de SLOPER, 2002.

Sendo assim, ao aplicar qualquer nova funcionalidade ao jogo é necessário criar

subprocessos que englobam todo o conceito básico de produção do game, desde a
pré-produção até a finalização daquele determinado recurso como retrata a Figura 3.
Com isso, justifica-se como um dos motivos pelos quais o desenvolvimento de
jogos torna-se mais complexo perante ao software padrão, visto que apenas um
recurso adicional por vezes necessita de vários processos iterativos até que o
mesmo seja validado e colocado em vigência no projeto principal do jogo.

Figura 8 - Vários ciclos de produção para um único projeto.

Fonte: CHANDLER, p.6, 2009

 24

A pré-produção é uma das mais importantes do processo, ela é responsável

pela idealização do projeto. Conta com as definições de como será o jogo, custo a
ser aplicado, quantidade de desenvolvedores que serão envolvidos e quanto tempo
será necessário para concluir todo o processo. Esse processo é uma parcela de 10
a 25% do tempo total de produção do jogo visto que nela estarão presentes o plano
para a conclusão do produto e a liberação do código. Como Chandler (2009, p. 5)
afirma, “o planejamento deve incluir informações sobre o conceito, a documentação
básica técnica e de design, e, para concluir, quanto custará, quanto tempo levará e
quantas pessoas, com que habilidades, serão necessárias”. Pode-se dividir a pré-
produção em:
• Conceito de jogo: nesta etapa estão presentes a definição do conceito
inicial, plataforma e gênero, entrega das funções aos desenvolvedores,
elementos básicos de jogabilidade, protótipo piloto, análise de risco,
aprovação do conceito pelos stakeholders e agendamento de lançamento
do projeto.
• Requisitos do jogo: aqui são definidas os recursos que devem ou não
devem ser implantados, a escolha do conjunto de recursos e a tecnologia
em relação a estes, ferramentas e pipeline, quais serão as técnicas
básica assim como a elaboração da documentação técnica e para findar
efetua-se a análise de risco e a aprovação dos requisitos pelos
stakeholders.
• Planejamento do jogo: responsável por levantar o orçamento,
cronograma e a quantidade de pessoas que serão envolvidas. Deve-se
passar as informações para os membros de equipe aprovem o
cronograma junto do plano pessoal e os stakeholders novamente
responsáveis por aprovar todo o processo de planejamento.
Ainda nesse processo se encontra a fase de produção, dividida em
implementação do plano, rastreamento do progresso e conclusão de tarefas. Que
tratam respectivamente da comunicação entre a equipe, recursos necessário para
desenvolvimento das tarefas, controle de crescimento, gerenciamento de
dependência de tarefas, maneiras de rastreamento de progresso das tarefas assim
como a visão dessas para toda a equipe e por fim se as formas de saídas estão
claramente definidas, visíveis para toda equipe e prontas para a aprovação. Em
 25

seguida, a fase de testes responsável pela parte de validação do plano e liberação

do código (CHANDLER, 2009).

7.3 DESENVOLVIMENTO DE JOGOS E A ENGENHARIA DE SOFTWARE

Ao longo dos anos alguns autores tentam propor alterações nos modelos de
processos da engenharia de software para que os mesmos possam ser utilizados no
desenvolvimento de jogos e atendam às necessidades desse tipo de aplicação
(BRATHWAIT; SCHEREIBER, 2009; IRISH, 2005).
Em um estudo efetuado por Petrillo et. al. (2009) foi listado e analisado pelos
autores através de postmortems, os problemas mais comuns encontrados durante a
construção de jogos pelos desenvolvedores. Entre os mais corriqueiros podem-se
ser citados escopos impraticáveis, código de difícil gerenciamento perante
quantidade significativa de funcionalidades (features) adicionadas e ou removidas,
problemas de design, atrasos na entrega de etapas, perda de prazos e falta de
documentação. Os autores concluem que a indústria de desenvolvimento de jogos
sofre com problemas de gerenciamento e que esses problemas também são
comumente encontrados no desenvolvimento de sistemas tradicionais.
Politowski et al. (2016b) desempenharam uma pesquisa online com 58
desenvolvedores que abordava os problemas enfrentados durante a criação de
jogos no mercado brasileiro e a ligação desse processo com a engenharia de
software. Durante a pesquisa os autores constataram três resultados principais:
O primeiro mostra que projetos que usaram abordagens sistemáticas,
independente do tipo, resultaram em produtos melhores. O segundo
resultado destaca atrasos, escopo não realista e falta de documentação
como os problemas mais frequentes enfrentados por desenvolvedores de
jogos. Por fim, o artigo descreve algumas considerações coletadas de
desenvolvedores e literatura, servindo como uma fonte de conhecimento
bem como caracterização dos desenvolvedores brasileiros (POLITOWSKI et
al., p. 39, 2017).

Outra pesquisa realizada pelos autores se deu em recolher, analisar e classificar

processos retirados de 20 postmortems do site Gamasutra a fim de transpor as
informações descritas pelos desenvolvedores em um processo gráfico. Nele pode-se
encontrar uma metodologia para analisar e extrair os processos encontrados nos
postmortems, mostrando que a execução de formas iterativas e metodologias ágeis
de desenvolvimento, oriundas da engenharia de software, vem crescendo e que
 26

processos como o modelo cascata (waterfall) ainda são utilizados, o que

correspondeu a 30% dos projetos analisados na pesquisa (POLITOWSKI et al.
2016a).
Segundo O’Hagan e O’Connor (2015), um modelo de boas práticas seria
favorável para a indústria de jogos notando que há várias lacunas no que diz
respeito aos processos de desenvolvimento e ainda sugerem baseá-lo em padrões
que já existem como a ISO/IEC 29110. Os autores ainda complementam que essas
boas práticas trariam melhor qualidade para o produto final e diminuiria o tempo para
entrega no mercado.
Portanto, o desenvolvimento de jogos tem peculiaridades que se encontram
somente nesse tipo de aplicabilidade e o uso da engenharia de software através de
métodos ágeis ajustados na pré-produção pode entregar formas de facilitar a
resolução de dificuldades e por fim agilizar o processo. Além disso, a gestão dos
componentes em grandes quantidades se faz muito importante durante esse tipo de
projeto (KANODE; HADDAD, 2009).
 27

8 METODOLOGIA

8.1 MÉTODO DE ABORDAGEM

O presente trabalho se dará em uma abordagem indutiva, visto que pretende

verificar processos já existentes dentro da engenharia de software, observando suas
similaridades com o processo de desenvolvimento de jogos através de artigos que
demonstram os aspectos dessa prática. Desta forma, conduzir uma comparação
entre os procedimentos que podem ser aplicados em ambas as situações e como
resposta obter dados gerais da construção de jogos que possam elevar a qualidade,
velocidade e ganhos para esse tipo de mercado.

8.2 TÉCNICAS DE PESQUISA

Para a extração dos processos de desenvolvimento será efetuado uma revisão

em postmortems, onde serão extraídos características de cada processo
desempenhado pelos desenvolvedores na elaboração de jogos. Após, será
agrupado essas informações em conjuntos por similaridade com intenção de
categorizar as principais atividades desempenhadas, negativa ou positivamente,
comparando-as com procedimentos utilizados na engenharia de software.
Igualmente, os procedimentos utilizados na engenharia de software serão
levantados a partir de revisão bibliográfica para que seja possível tal comparação.
Por fim será efetuado a análise dos resultados com o intuído de gerar documentação
de fácil acesso aos interessados por esse tipo de desenvolvimento.
 28

9 CRONOGRAMA

Período: Meses
Atividades
Jun Jul Ago Set Out Nov Dez

Entrega do Projeto de TCC.

Encontro com o orientador

Coleta de dados.

Tabulação dos dados coletados.

Análise e interpretação dos dados.

Finalização do TCC para entrega.

Entrega do TCC.

Apresentação do TCC.
 29

10 PROPOSTA DE SUMÁRIO PARA O TCC

1 INTRODUÇÃO
2 CONTEXTUALIZAÇÃO DO ESTUDO
2.1 Apresentação do Tema
2.2 Problema
2.3 Objetivos
2.3.1 Objetivo geral
2.3.2 Objetivos específicos
2.4 Justificativa
3 REFERENCIAL TEÓRICO
3.1 Engenharia de Software
3.2 Modelos de Processos de Softwares
3.2.1 Modelo Cascata
3.2.2 Desenvolvimento Incremental
3.2.3 Orientada a Reuso
3.3 Metodologias Ágeis
3.3.1 Extreme Programming (XP)
3.3.2 Scrum
3.4 Desenvolvimento de Jogos
3.5 Engenharia de Software e o Desenvolvimento de Jogos
4 METODOLOGIA
4.1 Métodos de abordagem
4.2 Técnicas de Pesquisa
5 RESULTADOS
5.1 Análise dos Postmortems
5.2 Análise da Relação entre os Métodos Utilizados na Engenharia de
Software Aplicada ao Desenvolvimento de Jogos
5.3 Proposta de Ações e Estratégias que Facilitem o Desenvolvimento de
Jogos
CONCLUSÃO
REFERÊNCIAS BIBLIOGRÁFICAS
ANEXOS
APÊNDICES
 30

11 REFERÊNCIAS

ALBINO, R.; SOUZA, C.; PRADO, E. Benefíıcios alcançados por meio de um

modelo de gestão ágil de projetos em uma empresa de jogos eletrônicos.
Revista de Gestão e Projetos, v.5, n.1, p. 15–27, 2014.

AMPATZOGLOU, A.; CHATZIGERORGIOU, A. Evaluation of object-oriented

design patterns in game development. Information and Software Technology,
v.49, n.5, p. 445–454, 2007.

BIRK, A.; DINGSOYR, T.; STALHANE, T. Postmortem: Never leave a project

without it. IEEE software, IEEE, v. 19, n. 3, p. 43–45, 2002.

BRATHWAITE, B.; SCHREIBER, I. Challenges for game designers. [S.l.]: Nelson

Education, 2009.

CHANDLER, H. M. Manual de produção de jogos digitais. [S.l.]: Bookman Editora,

2009.

CLANCY, T. The standish group report. Chaos report, 1995.

FAGUNDES, Priscila Bastos. Framework para Comparação e Análise de Métodos

Ágeis. Dissertação de Mestrado. Universidade Federal de Santa Catarina.
Florianópolis: 2005.

GEDIGAMES, NPGT. Relatório Final: Mapeamento da Indústria Brasileira e Global

de Jogos Digitais. Technical report, BNDS, São Paulo, Fevereiro 2014.

HAMANN, W. Goodbye postmortems, hello critical stage analysis. Gamasutra -

The Art & Business of Making Games, 2003. Disponível em:
<https://www.gamasutra.com/view/feature/131235/goodbye_postmortems_hello_.ph
p> Acesso em: 12 maio.2019.

HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia.

[S.l.]: Elsevier Brasil, 2012.

JR, M. W. et al. What went right and what went wrong: an analysis of 155
postmortems from game development. In: ACM. Proceedings of the 38th
International Conference on Software Engineering Companion. [S.l.], 2016. p. 280–
289

KANODE, C. M.; HADDAD, H. M. Software engineering challenges in game

development. In: IEEE. Information Technology: New Generations, 2009. ITNG’09.
Sixth International Conference on. [S.l.], 2009. p. 260–265.

KOPPENSTEINER, Sonja; UDO, Nathalie. Will agile development change the way
we manage software projects? Agile from s PMBOK guide perspective.
Projectway, LLC, 2003.
 31

MURPHY-HILL, Emerson; ZIMMERMANN, Thomas; NAGAPPAN, Nachiappan.

Cowboys, ankle sprains, and keepers of quality: how is vídeo game development
different from software development?. Proceedings Of The 36th International
Conference On Software Engineering – Icse 2014, [s.I], p. 1-11, jul. 2014. ACM
Press. http://dx.doi.org/10.1145/2568225.2568226

NEWZOO. The Brazilian Gamer 2017. 6 de Julho de 2018. Disponível em:

<https://newzoo.com/insights/infographics/the-brazilian-gamer-2017/> Acesso em: 11
maio.2019

NEWZOO. Brazil Games Market 2018. 6 de Julho de 2018. Disponível em: <
https://newzoo.com/insights/infographics/brazil-games-market-2018/> Acesso em: 20
mar.2019.

NIELSEN, J; NODDER, C. Agile Usability: Best Practices for User Experience on

Agile Development Projects - 2nd edition. Fremont, CA: NN Group Report, 2008.

OLSEN, J. Game Development Salary Survey 2003. 10 de Fevereiro de 2004.

Disponível:
<https://www.gamasutra.com/view/feature/130444/game_development_salary_surve
y_> Acesso em: 12 maio.2019

PETRILLO, F. et al. What went wrong? a survey of problems in game

development. Computers in Entertainment (CIE), ACM, v. 7, n. 1, p. 13, 2009.

PRIKLADNICKI, R.; WILLI, R.; MILANI, F. (2014) Métodos Ágeis Para o

Desenvolvimento de Software. Porto Alegre: Bookman.

POLITOWSKI, C. et al. Are the Old Days Gone? A survey on Actual Software
Engineering Processes in Video Game Industry. In: GAS 2016. [S.I.: s.n.], 2016.
ISBN 9781450341608.

POLITOWSKI, C. et al. Software engineering processes in game development: a

survey about brazilian developers’ experiences. 2016.

POLITOWSKI, C. et al. Sistema de recomendação de processos para o

desenvolvimento de jogos digitais. Universidade Federal de Santa Maria, 2017.

PRESSMAN, R.; MAXIM, B. Engenharia de Software. 8. ed. [S.1]: McGraw Hill

Brasil, 2016.

REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informação. 3

ed. Rio de Janeiro: Brasport, 2005.

RIBEIRO, R. D.; RIBEIRO, H. C. S. Métodos ágeis em gerenciamento de

projetos. Rio de Janeiro: Horácio da Cunha e Sousa Ribeiro, 2015.

SLOPER, T. Following Up After the Game is Released: It’s not Over when it’s
Over, Game Design Perspectives, 2002.
 32

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice

Hall, 2011.

VALIN, A. Conheça Ralph Baer: O Inventor do Video Game, 2013. Disponível em:
https://www.tecmundo.com.br/video-game-e-jogos/37988-conheca-ralph-baer-o-
inventor-do-video-game.htm. Acesso em: 11 maio.2019.

WAZLAWICK, R. Engenharia de software: conceitos e práticas. [S.l.]: Elsevier

Brasil, 2013. v. 1.

WEPC. Video Game Industry Statistics, Trends & Data. 2019. Disponível em:
https://www.wepc.com/news/video-game-statistics/. Acesso em: 20 mar.2019.