livro dev de jogos

Prévia do material em texto

Indaial – 2021
Desenvolvimento 
De Jogos 
multiplataformas
Prof.a Tatiana Tozzi
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.
Impresso por:
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
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á 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 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 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 a documentação de projetos 
de jogos e o desenvolvimento de jogos mobile, em que conheceremos mais o 
desenvolvimento de jogos para sistemas Android e IoS.
 
Bons estudos e sucesso em sua trajetória!
Prof.ª Tatiana Tozzi
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!
NOTA
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!
LEMBRETE
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
1
UNIDADE 1 — 
DESENVOLVIMENTO 
MULTIPLATAFORMA E PLATAFORMAS 
ALTERNATIVAS PARA JOGOS
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
 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.
 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
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorverá 
melhor as informações.
CHAMADA
2
3
TÓPICO 1 — UNIDADE 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 cheio 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 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 é o clássico jogo 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”. 
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
4
No entanto, 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 característica 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.
TÓPICO 1 — DESENVOLVIMENTO DE JOGOS 2D
5
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.
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.
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.
NOTA
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
6
QUADRO 1 – TIPOS DE JOGOS 2D
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?
Tipo do 
jogo
Exemplo 
de jogo Características
2D lateral Super Mário
É o tipo mais conhecido de jogos 2D, onde um 
personagem se move horizontalmente até o fim da 
cena, para isso ele pode correr ou caminhar, no eixo 
Y é utilizando para realizar os pulos. Para simular a 
profundidade é utilizado um efeito chamado scroll, 
para movimentar as imagens do fundo do cenário.
Isométrico Sim City
Nesse tipo de jogo temos uma visão superior dos 
objetos em cena, de todo o cenário e os personagens, 
assim temos um plano mais elevado, sendo os 
objetos em cena sendo apresentados utilizando um 
ângulo de 30 graus com o eixo X.
2D Vertical Space Ship
Esse tipo de jogo 2D tem sua movimentação no 
eixo Y (vertical), é comumente encontrado em 
dispositivos móveis. Os efeitos de scroll, quando 
usado nesse tipo de jogo devem ser feitos com 
cuidado, para que não sejam apresentadas falhas 
entre as junções de imagens utilizadas.
2D 
Estático
Jogo da 
cobrinha
Nesse tipo de jogo a tela não se move em nenhum 
eixo, apenas os ‘personagens’ que se movimento 
dentro dos limites definidos. Esse tipo de jogo é 
o mais simples de ser desenvolvido, porém não 
podemos adicionar muitos elementos na cena. 
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.
DICAS
TÓPICO 1 — DESENVOLVIMENTO DE JOGOS 2D
7
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 
baseado 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 recursomuito 
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).
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
8
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.
DICAS
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
RPG 
Maker
https://www.
rpgmakerweb.
com/
É 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 
exige conhecimento de 
programação, porém 
permite que sejam 
utilizados comandos caso 
o desenvolvedor domine 
programação. Pode ser 
utilizado para desenvolver 
jogos para PC, navegador e 
Android. 
Possui 
uma 
versão 
gratuita.
Versão 
paga com 
recursos 
adicionais.
Construct 
3
https://www.
construct.net/en
Também não exige 
conhecimento de 
programação, utiliza 
o recurso arraste e 
solte para designar os 
comandos. Utilizado no 
desenvolvimento de jogos 
arcade, plataforma, puzzle 
e corrida. 
Possui 
um 
período 
de teste.
Sim.
TÓPICO 1 — DESENVOLVIMENTO DE JOGOS 2D
9
FONTE: Adaptado de Nascimento (2021)
Scratch https://scratch.mit.edu/
É um software para se 
ensinar programação 
ao criar jogos, possui 
conceitos de linguagem 
de programação. Utiliza o 
recurso de arraste e solte 
para definir os comandos, 
é de fácil edição. 
Sim. Não.
Stencyl http://www.stencyl.com/
Também é utilizado para 
ensinar programação 
criando jogos, Além de 
permitir uma variedade 
de ferramentas. Os 
jogos criados têm 
compatibilidade com 
múltiplas plataformas. 
Não. Sim.
Clickteam 
Fusion
https://www.
clickteam.com/
clickteam-
fusion-2-5
Um dos primeiros 
softwares de 
desenvolvimento de 
jogos, não precisa 
de conhecimento de 
programação, porém pode-
se utilizar para realizar 
tarefas mais simples.
Possui 
uma 
versão 
grátis.
Sim.
Game 
Maker 
Studio 2
https://www.
yoyogames.
com/pt-BR/
gamemaker
Possui ferramentas 
avançadas, além de 
permitir a criação de 
elementos no próprio 
programa, podendo ser 
utilizado para vários 
gêneros. Requer um 
conhecimento básico de 
programação
Não. Sim.
Unreal 
Engine
https://www.
unrealengine.
com/
Requer conhecimento 
avançado em modelagem 
e programação. Permite 
criar jogos com altíssima 
qualidade.
Não. Sim.
Unity
https://unity.
com/pt/
solutions/2d
Um dos softwares 
mais utilizados no 
desenvolvimento 
de jogos, requer 
conhecimento avançando 
em programação e 
modelagem. Permite 
criar jogos com altíssima 
qualidade.
Possui 
uma 
versão de 
teste.
Sim.
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
10
Como você pode observar, existem vários softwares para se desenvolver 
jogos 2D. Você pode acessar os endereços e testar cada um deles, a fim 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. 
TÓPICO 1 — DESENVOLVIMENTO DE JOGOS 2D
11
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 
Game Art (https://opengameart.org/) reúne vários recursos gratuitos, incluindo folhas de 
sprites que você pode utilizar no desenvolvimento dos seus jogos.
DICAS
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
12
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, encontramosnos 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, 
TÓPICO 1 — DESENVOLVIMENTO DE JOGOS 2D
13
FONTE: Adaptado de Microsoft (2017), Gomes (s. d.), PT Computador (s. d.)
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
Gamepads
Também conhecido como joypad, é usado em jogos 
mais comumente usados, alguns modelos podem 
também ser um dispositivo de saída (vibração).
Direcionais analógico 
de arcade
São dispositivos que reproduzem a sensação das 
máquinas de arcade verticais para luta.
Joysticks para simulador 
de voo
Utilizado principalmente para simulador de voo 
como um manche.
Teclado e Mouse São os principais dispositivos de entrada utilizado em jogos.
Volante Utilizado em simuladores de corrida, em alguns casos é utilizado com um conjunto de pedais.
Gaming Keypad Dispositivo com um teclado reduzido, com apenas as teclas utilizadas para jogar.
Controlador Musical Utilizado em jogos musicais, que simulam um instrumento musical, como guitarra ou bateria.
Trackball É um estilo de mouse, com mais recursos e botões.
Controlador WII
Usado para controlar jogos, além de um dispositivo 
de entrada, também é um dispositivo de saída 
(som).
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
14
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á implementada, 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 compostos 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 transformam 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
FONTE: Adaptado de Cople (2019)
 
Característica Descrição
Graphic Engine Motor Gráfico, para renderizar gráficos 2D e 3D.
Physics Engine Motor de Física, para simular a física em si ou 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.
TÓPICO 1 — DESENVOLVIMENTO DE JOGOS 2D
15
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”. 
16
 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 têm 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) têm seus possíveis movimentos criados, 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.
