Desenvolvimento de Jogos Multiplataformas

Desenvolvimento
de Jogos
Multiplataformas
Prof.a Tatiana Tozzi
Indaial – 2021
1a Edição
Copyright © UNIASSELVI 2021
Elaboração:
Prof.a Tatiana Tozzi
Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.
T757d
Tozzi, Tatiana
Desenvolvimento de jogos multiplataformas. / Tatiana Tozzi
– Indaial: UNIASSELVI, 2021.
239 p.; il.
ISBN 978-65-5663-841-6
ISBN Digital 978-65-5663-842-3
1. Aplicativos móveis. - Brasil. 2. Inovações educacionais. -
Brasil. II. Centro Universitário Leonardo da Vinci.
CDD 004
Impresso por:
Apresentação
Prezado acadêmico! Seja bem-vindo à Disciplina Desenvolvimento
de Jogos Multiplataformas!
No caminho até aqui você conheceu algumas disciplinas que

abordaram um pouco sobre o Desenvolvimento de Jogos, mas agora, nesta
disciplina, vamos explorar sobre o Desenvolvimento de Jogos.
No decorrer do livro, você conhecerá sobre os conceitos do

desenvolvimento de jogos, além das principais e mais utilizadas plataformas
de desenvolvimento de jogos. Os conteúdos apresentados no decorrer
deste livro serão essenciais quando chegar o momento de você iniciar o
desenvolvimento dos seus jogos.
Um dos conteúdos de maior relevância no desenvolvimento de jogos

são as fases de pré-produção, produção e pós-produção. Através da execução,
devemos ter como resultado um jogo bem planejado e desenvolvido, mas
vamos deixar um pouco de mistério até começar a segunda unidade.
Na Unidade 1, estudaremos sobre o desenvolvimento de jogos 2D, 3D

e multiplataformas. No decorrer dos tópicos conheceremos vários elementos
que estão presentes no desenvolvimento de jogos de cada um desses tipos.
Na Unidade 2, abordaremos sobre a produção de jogos, conheceremos

métodos de gerenciamento de projetos e as três frases de produção de jogos.
Por fim, na Unidade 3, aprenderemos sobre a documentação de

projetos de jogos e o desenvolvimento de jogos mobile, em que conheceremos
mais sobre o desenvolvimento de jogos para sistemas Android e IoS.

Bons estudos e sucesso em sua trajetória!
Prof.ª Tatiana Tozzi

NOTA
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há
novidades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é

o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um
formato mais prático, que cabe na bolsa e facilita a leitura.
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova
diagramação no texto, aproveitando ao máximo o espaço da página, o que também
contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade
de estudá-lo com versatilidade nas telas do celular, tablet ou computador.

Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto
em questão.
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

Desempenho de Estudantes – ENADE.

Bons estudos!
LEMBRETE
Olá, acadêmico! Iniciamos agora mais uma disciplina e com ela

um novo conhecimento.
Com o objetivo de enriquecer seu conhecimento, construímos, além do livro

que está em suas mãos, uma rica trilha de aprendizagem, por meio dela você
terá contato com o vídeo da disciplina, o objeto de aprendizagem, materiais complemen-
tares, entre outros, todos pensados e construídos na intenção de auxiliar seu crescimento.
Acesse o QR Code, que levará ao AVA, e veja as novidades que preparamos para seu estudo.
Conte conosco, estaremos juntos nesta caminhada!

Sumário
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS
ALTERNATIVAS PARA JOGOS.......................................................................................1
TÓPICO 1 — DESENVOLVIMENTO DE JOGOS 2D..................................................................... 3

1 INTRODUÇÃO .................................................................................................................................... 3
2 INTRODUÇÃO AOS JOGOS 2D...................................................................................................... 3
3 MODELAGEM DE AMBIENTES 2D................................................................................................ 7
4 SPRITES................................................................................................................................................ 10
5 FÍSICA E ANIMAÇÃO EM 2D........................................................................................................ 12
6 DISPOSITIVOS DE ENTRADA...................................................................................................... 13
7 GAME ENGINES................................................................................................................................. 14
RESUMO DO TÓPICO 1..................................................................................................................... 16
AUTOATIVIDADE............................................................................................................................... 17
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS 3D................................................................... 19

1 INTRODUÇÃO .................................................................................................................................. 19
2 INTRODUÇÃO AOS JOGOS 3D.................................................................................................... 19
3 USO DE MODELOS 3D.................................................................................................................... 22
4 TÉCNICAS DE GAMEPLAY............................................................................................................. 23
5 INTERAÇÃO....................................................................................................................................... 24
6 SCRIPTS................................................................................................................................................ 25
7 ANIMAÇÃO EM 3D.......................................................................................................................... 26
RESUMO DO TÓPICO 2..................................................................................................................... 32
AUTOATIVIDADE............................................................................................................................... 33
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA.............................. 35

1 INTRODUÇÃO .................................................................................................................................. 35
2 PLANO DE DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA.............................. 36
3 METODOLOGIAS DE DESENVOLVIMENTO DE JOGOS..................................................... 38
4 GDD – DOCUMENTO DE GAME DESIGN.................................................................................. 46
5 SISTEMA DE BANCO DE DADOS................................................................................................ 48
6 GÊNEROS............................................................................................................................................ 51
7 PLATAFORMAS................................................................................................................................. 53
8 TIPOS E CARACTERÍSTICAS........................................................................................................ 55
LEITURA COMPLEMENTAR............................................................................................................. 57
RESUMO DO TÓPICO 3..................................................................................................................... 64
AUTOATIVIDADE............................................................................................................................... 65
REFERÊNCIAS....................................................................................................................................... 66
UNIDADE 2 — PRODUÇÃO DE JOGOS........................................................................................ 71
TÓPICO 1 — MÉTODOS DE GERENCIAMENTO DE PROJETO E

INTRODUÇÃO A PRODUÇÃO DE JOGOS.......................................................... 73
1 INTRODUÇÃO .................................................................................................................................. 73
2 MÉTODOS DE GERENCIAMENTO DE PROJETOS................................................................. 73
2.1 PROCESSO PESSOAL DE SOFTWARE (PSP)........................................................................... 75
2.2 SCRUM............................................................................................................................................ 78
2.3 PROJECT MANAGEMENT INSTITUTE (PMI)......................................................................... 82
3 CICLO DE PRODUÇÃO DE JOGOS.............................................................................................. 84
RESUMO DO TÓPICO 1..................................................................................................................... 89
AUTOATIVIDADE............................................................................................................................... 90
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO........................................................ 93

1 INTRODUÇÃO .................................................................................................................................. 93
2 PRÉ-PRODUÇÃO............................................................................................................................... 94
2.1 DEFINIÇÃO DO CONCEITO...................................................................................................... 94
2.1.1 Início do processo................................................................................................................. 95
2.1.2 Brainstorm............................................................................................................................... 95
2.1.3 Conceito inicial...................................................................................................................... 96
2.1.4 Gênero.................................................................................................................................... 97
2.1.5 Plataforma.............................................................................................................................. 97
2.1.6 Análise SWOT....................................................................................................................... 97
2.1.7 Declaração da missão........................................................................................................... 98
2.1.8 Cenário do jogo..................................................................................................................... 99
2.1.9 Mecânica do jogo.................................................................................................................. 99
2.1.10 Sinopse da história............................................................................................................ 100
2.2 REQUISITOS DO JOGO.............................................................................................................. 100
2.2.1 Definição dos recursos do jogo......................................................................................... 101
2.2.2 Definição das etapas e produtos....................................................................................... 103
2.2.3 Avaliação da tecnologia..................................................................................................... 104
2.2.4 Definição das ferramentas e pipeline................................................................................ 104
2.2.5 Documentação..................................................................................................................... 105
2.2.6 Análise de risco................................................................................................................... 106
2.3 PLANEJAMENTO DO JOGO.................................................................................................... 107
2.3.1 Dependências...................................................................................................................... 107
2.3.2 Cronograma......................................................................................................................... 107
2.3.3 Orçamento........................................................................................................................... 111
2.3.4 Equipe................................................................................................................................... 111
2.4 GDD............................................................................................................................................... 113
2.5 LISTA DE VERIFICAÇÃO DA PRÉ-PRODUÇÃO................................................................. 124
3 PRODUÇÃO...................................................................................................................................... 125
3.1 IMPLEMENTAÇÃO DO PLANO............................................................................................. 126
3.2 RASTREAMENTO DO PROGRESSO....................................................................................... 127
3.2.1 Revisões de projeto............................................................................................................. 127
3.2.2 Reuniões............................................................................................................................... 127
3.2.3 Priorização........................................................................................................................... 127
3.2.4 Mudanças............................................................................................................................. 128
3.2.5 Processo de aprovação....................................................................................................... 129
3.3 CONCLUSÃO DE TAREFAS..................................................................................................... 129
3.4 LISTA DE VERIFICAÇÃO DA PRODUÇÃO.......................................................................... 129
RESUMO DO TÓPICO 2................................................................................................................... 131
AUTOATIVIDADE............................................................................................................................. 132
TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO................................................................. 133
1 INTRODUÇÃO ................................................................................................................................ 133
2 TESTES............................................................................................................................................... 133
2.1 PLANO DE TESTES.................................................................................................................... 136
2.2 LIBERAÇÃO DO CÓDIGO........................................................................................................ 138
2.3 TDD................................................................................................................................................ 139
2.4 LISTA DE VERIFICAÇÃO DA EXECUÇÃO DE TESTES..................................................... 140
3 PÓS-PRODUÇÃO............................................................................................................................. 141
3.1 APRENDER COM A EXPERIÊNCIA........................................................................................ 142
3.2 PLANO DE ARQUIVAMENTO................................................................................................ 143
3.3 LISTA DE VERIFICAÇÃO DA PÓS-PRODUÇÃO................................................................. 143
LEITURA COMPLEMENTAR........................................................................................................... 144
RESUMO DO TÓPICO 3................................................................................................................... 151
AUTOATIVIDADE............................................................................................................................. 152
REFERÊNCIAS..................................................................................................................................... 154
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE.............. 159
TÓPICO 1 — KITS DE FECHAMENTO......................................................................................... 161

1 INTRODUÇÃO................................................................................................................................. 161
2 DEFINIÇÃO DOS KITS DE FECHAMENTO............................................................................ 161
3 CRIANDO OS KITS DE FECHAMENTO................................................................................... 162
3.1 ASSETS.......................................................................................................................................... 164
3.2 FERRAMENTAS.......................................................................................................................... 166
3.3 CÓDIGO DO JOGO..................................................................................................................... 166
3.4 DOCUMENTAÇÃO.................................................................................................................... 167
4 ORGANIZAÇÃO DO CONTEÚDO............................................................................................. 169
RESUMO DO TÓPICO 1................................................................................................................... 173
AUTOATIVIDADE............................................................................................................................. 174
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID.......................................... 177

1 INTRODUÇÃO ................................................................................................................................ 177
2 INSTALAÇÃO DO UNITY............................................................................................................. 179
2.1 TIPO DE GAMES......................................................................................................................... 183
3 ENGINE UNITY................................................................................................................................. 184
4 FERRAMENTAS DA ENGINE...................................................................................................... 186
5 TRABALHANDO COM OBJETOS............................................................................................... 191
6 LEVEL.................................................................................................................................................. 193
7 COLISÕES DE FÍSICA.................................................................................................................... 194
8 ELEMENTOS DO JOGO................................................................................................................. 198
8.1 MENU E CONTROLES............................................................................................................... 198
8.2 EFEITOS SONOROS.................................................................................................................... 200
9 PUBLICANDO O JOGO................................................................................................................. 201
RESUMO DO TÓPICO 2................................................................................................................... 204
AUTOATIVIDADE............................................................................................................................. 205
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS PARA IOS................................................... 207

1 INTRODUÇÃO................................................................................................................................. 207
2 BASE DO JOGO................................................................................................................................ 208
3 BACKGROUND E LOGO................................................................................................................ 210
4 CENAS DO JOGO............................................................................................................................ 211
5 TRANSIÇÃO DE TELAS................................................................................................................ 215
6 ILUMINAÇÃO.................................................................................................................................. 216
7 EXIBIÇÃO DO JOGO...................................................................................................................... 218
8 MELHORAR O JOGO..................................................................................................................... 219
9 PUBLICANDO O JOGO................................................................................................................. 220
LEITURA COMPLEMENTAR........................................................................................................... 225
RESUMO DO TÓPICO 3................................................................................................................... 232
AUTOATIVIDADE............................................................................................................................. 234
REFERÊNCIAS..................................................................................................................................... 236
UNIDADE 1 —
DESENVOLVIMENTO MULTIPLATAFORMA
E PLATAFORMAS ALTERNATIVAS PARA
JOGOS
OBJETIVOS DE APRENDIZAGEM
A partir do estudo desta unidade, você deverá ser capaz de:
• contextualizar sobre o desenvolvimento de jogos 2D, 3D e multiplataforma;

• ter uma visão geral sobre o desenvolvimento de jogos;
• conhecer os elementos essenciais do desenvolvimento de jogos;
• explorar um ambiente de desenvolvimento de jogos multiplataforma.
PLANO DE ESTUDOS
Esta unidade está dividida em três tópicos. No decorrer da unidade,
você encontrará autoatividades com o objetivo de reforçar o conteúdo
apresentado.
TÓPICO 1 – DESENVOLVIMENTO DE JOGOS 2D
TÓPICO 2 – DESENVOLVIMENTO DE JOGOS 3D
TÓPICO 3 – DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
CHAMADA
Preparado para ampliar seus conhecimentos? Respire e vamos

em frente! Procure um ambiente que facilite a concentração, assim absorverá
melhor as informações.
1
2
UNIDADE 1 TÓPICO 1 —
DESENVOLVIMENTO DE JOGOS 2D
1 INTRODUÇÃO
Caro acadêmico, neste tópico, você poderá conhecer os elementos do
desenvolvimento de jogos 2D. Talvez você se lembre de algum jogo que tenha
jogado em 2D. No decorrer deste tópico, vamos explorar os principais elementos
que compõem um jogo 2D.

Para começar, o que determina que um jogo seja 2D, padawan? Jogos 2D
são simples? Essas são algumas perguntas que podem surgir quando o tema
deste tópico começa a ser discutido. Os jogos 2D podem ser simples ou complexos
e cheios de recursos, isso varia conforme o objetivo do jogos que estão sendo
desenvolvidos e qual software é utilizado em sua criação. Falando sobre software...
vamos tratar dele mais adiante neste tópico.
No decorrer deste tópico, conheceremos sobre os jogos 2D, através de uma

introdução sobre o seu desenvolvimento, os ambientes de modelagem, sprites, a
física e animação, dispositivos de entrada e, por último, games engines.
Então, vamos começar nossa jornada no desenvolvimento de jogos 2D?
Bons estudos!
2 INTRODUÇÃO AOS JOGOS 2D

É bem provável que você já tenha jogado um jogo 2D. Um bom exemplo
de jogo 2D são os jogos clássicos do Mario Bros. Outro exemplo e concorrente
é o Sonic. Esses dois são apenas alguns exemplos de jogos 2D, e apesar de ser
considerados ‘antigos’, os jogos em 2D continuam a ser desenvolvidos e jogados,
só que agora, em vez de estarem restritos aos fliperamas, podemos acessá-los em
nosso smartphone, computador e até em TVs Smarts. A principal dificuldade que
podemos encontrar como jogadores é qual será o jogo que iremos jogar.
Segundo Cople (2019, p. 112), o desenvolvimento de jogos 2D “tem se

tornado cada vez mais aquecido com o advento de plataformas móveis, gerando
uma grande oportunidade para desenvolvedores independentes, principalmente
devido ao baixo custo necessário para implementação e distribuição desse tipo
de produto”.
3
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
Mas o que é 2D? 2D significa que o jogo tem apenas duas dimensões, a
largura e o comprimento. A Figura 1 demonstra duas imagens de um quadrado,
a primeira em 2D e a segunda em 3D. Como podemos observar, o quadro 3D
apresenta uma caracteriza a mais, a profundidade.
FIGURA 1 – EXEMPLO DE IMAGEM EM 2D E 3D
FONTE: <https://bit.ly/2Z4IhzH>. Acesso em: 28 jun. 2021.
Para começar, o que caracteriza um jogo 2D? Um jogo em duas dimensões,

ou seja, utiliza dois eixos (x e y) para representar o ambiente do jogo. Os jogos
2D são planos, o jogo pode ir para frente ou para trás, não sendo utilizadas suas
laterais. Como você pode observar na Figura 2, são apresentados o jogo Super
Mario World em duas versões, a primeira imagem é a versão do jogo em 2D, já a
segunda em 3D. Soares (2018, s. p.) destaca que o 2D “é um estilo tradicional que
mostra dois ângulos e também mostra os objetos e personagens em um estilo de
desenho animado”. Os cenários, personagens e animações são figuras planas em
jogos 2D, conseguimos observar somente o que é exibido, sem uma sensação de
espaço ou perspectiva que se tem em jogos 3D.
FIGURA 2 – EXEMPLO DE JOGOS 2D e 3D: SUPER MARIO WORLD
FONTE: <https://bit.ly/3C6asNc>. Acesso em: 28 jun. 2021.
4
TÓPICO 1 — DESENVOLVIMENTO DE JOGOS 2D
Em jogos 2D, é comum o uso de imagens pixeladas para compor os

cenários, personagens, recompensas, ou outros elementos que estão presentes no
jogo. A Figura 3 [A] demonstra uma imagem pixelada. Contudo, nem todos os
jogos 2D utilizam tais imagens pixeladas, em jogos 2D é comum utilizá-las para
se criar jogos com aspectos retrô, mas vale ressaltar que é comum e cada vez
mais presente nos jogos a utilização de imagem de excelente qualidade, como
representado na Figura 3 [B]. Em jogos 3D, são utilizadas principalmente imagens
de alta qualidade, porém, isso não significa que um jogo não possa ser criado
usando a pixel art.
FIGURA 3 – IMAGEM PIXELADA VERSUS IMAGEM COM QUALIDADE
FONTE: Adaptada de <https://bit.ly/3B5cKuT>. Acesso em: 30 jul. 2020.
NOTA
A Pixel Art é uma maneira de se criar uma obra de arte digitais (imagem) utili-
zando pixels, sendo o pixel o menor ponto de uma imagem digital, a qual está presente em
vários recursos digitais, entre eles os jogos (MANNARA, 2016). Você pode utilizar uma das
ferramentas on-line apresentadas a seguir para criar os elementos do seu jogo.
• GrafX2: http://grafx2.chez.com/;
• Pixilart: https://www.pixilart.com/;
• Piq – Pixel Art Maker: https://piq.codeus.net/;
• Piskel: https://www.piskelapp.com/.
FONTE: MANNARA, B. O que é pixel art e como fazer. TechTudo. 2016. Disponível em:
https://glo.bo/3B1BFiH. Acesso em: 26 jun. 2021.
Os jogos do Mário ou Sonic não são os únicos tipos de jogos 2D. No

Quadro 1 você irá conhecer os tipos de jogos 2D.
5
QUADRO 1 – TIPOS DE JOGOS 2D
Tipo do Exemplo
Características
jogo de jogo
É o tipo mais conhecido de jogos 2D, onde um
personagem se move horizontalmente até o final da
Super cena, para isso ele pode correr ou caminhar, no eixo
2D lateral
Mário Y é utilizando para realizar os pulos. Para simular a
profundidade é utilizado um efeito chamado scroll,
para movimentar as imagens do fundo do cenário.
Nesse tipo de jogo temos uma visão superior dos
objetos em cena, de todo o cenário e os personagens,
Isométrico Sim City assim temos um plano mais elevado, sendo os
objetos em cena sendo apresentados utilizando um
ângulo de 30 graus com o eixo X.
Esse tipo de jogo 2D tem sua movimentação no
eixo Y (vertical), é comumente encontrado em
Space dispositivos móveis. Os efeitos de scroll, quando
2D Vertical
Ship usado nesse tipo de jogo devem ser feitos com
cuidado, para que não sejam apresentadas falhas
entre as junções de imagens utilizadas.
Nesse tipo de jogo a tela não se move em nenhum
eixo, apenas os ‘personagens’ que se movimento
2D Jogo da
dentro dos limites definidos. Esse tipo de jogo é
Estático cobrinha
o mais simples de ser desenvolvido, porém não
podemos adicionar muitos elementos na cena.
FONTE: Adaptado de <https://bit.ly/3poMeu9>. Acesso em: 24 ago. 2021.
Como podemos observar no Quadro 1, podemos explorar e criar jogos 2D

utilizando um dos tipos apresentados, porém, existe a possibilidade de inovar e
desenvolver novos tipos, uma vez que o desenvolvimento de jogos 2D ainda pode
ser mais explorado ao utilizar novas tecnologias que venham a surgir. Quem sabe
daqui algum tempo não existam outros tipos de jogos 2D?
DICAS
O desenvolvimento de jogos é tema do documentário A Revolução dos Games

(2021). Nele, são abordadas as batalhas que deram origem à indústria de desenvolvimento
de jogos eletrônicos. Alguns dos tipos de jogos 2D tem sua história contada neste
documentário a seguir. Acesse em: https://bit.ly/3G66Ygl.
6
3 MODELAGEM DE AMBIENTES 2D
Modelar um jogo significa, criar um mundo novo, conforme Morais e
Silva (2009, p. 5), é “(...) onde são criados os desenhos definitivos que estarão
presentes e farão parte do jogo final”. Normalmente, um jogo tem pelo menos
um ou todos alguns desses elementos: cenário, elementos gráficos (objetos em
cena) e os personagens, porém, isso não é regra geral para todos. Como vimos
anteriormente, dependendo do tipo de jogo, os objetos em cena são minimamente
utilizados, como em jogos estáticos.
Atualmente, podemos contar com vários ambientes (software) de mode-

lagem de jogos 2D. Entre eles, um dos mais utilizado é o Construct 2 (Figura 4):
(...) é um editor de jogos 2D desenvolvido pela Scirra Ltda. Ele

permite um processo de criação mais ágil do que os outros editores
por conta do seu editor visual drag-and-drop, possui um sistema de
lógica baseada em comportamento e possibilita criar jogos mesmo sem
conhecimentos em linguagem de programação (EBG, 2016, s.p.).

FIGURA 4 – SOFTWARE CONSTRUCT 2
FONTE: <https://bit.ly/3ne2lId>. Acesso em: 28 jun. 2021.
A utilização do Construct 2 é simples, pois utiliza um recurso muito

presente em softwares de edição gráfica e desenvolvimento de sites, o arraste e
solte. Com isso, mesmo que os desenvolvedores não dominem alguma linguagem
de programação, conseguem criar um jogo de forma simples e publicá-lo em
HTM5, mas vale ressaltar que antes de sair criando um jogo é fundamental a
elaboração do roteiro dele (SILVA, 2013).
7
DICAS
A elaboração de um roteiro para jogos é diferente de um roteiro de um re-

curso audiovisual. No link a seguir, você poderá compreender mais sobre essa diferença:
https://www.fabricadejogos.net/posts/roteiro-de-games-e-diferente-de-filmes/.
Já neste vídeo a seguir, você poderá conhecer três softwares que você pode utilizar para
criar o roteiro dos seus jogos: https://www.youtube.com/watch?v=V7A-ZweiuYo. Além
desses três, temos o Twine (https://twinery.org/), um software que permite construir narra-
tivas interativas e no planejamento do seu jogo.
Além do Construct 2, existem outros softwares para desenvolver jogos 2D.

No Quadro 2 apresentamos os mais utilizados e atuais softwares de criação 2D.
QUADRO 2 – LISTA DE AMBIENTE DE DESENVOLVIMENTO JOGOS 2D
Software Endereço Descrição Gratuito Pago

É utilizado para a criação
de jogos RPG e possui
inúmeras ferramentas
e recursos, porém pode
ser utilizado para se
desenvolver outros
tipos de jogos. Não Possui Versão
https://www.
RPG exige conhecimento de uma paga com
rpgmakerweb.
Maker programação, porém versão recursos
com/
permite que sejam gratuita. adicionais.
utilizados comandos caso
o desenvolvedor domine
programação. Pode ser
utilizado para desenvolver
jogos para PC, navegador e
Android.
Também não exige

conhecimento de
programação, utiliza
Possui
o recurso arraste e
Construct https://www. um
solte para designar os Sim.
3 construct.net/en período
comandos. Utilizado no
de teste.
desenvolvimento de jogos
arcade, plataforma, puzzle
e corrida.
8
É um software para se
ensinar programação
ao criar jogos, possui
https://scratch. conceitos de linguagem
Scratch Sim. Não.
mit.edu/ de programação. Utiliza o
recurso de arraste e solte
para definir os comandos,
é de fácil edição.
Também é utilizado para
ensinar programação
criando jogos, Além de
http://www. permitir uma variedade
Stencyl Não. Sim.
stencyl.com/ de ferramentas. Os
jogos criados têm
compatibilidade com
múltiplas plataformas.
Um dos primeiros
softwares de
https://www. desenvolvimento de Possui
Clickteam clickteam.com/ jogos, não precisa uma
Sim.
Fusion clickteam- de conhecimento de versão
fusion-2-5 programação, porém pode- grátis.
se utilizar para realizar
tarefas mais simples.
Possui ferramentas
avançadas, além de
permitir a criação de
https://www.
Game elementos no próprio
yoyogames.
Maker programa, podendo ser Não. Sim.
com/pt-BR/
Studio 2 utilizado para vários
gamemaker
gêneros. Requer um
conhecimento básico de
programação
Requer conhecimento
https://www. avançado em modelagem
Unreal
unrealengine. e programação. Permite Não. Sim.
Engine
com/ criar jogos com altíssima
qualidade.
Um dos softwares
mais utilizados no
desenvolvimento
Possui
https://unity. de jogos, requer
uma
Unity com/pt/ conhecimento avançando Sim.
versão de
solutions/2d em programação e
teste.
modelagem. Permite
criar jogos com altíssima
qualidade.
FONTE: Adaptado de Nascimento (2021)
9
Como você pode observar, existem vários softwares para se desenvolver

jogos 2D. Você pode acessar os endereços e testar cada um deles, afim de descobrir
qual você mais tem afinidade em utilizar. Explore esses softwares, mas não se limite
a essa lista, uma vez que sempre surgem novos ambientes de desenvolvimento.
4 SPRITES
Os movimentos dos personagens contidos no jogo são gerados através de
animação. Segundo Novak (2017, p. 172), “na maioria dos games 2D, a animação é
restrita a pequenas áreas da tela que são controladas pelo jogador, (...) costumam
ser chamadas de sprites e podem conter um personagem ou um objeto que se
move sobre um fundo estático ou rolante”.
Os personagens ou objetos são representados por sprites, que são imagens

sequenciais animadas quadro a quadro. Para Freitas (2014, p. 31), “sprites são
imagens bidimensionais ou tridimensionais que se movem sem deixar traços na
tela”. Já Cavaco (2007, p. 50) define sprites como:
Sprites podem conter, em alguns pontos do desenho, uma transparência,

esse recurso é conhecido como “alpha-bleding” e possibilita uma
melhor qualidade gráfica aos jogos 2D. Sprite pode ser usado através
de aplicação de máscara. (...) O uso de sprites sobrepostos ao mapa
de bits da tela de um fundo, usualmente denomina de tile. Ao sprite
se associa altura, largura, posição, estado de visibilidade, prioridade
sobre outros sprites, transformações de escala, translação e rotação,
controle de colisão com outros sprites, manipulação de tabela de
cores. (...) Exemplo de cenário: Uma cena composta por três layers (o
pilar, o céu, e o chão). Os objetos geralmente são sprites. (...) Muitos
sprites são personagens que aparecem no jogo, que interagem uns
com os outros e com o cenário. Eles podem correr, pular, voar, nadar,
lutar e atirar. Geralmente, o jogo fornece um sprite que representa
o personagem principal controlado pelo jogador. Os outros sprites
podem ser monstros e inimigos que perseguem o jogador, ou objetos
que o jogador pode pegar, tal como moedas e armas.
A Figura 5 demonstra uma folha de sprites do Mario Bros, a folha de estilo

também é conhecida em inglês como Sprite Sheet. Na Figura 5 podemos observar
quadro a quadro os movimentos que o personagem pode realizar no jogo.
10
FIGURA 5 – FOLHA DE SPRITES DO MÁRIO BROS
FONTE: <https://i.imgur.com/zhM3VPv.png>. Acesso em: 28 jun. 2021.
DICAS
Existem várias folhas de sprites prontas e gratuitas na internet. O site Open

Game Art (https://opengameart.org/) reúne vários recursos gratuitos, incluindo folhas de
sprites que você pode utilizar no desenvolvimento dos seus jogos.
11
5 FÍSICA E ANIMAÇÃO EM 2D
Nos jogos podemos ter personagens que saltam, pulam, entre outras
ações. O personagem é um corpo, as ações de saltar ou pular são onde é aplicada
a força de baixo para cima para saltar ou pular. A gravidade é o trazer o corpo de
volta para o chão e as colisões fazem o personagem parar ou ir para a próxima
ação (CÁSSIO, 2014).

No desenvolvimento de jogos, a física está presente, assim como em nosso
cotidiano. Segundo Freitas (2014, p. 20), o “[...] motor de física simula a física real
como gravidade, elasticidade, fricção, bem como calcula movimento de colisão
entre corpos”. A Figura 6 ilustra como a física está presente no jogo e na animação
dos personagens e elementos que o compõem. No desenvolvimento de grandes
jogos, é comum termos o profissional ‘Programador de Física’, que é o responsável
pela criação do código que simula as reações físicas, a força, fenômenos naturais,
entre outras simulações (FLEURY et al., 2014).
FIGURA 6 – DEMONSTRAÇÃO DE FÍSICA EM UMA TELA DE JOGO 2D
FONTE: <https://bit.ly/3Bd3Mw7>. Acesso em: 29 jun. 2021.
Além de motores de física, é comum encontrarmos na literatura seu

sinônimo, engines. Nem sempre podemos contar com um Programador de Física
em um projeto, mas isso não é um grande problema, não é mesmo? Temos as
tecnologias para auxiliar no desenvolvimento de jogos, com isso, conforme Cássio
(2014), podemos utilizar “bibliotecas, frameworks, que pretendem simular física
realista em um computador, poupando o programador de conhecer fórmulas e
inúmeros detalhes”. Segundo Biurrum (2015, p. 23):
Basicamente, encontramos nos jogos eletrônicos características de

dois grandes segmentos da física: mecânica clássica e ondulatória.
Dessas áreas é comum a utilização dos conhecimentos da cinemática,
12
dinâmica, trabalho e mecânica, sistema de partículas, colisões,

movimento rotacional, gravitação, fluidos, som e luz. (...)
Dois elementos da física são constantemente aplicados na partida do
jogo. São eles: movimentação e colisão. O movimento dos elementos
gráficos acontece a partir da alteração de suas coordenadas X e Y na
cena, tendo como base suas velocidades e direções atuais.
A física está presente em qualquer jogo atualmente, porém, cada tipo de

jogo pode ter um certo nível de necessidade para física (MIOTO, 2010). O que
vai determinar as frameworks ou bibliotecas que serão utilizadas depende do que
você irá desenvolver.
6 DISPOSITIVOS DE ENTRADA
Hoje, nos consoles e computadores, podem ser adicionados alguns
dispositivos de entrada, como pistolas, volantes, joysticks, entre outros dispositivos.
A utilização de telas touchscreen também nos proporciona novas experiências ao
jogar um jogo. No Quadro 3, apresentamos os principais dispositivos de entrada
utilizados atualmente.
QUADRO 3 – DISPOSITIVOS DE ENTRADA
Dispositivo de entrada Descrição

Também conhecido como joypad, é usado em jogos
Gamepads mais comumente usados, alguns modelos podem
também ser um dispositivo de saída (vibração).
Direcionais analógico São dispositivos que reproduzem a sensação das
de arcade máquinas de arcade verticais para luta.
Joysticks para simulador Utilizado principalmente para simulador de voo
de voo como um manche.
São os principais dispositivos de entrada utilizado
Teclado e Mouse
em jogos.
Utilizado em simuladores de corrida, em alguns
Volante
casos é utilizado com um conjunto de pedais.
Dispositivo com um teclado reduzido, com apenas
Gaming Keypad
as teclas utilizadas para jogar.
Utilizado em jogos musicais, que simulam um
Controlador Musical
instrumento musical, como guitarra ou bateria.
Trackball É um estilo de mouse, com mais recursos e botões.
Usado para controlar jogos, além de um dispositivo
Controlador WII de entrada, também é um dispositivo de saída
(som).
FONTE: Adaptado de Microsoft (2017), Gomes (s. d.), PT Computador (s. d.)
13
Como podemos observar no Quadro 3, são vários os dispositivos que

podem ser utilizados para se jogar, mas, dependendo do tipo de jogo, podemos
definir para quais plataformas ou qual plataforma será desenvolvido, é provável
que você indique a utilização de um desses dispositivos. Seja utilizando algum
dos dispositivos de entrada apresentados ou simplesmente um toque na tela, os
dispositivos de entrada são fundamentais para uma boa experiência no jogo.
7 GAME ENGINES
Para o desenvolvimento de jogos, o game engine ou motor de jogo pode
ser um ambiente de desenvolvimento, como conhecemos anteriormente, ou uma
biblioteca de funcionalidade já implementadas, assim, podemos criar o jogo com
uma base pronta e implementar o que for necessário. Assim, não é necessário
começar o jogo do zero (FREITAS, 2014).
Nemitz Neto (2015, p. 40) define que o Game Engines,
(...) são compostas por um conjunto de ferramentas de produção de

conteúdo e um componente de execução. Conteúdo são scripts de
inteligência artificial, imagens e sons que fazem parte de um jogo.
O componente de execução é um sistema de software dirigido por
dados que transforma o conteúdo providenciado pela equipe de
desenvolvimento em um jogo digital.
Utilizando um ambiente de desenvolvimento ou uma biblioteca de

funcionalidades, o game engines possue algumas características, conforme
podemos observar no Quadro 4.
QUADRO 4 – CARACTERÍSTICAS DO GAME ENGINES
Característica Descrição
Graphic Engine Motor Gráfico, para renderizar gráficos 2D e 3D.
Motor de Física, para simular a física em si ou
Physics Engine
simplesmente para fazer detecção de colisão.
Media Framework Gerenciador de animações e demais mídias.
Sound Engine Motor de Sons, para gerenciamento dos sons.
AI Engine Motor de Inteligência Artificial.
Input System Controlador de dispositivos de entrada.
Resource Manager Gerenciador de memória e arquivos.
IDE Ambiente visual de criação.
FONTE: Adaptado de Cople (2019)
14
Na literatura, as características apresentadas no Quadro 4 também são

conhecidas como funcionalidade de um jogo. Gregory (2017 apud COLOMBO,
2009, p. 27) “ressalta que existe uma linha tênue entre as funções da game engine e
das funções de um jogo específico. Isso ocorre devido às funcionalidades que são
particulares de um tipo característico de jogo, e como consequência, existe uma
game engine adequada para cada situação ou gênero”.
15
RESUMO DO TÓPICO 1
Neste tópico, você aprendeu que:
• Jogos 2D são bidimensionais, possuindo como medida a largura e o

comprimento. Apesar de serem desenvolvidos há muito tempo, jogos 2D
ainda são atuais e fazem muito sucesso em diversas plataformas.
• Normalmente, no desenvolvimento de jogos 2D são utilizadas imagens

pixeladas, porém, hoje já podemos encontrar jogos com imagens de excelente
qualidade. Muitas vezes imagens pixeladas são utilizadas para criar jogos
“retrô” ou clássicos, mas com as tecnologias atuais.
• Os jogos 2D tem como tipos: 2D Lateral, Isométrico, 2D Vertical e 2D Estático.

O jogo Mario Bros é um exemplo de jogo de 2D Lateral, já o jogo Sim City é do
tipo isométrico, uma vez que temos a visão mais elevada. O jogo Space Ship é
do tipo 2D vertical, e, por último, temos o 2D estático, representado aqui pelo
famoso jogo da cobrinha, onde os limites laterais são preservados.
• Os ambientes de modelagem 2D possibilitam que jogos sejam desenvolvidos

de maneira simples e rápida, pois muitos utilizam o recurso de arraste e
solte, e na maioria das vezes a programação do jogo é realizada através das
configurações que o desenvolvedor incluir no projeto do jogo.
• Sprites são imagens bidimensionais que ao se mover não deixam rastros.

Através de folhas de sprites todos os elementos (personagens, objetos e
demais elementos) tem seus possíveis movimentos criados, e os quais serão
utilizados para dar vida a esses elementos no jogo.
• Em jogos mais avançados, os motores de física podem ser criados por um

profissional. Já em projetos mais simples, pode-se utilizar as bibliotecas e
frameworks para simular a física real.
16
AUTOATIVIDADE
1 Jogos 2D possuem duas dimensões que são representadas por dois eixos, X
e Y. Sobre essas duas dimensões, assinale a alterativa CORRETA:
a) ( ) Largura X Altura.
b) ( ) Largura X Comprimento.
c) ( ) Comprimento X Profundidade.
d) ( ) Altura X Resolução.
2 Um dos tipos mais conhecidos de jogos 2D. É aquele em que o personagem

se move horizontalmente até o final da cena. Um exemplo desse tipo de
jogo é o jogo Mario Bros. Sobre esse tipo de jogo, assinale a alternativa
CORRETA:
a) ( ) Isométrico.
b) ( ) 2D Estático.
c) ( ) 2D Lateral.
d) ( ) Jogo Horizontal.
3 Sprites representam personagens e objetos que irão compor o jogo. Cada

um dos elementos é representado por desenhos quadro a quadro, os quais
serão utilizados na animação dos elementos. Sobre o conjunto de imagens
sequências, assinale a alterativa CORRETA:
a) ( ) Sprite Sheet.
b) ( ) Sprite Page.
c) ( ) Folha de animação.
d) ( ) Plano sequência.
4 A física está presente em nosso cotidiano, e em jogos ela está presente no

desenvolvimento das atividades que irão ocorrer no jogo. Disserte sobre
função do motor de física.
5 Para interagir, ou melhor falando, jogar um jogo, contamos com vários

dispositivos de entrada. Nesse contexto, disserte sobre três dispositivos de
entrada que você mais utilizou ou conhece.
17
18
DESENVOLVIMENTO DE JOGOS 3D
1 INTRODUÇÃO
Olá, acadêmico! Neste tópico iremos abordar sobre os elementos presentes
no desenvolvimento de jogos 3D. Alguns dos elementos conhecidos na Unidade
1, como: dispositivos de entrada, física, sprites e game engines, também se aplicam
no desenvolvimento de jogos 3D. Neste tópico conheceremos novos elementos.
Para começar, vamos explorar sobre o desenvolvimento de jogos 3D

através de uma introdução. Em seguida, abordaremos sobre o Uso dos Modelos
3D, conheceremos as Técnicas de Gameplay, Interação e Scripts.
Vamos começar nossa trajetória no desenvolvimento de jogos 3D?
Bons estudos!
2 INTRODUÇÃO AOS JOGOS 3D

Você se lembra do significado da expressão 2D? Se 2D significa duas
dimensões (largura e comprimento), a expressão 3D significa que além da largura
e comprimento temos a profundidade, ou seja, são tridimensionais. Jogos 2D e 3D
diferem, segundo Mioto (2010, p. 10), na “(...) quantidade de dimensões em que se
trabalha. Um jogo 2D possui apenas duas dimensões (X, representando a diretriz
horizontal e Y representado a vertical), sendo que um projeto 3D também inclui a
diretriz Z que representa a profundidade”.
DICAS
Criar um jogo em 2D ou 3D, eis a questão. No artigo ‘É melhor criar um jogo

em 2D ou 3D?’, o autor Wenes Soares apresenta os prós e contras em desenvolver jogos
2D e 3D. Confira o artigo em: https://www.crieseusjogos.com.br/e-melhor-criar-um-jogo-
2d-ou-3d/.
19
Jogos 3D são os mais desenvolvidos atualmente. Cople (2019, p. 160)

identificou que “o fascínio pelos jogos 3D é cada vez maior, isto devido ao
grande aumento da qualidade gráfica nas diversas plataformas, inicialmente
computadores e consoles, mas hoje atingindo também os dispositivos móveis”.
Na Figura 7, apresentamos alguns exemplos de jogos em 3D. Como

podemos observar nesses exemplos, existe uma alta qualidade das imagens
dos personagens, objetos e cenários, logo, o desenvolvimento de jogos 3D pode
exigir mais atenção aos detalhes que irão compor o jogo planejado. Com isso, tal
desenvolvimento é mais complexo do que a de um jogo 2D.
FIGURA 7 – EXEMPLOS DE JOGOS 3D
FONTE: <https://br.focgames.com/imgAmp/headersv2/3d3.jpg>. Acesso em: 30 jun. 2021.
Em jogos 3D é comum a utilização de câmeras em primeira pessoa. Com

isso, o jogador tem a ‘visão’ do personagem (avatar). Em muitos casos, temos a
percepção de que estamos no cenário do jogo. Assim, é possível que o jogador
tenha maior imersão na história que está sendo jogada, porém, também são
utilizadas câmeras em terceira pessoa, onde temos uma visão por cima do ombro
do personagem. Com isso, o jogador tem uma visão do personagem e como ele
interage na história do jogo (PEREIRA, 2019).
DICAS
No artigo ‘Desenvolvimento de Jogos 3D: Concepção, Design e Programação

‘, você poderá conhecer mais sobre a história do desenvolvimento de jogos 3D. Acesse em:
http://www.ic.uff.br/~esteban/files/Desenvolvimento%20de%20jogos%203D.pdf.
20
Alguns ambientes de desenvolvimento utilizados no desenvolvimento de

jogos 2D também podem ser utilizados para criar jogos 3D, como é o caso dos
softwares Construct 3, Unreal Engine e Unity. Além desses os softwares listados no
Quadro 5, também são alternativas para o desenvolvimento.
Software Endereço Descrição Gratuito Pago

Com esse software é
possível criar jogos 3D
de maneira rápida e
simples, contém diversas
https://www. ferramentas e modelos
Roblox
roblox.com/ prontos. O desenvolvedor Sim. Não
Studio
create deve criar os cenários e as
regras do jogo. Os jogos só
funcionam na plataforma
Roblox, em sistemas
Windows ou Mac.
É uma plataforma online,
não sendo necessário
instalação. Permite criar,
https:// compartilhar e jogar.
Kogama kogama.com. Possui ferramentas Sim. Não
br/ básicas, para adicionar um
elemento é arrastar para
o cenário. Os jogos são
limitados à plataforma.
Considerado um dos
Possui
http://www. melhores softwares para
3D Game uma
3dgamestu- criação de jogos 3D, o Sim.
Studio versão
dio.com/ desenvolvimento simples
de teste
com excelentes resultados.
Software de código
livre, possibilita o
desenvolvimento com
https://libgdx. várias linguagens de
libGDX Sim. Não.
com/ programação. Considerado
uma boa opção para criar
jogos de baixa e média
complexidade
FONTE: Adaptado de Nascimento (2021), IPED (2021), Gasparotto (2017)

Como você pôde observar no Quadro 5, temos vários softwares para criar
jogos em 3D, e ainda os softwares Construct 3, Unreal Engine e Unity que conhecemos
no Quadro 2, mas qual o melhor? A resposta é simples: teste e explore! Analise
cada um e veja qual melhor para você utilizar em seus projetos.
21
DICAS
Para conhecer novos ambientes de desenvolvimento ou buscar por um tipo

específico, podemos contar com o ‘Produção de Jogos’. Nele, você encontra uma lista
atualizada de todos os ambientes de desenvolvimento, do mais básico ao avançado. Utilize
os filtros para otimizar sua pesquisa. Acesse: https://producaodejogos.com/content-main/
programas-para-criar-jogos-a-lista-definitiva/.
3 USO DE MODELOS 3D
Se no desenvolvimento de jogos 2D temos os sprites, que demonstram
quadro a quadro personagens e elementos em movimento, no desenvolvimento
de jogos 3D utilizamos outro termo para a definição dos elementos que irão
compor o jogo: são chamados de Modelos 3D. Os modelos podem ser criados
utilizando um software de edição 3D ou utilizado um pacote com modelos 3D
prontos. A Figura 8 ilustra um pacote de modelos 3D.
FIGURA 8 – EXEMPLO DE MODELOS 3D
FONTE: <https://bit.ly/3vCrWOX>. Acesso em: 30 jun. 2021.
TUROS
ESTUDOS FU
Estudaremos sobre Animação 3D mais adiante neste tópico, onde iremos

conhecer alguns softwares de criação de imagens 3D.
22
Na literatura, é comum acharmos o termo de modelagem para abordar os

modelos 3D. A modelagem, segundo Jasmin (2018, p. 17):

(...) é o processo de criação dos modelos tridimensionais que irão
compor as cenas da animação. Modelagem de objetos orgânicos, como
animais pessoas e plantas é muito mais complexa do que objetos
formados de cubos esferas e outras formas geométricas básicas.
Para se modelar os elementos 3D em um software de edição, inicia-se com

a construção de uma malha, onde serão organizados os materiais, texturas e por
último os elementos de iluminação. A modelagem 3D é uma das partes mais
importantes no desenvolvimento de jogos, uma vez que é a responsável por todo
o universo (cenários, personagens, objetos, efeitos) que serão apresentados no
jogo (MARQUES, 2015).
NOTA
Ao se desenvolver um jogo, você pode escolher utilizar um banco de assets

(recursos ou elementos que compõem um jogo) para selecionar os modelos 3D dos ele-
mentos que irão compor seu jogo, porém, em projetos maiores, é recomendável que seja
desenvolvido seus próprios modelos 3D.
4 TÉCNICAS DE GAMEPLAY
O termo gameplay, na literatura, muitas vezes é remetido à jogabilidade,
traduzindo para a língua portuguesa, podemos dizer que significa jogando o
jogo. Para Schuytema (2008, p. 7), gameplay “(...) é o que acontece entre o início
e o final de um game – desde o momento em que você aprende quais são seus
objetivos até atingir a vitória ou o fracasso no final”.

Aguiar e Battaiola (2016) desenvolveram uma pesquisa buscando uma
definição do que significa Gameplay. A Figura 9 demonstra um diagrama com a
definição consensual para gameplay.
23
FIGURA 9 – MODELO DA DEFINIÇÃO DE GAMEPLAY
FONTE: Aguiar e Battaiola (2016, p. 537)
Conforme Aguiar e Battaiola (2016, p. 537):
(...) a partir de gameplay tem-se o fluxo do jogo que determina a

interação com as mecânicas de jogo resultando em playability e
jogabilidade, ambos destacados num mesmo nível relacional, pois
são equivalentes. O conceito de interação encontra-se no centro da
representação porque sua ocorrência é percebida na definição das
três categorias, associação possível por meio das mecânicas de jogo.
Assim, playability e jogabilidade relacionam-se à facilidade em jogar
e à experiência do usuário, culminando na usabilidade aplicada ao
ambiente dos jogos digitais.
O gameplay está presente em todos os elementos (nas regras do jogo, nas

condições de vitória e derrota, nos modos de interatividade, nos tipos de desafios
e metas dos games), desde o momento que o jogador inicia a partida (SENAC,
2019a).
5 INTERAÇÃO
A interação acontece quando o jogador inicia a jogo, ao se envolver com
a regras as manipulações, os personagens, cenários, ou seja, quando o jogador se
envolver com o universo do que está se jogando. Crawford (1982, p. 8-14) define
a interação como:
(...) a coisa mais fascinante sobre a realidade não é que ela existe,
ou mesmo que ela altera, mas como ela se altera, a intricada teia de
causa e efeito pela qual todas as coisas se enlaçam. A única maneira de
adequadamente representar essa teia é permitir a audiência explorar
seus cantos e recantos, deixá-los gerar causas e observar efeitos. (...)
Jogos proveem esse elemento interativo e é um fator crucial no seu
apelo.
24
A interação não está presente somente entre jogo e jogador, mas também
entre os personagens e todo universo apresentado no jogo, ou seja, a interação está
em como as regras do jogo aparecem na história, a evolução dos personagens, no
ganho de experiência do personagem, entre outras ações (COPLE, 2019). Credidio
(2007, p. 12), nos faz recordar que:
Jogos também são softwares, programáveis e que possuem interface

de interação com o jogador, mas possuem características distintas
de softwares de produção, como um editor de texto por exemplo, a
principal diferença é que jogos são feitos com a finalidade de desafiar
o jogador e muitas vezes dificulta a vida deles, já que um dos objetivos
principais do jogador-usuário é tentar vencer os desafios impostos
pelas regras do jogo.
A Figura 10, conforme Barbosa e Silva (2010, p. 18), “ilustra uma situação
típica de uso: um usuário engajado num processo de interação com a interface de
um sistema interativo, buscando alcançar um objetivo em determinado contexto
de uso”. Como podemos observar na Figura 10, no contexto do desenvolvimento
de jogos, podemos definir o usuário como o jogador; o objetivo é a conclusão de
uma ação, como passar de fase; o sistema é o jogo sendo executado e a interface
do usuário é a plataforma utilizada para se jogar, ou seja, um dispositivo.
FIGURA 10 – ELEMENTOS ENVOLVIDOS NO PROCESSO DE INTERAÇÃO
FONTE: Barbosa e Silva (2010, p. 18).
6 SCRIPTS
Scripts são os códigos de programação que estão presentes no
desenvolvimento de jogos. O scripting, ou seja, escrever os comandos ou
programar, é uma das partes mais importantes no desenvolvimento de jogos,
pois os comandos automatizam a realização de tarefas (ações) dentro do jogo
(SOUSA; FLORES; AMORIM, 2013).
25
Segundo Rogers (2012, p. 38), os desenvolvedores de jogos “usam

ferramentas para escrever códigos que permitam que coisas aconteçam no jogo,
desde disparar uma armadilha até a coreografia de um movimento de câmera”.
As linguagens de programação mais utilizadas no desenvolvimento de jogos são:
• Java;
• Python;
• C++;
• Objective-C;
• C#;
• Swift;
• JavaScript;
• C;
• Lua;
• HTML5.
Explore as linguagens e descubra qual ou quais você tem mais

familiaridade e melhor se aplica em seus projetos, mas não se assuste com essas
linguagens, alguns ambientes que apresentamos no decorrer do livro, que contém
os recursos ‘arraste e solte’, criam o código por baixo dos panos, por assim dizer.
Em ambientes de desenvolvimento avançado, é comum que o jogo seja parcial ou
totalmente desenvolvido através de linguagens de programação.
DICAS
Curioso sobre as linguagens de programação para desenvolvimento de jogos?

No vídeo ‘Linguagem de Programação para Jogos’ são discutidas essas linguagens. Para
conferir, acesse: https://www.youtube.com/watch?v=ZzV3VIgn8fI.
7 ANIMAÇÃO EM 3D
O movimento dos personagens, cenários e demais elementos são criados
através da animação. Segundo o Senac (2019a, s. p.), “A animação dos personagens
pode ser simples trocas de sprites, ou uma animação 3D baseada em movimentos
de bones (esqueletos de animação)”. O processo de criação de animações em 3D
segue uma sequência de etapas, conforme apresentado pela Figura 11 (JASMIN,
2018 apud DERAKHSHANI; MUN, 2008).
26
FIGURA 11 – EXEMPLO DE CRIAÇÃO DE UMA ANIMAÇÃO EM 3D
FONTE: Adaptado de Jasmin, 2018 (apud Derakhshani; Mun, 2008).
Na modelagem são criados os modelos tridimensionais dos elementos

(personagens, cenários e objetos) que irão compor as cenas de animação. A
texturização é onde é escolhida a aparência de cada elemento que irá fazer parte.
Na animação são definidas as câmeras e as luzes das cenas. Já na iluminação,
são escolhidas as luzes, definido se será com sombras ou iluminação global. Por
último, na renderização, é o processo de mesclar todas as definições escolhidas nas
etapas anteriores. O tempo de processamento pode variar conforme a resolução
da imagem ou da cena que foi criada (JASMIN, 2018).
Os elementos tridimensionais podem levar mais tempo para serem

desenvolvidos. A Figura 12 demostra a criação de uma cena em 3D. Segundo
Cople (2019, p. 25):
Os elementos 3D apresentam uma complexidade maior, pois

trabalham com efeitos de iluminação e texturização em tempo real,
diferentemente de um vídeo, onde a renderização ocorre toda antes
da exposição da animação.
O processo de criação em 3D é iniciado com a construção de uma malha
e definição de materiais, e você pode utilizar diversos softwares para
essa modelagem, como 3DS Max, Blender ou Maya. Durante a execução
do jogo, essa malha e materiais associados receberão a iluminação e
serão texturizadas a cada quadro, o que acaba exigindo maior poder
de processamento gráfico e matemático, sendo comumente utilizado,
como medida de eficiência, a quantidade de quadros por segundo
(FPS).
É comum a utilização de Model Sheet, tratando de um conjunto de
visões (superior, frontal, lateral) de um personagem, concebido de
forma artística, para viabilizar a modelagem computacional.
27
FIGURA 12 – EXEMPLO DE CRIAÇÃO DE UMA ANIMAÇÃO EM 3D
FONTE: <https://bit.ly/3Eaf9q5>. Acesso em: 1 jul. 2021.
DICAS
O Podcast ‘Animação 3D e Efeitos visuais’, do Sala de Edição, traz uma conversa

sobre animação 3D, computação gráfica e efeitos especiais. Ouça o podcast em: https://
bit.ly/3B2z4Wg.
A criação de animações em 3D exige bastante trabalho e dedicação para

que se tenha uma animação de qualidade. No Quadro 6, apresentamos os softwares
mais conhecidos para desenvolver animações.
Gratuito
Software Aplicação SO Formatos
/ Pago
stl, 3ds, ai, abc, ase, asm,
Captura de catproduct, catpart,
movimento, dem, dwg, dxf, dwf, flt,
3ds Max Animação de Windows Pago iges, ipt, jt, nx, obj, prj,
quadros-chave prt, rvt, sat, skp, sldprt,
(keyframes) sldasm, stp, vrml, w3d
xml
28
Gratuito
/ Pago
Captura de
Mo- movimento,
asf, amc, bvh, c3d, fbx,
tionbuil- Animação de Windows Pago
htr, tr3
der quadros-chave
(keyframes)
Captura de
movimento, Windows, 3ds, dae, fbx, dxf, obj, x,
Blender Animação de macOS, Gratuito lwo, svg, ply, stl, vrml,
quadros-chave Linux vrml97, x3d
(keyframes)
Captura de
movimento, 3ds, dae, dem, dxf, dwg,
Cinema Windows,
Animação de Pago x, fbx, iges, lwf, rib, skp,
4D macOS
quadros-chave stl, wrl, obj
(keyframes)
3dm, 3ds, cd, dae, dgn,
gf, gdf, gts, igs, kmz,
Animação de Navega- lwo, rws, obj, off, ply,
Clara.io quadros-chave dor da Gratuito pm, sat, scn, skp, slc,
(keyframes) internet sldprt, stp, stl, x3dv,
xaml, vda, vrml, x_t, x,
xgl, zpr
Captura de
movimento,
Windows,
Daz3D Animação de Gratuito obj, fbx, dae, daz
macOS
quadros-chave
(keyframes)
Captura de
Houdini Windows, Gratuito
movimento,
Appren- macOS, (com limi- bgeo, clip, fbx, geo, hip
Animação com
tice Linux tações)
keyframes
Captura de
movimento,
3ds, bvh, fbx, obj, vns,
iClone Animação de Windows Pago
skp
quadros-chave
(keyframes)
Captura de
iPi Soft Windows Pago bvh, fbx
movimento
Captura de
movimento, Windows,
MakeHu-
Animação de macOS, Gratuito dae, fbx, obj, STL
man
quadros-chave Linux
(keyframes)
29
Gratuito
/ Pago
Captura de
movimento, Windows, ai, aiff, dae, dxf, dwg,
Maya Animação de macOS, Pago eps, fbx, maya, mel, obj,
quadros-chave Linux stl
(keyframes)
Captura de
movimento, Navega-
mixamo Animação de dor da Gratuito bhv, fbx, obj
quadros-chave internet
(keyframes)
Captura de
movimento, Windows, lwo, abc, obj, pdb, 3dm,
modo Animação de macOS, Pago dae, fbx, dxf, x3d, geo,
quadros-chave Linux stl,
(keyframes)
Captura de
movimento,
Windows,
Poser Pro Animação de Pago bvh, cr2, obj, pz2
macOS
quadros-chave
(keyframes)
Animação de Windows,
chan, clip, exr, fbx, geo,
Terragen quadros-chave macOS, Pago
lwo, mov, obj, ter
(keyframes) Linux
Windows,
Linux,
SmartBo- Captura de
macOS, Gratuito af, bvh, dae, fbx, sk, xml
dy movimento
Android,
iOS
Windows,
Boats
Stop Motion macOS, Gratuito avi, mov, mpg
Animator
Linux
Windows,
Dragon-
Stop Motion macOS, Pago avi, mov, mpg
frame
Linux
Animate Windows, fla, xfl, swf, as, apr, psd,
Animação 2D Pago
CC macOS eps, jpg, png, tiff
Anima- Windows,
Animação 2D Pago formato proprietário
tion Paper macOS
ai, avi, bmp, eps, gif,
Windows,
Moho Animação 2D Pago jpeg, mov, obj, png,
macOS
targa
Windows,
gif, png, pcl, pclx, xml,
Pencil2D Animação 2D macOS, Gratuito
avi, mov, mpg, mp4
Linux
30
Gratuito
/ Pago
Windows, avi, bmp, gif, mng,
Synfig
Animação 2D macOS, Gratuito mpeg, png, ppm, sif,
Studio
Linux sifz, sfg, svg
FONTE: <https://bit.ly/3aZyq0T>. Acesso em: 1 jul. 2021.
Como podemos observar na Figura 6, existem várias opções que podemos

utilizar para criarmos animações. Explore e decida qual ou quais softwares você
tem mais familiaridade e que pode ser a melhor opção para você utilizar em seus
projetos.
31
RESUMO DO TÓPICO 2
• Jogos 3D são tridimensionais (altura X comprimento X profundidade). Jogos

3D normalmente são desenvolvidos utilizando imagens de alta qualidade e
com riqueza de detalhes, seja nos personagens, cenários ou demais objetos
presentes no jogo.
• Em jogos 3D, pode-se utilizar duas câmeras, em primeira pessoa ou em terceira

pessoa. no primeiro tipo temos uma perspectiva que estamos inseridos no
jogo, já no segundo tipo temos a visão do personagem em jogo.
• Dependendo da complexidade do jogo, podemos utilizar ambientes de

desenvolvimento de jogos 3D mais básicos ou avançados. Os ambientes
básicos normalmente contêm o recurso arraste e solte, e pouco ou nenhuma
programação. Já ambientes avançados podem ter tal recurso, mas requerem
um conhecimento maior de programação para desenvolver o jogo.
• Modelos 3D podem ser criados pelos desenvolvedores ou obtidos em um

banco assets. Através desses modelos os personagens, objetos e demais
elementos que irão compor o jogo serão animados.
• Gameplay é o que ocorre desde o início do jogo até o final. Através do

gameplay, temos a interação com as mecânicas do jogo, as quais resultam
na jogabilidade, sendo o gameplay presente em todos os requisitos que
compõem o jogo.
• Para se criar uma animação 3D é necessário seguir uma sequência de etapas:

modelagem, texturização, animação, iluminação e renderização.
• Os scripts estão presentes nos jogos, mesmo quando não foi o desenvolvedor
que o escreveu, mais sim o ambiente de desenvolvimento. Através dos scripts,
os comandos são automatizados e ações são executadas.
32
AUTOATIVIDADE
1 Jogos 3D possuem eixos X, Y e Z. Cada um destes eixos representam uma

característica das dimensão. Duas dessas características estão também
presentes em jogos em 2D, e em alguns casos como em jogos 2.5D
parcialmente implementadas. Sobre essas dimensões, assinale a alternativa
CORRETA:
a) ( ) Altura X Comprimento X Profundidade.

b) ( ) Altura X Comprimento X Resolução.
c) ( ) Largura X Altura X Dimensão.
d) ( ) Altura X Lateralidade X Profundidade.
2 A criação de animação 3D é desenvolvida através a realização de uma

sequência de etapas. Tendo como resultado modelos tridimensionais, esses
modelos podem ser personagens, cenários e objetos que irão compor a cena
do jogo, esse processo de criação é demorado, uma vez que requer cuidado
com os detalhes que irão compor cada objeto. Sobre essa sequência, assinale
a alternativa CORRETA:
a) ( ) Modelagem, Animação, Texturização, Iluminação, Renderização.

b) ( ) Modelagem, Texturização, Iluminação, Renderização, Animação.
c) ( ) Modelagem, Texturização, Animação, Iluminação, Renderização.
d) ( ) Animação, Renderização, Modelagem, Animação, Texturização.
3 O termo Gameplay não possui uma tradução oficial e unicamente

reconhecida, porém, é normalmente remetido ao termo jogabilidade. Sobre
o significado de gameplay, assinale a alternativa CORRETA:
a) ( ) O que acontece somente quando se inicia o jogo.

b) ( ) O que acontece ao se jogar.
c) ( ) O que acontece ao final da partida.
d) ( ) O que ocorre entre o início e o final do jogo.
4 Os softwares de desenvolvimento de jogos, na maioria, possuem a função

arraste e solte, porém os softwares mais avançados possibilitam que
a programação dos jogos seja criada manualmente. Disserte sobre o
significado de scripts.
5 Em jogos 3D é comum serem utilizadas câmeras em primeira e terceira

pessoas. Nesse contexto, disserte sobre a diferença entre esses dois tipos de
perspectiva do jogador.
33
34
DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
1 INTRODUÇÃO
Bem-vindo, ao terceiro tópico da Unidade 1! No decorrer deste tópico,
iremos abordar sobre o Desenvolvimento de Jogos Multiplataforma. Iniciaremos
conhecendo o que é o Plano de Desenvolvimento de Jogos Multiplataforma.
Em seguida, iremos diferenciar as Metodologias de Desenvolvimento, veremos
os elementos presentes do GDD (Documento de game design) e, na sequência,
abordaremos sobre Sistema de banco de dados, os Gêneros dos jogos, as
plataformas utilizadas para jogar e os Tipos e características dos jogos.
Antes de iniciarmos, você sabe o que significa multiplataforma? O

dicionário on-line de Língua Portuguesa Dicio define o termo multiplataforma
como:
Característica do programa, software ou aplicativo que pode funcionar

em várias plataformas (dispositivos) diferentes: jogos multiplataforma.
Particularidade do conteúdo que é transmitido em diferentes
plataformas, como televisão, computador, tablets e smartphones:
comunicação multiplataforma (MULTIPLATAFORMA, 2021, s. p.).
Talvez o termo ainda não seja tão comum em nosso cotidiano, porém,
é uma realidade em nossas vidas. Hoje, temos a facilidade e simplicidade de
podermos acessar conteúdos em vários dispositivos, com as ações que realizamos
sincronizadas em todos os nossos dispositivos rapidamente. Com os jogos,
podemos iniciar uma partida de um jogo em um dispositivo, pausá-lo e continuar
em outro momento e outro dispositivo do mesmo ponto que foi pausado.
Fantástico, não é mesmo? Duenas (2019, s.p.) destaca que aplicações (softwares)
multiplataforma funcionam “(...) em diferentes sistemas e ambientes, como
Windows, Android e Cloud. A ideia por trás do desenvolvimento multiplataforma
é entregar a melhor experiência aos usuários para cada funcionalidade do sistema
de gestão e garantir os benefícios da mobilidade”.
Vamos começar nossa jornada no desenvolvimento de jogos

multiplataforma?
Bons estudos!
35
2 PLANO DE DESENVOLVIMENTO DE JOGOS

MULTIPLATAFORMA
O plano de desenvolvimento de jogos é realizado em fases, sendo composto
pela concepção, a pré-produção, produção e finalização (pós-produção), a Figura
13 ilustra essas fases (SENAC, 2019b). Chandler (2012, p. 8) aborda que “o
planejamento do jogo é onde as informações são reunidas mostrando como tudo
será realizado”.
FIGURA 13 – ETAPAS DO DESENVOLVMENTO DE JOGOS
FONTE: Adaptado de SENAC (2019b).
Segundo Novak (2017), o plano de desenvolvimento ou plano de projeto

é criado para descrever:
(...) o percurso que será adotado para desenvolver o game. Começando

com as listas de tarefas básicas descritas no documento técnico de
design, ele estabelece dependências, acrescenta horas operacionais
e transforma tudo isso em um cronograma real. O plano final do
projeto inclui um plano de recursos, um orçamento, um cronograma
e os marcos intermediários que ajudarão a monitorar o progresso do
projeto.
O plano de recursos é uma planilha relacionando todas as pessoas
envolvidas no projeto, quando começarão a trabalhar e quanto de seus
salários será dedicado ao projeto. Ele obtém no documento técnico de
design as datas das aquisições de hardware necessárias para apoiar o
pessoal envolvido e estima quando os custos externos (como a mão de
obra terceirizada) serão contraídos. Depois de aplicar os custos fixos,
você poderá usar esses números para calcular os requisitos financeiros
mensais e o orçamento geral do game. O plano do projeto é revisto e
atualizado durante todo o transcorrer do projeto (NOVAK, 2017, p.
378).
Antes de começarmos a falar sobre as fases do plano de desenvolvimento,

vamos falar sobre a ideia. Qual a ideia do jogo? O que temos em mente para o
jogo que idealizamos? Velasquez (2009, p. 38), diz que “ideias simples constituem
grande jogos”. Toda a equipe deve contribuir com ideias, mesmo as bobas ou
mais simples podem resultar em um sucesso no futuro. Uma prática para criação
36
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
de ideias em equipe é a utilização de Brainstorming, onde todos apresentam suas

ideias e ao final os líderes realizam uma filtragem das ideias apresentadas e
extraem o que podemos definir como ‘a melhor ideia’ (SENAC, 2019b). Contudo,
depois da definição da ideia inicial, temos mais trabalho a realizar, conforme
afirma Velasquez (2009).
Uma vez criada a ideia inicial, tem de ser desenvolvida a ideia do

jogo. Essa ideia que não é mais que a estrutura do funcionamento do
jogo, não deve conter mais de oito a 10 linhas, que apenas descrevem
os desafios que o jogador irá ter de ultrapassar e o que fazer para os
ultrapassar. Nesse ponto, tem de se descrever todos os obstáculos que
o jogador terá e como os conseguir superar (...). (VELASQUEZ, 2009,
p. 38).
NTE
INTERESSA
Neste artigo de Neil Patel, podemos conhecer mais sobre a técnica de

Brainstorming, sobre o que é e como fazer um. Acesse em: https://neilpatel.com/br/blog/o-
que-e-brainstorming/.
Voltando para as fases do plano de desenvolvimento, na concepção é onde

vamos definir o que criar, a partir da ideia do que pretendemos desenvolver, mas
não é somente a ideia original que deve ser abordada na fase de concepção. A
Figura 14 ilustra os elementos pertencentes a essa fase.
FIGURA 14 – SEQUÊNCIA DE ATIVIDADES DA FASES DE CONCEPÇÃO
FONTE: Adaptado de Velasquez (2009)
Na narrativa é onde deve ser definida a história do jogo, na qual o

jogador irá percorrer. A história pode ser representada por mundos no decorrer
do percurso do jogo e os quais irão fazer parte da história do jogo. No papel
37
e objetivos é onde ocorre a descrição dos personagens, mundos, definindo as

suas características e os objetivos que podem fazer, como as movimentações
e limitações. Já no cenário é onde o jogo irá acontecer, podendo ser mais de
um. O cenário é onde o jogador interage com o mundo que foi criado, como a
utilização de uma avatar, por exemplo; sendo que no cenário o jogador pode ter a
perspectiva da primeira ou terceira pessoa. Por último, no Gameplay é o momento
do jogador se divertir, onde ele pode interagir no jogo escolhendo as opções de
movimentação, vencendo obstáculos etc. (VELASQUEZ, 2009).
TUROS
ESTUDOS FU
Em nossa próxima Unidade iremos tratar mais profundamente as fases de Pré-

produção, Produção e Pós-produção (Finalização).
3 METODOLOGIAS DE DESENVOLVIMENTO DE JOGOS

Ao começarmos a planejar o desenvolvimento de jogos, temos que
definir qual será a metodologia de desenvolvimento. Atualmente, não existe
uma metodologia específica para desenvolver jogos, com isso, as metodologias
que conheceremos a seguir tem como origem a Engenharia de Software.
Entretanto, já ocorreram iniciativas para se adaptar algumas metodologias para o
desenvolvimento de jogos, como no caso das metodologias Game Waterfall Process
(Modelo Cascata para Jogos), eXtreme Game Development (XGD) e a Gamescrum.

Podemos utilizar uma metodologia tradicional (cascata, incremental,
iterativa, evolucionária ou espiral) ou uma metodologia ágil (XP, Design Thinking,
Gamescrum, FDD ou Scrum). Na Figura 15 podemos observar as principais
diferenças entre as metodologias tradicionais das ágeis. Uma das principais
diferenças entre metodologias tradicionais e ágeis, conforme o IEEP (2020,
s.p.), é que “as metodologias tradicionais se baseiam, em etapas mais rígidas e
controladas, enquanto as metodologias ágeis se fundamentam na flexibilidade e
adaptabilidade das estratégias”.
38
FIGURA 15 – DIFERENÇAS ENTRE METODOLOGIAS TRADICIONAIS (WATERFALL) X ÁGEIS
FONTE: <https://bit.ly/3sFBkQl>. Acesso em: 6 jul. 2021.
Vamos iniciar falando sobre a metodologia tradicional cascata (Waterfall).

É uma das metodologias mais rígidas, pois ela somente avança, ou seja, uma
vez concluída uma de suas fases é iniciada a próxima. Se ocorrer algum erro,
problema ou mudança, é necessário recomeçar tudo. A Figura 16 demonstra as
sequências da metodologia cascata, que segundo o SENAC (2019c, s. p.)
(...) está dividida nas etapas de comunicação, de planejamento,

de modelagem, de construção e de entrega, conforme Pressman
2011. Como em qualquer produto, levantam-se as necessidades, ou
requisitos (concepção), cria-se um cronograma, analisa-se e se projeta
o que fazer (pré-produção), codifica-se e se testa (produção e play teste,
alpha teste e betha teste) e entrega-se o jogo (finalização).

FIGURA 16 – SEQUÊNCIA DA METODOLOGIA CASCATA
FONTE: A autora
39
Na Figura 17 podemos observar uma versão da metodologia cascata

que foi adaptada para o desenvolvimento de jogos. Ela é conhecida como Game
Waterfall Process, porém, assim como a versão original, é pouco flexível (TEIXEIRA;
GONÇALVES, 2015). No entanto, apesar dessa rigidez das sequências, essa
metodologia foi uma das mais utilizadas para a criação de jogos (SILVA, 2016
apud THORN, 2013).
FIGURA 17 – SEQUÊNCIA DA METODOLOGIA GAME WATERFALL PROCESS
FONTE: Teixeira e Gonçalves (2015, p. 13)
A metodologia interativa e incremental foi criada para responder as

fraquezas encontradas na metodologia cascata. Nessa metodologia, as fases são
avançadas através de iterações, sendo que uma fase depende da anterior. Essa
metodologia é mais flexível caso tenha que realizar mudanças ou problemas
ocorram. Pode-se dividir por interações e ao final das interações temos a entrega
do jogo desenvolvido. A Figura 18 demonstra o ciclo da metodologia iterativa.
Conforme SENAC (2019c, s. p.),
Nesse processo, é feita a comunicação, ou seja, o levantamento do

conjunto de requisitos da parte do jogo que será desenvolvida,
planejada, analisada, codificada e testada. Logo, não se verificam os
erros apenas no final do processo de desenvolvimento, mas a cada
iteração eliminando o problema apresentado pela metodologia em
cascata.
40
FIGURA 18 – CICLO DA METODOLOGIA ITERATIVA
FONTE: Adaptada de SENAC (2019c)
Nossa última metodologia tradicional utilizada no desenvolvimento de

jogos é a Evolucionária e Espiral, que segundo o SENAC (2019c, s. p.)
(...) é introduzida a etapa de entrega e integração nas iterações. O

processo de desenvolvimento do jogo, a cada iteração, vai agregando
ao jogo fases, protótipos jogáveis, para que seja feita a avaliação de
qualidade e performance, para o caso de necessitar manutenção,
serem realizadas a tempo e sem provocar grandes efeitos colaterais.
A metodologia evolutiva não se preocupa com os riscos no

desenvolvimento, mas traz a prototipagem e o design interativo. A metodologia
espiral é uma melhoria à evolucionária, pois ela se preocupa com os riscos, o seu
desenvolvimento é planejado para um longo prazo e organizado em etapas, sendo
uma das melhores alternativas de metodologias tradicionais (OLIVEIRA, 2018).
A Figura 19 apresenta o ciclo da metodologia em espiral. Em muitos casos, no
desenvolvimento de jogos, ambas são utilizas em conjunto e se complementam.
FIGURA 19 – CICLO DA METODOLOGIA EVOLUCIONÁRIA / ESPIRAL (RUP)
Conforme o SENAC (2019c, s.p.), “o processo mais conhecido é o processo

unificado, que tem sua sistematização desenvolvida pela Rational, o Rational
Unified Process (RUP). Esse processo, também, contempla as fases de concepção,
elaboração, construção e transição”.
41
Se nas metodologias tradicionais o foco é no processo, as metodologias

ágeis têm seu foco nas pessoas e em sua comunicação, com isso a burocracia foi
reduzida (SENAC, 2019c).
Vamos iniciar com a metodologia ágil XP (eXtreme Programming). Ela é

utilizada para o desenvolvimento de software, mas também pode ser utilizada
para desenvolver jogos, conforme o SENAC (2019c, s. p.), sendo “(...) baseada
nos princípios de comunicação, simplicidade, feedback, ou seja, a realimentação e
retorno ao publicador, coragem e respeito. Esses valores direcionam as atividades,
ações e tarefas da metodologia”. A Figura 20 demonstra o ciclo da metodologia
XP.

FIGURA 20 – CICLO DA METODOLOGIA XP
Foi criada uma versão da XP para o desenvolvimento de jogos, a eXtreme

Game Development (XGD), que utiliza os princípios e boas práticas do XP. Sua
criação foi motivada, segundo Carvalho (2006 apud FREITAS, 2014, p. 14) pelos
“(...) constantes atrasos presentes no desenvolvimento de jogos, em conjunto com
as altas penalidades impostas pelas publicadoras sobre os atrasos. Isso faz com
que a equipe de desenvolvimento trabalhe sobre grande pressão e aumenta as
chances da entrega de milestones instáveis”. O XGD se baseia em cinco princípios
do XP, como apresentado no Quadro 7.
42
QUADRO 7 – VALORES DO XGD
Valor Descrição
A comunicação entre os integrantes da equipe é de suma
importância. A Comunicação auxilia na solução de problemas
Comunicação
e aumenta o sentimento de cooperação entre a equipe. Além
disso, a comunicação direta deve ser feita em detrimento aos
documentos formais.
Simplicidade é, talvez, o principal valor do XGD. A lei do XP e
Simplicidade
do XGD é: “Faça o item que funcione, da forma mais simples
possível.”
É o ato de o cliente comunicar ao desenvolvedor algo de
novo que ele aprendeu sobre o problema. É também o
Feedback
desenvolvedor comunicar ao cliente estimativas, riscos e
melhorias do projeto. Quanto mais cedo se sabe, antes se pode
adaptar (Beck, 2004).
Coragem é ter ações efetivas para superar dificuldades.
Quando combinada com outros valores, torna-se uma arma
Coragem
poderosa: coragem para comunicar, para manter simples e
para ouvir o feedback (Beck, 2004).
Toda a equipe de desenvolvimento precisa ter respeito com os
demais. É preciso que cada um se importe com o projeto, caso
Respeito
contrário, o fracasso será certo. Assim como no XP, no Extreme
Game Development todos são responsáveis pelo projeto (Beck,
2004).
FONTE: Freitas (2014, p.14)
NOTA
Milistones são metas para versões intermediárias do jogo.
Além dos valores, o XGD também se baseia nas práticas do XP, porém, o
XGD utiliza apenas algumas como as apresentadas no Quadro 8.
43
Prática Descrição
A equipe deve permanecer coesa em comunicação. A
Time Inteiro
equipe é um todo, e não a soma de forças individuais.
As tarefas (assets) de um jogo devem ser feitas da forma

Design Incremental
mais simples possível, que funcionem corretamente.
São pequenas descrições das funcionalidades do jogo,
Estórias de Usuário
descritas normalmente pelo cliente.
O projeto é organizado e planejado para ser executado
Ciclo Semanal
em ciclos de curta duração.
Código Todos da equipe compartilham todo o código-fonte do
Compartilhado projeto.
No projeto não existem “pedaços” de código-fonte. O
Integração Contínua
projeto está continuamente integrado e funcionando.
Reuniões rápidas de projeto, com objetivo de que toda
Reuniões Stand-up a equipe esteja ciente do trabalho que está sendo feito
num dado momento.
FONTE: Freitas (2014, p. 15)
A próxima metodologia que é utilizada para desenvolvimento de jogos é

a FDD (Feature-driven development), que tem o foco nas funcionalidades, as quais
podem ser desenvolvidas em um poucas horas. A Figura 21, demonstra como a
FDD é desenvolvida.

Ela possui seis fases para o projeto e a funcionalidade a ser implementada.
Segundo o SENAC (2019c, s.p.), “(...) desenrolar do projeto, projeto, inspeção
de projeto, codificação, inspeção de código, progressão para construção/
desenvolvimento. Todas as etapas são desenvolvidas com base nas funcionalidades
elencadas”.
44
FIGURA 21 – DESENVOLVIMENTO DA FDD
FONTE: <https://bit.ly/3juB43f>. Acesso em: 7 jun. 2021.
No FDD, os resultados, ou seja, as funcionalidades são entregues a cada

duas semanas ou em menor tempo, os blocos das funcionalidades são valorizados
pelo líder do projeto ou o cliente. Todo o desenvolvimento é monitorado em
detalhes, assim como o planejamento (AUDY, 2012).
TUROS
ESTUDOS FU
Percebeu que falta uma metodologia ágil? Estamos falando sobre o Scrum, o
qual iremos abordar em nossa próxima Unidade, pois além de uma metodologia, o Scrum
também pode ser utilizado na gestão do processo de desenvolvimento de jogos.
O Gamescrum é uma metodologia criada com a junção das metodologias

XP e Scrum. Segundo Silva, Morais e Morais (2018, p. 18), “teve como intuito
resolver problemas recorrentes no gerenciamento de desenvolvimento dos
jogos”. Com essa junção, são utilizadas as melhores partes de cada metodologia,
ou seja, “para o melhor funcionamento de suas Sprints, do Scrum foi utilizado o
Gerenciamento de projetos e do XP a engenharia de projetos” (SILVA; MORAIS;
MORAIS, 2018, p. 18).
A metodologia Gamescrum é dividida em fases: Pré-produção, Produção e

Pós-produção. A Figura 22 ilustra o fluxo do gamescrum.

45
FIGURA 22 – FLUXO DO GAMESCRUM
FONTE: Rocha e Araújo (2013, p. 149)
Além dessas metodologias existem outras como a Game Design, OriGame

que foram criadas para o desenvolvimento de jogos e a Business Model Canvas
(SILVA, 2016). Seja utilizando uma dessas metodologias, criando uma adaptação
ou uma nova, o importante é que se tenha uma para manter o desenvolvimento
organizado e bem planejado.
TUROS
ESTUDOS FU
Em nossa próxima unidade iremos abordar sobre as três fases do Games-

crum: Pré-produção, Produção e Pós-produção.
4 GDD – DOCUMENTO DE GAME DESIGN

O Game Design Document (GDD), ou em português o Documento de
Game Design, é a espinha dorsal de um plano de desenvolvimento de jogos. esse
documento contém todas as informações do jogo e é utilizado para apresentar
aos investidores, clientes ou líderes do projeto, além de guiar toda equipe na
produção do jogo (MIOTO, 2010; LEMES, 2009).
46
O documento de design do jogo ou Game Design Document (GDD) é o

documento que apresenta detalhadamente todas as características de
um jogo, como histórias, conceitos, personagens, cenários, mecânicas
e sons, por exemplo. Esse documento serve de referência para todos os
envolvidos entenderem e estarem a par do desenvolvimento do jogo
(HIRA et al. 2016, p. 329).
O Documento de Game Design está presente em todo o desenvolvimento

do jogo e será atualizado em toda a execução do projeto, por isso, é importante que
o documento seja acessível a toda a equipe, permitindo assim que todos possam
atualizá-lo e melhorar o desenvolvimento. Segundo O SENAC (2019d, p. 2), “o
GDD deverá conter as regras do jogo, a descrição e imagens dos personagens e
cenários o leiaute de telas”. O GDD tem alguns itens, alguns autores divergem
quanto à quantidade de itens que devem compor o documento. Isso também
ocorre pois o desenvolvimento de um jogo é diferente de outro, por isso não
existe uma estrutura que possa ser aplicada para o desenvolvimento de qualquer
tipo de jogo. No Quadro 9, podemos conhecer alguns itens presentes em GDD.
Item do GDD Descrição

Deve conter o nome do jogo, a informação de direitos de autor,
Página de Título
o número da versão do jogo, o autor e a data.
Tabela de conteúdo É o índice das tabelas contidas no documento.
As versões já implementadas, deve conter a descrição de
Histórico
grandes mudanças, assim como as alterações realizadas.
Deverá conter subseções, a concepção do jogo, as
características iniciais do jogo, tipo de jogo, público alvo,
sumário do game flow (a movimentação do jogador no jogo),
Visão geral do jogo
look and feel (visão básica do jogo e seu comportamento), e o
Project scope (sumários dos principais locais e ambientes do
jogo).
Descrição da progressão do jogo (estrutura de missões),
Gameplay e os objetivos do jogo e o game flow (como o jogador tem a
mecânicas de jogo percepção). Na mecânica (movimentos, ações, combates etc) e
regras do jogo que envolvem todos os elementos do jogo.
História e
São descritos todos as histórias e personagens do jogo.
Personagem
Níveis Cada nível é explicado em mínimos detalhes.
Descrição de todo o sistema virtual, controle do jogo, áudios,
Interface
efeitos e ajuda.
Inteligência Prever as jogadas dos personagens e programa-las para se
Artificial comportarem de acordo uma com as outras.
Tecnologia Descrição do hardware do dispositivo que será utilizado o jogo.
Ou Game Art, devem ser demonstrados os desenhos do jogo,
Arte de jogo como personagens, ambientes, guia de estilo, entre outros
objetos do jogo.
47
Software Secundário Software de instalação, editor de mapas ou atualizações.

Calendário em detalhes, recursos utilizados, análise de riscos e
Gestão
plano de testes.
Apêndices Informações que não foram inclusas nos itens anteriores.
FONTE: Adaptado de Velasquez (2009)
Como citado anteriormente, os itens podem mudar conforme o tipo

de jogo que está sendo desenvolvido. Assim, você poderá criar um GDD com
itens básicos, mas é claro, que contenha todas as informações dos jogos que será
desenvolvido.
NTE
INTERESSA
Através do link a seguir você poderá conhecer um exemplo de GDD do jogo

Alien Attack: https://pt.slideshare.net/marcelinhoscf/exemplo-de-gdd.
5 SISTEMA DE BANCO DE DADOS

Em jogos, o sistema de banco de dados nos auxilia a armazenar os dados,
por exemplo, dos usuários, da partida, do tempo em que a partida foi parada, a
quantidade de pontos e níveis, entre outros. Segundo o SENAC (2019e, p. 6):
(...) informações do jogo digital representam, literalmente, a ideia

de um banco de dados: uma coleção de dados interrelacionados,
representando informações sobre um domínio específico, nesse caso,
os dados dos usuários, personagens e monstros, que compõe o mundo
virtual.
Nos jogos, podem ser utilizados seus próprios bancos de dados, sem a
necessidade de SGBD (Sistema de Gerenciamento de Banco de Dados), porém,
dependendo da complexidade dos dados que serão armazenados e do jogo, é
recomendável a utilização de SGBD. Existem tipos diferentes de banco de dados
para jogos, como:
• base de dados de tipos: armazena as informações de modelos do jogo

(estatísticas, imagens, sons etc.), essas informações não sofrem alterações e
servem como base de referência para possíveis alterações;
• base de dados de modelos: agrega modelos utilizados nos jogos, a base deve
ser de rápido acesso;
48
• persistência para salvar e recuperar o progresso no jogo: quando o jogador

pausa o jogo, é necessário salvar o ponto em que foi pausado, e carregado
quando reiniciado (SILVA, 2017).
NOTA
Um Sistema de Gerenciamento de Banco de Dados (SGBD), segundo SENAC

(2019e, p. 6), “é um software com recursos específicos, que facilita a manipulação das
informações dos dados e o desenvolvimento de programas e aplicativos. O SGBD é uma
coleção de programas, que permite que usuários criem e mantenham bancos de dados”.
Um projeto de banco de dados para jogos, assim como para softwares,

envolve o desenvolvimento de três etapas, modelo conceitual, lógico e físico. O
modelo conceitual descreve a estrutura do banco de dados. Nesse modelo são
registrados quais os dados que irão aparecer no banco de dados (SENAC, 2019e).
A Figura 23 demonstra um exemplo.
FIGURA 23 – EXEMPLO DE MODELO CONCEITUAL
FONTE: Senac (2019e, p. 8)
No modelo conceitual normalmente é utilizado o diagrama E-R (Entidade-

Relacionamento), que contém três elementos básicos: entidade, atributos e
relacionamentos (SILVA, 2017). Na Figura 23, o jogador e o personagem são a
entidade, o relacionamento é representado pelo losango ‘possui’, o qual “indica
que os dados do jogador e do personagem precisam ser associados um ao
outro, indicando que um (1) jogador possui N (vários) personagens, e que cada
personagem possui somente um jogador” (SENAC, 2019e, p. 7). E os atributos são
dados que deverão ser armazenados (login, senha, e-mail, por exemplo).
O modelo conceitual é transformado para o modelo lógico, assim passamos

a ter uma definição de como o banco de dados irá ser implementado, podendo
ser do tipo:
49
• Modelo hierárquico: “(...) organiza seus dados conectando registros

diferentes, por meio de ligações, de tal modo que cada tipo de registro tenha
apenas um pai, formando, assim, uma estrutura parecida, como uma árvore
com ramificações, a partir de uma raiz” (SENAC, 2019e, p. 8). A Figura 24
demonstra um exemplo de banco hierárquico.
FIGURA 24 – EXEMPLO DE DADOS PARA O BANCO HIERÁRQUICO
• Modelo relacional: “(...) modela o conjunto de dados de uma forma que eles
sejam percebidos pelo usuário, como tabelas, ou mais formalmente, como
relações” (SENAC, 2019e, p. 9). A Figura 25 demonstra um exemplo de banco
relacional.
FIGURA 25 – BANCO DE DADOS RELACIONAL
50
• Modelo orientado a objetos: “(...) utiliza tabelas para organizar as informações,

porém podemos representar informações mais complexas em um atributo”
(SENAC, 2019e, p. 10). A Figura 26 demonstra um exemplo de banco orientado
a objetos.
FIGURA 26 – BANCO DE DADOS ORIENTADO A OBJETOS
FONTE: Senac (2019e)
Na última fase, ao modelo físico são adicionados detalhes para o

desempenho do banco de dados, porém, não implica a funcionalidade da
implementação do banco de dados, essa fase pode ser continuada e melhora
mesmo com o banco de dados já implementado e em utilização (SENAC, 2019e).
6 GÊNEROS
Classificar um jogo pode ser uma tarefa muito difícil, já que atualmente
existem mais de 100 gêneros diferentes, principalmente pela criação de uma nova
nomenclatura pela equipe de desenvolvimento ou pelos jogadores. Hoje em dia
um jogo pode possui um gênero ou subgênero (PEREIRA, 2019; BIURRUM,
2015). Novak (2017, p. 96) define gênero de jogos como “categorias baseadas em
uma combinação de tema, ambiente, apresentação/formato na tela, perspectiva
do jogador e estratégias de jogo”.
As principais classificações de jogos foram criadas por tipologias:
• BECTA (British Educational Communications and Technology Agency) – 2003,

define uma classificação que englobe vários gêneros de jogos conforme o
estilo, temática, narrativa e atividade. O Quadro 10 demonstra os gêneros da
tipologia BECTA
QUADRO 10 – TIPOLOGIA BECTA
Gênero Descrição
Ação e Elementos de combate junto à resolução de problemas e
aventura exploração do mapa.
Luta O jogador deve derrotar diversos adversários para a conclusão
de algum objetivo principal.
51
Jogo em primeira pessoa com o objetivo de atirar no máximo

FPS
de adversários, podendo trabalhar com equipes em ambiente
multiplayer.
Gestão Controle de recursos para a manutenção de ambientes
simulados, como zoológicos e cidades.
Plataforma O objetivo é completar os níveis evitando obstáculos,
normalmente saltando e utilizando plataformas.
Corridas Simulação de corridas, podendo ser muito simples ou com
avançados recursos gráficos e de física.
Real Time Strategy engloba o controle de unidades e grupos em
RTS
tempo real com o objetivo de expansão, como na construção de
impérios através de conquistas.
RPG Role Playing Games engloba o controle de unidades e grupos para
explorar o mapa e completar missões.
Simulação Utilizados inclusive para treinamento profissional, visa simular
um ambiente real, como o cockpit de um avião.
Constru- Manipulação de personagens e ambientes para atingir
ção de determinado nível de desenvolvimento, como no caso de Spore
mundos ou The Sims.
FONTE: Cople (2019, p. 11-12)
• GRAELLS – 2000, que considera a estrutura do jogo e suas principais

competências realizadas pelo jogador no decorrer do jogo (raciocínio, lógica,
estratégia, memória, psicomotricidade) (MARTINS, 2017). o Quadro 11
demonstra os gêneros da tipologia Graells.
QUADRO 11 – TIPOLOGIA GRAELLS
Gênero Descrição
Jogos do tipo plataforma ou luta, como Sonic, Mario e Street,
Arcade
Fighter (psicomotricidade).
Esporte de forma geral, como NBA, FIFA e Need for Speed
Esportes
(psicomotricidade)
Visam completar níveis dentro de um roteiro, como Indiana
Aventura
Jones e Final Fantasy (psicomotricidade).
Simulação e Envolvem simulação e construção de mundos, como Spore e
Construção The Sims (raciocínio e psicomotricidade).
Normalmente são campanhas, como em Civilization e WOW
Estratégia
(raciocínio, lógica e estratégia).
52
Puzzles e Jogos de tabuleiro e junção de peças, como Xadrez e Tetris

Lógica (raciocínio, memória, lógica e estratégia).
Exemplos deste tipo de jogo são Quiz e Trivia (memória, lógica
Perguntas
e estratégia).
FONTE: Cople (2019, p.12-13)
DICAS
No link a seguir, você poderá acessar um artigo que apresenta os 10 gêneros

de jogos mais jogados atualmente: https://bit.ly/3vAfpLZ.
7 PLATAFORMAS
Hoje, os jogos podem ser jogados em várias plataformas, como consoles,
smartphones, computadores, entre outros. Segundo Novak (2017, p. 82), “todos
esses formatos são conhecidos como sistemas ou plataformas de games”. A
popularização dos jogos ocorreu principalmente por fliperamas, Novak (2017, p.
82) define como “sistemas de games autônomos encontrados em locais públicos
— como casas de fliperama, boliches, parques de diversão e pizzarias (...). A
maioria dos games é jogada de pé, usando controladores na forma de botões,
joysticks ou uma combinação deles”. A Figura 27 demonstra a ilustração de um
gabinete vertical.

Com sua popularização, foram criados consoles menores para que
pudessem ser instalados em televisões para se jogar. O Senac (2019f, p. 2) define
os consoles como:
(...) equipamentos eletrônicos cujo objetivo principal é rodar

jogos digitais em sua casa. Os modelos atuais permitem outras
funcionalidades, como assistir filmes, ouvir música, navegar na
internet etc. Seu hardware é conectado a um aparelho de TV, ou ainda
a um monitor de computador, para exibição das imagens. Possui
controles analógicos, constituídos de joysticks para interação com os
elementos do game.
Apesar de muitos jogos já serem multiplataforma, os consoles ainda

são muito populares e são anualmente atualizados, trazendo novos recursos,
tecnologias e funcionalidades. A Figura 27 demonstra um exemplo de console,
Playstation One. Outra plataforma popular são os consoles portáteis. Como
podemos observar um exemplo na Figura 27 (Playstation Portable), eles
podem transportados para qualquer lugar, são pequenos e funcionam à bateria
recarregável (NOVAK, 2017).
53
FIGURA 27 – EXEMPLO DE PLATAFORMAS
FONTE: Rogers (2012, p. 29-31)
Os computadores (desktop ou notebook) são amplamente utilizados para

jogar, sejam os jogos contidos no sistema operacional, os jogos instalados ou
utilizando a internet para jogar. O SENAC (2019f) identifica que existem vantagens
e desvantagens na utilização de computadores como plataforma:
A principal vantagem é que por ser uma tecnologia aberta qualquer

estúdio pode desenvolver para PCs, o que eleva a quantidade de
games disponíveis no mercado. Até mesmo os grandes estúdios, que
desenvolvem para um console específico, acabam desenvolvendo
também para PCs.
A desvantagem está relacionada a capacidade de hardware que o
computador possui para rodar determinado jogo. Em um game para
X-Box One você tem a certeza que ele rodará em qualquer console
X-Box One, pois todos são iguais. Já os computadores apresentam
configurações diferentes logo, um jogo que tem um desempenho em
um PC, pode nem iniciar em um outro que possui uma configuração
diferente (SENAC, 2019f, p. 6).
Atualmente, os smartphones são uma das plataformas mais utilizadas

para jogar, seja por estarmos sempre com nossos dispositivos, a facilidade
de utilização e instalação ou a qualidade dos jogos. Os jogos para smartphone,
segundo o SENAC (2019f, p. 10), “normalmente não apresentam uma grande
complexidade em termos de jogabilidade, pois o objetivo é um divertimento
momentâneo”. Normalmente, instalamos jogos que são divertidos e desafiadores,
para passar o tempo, como quando estamos esperando para dar continuidade a
uma atividade.
Outra plataforma utilizada para os jogos é a internet. Hoje, muitos jogos

podem ser executados em navegadores web, não precisando instalação. Também
é comum utilizar a internet para jogar em equipe, em competições etc. Novak
(2017) usa o termo de ‘game on-line’ para a plataforma internet.
54
Os games on‑line são jogados em uma plataforma de computador ou

em um sistema de console conectado à internet, mas a tecnologia
empregada difere substancialmente dos games para outras
plataformas. Os jogadores precisam de uma conexão à internet para
jogar, e as informações do game podem estar armazenadas em um
servidor. Os maiores games on‑line envolvem milhares de jogadores
simultâneos, o que, às vezes, exige que as informações do game sejam
armazenadas em vários servidores (NOVAK, 2017, p. 85).
Todas essas plataformas são utilizadas atualmente para jogos, mesmo

no caso dos fliperamas, que contam com jogos clássicos e alguns atuais. Ao
desenvolver seus projetos, você deve definir para quais plataformas, ou criar
jogos multiplataformas.
8 TIPOS E CARACTERÍSTICAS
Nem todos os jogos possuem o mesmo tipo e público. Normalmente,
jogamos jogos de entretenimento para nos divertir, fato esse confirmado
pelo I Censo da Indústria Brasileira de Jogos Digitais, realizado em 2013, que
identificou que 49,3% dos jogos desenvolvidos naquele ano foram do tipo de jogo
Entretenimento (FLEURY et al., 2014).

Santos (2010, p. 181), destaca que “diferentes tipos de jogos agradam
a diferentes tipos de jogadores, o que implica em jogadores de diferentes
personalidades, com diferentes preferências e habilidades, e que, logicamente,
endereçam suas escolhas em função de suas especificidades”. No Quadro 12,
iremos conhecer outros tipos de jogos que vem sendo mais desenvolvidos.
QUADRO 12 – TIPOS DE JOGOS
Tipo de jogo Características

Utilizam ideias de jogos, porém nenhum elemento
Game inspired design
do jogo, ou seja, possui ligações com jogos, mas não
(Design inspirado
contém nada que possa ser considera parte do jogo,
em jogos)
como dinâmicas, mecânicas etc.
É a utilização de pensamentos e elementos de jogos
G a m i f i c a t i o n em contextos fora de jogos, utiliza-se elementos como
(Gamificação) mecânica, premiações e afins, para tornar a atividade
mais competitiva e interessante.
55
São criados com o objetivo de entreter o jogador, são

divididos em quatro categorias:
- jogo de ensino ou para aprendizagem: o jogador é
ensinado a fazer algo ao jogar um jogo;
- simulador: o jogador interage com uma versão virtual
Serious Games (Jogo
de algo real;
sério) e Simulação
- jogo com significado (jogo para o bem): visa passar
uma mensagem com algum significado importante,
assim promovendo uma mudança;
- jogo com propósito: ao serem jogados possuem um
resultado no mundo real.
Que é o que conhecemos em maior quantidade
Jogo no cotidiano, os quais podem ser divididos em
entretenimento e artísticos.
FONTE: Adaptado de Pereira (2019)
No Quadro 12 foram apresentados os tipos de jogos classificados por

Pereira (2019), com base em trabalhos do profissional mais influentes na área
de jogos e design Andrzey Marczewski. Assim, Pereira (2019, p. 10) chama essa
classificação como: “o conjunto contendo todos os tipos de jogos de Game Thinking,
ou pensamento de jogo, o qual definiremos como: ‘uso de jogos e soluções
semelhantes em contextos fora e dentro de jogos’”. No documento do 1 Censo
da Indústria Brasileira de Jogos Digitais (FLEURY et al., 2014), os jogos possuem
outras classificações como: jogos publicitários (advergames), adultos, jogos para a
saúde, entre outros.
Chegamos ao fim de nossa Unidade 1 (Figura 29). Em nossa próxima

Unidade iremos continuar explorando o desenvolvimento de jogos. Até lá!
FIGURA 28 – FINAL DA UNIDADE 1
FONTE: <https://bit.ly/3876DtS>. Acesso em: 15 jul. 2021.
56
LEITURA COMPLEMENTAR
INTELIGÊNCIA ARTIFICIAL EM JOGOS ELETRÔNICOS
André Kishimoto
1.1 – Game AI (IA para jogos eletrônicos)
Para os desenvolvedores de jogos eletrônicos, as aplicações computacionais

de IA e o significado do termo IA são diferentes dos encontrados no meio
acadêmico. Para distinguir a inteligência artificial utilizada em jogos e no meio
acadêmico, os desenvolvedores adotaram o termo Game AI (FUNGE, 2004).
A principal diferença entre a IA acadêmica e a IA para jogos é o objetivo que

cada uma busca. No primeiro caso, o objetivo é buscar a solução para problemas
extremamente difíceis, como imitar o reconhecimento que os humanos são capazes
de realizar (reconhecimento facial e de imagens e objetos, por exemplo), entender
e construir agentes inteligentes (SCHWAB, 2004). No segundo caso, o objetivo de
usar inteligência artificial é a diversão. Sua importância é quanto aos resultados
que o sistema irá gerar, e não como o sistema chega até os resultados; ou seja,
o problema não é como o sistema pensa, mas sim como ele age. Isso se deve
pelo fato que jogos eletrônicos são negócios – os consumidores desses produtos
os compram em busca de diversão, e não lhes interessa como a inteligência de
um personagem no jogo foi criada, desde que ela transforme o jogo divertido
e desafiador, além, claro, de tomar decisões coerentes com o contexto do jogo
(TOZOUR, 2002) (SCHWAB, 2004).
Um dos problemas encontrados sobre IA na indústria de jogos eletrônicos

é a grande variedade de gênero dos jogos existentes e os comportamentos dos
personagens, resultando numa interpretação ampla do que é considerada IA para
jogos. Há desenvolvedores que consideram a interface do jogo com o usuário parte
da área de IA, assim como outros consideram algoritmos de movimento e colisão
também como IA (BOURG, 2004). Para (TOZOUR, 2002), é até vergonhoso que
Game AI seja chamada e considerada inteligência artificial, uma vez que no campo
de IA para jogos é necessário criar agentes com comportamentos apropriados
num determinado contexto, embora a adaptabilidade da inteligência humana
nem sempre é necessária ou desejada para produzir tais comportamentos.
Embora exista esse problema, um fato que surpreendeu muitas pessoas da

indústria ocorreu durante a mesa-redonda de IA na Game Developers Conference
(GDC) de 1999: diversos membros da parte de pesquisa acadêmica sobre IA
estavam presentes no evento e puderam compartilhar e discutir ideias sobre
o assunto com os desenvolvedores de jogos. Durante o evento, alguns desses
pesquisadores admiraram a rápida evolução de desenvolvimento da indústria
de jogos, dizendo que a indústria de jogos parecia estar anos-luz à frente do
57
meio acadêmico com relação à construção de soluções práticas de IA para certos

problemas, que estudos formais de IA podem levar anos para formular teorias
de comportamento, examinar possíveis soluções e desenvolver protótipos para
testes. Contudo, a falta de uma metodologia rigorosa faz com que muitas das
soluções encontradas pelos desenvolvedores de jogos não sejam aceitas como um
apoio aos estudos formais de IA (WOODCOCK, 1999).
(...)
3 – IA E JOGOS ELETRÔNICOS
Conforme já mencionado, a IA para jogos não é considerada a mesma

que estudada e pesquisada no meio acadêmico. No começo do desenvolvimento
de jogos eletrônicos, a programação de IA era mais usualmente conhecida por
“programação de jogabilidade”, pois não havia nada de inteligente sobre os
comportamentos exibidos pelos personagens controlados pelo computador
(SCHWAB, 2004).
(...)
3.1 – O INÍCIO DA IA EM JOGOS
Muitos programadores do início da era de jogos eletrônicos implementavam

padrões de movimentos ou movimentos repetitivos e/ou aleatórios para os
personagens controlados pelo computador (como Galaga e Donkey Kong) como
sendo a inteligência existente no jogo. Esse fato foi principalmente causado
pela falta de memória e limitação existente na velocidade de processamento
(SCHWAB, 2004).
Os jogos de estratégia (Civilization de 1991, por exemplo) estão entre os

pioneiros em IA para jogos, uma vez que tais jogos necessitam de uma boa IA para
que sejam jogáveis, pois requerem que o computador controle unidades (grupo
de personagens) com estratégias e táticas complexas. Uma extensão dos jogos de
estratégia são os jogos de estratégia em tempo real, onde toda a ação acontece em
tempo real (ao contrário de outros jogos de estratégia, que ocorre em turnos). A
IA para esse gênero de jogo deve realizar buscas de caminhos (pathfinding) para
centenas de unidades em tempo real (TOZOUR, 2002).
Jogos do gênero “sims” (simuladores de gestão de cidades, fazendas,

relações pessoais, entre outros), como o clássico SimCity, lançado pela empresa
Maxis em 1989, foram os primeiros a provarem o potencial dos métodos de
Artificial Life (A-Life). Outro jogo famoso da Maxis, The Sims (2000), conta com
personalidades profundas em seus agentes inteligentes. Tal jogo é exemplo do
potencial uso de máquinas de estado fuzzy (fuzzy-state machines ou FuSM) e A-Life.
Outro exemplo do uso de A-Life em jogos é o título Creatures (criado pela CyberLife
em 1996), que simula a psicologia e fisiologia dos personagens do jogo, incluindo
um “DNA digital” único de cada personagem (TOZOUR, 2002).
58
Em jogos de tiro de primeira pessoa (first-person shooter ou FPS), como

Half-Life (Valve) e Unreal: Tournament (lançado em 1999 pela Epic MegaGames),
a IA ficou conhecida pelo excelente nível tático dos inimigos, desenvolvida
através do uso de máquinas de estado finito (finite state machines ou FSM) e
scripts que determinam como um agente inteligente deve agir em várias situações
(WOODCOCK 1999) (TOZOUR, 2002).
3.2 – TÉCNICAS E ALGORITMOS DE IA IMPLEMENTADA EM JOGOS
Existem diversas técnicas e algoritmos utilizados pelos desenvolvedores

de jogos para dar aos personagens uma certa inteligência (ou ao menos fazer
com que os personagens pareçam ser inteligentes) e uma personalidade
(BOURG, 2004). Segundo (LAMOTHE, 1999), um dos princípios básicos de IA
para jogos são os algoritmos de IA determinísticos e padrões de movimento,
onde os comportamentos são pré-programados ou pré-processados. Ainda,
(DALMAU, 2004) cita quatro tipos principais de IA que são implementadas em
jogos: máquinas de estado, sistemas baseados em regras, algoritmos de busca e
algoritmos genéticos.
3.2.1 – Algoritmos de IA determinísticos e padrões de movimento
Os algoritmos de IA determinísticos, junto com padrões de movimento,

foram utilizados nos primeiros jogos eletrônicos da história, e são compostos
por movimentos aleatórios, algoritmos de perseguição e evasão. Movimentos
aleatórios podem ser implementados simplesmente obtendo um valor aleatório
e incrementando a posição de um personagem com tal valor. O algoritmo de
perseguição verifica a posição de um personagem 1 em relação à posição de um
personagem 2, e avança em direção a ele. O algoritmo de evasão faz o personagem
1 se distanciar do personagem 2. Os padrões de movimento fazem com que
um personagem se movimente em um determinado padrão, por exemplo, um
personagem pode fazer uma ronda em uma área retangular (LAMOTHE, 1999).
3.2.2 – Máquinas de estado
Uma máquina de estado finita é uma máquina abstrata que define os

estados em que um personagem pode se encontrar e quando ele muda de estado.
O estado atual da máquina determina como o personagem deve atuar no jogo.
Máquinas de estado foram usadas no início da criação de jogos (com IA) e são
usadas até hoje por serem de fácil entendimento, implementação e depuração de
erros. No jogo Pac-man, por exemplo, uma máquina de estado é implementada
para cada fantasma do jogo. Um fantasma pode estar nos seguintes estados:
“procurando jogador”, “perseguindo jogador” e “fugindo do jogador”. Quando
o fantasma está procurando o jogador, ele apenas se movimenta pelo labirinto
até encontrar o jogador. Quando ele se depara com o jogador, verifica se ele
pode perseguir o jogador ou se precisa fugir (isso acontece quando o jogador
obtém poder de “engolir” o fantasma), e troca de estado conforme a situação.
Se o fantasma pode seguir o jogador, ele muda seu estado para “perseguindo
59
jogador” e tenta alcançar o jogador. Se durante esse tempo o jogador ganha a

habilidade de engolir o fantasma, o fantasma muda seu estado para “fugindo do
jogador” (BOURG, 2004).
Os desenvolvedores também utilizam a lógica fuzzy em máquinas de

estado fuzzy para criar resultados de ações que são menos previsíveis e para
reduzir o grande trabalho de enumerar a grande quantidade de regras if-then.
A lógica fuzzy permite criar regras usando condições menos precisas, criando
agentes com um conhecimento imperfeito, uma vez que essa lógica é baseada em
níveis de incerteza e verdades em uma sentença (WOODCOCK, 1999) (BOURG,
2004).
3.2.3 – Sistemas baseados em regras
Alguns fenômenos não são fáceis de ser modelados em termos de estados e

transições. Considerando como exemplo os seguintes fenômenos de um cachorro
virtual:
- se há um osso por perto e o cachorro está com fome, ele irá comê-lo;
- se o cachorro está com fome, mas não há nenhum osso por perto, ele
procura por um;
- se o cachorro não está com fome, mas está com sono, ele irá dormir;
- se o cachorro não está com fome e não está com sono, o cachorro irá
andar e latir.
Essas quatro sentenças são difíceis de serem representadas através de

uma máquina de estados, pois cada sentença leva a um estado da máquina e
cada estado pode transitar para qualquer um dos outros estados. Esse tipo de
problema é conhecido por comportamento global. Máquinas de estado são úteis
para situações locais (onde dado um estado, apenas algumas condições podem
ser aplicadas como saída).
Nesse exemplo, o cachorro se comporta de acordo com um conjunto de

prioridades ou regras. Um sistema baseado em regras tem a forma “Condição _
Ação”. No exemplo citado, as regras teriam a seguinte forma:
- Fome & osso por perto _ comer.

- Fome & não osso por perto _procurar.
- Não fome & com sono _ dormir.
- Não fome & sem sono _ andar e latir.
Dessa maneira, são especificadas as condições que ativam as regras, assim

como quais ações devem ser tomadas caso a regra é ativada (DALMAU, 2004).
60
3.2.4 – Algoritmos de busca
Busca é um dos problemas mais básicos de IA para jogos. Quando um

jogo implementa uma busca pobre (ou “burra”), o resultado é personagens que
parecem totalmente artificiais e sem inteligência de navegar entre locais e desviar
de obstáculos, o que acaba com a imersão do jogo e a diversão (BOURG, 2004).
Para solucionar o problema de busca (sair de um ponto e chegar a um

destino), diversos algoritmos podem ser utilizados, sendo o algoritmo A* o
mais famoso e implementado em jogos, embora soluções como o algoritmo de
Dijkstra e waypoints também são utilizados (LAMOTHE, 1999) (DALMAU, 2004).
Em muitos jogos, os desenvolvedores representam o mundo virtual por onde
um personagem caminha através de “grades” (grids), onde cada célula pode
representar um nó de um grafo. Um custo é associado para cada célula do grid,
utilizado pela heurística do A* (LAMOTHE, 1999).
Como o uso de busca pode consumir muito tempo do processador, é

possível contornar esse problema através de caminhos pré-calculados, chamados
de waypoints, quando o jogo permite esse tipo de solução. Os waypoints são nós
em locais do mundo virtual que auxiliam no deslocamento de um lugar (nó atual)
para outro (nó destino) através de caminhos pré-calculados ou métodos de busca
de baixo custo (BOURG, 2004).
3.2.5 – Algoritmos genéticos
Dalmau (2004) cita que um dos usos de algoritmos genéticos em jogos

pode ser a geração de uma população, criando diferentes indivíduos de acordo
com um DNA virtual, sendo esse representado por um vetor de valores, cada um
sendo um parâmetro da espécie a ser modelada. Essa técnica pode ser utilizada
para a criação de pedestres em um jogo onde o mundo virtual seja uma cidade.
(DALMAU, 2004) e (LAMOTHE, 1999) também citam o uso de algoritmos
genéticos para mutação ou evolução de personagens.
3.2.6 – Outras técnicas
A IA para jogos não para por aqui. Existem outras técnicas que não foram
discutidas e que são aplicadas nos jogos. O uso de A-Life é uma delas. Alguns
jogos utilizam algoritmos de flocking para simular o movimento em grupo de
monstros, pássaros, peixes, entre outros (WOODCOCK, 1999). A implementação
de redes neurais em jogos também é realizada, onde os personagens necessitam
de aprendizado através das escolhas do jogador, como no jogo Black & White
(um gênero onde o jogador assume a posição de deus e controla o ambiente do
jogo) (BOURG, 2004). Ainda, há jogos (por exemplo, Baldur’s Gate e Unreal) que
implementam a IA através de scripts, possibilitando que qualquer pessoa possa
criar novos tipos de NPC’s (non-player characters) ou modificar um personagem já
existente de acordo com o seu estilo de jogo. Esse tipo de IA (também conhecido
por Extensible AI) é baseada fortemente em sistemas de regras (WOODCOCK,
1999).
61
3.3 – BENEFÍCIOS DO USO DE IA EM JOGOS
O principal benefício que o uso de IA em jogos pode propiciar ao

desenvolvimento de jogos é o fator diversão. Os personagens de um jogo
devem simular inteligência e erros humanos e ter personalidades, devem ser
capazes de fornecer diferentes níveis de dificuldade ao jogador, para que ele se
sinta desafiado. Além disso, os jogadores, cada vez mais, demandam melhores
oponentes em jogos mais complexos (SCHWAB, 2004). A IA em jogos aumenta a
experiência e imersão do jogo, melhorando sua jogabilidade. NPC’s inteligentes
fazem com que a criação de jogos single-player (para um jogador) seja possível,
além de melhorar a experiência em jogos multiplayer (para vários jogadores) sem
a necessidade de se ter uma comunidade de pessoas (reais) atuando durante o
jogo. Os NPC’s inteligentes são necessários a qualquer gênero de jogo para criar a
ilusão que o jogador está num mundo com outros jogadores inteligentes, além de
adicionar uma profundidade ao jogo (CHAMPANDARD, 2003).
O uso da IA também pode trazer vantagens de desenvolvimento de jogos;

segundo (CHAMPANDARD, 2003), o jogo Colin McRae Rally 2 utiliza redes
neurais e aprendizado, não sendo necessário, assim, a programação manual da
IA (uma vez que o jogo aprende como os carros devem se comportar durante
as corridas). Outros exemplos de como a IA pode ser aplicada em jogos é
encontrada nos artigos dos livros da série AI Game Programming Wisdom e da
série Game Programming Gems, ambos da Charles River Media. No volume 4 da
série Gems (KIRMSE, 2004), pode-se estudar o uso de IA para realizar a navegação
tridimensional de uma câmera, assim como o uso da IA pode aumentar a tensão
em um jogo de ação e realizar decisões feitas por NPC’s.
3.4 – PROBLEMAS ENVOLVENDO IA E JOGOS
Embora os desenvolvedores tenham encontrado muitas soluções através

da implementação de IA nos jogos, muitos problemas também aparecem pelo
uso de IA em jogos. Quatro fatores podem ser citados como principais problemas
da IA para jogos:
- Período de desenvolvimento: o curto período de desenvolvimento dos jogos

dificulta o aprendizado dos desenvolvedores para tecnologias de ponta sobre
IA e suas aplicações em um jogo comercial (BOURG, 2004);
- Algoritmos de aprendizado: os resultados produzidos por algoritmos de
aprendizado são difíceis de serem testados e depurados contra erros, visto que
os resultados não são previsíveis. Por essa razão, muitos desenvolvedores têm
preferência por técnicas de IA determinísticas, e por serem mais conhecidas
por eles e de fácil implementação e depuração (WOODCOCK, 1999);
- Poder de processamento: jogos são softwares com execução em tempo real, onde
informações são processadas e atualizadas a cada ciclo de máquina. Algoritmos
com alto custo de processamento (ainda) não podem ser implementados em
jogos que necessitam de respostas em tempo real (TOZOUR, 2002);
62
- Jogos são baseados em game design: durante o desenvolvimento de um jogo,

toda equipe baseia-se no documento de game design do jogo. No entanto, existe
um confronto entre game designers e game AI, pois os game designers constroem
a narrativa do jogo e definem a jogabilidade e eventos do jogo, tendo um
controle explícito do jogo e dos NPC’s. Surge, então, o seguinte conflito: os
designers controlam o comportamento dos NPC’s. É preciso, então, o uso de
IA? Em contrapartida, se a IA estiver presente (NPC’s inteligentes podem se
comportar com autonomia), é preciso ter designers? A solução para esse caso
é os game designers e programadores de IA entrarem em um acordo sobre o
controle sobre os NPC’s do jogo (CHAMPANDARD, 2003).
(...)
FONTE: Adaptado de <https://bit.ly/3vDVJa8>. Acesso em: 26 jun 2021.
63
RESUMO DO TÓPICO 3
• Jogos multiplataformas significa que um jogo poderá ser utilizado em vários

dispositivos (plataforma).
• O desenvolvimento de jogos é realizado em etapas: concepção, pré-produção,

produção e pós-produção.
• Na etapa de Concepção são realizadas as atividades de narrativa, papel e

objetivos, cenário e gameplay.
• Os bancos de dados para jogos que são mais utilizados são: base de dados de
tipos, base de dados de modelos e persistência.
• As principais classificações de jogos são das tipologias BECTA e GRAELLS;
CHAMADA
Ficou alguma dúvida? Construímos uma trilha de aprendizagem

pensando em facilitar sua compreensão. Acesse o QR Code, que levará ao
AVA, e veja as novidades que preparamos para seu estudo.
64
AUTOATIVIDADE
1 O plano de desenvolvimento de jogos é realizado através de uma sequência

de fases, essas fases guiam o desenvolvimento, elas podem iniciar após a
finalização da fase anterior ou também serem executadas paralelamente,
assim uma complementa a outra. Sobre essas fases sequências, assinale a
alternativa CORRETA:
a) ( ) Ideação, Reunião, Produção, Finalização.

b) ( ) Introdução, Revisão, Produção, Finalização.
c) ( ) Ideação, Pré-produção, Produção, Finalização.
d) ( ) Concepção, Pré-produção, Produção, Finalização.
2 A Engenharia de Software, auxilia no desenvolvimento de jogos ao trazer as

metodologias de desenvolvimento. No desenvolvimento de jogos, algumas
metodologias foram adaptadas. Sobre essas metodologias, assinale a
alternativa CORRETA:
a) ( ) Metodologia Evolucionária para jogos e Metodologia Incremental

Games.
b) ( ) Game Waterfall Process e eXtreme Game Development.
c) ( ) Waterfall Process Development e Metodologia Incremental Games.
d) ( ) Waterfall Process Development e eXtreme Game Programming.
3 Projeto de banco de dados para jogos é desenvolvido em três etapas, os

três modelos podem serem desenvolvidos na sequência, ou seja, a partir do
primeiro é criado o seguinte com base no que foi desenvolvido, tendo uma
nova perspectiva. Sobre as etapas, assinale a alternativa CORRETA:
a) ( ) Modelo de domínio, modelo lógico e modelo físico.

b) ( ) Modelo Conceitual, modelo lógico e modelo físico.
c) ( ) Modelo Conceitual, modelo dinâmico e modelo físico.
d) ( ) Modelo Conceitual, modelo lógico e modelo relacional.
4 Os gêneros de jogos são categorias, atualmente existem mais de 100 gêneros

diferentes, porém foram criadas duas tipologias para agrupar gêneros, a
BECTA e a GRAELLS. Disserte sobre a diferença entres essas duas tipologias
de gêneros.
5 Jogos possuem tipos diferentes e agradam a diferentes jogadores, Andrzey

Marczewski, definiu quatro tipos de jogos, disserte sobre os tipos de jogos:
Design inspirado em jogos e Gamificação.
65
REFERÊNCIAS
AGUIAR, M.; BATTAIOLA, A. L. Gameplay: uma definição consensual à luz da
literatura. SB Games. In: SIMPÓSIO BRASILEIRO DE GAMES E ENTRETENI-
MENTO DIGITAL, 15., 2016, São Paulo. Anais [...] São Paulo, 2015. p. 531-538.
Disponível em: https://bit.ly/3C8UC4q. Acesso em: 5 jul. 2021.
AUDY, J. K. FDD – Feature-Driven Development. Blog 360° Jorge Horácio, 24

set. 2012. Disponível em: https://bit.ly/3m36lvY. Acesso em: 14 jul. 2021.
BARBOSA, S. D. J.; SILVA, B. S. da. Interação humano-computador. Rio de

Janeiro: Elsevier, 2010.
BIURRUM, G. R. DESENVOLVIMENTO DE JOGOS ELETRÔNICOS COM

HTML5. 2015, 91f. Monografia (Bacharelado em Ciência da Computação) – Uni-
versidade Estadual do Sudoeste da Bahia, Vitória da Conquista, 2015. Disponí-
vel em: https://bit.ly/3jnWXkP. Acesso em: 29 jun. 2021.
CÁSSIO, É. Jogos em HTML5: explore o mobile e física. São Paulo: Casa do

Código, 2014.
CAVACO, M. Programação de jogos: Dicas e sugestões para criar jogos. 2007.

Disponível em: https://bit.ly/3B4yVkU. Acesso em: 29 jun. 2021.
CHANDLER, H. M. Manual de Produção de Jogos Digitais. 2. ed. Porto Alegre,

Bookman, 2012.
COLOMBO, C. Desenvolvimento de um jogo multiplataforma utilizando

cross platform toolkit haxe. 2017, 55f. TCC (Bacharel em Engenharia de Softwa-
re) – Centro Universitário Univates, Centro de Ciências Exatas e Tecnológicas,
Lajeado, 2017. Disponível em: https://www.univates.br/bdu/handle/10737/1677.
Acesso em: 30 jun. 2021.
COPLE, D. G. D. Desenvolvimento de Jogos II. Rio de Janeiro: SESES, 2019.
CRAWFORD, C. The Art of Computer Design. Electronic Version. Seattle:

Washington State University Vancouver, 1982. Disponível em: http://www.digi-
tpress.com/library/books/book_art_of_computer_game_design.pdf. Acesso em:
8 jul. 2021.
CREDIDIO, D. de C. Metodologia de Design aplicada à concepção de jogos

digitais. 2007, 95f. Dissertação (Mestrado em Design) – Universidade Federal
de Pernambuco, Recife, 2007. Disponível em: https://repositorio.ufpe.br/hand-
le/123456789/3415. Acesso em: 8 jul. 2021.
66
DERAKHSHANI, D.; MUN, R. L. Aprendendo 3ds Max 2008. Guia autorizado
Autodesk. Rio de Janeiro: Editora Alta Books, 2008.
MULTIPLATAFORMA. In: DICIO, Dicionário On-line de Português. Porto:

7Graus, c2021. Disponível em: https://www.dicio.com.br/multiplataforma/.
Acesso em: 9 jul. 2021.
DUENAS, C. Desenvolvimento multiplataforma: por que você não pode ignorar

esse conceito? Blog Vinco, São Paulo, 2019. Disponível em: https://bit.ly/3Bbb-
zK9. Acesso em: 9 jul. 2021.
ESCOLA BRASILEIRA DE GAMES (EBG). Combo Construct: confira dois cur-

sos para aprender as técnicas básicas de criação de jogos. [S.l.], 2016. Disponível
em: https://bit.ly/2Z9oKhA. Acesso em: 27 jun. 2021.
FLEURY, A. et al. I Censo da Indústria Brasileira de Jogos Digitais, com Vo-

cabulário Técnico sobre a IBJD. São Paulo: USP/BNDES. 2014. Disponível em:
https://bit.ly/3pBkqTg. Acesso em: 29 jun. 2021.
FREITAS, E. F. de. UFOQX – Desenvolvimento de um jogo 2d para plataforma

android. 2014, 49f. Monografia (Graduação em Sistemas de Informação) – Uni-
versidade Federal do Ceará, Quixadá, 2014. Disponível em: http://www.reposi-
torio.ufc.br/handle/riufc/25206. Acesso em: 29 jun. 2021.
GASPAROTTO, H. M. Devmedia, 2017. Como criar jogos: conheça as principais

ferramentas. 2017. Disponível em: https://www.devmedia.com.br/como-criar-jo-
gos-conheca-as-principais-ferramentas/37848. Acesso em: 30 jun. 2021.
GOMES, R. Controladores de jogos. s. d. Disponível em: https://perifericosinfor-

maticos.weebly.com/controladores-de-jogos.html. Acesso em: 30 jun. 2021.
HIRA, W. K. et al. Criação de um modelo conceitual para Documentação de

Game Design. In: SIMPÓSIO BRASILEIRO DE JOGOS E ENTRETENIMENTO
DIGITAL – SBGAMES, 15., 2016, São Paulo. Anais [...] São Paulo: USP, 2016.
p. 329-336. Disponível em: http://www.sbgames.org/sbgames2016/downloads/
anais/157033.pdf. Acesso em: 16 jul. 2021.
INSTITUTO DE EDUCAÇÃO POR EXPERIÊNCIA E PRÁTICA (IEEP). Metodo-

logias Ágeis x Metodologias Tradicionais: Quais as principais diferenças? Blog
IEEP, Juiz de Fora, MG, 2020. Disponível em: https://www.ieepeducacao.com.
br/metodologias-tradicionais/. Acesso em: 10 jul. 2021.
INSTITUTO POLITÉCNICO DE ENSINO A DISTÂNCIA (IPED). 5 programas

imprescindíveis para trabalhar com 3D e games. São Paulo, 2021. Disponível
em: https://www.iped.com.br/materias/3d-e-games/5-programas-imprescindi-
veis-trabalhar-3d-games.html. Acesso em: 30 jun. 2021.
67
JASMIN, L. Jogos I: Animação – técnicas. 2018. Disponível em: https://docero.
com.br/doc/e81vc8c. Acesso em: 2 jul. 2021.
LEMES, D. de O. Games Independentes: fundamentos metodológicos para cria-

ção, planejamento e desenvolvimento de jogos digitais. 2009, 158f. Dissertação
(Mestrado em Tecnologias da Inteligência e Design Digital) – Pontifícia Univer-
sidade Católica de São Paulo, São Paulo, 2009. Disponível em: https://sapientia.
pucsp.br/handle/handle/18241. Acesso em: 16 jul. 2021.
MANNARA, B. O que é pixel art e como fazer. TechTudo. 2016. Disponível em:
https://glo.bo/3B1BFiH. Acesso em: 26 jun. 2021.
MARQUES, G. C. Introdução ao desenvolvimento de jogos digitais utilizando

o motor de jogo UDK. 2015,119f. Dissertação (Mestrado em Tecnologias da In-
teligência e Design Digital) – Pontifícia Universidade Católica de São Paulo, São
Paulo, 2015. Disponível em: https://bit.ly/3m57BP5. Acesso em: 5 jul. 2021.
MARTINS, R. B. O uso e desenvolvimento de jogos digitais educativos no ins-

tituto federal baiano: uma experiência no campus Valença. 2017, 110f. Disser-
tação (Ciência da Computação) – Universidade Federal de Pernambuco, Recife,
2017. Disponível em: https://bit.ly/30IdEki. Acesso em: 17 jul. 2021.
MICROSOFT. Entrada para jogos. 2017. Disponível em: https://docs.microsoft.

com/pt-br/windows/uwp/gaming/input-for-games. Acesso em: 30 jun. 2021.
MIOTO, F. R. Estrutura de um jogo 2d. 2010, 87f. Monografia (Curso de Gra-

duação em Ciências da Computação) –Universidade do Sul de Santa Catarina,
Florianópolis, 2010. Disponível em: https://repositorio.animaeducacao.com.br/
bitstream/ANIMA/11162/1/103828_Felipe.pdf. Acesso em: 23 ago. 2021.
MORAIS, F. C.; SILVA, C. M. Desenvolvimento de jogos eletrônicos. Revista

e-xacta, [s.l.], v. 2, n. 2, 2009. Disponível em: https://revistas.unibh.br/dcet/arti-
cle/view/242. Acesso em: 28 jun. 2021.
NASCIMENTO, R. Liga dos games, 2021. Os 10 melhores programas para criar

jogos em 2021! 2021. Disponível em: https://www.ligadosgames.com/progra-
mas-para-criar-jogos/. Acesso em: 29 jun. 2021.
NEMITZ NETO, W. L. F. Cristina: uma ferramenta para transformar protótipos

de jogos em código reutilizável. 2015, 67f. Monografia (Curso de Graduação em
Engenharia de Software) – Universidade Federal do Pampa, Alegrete, Disponí-
vel em: https://bit.ly/3GdLC0f. Acesso em: 30 jun. 2021.
NOVAK, J. Desenvolvimento de games. São Paulo: Cengage Learning, 2017.
OLIVEIRA, F. N. de. Fábrica de jogos, 2018. Metodologias para Desenvolvimen-

to de Jogos. 2018. Disponível em: https://www.fabricadejogos.net/posts/metodo-
logias-para-desenvolvimento-de-jogos/. Acesso em: 11 jul. 2021.
68
PEREIRA, L. T. Introdução aos Jogos Digitais: Desenvolvimento, Produção e
Design. 1. ed. [S.l.]: Livrandante, 2019. Disponível em: https://bit.ly/3b4lmqQ.
PT COMPUTADOR. Dispositivos de Entrada para Extrema Jogos de Compu-

tador. s. d. Disponível em: http://ptcomputador.com/Ferragens/computer-peri-
pherals/14823.html. Acesso em: 30 jun. 2021.
ROCHA, R. V.; ARAÚJO, R. B. de. Metodologia de Design de Jogos Sérios para

Treinamento: Ciclo de vida de criação, desenvolvimento e produção. In: SIM-
PÓSIO BRASILEIRO DE JOGOS E ENTRETENIMENTO DIGITAL – SBGAMES,
12., 2013, São Paulo. Anais [...] São Paulo: UPM, 2013. p. 63-72. Disponível em:
https://bit.ly/3Gb2ipp. Acesso em: 16 jul. 2021.
ROGERS, S. Level UP: um guia para o design de grandes jogos. São Paulo: Blu-
cher, 2012.
SANTOS, H. V. de A. A importância das regras e do gameplay no envolvi-

mento do jogador de videogame. 2010, 257f. Tese (Doutorado em Artes Visu-
ais) – Universidade de São Paulo, Escola de Comunicação e Arte, São Paulo,
2010. Disponível em: https://www.teses.usp.br/teses/disponiveis/27/27159/tde-
22062010-102953/pt-br.php. Acesso em: 12 jul. 2021.
SCHUYTEMA, P. Design de Games: Uma Abordagem Prática – Série Profissio-

nal. 2. ed. [S.l.], Cengage Learning, 2008.
SENAC. Documento de game design – Game design document (GDD) para

multiplataformas Game design. Planejamento de jogos digitais para multiplata-
formas. Porto Alegre, RS: Rede Fecomércio de Educação. 2019a. Disponível em:
https://bit.ly/3b4rbF0. Acesso em: 5 jul. 2021.
SENAC. Plano de desenvolvimento do jogo digital para multiplataformas.

Planejamento de jogos digitais para multiplataformas. Porto Alegre, RS: Rede
Fecomércio de Educação. 2019b. Disponível em: https://bit.ly/3B5Vplt. Acesso
em: 5 jul. 2021.
SENAC. Metodologias de desenvolvimento de jogos. Planejamento de jogos

digitais para multiplataformas. Porto alegre, RS: Rede Fecomércio de Educação.
2019c. Disponível em https://bit.ly/3B1vlrv. Acesso em: 5 jul. 2021.
SENAC. GDD – Documento de game design. Porto alegre, RS: Rede Fecomér-

cio de Educação. 2019d. Disponível em: https://bit.ly/3GavooN. Acesso em: 5 jul.
2021.
SENAC. Sistema de banco de dados. Porto alegre, RS: Rede Fecomércio de

Educação. 2019e. Disponível em: https://bit.ly/2ZjE1Ne. Acesso em: 5 jul. 2021.
69
SENAC. PLATAFORMAS: conceitos, tipos e características. Rede Fecomércio
de Educação Porto Alegre, RS: Rede Fecomércio de Educação. 2019f. Disponível
em: https://www.senacrs.com.br/cursos_rede/planejamento_de_jogos_digi-
tais_para_multiplataformas/html/impressos/Plataformas_conceitos_tipos_e_ca-
racteristicas/plataformas_conceitos_tipos_e_caracteristicas.pdf. Acesso em: 5 jul.
2021.
SILVA, D. G. de M.; MORAIS, A. M. de; MORAIS, A. M. de. Análise compara-

tiva de metodologias usadas no desenvolvimento de jogos digitais. Cabedelo,
PB: Editora
IESP, 2018. 56 p. E-book. Disponível em: https://bibliotecavirtual.iesp.edu.br/in-
dex.php/UNIESP/catalog/view/9/5/25-1. Acesso em: 14 jul. 2021.
SILVA, J. G. da. Plataforma para criação de jogos educativos para usuários não-
-experientes. 2016, 119f. TCC (Mestrado em Ciência da Computação) – Centro
de Informática da Universidade Federal de Pernambuco, Recife, 2016. Disponí-
vel em: https://bit.ly/3b01u8z. Acesso em: 11 jul. 2021.
SILVA, M. F. P. da. Persistência e Banco de Dados em Jogos Digitais. 2017.

Disponível em: https://docplayer.com.br/6121385-Persistencia-e-banco-de-da-
dos-em-jogos-digitais.html. Acesso em: 16 jul. 2021.
SILVA, W. Techenet, 2013. Construct 2 – Uma ferramenta ideal para quem dese-
ja se iniciar no desenvolvimento de jogos. Disponível em: https://bit.ly/3niNegO.
SOARES, W. É melhor criar um jogo 2D ou 3D? 2018. Disponível em: https://

www.crieseusjogos.com.br/e-melhor-criar-um-jogo-2d-ou-3d/. Acesso em: 26
jun. 2021.
SOUSA, A.; FLORES, N.; AMORIM, P. Desenvolvimento de Jogos 2D: Criação

e distribuição de jogos 2D. Porto: UPorto/Feup, 2013. Disponível em: https://
docplayer.com.br/5914431-Desenvolvimento-de-jogos-2d-criacao-e-distribui-
cao-de-jogos-2d.html. Acesso em: 8 jul. 2021.
TEIXEIRA, C. V. M.; GONÇALVES, R. R. Metodologias de desenvolvimento

de jogos. 2015 . Disponível em: https://pt.slideshare.net/CaioViniciusMarquesT/
metodologias-de-desenvolvimento-de-jogos-e-introduo-a-game-design. Acesso
em: 11 jul. 2021.
THORN, A. Game Development Principles. USA: Cengage Learn PTR, 2013.
VELASQUEZ, C. E. L. Modelo de Engenharia de Software para o Desenvol-

vimento de Jogos e Simulações Interactivas. 2009, 121f. Dissertação (Mestrado
em Computação Móvel) – Universidade Fernando Pessoa, Porto, 2009. Disponí-
vel em: https://bdigital.ufp.pt/bitstream/10284/1361/2/DM_CarlosVelasquez.pdf.
70
UNIDADE 2 —
PRODUÇÃO DE JOGOS
• compreender as fases de desenvolvimento (pré-produção, produção,

testes e pós-produção) de produção de jogos;
• conhecer os métodos de gerenciamento para utilização em projetos de
desenvolvimento de jogos;
• aprender sobre as técnicas de Brainstorm e MoSCoW;
• conhecer os diferentes ciclos de desenvolvimento de jogos.
PLANO DE ESTUDOS
apresentado.
TÓPICO 1 – MÉTODOS DE GERENCIAMENTO DE PROJETO E

INTRODUÇÃO A PRODUÇÃO DE JOGOS
TÓPICO 2 – FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
TÓPICO 3 – TESTES E FASE DE PÓS-PRODUÇÃO
CHAMADA

71
72
UNIDADE 2
TÓPICO 1 —
MÉTODOS DE GERENCIAMENTO DE PROJETO E

INTRODUÇÃO A PRODUÇÃO DE JOGOS
1 INTRODUÇÃO
Olá, acadêmico! Seja bem-vindo a nossa segunda Unidade da disciplina
de Desenvolvimento de Jogos Multiplataforma! No decorrer desta unidade,
iremos abordar sobre a Produção de Jogos. Para iniciarmos, iremos conhecer, no
Tópico 1, sobre os Métodos de Gerenciamento de Projeto e uma breve introdução
sobre a produção de jogos.
No decorrer deste tópico iremos conhecer sobre o métodos de

gerenciamento de projetos são abordados no desenvolvimento de jogos, os
métodos de gerenciamento que iremos conhecer, além pode derem ser utilizados
no desenvolvimento de jogos são utilizados no desenvolvimento de tecnologias,
porém, também podem ser aplicados em projetos, em seguida explorar sobre o
Processo pessoal de software (PSP), a metodologia SCRUM, o Project Management
Institute (PMI) e por último conheceremos o Ciclo de produção de jogos.
Vamos começar a nossa jornada agora, padawan! Bons estudos!
2 MÉTODOS DE GERENCIAMENTO DE PROJETOS

Em nossa unidade anterior, conhecemos algumas metodologias utilizadas
no desenvolvimento de jogos, agora iremos conhecer alguns métodos de
gerenciamento de projetos. A metodologia XP (Extreming Programing) que vimos
anteriormente também é utilizada como um gerenciador de projetos. Bom, mas
vamos conhecer novos métodos agora.
O que significa o termo projeto? Tão presente em nosso cotidiano, esse

termo pode passar despercebido. Segundo Espinha (2021), projeto é definido
como:
Um projeto é um esforço único, temporário e progressivo empreendido

para criar um produto, serviço ou resultado exclusivo.
Isso significa que um projeto é uma ação especial que tem início
e fim determinados (é, portanto, temporária), e um objetivo claro a
ser atingido dentro dos recursos que são destinados a ele (humanos,
financeiros e materiais). Geralmente, os projetos são divididos em
etapas, as quais vão sendo executadas para gerar entregas (ESPINHA,
2021, s. p.).
73
UNIDADE 2 — PRODUÇÃO DE JOGOS
A Figura 1 demonstra o como a comunicação é importante ao se criar um

produto. Como podemos observar na primeira imagem da figura, a definição do
que o cliente quer e o que ele recebeu, conforme apresentando na última figura,
mostra uma distorção da ideia que o cliente queria inicialmente. O sucesso do que
viemos a desenvolver depende da qualidade do jogo que será produzido, pois ele
é o serviço/produto o qual deverá ser entregue e utilizado (SENAC, s. d.).
FIGURA 1 – ENTREGA DE UM PROJETO DE BALANÇO
FONTE: <https://bit.ly/3pBuyvv>. Acesso em: 25 jul. 2021.
Em grande desenvolvimento de jogos é comum que o gerenciamento de

projetos do desenvolvimento de jogos seja realizado por uma pessoa específica
ou uma equipe que tem como objetivo garantir que os prazos, tarefas e atividades
sejam implementadas e realizadas, porém, em jogos mais simples é comum
que essa atividade de gerenciamento seja realizada pelo desenvolvedor ou em
parceria com todos os integrantes da equipe.
74
TÓPICO 1 — MÉTODOS DE GERENCIAMENTO DE PROJETO E INTRODUÇÃO A PRODUÇÃO DE JOGOS
Ao se gerenciar um projeto, alguns elementos essenciais precisam ser

controlados, a Figura 2 apresenta as principais partes do gerenciamento de
projetos. Os recursos representam toda a equipe que irá atuar no projeto, os
riscos precisam ser identificados a fim de que o objetivo do projeto seja entregue,
os custos devem ser controlados e medidos, a comunicação trata de como será
o relacionamento entre cliente x líder e líder x equipe, os prazos devem ser
mensurados e controlados a fim de garantir que não ocorram atrasos na entrega
e, por último, as compras trata-se de recursos que essenciais que devem ser
comprados para serem utilizados no decorrer do projeto.
FIGURA 2 – PARTES ESSENCIAIS DO GERENCIAMENTO DE PROJETO
FONTE: <https://bit.ly/2ZrA7BL>. Acesso em: 25 jul. 2021.
DICAS
O tema Gerenciamento de projetos é muito amplo, e pode ser aplicado não

somente no desenvolvimento de jogos, mas em todas as atividades realizadas, assim é
bem mais provável que as atividades sejam realizadas e entregues antes do prazo e com
qualidade. Neste vídeo, você poderá conhecer mais sobre o tema: https://www.youtube.
com/watch?v=9mCQORwPY-A.
2.1 PROCESSO PESSOAL DE SOFTWARE (PSP)

Erros e problemas podem acontecer e acontecem quando se desenvolve
softwares, e o desenvolvimento de jogos não foge à regra. No entanto, esses erros
e problemas podem afetar o desempenho do desenvolvimento e do projeto.
Para isso foi criado o Processo de Software Pessoal (Personal Software Process) o
PSP. O PSP é um processo de desenvolvimento para engenheiros de software
(desenvolvedores), porém, não se limita a esses profissionais, uma vez que pode
ser seguido por todos os integrantes da equipe de desenvolvimento do projeto
(RICARDO, 2012; BRUN, 2002). O PSP é descrito por Ladeira (2012) como “um
processo de automelhoria projetado para ajudar o engenheiro de software a
controlar, administrar e melhorar o modo como ele trabalha. Sendo uma estrutura
de formulários, diretrizes e procedimentos para o desenvolvimento de software”.
75
O PSP tem como objetivos:
• Ajudar os integrantes do projeto a serem melhores engenheiros de softwares

(desenvolvedores).
• Ser um mecanismo para melhor o nível pessoal, a capacidade de planejamento,
acompanhamento e na qualidade dos resultados do produto/serviço
desenvolvido.
• Poder ser utilizado como ferramenta para gerenciar atividades pessoais ou
profissionais.
• Melhorar a produtividade.
• Corrigir erros mais cedo no projeto.
• Melhorar a qualidade dos produtos/serviços (CÔRTES, 1998; RICARDO,
2012).
Observando os objetivos, devemos adotar um processo pessoal que seja

bem definido, para isso devemos controlar o tempo gasto em cada atividade
realizada e sua qualidade, assim essas informações podem auxiliar na execução
de futuros projetos e atividade. A Figura 3 demonstra o fluxo do PSP. Através dos
requisitos, usa-se “scripts” como guia em cada case do processo (planejamento,
modelagem, revisão da modelagem, codificação, revisão da codificação,
compilação, testes e finalização (RICARDO, 2012). Ao realizar cada uma das fases
do fluxo, devem ser coletados dados sobre o tempo gasto, defeitos e problemas
que ocorram, através da análise desses dados com o que foi planejado é possível
avaliar o processo das atividades desenvolvidas.
FIGURA 3 – PROCESSO DE FLUXO DO PSP
FONTE: Adaptado de Humphrey (2000)
76
Utilizar o PSP traz uma série de benefícios, como a produção com menos
defeitos, confiança da equipe, entre outros benefícios. No entanto, os benefícios da
utilização do PSP podem ser percebidos no âmbito pessoal e da organização. No
Quadro 1 vamos conhecer os benefícios para cada um (BRUN, 2002; LADEIRA,
2012).
QUADRO 1 – BENEFÍCIOS DA UTILIZAÇÃO DO PSP
Benefícios pessoais Benefícios para organização

O programador ganha uma
Dados do PSP melhoram o planejamento
avaliação das suas forças e
e o gerenciamento do cronograma de
fraquezas, mostrada nos dados do
projetos de software.
PSP.
A remoção de defeitos introduzidos
O programador pode interpolar
antes da compilação e testes resulta em
dados colecionados de tal forma
um produto de melhor qualidade, reduz
que podem ser derivadas ideias
o custo dos testes e diminui o tempo de
para a melhoria de processos.
desenvolvimento.
O programador pode resistir O PSP introduz um aprendizado e
a uma pressão irracional por prática para a melhoria do processo.
discussão do tamanho antecipado Pequenos ciclos de desenvolvimento
do problema e relacionar isto a e os dados pessoais tornam fácil o
sua produtividade histórica. entendimento e aumenta a experiência.
O PSP ajuda os engenheiros e seus
gerentes a aprenderem a prática da
A conclusão organizada de um quantificação do gerenciamento do
projeto fornece ao programador processo. Eles aprendem o uso do
um senso de realização pessoal. processo definido e aprendem também a
coletar dados para gerenciar, controlar e
melhorar o trabalho.
Considerando que o programador Finalmente, o PSP expõe os engenheiros
tem um processo repetível, a 12 áreas chaves do CMMI (KPAs).
consistente e estável, ele vai Com isso, facilita a preparação dos
ganhar mais confiança do seu engenheiros a participar na melhoria
grupo. baseada no CMMI.
FONTE: Adaptado de Ladeira (2012)
77
DICAS
O CMMI (Capability Maturity Model® Integration) é uma abordagem para a

melhoria de processos, que as organizações podem utilizar para deixar os processos mais
eficazes. Neste vídeo, você poderá conhecer sobre a aplicação do CMMI: https://www.
youtube.com/watch?v=lFrsy6sPVic.
Como podemos observar no Quadro 1, são vários os benefícios da

utilização do PSP, ao escolher o PSP estamos optando por um gerenciamento
de projeto em que a qualidade é ponto chave, e onde os defeitos são estudados e
analisado para que não venham ser repetido em futuras ações/atividades.
2.2 SCRUM
A metodologia ágil Scrum é uma das mais utilizadas em desenvolvimento
de softwares, jogos e projetos, pois ela é menos burocrática. Os acompanhamentos
são visuais e informais, a comunicação entre os participantes e com o cliente
é clara, uma vez que ele pode acompanhar todo o processo, e acima de tudo
valoriza a integração da equipe, assim, essa metodologia pode ser utilizada
por grupos pequenos ou grandes (OLIVEIRA, 2018). Lima e Aymone (2015)
afirmam que o método definido como Scrum é mais voltado ao gerenciamento de
processos dentro de projetos, ao passo que a XP está mais associada a processos
de desenvolvimento técnico de software.
O Scrum surgiu como uma alternativa para os métodos tradicionais de

desenvolvimento de software. Na literatura, é comum encontrarmos Scrum como
um framework,
(...) para criação de produtos complexos que vem sendo utilizado

desde a década de 90, e destaca-se dos métodos ágeis existentes pela
maior ênfase dada ao gerenciamento do projeto. O Scrum é formado
por um conjunto de boas práticas de gestão que admite ajustes rápidos,
acompanhamento e visibilidade constantes e planos realísticos
(GOMES et al., 2011, p. 1).
O Scrum tem como principal objetivo prover um framework para

gerenciamento de projetos onde, a partir de um backlog inicial (conjunto de
atividades de uma entrega), prioriza-se o trabalho que será realizado na iteração
(denominado sprint), gerando um potencial produto no final de cada ciclo. Por
isso, é comum a utilização do Scrum no desenvolvimento de projetos de recursos
tecnológicos.
78
E
IMPORTANT
O framework é um pacote de códigos prontos que podem ser utilizados no

desenvolvimento de sites. A proposta de uso dessa ferramenta é aplicar funcionalidades,
comandos e estruturas já prontas para garantir qualidade no projeto e produtividade
(SOUZA, 2019).
Como podemos observar, o Scrum pode ser utilizado como uma

metodologia de desenvolvimento ou um gerenciador de projetos. O processo do
Scrum é apresentado pela Figura 4, o qual demonstra como o Scrum como um
processo incremental e interativo.
FIGURA 4 – PROCESSO DO SCRUM
FONTE: <https://bit.ly/2XLXgOE>. Acesso em: 26 jul. 2021.
Na Figura 4, podemos observar os ciclos do processo, o Scrum é dividido

utilizando ciclos chamados de Sprints (interações), onde cada um dos sprints
representa uma série de tarefas a ser executadas em um período de tempo, o qual
pode variar entre duas ou quatro semanas, dependendo do que foi definido. No
início de cada Sprint, toda equipe fica encarregada de implementar funcionalidades
do projeto, as quais são apresentadas em uma lista chamada de Product Backlog.
Durante o período de execução do Sprint são realizadas reuniões diárias rápidas
de até 15 minutos com todos da equipe, as quais são chamadas de Daily Scrum.
Nessa reunião os integrantes da equipe devem responder a três perguntas:
79
• O que eu fiz desde o Daily Scrum anterior?

• O que farei até o próximo Daily Scrum?
• Quais são os impedimentos que estão me atrasando?
Ao responder essas perguntas, todos os integrantes irão saber o status

de desenvolvimento de atividades de cada um, porém, o Daily Scrum não tem
como objetivo ser uma reunião para solucionar problemas. Para isso, podemos os
problemas que venham surgir no desenvolvimento das atividades para a reunião
do final do Sprint, chamada de Sprint Review. Nesta reunião são analisados se as
atividades atribuídas para o Sprint foram concluídas, seus problemas etc., tem
como característica ser uma reunião casual, na qual se receba um feedback honesto
das atividades. As atividades que não foram concluídas voltam para a lista de
Sprint Backlog para serem incluídas no próximo ciclo de Sprint, após a reunião de
Planejamento do Sprint (SILVA et al. 2018; LOURENÇON et al., s.d.). A Figura 5
demonstra todas as etapas sequências do Scrum.
FIGURA 5 – SEQUÊNCIA DE ETAPAS DO SCRUM
FONTE: <https://bit.ly/30YkS3L>. Acesso em: 26 jul. 2021.
No Scrum temos três papéis distintos, o Product Owner (PO) é do cliente,

por assim dizer. Ele é quem pagará pelo projeto e o qual irá aprovar as entregas e
solicitar mudanças no produto em desenvolvimento. Em seguida, temos o papel
de Scrum Master (SM), que é um membro da equipe com a função de liderança,
sendo responsável por manter o Product Backlog, Sprint Backlog, além de comandar
as reuniões o Scrum Master é o responsável de resolver os problemas que ocorram
no desenvolvimento, logo esse papel está em todas as etapas do Scrum. Por
último, temos a Team Scrum, também conhecida como Equipe Scrum ou Equipe
de desenvolvimento, a qual é responsável por executar o projeto (COLOMBO,
80
2017). A Figura 6 demonstra o relacionamento de intersecção dos papéis do

Scrum. O Product Owner se relaciona com a Equipe Scrum para dar esclarecimento
sobre as atividades a serem desenvolvidas, a Scrum Master se relaciona com a
Equipe Scrum para apoiar e garantir o progresso das atividades, o Scrum Master
se relaciona com o Product Owner para apoiar e reforçar o planejamento das
atividades, porém, os três papéis se relacionam de forma harmônica e constante
ao longo dos Sprints (CAMPOS, 2021).
FIGURA 6 – PAPÉIS DO SCRUM
Product Owner
Planejamento Progresso
SCRUM
Scrum Master Equipe Scrum

Esclarecimento
FONTE: <https://bit.ly/2Zm80DS>. Acesso em: 26 jul. 2021.
Cada um dos papéis do Scrum tem responsabilidade dentro do desen-

volvimento do Scrum, Sabbagn (2014) identificou as seguintes responsabilidades
conforme cada um (Figura 7).
81
FIGURA 7 – RESPONSABILIDADES DOS PAPÉIS
FONTE: Adaptado de Sabbagn (2014).
Apesar de alguns autores dizerem que o Scrum é uma metodologia para

grupos pequenos com no máximo 9 integrantes, é comum que esse número seja
maior na prática, e que na equipe de desenvolvimentos seja subdividida com
equipes de áreas específicas, por exemplo, de design, de análise, programação,
entre outros funções, nesses casos é comum que se tenha um líder da subequipe o
qual participa de todas as reuniões, passando assim as informações das reuniões
e status de andamento do sprint para seu colegas de subequipe.
DICAS
Quer conhecer mais sobre o Scrum no desenvolvimento de jogos? Assista a

esse vídeo: https://www.youtube.com/watch?v=k6mrbk3fQXA.
2.3 PROJECT MANAGEMENT INSTITUTE (PMI)

O Project Management Institute (PMI) é descrita no guia de conhecimento
de gerenciamento de projeto do Project Management Book Of Knowloedge
(PMBOK), nele, são utilizados os processos que se adequam a uma metodologia
de desenvolvimento (SENAC, 2009b).
Atualmente o PMBOK encontra-se em sua sétima edição, é tem como

objetivo apresentar as melhores práticas para o gerenciamento de projetos,
contém uma descrição sobre os conjuntos de processos que são necessários para
que seja realizado as atividades de gerenciamento de projeto (LEITE et al., 2015).
82
Como podemos observar na Figura 8, o Mapa de processos do PMBOK

é composto por várias fases e processos que devem ser realizados para que a
próxima área seja executada. Ao todo, são 10 áreas de gerenciamento, sendo elas:
1. Gerenciamento de aquisições do projeto;

2. Gerenciamento da qualidade do projeto;
3. Gerenciamento de riscos do projeto;
4. Gerenciamento do escopo do projeto;
5. Gerenciamento de custos do projeto;
6. Gerenciamento de integração do projeto;
7. Gerenciamento das comunicações do projeto;
8. Gerenciamento de recursos humanos do projeto;
9. Gerenciamento de tempo do projeto;
10. Gerenciamento das partes interessadas.
FIGURA 8 – MAPA DE PROCESSOS DO GUIA PMBOK – 6ª EDIÇÃO
4.2 - INTEGRAÇÃO
DESENVOLVER O PLANO 4.3 - INTEGRAÇÃO
DE GERENCIAMENTO DO PROJETO
6.2 - CRONOGRAMA
ORIENTAR E GERENCIAR
4.1 - INTEGRAÇÃO 6.1 - CRONOGRAMA 6.3 - CRONOGRAMA O TRABALHO DO PROJETO
5.1 - ESCOPO
PLANEJAR O DEFINIDAS AS
DESENVOLVER O GERENCIAMENTO ATIVIDADES SEQUENCIAR AS 4.4 - INTEGRAÇÃO
PLANEJAR O ATIVIDADES
9.3 - RECURSOS
GERENCIAR O
TERMO DE GERENCIAMENTO DO CRONOGRAMA CONHECIMENTO
ABERTURA
Profª.
DOMiriam De Cassia Do DO
PROJETO
ESCOPO
Carmo Mascarenhas Mattos 6.4 - CRONOGRAMA 6.5 - CRONOGRAMA
DO PROJETO
7.1 - CUSTOS 8.2 - QUALIDADE

Profª. Raffaela Dayane5.2Afonso
- ESCOPO PLANEJAR O
ESTIMAR AS
DESENVOLVER O
DURAÇÕES DAS REALIZAR A
GERENCIAMENTO CRONOGRAMA 9.4 - RECURSOS
13.1 - PARTES INTERESSADAS

COLETAR OS DO CUSTO ATIVIDADES QUALIDADE
REQUISITOS 7.2 CUSTOS 10.2 - COMUNICAÇÕES
9.1 - RECURSOS 7.3 CUSTOS
ESTIMAR OS GERENCIAR AS
5.3 - ESCOPO CUSTOS DETERMINAR O COMUNICAÇÕES
9.5 - RECURSOS
ORÇAMENTO
DEFINIR O 13.2 - PARTES INTERESSADAS 13.3 - PARTES INTERESSADAS
ESCOPO 9.2 - RECURSOS PLANEJAR O GERENCIAR O

ENGAJAMENTO ENGAJAMENTO
DAS PARTES DAS PARTES
5.4 - ESCOPO
INTEGRAÇÃO INTERESSADAS 12.2 - AQUISIÇÕES
INTERESSADAS
CRIAR A EAP 10.1 - COMUNICAÇÕES 8.1 - QUALIDADE
CONDUZIR AS
12.1 - AQUISIÇÕES
ESCOPO PLANEJAR O AQUISIÇÕES 11.6 - RISCOS
11.1 - RISCOS GERENCIAMENTO IMPLEMENTAR
CRONOGRAMA DA QUALIDADE RESPOSTAS A RISCOS
PLANEJAR O
GERENCIAMENTO
CUSTOS DE RISCOS 11.3 - RISCOS 11.4 - RISCOS 11.5 - RISCOS
QUALIDADE REALIZAR REALIZAR 4.7 - INTEGRAÇÃO

11.2 - RISCOS
A ANÁLISE A ANÁLISE PLANEJAR
RECURSOS IDENTIFICAR QUALITATIVA QUANTITATIVAS RESPOSTAS ENCERRAR O
OS RISCOS DOS RISCOS DOS RISCOS AOS RISCOS PROJETO OU FASE
COMUNICAÇÕES
RISCOS
4.5 - INTEGRAÇÃO 5.5 - ESCOPO 6.6 - CRONOGRAMA 8.3 - QUALIDADE 11.7 - RISCOS 13.4 - PARTES INTERESSADAS
AQUISIÇÕES
MONITORAR O
MONITORAR VALIDAR O CONTROLAR O CONTROLAR A MONITORAR OS ENGAJAMENTO
PARTES
INTERESSADAS E CONTROLAR ESCOPO CRONOGRAMA QUALIDADE RISCOS DAS PARTES
O TRABALHO DO INTERESSADAS
PROJETO
5.6 - ESCOPO 7.4 - CUSTOS 10.3 - COMUNICAÇÕES 12.3 - AQUISIÇÕES 4.6 - INTEGRAÇÃO
9.5 - RECURSOS REALIZAR O
CONTROLAR O CONTROLAR MONITORAR AS CONTROLAR AS CONTROLE
ESCOPO OS CUSTOS COMUNICAÇÕES AQUISIÇÕES INTEGRADO DE
MUDANÇAS
FONTE: <https://bit.ly/3GsbkOG>. Acesso em: 26 jul. 2021.
Como podemos observar na Figura 8, a sequência de etapas a serem

desenvolvidas utilizando o PMBOK é mais ampla e todos os processos são
descritos, as outras metodologias que vimos anteriormente possuem processos e
fases de desenvolvimento mais simples, porém é comum que essas metodologias
seja paralelamente, ou seja, uma auxiliando a outra e claro melhorando o
83
desenvolvimento. Em todas elas podemos observar o foco no desenvolvimento

com qualidade, com monitoramento das atividades e recursos e onde a
comunicação é um dos elementos para que o serviço/produto idealizado seja
entregue.
NTE
INTERESSA
O PMBOK® (Project Management Body of Knowledge), consiste, na verdade,

em uma padronização que identifica e conceitua processos, áreas de conhecimento,
ferramentas e técnicas da gestão de projetos (CAMARGO, 2019). Quer conhecer como
ocorre todo o processo do PMBOK? Assista a este vídeo: https://www.siteware.com.br/
blog/projetos/gerenciamento-de-projetos-pmbok/.
3 CICLO DE PRODUÇÃO DE JOGOS

Na primeira Unidade conhecemos o ciclo de produção da Metodologia
Gamescrum, porém, outros ciclos de produção de jogos são encontrados na
literatura. A seguir, conheceremos alguns, porém, vale ressaltar que apesar de
possuírem diferenças os quatro ciclos que conheceremos apresentam as mesmas
fases de Pré-projeto, Projeto e Pós-projeto com algumas variações entre elas.
Na Figura 9 podemos observar o modelo de ciclo de desenvolvimento de

jogos proposto por Ramadan e Widyani no trabalho “Game development life cycle
guidelines”, em 2013. Na fase de início, é definido o conceito do jogo, já na fase de
Pré-produção são criados os protótipos e é avaliado todo o seu conceito, na fase
de Produção, é criado o jogo, sendo nesta fase realizada a codificação e inclusão
dos elementos que irão compor o jogo. Terminada a Produção, inicia-se a fase de
Teste, onde são realizados testes internos com a versão Alpha do jogo, analisando
a usabilidade e jogabilidade. Caso ocorram problemas nesta fase, é realizada uma
nova fase de Pré-produção a fim de corrigir os erros encontrados. Após corrigidos
pela fase de Produção, o jogo passa para a fase de Testes e em sequência para a
fase Beta, onde é criada uma versão do jogo para avaliação junto ao público-alvo,
e o qual será avaliado para identificar se passara para a fase seguinte. Por último,
na fase de Lançamento a documentação, é finalizada e o jogo é preparado para ser
disponibilizado para o público em geral (BARATA et al., 2020 apud RAMADAN;
WIDYANI, 2013).
84
FIGURA 9 – MODELO DE CICLO DE DESENVOLVIMENTO DE JOGOS
Teste Beta Lançamento
Pré-
Início Produção Produção
Versão Conceito/Desenho Versão Alpha Versão Beta Versão de Lançamento

Estágio Fundação Estrutura Detalhamento Formal Refinamento
FONTE: Adaptado de Barata et al. (2020) apud Ramadan e Widyani (2013)
Outro ciclo é o apresentado por Novak (2017). Na Figura 10, podemos

observar que ele possui similaridade com a proposta de Ramandan e Widyani,
porém, contém outras etapas como Protótipos, onde são criadas as telas dos
jogos, e a fase Ouro onde o jogo é fabricado e gravado em uma mídia para ser
vendido, mas é comum que também seja distribuído em lojas digitais de consoles
(MENEZES, 2015).
FIGURA 10 – FLUXO DE CICLO DE VIDA
FONTE: <https://static.wixstatic.com/media/5e8a7d_695e284232c94455bd0897619da1fd62.
png>. Acesso em: 25 jul. 2021.
85
Chandler (2012) apresenta um ciclo básico de produção de jogos, o qual

possui quatro fases: pré-produção, produção, testes e pós-produção, o qual é um
processo ciclo, assim uma fase auxilia no desenvolvimento da outra (figura 11).
Na fase de pré-produção é definido o conceito, levantado os requisitos do jogo,
realizado o planejamento do projeto e avaliação de risco. Na fase de produção é
implementado do plano, rastreado o progresso e avaliação de risco. Na fase de
testes é realizada a validação do plano e a liberação do código, na última fase a
finalização, e criado o Post-mortem e o plano de arquivamento. Vale ressaltar que
existem uma versão do ciclo com apenas as fases de pré-produção, produção e
pós-produção, tendo as perspectivas de design (SCHUYTEMA, 2008).
FIGURA 11 – CICLO BÁSICO DE PRODUÇÃO
FONTE: Adaptado de Cezarotto e Battaiola (2018, apud CHANDLER, 2012)
TUROS
ESTUDOS FU
Nós próximos tópicos iremos conhecer as fases de desenvolvimento, confor-

me Schuytema (2008) e Chandler (2012), que é composta por quatro fases (pré-produção,
produção, testes e pós-produção).
A pergunta que fica é: qual ciclo usar? Bom, como podemos observar
nestes ciclos, eles possuem aspectos similares, a escolha entre um ou outro é
uma decisão da equipe. Para facilitar essa escolha, Rocha e Araújo (2013) criaram
um quatro comparativo dos ciclos de vida (quadro 2) dos autores Novak (2017),
Chandler (2012) e Schuytema (2008), onde são apresentas todas as fase e ações
realizadas.
86
QUADRO 2 – COMPARATIVO DE CICLOS DE PRODUÇÃO DE JOGOS

Autor Schuytema
Novak (2017) Chandler (2012)
Característica (2008)
Fases 8 4 4
Perspectiva Indústria de jogos produtor designers
ideia do jogo,
público, recursos,
Conceito objetivo, finalidade Não tem Não tem
do jogo, e condições
de vitória
conceito, requisitos
plano de ilustração,
do jogo (de
plano do projeto, conceito do jogo,
arte, design e
documento de brainstorming,
Pré-produção engenharia),
design do jogo, documento de
planejamento do
documento técnico design
projeto, e avaliação
de design
de risco
telas que capturam
a essência do
Protótipo jogo para teste da Não tem Não tem
mecânica do jogo e
sua diversão
implementação
construção
do plano,
do jogo, e
Produção Desenvolvimento rastreamento do
programação do
projeto, e avaliação
código-fonte
de risco
teste do jogo do
Alfa
começo ao fim
correção de defeitos
encontrados e validação do plano
Beta conclusão do e Não tem
desenvolvimento liberação do código
do jogo
fabricação da mídia
Ouro
física
lançamento de
aprendizado com a inclusão de
novas versões com
experiência, e recursos, e
Pós-produção correções ou
plano avaliação da
conteúdos
de arquivamento receptividade
adicionais
FONTE: Adaptado de Rocha e Araújo (2013)
87
DICAS
Que conhecer mais profundamente todas as fases de um ciclo de produção?

Assista este vídeo: https://www.youtube.com/watch?v=Kv48Nezf5O0.
88
RESUMO DO TÓPICO 1
• Um projeto é um esforço único, que é realizado em um determinado prazo a

fim de se atingir um objetivo.
• Ao se gerenciar um projeto, é fundamental que os artefatos (recursos,

riscos, escopo, custos, comunicação, prazos e compras) sejam planejados,
mensurados e controlados.
• O Personal Software Process (Processo de Software Pessoal – PSP) auxilia não

somente engenheiros de software, mas pode ser aplicado em projetos pessoais
e da organização.
• A metodologia Scrum pode ser utilizada como uma metodologia para

desenvolvimento ou como um gerenciador de projetos, sendo uma das
metodologias mais utilizadas atualmente para o desenvolvimento de recursos
tecnológicos.
• O PMBOK é um guia de conhecimento para gerenciamento de projetos, o qual

compreende dez áreas de gerenciamento, sendo assim, o projeto é controlado
e planejado do início ao fim, por meio de processo.
• Os ciclos de produção de jogos podem variar conforme a literatura, porém, a

maioria contém no mínimo três fases, sendo elas a pré-produção, produção e
pós-produção.
89
AUTOATIVIDADE
1 A definição de projeto possui algumas características de como um projeto

é executado, e que difere um projeto de um processo. Sobre a definição do
termo projeto, assinale a alternativa CORRETA:
a) ( ) É uma ação única, infinita e cíclica.

b) ( ) É uma ação única, temporária e progressiva com o intuito de se atingir
um objetivo.
c) ( ) É uma ação recorrente, temporária e interativa.
d) ( ) É uma ação única, com prazo final definido, cíclica.
2 O Processo Pessoal de Software (PSP) pode ser definido como um processo

de automelhoria, o qual busca auxiliar o engenheiro de software, porém o
PSP pode ser utilizados por outros profissionais. Sobre os objetivos do PSP,
assinale a alternativa CORRETA:
a) ( ) Ajudar somente os engenheiros de software a serem melhores, utilizar

no gerenciamento de projetos profissionais e pessoais, melhorar a
produtividade.
b) ( ) Ajudar os engenheiros de software e demais integrantes da equipe
a serem melhores, utilizar somente no gerenciamento de projetos
profissionais, melhorar a qualidade.
c) ( ) Ajudar os integrantes da equipe a serem melhores, utilizar no
gerenciamento de projetos profissionais e pessoais, reduzir os
resultados.
d) ( ) Ajudar os engenheiros de software e demais integrantes da equipe a
serem melhores, utilizar no gerenciamento de projetos profissionais e
pessoais, melhorar a produtividade.
3 A metodologia ágil Scrum é uma das mais utilizadas atualmente no

desenvolvimento de recursos tecnológicos, seja como uma metodologia de
desenvolvimento de software ou como um gerenciamento de projetos. Sobre
as características que fazem o Scrum uma das opções mais utilizas, assinale
a alternativa CORRETA:
a) ( ) Metodologia burocrática, como acompanhamento difícil e complexo.

b) ( ) Metodologia burocrática, comunicação clara, relatórios visuais e
informais.
c) ( ) Metodologia menos burocrática, comunicação clara, relatórios visuais
e informais.
d) ( ) Metodologia menos burocrática, equipe desintegrada e dividida,
relatórios visuais.
90
4 O ciclo de produção de jogos varia conforme a literatura, alguns possuem
mais fases que outros, já uns tem fase que são subfases em outros ciclos, não
existe apenas uma opção de escolha e novos ciclos podem ser desenvolvidos
ao longo do tempo. Disserte sobre as três fases (pré-produção, produção e
pós-produção) presentes em todos os ciclos apresentado.
5 No Scrum, existem três papéis essenciais, o Product Owner, Scrum Master e

a Equipe Scrum. Todos os papéis se relacionam e participam da execução
do Scrum. Neste contexto, disserte sobre as responsabilidades de cada um
desses papéis.
91
92
UNIDADE 2
TÓPICO 2 —
FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
1 INTRODUÇÃO
Olá, acadêmico! Seja bem-vindo ao Tópico 2! No decorrer deste tópico
iremos abordar sobre as fases de Produção de Jogos. A Figura 12 demonstra as
duas fases que iremos conhecer neste tópico, sendo as fases de Pré-produção
e Produção. Lembrando que esse ciclo é composto por quatro fases, conforme
estabelece Schuytema (2008).
FIGURA 12 – FASES DE DESENVOLVIMENTO DE JOGOS
FONTE: A autora
Ao longo deste tópico, abordaremos na fase de Pré-produção sobre a

definição do conceito de jogo, os requisitos, como é realizado um planejamento
de jogo e o GDD. Já na fase de Produção, conheceremos sobre a implementação
do plano, o rastreamento do progresso de desenvolvimento, a criação de builds
e a conclusão de tarefas. Essas duas fases contém um item similar à Lista de
verificações, que tem como função identificar se tudo o que foi idealizado naquela
fase foi concluído. Bom, como você pode perceber, temos muitos assuntos a tratar.
Que você tenha uma excelente jornada de estudos!
93
2 PRÉ-PRODUÇÃO
A primeira fase do ciclo de produção que é a fase de pré-produção, nela
são definidos o que iremos criar, quem será o público-alvo do jogo, “(...) significa
a decisão de qual tipo de jogo que será produzido, teste de algumas ideias geradas
e levantamento dos custos de produção, tempo e equipe. É normalmente uma
etapa que demanda um certo tempo” (CREDIDIO, 2007, p. 19).
A fase de pré-produção deve durar até que todos os conceitos e informações

sobre o desenvolvimento do jogo sejam bem definidos, não deixando margem
para dúvidas posteriores, logo essa fase pode ser uma das mais longas que deverá
ser realizada, mas lembre-se ela é a base para o que será desenvolvidos nas fases
seguintes, por isso deve ser realizada com cuidado e atenção. Chandler (2012),
afirma que “um projeto que não define um plano na pré-produção costuma
encontrar vários problemas que poderiam ter sido evitados ou resolvidos
antecipadamente”.
O principal objetivo desta fase “é essencialmente a criação do planejamento

do jogo, que é um roteiro para a conclusão deste e a liberação do código”
(CHANDLER, 2012). Estima-se que essa fase corresponda de 10 a 25% do tempo
total de desenvolvimento do jogo, além de poder durar entre uma semana até
um ano para sua completa realização (PEREIRA; LOPES, s. d.). Como podemos
identificar nesta fase são definidos os conceitos norteadores e essenciais para o
desenvolvimento do jogo, os quais iremos conhecer a seguir.
2.1 DEFINIÇÃO DO CONCEITO

O conceito de jogo busca procurar uma solução para um problema, o qual
deve começar com uma pergunta, a qual apresenta um problema a ser resolvido.
Nesse caso o jogo tem como objetivo resolver esse problema (CHANDLER, 2012).
“Desenvolver um conceito para um jogo é como fazer um esboço. Uma ideia é
tirada de algum estado precoce em algo mais elaborado. Mediante esse processo,
os detalhes são trabalhados e o conceito são trabalhados e o conceito se torna
mais ‘real’” (RABIN, 2012, p. 119).
Chandler (2012) afirma que “muitos conceitos inicialmente são vagos

e a equipe primária de desenvolvimento deve destrinchá-los para que todos
entendam facilmente quais são os objetivos do produto e quais devem ser os
principais elementos de jogabilidade necessários ao seu suporte e fortalecimento”.
A definição do conceito do jogo não é uma atividade simples, uma vez que
ideias consideradas originais e que venham ser identificadas como inovadoras,
acabam sendo abandonadas por não ser possível criar aplicações com as mecânicas
de jogo. Por isso o processo de definição de conceito deve ser realizado com muita
atenção e cuidado (SATO, 2010).
94
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
NTE
INTERESSA
Definir o conceito do jogo nem sempre é um processo fácil. Este vídeo trata
de como se definir o conceito do jogo: https://www.youtube.com/watch?v=8rw40khX0Es.
2.1.1 Início do processo

O início do processo da pré-produção acontece após a definição do
conceito do jogo, onde a equipe deve responder duas perguntas:
1°. O que vai ser feito?

2°. Para quem vai ser feito?
A primeira pergunta busca identificar sobre qual o gênero será o jogo

e quais os elementos de narrativa serão utilizados. A segunda pergunta busca
identificar o público-alvo do jogo que será desenvolvido (CHANDLER, 2012).
Além de responder essas perguntas, é comum serem criados protótipos

do jogo, mas nada de muitos detalhes e recursos tecnológicos para criá-los. O
ideal é ser realizado manualmente, utilizado papéis ou lousas. Outra opção que
podemos utilizar é identificar jogos similares e avaliá-los para ver o que vem
sendo desenvolvido e jogado pelo público-alvo.
2.1.2 Brainstorm
O brainstorm ou tempestade de ideias, como é conhecido na língua
portuguesa é uma técnica para gerar ideias, no desenvolvimento de jogos
o brainstorm é realizado para escolher a melhor ideia do jogo. Marques (2015)
ressalta que o brainstorm,
(...) funciona como uma tempestade de ideia é o momento do qual a

equipe de game designers se reúne para uma sessão de ideias, da qual
os participantes discutem uma série de aspectos como, conceito do
jogo, roteiro, guia de estilo, mecânicas, softwares a serem utilizado,
questões técnicas, entre outros, todos os participantes são convidados
a expor suas ideias, cada ideia é anotada e discutida entre todos, sendo
validada ou não.
É um momento de intensa criatividade, muito útil na produção do
conceito de um jogo ou para uma solução de problemas. Tendo como
objetivo que a equipe lidere sem restrições toda sua criatividade e
ideias (MARQUES, 2015, p. 28).
95
Nestas sessões, todos os integrantes da equipe devem compartilhar suas

ideias, mesmo quando consideradas ‘bobas’, pois podem ser discutidas e se
tornar uma excelente ideia de desenvolvimento. O que é necessário para que uma
sessão de brainstorm ocorra? A Figura 13 apresenta a estrutura necessária para
uma sessão.
FIGURA 13 – ESTRUTURA DE UMA SESSÃO DE BRAINSTORM
FONTE: <https://bit.ly/3vSxMvJ>. Acesso em: 27 jul. 2021.
Primeiro a equipe deve ser dividida, deve ser identificado um líder, os

membros e assistente, em segundo lugar a sessão deve ser realizada em uma
ambiente tranquilo e que o barulho de conversas não atrapalhe outras pessoas fora
da sessão, nesta sessão um roteiro será seguido, inicialmente todos compartilham
suas ideias, as quais são TODAS anotadas, em um segundo momento cada uma
das ideias apresentadas anteriormente são discutidas, observando se a mesma será
validada ou rejeitada, a última parte é a realização de filtro buscando identificar
a melhor das ideias, função essa realizada pelo líder.
NTE
INTERESSA
Neste manual criativo e ilustrado de brainstorm, você poderá aprofundar

os estudos sobre esta técnica de criação de ideias. Acesse o link: https://bdm.unb.br/
bitstream/10483/9843/2/2014_JulianaRaposoCiarlini_Manual.pdf.
2.1.3 Conceito inicial

O conceito inicial do jogo pode ser identificado por uma sessão de
Brainstorm, como aponta Chandler (2012) “você pode fazer uma brainstorm
sobre o conceito inicial do jogo, a jogabilidade básica, o ambiente do jogo ou a
aparência dos personagens. Sessões de brainstorm bem gerenciadas também são
um ótimo exercício de construção de equipes porque permitem que todos deem
suas opiniões”.
96
O conceito inicial pode ser realizado em um documento ao qual deve conter

uma visão geral que explica os princípios mais importantes do jogo e alguns de
seus recursos principais (SCHUYTEMA, 2008). Pra a criação do conceito inicial
é utilizada um high concept, ou seja, uma sentença simples que tem como objetivo
descrever a essência do jogo (LEMES, 2009).
2.1.4 Gênero
Como vimos em nossa primeira unidade, existem vários gêneros de
jogos. Ao se decidir qual será o gênero do nosso jogo é essencial antes de dar
seguimento ao desenvolvimento, uma vez que, dependendo do tipo de jogo,
pode implicar que algumas fases de desenvolvimento sejam alteradas. Logo, esse
é um dos primeiros passos a serem definidos após a definição do conceito do jogo
(CAVACO, 2007).
É importante lembrar que aos se definir o gênero do jogo é uma maneira

dele ser categorizado, assim a equipe pode melhor visualizar com maior
facilidade a mecânica do jogo, vale ressaltar que a escolha do gênero afeta todo o
desenvolvimento do jogo (RIBEIRO, 2016).
2.1.5 Plataforma
A escolha da plataforma é a definição de em qual plataforma nosso jogo
irá ser executado, Ribeiro (2006), aponta que a plataforma
(...) é o hardware utilizado para rodar o jogo. Pode se tratar de um

console específico para jogos, um computador, notebook, tablet,
smartphone ou um sistema imersivo. Muitas vezes, os jogos digitais são
desenvolvidos para mais de uma plataforma (RIBEIRO, 2016, p. 56).
É comum que os jogos atualmente desenvolvidos temam uma abordagem

multiplataforma, assim, ele pode ser jogado por um maior público. Com isso, os
jogadores podem escolher em qual plataforma jogar. É claro que a escolha da
plataforma implicará que o design do jogo possa sofrer modificações, uma vez que
as plataformas possuem diferenças entre si, assim, podem ter algumas limitações
e oportunidades (CHANDLER, 2012).
2.1.6 Análise SWOT

A análise SWOT pode auxiliar no processo de definição do conceito do
jogo (CHANDLER, 2012), porém a análise SWOT é muito utilizada na área de
Marketing e Administração, mas pode ser utilizada para a concepção do jogo. A
Figura 14 demonstra a estrutura do SWOT.
97
FIGURA 14 – ESTRUTURA DA SWOT
FONTE: <https://rockcontent.com/br/wp-content/uploads/sites/2/2021/02/swot-1.png>. Acesso

em: 27 jul. 2021.
SWOT é a sigla para Strenghts, Weaknesses, Opportunities e Threats,

ou seja, Forças, Fraquezas, Oportunidades e Ameaças, sendo conhecida em
português através da sigla FOFA, é uma ferramenta relativamente simples, mas
capaz de identificar os pontos fortes e fracos do conceito do jogo, assim como
suas oportunidades de mercado e possíveis ameaças ao projeto (RIBEIRO,
2016). A análise SWOT é realizada ao comparar jogos concorrentes com a ideia
que está sendo desenvolvida, buscando assim identificar as características
de cada um, “identificadas essas características, deve ser definido como as
forças e oportunidades serão exploradas e como as ameaças e fraquezas serão
neutralizadas, de modo a integrar essas ações ao projeto (RIBEIRO, 2016).
2.1.7 Declaração da missão

A declaração da missão estimula a equipe ao se desenvolver o jogo.
Através da declaração é definido o que será feito e para quem será feito. Chandler
(2012) define a declaração da missão
Para resumir, usarei um termo de que todos se lembrarão – a

declaração de missão é a “conversa de elevador” da equipe. A equipe
inteira deve ser envolvida na definição e modelagem da declaração de
missão, assim todos terão contribuído com uma parte do projeto. Essa
sensação de posse é imperativa para a construção de uma equipe forte.
Lembre-se de que a declaração de missão não precisa declarar “como”
essas coisas serão feitas, já que o “como” será resolvido quando o
planejamento do projeto for elaborado (CHANDLER, 2012, p. 6).
Com isso, podemos definir que ao se realizar uma declaração de missão,

estamos definindo qual o jogo será desenvolvido e para qual público-alvo ele será
pensado e criado.
98
2.1.8 Cenário do jogo

O cenário do jogo é onde a história do jogo será apresentada, Novak
(2017), afirma que o cenário:
(...) ou contexto representa o mundo que está sendo explorado pelo

público, pelos personagens ou pelo jogador. Ao criar uma história
para um game, pense no mundo em que seus personagens deverão
viver e interagir. Não se limite a estereótipos. Será um local do mundo
real (por exemplo, o deserto do Saara ou a tundra do Alasca) ou um
período de tempo específico (por exemplo, a era vitoriana ou a década
de 1920)? (NOVAK, 2017, p. 133).
O cenário pode ser fixo, onde apenas os personagens e elemento são

animados ou dinâmicos quando o cenário se movimenta conforme os comandos
ou movimentos do jogador (COPLE, 2019). Velasquez (2009) define o cenário
como:
(...) o espaço onde se desenrola o jogo. Pode ser mais do que um e se

for tridimensional deve permitir o seu percurso em vários sentidos.
É o modelo de interacção, a maneira como o jogador interage com
esse espaço/mundo (1ª ou 3ª pessoa). Finalmente o mundo do jogo
(VELASQUEZ, 2009, p. 39).
Uma boa prática para elaboração dos cenários do jogo é através

da prototipação, onde a equipe pode criar rascunhos em papel mesmo ou
utilizando um software de criação de protótipos para que todos tenham uma ideia
compartilhada dos cenários que serão criados para o jogo. Outra alternativa é a
criação de Storyboards de como será o jogo, suas fases ou níveis.
NOTA
“O storyboard é uma sequência de desenhos quadro a quadro com o esboço

das cenas pensadas para um conteúdo em vídeo, como: filmes e animações” (COFFEE,
2018, s. p.).
2.1.9 Mecânica do jogo

A mecânica do jogo envolve como o jogador vivência o jogo. Barcelos
(2013 apud Schell, 2011) destaca que os “(...) principais aspectos da mecânica
do jogo são: o espaço do jogo; os objetos do jogo (incluindo aí os personagens
não-jogadores), regras, possíveis ações dos jogadores e dos personagens não
jogadores, dentre outros”. Novak (2017) também defende que a mecânica tem
99
como objetivo oferecer a estrutura do jogo, através de objetivos, procedimentos e

regras. Segundo Novak (2017, p. 148), “(...) esses elementos que criam a ação e o
jogo propriamente dito”.
Os principais sistemas de mecânica na pré-produção são:
• os desafios mais recorrentes durante o decorrer do jogo;

• as recompensas para o jogador;
• a curva de aprendizagem, ou seja, a rapidez com que o jogador começa a ter
uma experiência de diversão, a partir do início do jogo;
• o esquema de controle;
• as ações do jogador, como correr, lançar, pular, entre outras ações;
• e os principais elementos de multijogador, se aplicável (CHANDLER, 2012;
SICART, 2008).
2.1.10 Sinopse da história

Na sinopse da história deve ser apresentado o enredo narrativo do jogo, o
qual deve conter o ambiente, a mecânica e os personagens do jogo, a fim de que
se tenha uma boa experiência do que irá ser desenvolvido.
Descreva a sinopse de sua história em um parágrafo. Não detalhe os

diferentes pontos do enredo; limite‑se à ideia principal. Concentre‑se
nos aspectos dela que podem ser únicos ou emocionalmente atraentes.
Inclua também uma discussão sobre como o modo de jogar refletirá
a história. O que o jogador fará no game? Que tipos de ambientes ou
cenários o jogador encontrará? (NOVAK, 2017, p. 371).
Na fase de pré-produção não é necessário que a sinopse da história do

jogo seja totalmente criada em detalhes (RIBEIRO, 2016), uma vez que no decorrer
do desenvolvimento do jogo poderá ser necessário modificar e alterar a sinopse,
com isso podemos criar uma sinopse básica e ao longo do desenvolvimento do
jogo incluindo mais detalhes.
2.2 REQUISITOS DO JOGO

Ao se elencar os requisitos do jogo, não são definidos somente as ações
que irá ocorrer quando o personagem andar de um lado para o outro. Chandler
(2012) destaca que os requisitos de jogo “incluem os recursos básicos de arte,
design e engenharia que devem ter suporte, qualquer restrição ao projeto e
a documentação básica técnica e de design. Todos os recursos devem estar de
acordo com o conceito estabelecido e a declaração da missão”.
100
Através dos requisitos do jogo são desenvolvidos documentos que

orientarão o desenvolvimento do jogo, além de ser definido as etapas que virão a
ser desenvolvidas e o que deverá ser entregue em cada uma das etapas (RIBEIRO,
2016). A seguir iremos conhecer os elementos que compõem os requisitos do jogo,
na figura 15 podemos observar as etapas que envolvem a descrição dos requisitos
do jogo.
FIGURA 15 – LISTA DE RECURSOS CATEGORIZADOS
FONTE: Adaptado de Chandler (2012)
2.2.1 Definição dos recursos do jogo

Ao se desenvolver jogos é comum que se queira utilizar as tecnologias
mais recentes, porém nem sempre os recursos escolhidos não são os que a equipe
gostaria de utilizar, por isso é fundamental consultar a equipe para escolher os
recursos que irão utilizar no desenvolvimento do jogo. Uma solução para escolher
os recursos que serão utilizados é a realização de uma sessão de brainstorm,
Chandler (2012) diz que na sessão de brainstorm temos que discutir sobre
(...) recursos multijogador, recursos de jogador único, a mecânica, o

som e qualquer aspecto do jogo. Reúna todas as opiniões sobre os
recursos em uma única lista e então categorize-as por tipo. Isso ajudará
o produtor e os líderes a priorizarem melhor os recursos. Algumas
categorias que devem ser consideradas são as seguintes:
101
Processo: Esses recursos estão ligados à melhoria do processo de

desenvolvimento. (...)
Produção: Esses recursos envolvem melhorias nas ferramentas e na
tecnologia usadas na criação do jogo. (...)
Jogabilidade: Esses recursos são compostos por elementos de
jogabilidade que afetarão diretamente a experiência do jogador e que
podem ser vistos por ele (CHANDLER, 2012, p. 238).
Uma estratégia é utilizar uma lista para com as categorias para assim
ter melhor controle sobre os tipos de recursos que serão escolhidos, a Figura 16
demonstra um exemplo de lista de recursos categorizados (CHANDLER, 2012).
FIGURA 16 – LISTA DE RECURSOS CATEGORIZADOS
Após a categorização dos recursos na lista, os líderes do projeto devem

atribuir prioridades para os itens arte, engenharia, design e teste. Cada recursos
deverá atribuir uma pontuação para os recursos, sendo 3 como prioridade alta e
1 para mais baixa. A Figura 17 apresenta uma planilha de pontuação de recursos
classificada por pontuação (CHANDLER, 2012).
102
FIGURA 17 – PLANILHA DE PONTUAÇÃO DE RECURSOS
2.2.2 Definição das etapas e produtos

A definição das etapas é realizada para que seja possível realizar o
rastreamento do progresso do desenvolvimento do jogo, assim, através das
etapas definidas os objetivos para cada uma das etapas são criados, com isso
o desenvolvimento se torna mais gerenciável, para equipe venha a alcançar no
prazo. As etapas auxiliam também a facilmente definir a lista dos produtos que
cada etapa deverá entregar (CHANDLER, 2012).
As etapas são categorizadas de maneira geral na seguinte ordem:
• Primeira versão jogável: é uma versão inicial do jogo, onde podem ser
observados a jogabilidade e os elementos, sendo desenvolvida conforme os
protótipos criados.
• Versão alfa: nessa versão do jogo pelo menos metade dos recursos gráficos e
de jogabilidade já foram implementados.
• Congelamento do código: após a conclusão do código do jogo, a equipe de
programação se concentra em rastrear e corrigir erros.
• Versão beta: e a versão do jogo 100% implementada, ou seja, os recursos e
elementos do jogo foram todos concluídos, e as equipes agora buscam corrigir
os erros relatados pela equipe de testes.
• Versão gold: depois de corrigido todos os erros o jogo é liberado para os testes
finais (CHANDLER, 2012; NOVAK, 2017, CRUZ, 2013).
103
2.2.3 Avaliação da tecnologia

Ao se definir os requisitos do jogo, deve-se avaliar quais serão as
necessidades de tecnologia no decorrer do desenvolvimento do jogo. Para isso,
pode-se consultar o líder da equipe de desenvolvimento ou realizar uma reunião
com toda equipe de programação para definir as tecnologias em conjunto,
lembrando que essa decisão implica sobre os mecanismos do jogo, na arte, nos
scripts e em sistemas de IA (inteligência artificial). Logo, é recomendável que
um dos integrantes da equipe passe algum tempo avaliando as tecnologias que
podem ser aplicadas no projeto, normalmente quem assume essa função é o
programador líder (CHANDLER, 2012).
2.2.4 Definição das ferramentas e pipeline

Além de definir as tecnologias que serão utilizadas no desenvolvimento
do jogo, a equipe, ou melhor, os líderes das equipes, devem definir o pipeline de
produção, que é, segundo Chandler (2012, p. 246), “é a série de etapas que são
necessárias para o código e os assets (elementos do jogo) funcionarem em uma
versão jogável. Ele deve incorporar sem problemas as ferramentas, os assets e as
necessidade de produção do jogo”. Deve-se considerar as respostas das seguintes
perguntas para a definição do pipeline, conforme apresenta o quadro:
QUADRO 3 – PERGUNTAS PARA A DEFINIÇÃO DO PIPELINE
Pergunta Descrição
As ferramentas de do software são necessárias para
Que ferramentas quando é preciso converter um formato de arquivo,
e softwares são já software de controle de código-fonte pode ser
necessários? utilizados para que seja inserido ou removido assets
na build (versão compilada do jogo).
Deve ser possível que os assets sejam convertidos

O pipeline dá suporte
para utilização no jogo, assim como serem
a funcionalidade
transformados na versão original, assim as alterações
bidirecional?
são realizadas mais rapidamente nos assets.
Todos devem ter um volume de trabalho

Qual é o caminho
proporcional, assim ninguém fica com um gargalo.
crucial? Há algum
Também deve ser limitado o número de etapas do
gargalo?
pipeline.
Quando o sistema
precisa estar O pipeline tem que estar operacional para que o
funcionando build jogável com os assets corretos seja criada.
plenamente?
104
É importante decidir com os softwares de controle de

Como os assets
código--fonte será utilizado, para que os assets atuais
são gerenciados
sejam trabalhados. Utilizando um controle de versões
e rastreados no
são uma boa solução para que várias versões do
sistema?
projeto não causem confusões do desenvolvimento.
Que áreas do
Ao automatizar os pipelines é possível reduzir tempo
sistema podem ser
e erros humanos.
automatizadas?
Após os líderes das equipes responderem estas perguntas, eles poderão

definir qual será o melhor pipeline para ser utilizado no decorrer do projeto do
jogo (CHANDLER, 2012).
2.2.5 Documentação
Conforme os itens que conhecemos anteriormente forem sendo
identificados, é fundamental que essas informações sejam documentadas. Na
documentação, além das informações já definidas anteriormente, deve conter
a documentação artística, de design e técnica. Vale ressaltar que estas três
documentações serão criadas por cada uma das equipes, que não seguem uma
estrutura igual para cada uma, assim, é normal que sejam criadas utilizadas
formatos diferentes. O mais importante é que a documentação seja de fácil leitura,
e que forneça informações claras sobre o desenvolvimento do jogo (CHANDLER,
2012).
Na documentação de design são reunidas as informações sobre os

recursos de interface do usuário, o enredo, os mapas, o ambiente multijogador (se
aplicável), o histórico dos personagens e seus diálogos, os sistemas de pontuação,
de controle e ações que o jogador irá realizar, assim como os objetos e a inteligência
artificial.
Já a documentação técnica deverá conter os assuntos que guiaram a

programação do jogo, a arquitetura de codificação, as interfaces de programação,
as definições de software e hardware, as tecnologias e os tipos de arquivos que
serão utilizados.
A documentação de arte deve conter as informações sobre os elementos

estéticos do jogo, o qual deve servir como um a guia de estivo, composto pela
descrição e exemplos da aparência dos cenários, objetos, personagens, além de
incluir a paleta de cores para cada uma das artes (CHANDLER, 2012; NOVAK,
2017, CRUZ, 2013).
105
Novak (2017) aborda que:
A documentação do game é criada durante as fases de conceito,

pré‑produção e produção para informar os membros da equipe e
parceiros em potencial (como a editora, o fabricante ou o licenciador)
sobre os componentes do projeto. A documentação atende a duas
finalidades: garantir que os membros da equipe compreendam suas
respectivas funções no processo de desenvolvimento e convencer
outras empresas a desenvolver, financiar a produção ou ajudar de
outras maneiras a transformar o game em realidade. Lembre‑se de
que as descrições e os elementos da documentação citados a seguir
são apenas para sua orientação. Ainda não existem normas estritas
de documentação no setor, embora os itens a seguir representem os
componentes essenciais necessários para proporcionar uma base
sólida (NOVAK, 2017, p. 363).
Com isso, podemos identificar que a documentação é construída ao longo

do desenvolvimento do jogo, o qual serve para guiar o que será desenvolvido,
assim como consultar os passos executados. A documentação é “(...) o primeiro
contato prático que os desenvolvedores têm com a ferramenta. Apenas este fato
já seria suficiente para ser levada em consideração, mas a documentação também
introduz os desenvolvedores às boas práticas, customização e comunidade”
(AFONSO, 2020, p. 71).
2.2.6 Análise de risco

Na análise de risco, busca-se avaliar e controlar os riscos, que possam
vir a ocorrer durante o desenvolvimento do jogo. É importante ressaltar que
a análise de risco deve ocorrer em todas as etapas de desenvolvimento, não se
limitando apenas a etapa de pré-produção. Os riscos são situações que podem
gerar algum erro e que implique na entrega do produto dentro do prazo
estabelecido (CHANDLER, 2012). Segundo Novak (2017), são riscos comuns no
desenvolvimento de projetos:
- Dificuldades de recrutamento de mão de obra.

- Atrasos na entrega de materiais (como os kits de desenvolvimento de
software dos
fabricantes de consoles).
- Dependência de fontes externas para componentes tecnológicos
cruciais.
- Desenvolvimentos tecnológicos competitivos.
- Tecnologias experimentais ou decisões de design que podem afetar o
cronograma.
- Normas de proteção dos ativos (NOVAK, 2017, p. 372).
Na avaliação de riscos devem ser procurados riscos que poderiam afetar

o projeto e considerar a possibilidade que eles ocorram e quais os impactos que
podem gerar. Uma vez conhecidos os riscos em potencial, é necessário controlá-
los. Para isso, é recomendável um plano de ação para eliminar riscos cruciais
(CHANDLER, 2012).

106
2.3 PLANEJAMENTO DO JOGO

O planejamento do jogo “é onde as informações são reunidas mostrando
como tudo será realizado” (CHANDLER, 2012). É no planejamento que são
definidas quais são as dependências, é criado um orçamento do que será gasto
no decorrer do projeto, um cronograma das atividades, produtos e entregas, e a
definição da equipe e seus cargos/funções (CHANDLER, 2012). O planejamento
é presente em todas as fases do desenvolvimento do jogo.
2.3.1 Dependências
As dependências estão em três relacionamentos fatores: cronograma,
funcionalidades e recursos. Esses três fatores implicam na qualidade do que iremos
desenvolver. A Figura 18 demonstra essa dependência entre cronograma, recursos
e funcionalidades. Por isso, é essencial que sejam realizados os planejamentos de
orçamento, do cronograma e de pessoal na fase de pré-produção.
FIGURA 18 – DEPENDÊNCIAS
FONTE: Chandler (2012, p. 258)
Um desses fatores implica no outro, o que pode resultar em que o

projeto tenha que sofrer alterações. Por isso, como Chandler (2012) ressalta
que é importante “ saber distribuir, no tempo alocado (cronograma), a equipe
e o orçamento disponíveis (recursos), o conjunto de funcionalidade do jogo
(funcionalidades) e a qualidade, como os elementos gráficos de última geração
(qualidade), é extremamente importante na elaboração do planejamento do jogo”.
2.3.2 Cronograma
O cronograma é uma lista de tarefas a serem realizadas, a estimativa de
tempo, o responsável por cada tarefa, e quais tarefas são dependentes de atividade
já existentes. A criação do cronograma é realizada na fase de pré-produção e se
estende, logo, o cronograma é construído e atualizado neste período, uma vez
107
que algumas atividades não são ainda conhecidas no primeiro momento, assim
ajustes podem vir ser realizados o que pode modificar a execução do projeto
(CHANDLER, 2012).
Um cronograma deve ser pensado a partir dos produtos que

cada etapa deve entregar e então, do detalhamento de cada tarefa
necessária para sua conclusão. Por fim, os profissionais disponíveis
devem ser alocados nessas tarefas, o que dará a noção da extensão do
projeto, a partir do desenvolvimento de seus recursos, bem como o
gerenciamento de revisão de etapas em casos de alteração de prazos
de entrega (RIBEIRO, 2016 apud CHANDLER, 2012).
Um cronograma inicial é criado e compartilhado com toda a equipe, para

que sejam planejadas as datas-chave (data de entrega). No cronograma, devem
ser listados os principais critérios de saída de cada área do jogo (produção,
arte, engenharia, áudio, localização, QA – Quality and Assurance – Qualidade e
Segurança / Testes de qualidade), fornecedores, marketing e aprovações), além de
no decorrer poderem ser inclusos mais critérios. Após a definição dos critérios
datas devem ser estimadas (CHANDLER, 2012), no Quadro 4 podemos observar
um exemplo de cronograma inicial conforme os critérios.
QUADRO 4 – EXEMPLO DE UM CRONOGRAMA INICIAL
Unidade de Justiça Data Estimada Notas

Idiomas: inglês, alemão, francês, italiano, espanhol
Produção
Fase conceitual concluída
Fase de requisitos concluída
Plano inicial do jogo concluído
Primeira versão jogável
Alfa
Congelamento do código
Beta
Envio para a Microsoft para pré-certificação
Código candidato à liberação
Envio para a Microsoft para certificação
Aprovações
Aprovação do conceito
Aprovação dos requisitos
Aprovação do plano do jogo
Aprovação de licenças
Aprovação do fabricante do console
Design
Produtos concluídos para a fase conceitual
Produtos concluídos para a fase de requisitos
108
Documentação detalhada dos recursos do jogo

Documentos de personagens e da história

concluídos
Roteiros de voiceover concluídos
Missão e cenários projetados
Protótipos de missão roteirizados
Playtest
Missões finais roteirizadas
Arte
Protótipos concluídos
Nível da primeira versão jogável concluído
Efeitos especiais concluídos
IU concluída
Cinemática concluída
Engenharia
Ferramentas de arte e design concluídas
Pipeline de produção concluído
Protótipos de engenharia concluídos
Todos os principais recursos da jogabilidade

implementados
Congelamento do código
Áudio
Designs de som concluídos
Protótipos de som concluídos
VO provisório gravado
VO final gravado
Música final implementada no jogo
Localização
Determinação das necessidades de localização
Organização de recursos para tradução
Integração dos recursos
Teste de funcionalidade
Teste linguístico
QA
Plano de testes concluído
Teste da primeira versão jogável concluído
Teste da versão alfa concluído
109
Playtest concluído
Primeiro código candidato à liberação enviado

para a QA
Liberação do código
Cinemática (fornecedor externo)
Entrega das especificações iniciais para o

fornecedor
Storyboard do fornecedor
Animática do fornecedor
Corte bruto do fornecedor
Filme final do fornecedor (sem som)
Filme enviado para o designer de som
Filme final pronto para o jogo
Marketing
Build de demonstração
Build para E3
Preview code para jornalistas
Review code para jornalistas
No cronograma inicial, como o exemplo apresentado no Quadro 4, devem

ser listadas todas as tarefas de cada uma das equipes. Normalmente, a definição
do cronograma inicial é feita pelo produtor, com a participação das equipes para
criar um cronograma possível de ser cumprido. Além de listar todas as atividades
que cada equipe deverá cumprir, uma data estimada de conclusão deve ser
definida de comum acordo entre todas as equipes, e as notas podem auxiliar
a identificar o que pode ser realizado primeiro, qual atividade possui alguma
dependência, entre outras informações que serão uteis para o projeto.
Para o cronograma, é comum que se utilize um software para a sua criação,

acompanhamento e compartilhamento com a equipe. Atualmente, contamos
com várias opções on-line e aplicativos para compartilhar nosso cronograma de
atividade. O cronograma inicial oferece uma boa ideia do que irá ser desenvolvido,
porém, é recomendável que um cronograma mais detalhado seja criado conforme
as informações irem sendo confirmadas. Este cronograma detalhado contará com
subtarefas para as tarefas básicas listadas no cronograma inicial, assim como um
aperfeiçoamento da lista de tarefas (CHANDLER, 2012).
110
DICAS
Nestes links você poderá conhecer softwares on-line para criar o cronograma:
• Trello: https://trello.com/
• Evernote: https://play.google.com/store/apps/details?id=com.evernote
• Todoist: https://play.google.com/store/apps/details?id=com.todoist
2.3.3 Orçamento
O orçamento é criado através do cálculo dos custos que estejam associados
aos projetos, os quais incluem:
• Profissionais (arte, design, engenharia, produção, QA, áudio).

• Equipamentos (hardware).
• Softwares (taxas de licenciamento).
• Outros custos (fornecedores, alimentação, materiais de escritório, expedição
etc.).
• Custos indiretos (aluguel, seguro, serviços públicos etc.).
Através dos cálculos dessas despesas é determinado o quanto será gasto

no projeto. Uma vez que o orçamento é definido através dos requisitos desejados
para o jogo e do que foi definido no cronograma, assim, o orçamento deve estar
em conformidade com o escopo e a qualidade do jogo que se deseja desenvolver
(CHANDLER, 2012).
2.3.4 Equipe
A equipe de desenvolvimento é composta por vários profissionais,
envolvendo várias áreas, logo é uma equipe de desenvolvimento de jogos é
multidisciplinar (NEMITZ NETO, 2015). Em pequenos projetos é comum que
um profissional exerça mais de uma função no desenvolvimento do jogo, já em
grandes projetos é comum que seja construída uma grande equipe, em que cada
profissional é responsável apenas por sua função específica. Chandler (2012) diz
que a equipe de desenvolvimento é composta por profissionais de Arte, Design,
Engenharia, Produção e QA. O Quadro 5 apresenta os profissionais de cada uma
dessas equipes.
111
QUADRO 5 – EQUIPES DE DESENVOLVIMENTO
Equipe Profissional Descrição

Supervisiona a equipe de arte, responsável por controlar os
Diretor de prazos, o desenvolvimento, orçamentos e as contratações
arte para a equipe, além de determinar o estilo de arte do jogo,
sua atmosfera e aparência em geral.
Supervisiona a equipe de arte, além de participar do
Artista líder
processo de produção da arte do jogo.
Artista Cria os desenhos e esboços do ambiente, objetos e os
conceitual personagens do jogo.
Profissionais de Arte
Construtor de
Constrói a geometria e as texturas do mundo do jogo.
mundos
Criação dos assets (personagens, acessórios, telas de
Criador de
interface de usuário, veículos, e qualquer outro assets
assets
necessário) que aparecem no jogo.
Aplica os movimentos aos personagens e objetos presentes
Animador
no mundo do jogo.
Gerenciam o lado técnico da criação de assets, como
Artista
garantia que os objetos sejam exportados, aplicação de
técnico
atributos físicos a objetos, criação de volumes de colisão.
Criam os recursos (captura de tela, filmar a mecânica
Artista de
do jogo, criar a embalagem, entre outros recursos) de
marketing
marketing do jogo.
Diretor de Garante a consistência do estilo geral e do conteúdo do
Profissionais de Design
criação jogo.
Supervisiona a equipe de design, e atua no
Designer líder
desenvolvimento do processo cotidiano de design.
É responsável por criar, simular, implementar e balancear
Designer
diferentes áreas do jogo.
Cria os elementos da história, os personagens e diálogos do
Redator
jogo.
Cria o desenho técnico do projeto, supervisiona sua
Diretor
implementação, escolhe as ferramentas, hardwares e define
técnico
padrões de programação.
Profissionais de Engenharia
Programador Supervisiona a equipe de engenharia e também participado

líder do desenvolvimento da programação do jogo.
Programador
Específica os componentes multijogador de jogos on-line.
de rede
Programador
Implementa os sons e músicas no jogo.
de som
Programador Projeta ferramentas que ajudam as equipes de arte e design
de a transformar o código de programação para ser incluído
ferramentas no jogo.
Programador Cria os comportamentos que a percepção de
de IA comportamento inteligente.
112
Produtor Gerencia a produção, da proposta e do protótipo, além de

Profissionais de Profissionais de executivo oferecer apoio ao projeto.
Produção Produtor Responsável pelo cumprimento das metas do projeto.
Produtor É subordinado ao produtor, interage com a equipe e
associado também auxilia os líderes das equipes quando necessário.
Analista líder Testar o jogo, fechar os bugs (erros) e determinar se o jogo
de QA está pronto para ter o código liberado.
QA
Verifica a funcionalidade do jogo com relação ao plano de

Testador de
testes, testa novos recursos e protótipos em busca de bugs
QA
(erros).
FONTE: Adaptado de Chandler (2012) e Novak (2017).
É possível que nem sempre os projetos tenham todos esses profissionais,

conforme apresentados no Quadro 5. Em alguns casos, um mesmo profissional
atua em mais de uma equipe, isso ocorre principalmente em projetos pequenos,
mas não significa que grandes projetos irão contar com todos os profissionais,
a definição dos profissionais normalmente é realizada pelo produtor, porém
a participação de todos esses profissionais no projeto também depende do
orçamento alocado para o projeto, com isso esse quadro de profissionais presentes
no desenvolvimento de jogos não é uma regra, ou seja, todo projeto é diferente
e pode conter profissionais com mais funções além de sua principal atribuição.
2.4 GDD
O GDD é o Game Design Document ou Documento de Projeto do Jogo em
português. No entanto, também é encontrado na literatura, como Documento de
Design do Jogo, Documento de Definição do Jogo ou Documento de Game Desing.
Este documento é a espinha dorsal de qualquer projeto de desenvolvimento de
jogos, através dele são definidos os pontos do jogo, além de guiar as equipes na
produção do jogo (LEMES, 2009). Baldwin (2005) define o GDD como um “(...)
mapa do qual o jogo será criado. Como tal, todos os detalhes necessários para a
construção do jogo têm de estar mencionados no documento. Se não estiver no
documento, então provavelmente não estará no jogo”.
O documento de design do jogo ou Game Design Document (GDD) é o

documento que apresenta detalhadamente todas as características de
um jogo, como histórias, conceitos, personagens, cenários, mecânicas
e sons, por exemplo. Este documento serve de referência para todos os
envolvidos entenderem e estarem a par do desenvolvimento do jogo
(HIRA et al. 2016, p. 329).
Com isso, todos os itens que conhecemos anteriormente devem estar

presente no documento, além de outro como veremos a seguir. Fleury et al.
(2014) definem o GDD como um documento “(...) altamente descritivo, textual
113
e visualmente, dentro do qual se mostra a concepção do jogo, os conceitos

presentes, a arte envolvida, a programação sugerida e requerida, a história e seus
marcos conceituais e de interação etc. Além de disso, o GDD “(...) irá acompanhar
e orientar toda a produção do jogo, garantido sua identidade conceitual, visual,
sonora etc.”. É importante ressaltar que não existe uma metodologia única de GDD,
existem várias metodologias, cabendo a equipe escolher qual seguirá (FLEURY,
et al. 2014). Segundo Schuytema (2008), o GDD deve possuir os seguintes itens:
1. Visão geral: qualquer pessoa se familiarize com o jogo. Deve conter o resumo
da história, aspectos relativos ao gameplay e os diferenciais do jogo.
a. Resumo: é uma síntese da história de forma de que a equipe tenha uma ideia
do que será desenvolvido, deve ser um enxuto e eficiente.
b. Aspectos fundamentais: descrição dos principais elementos de gameplay
indicando sua trama central.
c. Golden nuggets: são elementos e funcionalidade que fazem com que o jogo se
diferencie dos demais.
2. Contexto do jogo: descrição do jogo com relação à história que se deseja

contar, sem considerar a jogabilidade. Assim deve-se descrever a trajetória
do início ao fim do jogo, comentando o que acontece ao longo das fases, os
conflitos, inimigos etc.
a. História do jogo: descrição em detalhes de todo a história do jogo.
b. Eventos anteriores: apresentação de eventos anteriores a história do jogo (se
aplicável).
c. Principais jogadores: descrição dos principais personagens controlados pelos
jogadores, contendo suas características físicas e psicológicas, além de sua
biografia, habilidades e motivações.
3. Objetos essenciais do jogo: descrição de todos os objetos relevantes no jogo

ou os quais desempenham papel importante.
a. Personagens: deve-se listar todos os participantes, os quais devem conter
as todas as características físicas e características psicológicas com a
personalidade.
b. Armas: (se aplicável) devem ser informada os detalhes, se é estático ou
apresenta alguma animação, se apresenta efeitos, todos os detalhes devem
ser descritos.
c. Estruturas: consiste nos objetos ou construções utilizadas no mundo do jogo.
d. Objetos: devem ser descritos os objetos que desempenham um papel
importante no mundo do jogo.
4. Conflitos e Soluções: devem ser descritas todas as situações de conflito do

personagem com seus inimigos, além de apresentar como o personagem irá
interagir com os outros, ou seja, suas ações e reações no mundo do jogo.
5. Inteligência artificial: devem ser descritos os comportamentos das ações dos
oponentes do jogo.
6. Fluxo do jogo: as fases, missões ou campanhas nas quais o jogador irá passar
no decorrer do jogo devem ser descritas. Além de informar novas habilidades
e armas que apareceram a cada fase avançada do jogo.
114
7. Controles: devem ser descritos os botões, teclas ou outros elementos

responsáveis em realizar as ações do jogador.
8. Variações de jogo: informar se ações do jogador no modo único jogador e no
modo vários jogadores.
9. Definições: trazer uma relação das palavras e expressões que serão utilizadas
no jogo, um glossário pode ser criado para melhor entendimento.
10. Referências: apresenta jogos similares, filmes, músicas, quadrinhos, animações
que serviram de referência para o jogo que está sendo desenvolvido (SENAC,
2019c).
Além dos itens apresentados, existem vários documentos que podem

ser utilizados para se criar o GDD. Nos quadros a seguir iremos conhecer uma
estrutura básica de um GDD. No quadro 6 temos a identificação do Documento,
onde devem ser apresentados o título e subtítulo (se aplicável) do jogo. Em
seguida, um sumário deve ser criado para melhor localização das seções do
documento.
QUADRO 6 – ESTRUTURA BÁSICA DE UM GDD - IDENTIFICAÇÃO
Título do Jogo
Subtítulo do jogo
Sumário
FONTE: Adaptado de Azevedo (2009)
O quadro 7 apresenta a seção 1 do Documento de Game Design, onde

deverão ser descritas as versões e as mudanças que ocorreram em cada versão.
Uma opção é que essas mudanças sejam apresentadas em uma tabela, a qual deve
conter o número da versão, o que foi mudado e a data que ocorreu.
QUADRO 7 – ESTRUTURA BÁSICA DE UM DE UM GDD – HISTÓRICO
1- Histórico do Projeto
Escreva uma breve descrição das versões e mudanças ocorridas durante o
projeto desde o início.
115
No Quadro 8, são apresentadas as informações do Resumo do Projeto, no

qual devem ser descritos: o conceito do jogo, as características, o gênero, qual será
o público-alvo, um resumo do fluxo do jogo, como será a visão pela perspectiva
do jogador e o escopo do jogo, ou seja, a quantidade de níveis, cenários, objetos
entre elementos que estão presentes no jogo.

QUADRO 8 – ESTRUTURA BÁSICA DE UM DE UM GDD - RESUMO
2 - Resumo do Projeto
2.1 – Conceito do Jogo

Descreva um resumo do principal conceito do jogo (Ex.: O jogo baseia-se em...).
2.2 – Conjunto de características
Descreva um resumo das plataformas adotadas, número de níveis, tipos de
jogabilidade (Ex. Modo Arcade, Estória etc.), modos de visualização (Ex. 2D,
3D, Sonoro etc), características de cores (Ex. 16 bits, 32 bits etc), Física (Ex.
Básica, intermediária, Avançada).
2.3 – Gênero
Descreva um resumo do gênero do jogo (Ex. RPG, FPS, RTS, Aventura, Ação,
Simulação etc).
2.4 – Público-alvo
Descreva qual o público que você quer atingir (Ex. Jovens entre 12 e 17 anos,
Adultos do
sexo feminino etc.).
2.5 – Resumo do Fluxo do Jogo
Descreva resumidamente o processo do jogo como um todo, se perguntando:
Como o jogador se move pelo jogo? Como ele pega os itens? Como ele ganha
vida / energia? etc.
2.6 – Olhar e Sentir
Descreva qual será a visão do Jogador, os momentos em que a visão muda e o
estilo visual do jogo.
2.7 – Escopo do Projeto
Descreva um resumo do escopo do jogo:
2.7.1 – Número de cenários;
2.7.2 – Número de níveis;
2.7.3 – Número de NPCs;
2.7.4 – Número de armas;
2.7.5 – Etc.
Em seguida, devem ser descritos os elementos de jogabilidade e mecânica

(Quadro 9) que são utilizados, através de uma descrição detalhada da progressão
do jogo, a estrutura das fases, os objetivos do jogo, o fluxo de como o jogar irá
acontecer, as regras, como a física irá afetar o desenvolvimento, as ações dos
personagens, além da criação do fluxo de telas que tem como objetivo mostrar
como o jogo irá ser jogado.
116
QUADRO 9 – ESTRUTURA BÁSICA DE UM DE UM GDD – JOGABILIDADE E MECÂNICA

3 – Jogabilidade e Mecânica
3.1 – Jogabilidade
3.1.1 – Progressão do Jogo
3.1.2 – Estrutura das Missões / Desafios
3.1.3 – Estruturas dos Quebra-cabeças
3.1.4 – Objetivos
Descreva os objetivos do jogo
3.1.5 – Fluxo do Jogo
Descreva como o jogo flui para o jogador.
3.2 – Mecânicas
Descreva as regras do jogo (implícitas e explicitas). Este é o modelo do universo
no qual o jogo funciona. Pense em simulação do mundo do jogo e como todos
os pedaços interagem entre si. Geralmente este é a parte mais longa desta seção.
Esta seção é refere-se ao(s) personagem(ns) do jogo e seu universo.
3.2.1 – Física do jogo
Descreva como a física afeta o universo e os objetos no jogo.
3.2.2 – Movimentos
3.2.2.1 – Movimentos Gerais
3.2.2.2 – Movimentos específicos
3.2.2.3 – Outros movimentos
3.2.3 – Objetos
3.2.3.1 – Pegando objetos
3.2.3.2 – Movendo objetos
3.2.3.3 – Descartando objetos
3.2.3.4 – Modificando objetos
3.2.4 – Ações
3.2.4.1 – Interruptores, alavancas e botões
3.2.4.2 – Pegando, Carregando e Soltando
3.2.4.3 – Falando e Conversando
3.2.4.4 – Lendo e Pensando
3.2.5 – Combates
Descreva como são os combates ou eventuais conflitos. Modele especificamente
o fluxo
do início ao fim.
3.2.6 – Economia
Descreva qual a economia do jogo e como ela funciona.
3.2.7 – Planilha de Fluxo de Telas
Descreva graficamente como uma tela se relaciona com as demais.
3.2.8 – Descrição de Telas
Descreva a proposta de cada tela.
3.2.8.1 - Tela de instalação
3.2.8.2 - Tela Principal do jogo
3.2.8.3 - Tela Opções
3.2.8.4 - Etc
3.4 – Opções do jogo
Quais as opções e como elas afetam a jogabilidade e a mecânica?
3.5 – Re-jogando e Salvando o jogo
3.6 – Códigos de trapaça (Cheat-codes) e procedimentos escondidos (Easter-
eggs)
117
No Quadro 10, o enredo do jogo e seu universo devem ser descritos com
o máximo de informações possíveis, assim como as cenas e áreas que irão o
compor. Os personagens além da descrição física e psicológica podem descritos
suas habilidades, relacionamentos, a frequência que irão aparecer no decorrer do
jogo.
QUADRO 10 – ESTRUTURA BÁSICA DE UM GDD – ENREDO, UNIVERSO E PERSONAGENS
4 – Enredo, Universo e Personagens
4.1 – Enredo e Narrativa

Descreva resumidamente o enredo do jogo. Detalhes específicos como Script e
corte de
cenas, são descritos em uma Story Bible.
4.1.1 – Prelúdio
4.1.2 – Elementos do enredo
4.1.3 – Progressão do Jogo
4.1.4 – Corte de Cenas
4.1.4.1- Corte de cena 1
Atores
Descrição
Storyboard
Script
4.1.4.2 – Corte de cena 2
...
4.2 – Universo do Jogo
4.2.1 – Impressões gerais do universo do jogo
4.2 2 – Área 1
Descrição Geral
Características físicas (Ex.: visuais, sonoros etc.)
Níveis utilizados na Área
Conexões com outras Áreas
4.2.3 – Área 2
...
4.3 – Personagens
4.3.1 – Personagem 1
4.3.1.1 – Prelúdio
4.3.1.2 – Personalidade
4.3.1.3 – Aparência
Características físicas
Animações
4.3.1.4 – Habilidades especiais
4.3.1.5 – Relevância no Enredo do Jogo
118
4.3.1.6 – Relacionamentos com outros personagens

4.3.1.7 – Estatísticas (Ex.: Frequência em que o personagem aparece)
4.3.1 – Personagem 2
...
4.4 – Referências
Coloque documentos, livros, filmes, vídeos, apêndices deste documento,
outros jogos ou
atas de reunião como referência da narrativa e enredo.
Todo nível ou fase deve ser descrito. No Quadro 11 podemos observar as

subseções que devem ser descritas para cada nível que será criado, vale ressaltar
que é essencial que se tenha um objetivo diferente em cada nível.
QUADRO 11 – ESTRUTURA BÁSICA DE UM GDD - NÍVEIS
5 – Níveis
5.1 – Nível 1
5.1.1 – Resumo
5.1.2 – Material introdutório (Ex.: Cortes de cena, Breafing de missão, vídeos ou
textos)
5.1.3 – Objetivos
5.1.4 – Descrição física
5.1.5 – Mapa
5.1.6 – Caminho crítico (Ex.: Caminho em que o personagem pode encontrar
um inimigo)
5.1.7 – Encontros
5.1.8 – Nível passo a passo
5.1.9 – Finalização do material (Ex.: Cortes de cena, check de objetivos, vídeos
ou
textos)
5.2 – Nível 2
...
5.n – Nível de treinamento
O Quadro 12 apresenta o que deverá ser descrito na seção de interface,

deve ser definido qual o hardware irá controlar o jogo, os menus, as câmeras,
a iluminação, os comandos de controle, o sistema de áudio que será utilizado,
incluído músicas e efeitos sonoros e como será o sistema de ajuda do jogo.
119
QUADRO 12 – ESTRUTURA BÁSICA DE UM GDD - INTERFACE
6 – Interface
6.1 – Sistema Visual

6.1.1 – HUD (Head-Up Display) – O que controlar?
6.1.2 – Menus
6.1.3 – Sistema de Renderização
6.1.4 – Câmera
6.1.5 – Modelos de Iluminação
6.2 – Sistema de Controle
Descreva como o jogador pode controlar o jogo. Existem comandos específicos?
Existem
comandos ocultos para o jogador?
6.3 – Sistema de Áudio
Descreva se o áudio é em Mono, Stereo, 2D ou 3D.
6.3.1 – Músicas
6.3.2 – Efeitos sonoros
6.4 – Sistema de Ajuda
Na inteligência artificial que será utilizada no jogo, devem ser descritas as

ações estratégicas da IA, os personagens, as colisões e objetos que terão o suporte
de IA, conforme podemos observar no Quadro 13
QUADRO 13 – ESTRUTURA BÁSICA DE UM GDD – INTELIGÊNCIA ARTIFICIAL
7 – Inteligência Artificial
7.1 – IA de Oponentes
Descreva os oponentes ativo que interagem contra o jogador, no qual, reagem
às ações estratégicas feitas por ele (Ex.: Xadrez, jogo-da-velha etc).
7.2 – IA de Inimigos (Vilões e Monstros)
7.3 – Personagens Não-Combatentes
7.4 – Personagens Amigáveis
7.5 – IA de suporte
7.5.1 – Colisões do jogador e objetos
7.5.2 – Melhor caminho (Pathfinding)
O Quadro 14 apresenta a seção do projeto técnico, onde deverão ser

descritos os termos utilizados como um glossário para facilitar a consulta em
caso de dúvidas, definir o equipamento-alvo, ou seja, os requisitos mínimos de
hardware e software para que se possa executar o jogo, o ambiente em que foi
120
desenvolvido o jogo, os processamentos escolhidos para o seu desenvolvimento,

o motor, a rede (se aplicável) e a linguagem de programação que será utilizada
para seu desenvolvimento.
QUADRO 14 – ESTRUTURA BÁSICA DE UM GDD – PROJETO TÉCNICO
8 – Projeto Técnico
Os termos técnicos podem ser descritos em formato de glossário no Technical
Bible.
8.1 – Equipamento-alvo
Descreva o ambiente recomendado em que o jogo deverá ser instalado depois
de produzido, indicando, também, os requisitos mínimos de hardware e software
do jogador.
8.2 – Ambiente desenvolvido (Hardware e Software)
Descreva detalhadamente em que ambiente o jogo é desenvolvido, inclusive,
Sistema Operacional, Memória, Hard Disk e suas versões.
8.3 – Procedimentos e padrões de Desenvolvimento
8.4 – Motor do Jogo (Engine)
Descreva qual a engine utilizada para criar o jogo e sua versão.
8.5 – Rede
Descreva o ambiente de rede em que o jogo está expondo servidores (no caso de
Multiplayerse MMOs), se será via internet, apenas intranet ou VPN, entre outros.
8.6 – Linguagem de programação
O código-fonte comentado é inserido na Script Bible produzido pela equipe de
programadores.
No Quadro 15 devem ser descritos todos os termos artísticos que serão

utilizados. Na sequência, são descritas a arte conceitual, o guia de estilos,
personagens, ambientes, equipamentos, entre outros elementos que irão aparecer
no jogo. Além da descrição, podem ser incluídos desenhos e artes dos cenários,
personagens e demais elementos em cena.
QUADRO 15 – ESTRUTURA BÁSICA DE UM GDD – PROJETO ARTÍSTICO
9 – Projeto Artístico
Os termos artísticos podem ser descritos em formato de glossário no Art Bible.

Para projetos musicais é necessário criar um documento específico. Nesta seção
podem ser inseridos arquivos de imagens.
9.1 – Arte conceitual
9.2 – Guias de Estilo
9.3 – Personagens
121
9.4 – Ambientes
9.5 – Equipamentos
9.6 – Cortes de Cena
9.7 – Miscelânea
Todos os softwares utilizados no desenvolvimento do jogo devem ser

descritos na seção 10 do documento (Quadro 16). Além disso, os softwares podem
ser descritos nas atualizações e plugins utilizados no desenvolvimento.
QUADRO 16 – ESTRUTURA BÁSICA DE UM GDD – SOFTWARES SECUNDÁRIOS
10 – Softwares Secundários
10.1 – Editores (Ex.: Modelagem 2D ou 3D, sons, músicas)
10.2 – Instaladores
10.3 – Atualização de programas
10.4 – Miscelânea
Na seção de gerenciamento (Quadro 17) devem ser descritos o cronograma,

orçamentos, as licenças utilizadas, a análise de risco e o plano de locação, onde
será vendido o jogo (disponibilizado) e o plano de testes.
QUADRO 17 – ESTRUTURA BÁSICA DE UM GDD – GERENCIAMENTO
11 – Gerenciamento
11.1 – Detalhes do Cronograma
11.2 – Orçamento
11.3 – Considerações de Licença
11.4 – Análise de Risco
11.5 – Plano de Locação (Lugar a ser vendido)
11.6 – Plano de Teste
Qualquer pessoa ou organização que irá participar do desenvolvimento

do jogo devem ser descritas na seção 12 (Quadro 18), a qual deve conter o nome
do profissional ou organização e a sua atuação ou função no desenvolvimento.
122
QUADRO 18 – ESTRUTURA BÁSICA DE UM GDD – EQUIPE
12 – Equipe
Coloque os créditos da equipe do projeto, identificando o que cada pessoa ou
empresa terceirizada faz.
A seção 13, os apêndices (Quadro 19), deverá conter as informações que

porventura não puderam ser inseridas na seção ou informações adicionais, como
listas de ativos de arte, sons, e qualquer outros recursos que será utilizado no
desenvolvimento. Recomenda-se utilizar os endereços dos recursos para facilitar
o acesso a eles.
QUADRO 19 – ESTRUTURA BÁSICA DE UM GDD – APÊNDICES
13 – Apêndices
É recomendado escrever o caminho do arquivo com extensão para referências,
inclusive.
13.1 – Ativos de Arte
Lista de Modelos e Texturas
Lista de animações
Lista de efeitos
Lista de interface artística
Lista de cortes de cena
13.2 – Ativos de Som
Sons de ambiente
Sons de armas
Sons de interface
13.3 – Ativos de Música
Ambiente
“Ação”
Vitória
Derrota
13.4 – Ativos de Vozes
Ator 1 – Linha de voz
No final do documento, os gerentes do projeto, coordenadores técnicos e

coordenadores artísticos devem assinar o documento. O Quadro 20 apresenta a
estrutura final do documento.
123
QUADRO 20 – ESTRUTURA BÁSICA DE UM GDD – ASSINATURAS RESPONSÁVEIS
Em nn / nn / nnnn
Nome do Gerente do Projeto

Gerente do Projeto
Em nn / nn / nnnn
_________________________________
Nome do Coordenador Técnico
Coordenador Técnico
Em nn / nn / nnnn
_________________________________
Nome do Coordenador Artístico
Coordenador Artístico
E
IMPORTANT
Neste link a seguir, você irá encontrar o Documento de Game Design,

traduzido e adaptado por Elinaldo Azevedo (2009), que pode ser utilizado para você criar
uma estrutura básica do seu jogo: https://bit.ly/2ZqSMgW.
2.5 LISTA DE VERIFICAÇÃO DA PRÉ-PRODUÇÃO

A lista de verificação (Quadro 21) pode ser utilizada para confirmar
o progresso da fase de pré-produção, assim como observar o que pode ser
melhorado.
124
QUADRO 21 – LISTA DE VERIFICAÇÃO DA PRÉ-PRODUÇÃO
LISTA DE VERIFICAÇÃO DA PRÉ-PRODUÇÃO S/N NOTAS

CONCEITO
O conceito inicial do jogo foi definido?
A plataforma e o gênero foram especificados?
A declaração da missão foi concluída?
Os elementos básicos de jogabilidade foram definidos?
O protótipo foi concluído?
A análise de risco foi concluída?
A exposição do conceito está pronta para aprovação?
Todos os stakeholders aprovaram o conceito?
O lançamento do projeto foi agendado?

REQUISITOS DO JOGO
Os recursos que “devem entrar”, que “queríamos que

entrassem” e que “seria bom ter” foram definidos?
As restrições foram definidas e solucionadas nos conjuntos de

recursos?
As etapas e os produtos foram definidos?
A tecnologia foi avaliada com relação ao conjunto de recursos

desejado?
As ferramentas e o pipeline foram definidos?
A documentação básica do design foi concluída?
A documentação técnica básica foi concluída?
A análise de risco foi concluída?
Todos os stakeholders aprovaram os requisitos do jogo?

PLANEJAMENTO DO JOGO
O orçamento foi concluído?
O cronograma inicial foi concluído?
O plano inicial de pessoal foi concluído?
Os membros da equipe primária aprovaram o cronograma e

o plano de pessoal?
Todos os stakeholders aprovaram o planejamento do jogo?
3 PRODUÇÃO
Na fase de produção, as informações identificadas na fase de pré-projeto
são colocadas em prática, é onde se inicia a produção do jogo. Chandler (2012, p.
10) afirma que na fase de produção “(...) enfoca a criação de conteúdo e código, o
rastreamento do progresso e a conclusão de tarefas”.
125
A produção é o momento em que o jogo em si é construído, no qual os

modeladores/artistas, realizarão a modelagem tridimensional dos cenários e
personagens, texturização dos mesmos, em seguida farão a implementação dos
mesmos em um motor de jogo, ou seja, construirão o design de nível, os game
designers fazem o que Schuytema chama de roteiro de gameplay, ou seja, definem
a mecânica do jogo. Em seguida a equipe de programadores define, revisa e
implementa o código de programação (MARQUES, 2015, p. 27).
É comum que a fase de produção seja iniciada antes que seja finalizada a
fase de pré-produção, no decorrer da fase de produção ocorre o processo iterativo
de implementação do que foi planejado na fase de pré-produção. A produção,
segundo Chandler (2012), é dividida em nas fases de implementação do plano,
rastreamento do progresso e conclusão de tarefas.
3.1 IMPLEMENTAÇÃO DO PLANO

A implementação do plano se inicia quando o produtor comunicar à
equipe o plano final, além de fornecer todas as ferramentas e recursos necessários
para a implementação do jogo. Algumas boas práticas podem ser seguidas, como:
• Tornar o plano público, Disponível em:site ou área que a equipe tenha acesso;
• Incluir todos os documentos criados na fase de pré-produção;
• Afixar cópias impressas dos prazos-chave em um local em que toda a equipe
circule/frequente;
• Deve-se evitar o crescimento desenfreado, quando novas funcionalidades são
continuadamente inclusas no projeto, por exemplo. Ao se evitar o crescimento
desenfreado não teremos o risco de ficarmos sem tempo para executar o
projeto ou recursos (CHANDLER, 2012).
Na implementação do plano são realizados três ciclos de produção: design,

artística e programação. A Figura 19 demonstra essa iteração entre os ciclos de
produção.
FONTE: A autora
126
No ciclo de produção do design é onde são evoluídos os recursos criados

na fase de pré-produção. Esse ciclo envolve muitas iterações e evoluções nos
recursos. No ciclo de produção artística são criados os assets. No ciclo de produção
de programação, o jogo é codificado e os demais recursos criados nos outros ciclos
inclusos na implementação do jogo (CHANDLER, 2012).
3.2 RASTREAMENTO DO PROGRESSO

No rastreamento de progresso é analisado o ponto em que estamos, ou
seja, em que ponto está o desenvolvimento do jogo. Para realizar o rastreamento
de progresso, pode-se utilizar um software como o Microsoft Project, ou outro
software, de planejamento e cronograma (CHANDLER, 2012).
3.2.1 Revisões de projeto

A revisão do projeto deve ocorrer ao longo do desenvolvimento da fase
de produção do jogo, assim, podemos realizar o monitoramento do progresso de
desenvolvimento do jogo (CHANDLER, 2012). Ao realizar revisões regulares no
projeto, podemos controlar as tarefas e identificar se algum risco, falha ou atraso
pode ser corrigido em tempo.
3.2.2 Reuniões
As reuniões podem ser informais ou formais. As reuniões são uma
excelente oportunidade para compartilhar o progresso do desenvolvimento,
além de envolver a equipe a se conhecer e fomentar a comunicação entre os
integrantes dela (CHANDLER, 2012). Dependendo da metodologia ou método
de gestão de projeto, podem ocorrer reuniões diárias, para compartilhar o status
de desenvolvimento de cada um dos integrantes e das equipes. Essas reuniões
são curtas (até 15 minutos), informais e normalmente realizadas em pé.
3.2.3 Priorização

Ao se identificar as tarefas que serão executadas no decorrer do
desenvolvimento, devemos priorizar quais são as mais importantes e principais
no desenvolvimento. Chandler (2012, p. 7) ressalta que ao desenvolver o jogo,
devemos listar os recursos que serão desenvolvidos, sendo que “uma maneira de
fazer isso é pedir que a equipe liste recursos que “devem entrar”, “queríamos que
entrassem” e “seria bom ter”. Discuta-os e então crie um conjunto de recursos
final priorizado”.
127
Uma técnica que pode ser utilizada para se priorizar as tarefas é o Método
MoSCoW.
O método MoSCoW é uma técnica de priorização usada na gestão como

um todo, análise de negócios, gestão de projetos e desenvolvimento
de softwares com o intuito de encontrar um entendimento em comum
entre as partes interessadas sobre a importância que elas atribuem a
cada requisito (PIRES, 2019, s. p.).
O termo MoSCoW é um acrônimo em inglês, em que são utilizadas as

letras em maiúsculo para definir as quatro categorias, assim os ‘os’ são utilizados
para que fique pronunciável (SANTOS, 2018). As categorias do método MoSCow
são apresentadas pelas Figura 20.
FIGURA 20 – TÉCNICA MOSCOW
FONTE: SOUEID e ALVES (s. d.)
DICAS
Quer explorar mais sobre o método MoSCoW? Assista o seguinte vídeo:

https://www.youtube.com/watch?v=amHjvQt-WeA.
3.2.4 Mudanças
No desenvolvimento da fase de produção é provável que mudanças sejam
realizadas no jogo, na história e personagens. Muitas vezes elas podem ocorrer
para corrigir, adaptar ou melhorar o que já foi desenvolvido até o momento. No
entanto, é essencial que não ocorram grandes mudanças, como a troca de uma
128
hora para o outra do tipo de jogo, ou do gênero, por exemplo, uma vez que essas
grandes mudanças impactam o desenvolvimento e geram retrabalho. Isso porque
muitas ideias, documentos, protótipos, história, entre outros detalhes tem que ser
modificados ou refeitos. Com isso, ser for realizar mudanças, que sejam poucas e
que busquem melhorar o que foi desenvolvido até o momento, não impactando
drasticamente o planejamento do projeto.
3.2.5 Processo de aprovação

Finalizados os ciclos de produção, todas as tarefas que foram realizadas
para se desenvolver o jogo devem ser avaliadas e os resultados de cada uma dessas
tarefas devem ser aprovados pela equipe, buscando assim identificar se tudo o
que foi idealizado e planejado foi implementado no jogo. Após a aprovação de
toda equipe, uma versão compilada do jogo poderá ser criada.
3.3 CONCLUSÃO DE TAREFAS

Após finalizar todas as tarefas planejadas até a fase de produção, teremos
uma versão do jogo desenvolvida. Chandler (2012, p. 11) ressalta que “é difícil
determinar quando tarefas de engenharia estão concluídas, já que não há
indicadores claros relacionados à quando um trecho de código está concluído,
principalmente quando correções de bugs ainda podem ser feitas no código”.
Isso não quer dizer que o jogo esteja pronto, apenas que a fase de produção foi
concluída, mas ainda haverá muito trabalho a ser realizado nas próximas fases.
Para identificar se uma tarefa foi concluída, Chandler (2012, p. 11) propõe
a definição de critérios de saída, que “(...) são condições que devem ser atendidas
antes de uma tarefa ser considerada terminada”. Assim, as tarefas podem ser
melhor rastreadas, porém, esses critérios devem ser de fácil compreensão para
todos da equipe, e para quem for responsável por sua execução (CHANDLER,
2012).
3.4 LISTA DE VERIFICAÇÃO DA PRODUÇÃO

A lista de verificação (Quadro 22) pode ser utilizada para confirmar o
progresso da fase de produção, assim como observar o que pode foi realizado,
o que pode ser melhorado e se alguma tarefa está pendente, para assim iniciar a
próxima fase.
129
QUADRO 22 – LISTA DE VERIFICAÇÃO DA PRODUÇÃO
LISTA DE VERIFICAÇÃO DA PRODUÇÃO S / N NOTAS

IMPLEMENTAÇÃO DO PLANO
O planejamento do jogo foi claramente comunicado para a

equipe?
O planejamento do jogo está em um local publicamente

acessível?
O planejamento pode ser facilmente atualizado com

mudanças feitas pelo produtor?
Todas as pessoas da equipe têm os recursos necessários para

fazer seu trabalho?
Há um processo definido para o controle do crescimento

desenfreado?
A avaliação de risco está ocorrendo regularmente em toda a

produção?
Há um processo definido para o gerenciamento das

dependências de tarefas?

RASTREAMENTO DO PROGRESSO
Há um planejamento de jogo no qual o rastreamento do

progresso possa se basear?
Há um processo definido para o produtor rastrear o

progresso de todas as tarefas?
O progresso é afixado em áreas visíveis nas salas da equipe?

CONCLUSÃO DE TAREFAS
Cada tarefa tem critérios de saída claramente definidos?
Esses critérios de saída estão publicamente disponíveis para

a equipe?
Todos os stakeholders estão de acordo sobre quais serão os

critérios de saída?
TUROS
ESTUDOS FU
Em nosso próximo tópico, iremos dar continuidade nas fases de

desenvolvimento, onde iremos conhecer as fases de Testes e Pós-produção.
130
RESUMO DO TÓPICO 2
• O ciclo de desenvolvimento de jogos é composto por quatro fases: Pré-

produção, Produção, Testes e Pós-Produção.
• Na fase de Pré-produção é definido o conceito do jogo, seus requisitos, criado

seu planejamento e o GDD (Documento de Design do Jogo).
• O conceito do jogo deve ser um esboço do que será desenvolvido. O início do

processo começa quando se responde às perguntas: O que será feito? E para
quem será feito?
• Uma boa técnica para gerar ideias é a Brainstorm, onde todas as ideias são
aceitas e depois de discutidas são validadas ou descartadas, resultando na
identificação a melhor ideia.
• Ao se levantar os requisitos do jogo, devem ser inclusos os recursos de arte,

design e da engenharia, sendo que devem estar de acordo com o que foi
definido no conceito e na declaração da missão do jogo.
• As etapas e produtos as serem desenvolvidos são: (1) primeira versão jogável,

(2) versão alfa, (3) congelamento do código, (4) versão beta e (5) versão gold.
• O GDD é a documentação do jogo, considerada a espinha dorsal do projeto,

pois apresenta todas as características do jogo.
131
AUTOATIVIDADE
1 Na fase de pré-produção são realizadas várias atividades para identificar

o conceito do jogo e criar uma documentação que servirá como um guia
durante todo o projeto de desenvolvimento do jogo. Sobre este documento,
assinale a alternativa CORRETA:
a) ( ) O GDD (Game Design Document) será utilizado as vezes pelas equipes

de design e arte, para criar o conceito do jogo, artes e estilos.
b) ( ) O GDD (Game Design Document) será utilizado apenas pela equipe
de engenharia, uma vez que eles tiveram pouca participação no
desenvolvimento dos assets, artes e conceitos do jogo.
c) ( ) O GDD (Game Design Document) será utilizado por toda a equipe de
desenvolvimento, e pelas equipes especificas.
d) ( ) O GDD (Game Design Document) será utilizado somente para mostrar
aos clientes como o jogo será desenvolvido.
2 Na fase de produção, o jogo começa a ganhar vida, e sua implementação

é iniciada. O desenvolvimento do jogo é realizado pela iteração entre os
ciclos de produção. Sobre esses ciclos de produção, assinale a alternativa
CORRETA:
a) ( ) Produção de Design. Produção Artística. Produção de Programação.

b) ( ) Produção de Design. Produção Arte. Produção de Implementação.
c) ( ) Produção de Projeto. Produção Artística. Produção de Codificação.
d) ( ) Produção de Projeto. Produção Arte. Produção de Implementação.
3 A análise SWOT é conhecida em outras áreas do desenvolvimento, como

na Administração e Marketing. A estrutura da SWOT busca identificar
os fatores positivos, negativos e os fatos internos e externos que podem
impactar o produto. Sobre a utilização do SWOT e qual sua função no
desenvolvimento de jogos, assinale a alternativa CORRETA:
a) ( ) Auxiliar no processo de levantamento de ações dos personagens.

b) ( ) Auxiliar na identificação dos profissionais que irão atuar no jogo.
c) ( ) Auxiliar na definição da ideia do jogo.
d) ( ) Auxiliar no processo de definição do conceito do jogo e sua concepção.
4 Ao se desenvolver um projeto, tudo deve ser planejado e controlado. Os

riscos podem implicar que o projeto seja afetado, e que resulte em atrasos,
falhas e retrabalho. Disserte sobre os riscos mais comuns ao longo do
desenvolvimento de projetos.
5 No desenvolvimento de jogos é comum que vários profissionais atuem

juntos, logo, equipes de desenvolvimento são consideradas multidisciplinar,
uma vez que uma equipe apoia e interage com a outra. Neste contexto,
disserte sobre os líderes de cada uma das equipes.
132
UNIDADE 2
TÓPICO 3 —
TESTES E FASE DE PÓS-PRODUÇÃO
1 INTRODUÇÃO
Olá, caro(a) acadêmico(a)! Bem-vindo(a) ao Tópico 3. Ao longo deste
tópico, iremos abordar as fases finais do desenvolvimento de Produção de
jogos. A Figura 21 demonstra a trajetória que vivenciamos até o momento e nos
apresenta as duas fases finais.
FONTE: A autora
Na fase de testes, iremos conhecer o que deve acontecer após termos uma
versão compilada do jogo. Já na última fase, de pós-produção, iremos abordar
sobre o plano de arquivamento, como o que desenvolvemos pode ser resultar em
lições que podemos utilizar e aprimorar em futuros projetos.
2 TESTES
Por meio dos testes é que são identificados erros e falhas no jogo.
Chandler (2012) destaca que é uma das fases mais críticas no desenvolvimento.
É através dos testes que “(...) o jogo é verificado para vermos se tudo funciona
corretamente e se não há nenhum bug fatal. Os testes são contínuos durante o
processo de produção”, sendo que a equipe de QA “verificará as builds, as novas
funcionalidades e os novos recursos da etapa à medida que ficarem disponíveis
no jogo” (CHANDLER, 2012, p. 12). Novak (2017, p. 325) diz que os testes de
um jogo “consistem em jogá‑lo antes do lançamento para determinar se é ou não
jogável: ou seja, isento de erros, consistente e divertido”.
133
Durante os testes, todo o jogo é analisado em busca de falhas técnica e

conceituais. Os profissionais que realizam os testes, os testadores de QA, atuam
como jogadores, e eles devem explorar todos os elementos que compõem o jogo.
Caso algum erro (bug) ou problema seja encontrado, deverá ser informado à
equipe de engenharia para realizar os correções e ajustes necessários (PONTES,
2009).
Os testes são realizados desde a versão jogável do jogo. Aa versão beta é

quando todos os assets e recursos já foram implementados, assim, a equipe de
desenvolvimento fica responsável pela correção dos erros e pela criação de novas
compiladas e executadas (builds) do jogo, onde a equipe de QA irá realizar uma
nova rodada de testes. Após o jogo passar por todos os testes, é criada a versão
gold, que é a versão utilizada para a publicação (CHANDLER, 2012).
Qual o perfil de um testador, por assim dizer? Rogers (2010) afirma que:
um bom testador tem paciência, persistência e ótimas habilidades

de comunicação para relatar qualquer problema (ou "bugs”) que
eles encontrarem no jogo. Não é um trabalho fascinante, mas sem
testadores, seríamos atormentados por jogos que caem ao carregar,
têm câmeras ruins, sistemas de combate quebrados e balanços de
dificuldade injustos (ROGERS, 2010, p. 16-17).
Rogers (2010) também reitera que muitos profissionais que atuam no

desenvolvimento de jogos iniciam como testadores e vem se capacitando. Assim,
com o decorrer do tempo, atuam em outras equipes. Em muitos casos, atuar
como testador em um jogo pode ser uma grande chance de entrar na área de
desenvolvimento.
No entanto, vale ressaltar que os testes não iniciam apenas quando

o jogo foi todo codificado, nem em suas versões. Os testes de qualidade são
realizados em todo o decorrer do desenvolvimento do jogo. Chandler (2020, p.
245) afirma que o “teste de controle de qualidade ocorre durante todo o processo
de desenvolvimento e é mais do que apenas jogar o jogo para ver se é divertido.
Testar é um trabalho estressante e difícil, pois os testadores são a última rodada
de defesa antes que o jogo seja lançado para os jogadores”.
Não é realizado apenas um tipo de teste. Na verdade, são vários e cada

um com um objetivo próprio. No Quadro 23, são apresentados os diferentes tipos
de testes que devem ser executados.
134
TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO
QUADRO 23 – TIPOS DE TESTES
Tipo de Teste Objetivo do teste
Observar o fato de divertimento do jogo, não se espera

encontrar erros, mas sim ter uma perspectiva de como
Teste de
o jogo é interpretado pelo jogador. Pode-se utilizar os
Jogabilidade
profissionais da equipe ou convidar pessoas externas para
participar deste teste.
Cada funcionalidade do jogo é verificada, esse tipo de

teste é o que irá demandar maior tempo pois analisa em
Teste Funcional
detalhes as funcionalidades buscando identificar todos os
erros ou o máximo de erros possíveis.
Neste teste diferentes hardwares e softwares são utilizados

para testar a compatibilidade do jogo com as plataformas
Teste de
que irão ser utilizadas para executá-lo. Por este teste são
compatibilidade
identificadas as especificações mínimas de hardware e
software para que o jogo funcione quando for distribuído.
Identifica a quantidade de quadros por segundo (FPS)

no jogo, sendo que o mínimo necessário são 30 FPS. Em
Teste de
alguns jogos mais avançados e com maior qualidade
desempenho
gráfica, é comum que seja executado a 60 FPS. Esse teste é
realizado em todo o desenvolvimento do jogo.
Neste teste são verificadas as traduções do jogo, que devem

Teste de
ser realizadas por um testador nativo na língua em que o
localização
jogo é executado. Em alguns casos, este teste é terceirizado.
É um teste aleatório e não planejado, sendo que muitos

problemas podem ser encontrados neste tipo de teste. Para
o teste do jogo, por exemplo, são abertos vários outros
Teste Ad Hoc
softwares em paralelo ao jogo, forçando a identificação de
falhas no comportamento do jogo, como travas, falhas de
resposta, entre outros erros.
É importante ressaltar que em todos esses tipos de testes um profissional

da equipe deve acompanhar e reunir tudo o que foi analisado, falado e comentado
para gerar um feedback para toda a equipe. Pode-se utilizar um banco de dados de
rastreamentos dos erros coletados, os quais devem ser analisados e encaminhados
para a equipe de desenvolvimento realizar as correções necessárias.
135
2.1 PLANO DE TESTES

A equipe de QA é quem cria o plano de testes e realiza a validação do jogo
conforme planejado. Novak (2017) define o plano de teste como a
(...) construção de hipóteses a serem testadas e na criação de uma

lista de verificação discriminando cada aspecto ou área que deve ser
enfocada durante o processo de testes. O plano de testes documenta
esses procedimentos e descreve como o game será testado. Ele e
revisado sistematicamente durante o processo para abranger áreas
novas ou modificadas (NOVAK, 2017, p. 378).
Os testes são baseados nos assets e nas funcionalidades do jogo, conforme

especificado no planejamento. A equipe de QA trabalha com a equipe de
engenharia para compartilhar informações sobre o processo de testes e como
deve ser utilizado o software de identificação de erros.
Fleury et al. (2014) destacam que os testes
(...) são realizados nas várias versões do jogo em desenvolvimento,

desde os protótipos iniciais, a versão alfa, até o Beta final e a versão final.
Os testes de jogo podem ser internos na equipe de desenvolvimento
ou externos quando requeridos. Fãs cadastrados e conhecedores do
jogo, quando seriado, são frequentemente convidados a participarem
de testes de jogo na qualidade de testadores do jogo (playtesters)
(FLEURY et al., 2014, p. 131).

Todas as equipes devem auxiliar na validação do jogo. A equipe de QA
não tem como única função encontrar os erros, mas também analisar os erros
corrigidos pela equipe de engenharia, assim, o erro só é considerado concluído
ou fechado se a equipe de QA verificá-lo e confirmar sua correção (CHANDLER,
2012).
O plano de teste verifica em detalhes todas as áreas do jogo. O plano de

teste pode ser criado utilizando os documentos de design ou através dos protótipos
do jogo. É comum que seja utilizada uma lista de verificação para identificar a
aprovação ou reprovação de cada item.
Por exemplo, uma lista de verificação pode incluir uma lista de

personagens jogáveis, e o testador precisa iniciar o jogo, ir para a tela
de seleção de personagens e confirmar quais personagens jogáveis
estão no jogo. Na fase dois desta verificação, o testador pode precisar
selecionar cada personagem jogável e jogar através de um nível com
eles. Em um formato de reprovação, o testador pode precisar para
verificar cada botão na tela da interface do usuário e observe se ele
passa (o que significa que funciona conforme o esperado) ou falha (o
que significa que não funciona de maneira alguma ou não funciona
como o esperado) (CHANDLER, 2020, p. 251).
136
O plano de teste deve ser atualizado regularmente para que não se tenha
retrabalho, com isso é essencial que a cada erro solucionado uma nova versão
do jogo seja liberada para continuar os testes e identificar se os erros reportados
foram corrigidos. A utilização de um banco de dados de rastreamento de erros é
uma das maiores práticas de muitas equipes, pois uma vez inserido a informação
do erro no banco de dados, o mesmo deve ser verificado e em seguida fechado
pela equipe de desenvolvimento, assim podemos acompanhar o que foi corrigido
além destes dados poderem ser analisados e explorados para melhores práticas
de desenvolvimento e teste de jogos.
É essencial que seja definido como os erros devem ser relatados e rastreados,
por meio de um pipeline de correção de erros. O líder de controle de qualidade
deve garantir que todos os erros encontrados sejam priorizados e atribuídos a
uma pessoa apropriada para realizar as correções. Normalmente, o processo
de pipeline ocorre na seguinte sequência: Encontrado, Designado, Corrigido,
Verificado e Concluído (CHANDLER, 2020). No Quadro 24, são apresentadas as
definições de cada uma dessas fases do processo de pipeline.
QUADRO 24 – PROCESSO DE PIPELINE
Processo Descrição
Alguém na equipe de desenvolvimento ou na equipe de
Encontrado controle de qualidade encontra um bug e entra no banco de
dados de erros.
O bug é atribuído a um desenvolvedor para ser corrigido. A
Designado pessoa que faz as atribuições de bugs provavelmente é um
produtor ou um líder de equipe.
O desenvolvedor corrige o bug e o marca como corrigido no
banco de dados. Quando o bug é marcado como corrigido, o
Corrigido desenvolvedor notará em qual versão ele foi solucionado. Isso
ajuda o controle de qualidade a saber qual compilação eles
precisam verificar para a correção.
Na compilação apropriada, o testador de controle de qualidade
verificará a correção e observará como tal no banco de dados.
Eles incluirão em qual versão da compilação a correção foi
Verificado verificada. Isso se torna importante se o bug for reaberto mais
tarde. Pode ser que tenha sido verificado na compilação errada
ou que o bug tenha sido corrigido, mas agora voltou a ocorrer
devido a outras alterações no jogo.
O líder do controle de qualidade confirma que as correções
verificadas estão funcionando como pretendido e fecha o bug
no banco de dados. O bug é arquivado no banco de dados
Resolvido
e removido do processo de rastreamento de erros. Se o bug
ocorrer no futuro, o problema será reaberto e o processo
começará novamente.
137
Nem todos os erros são iguais, o que faz com que sejam classificados
em tipos, que ocorrem no desenvolvimento, não apenas de jogos, mas no
desenvolvimento de qualquer software:
• Bloqueador: é um erro que bloqueia os testes e que impossibilita que seja

executado o jogo. Com isso, é necessário que o erro seja resolvido e uma nova
versão compilada para que os testes sejam realizados.
• Erro de travamento: erro grave, pois impede que o jogo possa continuar.
Normalmente, esse erro é reportado e busca-se uma maneira de se evitá-lo
para que sejam continuados os testes no jogo.
• Erro crítico: quando um grande problema em alguma funcionalidade do jogo
impede o testador de progredir no jogo.
• Erro pequeno: são erros perceptíveis, mas que não afetam ou prejudicam
muito a experiência com o jogo. Exemplos desse tipo de erro são: erros de
digitação, textura, de cenário, entre outros.
• Solicitação de recursos: não é um erro, mas é um problema que pode ocorrer
ao executar o jogo. A solicitação de recursos é uma funcionalidade adicional
que tem sua utilização aconselhada. Um exemplo é quando o jogo solicita
autorização do usuário para acessar determinada pasta do sistema operacional
para armazenar informações do jogo ou seu log. Em alguns casos, o jogo é
interrompido quando a resposta é negativa (CHANDLER, 2020).
DICAS
O plano de testes é utilizado no desenvolvimento de software e nos jogos.

No vídeo a seguir, você pode conhecer mais profundamente sobre o assunto: https://
www.youtube.com/watch?v=UaYnchFsXzQ.
2.2 LIBERAÇÃO DO CÓDIGO

Após todos os testes concluídos e a aprovação da equipe de QA, começa o
processo de liberação do código. Chandler (2012, p. 13) assegura que na liberação
do código “todos os principais bugs já foram corrigidos, a funcionalidade está
conforme projetada e todos os assets do jogo foram finalizados. O jogo só precisa
de um último conjunto de verificações para confirmarmos se está pronto para ser
entregue ao fabricante”.
Novak (2017) ressalta que antes da liberação do código ocorre o

congelamento do código,
Os últimos dias ou semanas dessa fase constituem o que costuma

ser chamado de período de congelamento do código, durante o qual
todo o trabalho é finalizado e começa a preparação da mídia para
138
reprodução do game. Essa mídia (geralmente em forma de disco)

é submetida a testes e as únicas alterações permitidas no game são
aquelas que solucionam problemas urgentes encontrados durante essa
fase final de testes (NOVAK, 2017, p. 348).
Até que a liberação do código ocorra pode-se levar um tempo, ou seja, não
é uma ação imediata, e, também, dependendo do tamanho do jogo, esse tempo
pode durar entre um dia e uma semana. Assim, se tudo estiver ok, e nenhum
novo erro for encontrado, “o código do jogo será considerado lançado e o disco
poderá ser entregue ao fabricante para replicação” (CHANDLER, 2012, p. 13).
Será que o jogo está pronto mesmo? Um jogo, assim com um software,
está sempre em renovação e atualização. Com isso, uma vez lançado o código
do jogo, o desenvolvimento como um todo pode estar em fase de conclusão,
mas futuramente novas atividades serão necessárias para manter o jogo atual e
sem erros. “Depois que o jogo é lançado, ainda existem tarefas pós-lançamento,
incluindo a correção de problemas críticos que impedem os jogadores de
aproveitar o jogo, o gerenciamento de feedback da comunidade de jogadores e
o planejamento adicional lançamentos de conteúdo” (CHANDLER, 2020, p.
265). Com isso, podemos defender que um jogo que foi desenvolvido irá mudar
conforme o tempo, se adaptando a novas plataformas, novas linguagens de
programação e novas versões melhoradas do que foi desenvolvido inicialmente.
2.3 TDD
O Test Driven Development (Desenvolvimento Orientado por Testes),
ou TDD, é um método muito utilizado no desenvolvimento, que se baseia na
aplicação de pequenos ciclos de repetições onde um teste é aplicado em cada um
deles.
Um TDD é aplicado da seguinte forma. Primeiramente, os

desenvolvedores criam um teste que irá falhar de qualquer forma.
Afinal de contas, ainda não existe um recurso para ele.
Em seguida o time desenvolve a função que deve fazer o teste passar e
então reaplicar ele. Se o resultado é positivo, os profissionais implantam
o novo recurso no código, e então partem para o desenvolvimento de
um novo teste.
Esse ciclo é repetido até o final do projeto, quando o programa ou
aplicativo é finalizado (TECHLISE, 2021, s. p.).
Ao utilizar o TDD no desenvolvimento de jogos, os testes são escritos

antes do jogo ser implementado, e quando o código passa nos testes, ele pode vir
a ser melhorado. Essa técnica busca testar os recursos que serão desenvolvidos,
assim, evita-se o trabalho de implementar funções e depois descobrir que elas não
funcionam corretamente. Com isso, pode-se reduzir os custos de desenvolvimento
e evitar o retrabalho. O ciclo do TDD é bem simples, como pode ser observado
na Figura 22. Primeiro é criado um teste (vermelho – red), em seguida é a feita a
codificação para passar no teste (verde – green), e, por último, refatoramos o código
139
(refactor) (ROCHA, 2013; TECHLISE, 2021). Segundo Rocha (2013, s. p.), “(...) o
teste visa auxiliar a codificação, reduzindo consideravelmente os problemas na
fase de desenvolvimento”. Com isso, podemos utilizar este método ainda na fase
de produção, fazendo com que o processo de testes seja concluído mais rápido e
que menos erros sejam encontrados, uma vez que podem já terem sido corrigidos
ainda na implementação.
FIGURA 22 – CLICO DO TDD
FONTE: <https://bit.ly/3mm3sGA>. Acesso em: 15 ago. 2021.
NTE
INTERESSA
Quer se explorar mais sobre o TDD? Assista o seguinte vídeo: https://www.

youtube.com/watch?v=bLdEypr2e-8.
2.4 LISTA DE VERIFICAÇÃO DA EXECUÇÃO DE TESTES

A lista de verificação, apresentada no Quadro 23, pode ser utilizada para
confirmar o progresso da fase de testes, assim como observar o que pode ser
realizado, para assim iniciar a última fase.
140
QUADRO 23 – LISTA DE VERIFICAÇÃO DOS TESTES
LISTA DE VERIFICAÇÃO DOS TESTES S / N NOTAS

VALIDAÇÃO DO PLANO
O plano de testes foi criado?
O plano de testes foi atualizado para o departamento de QA?
O plano de testes foi atualizado com qualquer alteração que

tenha sido feita no planejamento do jogo?
As etapas de testes foram consideradas no cronograma?
O software de rastreamento de bugs foi disponibilizado para os

testadores e a equipe de desenvolvimento?
Todas as áreas do jogo foram testadas?
Todos os bugs foram regredidos e fechados?

LIBERAÇÃO DO CÓDIGO
A equipe de desenvolvimento enviou um candidato final à

liberação do código?
Há tempo suficiente no cronograma para o departamento de
QA concluir o plano de testes no candidato à liberação do
código?
O departamento de QA aprovou o produto para liberação do

código?
Somente no caso de console: O jogo que teve o código liberado

foi enviado para o fabricante do console para aprovação?
Somente no caso de console: O fabricante do console aprovou o

jogo para replicação final?
3 PÓS-PRODUÇÃO
Depois que o código for liberado e aprovado para fabricação ou
publicação, inicia-se a última fase da produção. Na pós-produção, o projeto deve
ser fechado, onde podemos conhecer as experiências que tivemos e realizar o
plano de arquivamento. Nem sempre essas duas ações são realizadas, existem
casos que essa fase da produção é ignorada ou esquecida (CHANDLER, 2012).
Concluído o plano de arquivamento, são identificadas as lições aprendidas e o
projeto pode ser considerado como concluído.
141
3.1 APRENDER COM A EXPERIÊNCIA

Ao se aprender com a experiência que tivermos ao desenvolver o jogo
produzido, podemos utilizar o conhecimento e a experiência em outros projetos.
Uma boa solução para identificar o que foi aprendido e os pontos positivos e
negativos de nosso desenvolvimento, é a condução de um post-mordem ao finalizar
o projeto. O post-mordem é um termo em latim, que significa
(...) depois de finalizado, após a morte. Na indústria de jogos, o termo

designa dois elementos: (1) um relatório, geralmente encabeçado pela
equipe de desenvolvimento, no qual se analisam os processos de
produção, os elementos aprendidos, revisados, as falhas, os métodos,
os ensinamentos etc. Geralmente os post-mortem podem se desdobrar
em vídeos de divulgação do jogo, publicados no Youtube ou Vimeo,
sendo muito apreciados e disputados pelos fãs e desenvolvedores em
formação. (2) um documento, livro ou artigo, publicado em revistas
científicas, ou especializadas pelos desenvolvedores (FLEURY et al.
2014, p. 124).
Pelo post-mordem, a equipe pode examinar o que ocorreu de bom e ruim

no projeto e propor soluções que podem auxiliar no desenvolvimento de futuros
jogos. O post-mordem não precisa ocorrer apenas depois da liberação do código,
mas também entre as liberações das versões alfa e beta, assim, por meio destes
pequenos post-mordem, as experiências de aprendizagem podem melhorar o
próprio desenvolvimento do jogo (CHANDLER, 2012).
Ao se criar o post-mordem, com relação ao feedback de desempenho do

projeto, será mais fácil corrigir problemas de processo e de desenvolvimento. O
post-mordem deve responder às seguintes perguntas:
• Atingimos os objetivos do jogo? Busca se identificar se o que foi planejado

e idealizado para o jogo foi realizado, não se a meta foi alcançada, mas sim
avaliar o que não foi alcançado e porque não foi possível alcançá-lo.
• As expectativas do projeto foram realistas? Deve ser discutido como se as
expetativas do projeto puderam ser realizadas, identificar o que não foi
realizado e sua causa ou se era uma atividade irrealista.
• O que deu certo? O que deu errado? Ao discutir estes dois pontos, a equipe
pode identificar soluções para evitar os problemas que surgiram e como os
evitar em futuros projetos. O que deu certo pode ser uma linha a ser seguida
em outros projetos.
• Que lições foram aprendidas? Devem ser discutidas as grandes lições que
foram aprendidas, e o que podem ser utilizados em próximos projetos, por
exemplo a comunicação clara com a equipe sobre os prazos (CHANDLER,
2020).
No decorrer do desenvolvimento, os profissionais poder anotar as

atividades que realizarem, para, assim, facilitar ao se discutir o post-mortem.
Com isso, detalhes não serão esquecidos. As lições aprendidas são o resultado
final do post-mortem, é o que fica de resultado tangível para consultas futuras.
142
Esse documento será publicado pela equipe e deverá ser disponibilizado para
que todos possam se beneficiar com o que foi aprendido. Chandler (2020, p. 201)
diz que deve ser limitado “o número de lições aprendidas no documento para
cinco. Qualquer coisa além disso é assustadora de implementar, reduzindo assim
a eficácia de publicar as lições em primeiro lugar”. Assim, devemos incluir no
documento lições que tenham maior probabilidade de que sejam implementadas
em outros projetos.
3.2 PLANO DE ARQUIVAMENTO

A última atividade para que o projeto seja concluído é a realização de um
plano de arquivamento, ou também conhecido como kit de fechamento. Chandler
(2012, p. 15) afirma que “esse kit contém toda a documentação de design, o código-
fonte, o arquivo-fonte da arte, os assets finais do jogo, os arquivos finais de música
e tudo o mais que foi usado na criação do jogo”.
O kit de fechamento pode ser composto por documentos físicos ou digitais,

uma boa alternativa é que o kit seja salvo em uma nuvem, para que fique mais
acessível, tanto para a equipe como a empresa realizarem consultas.
A criação deste kit é necessária, pois caso se deseje criar uma nova versão
do jogo, pode-se continuar do ponto que foi concluído, assim como é possível
utilizar o kit para criar novos jogos (CHANDLER, 2012). Com isso, toda a parte
inicial já está pronta, o que resta é realizar os ajustes e incluir os novos recursos,
fazendo com que não seja necessário começar uma produção do zero.
3.3 LISTA DE VERIFICAÇÃO DA PÓS-PRODUÇÃO

A lista de verificação (Quadro 24) pode ser utilizada para confirmar o
progresso da fase de pós-produção, além de observar se tudo foi concluído e o
projeto possa ser dado como concluído e arquivado.
QUADRO 24 – LISTA DE VERIFICAÇÃO DA PÓS-PRODUÇÃO
LISTA DE VERIFICAÇÃO DA FINALIZAÇÃO S/N NOTAS

PLANO DE ARQUIVAMENTO
O kit de fechamento foi concluído?

APRENDIZADO POR MEIO DA EXPERIÊNCIA
O post-mortem foi concluído?
O post-mortem foi publicado para o estúdio de desenvolvimento

inteiro?
143
DESIGN THINKING COMO METODOLOGIA ALTERNATIVA PARA O

DESENVOLVIMENTO DE JOGOS SÉRIOS
Luiz Carlos Murakami

Antonio José Melo Leite Júnior
Rodolfo Felipe Sganzerla Sabino
Diego Almeida Macedo
INTRODUÇÃO
(...) Este trabalho procura detalhar o processo de adaptação da metodologia

Design Thinking com o objetivo de propor um modelo alternativo de construção
de games que seja aplicado à geração de jogos sérios para fins diversos. Um
aspecto interessante a comentar sobre o desenvolvimento dos jogos em geral
é a necessidade de se explorar a interdisciplinaridade. O desenvolvimento dos
games é híbrido porque envolve diversas etapas, como estabelecimento de roteiro
de navegação, design de interface, aplicação de técnicas de animação, definição
de modelo de usabilidade, programação etc. Esta hibridização é resultado da
natureza necessariamente semiótica da linguagem dos games. Outra característica
dos games é a busca pela imersão do usuário baseada no aprimoramento da
interatividade, sendo está uma necessidade intrínseca à comunicação digital.
Na área de administração de empresas, existem estudos que comprovam

que é eficaz a utilização da aprendizagem experiêncial, processo em que o
conhecimento é criado através da transformação da experiência. Este processo de
aprendizagem é o que define os serious games, ou jogos sérios, que segundo são
jogos digitais feitos com o propósito de educar. Isto não quer dizer que eles não
sejam divertidos, mas não foram feitos exclusivamente com este propósito. Ainda
segundo o autor, os jogos, quando projetados com o objetivo de ensinar, podem
apresentar resultados significativos.
Outro olhar importante a se considerar é o de que analisa os jogos

segundo a epistemologia. Ele argumenta que os jogos são epistêmicos, ou seja,
precisam de uma maneira particular de pensar para serem utilizados. O modelo
de é baseado em conhecimento, habilidades, valores e identidade. (...) Existem,
portanto, razões importantes para delinear um método de elaboração de games
nesta direção. Dentro desta perspectiva, a metodologia Design Thinking pode ser
uma abordagem interessante em tal sentido, sendo a demonstração de seu uso o
objetivo principal deste trabalho. (...)
144
O QUE É DESIGN THINKING

A metodologia Design Thinking foi concebida por Nigel Cross após
analisar uma pesquisa feita por Bryan Lawson sobre uma situação em que foi
proposto um problema para ser resolvido por engenheiros e arquitetos, chegando
à conclusão que, de uma maneira geral, cientistas e designers resolvem problemas
de maneiras diferentes. De antemão, é importante salientar que, ao contrário do
que se pode considerar inicialmente, o termo design refere-se a projeto, resolução
de problemas, e não ao apelo estético de um produto. Assim, Design Thinking é
um método para resolver problemas baseado em soluções, “pensando-se”. Em
vez de se iniciar com um problema, inicia-se com uma solução-base e em seguida
definem-se parâmetros para se atingir o objetivo final. Na realidade, em suma, é
uma contraposição entre análise e síntese que é colocada neste tipo de abordagem
de um problema.
A proposta inicial da Design Thinking tem evoluído sobre maneira nos

últimos anos, e autores acabaram propondo alterações para seu uso em áreas bem
específicas, como criação de produtos, estabelecimento de negócios, educação,
publicidade etc. O presente trabalho apropria-se particularmente do modelo
proposto por, mais focado em inovação, e que faz a divisão da Design Thinking
em quatro fases principais, apresentadas a seguir.
Imersão: A imersão tem como objetivo o entendimento inicial do problema, com a

respectiva identificação de necessidades e oportunidades que nortearão a geração
de soluções. Para tanto, são procedidos, na verdade, dois tipos de imersão:
• Imersão preliminar, com realização de reuniões de alinhamento da equipe de

desenvolvimento com os possíveis clientes. Voltadas ao aprofundamento do
contexto do problema, tais reuniões consistem na pesquisa e na discussão de
assuntos análogos ao problema abordado, visando soluções próximas iniciais
e estabelecendo também os possíveis perfis dos usuários pretendidos;
• Imersão em profundidade, com realização de entrevistas (ou qualquer outra
técnica de consulta, como sessões generativas, cadernos de sensibilização etc.)
com usuários dos perfis identificados, a fim de se compreender melhor seus
respectivos anseios, necessidades e valores.
Análise e Síntese: Ao final da imersão, a massa de dados levantados é

analisada, cruzando informações a fim de identificar padrões e oportunidades.
Os resultados são sintetizados de forma estruturada, empregando ferramentas
de organização e planejamento comuns, porém também incluindo documentos
geralmente visuais e interativos, por exemplo, quadros de tarefas para
planejamento e organização dos esforços previstos (...) e mapas conceituais para
avaliação das relações entre produtos, tecnologias, indivíduos etc. (...). Nota-se,
então, que tal processo de análise e síntese é necessariamente complementar ao
processo de imersão, gerando subsídios válidos para a fase seguinte, de ideação.
145
Ideação: A partir dos documentos gerados pela Análise e Síntese,

procedem-se brainstorms da equipe de desenvolvimento junto a indivíduos
com perfil próximo ao definido (usuários e profissionais de áreas que sejam
convenientes ao tema trabalhado) e também possíveis clientes. Esses encontros
para geração e debates de ideias, conhecidos como workshops de cocriação, serão
os reais responsáveis pela riqueza e assertividade dos resultados pretendidos e
devem, então, ser realizados com especial atenção.
Prototipação: A fase de prototipação é o conceito inicial se torna um

conteúdo formal. A fase de prototipação contempla, em um primeiro momento, a
seleção e o refino de ideias, tornando-as tangíveis através de protótipos de baixa,
média e alta fidelidade. Posteriormente, o uso de tais protótipos, pela própria
equipe e por possíveis convidados, permite avaliar e finalmente validar ou refutar
cada uma das várias soluções anteriormente propostas. A prototipação pode,
e deve, então, antecipar, de forma controlada, possíveis problemas, reduzindo
riscos e otimizando gastos.
De uma forma geral, a prototipação consiste na transformação das ideias

em resultados reais, através da passagem, quantas vezes julgadas necessárias,
pelas seguintes etapas intermediárias: formulação de questões (escolha das
ideias para validação), criação dos protótipos (geração de modelos utilizáveis),
teste (aplicação dos protótipos junto a usuários internos e externos à equipe de
desenvolvimento), avaliação (análise de resultados) e conclusão (geração da
solução final). Por último, é importante deixar claro que as fases da Design Thinking
não são necessariamente sequenciais, mas módulos muitas vezes paralelos que se
inter-relacionam. E, da mesma forma, sempre que julgado necessário, é facultado
à equipe de desenvolvimento revisitar etapas a fim de otimizaras propostas
iniciais e as respectivas soluções obtidas.
ADAPTANDO DESIGN THINKING AO DESENVOLVIMENTO DE JOGOS

SÉRIOS
Pode-se notar que a Design Thinking em si é uma metodologia genérica

e generalista para a solução de problemas diversos, como produtos de mídia e
negócios, por exemplo. No entanto, sua adaptação direta para o desenvolvimento
de jogos sérios, ao contrário da maioria das metodologias voltadas à criação de
software, merece algumas considerações específicas:
• O uso da Design Thinking praticamente exige o emprego de uma equipe

multidisciplinare com número de membros variável, principalmente quando
se consideram os workshops de cocriação, que incluem possíveis clientes e
usuários/jogadores externos.
• É fortemente encorajado o uso de instrumentos intermediários (quadros

de tarefas, mapas conceituais etc.), de cunho visual e interativo, para a
representação de ideias.
146
• Um tom sempre crítico deve ser estimulado em toda a equipe de

desenvolvimento. Senão, de outra forma, será praticamente impossível
realizar corretamente a maioria dos processos previstos pela metodologia
Design Thinking.
• O contato direto com os jogadores que apresentam os perfis definidos é uma

constante no desenvolvimento, podendo implicar inclusive em alterações
profundas no projeto sempre que julgado necessário. Tais intervenções
dos possíveis usuários finais devem ocorrer referencialmente, mas não
necessariamente, já no início do desenvolvimento, a fim de minimizar gastos
posteriores com a realização de manutenções corretivas.
• A criação de protótipos em vários níveis é essencial para a completude de todos

os processos, envolvendo desde a criação da arte conceitual até a codificação
propriamente dita do game. O respectivo e constante uso de protótipos por
jogadores externos à equipe é crucial e a não permissão de tais intervenções
pode, muitas vezes, refletir-se até no fracasso do emprego do jogo como um
todo.
• Segundo a metodologia Design Thinking, ao final de todo o processo é necessário

resolver o problema. Assim, no caso específico de jogos sérios, deve-se
sempre concluir uma versão realmente utilizável do game, ficando possíveis
acréscimos reservados a novos projetos em separado. Tal decisão, porém,
implica logicamente na devida documentação e apropriação final de todo o
material gerado e das respectivas experiências obtidas no desenvolvimento
do projeto original para uso posterior nos possíveis desdobramentos.
APLICANDO DESIGN THINKING AO DESENVOLVIMENTO DE JOGOS

SÉRIOS
(...) O jogo foi elaborado por uma equipe composta por um professor do
curso de sistemas e mídias digitais, um professor do curso de administração e,
inicialmente, três alunos: dois desenhistas/animadores e um programador. (...) A
seguir, são apresentados os procedimentos e resultados práticos desenvolvidos
em cada uma das quatro fases principais definidas pelo uso da metodologia
Design Thinking adotada.
Imersão: Logo após a formação da equipe, foram feitas reuniões iniciais para
definição do tipo de jogo a ser desenvolvido. Deu-se, então, início ao processo de
imersão defendido pela Design Thinking. Na subfase de imersão preliminar foram
pesquisados vários jogos, discutindo-se possibilidades que tentavam relacionar
sempre Diversão e Ensino, termos eleitos como os principais assuntos análogos
ao problema. Já na subfase de imersão em profundidade, passou-se a trabalhar
também com um aluno do curso de administração da própria universidade (...).
Já a partir da fase de imersão, elegeu-se o próprio professor da administração,
147
membro da equipe, como o real cliente. Tal decisão mostrou-se muito importante,
pois foi possível, desde o começo, focar os esforços nas reais necessidades do jogo
a ser desenvolvido: aplicar o game em aulas tanto presenciais quanto a distância.
Análise e Síntese: O conjunto de informações obtidas na fase de imersão

foi compilado em um documento específico: o GDD, Game Design Document,
documento de projeto de jogo, bastante comum na definição e posterior
desenvolvimento de jogos eletrônicos. A opção por adotar-se o GDD como
principal base de informações foi necessária devido às particularidades dessa área
específica de desenvolvimento de software e, em hipótese alguma, prejudicou
as demais fases do projeto. Optou-se por disponibilizar o GDD a partir de
documentos compartilhados via internet, o que viabilizou a realização de várias
reuniões não presenciais pela equipe. Além disso, como a equipe não possuía
local fixo para trabalho, optou-se por estabelecer um quadro de tarefas virtual,
na forma de mensagens de e-mail trocadas sempre ao final das reuniões. Tais
mensagens indicavam tarefas a serem realizadas e seus respectivos responsáveis.
Nesta fase, os documentos gerados (GDD e quadro de tarefas virtual) ainda

se mostravam bastante desestruturados, pois ainda não havia uma real definição
do jogo a ser desenvolvido. Porém, já se expunham as principais necessidades e
possibilidades do jogo pretendido, o que serviria de base à realização da próxima
fase da metodologia.
Ideação: De posse do GDD inicial, o aluno consultado na fase de imersão

que cursava administração, acabou sendo oficializado como membro da equipe.
Paralelamente, o professor do curso de administração, membro da equipe,
começou a discutir possibilidades de jogos com colegas da instituição de ensino.
Passou-se, então, a buscar a especificação do jogo a ser desenvolvido. Para tanto,
considerou-se inicialmente a ideia de gameplay, provavelmente o conceito mais
importante para a elaboração de um jogo.
De forma complementar, outro aspecto considerado pela equipe para a

especificação do jogo foi trabalhar as regras que definem a essência do gameplay,
que podem ser definidas pelos bricks (...). Cada uma destas regras é representada
por um destes dez gameplaybricks, que podem se referir a regras relacionadas
a objetivos (avoid: evitar, match: encaixar/corresponder e destroy: destruir) ou
regras definindo meios e restrições para atingir os objetivos (create: criar, manage:
gerenciar, move: mover, random: sortear, select: selecionar, shoot: atirar/disparar e
write: escrever).
A partir do conceito de gameplay e do instrumento gameplaybricks, toda

a equipe debateu a especificação do jogo na forma de pequenos workshops de
cocriação, culminando no aprimoramento do GDD, tornando-o mais estruturado.
Nos workshops de cocriação abertos, que também envolveram alguns alunos
convidados do curso de administração da instituição, foram enumeradas
possibilidades de gameplays que poderiam envolver a correta abordagem dos
conceitos necessários. Ao final, optou-se finalmente pela criação do jogo Danki (...)
148
como cenário para as aplicações de estratégias de marketing. Baseada em fatos

reais do Japão feudal, a estória original Danki, desenvolvida pelo professor da
área de administração, participante da equipe, apresenta os desafios enfrentados
pelas ricas famílias produtoras de saquê. A fim de se tornarem a marca de bebida
preferida do imperador, tais famílias se desafiavam comercialmente e, muitas
vezes, chegavam a guerrear em busca da dominação de territórios.
Considerando-se como base o gameplay do jogo Plants versus Zoombies

foram diretamente associados aos gameplaybricksselect, match e destroy. A questão
era como combinar essas características com os conceitos de administração. O
passo seguinte foi discutir como criar cenários de guerra, base do jogo supracitado,
que tem um forte apelo nos jogadores, com decisões de marketing. Em seguida,
foi então proposta uma tela móvel que continha dois cenários, um de guerra e
outro comercial. No cenário de guerra (...) o jogador deveria escolher entre três
tipos de guerreiros: um samurai (lento, porém forte), um ninja (rápido, porém
fraco) e um arqueiro (com velocidade e força medianas). Estes guerreiros teriam
custos diferentes para uso, e os recursos para a aquisição dos mesmos viriam da
área comercial. No cenário comercial (...), o jogador deveria tomar determinadas
decisões, baseadas nos 4 Ps do marketing. Os 4Ps do marketing discutem como
quatro variáveis (Produto, Preço, Praça e Promoção) influenciam a forma como os
consumidores respondem ao mercado. A solução adotada para a narrativa-base
do jogo Danki, então, foi:
• Produto: o jogador poderia escolher quais produtos (três tipos de saquês,

voltados a consumidores de baixo, médio e alto poderes aquisitivos) manter
em estoque, cujo espaço para armazenamento era sempre limitado.
• Preço: o jogador poderia definir o preço das três diferentes bebidas a qualquer
hora. Se o preço fosse ou muito alto ou muito baixo, o fluxo de clientes iria se
alterar de acordo com os respectivos públicos consumidores.
• Praça: o jogador, à medida que passasse de fases, teria sua área comercial
modificada, com novos perfis de consumidores.
• Promoção: jogador poderia fazer uso de diferentes tipos de anúncios (festas e
eventos, por exemplo) para aumentar o fluxo de diferentes perfis de clientes.
Prototipagem: A partir das definições do jogo, foi elaborado um roteiro,

anexado ao GDD, e, à medida que mais reuniões eram realizadas, foram
estabelecidas diferentes atividades para os membros do grupo, sempre utilizando
o quadro de tarefas virtual. O processo de implementação do jogo foi dividido
nas seguintes etapas e respectivos protótipos:
• Definição da arte conceitual – desenhos iniciais com personagens, objetos e

cenários.
• Geração de elementos gráficos – arquivos digitais contendo imagens estáticas
e animadas, refinadas a partir da arte conceitual proposta.
• Definição da interface gráfica – protótipos de baixa (em papel), média e alta
fidelidades (arquivos digitais) contendo elementos, devidamente posicionados
em telas, necessários ao uso e correto entendimento do jogo.
149
• Pesquisa de soluções de programação – porções de código responsáveis pela

resolução de problemas identificados no GDD.
• Geração de versões do jogo – arquivos digitais contendo diferentes
possibilidades do jogo, criados sobre a plataforma Adobe Flash, com base nos
demais protótipos desenvolvidos.
As diversas versões do jogo foram avaliadas pela própria equipe de

desenvolvimento e por convidados que atendiam ao perfil determinado.
Novamente em workshops de cocriação foram discutidos problemas, possíveis
soluções e sugestões para aprimoramento dos protótipos.
Conforme dito anteriormente, no processo de desenvolvimento como um

todo, foi necessário percorrer várias vezes as fases principais da metodologia
Design Thinking, devido a alterações de requisitos e de conceitos. Notou-se, porém,
que tais idas e vindas acabaram por proporcionar um maior amadurecimento
das ideias envolvidas e da própria equipe. O desenvolvimento do game durou
cerca de 18 meses, prazo um tanto extenso, mas necessário pois o objetivo foi não
só o desenvolvimento do game mas principalmente o aprendizado dos alunos
bolsistas e dos professores participantes no estabelecimento e uso da metodologia
de desenvolvimento aqui exposta. (...)
FONTE: MURAKAMI, L. C. et al. Design Thinking como metodologia alternativa para o

desenvolvimento de jogos sérios. 2014. Disponível em: <http://www.tise.cl/volumen10/
TISE2014/tise2014_submission_200.pdf>. Acesso em: 25 jul. 2021.
150
RESUMO DO TÓPICO 3
• A fase de testes é considerada uma das mais críticas. É nela em que são
identificados os erros e falhas contidas no jogo, para que sejam corrigidas.
• Os testes buscam encontrar falhas técnicas e conceituais. Assim, os testadores

de QA atuam como jogadores. O plano de testes é criado com base nas
funcionalidades e assets, conforme foi especificado no planejamento do jogo.
• A liberação do código só ocorre quando todos os erros foram corrigidos pela

equipe de engenharia, testados e validados pela equipe de QA. Finalizado os
testes, ocorre a liberação do código para o fabricante ou cliente.
• O TDD é um método que se baseia em criar o teste antes da implementação

do código, tendo como objetivo reduzir custos e o retrabalho.
• A pós-produção nem sempre é realizada pelas equipes, porém, ela deve ser
executada para que seja identificado o que foi aprendido durante a produção
e para criar o plano de arquivamento.
• O post-mordem reúne as informações sobre o desenvolvimento do jogo pela

perspectiva da equipe, a qual examina os pontos positivos e negativos na
execução do projeto.
• O kit de fechamento deve incluir todas as informações que foram utilizadas no

projeto, além da documentação, o código-fonte, as artes, os assets, as músicas
e efeitos sonoros, ou seja, tudo que foi utilizado para se criar o jogo.
CHAMADA

151
AUTOATIVIDADE
1 O plano de teste é desenvolvido pela equipe de QA, é por meio dele que
o jogo será validado e testado. A equipe de QA trabalha com a equipe de
engenharia para corrigir os erros encontrados. Sobre os testes, assinale
a alternativa CORRETA que melhor define como os erros devem ser
abordados por ambas as equipes:
a) ( ) A equipe de engenharia corrige o erro, assim, uma nova versão do jogo

é criada e novos testes são realizados, para identificar que o erro foi
corrigido.
b) ( ) A equipe de engenharia corrige o erro, mas não cria uma nova versão
corrigida.
c) ( ) A equipe de engenharia agrupa os erros, para que depois seja aplicado
novos testes, para identificar que o erro foi corrigido.
d) ( ) A equipe de engenharia arruma o erro encontrado pela equipe de QA,
mas não cria uma nova versão, e fica no aguardo da identificação de
novos erros.
2 O TDD (Test Driven Development) – Desenvolvimento Orientado por Testes, é

um método utilizado atualmente por muitas equipes, para reduzir os custos
de desenvolvimento e o retrabalho na criação dos códigos dos softwares.
Este método é desenvolvido conforme o ciclo TDD. Sobre as etapas do ciclo
de TDD, assinale a alternativa CORRETA:
a) ( ) [1] O teste é escrito para que passe; [2] O código é escrito para que
funcione; [3] A redundância é eliminada.
b) ( ) [1] O teste é escrito para que passe; [2] O código é escrito para que
falhe; [3] A redundância é identificada.
c) ( ) [1] O teste é escrito para que falhe; [2] O código é escrito para que
funcione; [3] A redundância é eliminada.
d) ( ) [1] O teste é escrito para que falhe; [2] O código é escrito para que falhe;
[3] A redundância é eliminada.
3 Aprender com a experiência é algo que ocorre em todos os lugares e em

tudo que fazemos. No desenvolvimento de jogos, as experiências que temos
e o que aprendemos podem servir de base para futuros projetos. O post-
mordem é uma boa prática para identificar o que foi aprendido, classifique
V para as sentenças verdadeiras e F para as falsas:
( ) Apresenta dos pontos positivos e negativos identificados por toda a

equipe.
( ) Pode-se criar um relatório com a análise dos processos de produção, os
elementos aprendidos, as revisões, as falhas, os métodos utilizados, as
tecnologias e recursos usados etc.
152
( ) Apenas os líderes das equipes que são os responsáveis por identificar os
pontos negativos e positivos da produção.
Assinale a alternativa que apresenta a sequência CORRETA:
a) ( ) V – F – F.
b) ( ) V – F – V.
c) ( ) F – V – F.
d) ( ) V – V – F.
4 Depois de corrigido e criada uma versão do jogo, o código pode ser liberado.
Disserte sobre o processo de liberação do código.
5 Na pós-produção, são poucas atividades a serem realizadas pelas equipes.

Em alguns casos, essa fase passa despercebida, ou seja, o projeto nunca
é encerrado pela equipe. Neste contexto, disserte sobre as atividades de
plano de arquivamento e aprender com a experiência.
153
REFERÊNCIAS
AFONSO, F. M. Critérios para Adoção de Soluções de Desenvolvimento
Multiplataforma Móvel na Perspectiva de Desenvolvedores de Software. 2020.
Disponível em:https://repositorio.ufscar.br/handle/ufscar/13266. Acesso em: 21
jul. 2021.
AZEVEDO, E. Design Bible. 2009. Disponível em:https://pt.scribd.com/docu-

ment/85688341/Design-Bible-Elinaldo-Azevedo. Acesso em: 21 jul. 2021.
BALDWIN, M. Games design document outline. 2005. Disponível em:http://ga-

mesed.baldwinconsulting.org/files/Baldwin_Game_Design_Document_Templa-
te.doc. Acesso em: 21 jul. 2021.
BARATA, B. A. P. et al. Um jogo sério aplicado à saúde com foco em epide-

miologia: Apoena. 2020. Disponível em: https://www.researchgate.net/publica-
tion/340799872_Um_jogo_serio_aplicado_a_saude_com_foco_em_epidemiolo-
gia_Apoena. Acesso em: 21 jul. 2021.
BARCELOS, T. S. Proposta de game design de um jogo digital para o ensino

de Engenharia de Software. 2013. Disponível em: https://www.researchgate.
net/publication/259377773_Proposta_de_game_design_de_um_jogo_digital_pa-
ra_o_ensino_de_Engenharia_de_Software. Acesso em: 21 jul. 2021.
BRUN, J. A. Uma Ferramenta Para Automação do Processo de Software Pes-

soal. 2002. Disponível em: https://repositorio.ufsc.br/xmlui/bitstream/hand-
le/123456789/82614/189734.pdf. Acesso em: 21 jul. 2021.
CAMARGO, R. Entenda o que é PMBOK: o guia que vai dar um up na sua car-
reira. 2019. Disponível em: https://robsoncamargo.com.br/blog/PMBOK. Acesso
em: 21 jul. 2021.
CAMPOS, E. L. de. Interseções dos Papéis no Scrum. 2021. Disponível em:

https://blog.myscrumhalf.com/intersecoes-dos-papeis-no-scrum/. Acesso em: 21
jul. 2021.
CAVACO, M. Programação de jogos: Dicas e sugestões para criar jogos. 2007.

Disponível em: https://pdfcoffee.com/desenvolvimento-de-jogos-pdf-free.html.
CHANDLER, H. M. Manual de Produção de Jogos Digitais. 2ª ed. Porto Ale-

gre, Bookman, 2012.
CHANDLER, H. M. The Game Production Toolbox. CRC PressTaylor & Francis

Group: EUA, 2020.
154
COLOMBO, C. DESENVOLVIMENTO DE UM JOGO MULTIPLATAFORMA
UTILIZANDO CROSS PLATFORM TOOLKIT HAXE. 2017. Disponível em:
https://www.univates.br/bdu/handle/10737/1677. Acesso em: 30 jun. 2021.
COFFEE, R. Storyboard: por que ele é essencial para a sua estratégia de Marke-
ting Digital?. 2018. Disponível em: https://rockcontent.com/br/blog/storyboard/.
COPLE, D. G. D. Desenvolvimento de Jogos II. SESES: Rio de Janeiro, 2019.
CÔRTES, M. L. Modelos de Qualidade de SW. 1998. Disponível em: https://

www.ic.unicamp.br/~cortes/mc726/cap6.pdf. Acesso em: 21 jul. 2021.
CREDIDIO, D. de C. Metodologia de Design aplicada à concepção de jogos

digitais. 2007. Disponível em: https://repositorio.ufpe.br/handle/123456789/3415.
CRUZ, T. A. da. Gestão de design e desenvolvimento de jogos eletrônicos:

um estudo de caso das empresas da Grande Florianópolis. 2013. Disponível em:
https://repositorio.ufsc.br/bitstream/handle/123456789/107456/321225.pdf?se-
quence=1&isAllowed=y. Acesso em: 21 jul. 2021.
ESPINHA, R. G. Você realmente sabe o que é um projeto? Descubra o conceito,

os principais tipos e as fases de um projeto. 2021. Disponível em: https://artia.
com/blog/o-que-e-um-projeto/. Acesso em: 21 jul. 2021.
FLEURY, A. et al. I Censo da Indústria Brasileira de Jogos Digitais, com Voca-

bulário Técnico sobre a IBJD. 2014. Disponível em: http://www.abragames.org/
uploads/5/6/8/0/56805537/i_censo_da_industria_brasileira_de_jogos_digitais_2.
pdf. Acesso em: 29 jun. 2021.
GOMES, J. E. et al. Adoção de Metodologias Ágeis para Produção de Jogos So-

ciais com Times Distribuídos. 2011. Disponível em: http://www.sbgames.org/
sbgames2011/proceedings/sbgames/papers/comp/short/05-92290_2.pdf. Acesso
em: 21 jul. 2021.
HIRA, W. K. et al. Criação de um modelo conceitual para Documentação de

Game Design. 2016. Disponível em: http://www.sbgames.org/sbgames2016/
downloads/anais/157033.pdf. Acesso em: 21 jul. 2021.
HUMPHREY, W. S. The Personal Software Process (PSP). 2000. Disponível em:

https://resources.sei.cmu.edu/asset_files/TechnicalReport/2000_005_001_13751.
pdf. Acesso em: 21 jul. 2021.
LADEIRA, D. M. O processo de desenvolvimento de software focado na qua-

lidade pessoal. 2012. Disponível em: https://cepein.femanet.com.br/BDigital/
arqPics/1111320497P421.pdf. Acesso em: 21 jul. 2021.
155
LEITE, D. R. A. et al. GSPROJECTS - AMBIENTE PARA SIMULAÇÃO DA GES-
TÃO DE PROJETOS DE SOFTWARE. 2015. Disponível em: https://sol.sbc.org.br/
index.php/wei/article/view/10242/10114. Acesso em: 21 jul. 2021.
LEMES, D. de O. GAMES INDEPENDENTES: Fundamentos metodológicos

para criação, planejamento e desenvolvimento de jogos digitais. 2009. Disponí-
vel em: https://sapientia.pucsp.br/handle/handle/18241. Acesso em: 16 jul. 2021.
LIMA, A.; AYMONE, J. L. F. Práticas Ágeis Aplicadas ao Desenvolvimento de

Jogos Digitais. 2015. Disponível em: https://www.feevale.br/Comum/midias/
36624618-a871-4126-8ca3-dda9e924e086/Pr%C3%A1ticas%20%C3%81geis%20
Aplicadas%20ao%20Desenvolvimento.pdf. Acesso em: 21 jul. 2021.
LOURENÇON, G. et al. Scrum: O desenvolvimento ágil no desenvolvimento de

jogos. [s.d]. Disponível em: https://edisciplinas.usp.br/pluginfile.php/5751058/
mod_resource/content/1/Aula%2011%20-%20Scrum.pdf. Acesso em: 21 jul. 2021.
MARQUES, G. C. Introdução ao desenvolvimento de jogos digitais utilizando

o motor de jogo UDK. 2015.Disponível em: https://sapientia.pucsp.br/bitstream/
handle/18168/1/Gabriel%20Cavalcanti%20Marques.pdf. Acesso em: 21 jul. 2021.
MENEZES, J. T. Quais são as etapas de criação de um jogo?. 2015. Disponível

em: https://www.desenvolvendojogos.com/single-post/2015/06/05/quais-s%-
C3%A3o-as-etapas-de-cria%C3%A7%C3%A3o-de-um-jogo. Acesso em: 21 jul.
2021.

NEMITIZ NETO, W. L. F. Cristina: Uma ferramenta para transformar protóti-
pos de jogos em código reutilizável. 2015. Disponível em: http://dspace.unipam-
pa.edu.br:8080/jspui/handle/riu/886. Acesso em: 30 jun. 2021.
OLIVEIRA, F. N. de. Metodologias para Desenvolvimento de Jogos. 2018.

Disponível em: https://www.fabricadejogos.net/posts/metodologias-para-desen-
volvimento-de-jogos/. Acesso em: 11 jul. 2021.
PEREIRA, L. T.; LOPES, R. M. Produção de Jogos Digitais Da equipe aos pro-

dutos: como é feito um jogo? [s.d.]. Disponível em: https://edisciplinas.usp.br/
mod/resource/view.php?id=2703146. Acesso em: 21 jul. 2021.
PIRES, R. Aprenda a usar a técnica MoSCoW nos projetos da sua agência!.

2019. Disponível em: https://rockcontent.com/br/blog/metodo-moscow>. Acesso
em: 21 jul. 2021.
PONTES, M. B. Engenharia de Software - Introdução a Teste de Software. 2009.

Disponível em: http://www.devmedia.com.br/artigo-engenharia-de-software-in-
troducao-a-teste-de-software/8035. Acesso em: 21 jul. 2021.
156
RABIN, S. Introdução ao Desenvolvimento de Games. Vol 1. São Paulo. Cenga-
ge Learning, 2012.
RIBEIRO, T. H. Desenvolvimento de modelo para pré-produção de jogos

digitais baseado em métodos de design e processos de desenvolvimento
de jogos. 2016. Disponível em: https://repositorio.ufsc.br/bitstream/hand-
le/123456789/185474/PGDE0149-D.pdf?sequence=-1&isAllowed=y. Acesso em:
21 jul. 2021.
RICARDO, L. PSP – Personal Software Process. 2012. Disponível em: http://luizri-

cardo.org/2012/10/psp-personal-software-process/. Acesso em: 21 jul. 2021.
ROCHA, F. G. TDD: fundamentos do desenvolvimento orientado a testes. 2013.

Disponível em: https://www.devmedia.com.br/tdd-fundamentos-do-desenvol-
vimento-orientado-a-testes/28151. Acesso em: 21 jul. 2021.
ROCHA, R. V. da; ARAUJO, R. B. de. Metodologia de Design de Jogos Sérios

para Treinamento: Ciclo de vida de criação, desenvolvimento e produção da
Rocha. 2013. Disponível em: http://www.sbgames.org/sbgames2013/proceedin-
gs/artedesign/09-dt-paper.pdf. Acesso em: 21 jul. 2021.
ROGERS, S. Level Up!: The Guide to Great Video Game Design. Chichester:
John Wiley & Sons, 2010.
SABBAGN, R. Scrum: Gestão ágil para projetos de sucesso. São Paulo: Editora
Casa Do Código (Digital), 2014. Disponível em: https://www.google.com.br/
books/edition/Scrum/pG-CCwAAQBAJ?hl=pt-BR&gbpv=1&pg=PP1&printsec=-
frontcover. Acesso em: 21 jul. 2021.
SANTOS, V. F. M. dos. Aprenda a utilizar o Método MoSCoW em seus proje-

tos. 2018. Disponível em: https://www.fm2s.com.br/metodo-moscow/. Acesso
em: 21 jul. 2021.
SATO, A. K. O. Game Design e Prototipagem: Conceitos e Aplicações ao Longo

do Processo Projetual. 2010. Disponível em: http://www.sbgames.org/papers/
sbgames10/artanddesign/Full_A&D_10.pdf. Acesso em: 21 jul. 2021.
SCHUYTEMA, P. Design de games: uma abordagem prática. São Paulo, Cen-

gage Learning, 2008.
SENAC, R. S. GDD. Rede Fecomércio de Educação - RS. 2019. Disponível em:

https://www.senacrs.com.br/cursos_rede/planejamento_de_jogos_digitais_para_
multiplataformas/html/gdd/gdd/iframe/gdd.pdf. Acesso em: 05 jul. 2021.
SENAC, R. S. Metodologias de desenvolvimento de jogos. Planejamento de

jogos digitais para multiplataformas. Rede Fecomércio de Educação - RS. 2019b.
Disponível em: https://bit.ly/3B1vlrv. Acesso em: 05 jul. 2021.
157
SENAC, R. S. Projeto: conceito, tipologia, etapas, indicadores e aplicabilidade.
Gestão de Projetos. [s. d.]. Disponível em: https://www.senacrs.com.br/cursos_
rede/gestao_de_projetos/html/conteudo/projeto/index.html. Acesso em: 21 jul.
2021.
SCHELL, J. A arte de game design - O livro Original. Rio de Janeiro: Campus,

2010.
SICART, M. Defining Game Mechanics. 2008. Disponível em: http://gamestu-

dies.org/0802/articles/sicart. Acesso em: 21 jul. 2021.
SILVA, D. G. de M.; MORAIS, A. M. de; MORAIS, A. M. de. Análise comparati-

va de metodologias usadas no desenvolvimento de jogos digitais. 2018. Dispo-
nível em: https://editora.iesp.edu.br/index.php/UNIESP/catalog/view/9/5/25-1.
SOUEID, M.; ALVES, W. KANBAN NA PRÁTICA PARA GESTORES. [s.d.].

Disponível em: https://www.ciamakers.com/kanban.pdf. Acesso em: 21 jul. 2021.
SOUZA, I. de. Framework: descubra o que é, para que serve e por que você pre-
cisa de um para o seu site. 2019. Disponível em: https://rockcontent.com/br/blog/
framework/. Acesso em: 21 jul. 2021.
TECHLISE. TUDO O QUE VOCÊ PRECISA SABER SOBRE TDD. 2021. Dis-
ponível em: https://www.techlise.com.br/blog/tudo-o-que-voce-precisa-saber-
-sobre-tdd/. Acesso em: 21 jul. 2021.
VELASQUEZ, C. E. L. Modelo de Engenharia de Software para o Desenvolvi-

mento de Jogos e Simulações Interactivas. 2009. Disponível em: https://bdigital.
ufp.pt/bitstream/10284/1361/2/DM_CarlosVelasquez.pdf. Acesso em: 9 jul. 2021.
158
UNIDADE 3 —
DOCUMENTAÇÃO
E DESENVOLVIMENTO DE JOGOS
MOBILE
• identificar a importância do kit de fechamento do jogo;

• conhecer um exemplo de estrutura do kit de fechamento;
• aprender aspectos do desenvolvimento multiplataforma no ambiente
Unity;
• conhecer as características do Unity;
• aprender os elementos essenciais para o desenvolvimento de jogo.
PLANO DE ESTUDOS
apresentado.
TÓPICO 1 – KITS DE FECHAMENTO
TÓPICO 2 – DESENVOLVIMENTO DE JOGOS NO ANDROID
TÓPICO 3 – DESENVOLVIMENTO DE JOGOS PARA IOS
CHAMADA

159
160
UNIDADE 3
TÓPICO 1 —
KITS DE FECHAMENTO
1 INTRODUÇÃO
Caro acadêmico! Bem-vindo à Unidade 3! Na última unidade desse livro,
iremos conhecer sobre os Kits de Fechamento e o desenvolvimento de jogos para
sistema Android e para sistema IoS.
No Tópico 1, abordaremos sobre Kits de Fechamento, onde conheceremos

o que deverá ser incluído do kit. Vale ressaltar que no Kit de Fechamento deve
conter tudo o que foi desenvolvido nas quatro fases do projeto. Em seguida,
iremos explorar o desenvolvimento de jogos para sistemas Android. Iniciaremos
com a instalação do software Unity e conheceremos como um jogo é desenvolvido
utilizando este ambiente de desenvolvimento. Por último, conheceremos sobre
o desenvolvimento de jogos para sistemas IoS, onde iremos explorar como é o
desenvolvimento para este tipo de sistema operacional de dispositivo móvel.
Vamos começar a nossa última jornada, padawan! Bons estudos!
2 DEFINIÇÃO DOS KITS DE FECHAMENTO

Como vimos na Unidade 2, os Kits de Fechamento devem conter tudo o
que for desenvolvido ao longo da produção do jogo, e neste sentido, este kit poderá
ser utilizado para criar novas versões do jogo, atualizações, assim como servir de
uma base de consulta para o que já foi desenvolvido. Chandler (2012, p. 14) diz
que devemos “preparar um kit de fechamento para projetos futuros e examinar os
prós e contras de sua recente experiência de desenvolvimento de um jogo” .

O kit de fechamento é uma tarefa essencial para que o jogo seja arquivado
e futuramente consultado. Chandler (2009, p. 391) afirma que:
Após a pós-produção, uma tarefa importante é organizar todos

ativos dos jogos e código-fonte em um kit de fechamento e arquive-o
para referências futuras. Os arquivos são necessários se houver
necessidade de remasterizar o jogo, crie uma versão ou atualização
de conteúdo, transformar o jogo para outra plataforma, lançar o jogo
em outro idioma, desenvolva uma sequência ou qualquer outro tipo
de conteúdo isso exigirá os ativos, código e ferramentas originais do
jogo. Os editores podem enviar kits de fechamento para distribuidores
que desenvolverão versões localizadas do jogo para distribuição em
outros países.
161
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
No kit, além de todos os artefatos desenvolvidos, pode-se incluir o

relatório de lições aprendidas da equipe e o documento de post-mortem criado.
Esses dois documentos podem possibilitar que futuros desenvolvimentos sejam
realizados de maneira mais tranquila, sem a ocorrência de tantos erros, uma vez
que utiliza as boas práticas de projetos anteriores.
O kit de fechamento é criado após o projeto ser concluído, ou seja, tudo

o que foi planejado foi desenvolvido, os erros encontrados e corrigidos, os
documentos e relatórios entregues e validados. Com isso, o jogo irá se lançado e
seu código liberado para quem irá distribuir, seja em mídia física como em disco
ou digital.
Após o jogo ter seu código liberado, ele será arquivado para uso em
projetos futuros.
Isso é feito com a criação de um kit de fechamento. Esse kit contém
toda a documentação de design, o código-fonte, o arquivo-fonte da
arte, os assets finais do jogo, os arquivos finais de música e tudo o mais
que foi usado na criação do jogo.
Os kits de fechamento são necessários porque o publicador pode querer
criar uma versão especial do jogo a ser instalada em um componente
de hardware ou a equipe de desenvolvimento pode querer reutilizar o
código ou os assets em outro projeto (CHANDLER, 2012. p. 15).
A mesma prática do kit de fechamento é utilizada quando o jogo será

distribuído por terceiros em um idioma diferente ao qual ele foi desenvolvido.
Chandler (2020, p. 231) identifica esse processo de Localização, sendo normalmente
realizado quando o jogo irá ser lançado. Sendo assim, a “localização é o processo
de modificação de um jogo à venda em outros países. Como isso pode representar
mais de 50% do total de vendas, os mercados internacionais não são algo a ser
ignorado”. Por meio deste kit, a nova equipe irá adaptar e traduzir o jogo para
o idioma do país, além de poder ser modificado caso seja necessário, por uma
questão legal ou cultural do país.
3 CRIANDO OS KITS DE FECHAMENTO

O Kit de Fechamento deve conter o que foi desenvolvido. Com isso, além
dos artefatos, aconselha-se incluir os relatórios individuais de cada equipe, assim,
quem consultar e utilizar esses documentos e artefatos pode entender melhor
como foi todo o desenvolvimento, não deixando lacunas ou entendimentos
errados com relação ao que foi desenvolvido. Lembrando que o Kit de Fechamento
pode ser digital, ou seja, disponibilizado em uma base de conhecimento ou site
de compartilhamento de projetos. Com isso, toda a documentação será de fácil
consulta, o que não ocorre em centenas de páginas impressas.

Uma ideia é incluir no Kit de Fechamento um Short Game Design Document
(ShGDD), que é um documento de Game Design resumido, sendo que este tipo
é normalmente utilizado em instituições de ensino, pois com ele é possível
162
TÓPICO 1 — KITS DE FECHAMENTO
apresentar uma documentação resumida, incorporando elementos da gestão de

projeto (LLAGOSTERA, 2016). A Figura 1 demonstra um exemplo de ShGDD. Ao
utilizá-lo no kit, quem irá ler e conhecer o projeto poderá ter uma ideia geral do
que foi desenvolvido sem ter que ler ou acessar todo o kit. Devido ao ShGDD ser
um documento simples, com apenas uma página, todas as principais informações
do jogos devem ser descritas neste documento.

FIGURA 1 – EXEMPLO DE SHGDD
FONTE: <http://puccjogos.github.io/proj1-2016-2s/imgs/sgdd.PNG>. Acesso em: 21 ago. 2021.
163
O ShGDD inicia com o título do jogo, em sequência, o nome da equipe

desenvolvedora. A história do jogo deve ser descrita de forma resumida, buscando
sintetizar o jogo em um parágrafo. Em seguida, o jogo deve ser descrito, ou seja,
informado como ele será jogado, as fases, os comportamentos. Após o jogo, pode-
se criar uma tabela similar à apresentada pela Figura 1, contendo os campos de
Arte, Programação e Áudio e as respectivas ações de cada campo. Utilizando um
esquema de cores, podemos relacionar os elementos dos campos com a descrição
do jogo.

Os kits de fechamento devem incluir os ativos finais e o código-fonte do
jogo. O kit deve ser composto pelos assets (ativos), a documentação, as ferramentas
e o código-fonte (CHANDLER, 2009). Caso após a conclusão do kit novos recursos
sejam criados, seja para novas versões, novos idiomas ou correções, eles devem
ser arquivados juntos do com o kit original. Com isso, esse novo material não é
perdido e simplifica a localização de tudo o que foi desenvolvido.

Para Cohen e Bustamante II (2010), o kit de fechamento é o momento de
arquivar o que foi desenvolvido.
A equipe acabou e provavelmente está procurando o próximo projeto.

A única coisa que resta a ver com o código do jogo agora é arquivá-lo.
O arquivamento é melhor descrito como montar o jogo para que
ele seja armazenado em um local seguro, para que, se você precisar
recuperá-lo, tenha um lugar para desenhar o jogo. Isso precisa ser
feito com muito cuidado e eficiência, caso o código fonte do jogo seja
necessário novamente. Um jogo arquivado é uma versão oficial do
título que representa o culminar do que foi desenvolvido e enviado.
Além de arquivar o código, você deseja incluir toda a arte, áudio,
design e qualquer outro elemento ou ativo de cada estágio do
desenvolvimento (COHEN, BUSTAMANTE II, 2010. p. 271).
Ao organizar o conteúdo do kit de fechamento, toda a equipe pode auxiliar

na sua elaboração. Assim, essa função não fica sob a responsabilidade de um único
profissional, que normalmente é o produtor. Ao criar um kit com toda a equipe,
o mesmo padrão de organização dos recursos deve ser seguido. Outra opção é a
utilização de uma base de dados compartilhada, a qual poderá ser utilizada ao
longo do projeto para armazenar os recursos que serão desenvolvidos.
3.1 ASSETS
Os assets são todos os ativos que foram desenvolvidos, ou seja, as imagens
(personagens, cenários, e demais elementos gráficos), textos, áudios (músicas,
efeitos sonoros, sons), os quais devem serem inclusos no kit de fechamento. Devem
ser inclusos todos os arquivos e, em especial, os arquivos originais, pois eles
podem ser úteis caso seja necessário realizar alterações futuras, e quando o jogo é
modificado para criar versões localizadas (quando o jogo é traduzido para outro
idioma) (CHANDLER, 2009). Cohen e Bustamante II (2010, p. 77) afirmam que
164
“todos os ativos do desenvolvedor são entregues ao editor juntamente com kits

de teste e desenvolvimento e qualquer equipamento de propriedade do editor”,
para que sejam inclusos no kit de fechamento e posteriormente arquivados. No
Quadro 1, são listados os ativos que devem ser inclusos no kit de fechamento.
QUADRO 1 – LISTA DE ASSETS
Tipo de Ativo Ativos

Ativos de texto do jogo em todos os idiomas criados
Arquivo de ajuda e manual
Ativos de texto
Mensagens (palavras-chaves) de instalação
Mensagens de erros
Arquivos de áudio não compactados em todos os
idiomas criados
Ativos de Narração e roteiros cinematográficos
Narração Elenco de notas
Especificações técnicas de narração
Planilha mestre de narração
Ativos de arte final
Ativos de Arte Arquivos de origem para todos os ativos de arte,
incluindo os logotipos
Cinematográficas finais no jogo
Codecs de vídeo e players de filmes
Ativos Cinematografia não compactada
Cinematográficos Arquivos de origem cinematográfica
Faixas de áudio separadas e não compactadas para
efeitos de música, narração e som
Texto traduzido
Ativos de
Arquivos de narração traduzidos (versões compactadas
Localização
e não compactadas)
(se aplicável)
Glossários de localização
Inclua o layout e os ativos de origem da caixa, manual e
outras peças de papel, incluindo:
Ativos de Layout da caixa (e todos os arquivos de origem)
Embalagem Layout manual (e todos os arquivos de origem)
Capturas de tela não compactadas usadas em
embalagens
FONTE: Adaptado de Chandler (2013).
165
3.2 FERRAMENTAS
Devem ser incluídas no kit de fechamento todas as ferramentas (softwares)
que foram utilizados no decorrer do desenvolvimento, isso inclui também os
plugins utilizados. Também devem ser inseridos no relatório de ferramentas a
versão utilizada (CHANDLER, 2009), e, se possível, incluir no kit os softwares
utilizados ou seu instalador. Com isso, outras pessoas que venham a conhecer
o projeto não terão que pesquisar o software. Vale ressaltar que no decorrer do
desenvolvimento do jogo vários softwares são utilizados, como afirma Novak
(2017, p. 327): “a equipe de desenvolvimento do game utiliza diversas ferramentas
em cada fase do desenvolvimento para planejar, orçar, agendar, criar e testar
games”.
As ferramentas que devem ser incluídas nos kit são:
• Plugins que aumentam o software de terceiros;

• Ferramentas proprietárias criadas pela equipe de desenvolvimento;
• Ferramentas de localização (se aplicável), que são utilizadas para integrar
traduções (CHANDLER, 2009).
3.3 CÓDIGO DO JOGO

O código-fonte do jogo é o elemento obrigatório que deve estar incluso
no kit de fechamento. Chandler (2009, p. 268) afirma que “se o código-fonte for
ausente, não será possível criar patches, atualizações de conteúdo ou portos do
jogo”.
Fleury et al. (2014) definem o código do jogo:
Designa o código de programação do jogo – sendo sempre uma

determinada linguagem de programação. O código do jogo designa
as linhas de codificação que foram produzidas para o jogo. Muitas
vezes o código é segmentado em componentes que cuidam de áreas
específicas, com o HUD (Interface com o usuário), a IA do jogo, a
interação com as personagens etc. (FLEURY et al., 2014, p. 98).
Devem ser inclusos no kit de fechamento os ativos de códigos, sendo eles:
• Mestres de ouro, que é necessário para todas as versões do jogo.

• Como deve ser compilado o jogo, essa informação pode ser incluída em um
relatório sobre o código-fonte.
• O código-fonte deve ser incluído, para que, caso seja necessário realizar
modificações, uma sequência do jogo ou em um novo projeto, possa ser
utilizar assim evita-se o retrabalho (CHANDLER, 2009).
166
DICAS
Irish (2005, p. 179) afirma que “os programadores não gostam de aprender o
código de outras pessoas. Quando se depara com a opção de modificar o código de outra
pessoa e criar um plug-in ou criar uma ferramenta do zero, é comum que os programadores
optem pelo último”.
3.4 DOCUMENTAÇÃO
Deve ser incluída no kit de fechamento qualquer documentação criada
no decorrer do desenvolvimento do jogo, ou seja, o kit de fechamento deve
conter todos os documentos criados de design, ferramentas, técnicos e todas as
informações gerais criadas, anotadas no desenvolvimento (CHANDLER, 2013).
Segundo Irish (2005, p. 307), “a documentação final do projeto contém todas as
atualizações necessárias à lista de elementos do motor, bem como o design técnico
completo para apoiar todos os recursos planejados do jogo”.
A documentação é essencial, pois é através dela que são fornecidas

“todas as informações necessárias para como usar o kit de fechamento e detalhes
onde todos os ativos estão localizados. Na raiz do primeiro disco, inclua uma
tabela de conteúdos que detalha tudo no kit de fechamento. O conteúdo deve
incluir descrições da pasta principal e subpastas” (CHANDLER, 2013, p. 268).
Devem ser incluídos no kit de fechamento os seguintes itens, conforme o tipo de
documentação criada, como indicado no Quadro 2.
167
QUADRO 2 – TIPOS DE DOCUMENTAÇÃO
Tipos de
Itens a serem incluídos
Documentação
• Documentos de design principais
Documentação do • Gráfico de fluxo descrevendo a interface do usuário
jogo • Trapaças e passo a passo
• Planos de teste
• A visão geral do pipeline de produção detalha como

converter os arquivos de origem no formato usado
pelo jogo.
• As instruções para fazer criam detalhes sobre como
configurar o ambiente de desenvolvimento e o
processo para compilar a compilação.
• A lista de requisitos de software identifica qualquer
software comercial ou proprietário necessário
Diretrizes técnicas para configurar um pipeline de produção em
funcionamento.
• A lista de requisitos de hardware identifica o hardware
necessário para o desenvolvimento, incluindo kits de
desenvolvimento de console e informações sobre o
SDK usado para compilar o jogo.
• As instruções para ferramentas proprietárias
incluem como instalar e usar as ferramentas (se
algum tutorial foi criado, inclua-o também).
• As informações gerais do produto fornecem uma
visão geral do jogo, como plataforma, idiomas e
informações de licenciamento.
• Certifique-se de que alguém está listado como um
Informações
ponto de contato, caso haja alguma dúvida sobre o
gerais do jogo
conteúdo do kit de fechamento.
• Uma lista de bugs abertos e outros problemas
conhecidos também é útil, caso haja planos para um
patch ou atualização.
Esses documentos do jogo são essenciais para que sejam criados novos
conteúdos para o jogo, atualizações e novas versões. Já as diretrizes técnicas nos
fornecem informações sobre a integração dos ativos com o código do jogo, como
devem ser convertidos os ativos, os formatos de arquivos utilizados, além de
especificações de sobre os hardwares e softwares utilizados. Esses documentos
devem serem escritos utilizando uma linguagem clara e de fácil entendimento
(CHANDLER, 2009).
168
4 ORGANIZAÇÃO DO CONTEÚDO
Os arquivos do kit de fechamento devem ser organizados em pastas
separadas. A Figura 2 demonstra como podemos fazer um arquivo de kit de
fechamento organizado. Para isso, um arquivo raiz é criado com o nome do jogo
e são criadas subpastas com os nomes descritivos para que os ativos fiquem
organizados. Caso a documentação for extensa, inclua um documento com um
índice com o caminho de cada parte do kit (CHANDLER, 2013).
FIGURA 2 – ESTRUTURA DE PASTAS DO KIT DE FECHAMENTO
FONTE: Adaptado de CHANDLER (2013).
O exemplo de organização do kit por pastas, é útil para quando é necessário

acessar as informações do desenvolvimento. Para Cohen e Bustamante II (2010), o
kit de fechamento deve conter os seguintes itens:
● Última versão do jogo, normalmente a versão que foi enviada para

as lojas (Release To Manufacture, RTM).
● O código completo do jogo, conhecido como código fonte.
● Documentação: deve incluir o último relatório de bugs e certificação
de controle de qualidade, listas de verificação legais que certificam que
o jogo foi comprovado por sua equipe jurídica, TCRs e TRCs, último
relatório de tecnologia, certificação ESRB e certificações de primeiro
editor.
● Discos de localização: devem incluir versões localizadas do jogo,
cada território é construído em discos separados, juntamente com
todos os elementos do kit de localização.
● Uma explicação detalhada do jogo.
● Toda documentação, contrato, aprovação, ativo e correspondência
pertinente relacionada ao jogo. Basicamente, todos os elementos e
materiais relacionados (COHEN; BUSTAMANTE II, 2010, p. 271).
Após concluído o kit de fechamento, Chandler (2013) recomenda que seja

convidado um desenvolvedor externo à equipe para que venha reconstruir o jogo
e criar uma versão de ouro dele.
169
Essa é uma boa maneira de encontrar erros nas direções ou descobrir

quaisquer ativos que estejam faltando. Se os kits não forem verificados
antes de enviá-los para fornecedores terceirizados, a equipe de
produção original pode precisar gastar algum tempo solucionando
problemas com o kit de fechamento, afastando assim suas outras
tarefas de desenvolvimento (alguns membros da equipe já podem
estar trabalhando em novos jogos ou em uma empresa diferente)
(CHANDLER, 2013, p. 397).
Cohen e Bustamante II (2010) afirmam que depois de criado o kit, deve-se

realizar cópias dele, pois caso ocorra algum problema com um dos kits teremos
seu backup. Essas cópias devem ser armazenadas em local seguro. Em grandes
organizações, são armazenadas em cofres à prova de fogo, além de outras cópias
estarem armazenadas em outros lugares, sendo estas utilizadas para acessar o
conteúdo. Além das cópias armazenadas em cofre e outros locais, Chandler (2013)
ressalta que devem ser criadas cópias em vários sites. Uma cópia do kit deve ficar
com o desenvolvedor, outra arquivada e a terceira cópia enviada para que seja
armazenada em um ambiente externo. Para isso, devem ser utilizados discos ou
mídias portáteis, como HD externo ou pen drives. As mídias devem conter um
rótulo com as seguintes informações:
• Nome do jogo.
• Versão.
• Plataforma alvo.
• Data de criação.
• Número da mídia ou volume (se aplicável).
• Descrição do conteúdo (CHANDLER, 2013).
Para auxiliar o desenvolvimento e organização do kit de fechamento,

Chandler (2013), desenvolveu um checklist. Essa lista contém os itens gerais a
serem inclusos no kit, conforme podemos observar no Quadro 3. “A primeira
seção lista toda a documentação a incluir no kit. Na seção seguinte, os ativos
necessários para o jogo estão listados. A última seção inclui algumas perguntas
úteis para responder antes de completar o kit, a fim de garantir que todos os itens
necessários sejam incluídos” (CHANDLER, 2009, p. 397).
170
QUADRO 3 – LISTA DE VERIFICAÇÃO DO KIT DE FECHAMENTO
DOCUMENTAÇÃO S/N ANOTAÇÕES

Conteúdo do kit de fechamento (na raiz do primeiro
CD no kit de fechamento)
Documentação de projeto, incluindo: Design
Documentos
Trapaças e orientações
Fluxograma da interface do usuário
Plano de teste
Documentação técnica, incluindo:
Instruções sobre como fazer compilações (incluindo
versões localizadas)
Visão geral do oleoduto de produção
Requisitos de software (incluindo números de versão)
Requisitos de hardware
Instruções para ferramentas proprietárias
Informações gerais sobre o produto, incluindo:
Informações do jogo (plataforma, idiomas)
Informações de contato
Lista de bugs conhecidos
ATIVOS DO JOGO S/N ANOTAÇÕES
Texto
Ativos de origem para todos os arquivos de texto do
jogo
Lista de verificação para todos os arquivos de texto do
jogo
Locução
Arquivos VO não compactados para todo o áudio do
jogo
Mestre de narração
Elenco de notas
Especificações técnicas para narração
Arquivos VO finais no jogo para todo o áudio
Lista de verificação para todos os arquivos VO do jogo
Arte
Todos os ativos de origem para arte no jogo
Arquivos de origem para logo das artes
Lista de verificação para todos os ativos de arte do jogo
Cinemática
Arquivos de origem cinematográfica não compactados
- Não compactados
cinematografia
Cinema final compactado no jogo
Codecs e cineastas usados para cinemas
171
Trilha de áudio (música não compactada, efeitos

sonoros e narração ativada)
Faixas separadas
Mix de áudio final
Lista de verificação para cinemas
Localização
Glossários
Embalagem
Arquivos de origem para o layout da embalagem
Arquivos de origem para layout manual
Capturas de tela não compactadas (incl. versões
localizadas)
Lista de verificação para caixa e documentos a serem
localizados
ATIVOS DO CÓDIGO S/N ANOTAÇÕES
Mestre de ouro duplica
Código fonte do jogo
Ferramentas código fonte
Arquivos do instalador
FERRAMENTAS S/N ANOTAÇÕES
Plug-ins usados com software de terceiros (inclua
especificações de software)
Ferramentas proprietárias (incluindo código fonte)
Ferramentas de localização (incluindo código fonte)
OUTRAS PERGUNTAS S/N ANOTAÇÕES
O conteúdo do kit de fechamento está claramente
rotulado?
As direções são claras e fáceis de entender?
O kit foi verificado por vírus?
O kit está faltando em qualquer arquivo?
O kit contém arquivos extras?
O kit contém versão atual de todos os ativos?
São discos rotulados com nome do jogo, número da
versão, plataforma, data e disco número?
O kit foi verificado por alguém fora da equipe de
desenvolvimento?
São cópias do kit arquivadas no local e fora do local?
Criar o kit de fechamento irá levar um tempo, é uma atividade que irá
demandar tempo, paciência e organização, uma vez que será necessário coletar
todos os ativos, organizá-los e escrever sua documentação. É claro que o kit pode
ser criado coletivamente por toda a equipe, porém, é importante que seja revisado
pelo produtor ou líder do fechamento.
172
RESUMO DO TÓPICO 1
• Os kits de fechamento podem ser utilizados na atualização do jogo, criação de

novas versões e em suas traduções, sendo que em alguns projetos sua criação
é ignorada.
• Um Short Game Design Document (ShGDD) pode ser utilizado para apresentar
o kit de fechamento, uma vez que ele é um resumo de toda a documentação
do jogo.
• Todos os Assets que foram desenvolvidos para o jogo devem ser incluídos no
kit, assim como a identificação de ambientes de desenvolvimento e plugins
utilizados ao longo do projeto.
• A documentação do jogo pode ser desenvolvida ao longo do desenvolvimento

e deve ser inclusa no kit os tipos de documentação: do jogo, as diretrizes
técnicas e informações gerais sobre o jogo.
• O kit deve ser organizado em uma estrutura de pastas, e depois de concluído,

devem ser criadas três cópias, as quais devem estar em locais/regiões
diferentes.
• O arquivamento do kit garante que, caso seja necessário utilizar o projeto do

jogo, ele possa ser recriado. Por isso, é fundamental que a criação do kit de
fechamento seja realizada com cuidado.
• As ferramentas utilizadas, ou seja, os ambientes de desenvolvimento

que foram utilizados, devem ser inclusos no kit, assim, podemos criar um
documento de texto com os endereços das ferramentas, a versão utilizada, e,
se possível, incluir o seu instalador no kit.
173
AUTOATIVIDADE
1 O kit de fechamento é utilizado após a conclusão da produção do jogo. Ele

pode ser construído ao longo do desenvolvimento do jogo, ou seja, desde
a fase de pré-produção. Sobre a utilização após o kit de fechamento ser
concluído, assinale a alternativa CORRETA:
a) ( ) Pode-se ser utilizado o Kit para atualizar, modificar, lançar em outro

idioma o jogo.
b) ( ) Pode-se ser utilizado o Kit para apenas lançar em outro idioma.
c) ( ) Pode-se ser utilizado apenas como um arquivo do que foi criado.
d) ( ) O kit de fechamento não tem nenhuma utilidade futura para o jogo.
2 Os assets correspondem a tudo o que foi desenvolvido para que o jogo

ganhe vida. Eles podem ser utilizados para editar as informações para
outro idioma, por exemplo. Sobre os assets, assinale a alterativa CORRETA
que representa todos os tipos que podemos ter ao se criar um jogo.
a) ( ) Apenas as versões das Imagens, Textos, Gráficos, Áudios utilizadas no

jogo.
b) ( ) Arquivos em baixa qualidade dos Imagens, Textos, Gráficos, Áudios.
c) ( ) Arquivos originais e adaptados das Imagens, Textos, Gráficos, Áudios.
d) ( ) Não há necessidade de incluir os arquivos de Imagens, Textos, Gráficos,
Áudios.
3 A documentação do jogo deve reunir todas as informações sobre ele e como

foi seu desenvolvimento. Ela poderá guiar outros projetos, assim como
auxiliar na melhoria do jogo em futuras versões. Sobre os itens obrigatórios
da documentação do jogo, assinale a alternativa CORRETA:
a) ( ) Visão geral do pipeline, Passo a passo do jogo, Gráfico do fluxo e a

descrição da interface do usuário, documentação de design principais.
b) ( ) Planos de teste, Passo a passo do jogo, Lista de requisitos, instruções da
ferramentas, Gráfico do fluxo e a descrição da interface do usuário.
c) ( ) Visão geral do pipeline, Informações gerais sobre o produto, Gráfico
do fluxo e a descrição da interface do usuário, documentação de design
principais.
d) ( ) Planos de teste, Passo a passo do jogo, Gráfico do fluxo e a descrição da
interface do usuário, documentação de design principais.
4 A organização do kit é uma atividade extensa, uma vez que deve ser incluso
tudo o que foi desenvolvido na concepção do jogo. Disserte como podemos
realizar a organização dos kits de fechamento.
174
5 O kit de fechamento depois de concluído deve ser salvo em três cópias, eles
devem ser identificados, com o nome do jogo, a versão, a plataforma alvo,
a data em que foi criado, o número do volume e uma descrição sucinta do
conteúdo. Disserte sobre a importância da criação das três cópias do kit de
fechamento.
175
176
UNIDADE 3
TÓPICO 2 —
DESENVOLVIMENTO DE JOGOS NO ANDROID
1 INTRODUÇÃO
Querido acadêmico! Seja bem-vindo ao segundo tópico!
Os jogos estão presentes em várias plataformas. Entre as mais populares,

estão os dispositivos móveis, mas também é possível encontrar Smart TVs com a
possibilidade de incluir jogos. Graças à simplicidade de baixar e instalar jogos
nos smartphones e tablets com sistema operacional (SO) Android, cada vez mais
novos jogos são desenvolvidos, o que torna o mercado de desenvolvimento de
jogos competitivo. Todavia, não são apenas novidades que encontramos para
baixar. Muitos jogos clássicos foram atualizados e modificados e vem atraindo
um novo público, assim como os antigos jogadores. A utilização de jogos em
sistemas Android vem tornando a experiência dos jogadores cada vez melhor,
principalmente devido à esse sistema ser sempre sendo atualizado, além das
empresas desenvolveras desses hardwares (dispositivos) anualmente incluírem
cada vez mais funcionalidades e recursos para que os desenvolvedores possam
explorar o desenvolvimento dos seus jogos.
NTE
INTERESSA
Quer conhecer mais sobre a história e a evolução do sistema Android? Acesse

o seguinte link: https://mymob.com.br/blog/historia-do-android.html.
Segundo o Censo da Indústria Brasileira de Jogos Digitais realizado em

2014, o desenvolvimento de jogos para o sistema operacional Android é realizado
por 81% das empresas brasileiras, tendo com perspectiva que mais 29% da
indústria de jogos venha a desenvolver jogos para Android nos próximos 24
meses (FLEURY et al., 2014). Já no II Censo, realizado em 2018, foi identificado
que 59,2% das plataformas utilizadas pelos desenvolvedores são dispositivos
móveis (smatphone ou tablet), em seguida, os computadores, com 42,1% (SAKUDA;
FORTIM, 2018). Conforme podemos observar na Figura 3, os principais sistemas
operacionais de dispositivos móveis são Android, iOS e Windows, sendo estes o foco
das desenvolvedoras de jogos. Atualmente estima-se que a cada 10 brasileiros, 9
utilizem smartphones com sistema Android (CARDOSO, 2020).
177
FIGURA 3 – COMPARATIVO DE DESENVOLVIMENTO DE JOGOS CONFORME S.O.
FONTE: Adaptado de Fleury et al. (2014)
DICAS
A comparação entre as ferramentas de desenvolvimento multiplataforma é

um assunto sempre atual e recorrente. No artigo intitulado ‘Estudo Comparativo Sobre
Ferramentas de Desenvolvimento Multiplataforma para Aplicações Móveis’, os autores
exploram os softwares para o desenvolvimento de jogos. O artigo está disponível através do
link: https://www2.unicentro.br/decomp/files/2019/03/TCC-Gabriel-M%E3%80%95ler.pdf.
O desenvolvimento de jogos e aplicativos para Android pode ser utilizado

conforme identificado por Schmitz (2016, p. 20), “como opção de desenvolvimento
nativa para Android, o Google disponibiliza a ferramenta Android Studio, na qual
o desenvolvedor utiliza a linguagem de programação Java na escrita do código-
fonte, e a linguagem XML para definição do layout de interface do aplicativo”. No
entanto, outros softwares podem ser utilizados no desenvolvimento para Android,
Android Studio ou outros IDEs que permitam a utilização do Android

SDK (Software Development Kit) e do ADT (Android Development Tools).
O SDK contém as ferramentas básicas para o desenvolvimento do
aplicativo e o ADT estende a capacidade do SDK, dando suporte, por
exemplo, à criação da interface do usuário, criação rápida de novos
projetos, exportação do arquivo executável para a distribuição, entre
outras funções (BLANCO, 2020, p. 31).
Outra possibilidade de ferramentas de desenvolvimento são frameworks,

que são “(...) um conjunto cooperativo de classes que compõem um projeto
reutilizável para um domínio específico de softwares. (...) Um desenvolvedor
customiza o framework para uma aplicação específica utilizando instâncias das
classes do mesmo” (SCHAUKOSKI, 2018, p. 23). Os frameworks mais utilizados,
conforme apresentado a seguir, permitem que sejam desenvolvidos aplicativos
multiplataforma, o que torna o desenvolvimento mais tranquilo, uma vez que
poucas mudanças deverão ser realizadas. Os principais frameworks utilizado são
(ROSÁRIO, 2015):
178
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
• Cordova / PhoneGap.
• Ionic.
• Sencha Touch.
• Mono.
• Titanium Mobile.
• Adobe AIR.
Já a linguagem de programação utiliza no desenvolvimento para Android

o Java e o Kotlin, porém, é possível utilizar outras linguagens de programação ao
utilizar a ferramenta Basic4android (BLANCO, 2020).
No decorrer deste tópico, iremos abordar os elementos do desenvolvimento

de jogos para sistema Android, conheceremos o software Unity e seu processo de
instalação, seu Engine e ferramentas, como trabalhar os elementos, os níveis, além
de explorar a produção e física de animação, entre outros elementos que iremos
conhecer ao utilizar o software Unity. Lembrando que a maioria dos softwares de
desenvolvimento de jogos são semelhantes, assim, a maioria das ações que iremos
executar podem ser aplicadas em softwares concorrentes, por isso, é essencial que
você explore os demais software e escolha o seu melhor software para você utilizar
no desenvolvimento.
Bons estudos!
2 INSTALAÇÃO DO UNITY
O Unity é um software para o desenvolvimento de aplicativos e jogos 2D,
3D, Realidade Virtual (VR) e Realidade Aumentada (AR), que pode ser instalado
em sistemas operacionais Windows, Mac OS e Ubuntu. O Unity pode ser baixado
utilizando o link: https://unity3d.com/pt/get-unity/download.
O Unity é um dos softwares de desenvolvimento de jogos mais utilizado.

Kucera (2013) apresenta alguns aspectos que enfatiza a liderança na utilização
deste software:
Assim como toda game engine, ela facilita o desenvolvimento de jogos

pelo fato de o desenvolvedor não precisar programar diretamente
para DirectX ou OpenGL, pois ela já faz isso automaticamente. A Unity
pode fazer jogos para produtos da Apple (Mac, iPhone, iPod, iPad), da
Microsoft (Xbox, Windows), da Google (dispositivos com Android), da
Sony (Playstation 3), da Nintendo (Wii) e para navegadores Web (Internet
Explorer, Mozilla Firefox, Google Chrome, Opera e Safari).
Além dessa portabilidade, a Unity possui uma grande quantidade
de ferramentas e é muito fácil de trabalhar com ela, pois além de ser
visual (não apenas baseada em código como a Irrlicht, por exemplo) a
interface é bastante amigável (KUCERA, 2013, s. p.).
Após acessar o site da Unity, deve-se escolher a opção ‘Unity Hub’,

conforme identificado na figura 4.
179
FIGURA 4 – ESCOLHENDO INSTALADOR DO UNITY
FONTE: <https://unity3d.com/pt/get-unity/download>. Acesso em: 30 set. 2021.
Na sequência, o download do instalador será iniciado. O tempo de conclusão

do download pode várias conforme a conexão de Internet. Após concluído, deve-
se abrir o instalador. Será exibida uma tela similar ou igual à apresentada pela
figura 5, onde devemos concordar com os termos da licença do software. Ainda
não baixamos o Unity, mas sim o Unity Hub, que iremos utilizar para baixar o
Unity e que pode ser utilizado para organizar os projetos criados, acessar a área
de ensino e participar da comunidade de usuários.
FIGURA 5 – INSTALANDO DO UNITY - LICENÇA
FONTE: <https://bit.ly/2ZCbZMY>. Acesso em: 27 ago. 2021.
180
Após clicar em ‘Eu Concordo’, uma nova tela será exibida, conforme
ilustrado pela figura 6. Nesta fase, iremos escolher em qual o local que ficarão os
arquivos do Unity. Dependendo do sistema operacional do seu computador, o
instalador poderá sugerir um local, porém você poderá alterá-lo e escolher qual o
melhor local para armazenar os arquivos do programa.
FIGURA 6 – INSTALANDO DO UNITY – LOCAL DA INSTALAÇÃO
FONTE: <https://bit.ly/3bhSqMp>. Acesso em: 27 ago. 2021.
Uma vez instalado o Unity Hub, iremos realizar o download do Unity. Para
iniciar, iremos no tópico ‘Installs’ e em seguida, na opção ‘Add’, conforme ilustrado
pela figura 7. Após essas duas ações, uma tela sobressalente irá ser exibida.
FIGURA 7 – INSTALANDO DO UNITY – ADICIONANDO O UNITY
FONTE: <https://bit.ly/3nCJEy8>. Acesso em: 27 ago. 2021.
181
A figura 8 demonstra a tela sobressalente. Nela, iremos escolher a versão

do Unity que queremos instalar. Normalmente, são apresentas três opções da
versão estável (LTS) e outras versões futuras do Unity que estão disponíveis para
o usuário testar. Essas versões podem conter erros e falhas, por isso, opte por uma
versão do Unity estável. Após escolher a versão do Unity, deve-se clicar no botão
‘Next’ para avançar a instalação.
FIGURA 8 – INSTALANDO DO UNITY – ESCOLHENDO VERSÃO DO UNITY
FONTE: <https://bit.ly/3pLa8jK>. Acesso em: 27 ago. 2021.
Na sequência, você deverá escolher os suportes de criação dos seus jogos.

As opções apresentadas pela Figura 9 devem ser marcadas quando você realizar
sua instalação. Esses recursos serão úteis no momento de compilação do jogo, por
isso, deixe todas as opções do ‘Android Bluid Support’ (SPROVIERI, 2021). Após
marcar estas opções, clique no botão ‘Next’ para iniciar o download do Unity. Por
último, depois de instalado, você deverá abrí-lo. Uma mensagem sobre a licença
será exibida e você deverá acessar sua conta ou criar uma conta no Unity, sendo
que a versão Unity Personal é gratuita. Após escolher a versão, um arquivo será
gerado, o qual você deverá utilizar para ativar o Unity.
182
FIGURA 9 – INSTALANDO DO UNITY - RECURSOS
FONTE: <https://bit.ly/3msbxK8>. Acesso em: 27 ago. 2021.
2.1 TIPO DE GAMES

O Unity possibilita que sejam criando aplicativos, Realidade Aumentada
(AR), Realidade Virtual (VR) e jogos, que é nosso foco neste livro. No entanto,
cada vez mais vem sendo desenvolvidos jogos com Realidade Virtual e Realidade
Aumentada. Um exemplo amplamente conhecido de jogo em realidade
aumentada é o Pokémon Go, onde foram combinados a AR com a geolocalização
dos smartphones, o que tornou o jogo um sucesso (AGRELA, 2016).
No Unity é possível desenvolver jogos 2D e 3D, o qual conhecemos em

nossa primeira Unidade. Em jogos 2D usam gráficos planos, chamados de sprites,
e não possuem geometria tridimensional. Eles são desenhados nela como imagens
planas e a câmera (câmera ortográfica) não possui perspectiva. Por outro lado, os
jogos 3D “usam geometria tridimensional, com materiais e texturas renderizados
na superfície de GameObjects para tenham aparência de ambientes, personagens e
objetos sólidos que compõem o mundo do jogo” (UNITY, 2021c, s. p.).
Além desses dois tipos de jogos, uma versão híbrida, por assim dizer,
conhecida como 2.5D pode ser desenvolvida utilizando o Unity, pois
Alguns jogos 2D usam geometria 3D para o ambiente e personagens,

mas restringem a jogabilidade a duas dimensões, por exemplo, a
câmera pode mostrar uma vista de câmera lateral, mas o jogador só se
movimenta em duas dimensões. Para esse tipo de jogo, o efeito 3D tem
uma finalidade mais visual do que funcional.
Também há jogos que simulam geometria 3D e um eixo de
profundidade, mas usam uma câmera ortográfica em vez de uma
de perspectiva. É uma técnica comum que oferece ao jogador
vista panorâmica da ação do jogo e geralmente é chamada de vista
isométrica (UNITY, 2021c, s. p.).
183
NTE
INTERESSA
Neste vídeo você pode conhecer um exemplo de jogo em 2.5D. Para

acessar, utilize este link: https://bit.ly/3mofYFr.
No Unity você deve definir o tipo de jogo que irá desenvolver, ou seja, as
opções em 2D ou 3D, porém, é possível utilizar outras opções para se criar jogos,
assim como alterar o tipo do jogo, sem que tenhamos que começar do zero, o que
é muito útil para não perdermos tempo com retrabalho. Ao trocar o tipo de jogo,
algumas configurações podem ser modificadas, pois “a escolha entre começar
no modo 2D ou 3D determina algumas configurações para o Unity, como se as
imagens são importadas como texturas ou sprites e se a projeção da câmera é
ortográfica ou perspectiva” (UNITY, 2021c, s. p.).
3 ENGINE UNITY
Anteriormente já vimos alguns aspectos do Unity. Apesar de ser um
software proprietário, podemos utilizar sua versão gratuita para desenvolver
jogo, ou você, como aluno, pode ter um plano de estudante gratuito. A figura
10 demonstra os quatro tipos de licença, a licença Personal (Pessoal) é gratuita
e possui algumas limitações, mas é uma excelente para se iniciar no mundo do
desenvolvimento.
FIGURA 10 – TIPOS DE LICENÇA
FONTE: <https://store.unity.com/pt/compare-plans>. Acesso em: 6 out. 2021.
184
Criado em 2005, o Unity vem se sendo atualizado deste então e com o

passar do tempo novos recursos sendo adicionados, assim como vem se adaptando
conforme as mudanças tecnológicas para que seus usuários possam desenvolver
aplicativos e jogos com as linguagens e recursos mais avançados. Por conta disso,
é um dos motores de desenvolvimento de jogos (game engine) mais conhecidos e
utilizados. “O termo motor de desenvolvimento ou motor de jogo, refere-se a um
tipo específico de software que possui uma série de rotinas de programação que
permitem a projeção, criação e a operação de um ambiente interativo, ou seja, de
um videojogo, experiência digital ou filme/animação” (MASTER.D, 2021, s. p.).
O Unity tem como funcionalidades:
• O motor gráfico para renderização de gráficos 2D e 3D.

• O motor de física, que visa simular as interações entre os objetos.
• Sistema de iluminação.
• Criar animações.
• Sons.
• Programação de Inteligência Artificial (IA).
• Programação por scripting (codificação).
• Simulações.
• Entre outras funcionalidades (MASTER.D, 2021).
Como podemos observar pelas funcionalidades listadas, o Unity é

poderoso! Com o Unity podemos criar jogos para mais de 27 plataformas. Na
figura 11 apresentamos as plataformas para a qual podemos desenvolver.
FIGURA 11 – PLATAFORMAS SUPORTADAS
FONTE: A autora.
Mas por que usar ele? Bom vamos, lá... Como podemos ver até agora o
Unity é bem versátil, e com múltiplas possibilidades para o desenvolvimento
multiplataforma. A figura 12 apresenta as principais características do Unity, e
porque ele é uma boa escolha de software.
185
FIGURA 12 – BENEFÍCIOS DO UNITY
FONTE: Adaptado de Eduardo (2015).
Com o Unity, a produção é rápida, pois podemos construir cenas de maneira

rápida, assim como realizar testes e a edição do jogo, através do Som e Gráficos
cinemáticos, os jogos produzidos tem um toque refinado, luz de alta qualidade
e filtro de áudio para cenas. Podemos trabalhar em tempo real, a otimização do
desempenho garante uma incrível experiência em jogos desenvolvidos, com
o Unity Ads é possível aumentar os downloads dos jogos desenvolvidos, já os
tutoriais oferecidos pelo Unity podem guiar os desenvolvedores iniciantes. No
site do Unity, a documentação é composta por explicações das codificações.
A comunidade Unity é um dos grandes benefícios do Engine, pois muitos
desenvolvedores respondem perguntas e dúvidas da comunidade. Por último,
temos o Asset Store, onde podemos adquirir modelos, códigos e interfaces, entre
outros recursos que poderemos incluir em nossos projetos (EDUARDO, 2015).
4 FERRAMENTAS DA ENGINE
O Unity é repleto de recursos como vimos até agora. Com relação às
ferramentas o Unity possui diversas. Na figura 13 visualizamos a tela do Unity, ela
é nossa área de trabalho por onde iremos acessar todas as ferramentas e criarmos
nossos jogos. A área de trabalho é composta de várias janelas ou views como
também são conhecidas, podemos alterar seus tamanhos e posicionamento, assim
podemos personalizar nossa área de trabalho conforme o que vamos utilizando,
ou seja, deixando fixo apenas as ferramentas e recursos que mais utilizamos.
Cada view possui um propósito específico (PASSOS et al., 2009).
186
FIGURA 13 – ÁREA DE TRABALHO DO UNITY
FONTE: <https://bit.ly/2ZwE2xd>. Acesso em: 28 ago. 2021.
Vamos começar explorando a barra de ferramentas (figura 14). Ela contém

todos controles que afetam o Unity, é uma barra fixa, ou seja, ela não pode ser
removida da área de trabalho, uma vez que com os seus controles podem afetar o
Unity como um todo (BUTTFIELD-ADDISON et. al, 2019).
FIGURA 14 – BARRA DE FERRAMENTAS
FONTE: (BUTTFIELD-ADDISON et al., 2019)
A barra de ferramentas é composta por vários grupos de controle, em

que cada um destes grupos se relaciona com diferentes partes do editor (UNITY
DOCS, 2021a). No Quadro 4 poderemos conhecer cada um destes controles.
Esta paleta controla como os controles de transformação, que aparecem

quando um objeto é selecionado, se comportam. Somente um modo pode ser
selecionado por vez. Eles são:
187
QUADRO 4 – GRUPOS DE CONTROLE DA BARRA DE FERRAMENTAS
Controle: Descrição:
Use as ferramentas Transformar no Vista
da cena
- A primeira ferramenta na barra de
ferramentas, a Ferramenta de Mão,
permite que você dê a volta na cena.
- As
ferramentas Move, Rotate, Scale, Rect
Transform e Transform permitem editar
GameObjects individuais. GameObjects
selecionados também exibem
um Gizmo na exibição cena se você tiver
uma das quatro ferramentas Transform
selecionadas.
Toggling the Transform Gizmo afeta a visão
da cena.
Use os botões Jogar, Pausar e Passo
na exibição do jogo.
Inicie Unity Collaborate do menu suspenso
do Collab.
Clique no botão Nuvem para abrir a
janela Unity Services.
Acesse sua conta de unidade no menu
suspenso da conta.
Você pode controlar quais objetos
aparecem Cena vista do Camadas menu
suspenso.
Você pode alterar o arranjo de suas
visualizações e, em seguida, salvar o
novo layout ou carregar um existente no
menu suspenso do layout.
FONTE: Adaptado de UNITY DOCS, 2021a.
Como podemos observar no Quadro 4, várias ferramentas irão nos auxiliar

no nosso desenvolvimento, mas vamos analisar mais as sete ferramentas que irão
ajudar na execução das operações de visualização de cena
:
O primeiro é a ferramenta Mão. Quando é selecionado, nenhum

objeto será selecionado quando você clicar neles. Em vez disso, o
botão esquerdo do mouse será usado para percorrer a cena da mesma
maneira que segurar a roda de rolagem. (...) A segunda ferramenta
de cena é a ferramenta Mover (Figura 2-14). Quando um objeto é
selecionado na janela Cena, você pode arrastar setas para movê-lo na
188
direção de um eixo específico. O objeto também pode ser arrastado

pelos dois pequenos quadrados, para se mover ao longo de dois eixos
simultaneamente. A terceira ferramenta de cena, a ferramenta Rotate,
funciona da mesma maneira que a ferramenta Move, exceto que é usada
para girar GameObjects. Ao arrastar ao longo dos círculos coloridos,
você pode girar um GameObject em um dos três eixos ou ao longo
dos círculos cinzentos para girar em dois eixos simultaneamente. A
quarta ferramenta é a ferramenta Escala, o que nos permite reduzir
ou diminuir os GameObjects selecionados. Ao arrastar os quadrados
coloridos, você está escalando GameObjects para cima ou para baixo
ao longo do respectivo eixo e, arrastando-se do pequeno quadrado
no centro do GameObject, está escalando GameObjects para cima ou
para baixo uniformemente ao longo de todos os eixos de cada vez. A
quinta ferramenta de cena é a ferramenta Rect, que é útil para mover e
dimensionar objetos 2D. Nós o usaremos depois, quando precisarmos
mover ou dimensionar imagens, botões e elementos de interface do
usuário 2D.
A sexta ferramenta combina os recursos das ferramentas Mover, girar
e dimensionar. Vamos pular o que ele faz e usar a sétima e última
ferramenta (Multi) por enquanto. Na visualização Cena, você também
pode clicar nos pequenos cones no canto superior direito da janela, para
tornar o ângulo de visão perpendicular a um eixo (TAKOORDYAL,
2020, p.39-42).
Além da barra de ferramentas, nossa área de trabalho é composta da

view Hierarchy (Hierarquia), a qual irá exibir todos os elementos da cena que
estejamos editando. Podemos organizar e visualizar a hierarquia da composição
dos objetos, para isso podemos usar o recurso grafo de cena (PASSOS et al., 2009).
A view Inspector (Inspetor) tem como função exibir informações sobre um objeto
selecionado, ou seja, ao clicar em um dos objetos da view Hierarchy, as informações
do objeto selecionado serão exibidas automaticamente na view Inspector. A figura
15 demonstra as duas janelas, as informações do objeto é comportada por uma
lista de componentes, os quais podemos editar e modificar, sendo que “todos
os objetos de jogo têm pelo menos um componente, Transform, para que você
sempre veja pelo menos informações sobre posicionamento e rotação no Inspector.
Frequentemente, os objetos terão vários componentes listados aqui, incluindo
scripts anexados a eles” (HOCKING, 2018, p. 15).
189
FIGURA 15 – VIEW HIERARCHY E VIEW INSPECTOR
FONTE: Hocking (2018, p. 16)
A view Project (Projeto) é onde ficam os nossos Assets (figura 16), ou seja,
os arquivos do projeto que são nossos scripts, modelos, efeitos de áudio, texturas,
e prefabs que são um tipo de asset, Game Object reusável armazenado na janela
Project. Prefabs podem ser inseridos em diversas cenas, múltiplas vezes em cada
uma delas. Ao se adicionar um Prefab a uma cena, está sendo criada uma instância
dele, estão ligadas ao Prefab original e são, no fundo, clones desse (PASSOS et al.,
2009).
FIGURA 16 – VIEW PROJECT
FONTE: <https://bit.ly/3bmLYDL>. Acesso em: 6 out. 2021.
190
Nas views Scenes (Cenas) e Game (Jogo) iremos manipular os elementos e

desenvolver nossos jogos, é onde temos a visão do que estamos criando. Na view
Scene é onde iremos manipular os elementos visuais, assim podemos editar as
posições dos objetos, tamanho para construir a cena com foi planejado. Já a view
Game é onde veremos o resultado do que foi criado. Ao clicar na ferramenta Play
(barra de ferramentas), o jogo será ativado. É por meio dessa view que iremos ver
como será exibido o jogo, além de podermos visualizar o comportamento dos
elementos (PASSOS et al., 2009; FERRÃO, 2020).
NTE
INTERESSA
Neste vídeo podemos conferir como é a interface do Unity e como podemos

configurá-la. Para acessar o vídeo acesse o link: https://www.youtube.com/watch?v=t_
nGdkH8qIQ.
FIGURA 17 – VIEW SCENE E VIEW GAME
FONTE: <https://bit.ly/3bmLYDL>. Acesso em: 6 out. 2021.
5 TRABALHANDO COM OBJETOS

São diversos os elementos que iremos utilizar para criar nossos jogos,
além de recursos que já foram desenvolvidos, como os personagens e objetos de
cena, por exemplo, outros elementos podem ser adicionados na cena.
O GameObject é um conceito principal do Unity, pois cada objeto que for

incluído na cena é um GameObject, sobre esses objetos temos como exemplo os
personagens, itens em cena, as luzes, entre outros. Em cada um destes GameObject
devem ser atribuídas propriedades.
GameObjects são os objetos fundamentais em Unity que representam
191
personagens, adereços e cenários. Eles não realizam muito em si

mesmos, mas atuam como recipientes para Componentes , que
implementam a funcionalidade.
Para dar a um GameObject as propriedades necessárias para se
tornar uma luz, uma árvore ou uma câmera, você precisa adicionar
componentes a ele. Dependendo do tipo de objeto que deseja criar, você
adiciona diferentes combinações de componentes a um GameObject
(UNITY DOCS, 2021b).
Os componentes são responsáveis por incluir os comportamentos dos

objetos. A Documentação do Unity (2021c, s. p.) se refere a eles como as “porcas
e parafusos de objetos e comportamentos em um jogo”. Através da view Inspector
podemos editar os componentes do jogo, pois, segundo Manning e Buttfield-
Addison (2017, p. 371), são expostas “automaticamente todas as variáveis em
seus scripts como campos de texto, caixas de seleção e slots fáceis de usar para
descartar ativos e objetos de cena, o processo de montagem de uma cena é feito
muito mais rápido”.
Outros elementos podem ser incluídos, os quais são conhecidos como

Prefabs, ou Pré-fabricados. Eles podem ser importados de outros projetos, por
exemplo, porém, seus principais exemplos de utilização, segundo Unity Docs
(2021d), são:
• Ativos ambientais - por exemplo, um certo tipo de árvore usada

várias vezes em um nível (como visto na captura de tela acima).
• Personagens não-jogadores (NPCs) - por exemplo, um certo tipo
de robô pode aparecer em seu jogo várias vezes, em vários níveis.
Eles podem diferir (usando substituições) na velocidade em que
se movem ou no som que fazem.
• Projéteis - por exemplo, o canhão de um pirata pode instanciar
uma bola de canhão Prefab cada vez que é disparada.
• O personagem principal do jogador - o prefab do jogador pode ser
colocado no ponto de partida em cada nível (cenas separadas) do
seu jogo (UNITY DOCS, 2021d, s. p.).
A utilização de camadas ou layers é utilizada para identificar ou agrupar

quais objetos irão interagir entre si. Takoordyal (2020, p. 98) destaca que que
podemos definir uma
camada de GameObject que pode colidir com outra camada de

GameObject. (...), ela pode colidir com todos os objetos, usando
Camadas existentes, se você não modificar nada. As camadas também
podem ser usadas para definir quais objetos são renderizados pela
câmera ou afetados por uma fonte de luz específica.
Podemos criar várias camadas ao longo do desenvolvimento, que são

definidas como Camada de usuário, porém, o Unity possui Camadas Internas, as
quais podemos somente editar e utilizar.
192
6 LEVEL
O nível ou Level normalmente são as fases do jogo, onde cada uma tem
um objetivo próprio para ser alcançado. No entanto, existem jogos que possuem
apenas um nível, a construção de vários níveis vai muito do que foi planejado
para o jogo. Na maioria das vezes, os níveis possuem graus de dificuldades,
quanto maior a fase mais difícil será o jogo, mas é importante que se tenha um
equilíbrio da dificuldade de jogo. Borromeo (2020) afirma que
Há muitas considerações a serem feitas ao determinar o quão difícil

deve ser o seu jogo. Se for muito difícil, os jogadores perderão o
interesse e, se o jogo for muito fácil, pode não atrair o público-
alvo. Alguns jogos incluem níveis de dificuldade para os usuários
selecionarem. Outros jogos têm vários níveis, cada um com um nível
crescente de dificuldade. Há várias perguntas com as quais devemos
lidar para alcançar o equilíbrio de dificuldade desejado (BORROMEO,
2020, p. 26).
A dificuldade dos níveis pode ser controlada pela Progressão de

Dificuldade do jogo. Novak (2017) afirma que “é importante que a dificuldade
de um game aumente progressivamente conforme ele avança (...), o conflito deve
ser intensificado em cada nível por meio de uma série de arcos”. Pode ocorrer
também que além da dificuldade aumentar progressivamente, os personagens
também possam ir se adaptando aos novos desafios, assim como adquirindo
novos poderes ou recursos. Esta é só uma ideia, a principal motivação dos níveis é
deixar os jogadores ocupados, com algo para conquistar, fazer, descobrir. Novak
(2017, p. 217) reforça essa ideia ao dizer que “ o desafio é essencial, mas não torne
seus níveis tão difíceis que só os especialistas consigam sobreviver, enquanto
outros jogadores morram sucessivamente”, ou seja, os níveis são úteis para
manter o jogador envolvido ao jogo, mas se for um desafio com muita dificuldade
ou que o jogador tente várias vezes e falhe, pode ocorrer do jogador abandonar o
jogo no meio. A Progressão de Dificuldade, conforme apresentada na figura 18,
demonstra a comparação das progressões linear, plana e de curva em S.
Um game não precisa ser linear — consistindo em desafios cuja

dificuldade aumenta progressivamente conforme o game avança.
Ele também pode ser plano, mantendo o mesmo grau de dificuldade
de um nível para outro. Há também o modelo da curva em S, uma
combinação dos modelos linear e plano, que começa com uma seção
plana consistindo em um tutorial durante o qual o jogador aprende
a jogar. Após esse período de treinamento, o grau de dificuldade
aumenta constantemente durante o game até algumas horas antes do
seu final, quando ele se torna novamente plano para que os jogadores
que chegaram até esse ponto consigam terminá‑lo (NOVAK, 2017, p.
217).
193
FIGURA 18 – COMPARAÇÃO DAS PROGRESSÕES LINEAR, PLANA E DE CURVA EM S
FONTE: Novak (2017, p. 217)
É importante que cada nível possua uma meta para ser alcançada,
Novak (2017, p. 214) afirma que “cada nível deve ter um conjunto de objetivos
compreensíveis ao jogador”, pois caso o usuário não tenha a percepção do
objetivo, pode ocorrer de o “(...) jogador estar simplesmente se movendo, atirando,
solucionando enigmas e coletando objetos até que apareça algum sinal indicando
que o nível foi concluído ou que um novo nível está sendo carregado”.
O fluxo do níveis também deve estar relacionado, e que o jogador

permaneça no nível até que ele seja concluído. Outro detalhe que deve ser
observado nos níveis é sua duração, ou seja, quanto tempo o jogador deverá
permanecer em cada nível até que venha concluí-lo. É importante que tenha uma
curta duração, por exemplo, 15 minutos a 45 minutos. Outro fator a se observar
é a disponibilidade, ou seja, quantos níveis serão utilizados no jogo (NOVAK,
2017).
7 COLISÕES DE FÍSICA
Como conhecemos em nossa primeira Unidade, a física é aplicada nos
jogos e está presente na maioria dos momentos. Em alguns casos, um profissional
é responsável somente pela parte de inclusão da física em jogo. Com alguns
softwares, esse profissional é substituído pelos motores de física. O Unity possui
“um sistema de física separado para jogos 2D em vez da física 3D” (HOCKING,
2018, p. 131). Ou seja, no Unity temos um motor de física para cada tipo de jogo.
A física nos projetos é utilizada para “garantir que os objetos aceleram e

respondem corretamente a colisões, gravidade e várias outras forças” (UNITY
DOCS, 2021e, s. p.). A física é aplicada aos sprites dos personagens, e elementos
194
que compõem a cena, sendo necessária a atualização de dois componentes

físicos. Os colisores precisam estar atualizados para que se tenha a forma correta
e as juntas devem estar ajustadas para que girem no ponto certo do corpo do
personagem (MANNING; BUTTFIELD-ADDISON, 2017).
DICAS
Neste vídeo são exploradas as colisões e como podemos cria-las no Unity. Acesse
o link: https://www.youtube.com/watch?v=Kx_0pzU5Vic&ab_channel=PapodePlayer.
Segundo (2010), a física nos jogos funciona melhor do que em nossa

realidade
Como Sir Isaac Newton fez todo o trabalho duro em 1687, seria de se
supor que isso seria fácil, certo? A física do mundo real é baseada nas
leis da física com as quais vivemos todos os dias. Mas é necessária uma
certa fidelidade à vida real para vender a física do mundo real, e tentar
criar algo que imite precisamente a física do mundo real geralmente
acaba inferior a algo aprimorado. Por exemplo, a gravidade nos jogos
não é de 9,8 m / s 2) não importa o que o mundo real diga. De fato,
alguns jogos até usam constantes gravitacionais diferentes em objetos
diferentes!
É aqui que a física do jogo entra em jogo. Os programadores "ajustam"
os valores do mundo real para atender às necessidades de jogabilidade.
Velocidades de corrida, alturas e distâncias de salto e segurança de
colisão sempre se sentem melhor quando ajustadas (ROGERS, 2010,
p. 101).
No Unity temos o RigidBody, que quando é adicionado a um objeto irá

habilitar as forças físicas para que atuem sobre ele. Como exemplificado por
Leal (2016a), “você cria um cubo no meio da cena. Ele vai ficar flutuando lá,
pois a gravidade, que é uma força física, não atua sobre ele. Mas, ao adicionar a
propriedade RigidBody ao cubo, a gravidade agora atua e o cubo cai”. A figura 19
demonstra esse componente de física.
195
FIGURA 19 – RIGIDBODY
FONTE: <https://bit.ly/3jOhy1E>. Acesso em: 6 out. 2021.
Como podemos observar na figura 18, esse componente é cheio de

detalhes, os quais devemos configurar. Vamos conhecer um pouco sobre cada
um deles a seguir:
• Mass: é responsável por controlar a massa do objeto, quanto maior sua massa,
mais força será necessária para movê-lo.
• Drag: realiza o controle de quanto de resistência do ar afeta o objeto, ela pode
ser utilizada para que o objeto cair lentamente por exemplo, assim estaremos
adicionando resistência do ar ao cair.
• Angular Drag: realiza o controle da resistência do ar, quando o objetivo estiver
girando por causa do torque.
• Use Gravity: podemos ativar ou desativar a força de gravidade de um objeto;
• Is Kinematic: com ele podemos desativar a atuação da física sobre o objeto,
porém ele pode interagir com a física de outros objetos, ao ativar essa opção
ele se tornará um objeto estático.
• Interpolate: podemos utilizar esta propriedade para corrigir problemas com o
movimento do objeto, podendo escolher três opções:
օ None: não é utilizada interpolação;
օ Interpolate: utiliza a posição do último frame (quadro) para realizar o ajuste;
օ Extrapolate: utiliza a próxima posição (prevista) para realizar o ajuste.
• Collision Detection: pode ser utilizado para evitar que objetos se movam muito
rápido, sendo possível escolher entre três tipos:
օ Discrete: deve ser utilizado como padrão para a maioria dos objetos;
օ Continuous: pode ser utilizado quando um objeto rápido irá colidir com um
objeto estático, ou seja, quando a opção ‘Is Kinematic’ estiver selecionada;
օ Continuous Dynamic: é utilizado quando um objeto rápido irá colidir com um
objeto móvel, ou seja, quando a opção ‘Is Kinematic’ não estiver selecionada;
• Constraints: é utilizado para impedir o movimento e a rotação nos eixos
marcados (LEAL, 2016a).
Os Colliders ou colisadores são um grupo de componentes que permite

a colisão, sendo utilizado para definir a forma que um objeto para as colisões
físicas. Podemos adicionar quantos colliders forem necessários. É comum os
196
colliders serem utilizados como gatilhos (LEAL, 2016b; TAKOORDYAL, 2020). No

Unity existem seis tipos de colliders, conforme podemos observar na figura 20.
São: Caixa, Esfera, Cápsula, Malha, Roda e Terreno.
FIGURA 20 – COLLIDERS
FONTE: <https://bit.ly/3jOhy1E>. Acesso em: 6 out. 2021.
Cada um destes tipos de colliders possui propriedades próprias. Em geral,

devemos configurar seu tamanho e a sua forma, porém, alguns destes tipos
possuem propriedades em comum, como ressaltado por Leal (2016b):
• Is Trigger: quando essa propriedade está marcada, os objetos que

passam pelo colisor não são afetados por ele. Mas é possível saber
quando o objeto passou. Por exemplo: Em um jogo de corrida,
você quer saber quando o carro passa pela linha de chegada.
Colocamos um collider nela e marcamos a opção Is Trigger para
que o carro não pare quando colidir com ele;
• Material: atribuímos um material para um colisor quando
queremos simular diferentes superfícies. Por exemplo, uma bola
rolando na areia: ande menos do que uma que está rolando no
concreto;
• Center: marca a posição central do collider com relação ao objeto.
Os valores x:0, y:0 e z:0 indicam que o centro do colisor é o mesmo
que o centro do objeto (LEAL, 2016b, s. p.).
Outro recurso que podemos utilizar é o Character Controller, o qual nos

oferece a possibilidade de controlar objetos que sofram da ação da física e mantem
a interação com os objetos contidos na cena (PASSOS et al., 2009).
197
8 ELEMENTOS DO JOGO
No desenvolvimento de nossos jogos, muitos elementos serão criados
antes de sua implementação, os quais devem ser previstos ainda na fase de
pré-produção. Dentre esses elementos que veremos a seguir, são essenciais em
praticamente em todos os jogos o menu, os controles, o áudio e efeitos utilizados.
Como no momento da implementação esses elementos já devem terem sido
definidos, basta implementa-los no jogo, não é mesmo? No entanto, nem sempre
é o caso, uma vez que sempre são criados efeitos sonoros, áudios melhorados e
interfaces mais limpas, agradáveis e intuitivas desenvolvidas, que podem inspirar
melhorias em nosso jogo. Então, é comum que no momento de implementação
destes elementos, seja realizada uma pesquisa do estado atual deles, assim
podemos trazer ao projeto novas tendências. No entanto, não devemos começar
do zero, podemos observar o que tem-se de novo e anotar essas informações para
serem implementadas em futuras versões.
8.1 MENU E CONTROLES

Os menus são responsáveis pelo jogador acessar o jogo, configurá-
lo, personalizar avatares, escolher recursos, entre outras ações que podem ser
executadas pelo jogador. O menu e os controles correspondem a Interface do
Usuário.
O menu, assim como os controles do jogo, deve ser desenvolvido

garantindo que três fatores sejam observados, conforme ilustrado pela figura 21.
FIGURA 21 – FATORES DO DESIGN DE INTERFACE
FONTE: A autora
Estes três fatores irão impactar como os jogadores irão ver o seu jogo,
jogá-lo e comentá-lo. Por isso, eles devem ser bem pensados e criados, tendo o
foco no usuário, uma vez que um erro comum no desenvolvimento de softwares é
198
a implementação com base na informação de somente os desenvolvedores. Para

melhorar o desenvolvimento dos menus e dos controles, uma possibilidade é criar
protótipos do jogo em papel e testá-lo com vários grupos de pessoas com diversas
faixa etárias e de todas as áreas. Outra possibilidade é a criação de protótipos on-
line do jogo. Em ambos os casos, essa etapa pode ser desenvolvida ainda da fase
de pré-produção. A figura 22 demonstra os elementos de interface do usuário.
FIGURA 22 – ELEMENTOS DE INTERFACE DO USUÁRIO
FONTE: Buttfield-Addison et al. (2019)
Normalmente podemos adicionar botões, caixa de seleção (checkbox), caixa

de texto e slider horizontal, é comum também que sejam criados esses elementos
com as cores, ou a temática do jogo, assim podemos encontrar jogos cujo botões
são desenhos, por exemplo. Esses elementos podem ser adicionados no jogo,
uma vez que fazem parte do Unity. Por outro lado, os elementos personalizados
requerem que sejam previamente desenvolvidos para que sejam implementados.
Os controles do jogo dependem do hardware que será utilizado para

jogá-lo, ou seja, uma vez que Unity permite a criação de jogos multiplataforma,
muito do que foi desenvolvido para uma versão pode ser adaptado para outra.
No caso do Android, normalmente o controle é executado pelo toque na tela. Em
raros casos, os botões têm alguma utilização dentro do jogo, porém, uma vez
que o Android também é utilizado em outros dispositivos além de smartphones e
tablets. É essencial que os controles possam ser adaptados a outros dispositivos.
Os botões de controle são um dos principais meios do jogador realizar o controle
no jogo. Sinicki (2017) afirma que os botões devem:
199
(...) ser claros e fáceis de encontrar, mas também é importante que

eles não distraiam o jogador ou encobrem quaisquer elementos
importantes do jogo. Por esse motivo, escolher algo que pareça
levemente translúcido é uma boa opção.
Também é pertinente que os botões correspondam à estética do seu
mundo de jogos. A cor que você escolhe precisa se destacar contra
os níveis, mas sem colidir de maneira extravagante. À medida que
seus jogadores progridem no jogo, é normal que a paleta de cores do
mundo do jogo mude: talvez um nível seja definido debaixo d'água
com muitos blues e greens, e outro nível seja definido no espaço com
muito preto e branco. Se você criar seus botões em vermelho ou
verde, verá que eles às vezes parecem feios contra o mundo do jogo.
(SINICKI, 2017, p. 121).
Podemos criar um menu para cada fase do jogo. No entanto, normalmente

são criados apenas três menus:
1. O primeiro é exibido quando o jogo inicia.

2. Quando o jogador perde ou desiste.
3. Quando o jogador vence (TAKOORDYAL, 2020).
É claro que essa regra não é aplicável a todos os tipos de jogos, e podemos
adicionar quantos menus forem necessários. O importante é que sejam menus
objetivos em que o jogador não tenha que ler um manual para jogar, pois isso
pode fazer o jogador abandonar o jogo antes de iniciar. Uma boa prática que
podemos incluir em nossos jogos é um jogo inicial guiado, assim, o jogador irá
conhecendo as configurações e ações que poderá realizar e tirar suas dúvidas
antes de começar a jogar sozinho.
8.2 EFEITOS SONOROS

Os efeitos sonoros são uteis para chamar atenção do jogador, motivá-lo,
além de trazer uma boa experiência sonora, ou seja, devem ser utilizados recursos
sonoros de qualidade, mas para isso, precisamos desses recursos antes incluímos
em nosso projeto, ou seja, no momento de implementação do jogo já devemos ter
criados os efeitos sonoros ou utilizar uma base para adquirir os efeitos.
DICAS
Caso você não queira produzir os efeitos sonoros, podemos utilizar recursos
gratuitos, como os disponibilizados pelo Kenney.nl (https://kenney.nl/), a comunidade
Freesound (https://freesound.org/) e o aplicativo Bfxr (https://www.bfxr.net/).
200
O Unity aceita a importação de arquivos de áudio nos formatos aif, .wav,

.mp3, e .ogg. Caso sejam utilizadas outras extensões como .xm, .mod, .it, e .s3mO,
o Unity irá converte-lo (BUTTFIELD-ADDISON, et al., 2019). Uma opção, além de
se adquirir, é utilizar um software de edição de sons, como o Audacity, para criar
sons e narrações do jogo. Uma vez adicionado no Unity, podemos configurar as
propriedades do áudio, conforme representado na figura 23.
FIGURA 23 – IMPORTAÇÃO E CONFIGURAÇÃO DE ÁUDIO
FONTE: Buttfield-Addison et al. (2019)
Na primeira imagem da figura 23 temos a tela de importação do áudio. Já

na segunda imagem podemos observar as propriedades que podemos configurar
para melhor apresentá-lo no jogo. É claro que a cada arquivo de áudio inserido
no Unity você deve realizar as configurações. Os efeitos podem tornar o jogo
mais cativante ao seu público, então, ao planejar quais recursos sonoros serão
adicionados no jogo, inspire-se em jogos já consagrados e como um simples som
remete ao jogo.
9 PUBLICANDO O JOGO
No Unity, depois de concluída a implementação, ou até antes, podemos
criar uma versão para telas nos dispositivos Android. Para isso, iremos salvar
nosso projeto no formato .apk, o qual poderá ser incluído no Android e testado. A
figura 24 demonstra como podemos selecionar essa opção no Unity. Ao realizar
essas configurações antes de termos nosso arquivo .apk, o jogo irá ser compilado,
por isso, selecione as cenas que deseja compilar. Quanto maior o número de
cenas, maior será o tempo de compilação, o que pode váriar de dispositivo para
dispositivo.
201
FIGURA 24 – COMPILANDO O JOGO
FONTE: Takoordyal (2020, p. 240)
Realizadas as configurações e selecionadas as cenas, basta clicar no botão

‘Build’ para iniciar a compilação ou em ‘Bluid And Run’, para, além do jogo ser
compilado, depois ser executado. Uma vez finalizado todo o jogo, podemos
publicá-lo! Para isso, devemos realizar o upload da versão final do jogo no Google
Play. A figura 25 demonstra de tela de upload do jogo, onde iremos enviar, além
do arquivo final .apk, suas imagens de utilização (screenshots) e ícones. Além
destes arquivos, devemos incluir o nome do jogo, site, desenvolvedores e uma
mensagem sobre o jogo. Tenha cuidado e atenção com todas as informações
que for incluir para apresentar o seu jogo, seja claro e objetivo com o que ele
oferece. Prometer uma coisa e não cumpri no jogo é um tiro no pé, e pode gerar
comentários negativos para o seu jogo. Por isso, seja objetivo, claro e poderá ter
muito sucesso.
202
FIGURA 25 – UPLOAD DO JOGO
FONTE: James (2013, p. 286)
E
IMPORTANT
Ok, jogo publicado, acabou! Que nada! Após publicado, o jogo deve ser
atualizado e corrigido. Uma boa prática é acompanhar e responder os comentários que os
jogadores publicarem. Eles podem guiar melhorias, correções e até futuros projetos. Então,
uma vez publicado o jogo, a atividade de se desenvolver não se encerra, mas adapta-se
para outra, a de melhoria contínua do que foi desenvolvido.
203
RESUMO DO TÓPICO 2
• O desenvolvimento de jogos para Android é uma opção relevante, uma vez

que é um dos sistemas mais utilizados em smartphones, tablets e Smart Tvs.
• A utilização do Unity permite a criação de jogos multiplataformas, sem

que tenhamos que criar um jogo diferente para cada uma, o que elimina o
retrabalho no desenvolvimento de jogo.
• Com o Unity podemos criar jogos em 2D, 3D, em Realidade Aumentada e

Realidade virtual, além de podermos criar um projeto e depois alterar o tipo
de jogo.
• Cada objeto criado no Unity é um GameObject. Eles irão representar o que

for importado para o projeto, como os personagens, objetos de cena e cenário.
• Cada nível criado deve possuir uma meta a ser alcançada. Com isso, o jogador
continuará motivado e engajado com o jogo. O nível de dificuldade pode ser
aumentado gradativamente.
• As forças de física são aplicadas em um objeto quando utilizado o RigidBody,

já os Colliders definem a forma para as colisões físicas.
• Os fatores do design de interface devem garantir que os controles e menus

criados sejam intuitivos, limpos e de boa aparência.
• Podemos utilizar os efeitos sonoros para atrair a atenção do jogador, assim

como incluir um fundo musical ao jogo.
204
AUTOATIVIDADE
1 A área de trabalho do Unity é o local onde iremos desenvolver nossos

jogos. Ela é composta de várias janelas ou views, onde podemos alterar o
posicionamento e seu tamanho. Sobre essas views, assinale a alternativa
CORRETA que corresponda as views padrão do Unity.
a) ( ) Barra de Ferramentas, Barra de Status, Projeto e Inspetor, Jogo e Editor.

b) ( ) Barra de Ferramentas, Hierarquia, Projeto, Inspetor, Jogo e Cena.
c) ( ) Barra de Ferramentas, Pesquisa, Projeto, Cena e Jogo.
d) ( ) Barra de Status, Atualizador, Projeto e Inspetor.
2 Os prefabs, ou pré-fabricados, são ativos que podem ser importados de outros

projetos, assim como baixados de projetos on-line. Podem ser utilizados
para reaproveitar recursos e assets. Assinale a alternativa CORRETA que
representa exemplos de sua utilização:
a) ( ) Ativos ambientais, personagens não jogáveis, projeteis, personagens

principais.
b) ( ) Ativos ambientais, personagens jogáveis, personagens principais.
c) ( ) Ativos estruturais, personagens jogáveis, projeteis, elementos de cena.
d) ( ) Ativos hierárquicos, personagens não jogáveis, ferramentas,
personagens principais.
3 Os fatores do design de interface são utilizados no desenvolvimento de

vários recursos tecnológicos. No desenvolvimento de jogos de três fatores,
se destacam e são essenciais na criação de menus e nos controles do usuário.
Sobre esses três fatores, classifique V para as sentenças verdadeiras e F para
as falsas:
( ) Intuitivo, Limpo e Bonito.

( ) Difícil, Limpo e Agradável.
( ) Intuitivo, Complexo e Bonito.
a) ( ) V – F – F.
b) ( ) V – F – V.
c) ( ) F – V – F.
d) ( ) F – F – V.
4 A dificuldade dos níveis do jogo pode ser controlada utilizando a Progressão

de Dificuldade. Assim, a dificuldade do jogo irá aumentar gradativamente
e o jogador vai se adaptando ao jogo. Disserte sobre a Progressão da
Dificuldade.
205
5 No Unity, após a conclusão do jogo, ou até para criar versões de teste,
podemos criar compilações de jogo para diversas plataformas diferentes.
No entanto, sua utilização traz outras vantagens para os desenvolvedores
de jogos. Disserte sobre as vantagens de se utilizar este ambiente de
desenvolvimento.
206
UNIDADE 3
TÓPICO 3 —
DESENVOLVIMENTO DE JOGOS PARA IOS
1 INTRODUÇÃO
Bem-vindo ao nosso terceiro e último Tópico da Unidade 3! No caminho
até aqui conhecemos vários conceitos sobre o desenvolvimento de jogos, em
especial, nesta unidade, a documentação e o desenvolvimento mobile. Neste
tópico, iremos conhecer sobre o Desenvolvimento de jogos para sistemas IoS.
Continuaremos a abordar o desenvolvimento para IoS sobre a perspectiva do
ambiente de desenvolvimento Unity, uma vez que podemos utilizá-lo para
desenvolver jogos multiplataforma.
Ao longo deste tópico, iremos conhecer outros elementos resentes na

criação de jogos utilizando o ambiente Unity. Lembrando que o que conhecemos
na Unidade 2 pode ser utilizado no desenvolvimento para IoS, uma vez que
exploramos o mesmo ambiente. É claro que poderíamos utilizar um específico
para o IoS, mas como o foco desta disciplina é o desenvolvimento multiplataforma,
utilizar um ambiente que nos proporcione isso facilita a aprendizagem, além de
reduzir o retrabalho que teríamos, uma vez que cada ambiente pode possuir
configurações distintas. No entanto, nada nos impede de explorar outros
ambientes de desenvolvimento, não é mesmo? Na Unidade 1 vimos alguns
ambientes diferentes ao Unity, os quais podemos explorar para ver qual melhor
nos adaptamos.
Outra plataforma de desenvolvimento para IoS é o OXcode, onde podemos

baixar, desenvolver e utilizar diretamente na plataforma, porém, para a publicação
ou para executar um jogo ou aplicativo em um iPhone ou iPad, somente é possível
se você se registar como Desenvolvedor Apple no iOS Developer Program no link
<https://developer.apple.com/programs/ios/> (TOLLIN; GOMES; LEITE, 2012).
Porque desenvolver jogos para IoS? A Apple possui mais de 1 bilhão de

usuários ativos. Até o primeiro semestre de 2021, mais de 41,5 bilhões de dólares
em transações foram realizadas na App Store, sendo que 40% dos downloads da App
Store são de jogos, assim com 70% da renda vem deste meio (MARINHO, 2020;
PANKIEWICZ, 2021; MENGE, 2013). Seja para Android, IoS, Console ou outras
plataformas, a ideia principal é colocar o que você conheceu e apreendeu até aqui
em prática. Ao desenvolver, você irá criar experiência, superar dificuldades e se
aperfeiçoar.
Vamos explorar nosso último tópico. Bons estudos!
207
2 BASE DO JOGO
A base do jogo pode ser criada utilizando um projeto já desenvolvido ou
criando um do zero, porém, é fundamental que ao finalizar a criação ou criarmos
versões compiladas, selecionemos a opção iOS. Assim, podemos criar nossos
jogos e apenas no final do percurso de desenvolvimento escolher a plataforma
iOS. É claro que esse é um dos pontos fortes do Unity, se escolher outro ambiente
essa regra pode ser diferente. A figura 26 demonstra como podemos criar um
novo projeto no Unity ao acessarmos a opção ‘File’ e em seguida ‘New Project...’,
mas caso já tenhamos iniciado um projeto ou estarmos utilizando um que tenha
baixado, podemos selecionar a opção ‘Open Project...’.
FIGURA 26 – CRIANDO NOVO PROJETO NO UNITY
FONTE: Wells (2020)
Como estamos começando no mundo do desenvolvimento dos jogos, uma

alternativa é utilizar o Unity Hub. Lembra-se dele do Tópico 2? Se inicialmente ele
nos auxiliou na instalação do Unity, podemos utilizá-lo para criar e gerenciar
nossos projetos. Na primeira imagem da figura 27, podemos observar como
podemos criar um projeto. Ao clicar em ‘New’, começamos a criação de um novo
projeto no Unity. Em sequência, conforme apresentado na segunda imagem da
figura 27, iremos definir o nome do projeto, escolher o local que será salvo o
projeto no computador e escolher um dos modelos (templates) que iremos criar o
jogo.
DICAS
Neste vídeo podemos conhecer como criar nosso primeiro projeto no Unity:
<https://youtu.be/TboBWKBgQ8M>.
208
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS PARA IOS
FIGURA 27 – CRIANDO NOVO PROJETO NO UNITY HUB
FONTE: Wells (2020, p. 5-7)
Podemos considerar essa nossa base do jogo, porque sem ela não podemos
criar nada, então podemos criar quantos projetos de teste for necessário e explorar
os vários templates, sendo que cada um possui características diferentes e vão criar
jogos distintos, conforme Wells (2020):
2D: Uma configuração de projeto padrão para trabalhar em um

espaço 2D. As configurações específicas de 2D são configurados
para importação de textura, visualização de cena e configurações de
iluminação e câmera na cena da amostra.
3D: Um projeto configurado para usar o pipeline de renderização
embutido do Unity.
3D com extras: O mesmo que 3D, mas inclui um novo pilha de pós-
processamento e conteúdo de amostra adicional para exibir a nova
pilha de processamento.
RP de alta definição: Um projeto configurado para plataformas
de ponta. Ele usa um Oleoduto rotativo Renderiz (SRP) chamado
Oleoduto de alta definição do Render (HDRP), que fornece controle
de renderização adicional, permitindo configurar configurações de
renderização usando scripts C #.
RP universal: Isso usa o Tubulação universal do para-choque (URP).
Esse pipeline é semelhante ao HDRP, mas adequado para uma gama
mais ampla de dispositivos, incluindo dispositivos móveis (WELLS,
2020, p. 6).
A seleção entre se criar um jogo em 2D ou 3D não resulta em uma grande

diferença. Manning e Buttfield-Addison (2017) ressaltam que “os projetos 2D
são padronizados para uma visualização lateral, enquanto os projetos 3D são
padronizados para uma perspectiva 3D. Você também pode alterar a configuração
a qualquer momento no inspetor de configurações do editor”. Com isso, você
pode criar o seu jogo à vontade no Unity, e depois de tudo concluído, criar uma
versão dele em iOS ou em qualquer outra plataforma que você quiser.
209
3 BACKGROUND E LOGO
O background é o cenário ou imagem de fundo, ela pode ser fixa ou
dinâmica, ou seja, acompanhar o personagem quando ele explora o mundo do
jogo. Dependendo do jogo, podemos tem um background por fase ou diversos ao
longo das fases. Além de usarmos um fundo de cena no mundo do jogo, também
podemos utilizar em nossos menus. Wiebe (2011) diz:
Normalmente, a cena de fundo do sistema de menus também será uma

cena do jogo. Mas como o jogador não estará interagindo com a cena
de fundo do menu, ele não poderá vê-lo de todos os ângulos, pular nos
objetos e assim por diante. É possível retirar muitos dos componentes
da cena para otimizá-lo para uso como plano de fundo do menu.
Outra opção é criar uma nova cena de fundo que incorpore ativos de
jogos de vários níveis de jogo em um único menu para fornecer ao
jogador uma imagem completa do escopo do nosso jogo. Novamente,
podemos conseguir isso sendo seletivos quanto aos ativos do jogo
que usamos e eliminando todos, exceto os componentes visuais mais
essenciais desses ativos (WIEBE, 2011, p. 160).
Outra possibilidade é a utilização de texturas como plano de fundo.

Dependendo do jogo que está sendo desenvolvido, talvez seja uma boa escolha,
mas com os recursos que temos e as possibilidades gráficas que o Unity possui,
podemos criar um fundo rico em detalhes. O background pode ser criado utilizando
várias camadas, conhecidas com layers, as quais podem ser sobrepor para criar o
fundo desejado. Tollin, Gomes e Leite (2012, p. 64) afirmam que “essas camadas
são transparentes, a menos quando definidas de outra forma, e quando colocadas
uma sobre as outras definem a tela final. Na tela de abertura, podemos pensar
em camadas para a imagem de background, para o logo e para o menu”, não
somente para se criar os fundos, ou logo podemos utilizar as camadas, mas elas
podem e devem ser utilizadas em todo nosso desenvolvimento do jogo.
Já pensou no logo do seu jogo? Bom, ele deve ser bem pensado, mas,
acima de tudo, bem planejado ainda na fase de pré-produção. O ícone de acesso
é a ‘porta’ para o seu jogo, logo, deve transmitir a essência do jogo. O logo será
utilizado ao iniciar o jogo e nos menus, principalmente, mas você poderá utilizá-
lo também fora do desenvolvimento do jogo, ou seja, para promover o seu jogo.
Para isso, pode ser criada uma página oficial do jogo, assim com uma conta nas
redes sociais.
NTE
INTERESSA
Neste vídeo podemos conhecer como inserir background em nossos projetos:

<https://www.youtube.com/watch?v=ahI_nCTD1JE>.
210
A imagem do ícone, assim como seu logo, deve estar pronta até o momento
da compilação do jogo. Uma vez concluída a implementação do jogo, teremos
que editar as informações do jogo na view Inspector. A figura 28 demonstra o que
devemos incluir, que são: o Company Name (nome do jogo), Product Name (nome
do produto), em seguida, devemos incluir a imagem do ícone e na sequência,
podemos incluir uma imagem que pode servir de substituto do cursor (se
aplicável).
FIGURA 28 – CRIANDO INCLUINDO AS PROPRIEDADES DO JOGO
FONTE: Hocking (2018, p. 311)
DICAS
Neste vídeo podemos conhecer como inserir a logo do nosso jogo na tela
inicial: <https://www.youtube.com/watch?v=cvfRDMg9LXc>.
Seja nos backgrounds que iremos utilizar, ou no logo do jogo, ambos

elementos devem ser criados antes de começarmos a editar o jogo. Caso
sejam criados no momento em que o jogo está sendo implementado, poderão
comprometer o cronograma do projeto.
4 CENAS DO JOGO
As cenas do jogo é onde o mundo que criamos será representado, segundo
o Unity Docs (2021f), “as cenas são onde você trabalha com o conteúdo no Unity.
Eles são ativos que contêm todo ou parte de um jogo ou aplicativo”. Podemos
211
criar um jogo com apenas uma cena ou um jogo com n cenas, em que cada um
possui seus próprios ambientes, decoração e obstáculos. Quando um novo projeto
é criado pela primeira vez, o Unity abre uma cena de exemplo, o qual contém uma
câmera e luz (UNITY DOCS, 2021f). A Figura 29 demonstra o exemplo de cena.
FIGURA 29 – EXEMPLO DE CENA
FONTE: Unity Docs (2021f, s. p.)
No Unity, a criação de cena é realiza através de uma cópia dos modelos de

cena. A Unity Docs (2021g) define que os modelos de cena são
(...) como uma cena pré-configurada que contém todo o conteúdo com
o qual você deseja começar. Por exemplo, o modelo básico padrão
geralmente contém um Câmera e uma luz.
Você pode criar seus próprios modelos de cena para personalizar os
tipos de nova cena que você pode criar em um projeto. Por exemplo,
você pode criar modelos para cada nível em um jogo para que todos
os que trabalham no projeto possam iniciar suas cenas com os recursos
e a configuração corretos.
Você pode criar um modelo a partir de qualquer cena do Unity. Depois
de criar um modelo, você pode criar qualquer número de novas cenas
a partir dele. Como as cenas, a maioria dos modelos de cena são ativos
armazenados no projeto (UNITY DOCS, 2021g).
Para se criar uma nova cena, podemos realiza-la através de três maneiras:
• Modelo vazio, em branco o qual vamos criando o modelo do zero.

• Modelo a partir de um recurso de cena existente.
• Modelo a partir da cena atual (UNITY DOCS, 2021h).
Nas duas últimas maneiras podemos criar a cena com o que já foi
desenvolvido, ou seja, explorando os modelos criados ou uma parte dele.
212
NTE
INTERESSA
Que tal conhecer como montar uma cena em 3D no Unity? Confira o vídeo:
<https://www.youtube.com/watch?v=IuDVUILAioY>.
As cenas podem ser criadas utilizando o recurso de linha do tempo do

Unity, que é, segundo Borromeo (2020, p. 317), “um sequenciador de ações para
coordenar esse tipo de cenas. Nós vamos usar Linha do tempo para criar uma
cena de corte para nossa cena, mostrando o nível antes de iniciar o jogo”. Além
de auxiliar na criação de cenas, a linha do tempo também pode ser utilizada
para animar os personagens e o cenário. Ao se criar as cenas, devemos adicionar
primeiro os elementos estáticos, como o piso e as paredes. Em seguida, coloca-se
as luzes ao redor da cena. Em cada um dos objetos inseridos devemos incluir ou
editar suas propriedades na view Inspector (HOCKING, 2018).
Segundo Wells (2020), criar uma cena tem o seguinte significado:
Uma cena refere-se a um espaço 3D, o espaço-tempo do mundo do

jogo - o lugar onde as coisas existem. Como todos os jogos acontecem
no espaço e no tempo, precisaremos de uma cena para o jogo de coleta
de moedas. Em nosso jogo, uma cena representa um nível As palavras
cena e nível pode ser usado de forma intercambiável aqui. Em outros
jogos, você pode achar que uma cena contém vários níveis (WELLS,
2020, p. 19-20).
Para se criar uma nova cena, podemos utilizar as teclas de atalho Ctrl +
N ou pelo menu, acessando a opção ‘File’ e depois selecionando ‘New Scene’. A
figura 30 demonstra a área da cena criada. Podemos observar na figura 30 que
além da cena em branco, as guias das views Game e Console, na view Scene temos a
visão da cena projetada de maneira rápida e fácil (WELLS, 2020).
213
FIGURA 30 – ÁREA DA VIEW SCENE
FONTE: Wells (2020, p. 8)
É importante que, enquanto formos criando as cenas de nossos projetos,

irmos salvando-o, pois no Unity “não temos apenas um arquivo gigante com
todos os ativos do projeto, mas vários arquivos para cada ativo” (BORROMEO,
2020, p. 81). A Figura 31 demonstra um exemplo dos assets que podemos ter em
nossos arquivos de cena.
FIGURA 31 – ASSETS DA CENA
FONTE: Borremeo (2020, p. 81)
Para salvar nossas cenas, podemos utilizar o menu ‘File’ ou as teclas de

atalho Ctrl + S. Caso não tenhamos definido o local que será salvo nosso projeto
quando o criamos, uma janela será exibida para escolhermos o local que iremos
armazenar nosso projeto.
214
5 TRANSIÇÃO DE TELAS
A transição de tela é utilizada para se passar de um menu para uma fase,
por exemplo, mas, também, as transições podem ocorrer nas cenas, assim como
na criação das animações dos personagens e elementos do cenário do jogo.
A maioria das GUIs de jogos pode ser dividida em dois tipos: menu
e no jogo. O menu GUI é o que o jogador interage para preparar o
jogo para jogar - ou seja, optar por iniciar um novo jogo ou continuar
um jogo anterior, configurar configurações ou navegar para um jogo
multiplayer para participar. A GUI do jogo é sobreposta à visão do
jogador sobre o mundo do jogo.
As GUIs do jogo tendem a não mudar muito sua estrutura e geralmente
contêm leituras sobre informações importantes: quantas flechas estão
na aljava do jogador, quantos pontos de acerto eles têm e a distância
até o próximo objetivo. Os menus, no entanto, tendem a mudar
significativamente; o menu principal geralmente tem uma aparência
muito diferente da tela de configurações, porque eles têm requisitos
estruturais diferentes (MANNING; BUTTFIELD-ADDISON, 2017, p.
369).
DICAS
Neste vídeo podemos conhecer mais sobre as transições de tela no Unity:

<https://www.youtube.com/watch?v=Z4iQ-zxvJjU>.
Podemos criar a transição de tela do nosso jogo, utilizando um diagrama

de estados, conforme exemplificado pela figura 32, o qual também pode ser
usado para observar o que será exibido quando o jogo é pausado, ou quando
é acessado as opções/ configurações do jogo. Fowler e Chu (2017), diz que o
diagrama “mostra que o jogador pode ir do estado de jogo (ou equivalente, do
estado invisível do menu) ao menu principal de pausa e, a partir daí, a uma tela
de créditos ou um menu de opções, ou o jogador pode sair do jogo”. Todos os
estados podem realizar a transição de uma tela para outra. A exceção é quando a
opção ‘Quit’ (Fechar) é escolhida e temos um estado de saída do jogo (FOWLER;
CHU, 2017).
215
FIGURA 32 – DIAGRAMA DE ESTADOS
FONTE: Fowler e Chu (2017, p. 259)
No Unity não temos o conceito de uma tela de conteúdo, mas sim uma
coleção de objetos que estão presentes na tela. Quando desejamos mover de uma
tela para outra, ou seja, realizar uma transição, necessitamos inicialmente alterar
a tela em que a câmera está se movendo no momento ou mover a câmera para
que ela troque seu foco para algo diferente ao que estava sendo observado. Como
observado por Manning e Buttfield-Addison (2017, p. 369), “(...) é importante ter
em mente é mover a câmera- era separadamente da tela exige que o modo de tela
seja definido como Espaço Mundial; tanto no espaço de tela - sobreposição quanto
no espaço de tela - câmera, a interface do usuário sempre aparece diretamente na
frente da câmera”.
6 ILUMINAÇÃO
A iluminação está presente em todos os objetos que criarmos em nosso
jogo, sendo que para cada objeto podemos definir propriedades de iluminação.
Takoordyal (2020) define a iluminação como:
A iluminação é muito importante em um videogame. A posição e

rotação de uma luz principal determina a parte dos GameObjects que
são visíveis, em relação ao seu ângulo com os raios de direção, são
lançadas a partir da fonte de luz e, portanto, a direção em que as
sombras são lançadas, bem como o tamanho delas.
Uma cena vazia no Unity terá, por padrão, um GameObject conhecido
como Luz Direcional, com um componente Luz que fornece luz
uniforme em uma única direção, simulando algo semelhante a um
sol. Se não houvesse fontes de luz em uma cena, o mundo estaria
completamente escuro (TAKOORDYAL, 2020, p. 72).
Pierce (2012, p. 52) corrobora com essa definição ao afirmar que “um dos
seus ativos mais importantes no Unity é a iluminação“, e ao utilizar os efeitos de
iluminação podemos revolucionar nossos jogos. O Unity possui um mecanismo
de iluminação muito sofisticado, que pode lidar com luzes dinâmicas, luzes de
216
cozimento com o sistema de iluminação Beast e luzes adiadas. Como podemos

observar na figura 33, podemos editar as propriedades da iluminação. Essas
configurações podem serem editas para os objetos e cenas.
FIGURA 33 – CONFIGURAÇÕES DE ILUMINAÇÃO
FONTE: Takoordyal (2020, p. 73)
No Unity, temos três tipos de iluminação dinâmica, sendo as luzes:

direcional, de ponto (ou pontuais) ou local (spot). Wiebe (2011) ressalta a diferença
entre cada um destes tipos:
• Direcional: este é um tipo de iluminação que está indefinidamente

distante e afeta tudo na cena, como a luz do sol.
• Ponto: este é um tipo de iluminação que afeta tudo dentro do
alcance de sua posição na cena.
• Local: este é um tipo de iluminação que afeta tudo em forma de
cone, definido por seu ângulo e alcance desde sua posição na cena
(WIEBE, 2011, p. 16).
A iluminação também é utilizada quando utilizamos sobra nos objetos.

Caso não utilizarmos as luzes, os objetos aparecerão escuros e sem vida, uma
vez que a iluminação traz vida ao jogo e as cenas e as sombra criadas adicionam
profundidade ao mundo do jogo. O mapa de luz (Lightmapping) pode ser utilizado
para causar uma iluminação dinâmica, gerando os mapas de luz, porém, eles
217
demoram para serem gerados. Os mapas de luz são criados principalmente para
que não se tenha um desempenho ruim do jogo em dispositivos mais simples ou
antigos (PIERCE, 2012; FOWLER; CHU, 2017).
NTE
INTERESSA
Neste vídeo podemos conhecer mais sobre a iluminação dos jogos no Unity:
<https://www.youtube.com/watch?v=G6O3DA3nZZY>.
7 EXIBIÇÃO DO JOGO
Ao exibir nosso jogo, podemos observar o resultado final e até alguns
problemas que podemos corrigir, com isso, não precisamos criar uma versão para
ver como anda nosso desenvolvimento. No Unity, para exibir o jogo, basta acessar
a view Game. Utilizando os controles exibidos pela 34, podemos reproduzir,
pausar ou avançar o jogo.
FIGURA 34 – CONTROLES DE EXIBIÇÃO DO JOGO
FONTE: Pierce (2012, p. 25)
Pierce (2012) resume a ação que cada botão executa:
O Play controle fará com que o jogo comece a jogar. Se você quiser
parar e olhar para as coisas, pressione o Pausa botão. Quando o Pausa
botão é pressionado, o Unity mudará para Cena visualize (a menos
que já seja exibido) para que você possa examinar os detalhes da
cena. Pressionando Pausa novamente fará com que o jogo continue
de onde parou. Se, enquanto estiver em pausa, você quiser determine
o que acontecerá no próximo ciclo, você pode pressionar o botão
Play. Pressionando o botão Avançar enquanto um jogo estiver sendo
jogado fará com que ele entre em um estado pausado (PIERCE, 2012,
p. 25).
O jogo é exibido através da câmera e irá mostrar o que o jogador veria

quando estivesse jogando, porém, ao vermos no Unity, nossa exibição do jogo
somente é interativa se o botão de reprodução (Play) estiver ativo (BUTTFIELD-
ADDISON et al., 2019). Na figura 35 temos um exemplo de como o jogo será
exibido. Podemos observar na figura que diversos controles são exibidos para
que podemos alterar as configurações de visualização do jogo.
218
FIGURA 35 – EXEMPLO DE EXIBIÇÃO DO JOGO NO UNITY
FONTE: Fowler e Chu (2017, p. 50)
Através do menu Exibir (Display), iremos controlar o que será exibido na

tela. Em Free Aspect, podemos trocar a resolução e proporção da exibição do jogo.
Ao utilizar o botão deslizante Scale, podemos aumentar ou diminuir o zoom de
visualização do jogo, se clicarmos em Maximize On Play, o jogo será maximizado,
preenchendo toda a janela do editor quando o jogo estiver em reprodução. O
botão Mute permite desabilitar o som do jogo. Além destas ações, podemos ver as
estatísticas do jogo ao clicar no botão Stats, as quais serão exibidas em um painel
sobressalente e, por último, temos o botão Gizmos, o qual nos permite controlar os
objetos em cena (BUTTFIELD-ADDISON et al., 2019).
8 MELHORAR O JOGO
Para melhorar nossos jogos, devemos sempre ter as versões mais recentes e
estáveis do ambiente, dos plugins e assets que utilizarmos em seu desenvolvimento.
É claro que em algum momento devemos dar o desenvolvimento como encerrado
e nos dedicar a sua promoção e divulgação. Por isso, seguir o cronograma do
seu desenvolvimento à risca é uma boa prática, além de não adicionar a todo
momento novos recursos, fases e desafios. É normal encontrarmos jogos infinitos,
mas uma hora os jogadores cansam da mesmice e trocam por outro.
A melhoria contínua do jogo, ou seja, a inclusão de novas fases e novas

tecnologias devem ser realizadas, ao ponto em que a cada versão lançada gera
novidades e são apresentadas ao jogador, além de melhorias gráficas e de
jogabilidade, assim como na história do jogo.
O feedback do jogador pode implicar que você ou a equipe reconheça

problemas ou melhorias não identificados até o momento. O mesmo ocorre
quando a equipe de desenvolvimento informa o que foi alterado. Borromeo
(2020) diz que:
219
O feedback é um tópico importante nos videogames. Ele fornece

informações valiosas ao jogador, como a localização dos inimigos,
se houver uma configuração de som 3D, tiro distante representado
por focinho pisca em segundo plano, barras de vida indicando que o
jogador está prestes a morrer, animações que reagem de acordo com
os movimentos do jogador, e assim por diante (BORROMEO, 2020, p.
577).
A otimização do nosso jogo é uma das últimas atividades a serem

executadas. Sinicki (2017, p. 199) afirma que a otimização é “fazer seu jogo
funcionar sem problemas e seja fácil de editar, melhorar e atualizar daqui para
frente”. As técnicas de otimização do Unity permitem melhorar o jogo e seu
desempenho. O desempenho do jogo pode ser melhorado ao otimizar os gráficos,
o processamento e a memória (BORROMEO, 2020). Essas técnicas são aplicadas
pelo Unity quando iniciamos o processo de depuração do jogo, ao “ativar o modo
de depuração no Inspetor podemos ficar de olho em todas as variáveis públicas
e privadas durante o tempo de execução, certificando-se de que nenhuma
variável receba um valor inesperado” (WELLS, 2020, p. 104). Para ativar o modo
de depuração, basta seguir o exemplo apresentado pela figura 36, sendo que
podemos ativá-lo para analisar o jogo e por objetos.
FIGURA 36 – ATIVANDO O MODO DE DEPURAÇÃO
FONTE: Wells (2020, p. 104)
9 PUBLICANDO O JOGO
Já vimos como salvar nosso jogo no Tópico 2. Para a versão iOS a sequência
é similar. No entanto, não é somente publicar no App Store e pronto, pois “Apple
App Store exige que todos os jogos publicados tenham algum tipo de opção de
login social (como Facebook, Google etc.) e também para oferecer suporte à entrada
da Apple . Eles simplesmente não admitirão seu jogo se você não cumprir”
(BORREMEO, 2020, p. 524).
Além de termos criado o perfil de desenvolvedor e uma máquina Mac

para publicar nosso jogo, uma taxa anual deve ser paga para que nosso jogo seja
incluído na App Store e permaneça na loja.
220
DICAS
Criar um perfil de desenvolvedor Apple é uma atividade que requer

muitos detalhes e informações. Confira o vídeo a seguir: https://www.youtube.com/
watch?v=L7SSg05JvZQ.
Para publicar, é utilizado o iTunes Connect (itunesconnect.apple.com).

Se “você pretende vender seus aplicativos, também será obrigado a acessar o
Acordos, impostos e bancos seção e coloque suas informações bancárias”
(DORAN, 2017). A figura 37 demonstra a tela inicial do iTunes Connect.
FIGURA 37 – ITUNES CONNECT
FONTE: Doran (2017, p. 327)
Após incluir os dados bancários (se aplicável), devemos acessar My App

para incluir nosso jogo. Na figura 38, na primeira imagem, temos a tela com os
nossos aplicativos. Ao clicar em +, uma janela sobressalente é exibida, a qual
devemos preencher as informações do nosso jogo, conforme podemos observar
na segunda imagem da figura 38.
Neste menu, preencha iOS como seu Plataforma e coloque o nome

do seu jogo abaixo Nome (A Apple exige que cada nome seja único,
portanto, lembre-se de que você não poderá usar). (...) Debaixo Língua
Primária, selecione Inglês (EUA) e depois selecione o seu ID do pacote
e depois abaixo SKU colocar em um identificador (...). Então, clique no
Criar botão. (DORAN, 2017, p. 329).
221
FIGURA 38 – ADICIONANDO UM NOVO APLICATIVO
FONTE: Doran (2017, p. 328-329)
Na sequência, uma nova tela (primeira imagem da figura 39) será exibida
para o preenchimento das informações do jogo, onde devemos definir o nome,
a página oficial, um subtítulo (se aplicável) e definir sua categoria. Em seguida,
devemos criar uma breve descrição do jogo, (segunda imagem da figura 39).
FIGURA 39 – INFORMAÇÕES DO APLICATIVO – CATEGORIA - DESCRIÇÃO
FONTE: Doran (2017, p. 330-331)
Na sequência, devemos incluir o ícone e as imagens do jogo, que serão

apresentadas aos usuários da App Store, conforme podemos observar na figura
40.
222
FIGURA 40 – ADICIONANDO UM NOVO APLICATIVO – ÍCONE E IMAGENS
Por último, devermos editar as informações sobre o preço e a disponibili-

dade (Figura 41). Caso o jogo seja gratuito, deixe como USD 0, caso ele venha ser
pago, inclua o valor desejado.
FIGURA 41 – ADICIONANDO UM NOVO APLICATIVO – PREÇO E DISPONIBILIDADE
NTE
INTERESSA
Publicar um aplicativo na App Store pode ser considerado difícil. COnfir ao

vídeo a seguir: https://www.youtube.com/watch?v=NV9qv4YVNtE.
223
No caminho até aqui conhecemos um pouco sobre o ambiente de

desenvolvimento de jogos Unity. É claro que não o conhecemos totalmente, mas
ao longo de nossa trajetória podemos conhecer o básico dos seus aspectos no
desenvolvimento de jogos utilizando este ambiente. Em alguns outros ambientes,
a maioria das ações que realizamos podem ser aplicadas. Por isso, utilize-o sem
medo, nada que um Ctrl + Z ou iniciar um novo projeto não resolva. Explore-o,
assim como outros ambientes para o desenvolvimento de jogo. Explore seus
recursos e decida qual o melhor software para desenvolver seus jogos.
224
DESENVOLVIMENTO DE JOGOS: COMO DOCUMENTAR SEU CÓDIGO
Anderson Queiroga
Ter bom conhecimento de uma linguagem específica de programação, ser

capaz de escrever códigos de alta complexidade, convenção de nomes, classes,
variáveis, etc. são pontos importantes para um profissional da área de criação ou
manutenção de software. Além dessas características, é necessário que o profissional
tenha outras qualidades que farão grande diferença durante o andamento de
um projeto, saber documentar desde a proposta até a entrega do projeto, expor
as ideias através de diagramas e fluxos. Elementos estes que ajudaram durante
os passos de uma equipe durante o início do desenvolvimento ou durante uma
possível manutenção, são importantes no desenvolvimento de qualquer tipo de
sistemas, e claro, não poderiam deixar de ser importantes no desenvolvimento
de jogos. Neste artigo mostraremos alguns elementos relevantes para uma boa
documentação de projeto voltado para jogos, uma breve representação da parte
inicial de um projeto a partir da proposta, passando por uma descrição de alguns
diagramas e chegando ao início da codificação. O objetivo desse documento não
é um detalhamento de uma linguagem específica, de um banco específico e sim
as aptidões necessárias para um bom andamento de um projeto de jogo, práticas
e situações que são consideráveis no desenvolvimento de qualquer sistema.
Conforme o decorrer desse jogo, cada fase alcançada ficará mais difícil,
o jogo tem um perfil de aventura com foco educativo; será para plataforma web
com elementos do mundo real. Este jogo é para fins acadêmicos e não comerciais.
Serão implementadas funcionalidades como ranking de jogadores e para isso será
necessário conexão com um bando de dados.
A principal vantagem desse jogo é que será de fácil entendimento e

jogabilidade simples, onde o único objetivo é fazer com que o personagem resgate
o máximo de livros com suas limitações de andar para frente, para trás e saltar.
Relato do Processo de Desenvolvimento
A primeira etapa de um projeto é a proposta, momento onde é exposta

para o cliente qual a intenção que levou a necessidade do desenvolvimento
de um sistema. No PMBOK, que é um manual que descreve um universo de
conhecimentos para gerenciamento de projetos, o documento que representa esse
momento é o “project charter”. Vamos elencar os passos que fazem parte desse
documento.
225
Passo 1 - Designação: onde são mostradas as responsabilidades e

competências de cada envolvido no projeto, onde deve ser descrito exatamente
como vai ser sua participação no projeto, exemplo, quem é o gerente do projeto,
como ele vai integrar toda equipe, como ele vai cumprir os prazos, etc.
Passo 2 - Escopo: descreve o objetivo metas e custos de todo o projeto.

O objetivo é descrever exatamente qual intenção do jogo e o que o jogador terá
que fazer para chegar aos limites do jogo. Nas metas, descrever custos e prazos
necessários para a gerência, requisitos, desenvolvimentos, testes e encerramento
do projeto.
Passo 3 - Premissas: informa o que é indispensável para a realização de

todo o trabalho. Exemplo: equipamentos, infraestrutura, softwares e licenças
necessárias.
Passo 4 - Riscos: a seguir, temos uma tabela simplificada com grupos de

risco, suas descrições, e seus níveis (Tabela 1).
Grupo de Nível do
Descrição de riscos
Riscos Risco
Falta de dedicação total dos funcionários
Alto
envolvidos no projeto
Organização
Análises e capturas de informações erradas
Baixo
fornecidas pelo cliente
Exceder o valor estimado para a conclusão do
Baixo
Fundos projeto
Solicitação de empréstimos Baixo
Perda de colaboradores relacionados ao projeto Médio
Pessoal Eliminação de pessoas de nível hierárquico da
Alto
empresa
Tempo Tempo suficiente para a homologação do Projeto Médio
E se os fundos para o projeto estiverem
comprometidos "O que pode garantir fundos Baixo
Riscos do adequados"?
Negócio
Não foram realizados os pré-requisitos para a
Baixo
implantação do sistema
O escopo do projeto continua sendo aumentando. Baixo
Solicitação de customizações de programas
Alto
durante o período de adaptação do sistema
Riscos Interface de difícil administração e visualização Baixo
Técnicos Falta de preparo técnico dos funcionários na
Médio
utilização do sistema
A solução de o sistema ser muito complexa para a
Baixo
organização.
226
Danos físicos aos equipamentos de tecnologia Médio

Riscos da
Tecnologia Dependência de suporte técnico de equipamentos
Médio
com contrato de manutenção
Suporte com contrato de manutenção não possui
Alto
Riscos de componentes para substituição
dependência Legalização de licenças de softwares Baixo
externa Comprometimento de entrega do hardware com os
Alto
fornecedores
Descrição de Grupos de Risco no Desenvolvimento do Jogo (Project Management Docs, 2013 -
http://www.projectmanagementdocs.com/)
Passo 5 - Principais fases do projeto: são descritas na Tabela 2 as atividades

e o prazo para finalização de cada uma. Assim podemos identificar o início, como
está o andamento, se houve atrasos ou não e a finalização de todo o projeto.
Descrição das Atividades propostas para o desenvolvimento do jogo
Passo 6 - Principais envolvidos: indicação da participação de cada envolvido-

quem é o gerente, o responsável pelos custos, pelo escopo, riscos, qualidade, etc.
Para cada área deve ser indicado o nome do principal envolvido.
Passo 7 - Comentário: breve descrição sobre o desenvolvimento do projeto,

no caso desse documento trata-se da prática em projetos de jogos - “O jogo possui
uma série de controles e processos que serão desenvolvidos dentro de um curto
espaço de tempo e com grande qualidade e tecnologia para exceder as necessidades
do patrocinador (sponsor) controlando de forma ágil o processo e proporcionando
maior agilidade e qualidade dos participantes do jogo”.
Passo 8 - Cenário: conjunto de informações que darão uma primeira visão do

sistema, por exemplo, na interface do sistema devem ser apresentadas as primeiras
interfaces, momento onde os patrocinadores terão suas primeiras percepções no
que diz respeito ao jogo.
Passo 9 - Diagrama de casos de uso: neste caso demonstraremos um

diagrama de casos de uso para a proposta de desenvolvimento de um jogo. Esse
diagrama mostra as atividades de um ator dentro do ambiente do jogo, detalha
quais as funcionalidades dele e o que o jogador poderá fazer dentro do jogo em
questão (Figura 1).
227
Diagrama de Casos de Uso desenvolvido no contexto do jogo
Passo 10 - Diagrama de classes: representa as classes necessárias para

o desenvolvimento do sistema, muito útil para o programador, pois simplifica
a escrita do código e incrementa as funcionalidades descritas no diagrama de
casos de uso. No início do desenvolvimento de qualquer sistema, isso é uma fase
muito importante, é uma ótima representação gráfica dos códigos em orientação
a objetos, e também um primeiro esboço das funcionalidades de um programa,
e claro, não poderia deixar de ser menos importante no desenvolvimento de um
jogo (Figura 2).
Diagrama de Classes desenvolvido no contexto do jogo
228
Passo 11 - Tabela de requisitos: trata-se da tabela com informações e

requisitos necessários para o funcionamento correto do sistema (Tabela 3).
Funcionalidades estas que envolvem a segurança do sistema (controle de acesso,
validação de usuário, etc.), funcionalidades de configuração, etc.
Definição de Requisitos Funcionais e Não-Funcionais Associados no

Contexto do Jogo, baseado no Processo Unificado – UP (Wazlawick, 2013)
Passo 12 - Um sistema geralmente tem conexão com um bom banco

de dados. O projeto inicial de um BD é feito através do Diagrama Entidade
Relacionamento (DER). Com esse diagrama em mãos é possível entender o
processo de normatização do banco. Na Figura 3 temos um simples DER com
script SQL. No caso de um jogo simples, geralmente essas informações só dizem
respeito à parte de controle de acesso e andamento do jogo. Na figura consta a
parte de usuário e navegação no contexto do jogo.
Diagrama Entidade Relacionamento desenvolvido no contexto do jogo
Na Listagem 1 temos um script SQL para banco de dados MySQL, que

implementa o diagrama entidade relacionamento (DER) descrito anteriormente.
229
Listagem 1. Script SQL para criação das tabelas de banco de dados do jogo
Passo 13 - Para finalizar, na Figura 4 temos um fluxograma que trata-se

de uma prática que auxilia na programação. Basicamente envolve a lógica do
funcionamento do sistema através de um diagrama.
230
Início
Ator Pega qtdLivros = qtdLivros % qtdVidas=
livros? qtdLivros+1 100 = 0? qtdVidas+1
Criar Save
Ator é qtdLivros qtdLivros = 0
atacado? = 0?
Criar Usuário Usuário
existe?
qtdLivros %
0000 = 0
Carregar qtdVidas =
informações do save qtdVidas-1 qtdVidas = 0?
Fase = Fase +1
Retorna informações
da fase (vidas, pontos) Game Over!!!
Iniciar fase Jogar Atualizar save Fase > 3

novamente?
Animar ator Venceu!!!
End
Figura 4. Fluxograma representando o funcionamento do jogo
Uma boa documentação reduz riscos em momentos iniciais do projeto

e facilita a manutenção, é útil também na integração de novos profissionais.
Boas práticas no desenvolvimento de qualquer sistema são sempre bem vindas
e lógico que as técnicas não param por aqui, existem muitas outras técnicas e
benefícios relacionados a cada um dos itens que discutimos aqui; este artigo dá
apenas uma visão de uma pequena parte das práticas necessárias para um bom
desenvolvimento de um projeto.
FONTE: QUEIROGA, A. Desenvolvimento de Jogos: Como documentar seu código. DevMedia.

2013. Disponível em: https://www.devmedia.com.br/desenvolvimento-de-jogos-como-docu-
mentar-seu-codigo/29565. Acesso em: 25 ago. 2021.
231
RESUMO DO TÓPICO 3
• Jogos desenvolvidos pelo ambiente Unity podem utilizados em

multiplataformas, bastando a criação de sua versão.
• Podemos criar um projeto diretamente no Unity, ou utilizar o Unity Hub,

que também poderá ser utilizado para gerenciar nossos projetos e recursos
baixados/instalados.
• O background ou plano de fundo pode ser fixo ou dinâmico, além de podermos

criar uma para cada ambiente, fase ou nível de dificuldade. A logo deve ser
criada ainda na fase de pré-produção, assim como os backgrounds utilizados
(tipo fixo). O ícone deve representar a essência do jogo, e ele será utilizado
quando o jogo for publicado nas lojas de aplicativos.
• As transições de tela são realizadas principalmente na sequência de passagem

de fases. Ao iniciar o jogo e ao acessar as configurações, podemos representar
essas transições utilizando o diagrama de telas, onde podemos identificar
todas a telas e como deverá ser seu comportamento ao passar de uma para
outra.
• Pode-se escolher três opções de iluminação no Unity: a direcional, a pontual

ou a local.
• Ao se exibir o jogo no Unity, temos uma perspectivas do que estamos criando

e da visão do jogador, podemos utilizar os controle para controlar a exibição
do jogo, assim como podemos personalizar as propriedades de exibição para
analisar o jogo sob diferentes configurações.
• O feedback é importante no desenvolvimento dos jogos, uma vez que fornece

informações aos jogadores e os jogadores podem contribuir com a melhoria
do jogo.
232
• Para se publicar um jogo na Apple App Store é necessário que tenhamos um
perfil de desenvolvedor, que seja publicado utilizando uma máquina Mac e
que seja paga uma taxa anual.
CHAMADA

233
AUTOATIVIDADE
1 As cenas do jogo é onde iremos representar o mundo do jogo que estamos

desenvolvendo, onde serão inseridos os objetos, a física e a iluminação.
Podemos criar cenas de três maneiras deferentes. Sobre essas três maneiras
de criação de cena, assinale a alternativa CORRETA:
a) ( ) Modelo vazio, a partir de um recurso em cena ou a partir da cena atual.

b) ( ) Modelo personalizado, a partir de um objeto em cena ou a partir de um
objeto atual.
c) ( ) Modelo personalizado, partir de um objeto em cena ou a partir da cena
atual.
d) ( ) Modelo vazio, a partir de um recurso em objeto ou a partir da objeto
atual.
2 A transição de tela é utilizada quando passamos do jogo para o menu ou

vice e versa, assim como acessamos as configurações do jogo. Pode ser
utilizado um diagrama para criar ou representar como serão realizadas as
transições de tela. Sobre o diagrama, assinale a alternativa CORRETA:
a) ( ) Fluxograma.
b) ( ) Diagrama de Transições.
c) ( ) Diagrama de Estados.
d) ( ) Diagrama de Status.
3 A iluminação é um dos elementos utilizados nas cenas e nos objetos mais

importantes, sendo que a posição e a rotação determinam qual a parte
do GameObject será visível, sem a iluminação o jogo seria escuro e sem
vida. Podemos utilizar três tipos de iluminação no Unity. Sobre o exposto,
classifique V para as sentenças verdadeiras e F para as falsas:
( ) Focal, sequencial e local.

( ) Focal, pontual e central.
( ) Direcional, pontual e local.
a) ( ) V – F – F.
b) ( ) V – F – V.
c) ( ) F – V – F.
d) ( ) F – F – V.
234
4 A visualização do jogo na view Game nos possibilita analisar o que vem
sendo desenvolvido sob a perspectiva do jogador, onde podemos utilizar
os controle de exibição para iniciar o jogo. Disserte como podemos utilizar
os três botões de controle de exibição do jogo.
5 Uma cena do jogo pode ser criada a qualquer momento em que estamos
desenvolvendo, por padrão o Unity cria sempre uma cena em branco, mas
pode-se ser criadas outros tipos de cena. Neste contexto, disserte sobre a
importância de se criar as cenas em nossos jogos.
235
REFERÊNCIAS
AGRELA, L. O que é realidade aumentada, chave do sucesso de Pokémon Go.
EXAME. 2016. Disponível em: https://exame.com/tecnologia/o-que-e-realidade-
-aumentada-chave-do-sucesso-de-pokemon-go/. Acesso em: 25 ago. 2021.
BLANCO, J. Zo. Uma abordagem holística para o desenvolvimento de softwa-

re multiplataforma. 2020. Disponível em: https://repositorio.ufscar.br/bitstream/
handle/ufscar/13517/TeseVFinal.pdf. Acesso em: 22 ago. 2021.
BORROMEO, N. A. Hands-On: Unity 2020 Game Development. Birmingham:

Packt Publishing, 2020.
BUTTFIELD-ADDISON, P. et al. Unity Game Development Cookbook: From

the Basics to Virtual Reality. Sebastop: Editora O’Reilly Media, 2019.
CARDOSO, B. 9 em cada 10 brasileiros usam celular Android, diz relatório do

Google. TechTudo. 2020. Disponível em: https://glo.bo/3bxeumo. Acesso em: 22
ago. 2021.
CHANDLER. H. M. The Game Production Toolbox. Boca Raton: Editora CRC

Press, 2020.
CHANDLER, H. M. Manual de Produção de Jogos Digitais. 2ª ed. Porto Alegre,

Bookman, 2012.
CHANDLER, H. M. The Game Production Handbook: 3rd Edition. Burlington:

Editora Jones & Bartlett Learning, 2013.
CHANDLER, H. M. The Game Production Handbook: Second Edition. Burl-

ington: Editora Jones & Bartlett Learning, 2009.
COHEN, D. S.; BUSTAMANTE II, Sergio A.. Producing Games: From Business
and Budgets to Creativity and Design. Burlington: Editora Elsevier, 2010.
DORAN, J. P. Unity 2017 Mobile Game Development: Build, deploy, and mon-
etize games for Android and iOS with Unity. Birmingham: Packt Publishing,
2017.
EDUARDO, D. Porque Utilizar o Unity? 2015. Disponível em: https://www.eng.

com.br/artigo.cfm?id=17. Acesso em: 22 ago. 2021.
FERRÃO, C. Introdução à Unity. 2020. Disponível em: https://www.ufsm.br/

pet/sistemas-de-informacao/2020/07/07/introducao-a-unity/. Acesso em: 28 ago.
2021.
236
FLEURY, A. et al. I Censo da Indústria Brasileira de Jogos Digitais, com Voca-
bulário Técnico sobre a IBJD. 2014. Disponível em http://www.abragames.org/
uploads/5/6/8/0/56805537/i_censo_da_industria_brasileira_de_jogos_digitais_2.
pdf. Acesso em: 29 jun. 2021.
FOWLER, A.; CHU, P. Learn Unity 2017 for iOS Game Development Create
Amazing 3D Games for iPhone and iPad. Second Edition. New York: Apress,
2017
HOCKING, J. Unity in Action: Multiplatform game development in C# - Second

Edition. Shelter Island: Manning Publications, 2018.
IRISH, D. The Game Producer’s Handbook. Boston: Editora Thomson, 2005.
JAMES, D. Android™ Game Programming For Dummies. Hoboken: John Wi-

ley & Sons, 2013.
KUCERA, J. R. F. Desenvolva jogos com a Unity 3D. DevMedia. 2013. Disponí-

vel em: https://www.devmedia.com.br/desenvolva-jogos-com-a-unity-3d/29125.
Acesso em: 22 ago. 2021.
LEAL, F. Tutorial de Física no Unity – Parte 1 – RigidBody. 2016a. Disponível

em: https://www.fabricadejogos.net/posts/tutorial-de-fisica-no-unity-parte-1-ri-
gidbody/. Acesso em: 2 set. 2021.
LEAL, F. Tutorial de Física no Unity – Parte 2 – Colliders. 2016b. Disponível

em: https://www.fabricadejogos.net/posts/tutorial-de-fisica-no-unity-parte-
-2-colliders/. Acesso em: 2 set. 2021.
LLAGOSTERA, E. Documentação e GDDs. 2016. Disponível em: http://puccjo-

gos.github.io/proj1-2016-2s/aulas/documentacao-gdd/. Acesso em: 22 ago. 2021.
MANNING, J; BUTTFIELD-ADDISON, P. Mobile Game Development with

Unity: Build Once, Deploy Anywhere. Sebastop: Editora O’Reilly Media, 2017.
MARINHO, J. Apple ultrapassa 1 bilhão de usuários de iPhone. 2020. Disponí-

vel em: https://www.tecmundo.com.br/dispositivos-moveis/205904-apple-ultra-
passa-1-bilhao-usuarios-iphone.htm. Acesso em: 9 set. 2021.
MASTER.D. O que é o Unity e para que serve? 2021. Disponível em: https://
www.masterd.pt/noticias/o-que-e-o-unity-e-para-que-serve. Acesso em: 26 ago.
2021.
MENGE, L. Desenvolvendo Jogos para iOS. 2013. Disponível em: https://www.

cin.ufpe.br/~game/aulas/Jogos-iOS-2013.pdf. Acesso em: 9 set. 2021.
237
PANKIEWICZ, I. Consumidores gastaram US$ 40 bilhões na App Store no
primeiro semestre de 2021. 2021. Disponível em: https://mundoconectado.com.
br/noticias/v/20275/consumidores-gastaram-us-40-bilhoes-na-app-store-no-pri-
meiro-semestre-de-2021. Acesso em: 9 set. 2021.
PASSOS, E. B. et al. Desenvolvimento de jogos com unity 3d. In: VIII Brazilian
Symposium on Games and Digital Entertainment. 2009. Disponível em: https://
www.sbgames.org/~sbgameso/papers/sbgames09/computing/tutorialCompu-
ting2.pdf. Acesso em: 22 ago. 2021.
PIERCE, G. Unity iOS Game Development: Beginner's Guide - Develop iOS

games from concept to cash flow using Unity. Birmingham: Packt Publishing,
2012.
PRODUÇÃO DE JOGOS. Unity – Guia Completo sobre a Game Engine. 2018.

Disponível em: https://producaodejogos.com/unity/. Acesso em: 22 ago. 2021.
ROGERS, S. Level Up: The Guide to Great Video Game Design. Chichester: John
Wiley & Sons, 2010.
ROSÁRIO, F. C. do. Desenvolvimento de Aplicativos Móveis Multiplata-

forma. 2015. Disponível em: http://repositorio.roca.utfpr.edu.br/jspui/bitstre-
am/1/14106/1/MD_COADS_2015_2_05.pdf. Acesso em: 22 ago. 2021.
SAKUDA. L. O.; FORTIM, I. (Org.). 2o Censo da Indústria Brasileira de Jogos

Digitais. Ministério da Cultura: Brasília, 2018.
SCHAUKOSKI, E. D. Análise comparativa de frameworks open source para o

desenvolvimento de jogos multiplataforma. 2018. Disponível em: http://reposi-
torio.unesc.net/bitstream/1/8154/1/EDERSON%20DUARTE%20SCHAUKOSKI.
pdf. Acesso em: 22 ago. 2021.
SCHMITZ, L. Análise de Ferramentas de Desenvolvimento Multiplataforma

para Criação de Aplicativos Móveis. 2016. Disponível em: https://repositorio.
unisc.br/jspui/handle/11624/2149. Acesso em: 22 ago. 2021.
SINICKI, A. Learn Unity for Android Game Development: A Guide to Game

Design, Development, and Marketing. Guildford: Apress, 2017.
SPROVIERI, I. Como baixar a unity 2021 [Atualizado]. 2021. Disponível em: ht-
tps://www.crieseusjogos.com.br/como-baixar-a-unity-2021-atualizado/. Acesso
em: 25 ago. 2021.
TAKOORDYAL, K. Beginning Unity Android Game Development From Be-

ginner to Pro. Apress: New York, 2020.
238
TOLLIN, M.; GOMES, R.; LEITE, A.. Desenvolvimento de Jogos para Android:
Explore sua imaginação com o framework Cocos2D, Casa do Código, 2012.
UNITY DOCS. Documentation: The Toolbar. 2021a. Disponível em: https://docs.

unity3d.com/Manual/Toolbar.html. Acesso em: 28 ago. 2021
UNITY DOCS. Documentation: GameObjects. 2021b. Disponível em: https://

docs.unity3d.com/Manual/GameObjects.html. Acesso em: 28 ago. 2021.
UNITY DOCS. Documentation: Using Components. 2021c. Disponível em:

https://docs.unity3d.com/Manual/UsingComponents.html. Acesso em: 28 ago.
2021.
UNITY DOCS. Documentation: Prefabs. 2021d. Disponível em: https://docs.

unity3d.com/Manual/Prefabs.html. Acesso em: 28 ago. 2021.
UNITY DOCS. Documentation: Physics Section. 2021e. Disponível em: https://

docs.unity3d.com/Manual/PhysicsSection.html. Acesso em: 28 ago. 2021.
UNITY DOCS. Documentation: Scenes. 2021f. Disponível em: https://docs.uni-

ty3d.com/Manual/Scenes.html. Acesso em: 9 de set. 2021.
UNITY DOCS. Documentation: Creating Scenes. 2021g. Disponível em: https://

docs.unity3d.com/Manual/CreatingScenes.html. Acesso em: 9 de set. 2021.
UNITY DOCS. Documentation: Scenes Template Creating. 2021h. Disponível

em: https://docs.unity3d.com/Manual/scene-templates-creating.html. Acesso
em: 9 de set. 2021.
UNITY. A plataforma líder para criação de conteúdo interativo em tempo real.

2021a. Disponível em: https://unity.com/pt. Acesso em: 22 ago. 2021.
UNITY. Conjunto de ferramentas completo para videogames em 2D e 3D.

2021c. Disponível em: https://unity.com/pt/how-to/difference-between-2D-and-
-3D-games#unity-2d-and-3d-games. Acesso em: 22 ago. 2021.
UNITY. Get Unity. C2021b. Disponível em: < https://unity3d.com/pt/get-unity/

download>. Acesso em: 22 ago. 2021.
WELLS, R. Unity 2020 By Example: A project-based guide to building 2D, 3D,

augmented reality, and virtual reality games from scratch. Third Edition. Bir-
mingham: Packt Publishing, 2020.
WIEBE, R. Unity iOS Essentials: Develop high performance, fun iOS games
using Unity 3D. Birmingham: Packt Publishing, 2011.
239

Desenvolvimento de Jogos Multiplataformas

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Desenvolvimento de Jogos Multiplataformas

Enviado por

Direitos autorais:

Formatos disponíveis

Desenvolvimento

Revisão, Diagramação e Produção:

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

No caminho até aqui você conheceu algumas disciplinas que

No decorrer do livro, você conhecerá sobre os conceitos do

Um dos conteúdos de maior relevância no desenvolvimento de jogos

Na Unidade 1, estudaremos sobre o desenvolvimento de jogos 2D, 3D

Na Unidade 2, abordaremos sobre a produção de jogos, conheceremos

Por fim, na Unidade 3, aprenderemos sobre a documentação de

Prof.ª Tatiana Tozzi

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

Olá, acadêmico! Iniciamos agora mais uma disciplina e com ela

Com o objetivo de enriquecer seu conhecimento, construímos, além do livro

Conte conosco, estaremos juntos nesta caminhada!

TÓPICO 1 — DESENVOLVIMENTO DE JOGOS 2D..................................................................... 3

TÓPICO 2 — DESENVOLVIMENTO DE JOGOS 3D................................................................... 19

TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA.............................. 35

TÓPICO 1 — MÉTODOS DE GERENCIAMENTO DE PROJETO E

TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO........................................................ 93

UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE.............. 159

TÓPICO 1 — KITS DE FECHAMENTO......................................................................................... 161

TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID.......................................... 177

TÓPICO 3 — DESENVOLVIMENTO DE JOGOS PARA IOS................................................... 207

• contextualizar sobre o desenvolvimento de jogos 2D, 3D e multiplataforma;

TÓPICO 1 – DESENVOLVIMENTO DE JOGOS 2D

TÓPICO 2 – DESENVOLVIMENTO DE JOGOS 3D

TÓPICO 3 – DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA

Preparado para ampliar seus conhecimentos? Respire e vamos

No decorrer deste tópico, conheceremos sobre os jogos 2D, através de uma

Então, vamos começar nossa jornada no desenvolvimento de jogos 2D?

2 INTRODUÇÃO AOS JOGOS 2D

Segundo Cople (2019, p. 112), o desenvolvimento de jogos 2D “tem se

FIGURA 1 – EXEMPLO DE IMAGEM EM 2D E 3D

FONTE: <https://bit.ly/2Z4IhzH>. Acesso em: 28 jun. 2021.

Para começar, o que caracteriza um jogo 2D? Um jogo em duas dimensões,

FIGURA 2 – EXEMPLO DE JOGOS 2D e 3D: SUPER MARIO WORLD

FONTE: <https://bit.ly/3C6asNc>. Acesso em: 28 jun. 2021.

Em jogos 2D, é comum o uso de imagens pixeladas para compor os

FIGURA 3 – IMAGEM PIXELADA VERSUS IMAGEM COM QUALIDADE

FONTE: Adaptada de <https://bit.ly/3B5cKuT>. Acesso em: 30 jul. 2020.

Os jogos do Mário ou Sonic não são os únicos tipos de jogos 2D. No

QUADRO 1 – TIPOS DE JOGOS 2D

Como podemos observar no Quadro 1, podemos explorar e criar jogos 2D

O desenvolvimento de jogos é tema do documentário A Revolução dos Games

Atualmente, podemos contar com vários ambientes (software) de mode-

(...) é um editor de jogos 2D desenvolvido pela Scirra Ltda. Ele

FONTE: <https://bit.ly/3ne2lId>. Acesso em: 28 jun. 2021.

A utilização do Construct 2 é simples, pois utiliza um recurso muito

A elaboração de um roteiro para jogos é diferente de um roteiro de um re-

Além do Construct 2, existem outros softwares para desenvolver jogos 2D.

QUADRO 2 – LISTA DE AMBIENTE DE DESENVOLVIMENTO JOGOS 2D

Software Endereço Descrição Gratuito Pago

Também não exige

Como você pode observar, existem vários softwares para se desenvolver

Os personagens ou objetos são representados por sprites, que são imagens

Sprites podem conter, em alguns pontos do desenho, uma transparência,

A Figura 5 demonstra uma folha de sprites do Mario Bros, a folha de estilo

FIGURA 5 – FOLHA DE SPRITES DO MÁRIO BROS

FONTE: <https://i.imgur.com/zhM3VPv.png>. Acesso em: 28 jun. 2021.

Existem várias folhas de sprites prontas e gratuitas na internet. O site Open

FIGURA 6 – DEMONSTRAÇÃO DE FÍSICA EM UMA TELA DE JOGO 2D

FONTE: <https://bit.ly/3Bd3Mw7>. Acesso em: 29 jun. 2021.