RESUMO DO TÓPICO 1
17
1 Jogos 2D possuem duas dimensões que são representadas por dois eixos, X 
e Y. Sobre essas duas dimensões, assinale a alternativa 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.
AUTOATIVIDADE
18
19
TÓPICO 2 — UNIDADE 1
DESENVOLVIMENTO DE JOGOS 3D
1 INTRODUÇÃO 
Olá, acadêmico! Neste tópico, abordaremos os elementospresentes 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, exploraremos o desenvolvimento de jogos 3D através de 
uma introdução. Em seguida, abordaremos 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 representando a vertical), sendo que um projeto 3D também inclui 
a diretriz Z que representa a profundidade”. 
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/.
DICAS
20
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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). 
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.
DICAS
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS 3D
21
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.
QUADRO 5 – LISTA DE AMBIENTE DE DESENVOLVIMENTO JOGOS 3D
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.
Software Endereço Descrição Gratuito Pago
Roblox 
Studio
https://www.
roblox.com/
create
Com esse software é possível 
criar jogos 3D de maneira 
rápida e simples, contém 
diversas ferramentas 
e modelos prontos. O 
desenvolvedor deve criar 
os cenários e as regras do 
jogo. Os jogos só funcionam 
na plataforma Roblox, em 
sistemas Windows ou Mac.
Sim. Não
Kogama
https://
kogama.com.
br/
É uma plataforma online, não 
sendo necessário instalação. 
Permite criar, compartilhar 
e jogar. Possui ferramentas 
básicas, para adicionar um 
elemento é preciso arrastar 
para o cenário. Os jogos são 
limitados à plataforma.
Sim. Não
3D Game 
Studio
http://www.
3dgamestu-
dio.com/
Considerado um dos 
melhores softwares para 
criação de jogos 3D, o seu 
desenvolvimento é simples e 
possui excelentes resultados.
Possui 
uma 
versão 
de teste
Sim.
libGDX https://libgdx.com/
Software de código livre, 
possibilita o desenvolvimento 
com várias linguagens de 
programação. Considerado 
uma boa opção para criar 
jogos de baixa e média 
complexidade.
Sim. Não.
22
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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/.
DICAS
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.
Estudaremos sobre Animação 3D mais adiante neste tópico, onde iremos 
conhecer alguns softwares de criação de imagens 3D.
ESTUDOS FU
TUROS
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS 3D
23
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).
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.
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.
NOTA
24
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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 mesmoní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.
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS 3D
25
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).
26
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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.
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).
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.
DICAS
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS 3D
27
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.
FIGURA 11 – EXEMPLO DE CRIAÇÃO DE UMA ANIMAÇÃO EM 3D
28
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
FIGURA 12 – EXEMPLO DE CRIAÇÃO DE UMA ANIMAÇÃO EM 3D
FONTE: <https://bit.ly/3Eaf9q5>. Acesso em: 1 jul. 2021.
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.
QUADRO 6 – LISTA DE AMBIENTE DE DESENVOLVIMENTO JOGOS 3D
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.
DICAS
Software Aplicação SO Gratuito / Pago Formatos
3ds Max
Captura de 
movimento, 
Animação de 
quadros-chave 
(keyframes)
Windows Pago
stl, 3ds, ai, abc, ase, asm, 
catproduct, catpart, 
dem, dwg, dxf, dwf, flt, 
iges, ipt, jt, nx, obj, prj, 
prt, rvt, sat, skp, sldprt, 
sldasm, stp, vrml, w3d 
xml
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#3ds-max
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS 3D
29
Software Aplicação SO Gratuito / Pago Formatos
Mo-
tionbuil-
der
Captura de 
movimento, 
Animação de 
quadros-chave 
(keyframes)
Windows Pago asf, amc, bvh, c3d, fbx, htr, tr3
Blender
Captura de 
movimento, 
Animação de 
quadros-chave 
(keyframes)
Windows, 
macOS, 
Linux
Gratuito
3ds, dae, fbx, dxf, obj, x, 
lwo, svg, ply, stl, vrml, 
vrml97, x3d
Cinema 
4D
Captura de 
movimento, 
Animação dequadros-chave 
(keyframes)
Windows, 
macOS Pago
3ds, dae, dem, dxf, dwg, 
x, fbx, iges, lwf, rib, skp, 
stl, wrl, obj
Clara.io
Animação de 
quadros-chave 
(keyframes)
Navega-
dor da 
internet
Gratuito
3dm, 3ds, cd, dae, dgn, 
gf, gdf, gts, igs, kmz, 
lwo, rws, obj, off, ply, 
pm, sat, scn, skp, slc, 
sldprt, stp, stl, x3dv, 
xaml, vda, vrml, x_t, x, 
xgl, zpr
Daz3D
Captura de 
movimento, 
Animação de 
quadros-chave 
(keyframes)
Windows, 
macOS Gratuito obj, fbx, dae, daz
Houdini 
Appren-
tice
Captura de 
movimento, 
Animação com 
keyframes
Windows, 
macOS, 
Linux
Gratuito 
(com limi-
tações)
bgeo, clip, fbx, geo, hip
iClone
Captura de 
movimento, 
Animação de 
quadros-chave 
(keyframes)
Windows Pago 3ds, bvh, fbx, obj, vns, skp
iPi Soft Captura de movimento Windows Pago bvh, fbx
MakeHu-
man
Captura de 
movimento, 
Animação de 
quadros-chave 
(keyframes)
Windows, 
macOS, 
Linux
Gratuito dae, fbx, obj, STL
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#motionbuilder
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#motionbuilder
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#motionbuilder
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#blender
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#cinema-4d
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#cinema-4d
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#clara-io
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#daz3d
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#houdini-apprentice
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#houdini-apprentice
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#houdini-apprentice
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#iclone
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#ipi-soft
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#makehuman
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#makehuman
30
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
Software Aplicação SO Gratuito / Pago Formatos
Maya
Captura de 
movimento, 
Animação de 
quadros-chave 
(keyframes)
Windows, 
macOS, 
Linux
Pago
ai, aiff, dae, dxf, dwg, 
eps, fbx, maya, mel, obj, 
stl
mixamo
Captura de 
movimento, 
Animação de 
quadros-chave 
(keyframes)
Navega-
dor da 
internet
Gratuito bhv, fbx, obj
modo
Captura de 
movimento, 
Animação de 
quadros-chave 
(keyframes)
Windows, 
macOS, 
Linux
Pago
lwo, abc, obj, pdb, 3dm, 
dae, fbx, dxf, x3d, geo, 
stl,
Poser Pro
Captura de 
movimento, 
Animação de 
quadros-chave 
(keyframes)
Windows, 
macOS Pago bvh, cr2, obj, pz2
Terragen
Animação de 
quadros-chave 
(keyframes)
Windows, 
macOS, 
Linux
Pago chan, clip, exr, fbx, geo, lwo, mov, obj, ter
SmartBo-
dy
Captura de 
movimento
Windows, 
Linux, 
macOS, 
Android, 
iOS
Gratuito af, bvh, dae, fbx, sk, xml
Boats 
Animator Stop Motion
Windows, 
macOS, 
Linux
Gratuito avi, mov, mpg
Dragon-
frame Stop Motion
Windows, 
macOS, 
Linux
Pago avi, mov, mpg
Animate 
CC Animação 2D
Windows, 
macOS Pago
fla, xfl, swf, as, apr, psd, 
eps, jpg, png, tiff
Anima-
tion Paper Animação 2D
Windows, 
macOS Pago formato proprietário
Moho Animação 2D Windows, macOS Pago
ai, avi, bmp, eps, gif, 
jpeg, mov, obj, png, 
targa
Pencil2D Animação 2D
Windows, 
macOS, 
Linux
Gratuito gif, png, pcl, pclx, xml, avi, mov, mpg, mp4
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#maya
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#mixamo
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#modo
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#poser-pro
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#terragen
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#smartbody
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#smartbody
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#boats-animator
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#boats-animator
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#dragonframe
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#dragonframe
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#animate-cc
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#animate-cc
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#animation-paper
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#animation-paper
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#moho
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#pencil2d
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS 3D
31
Software Aplicação SO Gratuito / Pago Formatos
Synfig 
Studio Animação 2D
Windows, 
macOS, 
Linux
Gratuito
avi, bmp, gif, mng, 
mpeg, png, ppm, sif, 
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.
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#synfig-studio
https://all3dp.com/pt/1/software-animacao-3d-2d-stopmotion/#synfig-studio
32
RESUMO DO TÓPICO 2
 Neste tópico, você aprendeu que:
• 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.
33
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.
AUTOATIVIDADE
34
35
TÓPICO 3 — UNIDADE 1
DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
1 INTRODUÇÃO 
Bem-vindo, ao terceiro tópico da Unidade 1! No decorrer deste tópico, 
abordaremos 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 o 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!
36
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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 
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
37
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).
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 
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/.
INTERESSA
NTE
38
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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).
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 têm 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”.
Em nossa próxima Unidade iremos tratar mais profundamente as fases de Pré-
produção, Produção e Pós-produção (Finalização).
ESTUDOS FU
TUROS
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
39
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
FIGURA 15 – DIFERENÇAS ENTRE METODOLOGIAS TRADICIONAIS (WATERFALL) X ÁGEIS
40
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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 caso algum 
problema ocorra. 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.
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
41
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 utilizadas em conjunto e se complementam. 
FIGURA 19 – CICLO DA METODOLOGIA EVOLUCIONÁRIA / ESPIRAL (RUP)
FONTE: Adaptada de SENAC (2019c)
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”.
FIGURA 18 – CICLO DA METODOLOGIA ITERATIVA
42
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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
FONTE: Adaptada de SENAC (2019c)
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. 
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
43
FONTE: Freitas (2014, p.14)
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. 
QUADRO 7 – VALORES DO XGD
Valor Descrição
Comunicação
A comunicação entre os integrantes da equipe é de suma 
importância. A Comunicação auxilia na solução de problemas 
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 Simplicidade é, talvez, o principal valor do XGD. A lei do XP e do XGD é: “Faça o item que funcione, da forma mais simples 
possível.”
Feedback
É o ato de o cliente comunicar ao desenvolvedor algo de 
novo que ele aprendeu sobre o problema. É também o 
desenvolvedor comunicar ao cliente estimativas, riscos e 
melhorias do projeto. Quanto mais cedo se sabe, antes se pode 
adaptar (Beck, 2004).
Coragem
Coragem é ter ações efetivas para superar dificuldades. 
Quando combinada com outros valores, torna-se uma arma 
poderosa: coragem para comunicar, para manter simples e 
para ouvir o feedback (BECK, 2004).
Respeito
Toda a equipe de desenvolvimento precisa ter respeito com os 
demais. É preciso que cada um se importe com o projeto, caso 
contrário, o fracasso será certo. Assim como no XP, no Extreme 
Game Development todos são responsáveis pelo projeto (BECK, 
2004).
Milistones são metas para versões intermediárias do jogo.
NOTA
44
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
QUADRO 8 – VALORES DO XGD
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”.
 
Prática Descrição
Time Inteiro A equipe deve permanecer coesa em comunicação. A equipe é um todo, e não a soma de forças individuais.
Design Incremental As tarefas (assets) de um jogo devem ser feitas da forma mais simples possível, que funcionem corretamente.
Estórias de Usuário São pequenas descrições das funcionalidades do jogo, descritas normalmente pelo cliente.
Ciclo Semanal O projeto é organizado e planejado para ser executado em ciclos de curta duração.
Código 
Compartilhado
Todos da equipe compartilham todo o código-fonte do 
projeto.
Integração Contínua No projeto não existem “pedaços” de código-fonte. O projeto está continuamente integrado e funcionando.
Reuniões Stand-up
Reuniões rápidas de projeto, com objetivo de que toda 
a equipe esteja ciente do trabalho que está sendo feito 
num dado momento.
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
45
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).
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. 
 
Percebeu que falta uma metodologia ágil? Estamos falando sobre o Scrum, o 
qual abordaremos 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.
ESTUDOS FU
TUROS
46
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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.
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). 
Em nossa próxima unidade, abordaremos as três fases do Gamescrum: Pré-
-produção, Produção e Pós-produção.
ESTUDOS FU
TUROS
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
47
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.
QUADRO 9 – VALORES DO XGD
Item do GDD Descrição
Página de Título Deve conter o nome do jogo, a informação de direitos de autor, o número da versão do jogo, o autor e a data.
Tabela de conteúdo É o índice das tabelas contidas no documento.
Histórico As versões já implementadas, deve conter a descrição de grandes mudanças, assim como as alterações realizadas.
Visão geral do jogo
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), 
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).
Gameplay e 
mecânicas de jogo
Descrição da progressão do jogo (estrutura de missões), 
os objetivos do jogo e o game flow (como o jogador tem a 
percepção). Na mecânica (movimentos, ações, combates etc) e 
regras do jogo que envolvem todos os elementos do jogo.
História e 
Personagem São descritos todos as histórias e personagens do jogo.
Níveis Cada nível é explicado em mínimos detalhes.
Interface Descrição de todo o sistema virtual, controle do jogo, áudios, efeitos e ajuda.
Inteligência 
Artificial
Prever as jogadas dos personagens e programa-las para se 
comportarem de acordo uma com as outras.
Tecnologia Descrição do hardware do dispositivo que será utilizado o jogo.
Arte de jogo
Ou Game Art, devem ser demonstrados os desenhos do jogo, 
como personagens, ambientes, guia de estilo, entre outros 
objetos do jogo.
48
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
Software Secundário Software de instalação, editor de mapas ou atualizações.
Gestão Calendário em detalhes, recursos utilizados, análise de riscos e 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.
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;
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.
INTERESSA
NTE
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
49
• persistência para salvar e recuperar o progresso no jogo: quando o jogadorpausa o jogo, é necessário salvar o ponto em que foi pausado, e carregado 
quando reiniciado (SILVA, 2017).
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:
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”.
NOTA
50
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
• 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
FONTE: Senac (2019e, p. 9)
• 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
FONTE: Senac (2019e, p. 10)
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
51
• 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 possuir 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 
aventura
Elementos de combate junto à resolução de problemas e 
exploração do mapa.
Luta O jogador deve derrotar diversos adversários para a conclusão 
de algum objetivo principal.
52
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
FPS Jogo em primeira pessoa com o objetivo de atirar no máximo 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.
RTS Real Time Strategy engloba o controle de unidades e grupos em 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-
ção de 
mundos
Manipulação de personagens e ambientes para atingir 
determinado nível de desenvolvimento, como no caso de Spore 
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
Arcade Jogos do tipo plataforma ou luta, como Sonic, Mario e Street, Fighter (psicomotricidade).
Esportes Esporte de forma geral, como NBA, FIFA e Need for Speed (psicomotricidade) 
Aventura Visam completar níveis dentro de um roteiro, como Indiana Jones e Final Fantasy (psicomotricidade). 
Simulação e
Construção
Envolvem simulação e construção de mundos, como Spore e 
The Sims (raciocínio e psicomotricidade).
Estratégia Normalmente são campanhas, como em Civilization e WOW (raciocínio, lógica e estratégia).
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
53
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).
FONTE: Cople (2019, p.12-13)
Puzzles e
Lógica
Jogos de tabuleiro e junção de peças, como Xadrez e Tetris 
(raciocínio, memória, lógica e estratégia).
Perguntas Exemplosdeste tipo de jogo são Quiz e Trivia (memória, lógica e estratégia).
No link a seguir, você poderá acessar um artigo que apresenta os 10 gêneros 
de jogos mais jogados atualmente: https://bit.ly/3vAfpLZ.
DICAS
54
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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.
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
55
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
Game inspired design 
(Design inspirado 
em jogos)
Utilizam ideias de jogos, porém nenhum elemento 
do jogo, ou seja, possui ligações com jogos, mas não 
contém nada que possa ser considera parte do jogo, 
como dinâmicas, mecânicas etc. 
G a m i f i c a t i o n 
(Gamificação)
É a utilização de pensamentos e elementos de jogos 
em contextos fora de jogos, utiliza-se elementos como 
mecânica, premiações e afins, para tornar a atividade 
mais competitiva e interessante.
56
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
Serious Games (Jogo 
sério) e Simulação
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 
de algo real;
- 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.
Jogo
Que é o que conhecemos em maior quantidade 
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 continuaremos a explorar o desenvolvimento de jogos. Até lá! 
FIGURA 28 – FINAL DA UNIDADE 1
FONTE: <https://bit.ly/3876DtS>. Acesso em: 15 jul. 2021.
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
57
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 adaptabilidadeda 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 
LEITURA COMPLEMENTAR
58
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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).
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
59
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 
60
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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 
prioridadesou 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).
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
61
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 sem lógica), 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 NPCs (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).
62
UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS
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. NPCs 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 NPCs 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 NPCs.
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);
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA
63
- 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 NPCs. Surge, então, o seguinte conflito: os 
designers controlam o comportamento dos NPCs. É preciso, então, o uso de 
IA? Em contrapartida, se a IA estiver presente (NPCs 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 NPCs do jogo (CHAMPANDARD, 2003). 
(...)
FONTE: Adaptado de <https://bit.ly/3vDVJa8>. Acesso em: 26 jun 2021.
64
RESUMO DO TÓPICO 3
 Neste tópico, você aprendeu que:
• 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.
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.
CHAMADA
65
1 O plano de desenvolvimento de jogos é realizado através de umasequê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.
AUTOATIVIDADE
66
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.
67
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.
68
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. Metodologias para Desenvolvimento de 
Jogos. 2018. Disponível em: https://www.fabricadejogos.net/posts/metodologias-
-para-desenvolvimento-de-jogos/. Acesso em: 11 jul. 2021.
69
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. 
Acesso em: 30 jun. 2021.
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.
70
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. 
Acesso em: 29 jun. 2021.
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. 
Acesso em: 9 jul. 2021.
71
UNIDADE 2 — 
PRODUÇÃO DE JOGOS
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
 A partir do estudo desta unidade, você deverá ser capaz de:
• 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 as técnicas de Brainstorm e MoSCoW;
• conhecer os diferentes ciclos de desenvolvimento de jogos.
 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 – 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
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorverá 
melhor as informações.
CHAMADA
72
73
UNIDADE 2
1 INTRODUÇÃO 
Olá, acadêmico! Seja bem-vindo a nossa segunda Unidade da disciplina 
de Desenvolvimento de Jogos Multiplataforma! No decorrer desta unidade, 
abordaremos 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, conheceremos os métodos de gerenciamento 
de projetos abordados no desenvolvimento de jogos – além dos métodos de 
gerenciamento, que além de utilizados no desenvolvimento de jogos também são 
utilizados no desenvolvimento de tecnologias e em projetos relacionados à área. 
Na sequência, estudaremos 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.).
TÓPICO 1 — 
MÉTODOS DE GERENCIAMENTO DE PROJETO E 
INTRODUÇÃO A PRODUÇÃO DE JOGOS
UNIDADE 2 — PRODUÇÃO DE JOGOS
74
 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.
TÓPICO 1 — MÉTODOS DE GERENCIAMENTO DE PROJETO E INTRODUÇÃO A PRODUÇÃO DE JOGOS
75
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
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”.
FONTE: <https://bit.ly/2ZrA7BL>. Acesso em: 25 jul. 2021.
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.
DICAS
UNIDADE 2 — PRODUÇÃO DE JOGOS
76
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)
TÓPICO 1 — MÉTODOS DE GERENCIAMENTO DE PROJETO E INTRODUÇÃO A PRODUÇÃO DE JOGOS
77
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
FONTE: Adaptado de Ladeira (2012)
Benefícios pessoais Benefícios para organização
O programador ganha uma 
avaliação das suas forças e 
fraquezas, mostrada nos dados do 
PSP.
Dados do PSP melhoram o planejamento 
e o gerenciamento do cronograma de 
projetos de software.
O programador pode interpolar 
dados colecionados de tal forma 
que podem ser derivadas ideias 
para a melhoria de processos. 
A remoção de defeitos introduzidos 
antes da compilação e testes resulta em 
um produto de melhor qualidade, reduz 
o custo dos testes e diminui o tempo de 
desenvolvimento.
O programador pode resistir 
a uma pressão irracional por 
discussão do tamanho antecipado 
do problema e relacionar isto a 
sua produtividade histórica.
 O PSP introduz um aprendizado e 
prática para a melhoria do processo. 
Pequenos ciclos de desenvolvimento 
e os dados pessoais tornam fácil o 
entendimento e aumenta a experiência.
A conclusão organizada de um 
projeto fornece ao programador 
um senso de realização pessoal.
O PSP ajuda os engenheiros e seus 
gerentes a aprenderem a prática da 
quantificação do gerenciamento do 
processo. Eles aprendem o uso do 
processo definido e aprendem também a 
coletar dados para gerenciar, controlar e 
melhorar o trabalho.
Considerando que o programador 
tem um processo repetível, 
consistente e estável, ele vai 
ganhar mais confiança do seu 
grupo.
Finalmente, o PSP expõe os engenheiros 
a 12 áreas chaves do CMMI (KPAs). 
Com isso, facilita a preparação dos 
engenheiros a participar na melhoria 
baseada no CMMI.
UNIDADE 2 — PRODUÇÃO DE JOGOS
78
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 a aplicação do CMMI: https://www.youtube.
com/watch?v=lFrsy6sPVic.
DICAS
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.
TÓPICO 1 — MÉTODOS DE GERENCIAMENTO DE PROJETO E INTRODUÇÃO A PRODUÇÃO DE JOGOS
79
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:
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). 
IMPORTANT
E
UNIDADE 2 — PRODUÇÃO DE JOGOS
80
• 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, 
TÓPICO 1 — MÉTODOS DE GERENCIAMENTO DE PROJETO E INTRODUÇÃO A PRODUÇÃO DE JOGOS
81
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
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).
Scrum Master
Product Owner
Progresso
Equipe Scrum
SCRUM
Planejamento
Esclarecimento
UNIDADE 2 — PRODUÇÃO DE JOGOS
82
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.
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, e 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). 
Quer conhecer mais sobre o Scrum no desenvolvimento de jogos? Assista a 
esse vídeo: https://www.youtube.com/watch?v=k6mrbk3fQXA.
DICAS
TÓPICO 1 — MÉTODOS DE GERENCIAMENTO DE PROJETO E INTRODUÇÃO A PRODUÇÃO DE JOGOS
83
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
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 metodologiasque 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 
Profª. Miriam De Cassia Do Carmo Mascarenhas Mattos
Profª. Raffaela Dayane Afonso
4.1 - INTEGRAÇÃO
13.1 - PARTES INTERESSADAS
4.2 - INTEGRAÇÃO
5.1 - ESCOPO
5.2 - ESCOPO
6.1 - CRONOGRAMA
6.2 - CRONOGRAMA
6.3 - CRONOGRAMA
6.5 - CRONOGRAMA6.4 - CRONOGRAMA
7.2 CUSTOS
7.3 CUSTOS
7.1 - CUSTOS
9.1 - RECURSOS
9.2 - RECURSOS
9.3 - RECURSOS
9.4 - RECURSOS
9.5 - RECURSOS
4.7 - INTEGRAÇÃO
4.6 - INTEGRAÇÃO
4.3 - INTEGRAÇÃO
4.4 - INTEGRAÇÃO
10.1 - COMUNICAÇÕES
10.2 - COMUNICAÇÕES
13.2 - PARTES INTERESSADAS 13.3 - PARTES INTERESSADAS
13.4 - PARTES INTERESSADAS
12.1 - AQUISIÇÕES
12.2 - AQUISIÇÕES
12.3 - AQUISIÇÕES
8.1 - QUALIDADE
8.2 - QUALIDADE
11.4 - RISCOS 11.5 - RISCOS
11.7 - RISCOS
11.6 - RISCOS
11.3 - RISCOS
5.5 - ESCOPO 6.6 - CRONOGRAMA
10.3 - COMUNICAÇÕES
8.3 - QUALIDADE
5.6 - ESCOPO 7.4 - CUSTOS
5.3 - ESCOPO
5.4 - ESCOPO
11.1 - RISCOS
11.2 - RISCOS
4.5 - INTEGRAÇÃO
9.5 - RECURSOS
INTEGRAÇÃO
ESCOPO
CUSTOS
QUALIDADE
RECURSOS
COMUNICAÇÕES
RISCOS
AQUISIÇÕES
PARTES
INTERESSADAS
CRONOGRAMA
DESENVOLVER O
TERMO DE
ABERTURA
DO PROJETO
MONITORAR
E CONTROLAR
O TRABALHO DO
PROJETO
DESENVOLVER O PLANO
DE GERENCIAMENTO DO PROJETO
ORIENTAR E GERENCIAR
O TRABALHO DO PROJETO
GERENCIAR O 
CONHECIMENTO 
DO PROJETO
ENCERRAR O
PROJETO OU FASE
REALIZAR O 
CONTROLE
INTEGRADO DE
MUDANÇAS
PLANEJAR O
GERENCIAMENTO
DO ESCOPO
COLETAR OS 
REQUISITOS
DEFINIR O
ESCOPO
VALIDAR O
ESCOPO
CONTROLAR O 
ESCOPO
CRIAR A EAP
PLANEJAR O
GERENCIAMENTO
DO CRONOGRAMA
PLANEJAR O
GERENCIAMENTO
DO CUSTO
DETERMINAR O
ORÇAMENTO
ESTIMAR OS
CUSTOS
PLANEJAR O
GERENCIAMENTO
DA QUALIDADE
CONTROLAR A
QUALIDADE
REALIZAR A
QUALIDADE
CONTROLAR
OS CUSTOS
MONITORAR AS
COMUNICAÇÕES
GERENCIAR AS
COMUNICAÇÕES
DEFINIDAS AS
ATIVIDADES
ESTIMAR AS
DURAÇÕES DAS
ATIVIDADES
DESENVOLVER O
CRONOGRAMA
SEQUENCIAR AS
ATIVIDADES
CONTROLAR O
CRONOGRAMA
IDENTIFICAR
OS RISCOS
MONITORAR O
ENGAJAMENTO
DAS PARTES
INTERESSADAS
GERENCIAR O
ENGAJAMENTO
DAS PARTES
INTERESSADAS
PLANEJAR O
ENGAJAMENTO
DAS PARTES
INTERESSADAS
CONTROLAR AS
AQUISIÇÕES
CONDUZIR AS
AQUISIÇÕES
PLANEJAR O
GERENCIAMENTO
DE RISCOS
REALIZAR
A ANÁLISE
QUALITATIVA
DOS RISCOS
REALIZAR
A ANÁLISE
QUANTITATIVAS
DOS RISCOS
PLANEJAR
RESPOSTAS
AOS RISCOS
MONITORAR OS
RISCOS
IMPLEMENTAR
RESPOSTAS A RISCOS
UNIDADE 2 — PRODUÇÃO DE JOGOS
84
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.
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). 
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/.
INTERESSA
NTE
TÓPICO 1 — MÉTODOS DE GERENCIAMENTO DE PROJETO E INTRODUÇÃO A PRODUÇÃO DE JOGOS
85
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.
FIGURA 9 – MODELO DE CICLO DE DESENVOLVIMENTO DE JOGOS
Início
Versão
Fundação Estrutura
Versão Beta
Refinamento
Versão de Lançamento
Estágio
Conceito/Desenho Versão Alpha
Detalhamento Formal
Pré-
Produção Produção
Teste Beta Lançamento
-
UNIDADE 2 — PRODUÇÃO DE JOGOS
86
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
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.
FONTE: Adaptado de Cezarotto e Battaiola (2018, apud CHANDLER, 2012)
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).
ESTUDOS FU
TUROS
TÓPICO 1 — MÉTODOS DE GERENCIAMENTO DE PROJETO E INTRODUÇÃO A PRODUÇÃO DE JOGOS
87
QUADRO 2 – COMPARATIVO DE CICLOS DE PRODUÇÃO DE JOGOS
FONTE: Adaptado de Rocha e Araújo (2013)
Autor Novak (2017) Chandler (2012) Schuytema (2008)Característica
Fases 8 4 4
Perspectiva Indústria de jogos produtor designers
Conceito
ideia do jogo, 
público, recursos, 
objetivo, finalidade 
do jogo, e condições 
de vitória
Não tem Não tem
Pré-produção
plano de ilustração, 
plano do projeto, 
documento de 
design do jogo, 
documento técnico 
de design
conceito, requisitos 
do jogo (de 
arte, design e 
engenharia), 
planejamento do 
projeto, e avaliação 
de risco
conceito do jogo, 
brainstorming,
documento de
design
Protótipo
telas que capturam 
a essência do 
jogo para teste da 
mecânica do jogo esua diversão
Não tem Não tem
Produção Desenvolvimento
implementação 
do plano, 
rastreamento do 
projeto, e avaliação 
de risco
construção 
do jogo, e 
programação do 
código-fonte
Alfa teste do jogo do começo ao fim 
validação do plano 
e
liberação do código
Não temBeta
correção de defeitos 
encontrados e 
conclusão do 
desenvolvimento 
do jogo
Ouro fabricação da mídia física
Pós-produção
lançamento de 
novas versões com 
correções ou
conteúdos 
adicionais
aprendizado com a
experiência, e 
plano
de arquivamento
inclusão de 
recursos, e
avaliação da 
receptividade
UNIDADE 2 — PRODUÇÃO DE JOGOS
88
Que conhecer mais profundamente todas as fases de um ciclo de produção? 
Assista este vídeo: https://www.youtube.com/watch?v=Kv48Nezf5O0.
DICAS
89
 Neste tópico, você aprendeu que:
• 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.
RESUMO DO TÓPICO 1
90
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 utilizado 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.
AUTOATIVIDADE
91
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. 
92
93
UNIDADE 2
1 INTRODUÇÃO 
Olá, acadêmico! Seja bem-vindo ao Tópico 2! No decorrer deste tópico 
abordaremos 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!
TÓPICO 2 — 
FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
94
UNIDADE 2 — PRODUÇÃO DE JOGOS
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á desenvolvido 
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 conheceremos 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 é umaatividade 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).
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
95
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 as 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 para o jogo. Marques (2015) 
ressalta que o brainstorm,
(...) funciona como uma tempestade de ideia e é 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 o 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).
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.
INTERESSA
NTE
96
UNIDADE 2 — PRODUÇÃO DE JOGOS
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 e, em seguida, identificar um líder, 
os membros e assistente. Em segundo lugar, a sessão deve ser realizada em um 
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.
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”. 
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.
INTERESSA
NTE
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
97
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 definir o gênero do jogo é uma maneira de ele 
ser categorizado, assim, a equipe pode melhor visualizar a facilidade da 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. 
98
UNIDADE 2 — PRODUÇÃO DE JOGOS
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á desenvolvidoe para qual público-alvo ele será 
pensado e criado.
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
99
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 elementos 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. 
2.1.9 Mecânica do jogo
A mecânica do jogo envolve como o jogador vivencia 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 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 
“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.).
NOTA
100
UNIDADE 2 — PRODUÇÃO DE JOGOS
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”.
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
101
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, conheceremos 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:
102
UNIDADE 2 — PRODUÇÃO DE JOGOS
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
FONTE: Adaptado de Chandler (2012)
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 três como prioridade 
alta e um para mais baixa. A Figura 17 apresenta uma planilha de pontuação de 
recursos classificada por pontuação (CHANDLER, 2012). 
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
103
FONTE: Adaptado de Chandler (2012)
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 oserros o jogo é liberado para os testes 
finais (CHANDLER, 2012; NOVAK, 2017, CRUZ, 2013).
FIGURA 17 – PLANILHA DE PONTUAÇÃO DE RECURSOS
104
UNIDADE 2 — PRODUÇÃO DE JOGOS
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
Que ferramentas 
e softwares são 
necessários?
As ferramentas de do software são necessárias para 
quando é preciso converter um formato de arquivo, 
já software de controle de código-fonte pode ser 
utilizados para que seja inserido ou removido assets 
na build (versão compilada do jogo).
O pipeline dá suporte 
a funcionalidade 
bidirecional?
Deve ser possível que os assets sejam convertidos 
para utilização no jogo, assim como serem 
transformados na versão original, assim as alterações 
são realizadas mais rapidamente nos assets.
Qual é o caminho 
crucial? Há algum 
gargalo?
Todos devem ter um volume de trabalho 
proporcional, assim ninguém fica com um gargalo. 
Também deve ser limitado o número de etapas do 
pipeline. 
Quando o sistema 
precisa estar 
funcionando 
plenamente?
O pipeline tem que estar operacional para que o 
build jogável com os assets corretos seja criada.
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
105
FONTE: Adaptado de Chandler (2012)
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).
Como os assets 
são gerenciados 
e rastreados no 
sistema?
É importante decidir com os softwares de controle de 
código--fonte será utilizado, para que os assets atuais 
sejam trabalhados. Utilizando um controle de versões 
são uma boa solução para que várias versões do 
projeto não causem confusões do desenvolvimento.
Que áreas do 
sistema podem ser 
automatizadas?
Ao automatizar os pipelines é possível reduzir tempo 
e erros humanos.
106
UNIDADE 2 — PRODUÇÃO DE JOGOS
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 para então entender 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). 
 
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
107
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 
108
UNIDADE 2 — PRODUÇÃO DE JOGOS
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 
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
109
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 
Produtos concluídos para a fase conceitual 
Produtos concluídos para a fase de requisitos 
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 
Produtos concluídos para a fase conceitual 
Produtos concluídos para a fase de requisitos 
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 
110
UNIDADE 2 — PRODUÇÃO DE JOGOS
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 
FONTE: Chandler (2012, p. 263)
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 úteis 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).
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
111
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
DICAS
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.
112
UNIDADE 2 — PRODUÇÃO DE JOGOS
QUADRO 5 – EQUIPES DE DESENVOLVIMENTO
Equipe Profissional Descrição
Pr
ofi
ss
io
na
is
 d
e 
A
rt
e
Diretor de 
arte
Supervisiona a equipe de arte, responsável por controlar os 
prazos, o desenvolvimento, orçamentos e as contrataçõespara a equipe, além de determinar o estilo de arte do jogo, 
sua atmosfera e aparência em geral.
Artista líder Supervisiona a equipe de arte, além de participar do processo de produção da arte do jogo.
Artista 
conceitual
Cria os desenhos e esboços do ambiente, objetos e os 
personagens do jogo.
Construtor de 
mundos Constrói a geometria e as texturas do mundo do jogo.
Criador de 
assets
Criação dos assets (personagens, acessórios, telas de 
interface de usuário, veículos, e qualquer outro assets 
necessário) que aparecem no jogo.
Animador Aplica os movimentos aos personagens e objetos presentes no mundo do jogo.
Artista 
técnico
Gerenciam o lado técnico da criação de assets, como 
garantia que os objetos sejam exportados, aplicação de 
atributos físicos a objetos, criação de volumes de colisão.
Artista de 
marketing
Criam os recursos (captura de tela, filmar a mecânica 
do jogo, criar a embalagem, entre outros recursos) de 
marketing do jogo.
Pr
ofi
ss
io
na
is
 d
e 
D
es
ig
n Diretor de 
criação
Garante a consistência do estilo geral e do conteúdo do 
jogo.
Designer líder Supervisiona a equipe de design, e atua no desenvolvimento do processo cotidiano de design.
Designer É responsável por criar, simular, implementar e balancear diferentes áreas do jogo.
Redator Cria os elementos da história, os personagens e diálogos do jogo.
Pr
ofi
ss
io
na
is
 d
e 
En
ge
nh
ar
ia
Diretor 
técnico
Cria o desenho técnico do projeto, supervisiona sua 
implementação, escolhe as ferramentas, hardwares e define 
padrões de programação.
Programador 
líder
Supervisiona a equipe de engenharia e também participado 
do desenvolvimento da programação do jogo.
Programador 
de rede Específica os componentes multijogador de jogos on-line.
Programador 
de som Implementa os sons e músicas no jogo.
Programador 
de 
ferramentas
Projeta ferramentas que ajudam as equipes de arte e design 
a transformar o código de programação para ser incluído 
no jogo.
Programador 
de IA
Cria os comportamentos que a percepção de 
comportamento inteligente.
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
113
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 
Pr
ofi
ss
io
na
is
 d
e 
Pr
od
uç
ão
Produtor 
executivo
Gerencia a produção, da proposta e do protótipo, além de 
oferecer apoio ao projeto.
Produtor Responsável pelo cumprimento das metas do projeto.
Produtor 
associado
É subordinado ao produtor, interage com a equipe e 
também auxilia os líderes das equipes quando necessário.
Pr
ofi
ss
io
na
is
 d
e 
Q
A
Analista líder 
de QA
Testar o jogo, fechar os bugs (erros) e determinar se o jogo 
está pronto para ter o código liberado.
Testador de 
QA
Verifica a funcionalidade do jogo com relação ao plano de 
testes, testa novos recursos e protótipos em busca de bugs 
(erros).
114
UNIDADE 2 — PRODUÇÃO DE JOGOS
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 funcionalidades 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. 
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
115
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ãoutilizadas 
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
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
FONTE: Adaptado de Azevedo (2009)
Título do Jogo
Subtítulo do jogo
Sumário
1- Histórico do Projeto
Escreva uma breve descrição das versões e mudanças ocorridas durante o 
projeto desde o início.
116
UNIDADE 2 — PRODUÇÃO DE JOGOS
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
FONTE: Adaptado de Azevedo (2009)
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.
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.
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
117
QUADRO 9 – ESTRUTURA BÁSICA DE UM DE UM GDD – JOGABILIDADE E MECÂNICA
FONTE: Adaptado de Azevedo (2009)
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)
118
UNIDADE 2 — PRODUÇÃO DE JOGOS
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
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
119
FONTE: Adaptado de Azevedo (2009)
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
FONTE: Adaptado de Azevedo (2009)
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. 
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.
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
120
UNIDADE 2 — PRODUÇÃO DE JOGOS
QUADRO 12 – ESTRUTURA BÁSICA DE UM GDD - INTERFACE
FONTE: Adaptado de Azevedo (2009)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
FONTE: Adaptado de Azevedo (2009)
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 
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
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)
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
121
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
FONTE: Adaptado de Azevedo (2009)
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
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.
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
122
UNIDADE 2 — PRODUÇÃO DE JOGOS
9.4 – Ambientes
9.5 – Equipamentos
9.6 – Cortes de Cena
9.7 – Miscelânea
FONTE: Adaptado de Azevedo (2009)
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
FONTE: Adaptado de Azevedo (2009)
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
FONTE: Adaptado de Azevedo (2009)
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.
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
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
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
123
FONTE: Adaptado de Azevedo (2009)
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
FONTE: Adaptado de Azevedo (2009)
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.
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.
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
Ator 2 – Linha de voz
Ator 3 – Linha de voz
124
UNIDADE 2 — PRODUÇÃO DE JOGOS
QUADRO 20 – ESTRUTURA BÁSICA DE UM GDD – ASSINATURAS RESPONSÁVEIS
FONTE: Adaptado de Azevedo (2009)
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. 
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
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.
IMPORTANT
E
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
125
FONTE: Chandler (2012, p. 9)
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”. 
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 produtosforam 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? 
126
UNIDADE 2 — PRODUÇÃO DE JOGOS
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).
É 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 a 
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.
FIGURA 19 – FASES DE DESENVOLVIMENTO DE JOGOS
FONTE: A autora
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
127
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”. 
128
UNIDADE 2 — PRODUÇÃO DE JOGOS
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
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 
FONTE: Soueid e Alves (s. d.)
Quer explorar mais sobre o método MoSCoW? Assista o seguinte vídeo: 
https://www.youtube.com/watch?v=amHjvQt-WeA.
DICAS
TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO
129
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 ser realizado, 
o que pode ser melhorado e se alguma tarefa está pendente, para assim iniciar a 
próxima fase. 
130
UNIDADE 2— PRODUÇÃO DE JOGOS
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? 
FONTE: Chandler (2012, p. 12)
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.
ESTUDOS FU
TUROS
131
RESUMO DO TÓPICO 2
 Neste tópico, você aprendeu que:
• 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.
132
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 específicas. 
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.
AUTOATIVIDADE
133
UNIDADE 2
1 INTRODUÇÃO 
Olá, caro acadêmico! Bem-vindo 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. 
FIGURA 21 – FASES DE DESENVOLVIMENTO DE JOGOS
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, abordaremos 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”. 
TÓPICO 3 — 
TESTES E FASE DE PÓS-PRODUÇÃO
134
UNIDADE 2 — PRODUÇÃO DE JOGOS
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 umagrande 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.
TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO
135
FONTE: Adaptado de Chandler (2020)
É 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. 
QUADRO 23 – TIPOS DE TESTES
Tipo de Teste Objetivo do teste
Teste de 
Jogabilidade
Observar o fato de divertimento do jogo, não se espera 
encontrar erros, mas sim ter uma perspectiva de como 
o jogo é interpretado pelo jogador. Pode-se utilizar os 
profissionais da equipe ou convidar pessoas externas para 
participar deste teste.
Teste Funcional
Cada funcionalidade do jogo é verificada, esse tipo de 
teste é o que irá demandar maior tempo pois analisa em 
detalhes as funcionalidades buscando identificar todos os 
erros ou o máximo de erros possíveis. 
Teste de 
compatibilidade
Neste teste, diferentes hardwares e softwares são utilizados 
para testar a compatibilidade do jogo com as plataformas 
que irão ser utilizadas para executá-lo. Por este teste são 
identificadas as especificações mínimas de hardware e 
software para que o jogo funcione quando for distribuído. 
Teste de 
desempenho
Identifica a quantidade de quadros por segundo (FPS) 
no jogo, sendo que o mínimo necessário são 30 FPS. Em 
alguns jogos mais avançados e com maior qualidade 
gráfica, é comum que seja executado a 60 FPS. Esse teste é 
realizado em todo o desenvolvimento do jogo.
Teste de 
localização
Neste teste são verificadas as traduções do jogo, que devem 
ser realizadas por um testador nativo na língua em que o 
jogo é executado. Em alguns casos, este teste é terceirizado.
Teste Ad Hoc
É 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 
softwares em paralelo ao jogo, forçando a identificação de 
falhas no comportamento do jogo, como travas, falhas de 
resposta, entre outros erros.
136
UNIDADE 2 — PRODUÇÃO DE JOGOS
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).
TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO
137
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 inserida a informação 
do erro no banco de dados, ele deve ser verificado e em seguida fechado pela 
equipe de desenvolvimento para, assim, ser possível 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
FONTE: Adaptado de Chandler (2020)
Processo Descrição
Encontrado
Alguém na equipe de desenvolvimento ou na equipe de 
controle de qualidade encontra um bug e entra no banco de 
dados de erros.
Designado
O bug é atribuído a um desenvolvedor para ser corrigido. A 
pessoa que faz as atribuições de bugs provavelmente é um 
produtor ou um líder de equipe.
Corrigido
O desenvolvedor corrige o bug e o marca como corrigido no 
banco de dados. Quando o bug é marcado como corrigido, o 
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.
Verificado
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 
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.
Resolvido
O líder do controle de qualidade confirma que as correções 
verificadas estão funcionando como pretendidoe fecha o bug 
no banco de dados. O bug é arquivado no banco de dados 
e removido do processo de rastreamento de erros. Se o bug 
ocorrer no futuro, o problema será reaberto e o processo 
começará novamente.
138
UNIDADE 2 — PRODUÇÃO DE JOGOS
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).
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 
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.
DICAS
TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO
139
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 
140
UNIDADE 2 — PRODUÇÃO DE JOGOS
(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
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. 
FONTE: <https://bit.ly/3mm3sGA>. Acesso em: 15 ago. 2021.
Quer se explorar mais sobre o TDD? Assista o seguinte vídeo: https://www.
youtube.com/watch?v=bLdEypr2e-8.
INTERESSA
NTE
TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO
141
QUADRO 23 – LISTA DE VERIFICAÇÃO DOS TESTES
FONTE: Adaptado de Chandler (2012)
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.
 
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çãofinal? 
142
UNIDADE 2 — PRODUÇÃO DE JOGOS
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. 
TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO
143
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
FONTE: Adaptado de Chandler (2012)
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? 
144
UNIDADE 2 — PRODUÇÃO DE JOGOS
LEITURA COMPLEMENTAR
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. (...)
TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO
145
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 baseadoem 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.
146
UNIDADE 2 — PRODUÇÃO DE JOGOS
 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.
TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO
147
• 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, 
148
UNIDADE 2 — PRODUÇÃO DE JOGOS
membro da equipe, como o real cliente. Tal decisão mostrou-se muito importante, 
pois foi possível, desde o começo, focaros 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 (...) 
TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO
149
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.
150
UNIDADE 2 — PRODUÇÃO DE JOGOS
• 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.
151
RESUMO DO TÓPICO 3
 Neste tópico, você aprendeu que:
• 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.
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.
CHAMADA
152
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.
AUTOATIVIDADE
153
( ) 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. 
154
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://
gamesed.baldwinconsulting.org/files/Baldwin_Game_Design_Document_Tem-
plate.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. 
Acesso em: 29 jun. 2021.
CHANDLER, H. M. Manual de Produção de Jogos Digitais. 2 ed. Porto Alegre: 
Bookman, 2012.
CHANDLER, H. M. The Game Production Toolbox. CRC PressTaylor & Francis 
Group: EUA, 2020.
155
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/. 
Acesso em: 21 jul. 2021.
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. 
Acesso em: 21 jul. 2021.
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.
156
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.
NOVAK, J. Desenvolvimento de games. São Paulo: Cengage Learning, 2017.
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.
157
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&gbpv1=&pg=P1P&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.
158
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. 
Acesso em: 21 jul. 2021.
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.
159
UNIDADE 3 — 
DOCUMENTAÇÃO E 
DESENVOLVIMENTO DE JOGOS 
MOBILE
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
 A partir do estudo desta unidade, você deverá ser capaz de:
• 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.
 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 – KITS DE FECHAMENTO
TÓPICO 2 – DESENVOLVIMENTO DE JOGOS NO ANDROID
TÓPICO 3 – DESENVOLVIMENTO DE JOGOS PARA IOS
Preparado para ampliar seus conhecimentos? Respire e vamos 
em frente! Procure um ambiente que facilite a concentração, assim absorverá 
melhor as informações.
CHAMADA
160
161
UNIDADE 3
1 INTRODUÇÃO
Caro acadêmico! Bem-vindo à Unidade 3! Na última unidade desse 
livro, iremos conhecer 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 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.
TÓPICO 1 — 
KITS DE FECHAMENTO
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
162
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 
TÓPICO 1 — KITS DE FECHAMENTO
163
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.
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
164
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 
TÓPICO 1 — KITS DE FECHAMENTO
165
“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
FONTE: Adaptado de Chandler (2013).
Tipo de Ativo Ativos
Ativos de texto
Ativos de texto do jogo em todos os idiomas criados
Arquivo de ajuda e manual
Mensagens (palavras-chaves) de instalação
Mensagens de erros
Ativos de 
Narração
Arquivos de áudio não compactados em todos os 
idiomas criados
Narração e roteiros cinematográficos
Elenco de notas
Especificações técnicas de narração
Planilha mestre de narração
Ativos de Arte
Ativos de arte final
Arquivos de origem para todos os ativos de arte, 
incluindo os logotipos
Ativos 
Cinematográficos
Cinematográficas finais no jogo
Codecs de vídeo e players de filmes
Cinematografia não compactada 
Arquivos de origem cinematográfica
Faixas de áudio separadas e não compactadas para 
efeitos de música, narração e som
Ativos de 
Localização 
(se aplicável)
Texto traduzido
Arquivos de narração traduzidos (versões compactadas 
e não compactadas)
Glossários de localização
Ativos de 
Embalagem
Inclua o layout e os ativos de origem da caixa, manual e 
outras peças de papel, incluindo:
Layout da caixa (e todos os arquivos de origem)
Layout manual (e todos os arquivos de origem)
Capturas de tela não compactadas usadas em 
embalagens
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
166
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). 
TÓPICO 1 — KITS DE FECHAMENTO
167
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. 
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”. 
DICAS
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
168
Tipos de 
Documentação Itens a serem incluídos
Documentação do 
jogo
• Documentos de design principais
• Gráfico de fluxo descrevendo a interface do usuário
• Trapaças e passo a passo
• Planos de teste
Diretrizes técnicas
• 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 
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).
Informações 
gerais do jogo
• 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 
ponto de contato, caso haja alguma dúvida sobre o 
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.
QUADRO 2 – TIPOS DE DOCUMENTAÇÃO
FONTE: Adaptado de Chandler (2013)
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). 
TÓPICO 1 — KITS DE FECHAMENTO
169
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 
índicecom 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.
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
170
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).
TÓPICO 1 — KITS DE FECHAMENTO
171
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
QUADRO 3 – LISTA DE VERIFICAÇÃO DO KIT DE FECHAMENTO
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
172
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
FONTE: Adaptado de Chandler (2013)
Criar o kit de fechamento irá levar um tempo, pois é uma atividade 
demanda 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. 
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?
173
 Neste tópico, você aprendeu que:
• 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.
RESUMO DO TÓPICO 1
174
1 O kit de fechamento é utilizado após a conclusão daproduçã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.
AUTOATIVIDADE
175
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.
176
177
UNIDADE 3
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. 
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).
TÓPICO 2 — 
DESENVOLVIMENTO DE JOGOS NO ANDROID
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.
INTERESSA
NTE
https://mymob.com.br/blog/historia-do-android.html
178
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
FIGURA 3 – COMPARATIVO DE DESENVOLVIMENTO DE JOGOS CONFORME S.O.
FONTE: Adaptado de Fleury et al. (2014)
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):
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.
DICAS
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
179
• 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.
https://unity3d.com/pt/get-unity/download
180
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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.
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
181
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.
182
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
A figura 8 demonstra a tela sobressalente. Nela, iremos escolher a versão 
do Unity que queremos instalar. Normalmente, são apresentadas 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.
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
183
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.).
FIGURA 9 – INSTALANDO DO UNITY - RECURSOS
184
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
Neste vídeo você pode conhecer um exemplo de jogo em 2.5D. Para 
acessar, utilize este link: https://bit.ly/3mofYFr.
INTERESSA
NTE
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.
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
185
Criado em 2005, o Unity vem se sendo atualizado deste então e com o passar 
do tempo novos recursos vãosendo 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íficode 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. 
186
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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).
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
187
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:
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
FIGURA 13 – ÁREA DE TRABALHO DO UNITY
188
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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 
https://docs.unity3d.com/Manual/UsingTheSceneView.html
https://docs.unity3d.com/Manual/UsingTheSceneView.html
https://docs.unity3d.com/Manual/SceneViewNavigation.html
https://docs.unity3d.com/Manual/UsingTheSceneView.html
https://docs.unity3d.com/Manual/GameView.html
https://docs.unity3d.com/Manual/UnityCollaborate.html
https://docs.unity3d.com/Manual/UnityServices.html
https://docs.unity3d.com/Manual/UnityIAPSettingUp.html
https://docs.unity3d.com/Manual/Layers.html
https://docs.unity3d.com/Manual/CustomizingYourWorkspace.html
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
189
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).
190
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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.
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
191
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 
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).
FIGURA 17 – VIEW SCENE E VIEW GAME
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.
INTERESSA
NTE
192
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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 s.p.).
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. 
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
193
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 tornanovamente plano para que os jogadores 
que chegaram até esse ponto consigam terminá-lo (NOVAK, 2017, p. 
217).
194
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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 
que compõem a cena, sendo necessária a atualização de dois componentes 
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
195
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). 
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.
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.
DICAS
196
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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 
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
197
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). 
198
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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 é 
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
199
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: Adaptada de 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:
200
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
(...) 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. 
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/).
DICAS
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
201
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. 
202
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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. 
TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID
203
FONTE: James (2013, p. 286)FIGURA 25 – UPLOAD DO JOGO
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.
IMPORTANT
E
204
RESUMO DO TÓPICO 2
 Neste tópico, você aprendeu que:
• 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.
205
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.
Assinale a alternativa que apresenta a sequência CORRETA:
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.
AUTOATIVIDADE
206
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.
207
UNIDADE 3
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 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! 
TÓPICO 3 — 
DESENVOLVIMENTO DE JOGOS PARA IOS
208
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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: Adaptado de 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.
Neste vídeo podemos conhecer como criar nosso primeiro projeto no Unity: 
https://youtu.be/TboBWKBgQ8M.
DICAS
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS PARA IOS
209
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. 
210
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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. 
Neste vídeo podemos conhecer como inserir background em nossos projetos: 
https://www.youtube.com/watch?v=ahI_nCTD1JE.
INTERESSA
NTE
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS PARA IOS
211
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
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 
FONTE: Hocking (2018, p. 311)
Neste vídeo podemos conhecer como inserir a logo do nosso jogo na tela 
inicial: https://www.youtube.com/watch?v=cvfRDMg9LXc.
DICAS
212
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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, 2021, s.p.).
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. 
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS PARA IOS
213
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, colocam-
se as luzes ao redor da cena. Em cada um dos objetos inseridos devemosincluir 
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).
Que tal conhecer como montar uma cena em 3D no Unity? Confira o vídeo: 
<https://www.youtube.com/watch?v=IuDVUILAioY>.
INTERESSA
NTE
214
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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.
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS PARA IOS
215
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).
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). 
Neste vídeo podemos conhecer mais sobre as transições de tela no Unity: 
<https://www.youtube.com/watch?v=Z4iQ-zxvJjU>.
DICAS
216
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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 
TÓPICO 3 — DESENVOLVIMENTO DE JOGOS PARA IOS
217
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 
218
UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE
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). 
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