desenvolvimento de jogos multiplataformas

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çãoPrezado acadêmico! Seja bem-vindo à Disciplina Desenvolvimento

de Jogos Multiplataformas!

No caminho até aqui você conheceu algumas disciplinas que abordaram um pouco sobre o Desenvolvimento de Jogos, mas agora, nesta disciplina, vamos explorar sobre o Desenvolvimento de Jogos.

No decorrer do livro, você conhecerá sobre os conceitos do desenvolvimento de jogos, além das principais e mais utilizadas plataformas de desenvolvimento de jogos. Os conteúdos apresentados no decorrer deste livro serão essenciais quando chegar o momento de você iniciar o desenvolvimento dos seus jogos.

Um dos conteúdos de maior relevância no desenvolvimento de jogos são as fases de pré-produção, produção e pós-produção. Através da execução, devemos ter como resultado um jogo bem planejado e desenvolvido, mas vamos deixar um pouco de mistério até começar a segunda unidade.

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

Na Unidade 2, abordaremos sobre a produção de jogos, conheceremos métodos de gerenciamento de projetos e as três frases de produção de jogos.

Por fim, na Unidade 3, aprenderemos sobre a documentação de projetos de jogos e o desenvolvimento de jogos mobile, em que conheceremos mais sobre o desenvolvimento de jogos para sistemas Android e IoS.

Bons estudos e sucesso em sua trajetória!

Prof.ª Tatiana Tozzi

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 .................................................................... 31 INTRODUÇÃO ................................................................................................................................... 32 INTRODUÇÃO AOS JOGOS 2D ..................................................................................................... 33 MODELAGEM DE AMBIENTES 2D ............................................................................................... 74 SPRITES ............................................................................................................................................... 105 FÍSICA E ANIMAÇÃO EM 2D ....................................................................................................... 126 DISPOSITIVOS DE ENTRADA ..................................................................................................... 137 GAME ENGINES ................................................................................................................................ 14RESUMO DO TÓPICO 1..................................................................................................................... 16AUTOATIVIDADE .............................................................................................................................. 17

TÓPICO 2 — DESENVOLVIMENTO DE JOGOS 3D .................................................................. 191 INTRODUÇÃO ................................................................................................................................. 192 INTRODUÇÃO AOS JOGOS 3D ................................................................................................... 193 USO DE MODELOS 3D ................................................................................................................... 224 TÉCNICAS DE GAMEPLAY ............................................................................................................ 235 INTERAÇÃO ...................................................................................................................................... 246 SCRIPTS ............................................................................................................................................... 257 ANIMAÇÃO EM 3D ......................................................................................................................... 26RESUMO DO TÓPICO 2..................................................................................................................... 32AUTOATIVIDADE .............................................................................................................................. 33

TÓPICO 3 — DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA ............................. 351 INTRODUÇÃO ................................................................................................................................. 352 PLANO DE DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA ............................. 363 METODOLOGIAS DE DESENVOLVIMENTO DE JOGOS .................................................... 384 GDD – DOCUMENTO DE GAME DESIGN ................................................................................. 465 SISTEMA DE BANCO DE DADOS ............................................................................................... 486 GÊNEROS ........................................................................................................................................... 517 PLATAFORMAS ................................................................................................................................ 538 TIPOS E CARACTERÍSTICAS ....................................................................................................... 55LEITURA COMPLEMENTAR ............................................................................................................ 57RESUMO DO TÓPICO 3..................................................................................................................... 64AUTOATIVIDADE .............................................................................................................................. 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 ......................................................... 731 INTRODUÇÃO ................................................................................................................................. 732 MÉTODOS DE GERENCIAMENTO DE PROJETOS ................................................................ 73

2.1 PROCESSO PESSOAL DE SOFTWARE (PSP) .......................................................................... 752.2 SCRUM ........................................................................................................................................... 782.3 PROJECT MANAGEMENT INSTITUTE (PMI) ........................................................................ 82

3 CICLO DE PRODUÇÃO DE JOGOS ............................................................................................. 84RESUMO DO TÓPICO 1..................................................................................................................... 89AUTOATIVIDADE .............................................................................................................................. 90

TÓPICO 2 — FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO ....................................................... 931 INTRODUÇÃO ................................................................................................................................. 932 PRÉ-PRODUÇÃO .............................................................................................................................. 94

2.1 DEFINIÇÃO DO CONCEITO ..................................................................................................... 942.1.1 Início do processo ................................................................................................................ 952.1.2 Brainstorm .............................................................................................................................. 952.1.3 Conceito inicial ..................................................................................................................... 962.1.4 Gênero ................................................................................................................................... 972.1.5 Plataforma ............................................................................................................................. 972.1.6 Análise SWOT ...................................................................................................................... 972.1.7 Declaração da missão .......................................................................................................... 982.1.8 Cenário do jogo .................................................................................................................... 992.1.9 Mecânica do jogo ................................................................................................................. 992.1.10 Sinopse da história ........................................................................................................... 100

2.2 REQUISITOS DO JOGO ............................................................................................................. 1002.2.1 Definição dos recursos do jogo ........................................................................................ 1012.2.2 Definição das etapas e produtos ...................................................................................... 1032.2.3 Avaliação da tecnologia .................................................................................................... 1042.2.4 Definição das ferramentas e pipeline ............................................................................... 1042.2.5 Documentação .................................................................................................................... 1052.2.6 Análise de risco .................................................................................................................. 106

2.3 PLANEJAMENTO DO JOGO ................................................................................................... 1072.3.1 Dependências ..................................................................................................................... 1072.3.2 Cronograma ........................................................................................................................ 1072.3.3 Orçamento .......................................................................................................................... 1112.3.4 Equipe .................................................................................................................................. 111

2.4 GDD .............................................................................................................................................. 1132.5 LISTA DE VERIFICAÇÃO DA PRÉ-PRODUÇÃO ................................................................ 124

3 PRODUÇÃO ..................................................................................................................................... 1253.1 IMPLEMENTAÇÃO DO PLANO ............................................................................................ 1263.2 RASTREAMENTO DO PROGRESSO ...................................................................................... 127

3.2.1 Revisões de projeto ............................................................................................................ 1273.2.2 Reuniões .............................................................................................................................. 1273.2.3 Priorização .......................................................................................................................... 1273.2.4 Mudanças ............................................................................................................................ 1283.2.5 Processo de aprovação ...................................................................................................... 129

3.3 CONCLUSÃO DE TAREFAS .................................................................................................... 1293.4 LISTA DE VERIFICAÇÃO DA PRODUÇÃO ......................................................................... 129

RESUMO DO TÓPICO 2................................................................................................................... 131AUTOATIVIDADE ............................................................................................................................ 132

TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO ................................................................ 1331 INTRODUÇÃO ............................................................................................................................... 1332 TESTES .............................................................................................................................................. 133

2.1 PLANO DE TESTES ................................................................................................................... 1362.2 LIBERAÇÃO DO CÓDIGO ....................................................................................................... 1382.3 TDD ............................................................................................................................................... 1392.4 LISTA DE VERIFICAÇÃO DA EXECUÇÃO DE TESTES .................................................... 140

3 PÓS-PRODUÇÃO ............................................................................................................................ 1413.1 APRENDER COM A EXPERIÊNCIA ....................................................................................... 1423.2 PLANO DE ARQUIVAMENTO ............................................................................................... 1433.3 LISTA DE VERIFICAÇÃO DA PÓS-PRODUÇÃO ................................................................ 143

LEITURA COMPLEMENTAR .......................................................................................................... 144RESUMO DO TÓPICO 3................................................................................................................... 151AUTOATIVIDADE ............................................................................................................................ 152

REFERÊNCIAS .................................................................................................................................... 154

UNIDADE 3 — DOCUMENTAÇÃO E DESENVOLVIMENTO DE JOGOS MOBILE ............. 159

TÓPICO 1 — KITS DE FECHAMENTO ........................................................................................ 1611 INTRODUÇÃO ................................................................................................................................ 1612 DEFINIÇÃO DOS KITS DE FECHAMENTO ........................................................................... 1613 CRIANDO OS KITS DE FECHAMENTO .................................................................................. 162

3.1 ASSETS ......................................................................................................................................... 1643.2 FERRAMENTAS ......................................................................................................................... 1663.3 CÓDIGO DO JOGO .................................................................................................................... 1663.4 DOCUMENTAÇÃO ................................................................................................................... 167

4 ORGANIZAÇÃO DO CONTEÚDO ............................................................................................ 169RESUMO DO TÓPICO 1................................................................................................................... 173AUTOATIVIDADE ............................................................................................................................ 174

TÓPICO 2 — DESENVOLVIMENTO DE JOGOS NO ANDROID ......................................... 1771 INTRODUÇÃO ............................................................................................................................... 1772 INSTALAÇÃO DO UNITY ............................................................................................................ 179

2.1 TIPO DE GAMES ........................................................................................................................ 1833 ENGINE UNITY ................................................................................................................................ 1844 FERRAMENTAS DA ENGINE ..................................................................................................... 1865 TRABALHANDO COM OBJETOS .............................................................................................. 1916 LEVEL ................................................................................................................................................. 1937 COLISÕES DE FÍSICA ................................................................................................................... 1948 ELEMENTOS DO JOGO ................................................................................................................ 198

8.1 MENU E CONTROLES .............................................................................................................. 1988.2 EFEITOS SONOROS ................................................................................................................... 200

9 PUBLICANDO O JOGO ................................................................................................................ 201RESUMO DO TÓPICO 2................................................................................................................... 204AUTOATIVIDADE ............................................................................................................................ 205

TÓPICO 3 — DESENVOLVIMENTO DE JOGOS PARA IOS .................................................. 2071 INTRODUÇÃO ................................................................................................................................ 2072 BASE DO JOGO ............................................................................................................................... 2083 BACKGROUND E LOGO ............................................................................................................... 2104 CENAS DO JOGO ........................................................................................................................... 211

5 TRANSIÇÃO DE TELAS ............................................................................................................... 2156 ILUMINAÇÃO ................................................................................................................................. 2167 EXIBIÇÃO DO JOGO ..................................................................................................................... 2188 MELHORAR O JOGO .................................................................................................................... 2199 PUBLICANDO O JOGO ................................................................................................................ 220LEITURA COMPLEMENTAR .......................................................................................................... 225RESUMO DO TÓPICO 3................................................................................................................... 232AUTOATIVIDADE ............................................................................................................................ 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

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 cheios de recursos, isso varia conforme o objetivo do jogos que estão sendo desenvolvidos e qual software é utilizado em sua criação. Falando sobre software... vamos tratar dele mais adiante neste tópico.

No decorrer deste tópico, conheceremos sobre os jogos 2D, através de uma introdução sobre o seu desenvolvimento, os ambientes de modelagem, sprites, a física e animação, dispositivos de entrada e, por último, games engines.

Então, vamos começar nossa jornada no desenvolvimento de jogos 2D?

Bons estudos!

2 INTRODUÇÃO AOS JOGOS 2D

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

Segundo Cople (2019, p. 112), o desenvolvimento de jogos 2D “tem se tornado cada vez mais aquecido com o advento de plataformas móveis, gerando uma grande oportunidade para desenvolvedores independentes, principalmente devido ao baixo custo necessário para implementação e distribuição desse tipo de produto”.

UNIDADE 1 — DESENVOLVIMENTO MULTIPLATAFORMA E PLATAFORMAS ALTERNATIVAS PARA JOGOS

4

Mas o que é 2D? 2D significa que o jogo tem apenas duas dimensões, a largura e o comprimento. A Figura 1 demonstra duas imagens de um quadrado, a primeira em 2D e a segunda em 3D. Como podemos observar, o quadro 3D apresenta uma caracteriza a mais, a profundidade.

FIGURA 1 – EXEMPLO DE IMAGEM EM 2D E 3D

FONTE: <https://bit.ly/2Z4IhzH>. Acesso em: 28 jun. 2021.

Para começar, o que caracteriza um jogo 2D? Um jogo em duas dimensões, ou seja, utiliza dois eixos (x e y) para representar o ambiente do jogo. Os jogos 2D são planos, o jogo pode ir para frente ou para trás, não sendo utilizadas suas laterais. Como você pode observar na Figura 2, são apresentados o jogo Super Mario World em duas versões, a primeira imagem é a versão do jogo em 2D, já a segunda em 3D. Soares (2018, s. p.) destaca que o 2D “é um estilo tradicional que mostra dois ângulos e também mostra os objetos e personagens em um estilo de desenho animado”. Os cenários, personagens e animações são figuras planas em jogos 2D, conseguimos observar somente o que é exibido, sem uma sensação de espaço ou perspectiva que se tem em jogos 3D.

FIGURA 2 – EXEMPLO DE JOGOS 2D e 3D: SUPER MARIO WORLD

FONTE: <https://bit.ly/3C6asNc>. Acesso em: 28 jun. 2021.

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


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 final 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


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 baseada em comportamento e possibilita criar jogos mesmo sem conhecimentos em linguagem de programação (EBG, 2016, s.p.).

FIGURA 4 – SOFTWARE CONSTRUCT 2

FONTE: <https://bit.ly/3ne2lId>. Acesso em: 28 jun. 2021.

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


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.


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.

Unityhttps://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.


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, afim de descobrir qual você mais tem afinidade em utilizar. Explore esses softwares, mas não se limite a essa lista, uma vez que sempre surgem novos ambientes de desenvolvimento.

4 SPRITES

Os movimentos dos personagens contidos no jogo são gerados através de animação. Segundo Novak (2017, p. 172), “na maioria dos games 2D, a animação é restrita a pequenas áreas da tela que são controladas pelo jogador, (...) costumam ser chamadas de sprites e podem conter um personagem ou um objeto que se move sobre um fundo estático ou rolante”.

Os personagens ou objetos são representados por sprites, que são imagens sequenciais animadas quadro a quadro. Para Freitas (2014, p. 31), “sprites são imagens bidimensionais ou tridimensionais que se movem sem deixar traços na tela”. Já Cavaco (2007, p. 50) define sprites como:

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

A Figura 5 demonstra uma folha de sprites do Mario Bros, a folha de estilo também é conhecida em inglês como Sprite Sheet. Na Figura 5 podemos observar quadro a quadro os movimentos que o personagem pode realizar no jogo.


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


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, encontramos nos jogos eletrônicos características de dois grandes segmentos da física: mecânica clássica e ondulatória. Dessas áreas é comum a utilização dos conhecimentos da cinemática,


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

GamepadsTambé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 WIIUsado para controlar jogos, além de um dispositivo de entrada, também é um dispositivo de saída (som).


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á implementadas, assim, podemos criar o jogo com uma base pronta e implementar o que for necessário. Assim, não é necessário começar o jogo do zero (FREITAS, 2014).

Nemitz Neto (2015, p. 40) define que o Game Engines,

(...) são compostas por um conjunto de ferramentas de produção de conteúdo e um componente de execução. Conteúdo são scripts de inteligência artificial, imagens e sons que fazem parte de um jogo. O componente de execução é um sistema de software dirigido por dados que transforma o conteúdo providenciado pela equipe de desenvolvimento em um jogo digital.

Utilizando um ambiente de desenvolvimento ou uma biblioteca de funcionalidades, o game engines possue algumas características, conforme podemos observar no Quadro 4.

QUADRO 4 – CARACTERÍSTICAS DO GAME ENGINES

FONTE: Adaptado de Cople (2019)

Característica DescriçãoGraphic 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.


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 tem como tipos: 2D Lateral, Isométrico, 2D Vertical e 2D Estático. O jogo Mario Bros é um exemplo de jogo de 2D Lateral, já o jogo Sim City é do tipo isométrico, uma vez que temos a visão mais elevada. O jogo Space Ship é do tipo 2D vertical, e, por último, temos o 2D estático, representado aqui pelo famoso jogo da cobrinha, onde os limites laterais são preservados.

• Os ambientes de modelagem 2D possibilitam que jogos sejam desenvolvidos de maneira simples e rápida, pois muitos utilizam o recurso de arraste e solte, e na maioria das vezes a programação do jogo é realizada através das configurações que o desenvolvedor incluir no projeto do jogo.

• Sprites são imagens bidimensionais que ao se mover não deixam rastros. Através de folhas de sprites todos os elementos (personagens, objetos e demais elementos) tem seus possíveis movimentos criados, e os quais serão utilizados para dar vida a esses elementos no jogo.

• Em jogos mais avançados, os motores de física podem ser criados por um profissional. Já em projetos mais simples, pode-se utilizar as bibliotecas e frameworks para simular a física real.

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 alterativa CORRETA:

a) ( ) Largura X Altura.b) ( ) Largura X Comprimento.c) ( ) Comprimento X Profundidade.d) ( ) Altura X Resolução.

2 Um dos tipos mais conhecidos de jogos 2D. É aquele em que o personagem se move horizontalmente até o final da cena. Um exemplo desse tipo de jogo é o jogo Mario Bros. Sobre esse tipo de jogo, assinale a alternativa CORRETA:

a) ( ) Isométrico.b) ( ) 2D Estático.c) ( ) 2D Lateral. d) ( ) Jogo Horizontal.

3 Sprites representam personagens e objetos que irão compor o jogo. Cada um dos elementos é representado por desenhos quadro a quadro, os quais serão utilizados na animação dos elementos. Sobre o conjunto de imagens sequências, assinale a alterativa CORRETA:

a) ( ) Sprite Sheet.b) ( ) Sprite Page.c) ( ) Folha de animação.d) ( ) Plano sequência.

4 A física está presente em nosso cotidiano, e em jogos ela está presente no desenvolvimento das atividades que irão ocorrer no jogo. Disserte sobre função do motor de física.

5 Para interagir, ou melhor falando, jogar um jogo, contamos com vários dispositivos de entrada. Nesse contexto, disserte sobre três dispositivos de entrada que você mais utilizou ou conhece.

AUTOATIVIDADE

19


DESENVOLVIMENTO DE JOGOS 3D

1 INTRODUÇÃO

Olá, acadêmico! Neste tópico iremos abordar sobre os elementos presentes no desenvolvimento de jogos 3D. Alguns dos elementos conhecidos na Unidade 1, como: dispositivos de entrada, física, sprites e game engines, também se aplicam no desenvolvimento de jogos 3D. Neste tópico conheceremos novos elementos.

Para começar, vamos explorar sobre o desenvolvimento de jogos 3D através de uma introdução. Em seguida, abordaremos sobre o Uso dos Modelos 3D, conheceremos as Técnicas de Gameplay, Interação e Scripts.

Vamos começar nossa trajetória no desenvolvimento de jogos 3D?

Bons estudos!

2 INTRODUÇÃO AOS JOGOS 3D

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

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


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


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.


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

Kogamahttps://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 é 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 desenvolvimento simples com 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


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 FUTUROS


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


FIGURA 9 – MODELO DA DEFINIÇÃO DE GAMEPLAY

FONTE: Aguiar e Battaiola (2016, p. 537)

Conforme Aguiar e Battaiola (2016, p. 537):

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

O gameplay está presente em todos os elementos (nas regras do jogo, nas condições de vitória e derrota, nos modos de interatividade, nos tipos de desafios e metas dos games), desde o momento que o jogador inicia a partida (SENAC, 2019a).

5 INTERAÇÃO

A interação acontece quando o jogador inicia a jogo, ao se envolver com a regras as manipulações, os personagens, cenários, ou seja, quando o jogador se envolver com o universo do que está se jogando. Crawford (1982, p. 8-14) define a interação como:

(...) a coisa mais fascinante sobre a realidade não é que ela existe, ou mesmo que ela altera, mas como ela se altera, a intricada teia de causa e efeito pela qual todas as coisas se enlaçam. A única maneira de adequadamente representar essa teia é permitir a audiência explorar seus cantos e recantos, deixá-los gerar causas e observar efeitos. (...) Jogos proveem esse elemento interativo e é um fator crucial no seu apelo.


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


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


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


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.


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


29


Mo-tionbuil-der


Windows Pago asf, amc, bvh, c3d, fbx, htr, tr3

Blender


Windows, macOS, Linux

Gratuito3ds, dae, fbx, dxf, obj, x, lwo, svg, ply, stl, vrml, vrml97, x3d

Cinema 4D


Windows, macOS Pago

3ds, dae, dem, dxf, dwg, x, fbx, iges, lwf, rib, skp, stl, wrl, obj

Clara.ioAnimaçã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


Windows, macOS Gratuito obj, fbx, dae, daz

Houdini Appren-tice

Captura de movimento, Animação com keyframes


Gratuito (com limi-tações)

bgeo, clip, fbx, geo, hip

iClone


Windows Pago 3ds, bvh, fbx, obj, vns, skp

iPi Soft Captura de movimento Windows Pago bvh, fbx

MakeHu-man



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/#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/#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



Maya



Pagoai, aiff, dae, dxf, dwg, eps, fbx, maya, mel, obj, stl

mixamo


Navega-dor da internet

Gratuito bhv, fbx, obj

modo



Pagolwo, abc, obj, pdb, 3dm, dae, fbx, dxf, x3d, geo, stl,

Poser Pro


Windows, macOS Pago bvh, cr2, obj, pz2

TerragenAnimação de quadros-chave (keyframes)


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


Gratuito avi, mov, mpg

Dragon-frame Stop Motion


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 2DWindows, 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


31


Synfig Studio Animação 2D


Gratuitoavi, 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


• 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

35


DESENVOLVIMENTO DE JOGOS MULTIPLATAFORMA

1 INTRODUÇÃO

Bem-vindo, ao terceiro tópico da Unidade 1! No decorrer deste tópico, iremos abordar sobre o Desenvolvimento de Jogos Multiplataforma. Iniciaremos conhecendo o que é o Plano de Desenvolvimento de Jogos Multiplataforma. Em seguida, iremos diferenciar as Metodologias de Desenvolvimento, veremos os elementos presentes do GDD (Documento de game design) e, na sequência, abordaremos sobre Sistema de banco de dados, os Gêneros dos jogos, as plataformas utilizadas para jogar e os Tipos e características dos jogos.

Antes de iniciarmos, você sabe o que significa multiplataforma? O dicionário on-line de Língua Portuguesa Dicio define o termo multiplataforma como:

Característica do programa, software ou aplicativo que pode funcionar em várias plataformas (dispositivos) diferentes: jogos multiplataforma. Particularidade do conteúdo que é transmitido em diferentes plataformas, como televisão, computador, tablets e smartphones: comunicação multiplataforma (MULTIPLATAFORMA, 2021, s. p.).

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

Vamos começar nossa jornada no desenvolvimento de jogos multiplataforma?

Bons estudos!

36


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/.

INTERESSANTE

38


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 tem como origem a Engenharia de Software. Entretanto, já ocorreram iniciativas para se adaptar algumas metodologias para o desenvolvimento de jogos, como no caso das metodologias Game Waterfall Process (Modelo Cascata para Jogos), eXtreme Game Development (XGD) e a Gamescrum.

Podemos utilizar uma metodologia tradicional (cascata, incremental,

iterativa, evolucionária ou espiral) ou uma metodologia ágil (XP, Design Thinking, Gamescrum, FDD ou Scrum). Na Figura 15 podemos observar as principais diferenças entre as metodologias tradicionais das ágeis. Uma das principais diferenças entre metodologias tradicionais e ágeis, conforme o IEEP (2020, s.p.), é que “as metodologias tradicionais se baseiam, em etapas mais rígidas e controladas, enquanto as metodologias ágeis se fundamentam na flexibilidade e adaptabilidade das estratégias”.

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 FUTUROS


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


Na Figura 17 podemos observar uma versão da metodologia cascata que foi adaptada para o desenvolvimento de jogos. Ela é conhecida como Game Waterfall Process, porém, assim como a versão original, é pouco flexível (TEIXEIRA; GONÇALVES, 2015). No entanto, apesar dessa rigidez das sequências, essa metodologia foi uma das mais utilizadas para a criação de jogos (SILVA, 2016 apud THORN, 2013).

FIGURA 17 – SEQUÊNCIA DA METODOLOGIA GAME WATERFALL PROCESS

FONTE: Teixeira e Gonçalves (2015, p. 13)

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

Nesse processo, é feita a comunicação, ou seja, o levantamento do conjunto de requisitos da parte do jogo que será desenvolvida, planejada, analisada, codificada e testada. Logo, não se verificam os erros apenas no final do processo de desenvolvimento, mas a cada iteração eliminando o problema apresentado pela metodologia em cascata.


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 utilizas em conjunto e se complementam.

FIGURA 19 – CICLO DA METODOLOGIA EVOLUCIONÁRIA / ESPIRAL (RUP)


Conforme o SENAC (2019c, s.p.), “o processo mais conhecido é o processo unificado, que tem sua sistematização desenvolvida pela Rational, o Rational Unified Process (RUP). Esse processo, também, contempla as fases de concepção, elaboração, construção e transição”.

FIGURA 18 – CICLO DA METODOLOGIA ITERATIVA

42


Se nas metodologias tradicionais o foco é no processo, as metodologias ágeis têm seu foco nas pessoas e em sua comunicação, com isso a burocracia foi reduzida (SENAC, 2019c).

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

FIGURA 20 – CICLO DA METODOLOGIA XP


Foi criada uma versão da XP para o desenvolvimento de jogos, a eXtreme Game Development (XGD), que utiliza os princípios e boas práticas do XP. Sua criação foi motivada, segundo Carvalho (2006 apud FREITAS, 2014, p. 14) pelos “(...) constantes atrasos presentes no desenvolvimento de jogos, em conjunto com as altas penalidades impostas pelas publicadoras sobre os atrasos. Isso faz com que a equipe de desenvolvimento trabalhe sobre grande pressão e aumenta as chances da entrega de milestones instáveis”. O XGD se baseia em cinco princípios do XP, como apresentado no Quadro 7.


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



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-upReuniões rápidas de projeto, com objetivo de que toda a equipe esteja ciente do trabalho que está sendo feito num dado momento.


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 iremos abordar em nossa próxima Unidade, pois além de uma metodologia, o Scrum também pode ser utilizado na gestão do processo de desenvolvimento de jogos.

ESTUDOS FUTUROS

46


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 iremos abordar sobre as três fases do Games-crum: Pré-produção, Produção e Pós-produção.

ESTUDOS FUTUROS


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.


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 jogoOu Game Art, devem ser demonstrados os desenhos do jogo, como personagens, ambientes, guia de estilo, entre outros objetos do jogo.

48


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.

INTERESSANTE


49

• persistência para salvar e recuperar o progresso no jogo: quando o jogador pausa o jogo, é necessário salvar o ponto em que foi pausado, e carregado quando reiniciado (SILVA, 2017).

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


• Modelo hierárquico: “(...) organiza seus dados conectando registros diferentes, por meio de ligações, de tal modo que cada tipo de registro tenha apenas um pai, formando, assim, uma estrutura parecida, como uma árvore com ramificações, a partir de uma raiz” (SENAC, 2019e, p. 8). A Figura 24 demonstra um exemplo de banco hierárquico.

FIGURA 24 – EXEMPLO DE DADOS PARA O BANCO HIERÁRQUICO


• Modelo relacional: “(...) modela o conjunto de dados de uma forma que eles sejam percebidos pelo usuário, como tabelas, ou mais formalmente, como relações” (SENAC, 2019e, p. 9). A Figura 25 demonstra um exemplo de banco relacional.

FIGURA 25 – BANCO DE DADOS RELACIONAL



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 possui um gênero ou subgênero (PEREIRA, 2019; BIURRUM, 2015). Novak (2017, p. 96) define gênero de jogos como “categorias baseadas em uma combinação de tema, ambiente, apresentação/formato na tela, perspectiva do jogador e estratégias de jogo”.

As principais classificações de jogos foram criadas por tipologias:

• BECTA (British Educational Communications and Technology Agency) – 2003, define uma classificação que englobe vários gêneros de jogos conforme o estilo, temática, narrativa e atividade. O Quadro 10 demonstra os gêneros da tipologia BECTA

QUADRO 10 – TIPOLOGIA BECTA

Gênero DescriçãoAção e

aventuraElementos 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


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 eConstruçã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).


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 eLógica

Jogos de tabuleiro e junção de peças, como Xadrez e Tetris (raciocínio, memória, lógica e estratégia).

Perguntas Exemplos deste 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


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.


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


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.

JogoQue é 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 iremos continuar explorando o desenvolvimento de jogos. Até lá!

FIGURA 28 – FINAL DA UNIDADE 1

FONTE: <https://bit.ly/3876DtS>. Acesso em: 15 jul. 2021.


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 adaptabilidade da inteligência humana nem sempre é necessária ou desejada para produzir tais comportamentos.

Embora exista esse problema, um fato que surpreendeu muitas pessoas da indústria ocorreu durante a mesa-redonda de IA na Game Developers Conference (GDC) de 1999: diversos membros da parte de pesquisa acadêmica sobre IA estavam presentes no evento e puderam compartilhar e discutir ideias sobre o assunto com os desenvolvedores de jogos. Durante o evento, alguns desses pesquisadores admiraram a rápida evolução de desenvolvimento da indústria de jogos, dizendo que a indústria de jogos parecia estar anos-luz à frente do

LEITURA COMPLEMENTAR

58


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).


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


jogador” e tenta alcançar o jogador. Se durante esse tempo o jogador ganha a habilidade de engolir o fantasma, o fantasma muda seu estado para “fugindo do jogador” (BOURG, 2004).

Os desenvolvedores também utilizam a lógica fuzzy em máquinas de estado fuzzy para criar resultados de ações que são menos previsíveis e para reduzir o grande trabalho de enumerar a grande quantidade de regras if-then. A lógica fuzzy permite criar regras usando condições menos precisas, criando agentes com um conhecimento imperfeito, uma vez que essa lógica é baseada em níveis de incerteza e verdades em uma sentença (WOODCOCK, 1999) (BOURG, 2004).

3.2.3 – Sistemas baseados em regras

Alguns fenômenos não são fáceis de ser modelados em termos de estados e transições. Considerando como exemplo os seguintes fenômenos de um cachorro virtual:

- se há um osso por perto e o cachorro está com fome, ele irá comê-lo;- se o cachorro está com fome, mas não há nenhum osso por perto, ele

procura por um;- se o cachorro não está com fome, mas está com sono, ele irá dormir;- se o cachorro não está com fome e não está com sono, o cachorro irá

andar e latir.

Essas quatro sentenças são difíceis de serem representadas através de uma máquina de estados, pois cada sentença leva a um estado da máquina e cada estado pode transitar para qualquer um dos outros estados. Esse tipo de problema é conhecido por comportamento global. Máquinas de estado são úteis para situações locais (onde dado um estado, apenas algumas condições podem ser aplicadas como saída).

Nesse exemplo, o cachorro se comporta de acordo com um conjunto de prioridades ou regras. Um sistema baseado em regras tem a forma “Condição _ Ação”. No exemplo citado, as regras teriam a seguinte forma:

- Fome & osso por perto _ comer.- Fome & não osso por perto _procurar.- Não fome & com sono _ dormir.- Não fome & sem sono _ andar e latir.

Dessa maneira, são especificadas as condições que ativam as regras, assim como quais ações devem ser tomadas caso a regra é ativada (DALMAU, 2004).


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 “burra”), o resultado é personagens que parecem totalmente artificiais e sem inteligência de navegar entre locais e desviar de obstáculos, o que acaba com a imersão do jogo e a diversão (BOURG, 2004).

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

Como o uso de busca pode consumir muito tempo do processador, é possível contornar esse problema através de caminhos pré-calculados, chamados de waypoints, quando o jogo permite esse tipo de solução. Os waypoints são nós em locais do mundo virtual que auxiliam no deslocamento de um lugar (nó atual) para outro (nó destino) através de caminhos pré-calculados ou métodos de busca de baixo custo (BOURG, 2004).

3.2.5 – Algoritmos genéticos

Dalmau (2004) cita que um dos usos de algoritmos genéticos em jogos pode ser a geração de uma população, criando diferentes indivíduos de acordo com um DNA virtual, sendo esse representado por um vetor de valores, cada um sendo um parâmetro da espécie a ser modelada. Essa técnica pode ser utilizada para a criação de pedestres em um jogo onde o mundo virtual seja uma cidade. (DALMAU, 2004) e (LAMOTHE, 1999) também citam o uso de algoritmos genéticos para mutação ou evolução de personagens.

3.2.6 – Outras técnicas

A IA para jogos não para por aqui. Existem outras técnicas que não foram discutidas e que são aplicadas nos jogos. O uso de A-Life é uma delas. Alguns jogos utilizam algoritmos de flocking para simular o movimento em grupo de monstros, pássaros, peixes, entre outros (WOODCOCK, 1999). A implementação de redes neurais em jogos também é realizada, onde os personagens necessitam de aprendizado através das escolhas do jogador, como no jogo Black & White (um gênero onde o jogador assume a posição de deus e controla o ambiente do jogo) (BOURG, 2004). Ainda, há jogos (por exemplo, Baldur’s Gate e Unreal) que implementam a IA através de scripts, possibilitando que qualquer pessoa possa criar novos tipos de NPC’s (non-player characters) ou modificar um personagem já existente de acordo com o seu estilo de jogo. Esse tipo de IA (também conhecido por Extensible AI) é baseada fortemente em sistemas de regras (WOODCOCK, 1999).

62


3.3 – BENEFÍCIOS DO USO DE IA EM JOGOS

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

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

3.4 – PROBLEMAS ENVOLVENDO IA E JOGOS

Embora os desenvolvedores tenham encontrado muitas soluções através da implementação de IA nos jogos, muitos problemas também aparecem pelo uso de IA em jogos. Quatro fatores podem ser citados como principais problemas da IA para jogos:

- Período de desenvolvimento: o curto período de desenvolvimento dos jogos dificulta o aprendizado dos desenvolvedores para tecnologias de ponta sobre IA e suas aplicações em um jogo comercial (BOURG, 2004);

- Algoritmos de aprendizado: os resultados produzidos por algoritmos de aprendizado são difíceis de serem testados e depurados contra erros, visto que os resultados não são previsíveis. Por essa razão, muitos desenvolvedores têm preferência por técnicas de IA determinísticas, e por serem mais conhecidas por eles e de fácil implementação e depuração (WOODCOCK, 1999);

- Poder de processamento: jogos são softwares com execução em tempo real, onde informações são processadas e atualizadas a cada ciclo de máquina. Algoritmos com alto custo de processamento (ainda) não podem ser implementados em jogos que necessitam de respostas em tempo real (TOZOUR, 2002);


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 NPC’s. Surge, então, o seguinte conflito: os designers controlam o comportamento dos NPC’s. É preciso, então, o uso de IA? Em contrapartida, se a IA estiver presente (NPC’s inteligentes podem se comportar com autonomia), é preciso ter designers? A solução para esse caso é os game designers e programadores de IA entrarem em um acordo sobre o controle sobre os NPC’s do jogo (CHAMPANDARD, 2003).

(...)

FONTE: Adaptado de <https://bit.ly/3vDVJa8>. Acesso em: 26 jun 2021.

64

RESUMO DO TÓPICO 3


• Jogos multiplataformas significa que um jogo poderá ser utilizado em vários dispositivos (plataforma).

• O desenvolvimento de jogos é realizado em etapas: concepção, pré-produção, produção e pós-produção.

• Na etapa de Concepção são realizadas as atividades de narrativa, papel e objetivos, cenário e gameplay.

• Os bancos de dados para jogos que são mais utilizados são: base de dados de tipos, base de dados de modelos e persistência.

• As principais classificações de jogos são das tipologias BECTA e GRAELLS;

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 uma sequência de fases, essas fases guiam o desenvolvimento, elas podem iniciar após a finalização da fase anterior ou também serem executadas paralelamente, assim uma complementa a outra. Sobre essas fases sequências, assinale a alternativa CORRETA:

a) ( ) Ideação, Reunião, Produção, Finalização.b) ( ) Introdução, Revisão, Produção, Finalização.c) ( ) Ideação, Pré-produção, Produção, Finalização.d) ( ) Concepção, Pré-produção, Produção, Finalização.

2 A Engenharia de Software, auxilia no desenvolvimento de jogos ao trazer as metodologias de desenvolvimento. No desenvolvimento de jogos, algumas metodologias foram adaptadas. Sobre essas metodologias, assinale a alternativa CORRETA:

a) ( ) Metodologia Evolucionária para jogos e Metodologia Incremental Games.

b) ( ) Game Waterfall Process e eXtreme Game Development.c) ( ) Waterfall Process Development e Metodologia Incremental Games.d) ( ) Waterfall Process Development e eXtreme Game Programming.

3 Projeto de banco de dados para jogos é desenvolvido em três etapas, os três modelos podem serem desenvolvidos na sequência, ou seja, a partir do primeiro é criado o seguinte com base no que foi desenvolvido, tendo uma nova perspectiva. Sobre as etapas, assinale a alternativa CORRETA:

a) ( ) Modelo de domínio, modelo lógico e modelo físico.b) ( ) Modelo Conceitual, modelo lógico e modelo físico.c) ( ) Modelo Conceitual, modelo dinâmico e modelo físico.d) ( ) Modelo Conceitual, modelo lógico e modelo relacional.

4 Os gêneros de jogos são categorias, atualmente existem mais de 100 gêneros diferentes, porém foram criadas duas tipologias para agrupar gêneros, a BECTA e a GRAELLS. Disserte sobre a diferença entres essas duas tipologias de gêneros.

5 Jogos possuem tipos diferentes e agradam a diferentes jogadores, Andrzey Marczewski, definiu quatro tipos de jogos, disserte sobre os tipos de jogos: Design inspirado em jogos e Gamificação.

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, 2018. Metodologias para Desenvolvimen-to de Jogos. 2018. Disponível em: https://www.fabricadejogos.net/posts/metodo-logias-para-desenvolvimento-de-jogos/. Acesso em: 11 jul. 2021.

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


PLANO DE ESTUDOS


• compreender as fases de desenvolvimento (pré-produção, produção, testes e pós-produção) de produção de jogos;

• conhecer os métodos de gerenciamento para utilização em projetos de desenvolvimento de jogos;

• aprender sobre as técnicas de Brainstorm e MoSCoW;• conhecer os diferentes ciclos de desenvolvimento de jogos.


TÓPICO 1 – MÉTODOS DE GERENCIAMENTO DE PROJETO E INTRODUÇÃO A PRODUÇÃO DE JOGOS

TÓPICO 2 – FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO

TÓPICO 3 – TESTES E FASE DE PÓS-PRODUÇÃO


CHAMADA

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, iremos abordar sobre a Produção de Jogos. Para iniciarmos, iremos conhecer, no Tópico 1, sobre os Métodos de Gerenciamento de Projeto e uma breve introdução sobre a produção de jogos.

No decorrer deste tópico iremos conhecer sobre o métodos de gerenciamento de projetos são abordados no desenvolvimento de jogos, os métodos de gerenciamento que iremos conhecer, além pode derem ser utilizados no desenvolvimento de jogos são utilizados no desenvolvimento de tecnologias, porém, também podem ser aplicados em projetos, em seguida explorar sobre o Processo pessoal de software (PSP), a metodologia SCRUM, o Project Management Institute (PMI) e por último conheceremos o Ciclo de produção de jogos.

Vamos começar a nossa jornada agora, padawan! Bons estudos!

2 MÉTODOS DE GERENCIAMENTO DE PROJETOS

Em nossa unidade anterior, conhecemos algumas metodologias utilizadas no desenvolvimento de jogos, agora iremos conhecer alguns métodos de gerenciamento de projetos. A metodologia XP (Extreming Programing) que vimos anteriormente também é utilizada como um gerenciador de projetos. Bom, mas vamos conhecer novos métodos agora.

O que significa o termo projeto? Tão presente em nosso cotidiano, esse termo pode passar despercebido. Segundo Espinha (2021), projeto é definido como:

Um projeto é um esforço único, temporário e progressivo empreendido para criar um produto, serviço ou resultado exclusivo.Isso significa que um projeto é uma ação especial que tem início e fim determinados (é, portanto, temporária), e um objetivo claro a ser atingido dentro dos recursos que são destinados a ele (humanos, financeiros e materiais). Geralmente, os projetos são divididos em etapas, as quais vão sendo executadas para gerar entregas (ESPINHA, 2021, s. p.).

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


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)


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çãoO 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.


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 sobre 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.


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).

IMPORTANTE


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,


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


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, é 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


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 metodologias que vimos anteriormente possuem processos e fases de desenvolvimento mais simples, porém é comum que essas metodologias seja paralelamente, ou seja, uma auxiliando a outra e claro melhorando o

Profª. Miriam De Cassia Do Carmo Mascarenhas MattosProfª. Raffaela Dayane Afonso

4.1 - INTEGRAÇÃO

13.1 - PARTES INTERESSADAS

4.2 - INTEGRAÇÃO

5.1 - ESCOPO

5.2 - ESCOPO

6.1 - CRONOGRAMA6.2 - CRONOGRAMA

6.3 - CRONOGRAMA

6.5 - CRONOGRAMA6.4 - CRONOGRAMA

7.2 CUSTOS7.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


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


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

PARTESINTERESSADAS

CRONOGRAMA

DESENVOLVER OTERMO DEABERTURA

DO PROJETO

MONITORARE CONTROLAR

O TRABALHO DOPROJETO

DESENVOLVER O PLANODE GERENCIAMENTO DO PROJETO

ORIENTAR E GERENCIARO TRABALHO DO PROJETO

GERENCIAR O CONHECIMENTO

DO PROJETO

ENCERRAR OPROJETO OU FASE

REALIZAR O CONTROLE

INTEGRADO DEMUDANÇAS

PLANEJAR OGERENCIAMENTO

DO ESCOPO

COLETAR OS REQUISITOS

DEFINIR OESCOPO

VALIDAR OESCOPO

CONTROLAR O ESCOPO

CRIAR A EAP


DO CRONOGRAMA


DO CUSTO

DETERMINAR OORÇAMENTO

ESTIMAR OSCUSTOS


DA QUALIDADE

CONTROLAR AQUALIDADE

REALIZAR AQUALIDADE

CONTROLAROS CUSTOS

MONITORAR ASCOMUNICAÇÕES

GERENCIAR ASCOMUNICAÇÕES

DEFINIDAS ASATIVIDADES

ESTIMAR ASDURAÇÕES DAS

ATIVIDADES

DESENVOLVER OCRONOGRAMA

SEQUENCIAR ASATIVIDADES

CONTROLAR OCRONOGRAMA

IDENTIFICAROS RISCOS

MONITORAR OENGAJAMENTO

DAS PARTESINTERESSADAS

GERENCIAR OENGAJAMENTO


PLANEJAR OENGAJAMENTO


CONTROLAR ASAQUISIÇÕES

CONDUZIR ASAQUISIÇÕES


DE RISCOS

REALIZARA ANÁLISE

QUALITATIVADOS RISCOS

REALIZARA ANÁLISE

QUANTITATIVASDOS RISCOS

PLANEJARRESPOSTASAOS RISCOS

MONITORAR OSRISCOS

IMPLEMENTARRESPOSTAS A RISCOS


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/.

INTERESSANTE


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 AlphaDetalhamento Formal

Pré-Produção Produção

Teste Beta Lançamento

-


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 FUTUROS


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 4Perspectiva 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 e

sua 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ódigoNã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 ouconteúdos adicionais

aprendizado com aexperiência, e

planode arquivamento

inclusão de recursos, e

avaliação da receptividade


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


• 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 utilizados por outros profissionais. Sobre os objetivos do PSP, assinale a alternativa CORRETA:

a) ( ) Ajudar somente os engenheiros de software a serem melhores, utilizar no gerenciamento de projetos profissionais e pessoais, melhorar a produtividade.

b) ( ) Ajudar os engenheiros de software e demais integrantes da equipe a serem melhores, utilizar somente no gerenciamento de projetos profissionais, melhorar a qualidade.

c) ( ) Ajudar os integrantes da equipe a serem melhores, utilizar no gerenciamento de projetos profissionais e pessoais, reduzir os resultados.

d) ( ) Ajudar os engenheiros de software e demais integrantes da equipe a serem melhores, utilizar no gerenciamento de projetos profissionais e pessoais, melhorar a produtividade.

3 A metodologia ágil Scrum é uma das mais utilizadas atualmente no desenvolvimento de recursos tecnológicos, seja como uma metodologia de desenvolvimento de software ou como um gerenciamento de projetos. Sobre as características que fazem o Scrum uma das opções mais utilizas, assinale a alternativa CORRETA:

a) ( ) Metodologia burocrática, como acompanhamento difícil e complexo.b) ( ) Metodologia burocrática, comunicação clara, relatórios visuais e

informais. c) ( ) Metodologia menos burocrática, comunicação clara, relatórios visuais

e informais. d) ( ) Metodologia menos burocrática, equipe desintegrada e dividida,

relatórios visuais.

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.

93

UNIDADE 2

1 INTRODUÇÃO

Olá, acadêmico! Seja bem-vindo ao Tópico 2! No decorrer deste tópico iremos abordar sobre as fases de Produção de Jogos. A Figura 12 demonstra as duas fases que iremos conhecer neste tópico, sendo as fases de Pré-produção e Produção. Lembrando que esse ciclo é composto por quatro fases, conforme estabelece Schuytema (2008).

FIGURA 12 – FASES DE DESENVOLVIMENTO DE JOGOS

FONTE: A autora

Ao longo deste tópico, abordaremos na fase de Pré-produção sobre a definição do conceito de jogo, os requisitos, como é realizado um planejamento de jogo e o GDD. Já na fase de Produção, conheceremos sobre a implementação do plano, o rastreamento do progresso de desenvolvimento, a criação de builds e a conclusão de tarefas. Essas duas fases contém um item similar à Lista de verificações, que tem como função identificar se tudo o que foi idealizado naquela fase foi concluído. Bom, como você pode perceber, temos muitos assuntos a tratar.

Que você tenha uma excelente jornada de estudos!

TÓPICO 2 —

FASES DE PRÉ-PRODUÇÃO E PRODUÇÃO

94


2 PRÉ-PRODUÇÃO

A primeira fase do ciclo de produção que é a fase de pré-produção, nela são definidos o que iremos criar, quem será o público-alvo do jogo, “(...) significa a decisão de qual tipo de jogo que será produzido, teste de algumas ideias geradas e levantamento dos custos de produção, tempo e equipe. É normalmente uma etapa que demanda um certo tempo” (CREDIDIO, 2007, p. 19).

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

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

2.1 DEFINIÇÃO DO CONCEITO

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

Chandler (2012) afirma que “muitos conceitos inicialmente são vagos e a equipe primária de desenvolvimento deve destrinchá-los para que todos entendam facilmente quais são os objetivos do produto e quais devem ser os principais elementos de jogabilidade necessários ao seu suporte e fortalecimento”.

A definição do conceito do jogo não é uma atividade simples, uma vez que ideias consideradas originais e que venham ser identificadas como inovadoras, acabam sendo abandonadas por não ser possível criar aplicações com as mecânicas de jogo. Por isso o processo de definição de conceito deve ser realizado com muita atenção e cuidado (SATO, 2010).

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 duas perguntas:

1°. O que vai ser feito?2°. Para quem vai ser feito?

A primeira pergunta busca identificar sobre qual o gênero será o jogo e quais os elementos de narrativa serão utilizados. A segunda pergunta busca identificar o público-alvo do jogo que será desenvolvido (CHANDLER, 2012).

Além de responder essas perguntas, é comum serem criados protótipos do jogo, mas nada de muitos detalhes e recursos tecnológicos para criá-los. O ideal é ser realizado manualmente, utilizado papéis ou lousas. Outra opção que podemos utilizar é identificar jogos similares e avaliá-los para ver o que vem sendo desenvolvido e jogado pelo público-alvo.

2.1.2 Brainstorm

O brainstorm ou tempestade de ideias, como é conhecido na língua portuguesa é uma técnica para gerar ideias, no desenvolvimento de jogos o brainstorm é realizado para escolher a melhor ideia do jogo. Marques (2015) ressalta que o brainstorm,

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

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.

INTERESSANTE

96


Nestas sessões, todos os integrantes da equipe devem compartilhar suas ideias, mesmo quando consideradas ‘bobas’, pois podem ser discutidas e se tornar uma excelente ideia de desenvolvimento. O que é necessário para que uma sessão de brainstorm ocorra? A Figura 13 apresenta a estrutura necessária para uma sessão.

FIGURA 13 – ESTRUTURA DE UMA SESSÃO DE BRAINSTORM

FONTE: <https://bit.ly/3vSxMvJ>. Acesso em: 27 jul. 2021.

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

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.

INTERESSANTE


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 aos se definir o gênero do jogo é uma maneira dele ser categorizado, assim a equipe pode melhor visualizar com maior facilidade a mecânica do jogo, vale ressaltar que a escolha do gênero afeta todo o desenvolvimento do jogo (RIBEIRO, 2016).

2.1.5 Plataforma

A escolha da plataforma é a definição de em qual plataforma nosso jogo irá ser executado, Ribeiro (2006), aponta que a plataforma

(...) é o hardware utilizado para rodar o jogo. Pode se tratar de um console específico para jogos, um computador, notebook, tablet, smartphone ou um sistema imersivo. Muitas vezes, os jogos digitais são desenvolvidos para mais de uma plataforma (RIBEIRO, 2016, p. 56).

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

2.1.6 Análise SWOT

A análise SWOT pode auxiliar no processo de definição do conceito do jogo (CHANDLER, 2012), porém a análise SWOT é muito utilizada na área de Marketing e Administração, mas pode ser utilizada para a concepção do jogo. A Figura 14 demonstra a estrutura do SWOT.

98


FIGURA 14 – ESTRUTURA DA SWOT

FONTE: <https://rockcontent.com/br/wp-content/uploads/sites/2/2021/02/swot-1.png>. Acesso em: 27 jul. 2021.

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

2.1.7 Declaração da missão

A declaração da missão estimula a equipe ao se desenvolver o jogo. Através da declaração é definido o que será feito e para quem será feito. Chandler (2012) define a declaração da missão

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

Com isso, podemos definir que ao se realizar uma declaração de missão, estamos definindo qual o jogo será desenvolvido e para qual público-alvo ele será pensado e criado.


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 elemento são animados ou dinâmicos quando o cenário se movimenta conforme os comandos ou movimentos do jogador (COPLE, 2019). Velasquez (2009) define o cenário como:

(...) o espaço onde se desenrola o jogo. Pode ser mais do que um e se for tridimensional deve permitir o seu percurso em vários sentidos. É o modelo de interacção, a maneira como o jogador interage com esse espaço/mundo (1ª ou 3ª pessoa). Finalmente o mundo do jogo (VELASQUEZ, 2009, p. 39).

Uma boa prática para elaboração dos cenários do jogo é através da prototipação, onde a equipe pode criar rascunhos em papel mesmo ou utilizando um software de criação de protótipos para que todos tenham uma ideia compartilhada dos cenários que serão criados para o jogo. Outra alternativa é a criação de Storyboards de como será o jogo, suas fases ou níveis.

2.1.9 Mecânica do jogo

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

“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


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”.


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 iremos conhecer os elementos que compõem os requisitos do jogo, na figura 15 podemos observar as etapas que envolvem a descrição dos requisitos do jogo.

FIGURA 15 – LISTA DE RECURSOS CATEGORIZADOS

FONTE: Adaptado de Chandler (2012)

2.2.1 Definição dos recursos do jogo

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

(...) recursos multijogador, recursos de jogador único, a mecânica, o som e qualquer aspecto do jogo. Reúna todas as opiniões sobre os recursos em uma única lista e então categorize-as por tipo. Isso ajudará o produtor e os líderes a priorizarem melhor os recursos. Algumas categorias que devem ser consideradas são as seguintes:

102


Processo: Esses recursos estão ligados à melhoria do processo de desenvolvimento. (...)Produção: Esses recursos envolvem melhorias nas ferramentas e na tecnologia usadas na criação do jogo. (...)Jogabilidade: Esses recursos são compostos por elementos de jogabilidade que afetarão diretamente a experiência do jogador e que podem ser vistos por ele (CHANDLER, 2012, p. 238).

Uma estratégia é utilizar uma lista para com as categorias para assim ter melhor controle sobre os tipos de recursos que serão escolhidos, a Figura 16 demonstra um exemplo de lista de recursos categorizados (CHANDLER, 2012).

FIGURA 16 – LISTA DE RECURSOS CATEGORIZADOS


Após a categorização dos recursos na lista, os líderes do projeto devem atribuir prioridades para os itens arte, engenharia, design e teste. Cada recursos deverá atribuir uma pontuação para os recursos, sendo 3 como prioridade alta e 1 para mais baixa. A Figura 17 apresenta uma planilha de pontuação de recursos classificada por pontuação (CHANDLER, 2012).


103


2.2.2 Definição das etapas e produtos

A definição das etapas é realizada para que seja possível realizar o rastreamento do progresso do desenvolvimento do jogo, assim, através das etapas definidas os objetivos para cada uma das etapas são criados, com isso o desenvolvimento se torna mais gerenciável, para equipe venha a alcançar no prazo. As etapas auxiliam também a facilmente definir a lista dos produtos que cada etapa deverá entregar (CHANDLER, 2012).

As etapas são categorizadas de maneira geral na seguinte ordem:

• Primeira versão jogável: é uma versão inicial do jogo, onde podem ser observados a jogabilidade e os elementos, sendo desenvolvida conforme os protótipos criados.

• Versão alfa: nessa versão do jogo pelo menos metade dos recursos gráficos e de jogabilidade já foram implementados.

• Congelamento do código: após a conclusão do código do jogo, a equipe de programação se concentra em rastrear e corrigir erros.

• Versão beta: e a versão do jogo 100% implementada, ou seja, os recursos e elementos do jogo foram todos concluídos, e as equipes agora buscam corrigir os erros relatados pela equipe de testes.

• Versão gold: depois de corrigido todos os erros o jogo é liberado para os testes finais (CHANDLER, 2012; NOVAK, 2017, CRUZ, 2013).

FIGURA 17 – PLANILHA DE PONTUAÇÃO DE RECURSOS

104


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.


105


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


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 dosfabricantes de consoles).- Dependência de fontes externas para componentes tecnológicos cruciais.- Desenvolvimentos tecnológicos competitivos.- Tecnologias experimentais ou decisões de design que podem afetar o cronograma.- Normas de proteção dos ativos (NOVAK, 2017, p. 372).

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


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


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 NotasIdiomas: 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


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


Playtest concluído Primeiro código candidato à liberação enviado para a QA

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

Storyboard do fornecedor Animática do fornecedor Corte bruto do fornecedor Filme final do fornecedor (sem som) Filme enviado para o designer de som Filme final pronto para o jogo Marketing Build de demonstração Build para E3 Preview code para jornalistas Review code para jornalistas


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

Para o cronograma, é comum que se utilize um software para a sua criação, acompanhamento e compartilhamento com a equipe. Atualmente, contamos com várias opções on-line e aplicativos para compartilhar nosso cronograma de atividade. O cronograma inicial oferece uma boa ideia do que irá ser desenvolvido, porém, é recomendável que um cronograma mais detalhado seja criado conforme as informações irem sendo confirmadas. Este cronograma detalhado contará com subtarefas para as tarefas básicas listadas no cronograma inicial, assim como um aperfeiçoamento da lista de tarefas (CHANDLER, 2012).


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


QUADRO 5 – EQUIPES DE DESENVOLVIMENTO

Equipe Profissional DescriçãoPr

ofiss

iona

is d

e A

rte

Diretor de arte

Supervisiona a equipe de arte, responsável por controlar os prazos, o desenvolvimento, orçamentos e as contratações para 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.

Profi

ssio

nais

de

Des

ign Diretor de

criaçãoGarante 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.

Profi

ssio

nais

de

Enge

nhar

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.


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

Profi

ssio

nais

de

Prod

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.

Profi

ssio

nais

de

QA

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


e visualmente, dentro do qual se mostra a concepção do jogo, os conceitos presentes, a arte envolvida, a programação sugerida e requerida, a história e seus marcos conceituais e de interação etc. Além de disso, o GDD “(...) irá acompanhar e orientar toda a produção do jogo, garantido sua identidade conceitual, visual, sonora etc.”. É importante ressaltar que não existe uma metodologia única de GDD, existem várias metodologias, cabendo a equipe escolher qual seguirá (FLEURY, et al. 2014). Segundo Schuytema (2008), o GDD deve possuir os seguintes itens:

1. Visão geral: qualquer pessoa se familiarize com o jogo. Deve conter o resumo da história, aspectos relativos ao gameplay e os diferenciais do jogo.

a. Resumo: é uma síntese da história de forma de que a equipe tenha uma ideia do que será desenvolvido, deve ser um enxuto e eficiente.

b. Aspectos fundamentais: descrição dos principais elementos de gameplay indicando sua trama central.

c. Golden nuggets: são elementos e funcionalidade que fazem com que o jogo se diferencie dos demais.

2. Contexto do jogo: descrição do jogo com relação à história que se deseja contar, sem considerar a jogabilidade. Assim deve-se descrever a trajetória do início ao fim do jogo, comentando o que acontece ao longo das fases, os conflitos, inimigos etc.

a. História do jogo: descrição em detalhes de todo a história do jogo.b. Eventos anteriores: apresentação de eventos anteriores a história do jogo (se

aplicável).c. Principais jogadores: descrição dos principais personagens controlados pelos

jogadores, contendo suas características físicas e psicológicas, além de sua biografia, habilidades e motivações.

3. Objetos essenciais do jogo: descrição de todos os objetos relevantes no jogo ou os quais desempenham papel importante.

a. Personagens: deve-se listar todos os participantes, os quais devem conter as todas as características físicas e características psicológicas com a personalidade.

b. Armas: (se aplicável) devem ser informada os detalhes, se é estático ou apresenta alguma animação, se apresenta efeitos, todos os detalhes devem ser descritos.

c. Estruturas: consiste nos objetos ou construções utilizadas no mundo do jogo.d. Objetos: devem ser descritos os objetos que desempenham um papel

importante no mundo do jogo.

4. Conflitos e Soluções: devem ser descritas todas as situações de conflito do personagem com seus inimigos, além de apresentar como o personagem irá interagir com os outros, ou seja, suas ações e reações no mundo do jogo.

5. Inteligência artificial: devem ser descritos os comportamentos das ações dos oponentes do jogo.

6. Fluxo do jogo: as fases, missões ou campanhas nas quais o jogador irá passar no decorrer do jogo devem ser descritas. Além de informar novas habilidades e armas que apareceram a cada fase avançada do jogo.


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ão utilizadas no jogo, um glossário pode ser criado para melhor entendimento.

10. Referências: apresenta jogos similares, filmes, músicas, quadrinhos, animações que serviram de referência para o jogo que está sendo desenvolvido (SENAC, 2019c).

Além dos itens apresentados, existem vários documentos que podem ser utilizados para se criar o GDD. Nos quadros a seguir iremos conhecer uma estrutura básica de um GDD. No quadro 6 temos a identificação do Documento, onde devem ser apresentados o título e subtítulo (se aplicável) do jogo. Em seguida, um sumário deve ser criado para melhor localização das seções do documento.

QUADRO 6 – ESTRUTURA BÁSICA DE UM GDD - IDENTIFICAÇÃO

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


Título do JogoSubtítulo do jogo

Sumário

1- Histórico do ProjetoEscreva uma breve descrição das versões e mudanças ocorridas durante o projeto desde o início.

116


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


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 JogoDescreva um resumo do principal conceito do jogo (Ex.: O jogo baseia-se em...).2.2 – Conjunto de característicasDescreva 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êneroDescreva um resumo do gênero do jogo (Ex. RPG, FPS, RTS, Aventura, Ação, Simulação etc).2.4 – Público-alvoDescreva qual o público que você quer atingir (Ex. Jovens entre 12 e 17 anos, Adultos dosexo feminino etc.).2.5 – Resumo do Fluxo do JogoDescreva 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 SentirDescreva 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 ProjetoDescreva 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.


117

QUADRO 9 – ESTRUTURA BÁSICA DE UM DE UM GDD – JOGABILIDADE E MECÂNICA


3 – Jogabilidade e Mecânica

3.1 – Jogabilidade3.1.1 – Progressão do Jogo3.1.2 – Estrutura das Missões / Desafios3.1.3 – Estruturas dos Quebra-cabeças3.1.4 – ObjetivosDescreva os objetivos do jogo3.1.5 – Fluxo do JogoDescreva como o jogo flui para o jogador.3.2 – MecânicasDescreva 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 jogoDescreva como a física afeta o universo e os objetos no jogo.3.2.2 – Movimentos3.2.2.1 – Movimentos Gerais3.2.2.2 – Movimentos específicos3.2.2.3 – Outros movimentos3.2.3 – Objetos3.2.3.1 – Pegando objetos3.2.3.2 – Movendo objetos3.2.3.3 – Descartando objetos3.2.3.4 – Modificando objetos3.2.4 – Ações3.2.4.1 – Interruptores, alavancas e botões3.2.4.2 – Pegando, Carregando e Soltando3.2.4.3 – Falando e Conversando3.2.4.4 – Lendo e Pensando3.2.5 – CombatesDescreva como são os combates ou eventuais conflitos. Modele especificamente o fluxodo início ao fim.3.2.6 – EconomiaDescreva qual a economia do jogo e como ela funciona.3.2.7 – Planilha de Fluxo de TelasDescreva graficamente como uma tela se relaciona com as demais.3.2.8 – Descrição de TelasDescreva a proposta de cada tela.3.2.8.1 - Tela de instalação3.2.8.2 - Tela Principal do jogo3.2.8.3 - Tela Opções3.2.8.4 - Etc3.4 – Opções do jogoQuais as opções e como elas afetam a jogabilidade e a mecânica?3.5 – Re-jogando e Salvando o jogo3.6 – Códigos de trapaça (Cheat-codes) e procedimentos escondidos (Easter-eggs)

118


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 NarrativaDescreva resumidamente o enredo do jogo. Detalhes específicos como Script e corte decenas, são descritos em uma Story Bible.4.1.1 – Prelúdio4.1.2 – Elementos do enredo4.1.3 – Progressão do Jogo4.1.4 – Corte de Cenas4.1.4.1- Corte de cena 1AtoresDescriçãoStoryboardScript4.1.4.2 – Corte de cena 2...4.2 – Universo do Jogo4.2.1 – Impressões gerais do universo do jogo4.2 2 – Área 1Descrição GeralCaracterísticas físicas (Ex.: visuais, sonoros etc.)Níveis utilizados na ÁreaConexões com outras Áreas4.2.3 – Área 2...4.3 – Personagens4.3.1 – Personagem 14.3.1.1 – Prelúdio4.3.1.2 – Personalidade4.3.1.3 – AparênciaCaracterísticas físicasAnimações4.3.1.4 – Habilidades especiais4.3.1.5 – Relevância no Enredo do Jogo


119


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


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 personagens4.3.1.7 – Estatísticas (Ex.: Frequência em que o personagem aparece)4.3.1 – Personagem 2...4.4 – ReferênciasColoque documentos, livros, filmes, vídeos, apêndices deste documento, outros jogos ouatas de reunião como referência da narrativa e enredo.

5 – Níveis

5.1 – Nível 15.1.1 – Resumo5.1.2 – Material introdutório (Ex.: Cortes de cena, Breafing de missão, vídeos ou textos)5.1.3 – Objetivos5.1.4 – Descrição física5.1.5 – Mapa5.1.6 – Caminho crítico (Ex.: Caminho em que o personagem pode encontrar um inimigo)5.1.7 – Encontros5.1.8 – Nível passo a passo5.1.9 – Finalização do material (Ex.: Cortes de cena, check de objetivos, vídeos outextos)5.2 – Nível 2...5.n – Nível de treinamento

120


QUADRO 12 – ESTRUTURA BÁSICA DE UM GDD - INTERFACE


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


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 Visual6.1.1 – HUD (Head-Up Display) – O que controlar?6.1.2 – Menus6.1.3 – Sistema de Renderização6.1.4 – Câmera6.1.5 – Modelos de Iluminação6.2 – Sistema de ControleDescreva como o jogador pode controlar o jogo. Existem comandos específicos? Existemcomandos ocultos para o jogador?6.3 – Sistema de ÁudioDescreva se o áudio é em Mono, Stereo, 2D ou 3D.6.3.1 – Músicas6.3.2 – Efeitos sonoros6.4 – Sistema de Ajuda

7 – Inteligência Artificial

7.1 – IA de OponentesDescreva 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-Combatentes7.4 – Personagens Amigáveis7.5 – IA de suporte7.5.1 – Colisões do jogador e objetos7.5.2 – Melhor caminho (Pathfinding)


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


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écnicoOs termos técnicos podem ser descritos em formato de glossário no Technical Bible.

8.1 – Equipamento-alvoDescreva 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 Desenvolvimento8.4 – Motor do Jogo (Engine)Descreva qual a engine utilizada para criar o jogo e sua versão.8.5 – RedeDescreva 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çãoO 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 conceitual9.2 – Guias de Estilo9.3 – Personagens

122


9.4 – Ambientes9.5 – Equipamentos9.6 – Cortes de Cena9.7 – Miscelânea


Todos os softwares utilizados no desenvolvimento do jogo devem ser descritos na seção 10 do documento (Quadro 16). Além disso, os softwares podem ser descritos nas atualizações e plugins utilizados no desenvolvimento.

QUADRO 16 – ESTRUTURA BÁSICA DE UM GDD – SOFTWARES SECUNDÁRIOS


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


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ários10.1 – Editores (Ex.: Modelagem 2D ou 3D, sons, músicas)10.2 – Instaladores10.3 – Atualização de programas10.4 – Miscelânea

11 – Gerenciamento11.1 – Detalhes do Cronograma11.2 – Orçamento11.3 – Considerações de Licença11.4 – Análise de Risco11.5 – Plano de Locação (Lugar a ser vendido)11.6 – Plano de Teste


123


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


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 – EquipeColoque 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 ArteLista de Modelos e TexturasLista de animaçõesLista de efeitosLista de interface artísticaLista de cortes de cena13.2 – Ativos de SomSons de ambienteSons de armasSons de interface13.3 – Ativos de MúsicaAmbiente“Ação”VitóriaDerrota13.4 – Ativos de VozesAtor 1 – Linha de vozAtor 2 – Linha de vozAtor 3 – Linha de voz

124


QUADRO 20 – ESTRUTURA BÁSICA DE UM GDD – ASSINATURAS RESPONSÁVEIS


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 ProjetoGerente 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.

IMPORTANTE


125


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 NOTASCONCEITO O conceito inicial do jogo foi definido? A plataforma e o gênero foram especificados? A declaração da missão foi concluída? Os elementos básicos de jogabilidade foram definidos? O protótipo foi concluído? A análise de risco foi concluída? A exposição do conceito está pronta para aprovação? Todos os stakeholders aprovaram o conceito? O lançamento do projeto foi agendado? REQUISITOS DO JOGO Os recursos que “devem entrar”, que “queríamos que entrassem” e que “seria bom ter” foram definidos?

As restrições foram definidas e solucionadas nos conjuntos de recursos?

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

As ferramentas e o pipeline foram definidos? A documentação básica do design foi concluída? A documentação técnica básica foi concluída? A análise de risco foi concluída? Todos os stakeholders aprovaram os requisitos do jogo? PLANEJAMENTO DO JOGO O orçamento foi concluído? O cronograma inicial foi concluído? O plano inicial de pessoal foi concluído? Os membros da equipe primária aprovaram o cronograma e o plano de pessoal?

Todos os stakeholders aprovaram o planejamento do jogo?

126


A produção é o momento em que o jogo em si é construído, no qual os modeladores/artistas, realizarão a modelagem tridimensional dos cenários e personagens, texturização dos mesmos, em seguida farão a implementação dos mesmos em um motor de jogo, ou seja, construirão o design de nível, os game designers fazem o que Schuytema chama de roteiro de gameplay, ou seja, definem a mecânica do jogo. Em seguida a equipe de programadores define, revisa e implementa o código de programação (MARQUES, 2015, p. 27).

É comum que a fase de produção seja iniciada antes que seja finalizada a fase de pré-produção, no decorrer da fase de produção ocorre o processo iterativo de implementação do que foi planejado na fase de pré-produção. A produção, segundo Chandler (2012), é dividida em nas fases de implementação do plano, rastreamento do progresso e conclusão de tarefas.

3.1 IMPLEMENTAÇÃO DO PLANO

A implementação do plano se inicia quando o produtor comunicar à equipe o plano final, além de fornecer todas as ferramentas e recursos necessários para a implementação do jogo. Algumas boas práticas podem ser seguidas, como:

• Tornar o plano público, Disponível em:site ou área que a equipe tenha acesso;• Incluir todos os documentos criados na fase de pré-produção;• Afixar cópias impressas dos prazos-chave em um local em que toda a equipe

circule/frequente;• Deve-se evitar o crescimento desenfreado, quando novas funcionalidades são

continuadamente inclusas no projeto, por exemplo. Ao se evitar o crescimento desenfreado não teremos o risco de ficarmos sem tempo para executar o projeto ou recursos (CHANDLER, 2012).

Na implementação do plano são realizados três ciclos de produção: design, artística e programação. A Figura 19 demonstra essa iteração entre os ciclos de produção.


FONTE: A autora


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


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


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 foi realizado, o que pode ser melhorado e se alguma tarefa está pendente, para assim iniciar a próxima fase.

130


QUADRO 22 – LISTA DE VERIFICAÇÃO DA PRODUÇÃO

LISTA DE VERIFICAÇÃO DA PRODUÇÃO S / N NOTASIMPLEMENTAÇÃ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?


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 FUTUROS

131

RESUMO DO TÓPICO 2


• O ciclo de desenvolvimento de jogos é composto por quatro fases: Pré-produção, Produção, Testes e Pós-Produção.

• Na fase de Pré-produção é definido o conceito do jogo, seus requisitos, criado seu planejamento e o GDD (Documento de Design do Jogo).

• O conceito do jogo deve ser um esboço do que será desenvolvido. O início do processo começa quando se responde às perguntas: O que será feito? E para quem será feito?

• Uma boa técnica para gerar ideias é a Brainstorm, onde todas as ideias são aceitas e depois de discutidas são validadas ou descartadas, resultando na identificação a melhor ideia.

• Ao se levantar os requisitos do jogo, devem ser inclusos os recursos de arte, design e da engenharia, sendo que devem estar de acordo com o que foi definido no conceito e na declaração da missão do jogo.

• As etapas e produtos as serem desenvolvidos são: (1) primeira versão jogável, (2) versão alfa, (3) congelamento do código, (4) versão beta e (5) versão gold.

• O GDD é a documentação do jogo, considerada a espinha dorsal do projeto, pois apresenta todas as características do jogo.

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 especificas.

d) ( ) O GDD (Game Design Document) será utilizado somente para mostrar aos clientes como o jogo será desenvolvido.

2 Na fase de produção, o jogo começa a ganhar vida, e sua implementação é iniciada. O desenvolvimento do jogo é realizado pela iteração entre os ciclos de produção. Sobre esses ciclos de produção, assinale a alternativa CORRETA:

a) ( ) Produção de Design. Produção Artística. Produção de Programação.b) ( ) Produção de Design. Produção Arte. Produção de Implementação.c) ( ) Produção de Projeto. Produção Artística. Produção de Codificação.d) ( ) Produção de Projeto. Produção Arte. Produção de Implementação.

3 A análise SWOT é conhecida em outras áreas do desenvolvimento, como na Administração e Marketing. A estrutura da SWOT busca identificar os fatores positivos, negativos e os fatos internos e externos que podem impactar o produto. Sobre a utilização do SWOT e qual sua função no desenvolvimento de jogos, assinale a alternativa CORRETA:

a) ( ) Auxiliar no processo de levantamento de ações dos personagens.b) ( ) Auxiliar na identificação dos profissionais que irão atuar no jogo.c) ( ) Auxiliar na definição da ideia do jogo.d) ( ) Auxiliar no processo de definição do conceito do jogo e sua concepção.

4 Ao se desenvolver um projeto, tudo deve ser planejado e controlado. Os riscos podem implicar que o projeto seja afetado, e que resulte em atrasos, falhas e retrabalho. Disserte sobre os riscos mais comuns ao longo do desenvolvimento de projetos.

5 No desenvolvimento de jogos é comum que vários profissionais atuem juntos, logo, equipes de desenvolvimento são consideradas multidisciplinar, uma vez que uma equipe apoia e interage com a outra. Neste contexto, disserte sobre os líderes de cada uma das equipes.

AUTOATIVIDADE

133

UNIDADE 2

1 INTRODUÇÃO

Olá, caro(a) acadêmico(a)! Bem-vindo(a) ao Tópico 3. Ao longo deste tópico, iremos abordar as fases finais do desenvolvimento de Produção de jogos. A Figura 21 demonstra a trajetória que vivenciamos até o momento e nos apresenta as duas fases finais.


FONTE: A autora

Na fase de testes, iremos conhecer o que deve acontecer após termos uma versão compilada do jogo. Já na última fase, de pós-produção, iremos abordar sobre o plano de arquivamento, como o que desenvolvemos pode ser resultar em lições que podemos utilizar e aprimorar em futuros projetos.

2 TESTES Por meio dos testes é que são identificados erros e falhas no jogo.

Chandler (2012) destaca que é uma das fases mais críticas no desenvolvimento. É através dos testes que “(...) o jogo é verificado para vermos se tudo funciona corretamente e se não há nenhum bug fatal. Os testes são contínuos durante o processo de produção”, sendo que a equipe de QA “verificará as builds, as novas funcionalidades e os novos recursos da etapa à medida que ficarem disponíveis no jogo” (CHANDLER, 2012, p. 12). Novak (2017, p. 325) diz que os testes de um jogo “consistem em jogá-lo antes do lançamento para determinar se é ou não jogável: ou seja, isento de erros, consistente e divertido”.

TÓPICO 3 —

TESTES E FASE DE PÓS-PRODUÇÃO

134


Durante os testes, todo o jogo é analisado em busca de falhas técnica e conceituais. Os profissionais que realizam os testes, os testadores de QA, atuam como jogadores, e eles devem explorar todos os elementos que compõem o jogo. Caso algum erro (bug) ou problema seja encontrado, deverá ser informado à equipe de engenharia para realizar os correções e ajustes necessários (PONTES, 2009).

Os testes são realizados desde a versão jogável do jogo. Aa versão beta é quando todos os assets e recursos já foram implementados, assim, a equipe de desenvolvimento fica responsável pela correção dos erros e pela criação de novas compiladas e executadas (builds) do jogo, onde a equipe de QA irá realizar uma nova rodada de testes. Após o jogo passar por todos os testes, é criada a versão gold, que é a versão utilizada para a publicação (CHANDLER, 2012).

Qual o perfil de um testador, por assim dizer? Rogers (2010) afirma que:

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

Rogers (2010) também reitera que muitos profissionais que atuam no desenvolvimento de jogos iniciam como testadores e vem se capacitando. Assim, com o decorrer do tempo, atuam em outras equipes. Em muitos casos, atuar como testador em um jogo pode ser uma grande chance de entrar na área de desenvolvimento.

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

Não é realizado apenas um tipo de teste. Na verdade, são vários e cada um com um objetivo próprio. No Quadro 23, são apresentados os diferentes tipos de testes que devem ser executados.

TÓPICO 3 — TESTES E FASE DE PÓS-PRODUÇÃO

135


É 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


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).


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 inserido a informação do erro no banco de dados, o mesmo deve ser verificado e em seguida fechado pela equipe de desenvolvimento, assim podemos acompanhar o que foi corrigido além destes dados poderem ser analisados e explorados para melhores práticas de desenvolvimento e teste de jogos.

É essencial que seja definido como os erros devem ser relatados e rastreados, por meio de um pipeline de correção de erros. O líder de controle de qualidade deve garantir que todos os erros encontrados sejam priorizados e atribuídos a uma pessoa apropriada para realizar as correções. Normalmente, o processo de pipeline ocorre na seguinte sequência: Encontrado, Designado, Corrigido, Verificado e Concluído (CHANDLER, 2020). No Quadro 24, são apresentadas as definições de cada uma dessas fases do processo de pipeline.

QUADRO 24 – PROCESSO DE PIPELINE


Processo Descrição

EncontradoAlguém na equipe de desenvolvimento ou na equipe de controle de qualidade encontra um bug e entra no banco de dados de erros.

DesignadoO 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 pretendido e 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


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


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


(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.

INTERESSANTE


141

QUADRO 23 – LISTA DE VERIFICAÇÃO DOS TESTES


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 NOTASVALIDAÇÃO DO PLANO O plano de testes foi criado? O plano de testes foi atualizado para o departamento de QA? O plano de testes foi atualizado com qualquer alteração que tenha sido feita no planejamento do jogo?

As etapas de testes foram consideradas no cronograma? O software de rastreamento de bugs foi disponibilizado para os testadores e a equipe de desenvolvimento?

Todas as áreas do jogo foram testadas? Todos os bugs foram regredidos e fechados? LIBERAÇÃO DO CÓDIGO A equipe de desenvolvimento enviou um candidato final à liberação do código?

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

O departamento de QA aprovou o produto para liberação do código?

Somente no caso de console: O jogo que teve o código liberado foi enviado para o fabricante do console para aprovação?

Somente no caso de console: O fabricante do console aprovou o jogo para replicação final?

142


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.


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


LISTA DE VERIFICAÇÃO DA FINALIZAÇÃO S / N NOTASPLANO 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



DESIGN THINKING COMO METODOLOGIA ALTERNATIVA PARA ODESENVOLVIMENTO DE JOGOS SÉRIOS

Luiz Carlos MurakamiAntonio José Melo Leite Júnior

Rodolfo Felipe Sganzerla SabinoDiego 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. (...)


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 baseado em soluções, “pensando-se”. Em vez de se iniciar com um problema, inicia-se com uma solução-base e em seguida definem-se parâmetros para se atingir o objetivo final. Na realidade, em suma, é uma contraposição entre análise e síntese que é colocada neste tipo de abordagem de um problema.

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

Imersão: A imersão tem como objetivo o entendimento inicial do problema, com a respectiva identificação de necessidades e oportunidades que nortearão a geração de soluções. Para tanto, são procedidos, na verdade, dois tipos de imersão:

• Imersão preliminar, com realização de reuniões de alinhamento da equipe de desenvolvimento com os possíveis clientes. Voltadas ao aprofundamento do contexto do problema, tais reuniões consistem na pesquisa e na discussão de assuntos análogos ao problema abordado, visando soluções próximas iniciais e estabelecendo também os possíveis perfis dos usuários pretendidos;

• Imersão em profundidade, com realização de entrevistas (ou qualquer outra técnica de consulta, como sessões generativas, cadernos de sensibilização etc.) com usuários dos perfis identificados, a fim de se compreender melhor seus respectivos anseios, necessidades e valores.

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

146


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.


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


membro da equipe, como o real cliente. Tal decisão mostrou-se muito importante, pois foi possível, desde o começo, focar os esforços nas reais necessidades do jogo a ser desenvolvido: aplicar o game em aulas tanto presenciais quanto a distância.

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

Nesta fase, os documentos gerados (GDD e quadro de tarefas virtual) ainda se mostravam bastante desestruturados, pois ainda não havia uma real definição do jogo a ser desenvolvido. Porém, já se expunham as principais necessidades e possibilidades do jogo pretendido, o que serviria de base à realização da próxima fase da metodologia.

Ideação: De posse do GDD inicial, o aluno consultado na fase de imersão que cursava administração, acabou sendo oficializado como membro da equipe. Paralelamente, o professor do curso de administração, membro da equipe, começou a discutir possibilidades de jogos com colegas da instituição de ensino. Passou-se, então, a buscar a especificação do jogo a ser desenvolvido. Para tanto, considerou-se inicialmente a ideia de gameplay, provavelmente o conceito mais importante para a elaboração de um jogo.

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

A partir do conceito de gameplay e do instrumento gameplaybricks, toda a equipe debateu a especificação do jogo na forma de pequenos workshops de cocriação, culminando no aprimoramento do GDD, tornando-o mais estruturado. Nos workshops de cocriação abertos, que também envolveram alguns alunos convidados do curso de administração da instituição, foram enumeradas possibilidades de gameplays que poderiam envolver a correta abordagem dos conceitos necessários. Ao final, optou-se finalmente pela criação do jogo Danki (...)


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


• 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


• A fase de testes é considerada uma das mais críticas. É nela em que são identificados os erros e falhas contidas no jogo, para que sejam corrigidas.

• Os testes buscam encontrar falhas técnicas e conceituais. Assim, os testadores de QA atuam como jogadores. O plano de testes é criado com base nas funcionalidades e assets, conforme foi especificado no planejamento do jogo.

• A liberação do código só ocorre quando todos os erros foram corrigidos pela equipe de engenharia, testados e validados pela equipe de QA. Finalizado os testes, ocorre a liberação do código para o fabricante ou cliente.

• O TDD é um método que se baseia em criar o teste antes da implementação do código, tendo como objetivo reduzir custos e o retrabalho.

• A pós-produção nem sempre é realizada pelas equipes, porém, ela deve ser executada para que seja identificado o que foi aprendido durante a produção e para criar o plano de arquivamento.

• O post-mordem reúne as informações sobre o desenvolvimento do jogo pela perspectiva da equipe, a qual examina os pontos positivos e negativos na execução do projeto.

• O kit de fechamento deve incluir todas as informações que foram utilizadas no projeto, além da documentação, o código-fonte, as artes, os assets, as músicas e efeitos sonoros, ou seja, tudo que foi utilizado para se criar o jogo.


CHAMADA

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://ga-mesed.baldwinconsulting.org/files/Baldwin_Game_Design_Document_Templa-te.doc. Acesso em: 21 jul. 2021.

BARATA, B. A. P. et al. Um jogo sério aplicado à saúde com foco em epide-miologia: Apoena. 2020. Disponível em: https://www.researchgate.net/publica-tion/340799872_Um_jogo_serio_aplicado_a_saude_com_foco_em_epidemiolo-gia_Apoena. Acesso em: 21 jul. 2021.

BARCELOS, T. S. Proposta de game design de um jogo digital para o ensino de Engenharia de Software. 2013. Disponível em: https://www.researchgate.net/publication/259377773_Proposta_de_game_design_de_um_jogo_digital_pa-ra_o_ensino_de_Engenharia_de_Software. Acesso em: 21 jul. 2021.

BRUN, J. A. Uma Ferramenta Para Automação do Processo de Software Pes-soal. 2002. Disponível em: https://repositorio.ufsc.br/xmlui/bitstream/hand-le/123456789/82614/189734.pdf. Acesso em: 21 jul. 2021.

CAMARGO, R. Entenda o que é PMBOK: o guia que vai dar um up na sua car-reira. 2019. Disponível em: https://robsoncamargo.com.br/blog/PMBOK. Acesso em: 21 jul. 2021.

CAMPOS, E. L. de. Interseções dos Papéis no Scrum. 2021. Disponível em: https://blog.myscrumhalf.com/intersecoes-dos-papeis-no-scrum/. Acesso em: 21 jul. 2021.

CAVACO, M. Programação de jogos: Dicas e sugestões para criar jogos. 2007. Disponível em: https://pdfcoffee.com/desenvolvimento-de-jogos-pdf-free.html. Acesso em: 29 jun. 2021.

CHANDLER, H. M. Manual de Produção de Jogos Digitais. 2ª ed. Porto Ale-gre, Bookman, 2012.

CHANDLER, H. M. The Game Production Toolbox. CRC PressTaylor & Francis Group: EUA, 2020.

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%20Aplicadas%20ao%20Desenvolvimento.pdf. Acesso em: 21 jul. 2021.

LOURENÇON, G. et al. Scrum: O desenvolvimento ágil no desenvolvimento de jogos. [s.d]. Disponível em: https://edisciplinas.usp.br/pluginfile.php/5751058/mod_resource/content/1/Aula%2011%20-%20Scrum.pdf. Acesso em: 21 jul. 2021.

MARQUES, G. C. Introdução ao desenvolvimento de jogos digitais utilizando o motor de jogo UDK. 2015.Disponível em: https://sapientia.pucsp.br/bitstream/handle/18168/1/Gabriel%20Cavalcanti%20Marques.pdf. Acesso em: 21 jul. 2021.

MENEZES, J. T. Quais são as etapas de criação de um jogo?. 2015. Disponível em: https://www.desenvolvendojogos.com/single-post/2015/06/05/quais-s%-C3%A3o-as-etapas-de-cria%C3%A7%C3%A3o-de-um-jogo. Acesso em: 21 jul. 2021. NEMITIZ NETO, W. L. F. Cristina: Uma ferramenta para transformar protóti-pos de jogos em código reutilizável. 2015. Disponível em: http://dspace.unipam-pa.edu.br:8080/jspui/handle/riu/886. Acesso em: 30 jun. 2021.


OLIVEIRA, F. N. de. Metodologias para Desenvolvimento de Jogos. 2018. Disponível em: https://www.fabricadejogos.net/posts/metodologias-para-desen-volvimento-de-jogos/. Acesso em: 11 jul. 2021.

PEREIRA, L. T.; LOPES, R. M. Produção de Jogos Digitais Da equipe aos pro-dutos: como é feito um jogo? [s.d.]. Disponível em: https://edisciplinas.usp.br/mod/resource/view.php?id=2703146. Acesso em: 21 jul. 2021.

PIRES, R. Aprenda a usar a técnica MoSCoW nos projetos da sua agência!. 2019. Disponível em: https://rockcontent.com/br/blog/metodo-moscow>. Acesso em: 21 jul. 2021.

PONTES, M. B. Engenharia de Software - Introdução a Teste de Software. 2009. Disponível em: http://www.devmedia.com.br/artigo-engenharia-de-software-in-troducao-a-teste-de-software/8035. Acesso em: 21 jul. 2021.

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


PLANO DE ESTUDOS


• 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.


TÓPICO 1 – KITS DE FECHAMENTO

TÓPICO 2 – DESENVOLVIMENTO DE JOGOS NO ANDROID

TÓPICO 3 – DESENVOLVIMENTO DE JOGOS PARA IOS


CHAMADA

161

UNIDADE 3

1 INTRODUÇÃO

Caro acadêmico! Bem-vindo à Unidade 3! Na última unidade desse livro, iremos conhecer sobre os Kits de Fechamento e o desenvolvimento de jogos para sistema Android e para sistema IoS.

No Tópico 1, abordaremos sobre Kits de Fechamento, onde conheceremos o que deverá ser incluído do kit. Vale ressaltar que no Kit de Fechamento deve conter tudo o que foi desenvolvido nas quatro fases do projeto. Em seguida, iremos explorar o desenvolvimento de jogos para sistemas Android. Iniciaremos com a instalação do software Unity e conheceremos como um jogo é desenvolvido utilizando este ambiente de desenvolvimento. Por último, conheceremos sobre o desenvolvimento de jogos para sistemas IoS, onde iremos explorar como é o desenvolvimento para este tipo de sistema operacional de dispositivo móvel.

Vamos começar a nossa última jornada, padawan! Bons estudos!

2 DEFINIÇÃO DOS KITS DE FECHAMENTO

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

O kit de fechamento é uma tarefa essencial para que o jogo seja arquivado

e futuramente consultado. Chandler (2009, p. 391) afirma que:

Após a pós-produção, uma tarefa importante é organizar todos ativos dos jogos e código-fonte em um kit de fechamento e arquive-o para referências futuras. Os arquivos são necessários se houver necessidade de remasterizar o jogo, crie uma versão ou atualização de conteúdo, transformar o jogo para outra plataforma, lançar o jogo em outro idioma, desenvolva uma sequência ou qualquer outro tipo de conteúdo isso exigirá os ativos, código e ferramentas originais do jogo. Os editores podem enviar kits de fechamento para distribuidores que desenvolverão versões localizadas do jogo para distribuição em outros países.

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.


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


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 criadosArquivo de ajuda e manualMensagens (palavras-chaves) de instalaçãoMensagens de erros

Ativos de Narração

Arquivos de áudio não compactados em todos os idiomas criadosNarração e roteiros cinematográficosElenco de notasEspecificações técnicas de narraçãoPlanilha mestre de narração

Ativos de ArteAtivos de arte finalArquivos de origem para todos os ativos de arte, incluindo os logotipos

Ativos Cinematográficos

Cinematográficas finais no jogoCodecs de vídeo e players de filmesCinematografia não compactada Arquivos de origem cinematográficaFaixas de áudio separadas e não compactadas para efeitos de música, narração e som

Ativos de Localização

(se aplicável)

Texto traduzidoArquivos 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


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).


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


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


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).


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 índice com o caminho de cada parte do kit (CHANDLER, 2013).

FIGURA 2 – ESTRUTURA DE PASTAS DO KIT DE FECHAMENTO

FONTE: Adaptado de CHANDLER (2013).

O exemplo de organização do kit por pastas, é útil para quando é necessário acessar as informações do desenvolvimento. Para Cohen e Bustamante II (2010), o kit de fechamento deve conter os seguintes itens:

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

Após concluído o kit de fechamento, Chandler (2013) recomenda que seja convidado um desenvolvedor externo à equipe para que venha reconstruir o jogo e criar uma versão de ouro dele.


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).


171

DOCUMENTAÇÃO S/N ANOTAÇÕESConteúdo do kit de fechamento (na raiz do primeiro CD no kit de fechamento)Documentação de projeto, incluindo: DesignDocumentosTrapaças e orientaçõesFluxograma da interface do usuárioPlano de testeDocumentação técnica, incluindo:Instruções sobre como fazer compilações (incluindo versões localizadas)Visão geral do oleoduto de produçãoRequisitos de software (incluindo números de versão)Requisitos de hardwareInstruções para ferramentas proprietáriasInformações gerais sobre o produto, incluindo:Informações do jogo (plataforma, idiomas)Informações de contatoLista de bugs conhecidos

ATIVOS DO JOGO S/N ANOTAÇÕESTextoAtivos de origem para todos os arquivos de texto do jogoLista de verificação para todos os arquivos de texto do jogoLocuçãoArquivos VO não compactados para todo o áudio do jogoMestre de narraçãoElenco de notasEspecificações técnicas para narraçãoArquivos VO finais no jogo para todo o áudioLista de verificação para todos os arquivos VO do jogoArteTodos os ativos de origem para arte no jogoArquivos de origem para logo das artesLista de verificação para todos os ativos de arte do jogoCinemáticaArquivos de origem cinematográfica não compactados - Não compactadoscinematografiaCinema final compactado no jogoCodecs e cineastas usados para cinemas

QUADRO 3 – LISTA DE VERIFICAÇÃO DO KIT DE FECHAMENTO


172

Trilha de áudio (música não compactada, efeitos sonoros e narração ativada)Faixas separadasMix de áudio finalLista de verificação para cinemasLocalizaçãoGlossáriosEmbalagemArquivos de origem para o layout da embalagem Arquivos de origem para layout manualCapturas 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ÇÕESMestre de ouro duplicaCódigo fonte do jogoFerramentas código fonteArquivos do instalador


Criar o kit de fechamento irá levar um tempo, é uma atividade que irá demandar tempo, paciência e organização, uma vez que será necessário coletar todos os ativos, organizá-los e escrever sua documentação. É claro que o kit pode ser criado coletivamente por toda a equipe, porém, é importante que seja revisado pelo produtor ou líder do fechamento.

FERRAMENTAS S/N ANOTAÇÕESPlug-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ÇÕESO 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


• 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 da produção do jogo. Ele pode ser construído ao longo do desenvolvimento do jogo, ou seja, desde a fase de pré-produção. Sobre a utilização após o kit de fechamento ser concluído, assinale a alternativa CORRETA:

a) ( ) Pode-se ser utilizado o Kit para atualizar, modificar, lançar em outro idioma o jogo.

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

2 Os assets correspondem a tudo o que foi desenvolvido para que o jogo ganhe vida. Eles podem ser utilizados para editar as informações para outro idioma, por exemplo. Sobre os assets, assinale a alterativa CORRETA que representa todos os tipos que podemos ter ao se criar um jogo.

a) ( ) Apenas as versões das Imagens, Textos, Gráficos, Áudios utilizadas no jogo.

b) ( ) Arquivos em baixa qualidade dos Imagens, Textos, Gráficos, Áudios.c) ( ) Arquivos originais e adaptados das Imagens, Textos, Gráficos, Áudios.d) ( ) Não há necessidade de incluir os arquivos de Imagens, Textos, Gráficos,

Áudios.

3 A documentação do jogo deve reunir todas as informações sobre ele e como foi seu desenvolvimento. Ela poderá guiar outros projetos, assim como auxiliar na melhoria do jogo em futuras versões. Sobre os itens obrigatórios da documentação do jogo, assinale a alternativa CORRETA:

a) ( ) Visão geral do pipeline, Passo a passo do jogo, Gráfico do fluxo e a descrição da interface do usuário, documentação de design principais.

b) ( ) Planos de teste, Passo a passo do jogo, Lista de requisitos, instruções da ferramentas, Gráfico do fluxo e a descrição da interface do usuário.

c) ( ) Visão geral do pipeline, Informações gerais sobre o produto, Gráfico do fluxo e a descrição da interface do usuário, documentação de design principais.

d) ( ) Planos de teste, Passo a passo do jogo, Gráfico do fluxo e a descrição da interface do usuário, documentação de design principais.

4 A organização do kit é uma atividade extensa, uma vez que deve ser incluso tudo o que foi desenvolvido na concepção do jogo. Disserte como podemos realizar a organização dos kits de fechamento.

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.

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.

INTERESSANTE

https://mymob.com.br/blog/historia-do-android.html

178


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


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.


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


A figura 8 demonstra a tela sobressalente. Nela, iremos escolher a versão do Unity que queremos instalar. Normalmente, são apresentas três opções da versão estável (LTS) e outras versões futuras do Unity que estão disponíveis para o usuário testar. Essas versões podem conter erros e falhas, por isso, opte por uma versão do Unity estável. Após escolher a versão do Unity, deve-se clicar no botão ‘Next’ para avançar a instalação.

FIGURA 8 – INSTALANDO DO UNITY – ESCOLHENDO VERSÃO DO UNITY

FONTE: <https://bit.ly/3pLa8jK>. Acesso em: 27 ago. 2021.

Na sequência, você deverá escolher os suportes de criação dos seus jogos. As opções apresentadas pela Figura 9 devem ser marcadas quando você realizar sua instalação. Esses recursos serão úteis no momento de compilação do jogo, por isso, deixe todas as opções do ‘Android Bluid Support’ (SPROVIERI, 2021). Após marcar estas opções, clique no botão ‘Next’ para iniciar o download do Unity. Por último, depois de instalado, você deverá abrí-lo. Uma mensagem sobre a licença será exibida e você deverá acessar sua conta ou criar uma conta no Unity, sendo que a versão Unity Personal é gratuita. Após escolher a versão, um arquivo será gerado, o qual você deverá utilizar para ativar o Unity.


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


Neste vídeo você pode conhecer um exemplo de jogo em 2.5D. Para acessar, utilize este link: https://bit.ly/3mofYFr.

INTERESSANTE

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.


185

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

O Unity tem como funcionalidades:

• O motor gráfico para renderização de gráficos 2D e 3D.• O motor de física, que visa simular as interações entre os objetos.• Sistema de iluminação.• Criar animações.• Sons.• Programação de Inteligência Artificial (IA).• Programação por scripting (codificação).• Simulações.• Entre outras funcionalidades (MASTER.D, 2021).

Como podemos observar pelas funcionalidades listadas, o Unity é poderoso! Com o Unity podemos criar jogos para mais de 27 plataformas. Na figura 11 apresentamos as plataformas para a qual podemos desenvolver.

FIGURA 11 – PLATAFORMAS SUPORTADAS

FONTE: A autora.

Mas por que usar ele? Bom vamos, lá... Como podemos ver até agora o Unity é bem versátil, e com múltiplas possibilidades para o desenvolvimento multiplataforma. A figura 12 apresenta as principais características do Unity, e porque ele é uma boa escolha de software.

186


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).


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


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/SceneViewNavigation.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


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


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.


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.

INTERESSANTE

192


personagens, adereços e cenários. Eles não realizam muito em si mesmos, mas atuam como recipientes para Componentes , que implementam a funcionalidade. Para dar a um GameObject as propriedades necessárias para se tornar uma luz, uma árvore ou uma câmera, você precisa adicionar componentes a ele. Dependendo do tipo de objeto que deseja criar, você adiciona diferentes combinações de componentes a um GameObject (UNITY DOCS, 2021b).

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

Outros elementos podem ser incluídos, os quais são conhecidos como Prefabs, ou Pré-fabricados. Eles podem ser importados de outros projetos, por exemplo, porém, seus principais exemplos de utilização, segundo Unity Docs (2021d), são:

• Ativos ambientais - por exemplo, um certo tipo de árvore usada várias vezes em um nível (como visto na captura de tela acima).

• Personagens não-jogadores (NPCs) - por exemplo, um certo tipo de robô pode aparecer em seu jogo várias vezes, em vários níveis. Eles podem diferir (usando substituições) na velocidade em que se movem ou no som que fazem.

• Projéteis - por exemplo, o canhão de um pirata pode instanciar uma bola de canhão Prefab cada vez que é disparada.

• O personagem principal do jogador - o prefab do jogador pode ser colocado no ponto de partida em cada nível (cenas separadas) do seu jogo (UNITY DOCS, 2021d, s. p.).

A utilização de camadas ou layers é utilizada para identificar ou agrupar quais objetos irão interagir entre si. Takoordyal (2020, p. 98) destaca que que podemos definir uma

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

Podemos criar várias camadas ao longo do desenvolvimento, que são definidas como Camada de usuário, porém, o Unity possui Camadas Internas, as quais podemos somente editar e utilizar.


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 torna novamente plano para que os jogadores que chegaram até esse ponto consigam terminá-lo (NOVAK, 2017, p. 217).

194


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


195

que compõem a cena, sendo necessária a atualização de dois componentes físicos. Os colisores precisam estar atualizados para que se tenha a forma correta e as juntas devem estar ajustadas para que girem no ponto certo do corpo do personagem (MANNING; BUTTFIELD-ADDISON, 2017).

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


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


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


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 é


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: 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


(...) 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


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


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.


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.

IMPORTANTE

204

RESUMO DO TÓPICO 2


• O desenvolvimento de jogos para Android é uma opção relevante, uma vez que é um dos sistemas mais utilizados em smartphones, tablets e Smart Tvs.

• A utilização do Unity permite a criação de jogos multiplataformas, sem que tenhamos que criar um jogo diferente para cada uma, o que elimina o retrabalho no desenvolvimento de jogo.

• Com o Unity podemos criar jogos em 2D, 3D, em Realidade Aumentada e Realidade virtual, além de podermos criar um projeto e depois alterar o tipo de jogo.

• Cada objeto criado no Unity é um GameObject. Eles irão representar o que for importado para o projeto, como os personagens, objetos de cena e cenário.

• Cada nível criado deve possuir uma meta a ser alcançada. Com isso, o jogador continuará motivado e engajado com o jogo. O nível de dificuldade pode ser aumentado gradativamente.

• As forças de física são aplicadas em um objeto quando utilizado o RigidBody, já os Colliders definem a forma para as colisões físicas.

• Os fatores do design de interface devem garantir que os controles e menus criados sejam intuitivos, limpos e de boa aparência.

• Podemos utilizar os efeitos sonoros para atrair a atenção do jogador, assim como incluir um fundo musical ao jogo.

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.


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 sobre o Desenvolvimento de jogos para sistemas IoS. Continuaremos a abordar o desenvolvimento para IoS sobre a perspectiva do ambiente de desenvolvimento Unity, uma vez que podemos utilizá-lo para desenvolver jogos multiplataforma.

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

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

Porque desenvolver jogos para IoS? A Apple possui mais de 1 bilhão de usuários ativos. Até o primeiro semestre de 2021, mais de 41,5 bilhões de dólares em transações foram realizadas na App Store, sendo que 40% dos downloads da App Store são de jogos, assim com 70% da renda vem deste meio (MARINHO, 2020; PANKIEWICZ, 2021; MENGE, 2013). Seja para Android, IoS, Console ou outras plataformas, a ideia principal é colocar o que você conheceu e apreendeu até aqui em prática. Ao desenvolver, você irá criar experiência, superar dificuldades e se aperfeiçoar.

Vamos explorar nosso último tópico. Bons estudos!

TÓPICO 3 —

DESENVOLVIMENTO DE JOGOS PARA IOS

208


2 BASE DO JOGO A base do jogo pode ser criada utilizando um projeto já desenvolvido ou

criando um do zero, porém, é fundamental que ao finalizar a criação ou criarmos versões compiladas, selecionemos a opção iOS. Assim, podemos criar nossos jogos e apenas no final do percurso de desenvolvimento escolher a plataforma iOS. É claro que esse é um dos pontos fortes do Unity, se escolher outro ambiente essa regra pode ser diferente. A figura 26 demonstra como podemos criar um novo projeto no Unity ao acessarmos a opção ‘File’ e em seguida ‘New Project...’, mas caso já tenhamos iniciado um projeto ou estarmos utilizando um que tenha baixado, podemos selecionar a opção ‘Open Project...’.

FIGURA 26 – CRIANDO NOVO PROJETO NO UNITY

FONTE: Wells (2020)

Como estamos começando no mundo do desenvolvimento dos jogos, uma alternativa é utilizar o Unity Hub. Lembra-se dele do Tópico 2? Se inicialmente ele nos auxiliou na instalação do Unity, podemos utilizá-lo para criar e gerenciar nossos projetos. Na primeira imagem da figura 27, podemos observar como podemos criar um projeto. Ao clicar em ‘New’, começamos a criação de um novo projeto no Unity. Em sequência, conforme apresentado na segunda imagem da figura 27, iremos definir o nome do projeto, escolher o local que será salvo o projeto no computador e escolher um dos modelos (templates) que iremos criar o jogo.

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


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>.

INTERESSANTE


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


criar um jogo com apenas uma cena ou um jogo com n cenas, em que cada um possui seus próprios ambientes, decoração e obstáculos. Quando um novo projeto é criado pela primeira vez, o Unity abre uma cena de exemplo, o qual contém uma câmera e luz (UNITY DOCS, 2021f). A Figura 29 demonstra o exemplo de cena.

FIGURA 29 – EXEMPLO DE CENA

FONTE: Unity Docs (2021f, s. p.)

No Unity, a criação de cena é realiza através de uma cópia dos modelos de cena. A Unity Docs (2021g) define que os modelos de cena são

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

Para se criar uma nova cena, podemos realiza-la através de três maneiras:

• Modelo vazio, em branco o qual vamos criando o modelo do zero.• Modelo a partir de um recurso de cena existente.• Modelo a partir da cena atual (UNITY DOCS, 2021h).

Nas duas últimas maneiras podemos criar a cena com o que já foi desenvolvido, ou seja, explorando os modelos criados ou uma parte dele.


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, coloca-se as luzes ao redor da cena. Em cada um dos objetos inseridos devemos incluir ou editar suas propriedades na view Inspector (HOCKING, 2018).

Segundo Wells (2020), criar uma cena tem o seguinte significado:

Uma cena refere-se a um espaço 3D, o espaço-tempo do mundo do jogo - o lugar onde as coisas existem. Como todos os jogos acontecem no espaço e no tempo, precisaremos de uma cena para o jogo de coleta de moedas. Em nosso jogo, uma cena representa um nível As palavras cena e nível pode ser usado de forma intercambiável aqui. Em outros jogos, você pode achar que uma cena contém vários níveis (WELLS, 2020, p. 19-20).

Para se criar uma nova cena, podemos utilizar as teclas de atalho Ctrl + N ou pelo menu, acessando a opção ‘File’ e depois selecionando ‘New Scene’. A figura 30 demonstra a área da cena criada. Podemos observar na figura 30 que além da cena em branco, as guias das views Game e Console, na view Scene temos a visão da cena projetada de maneira rápida e fácil (WELLS, 2020).

Que tal conhecer como montar uma cena em 3D no Unity? Confira o vídeo: <https://www.youtube.com/watch?v=IuDVUILAioY>.

INTERESSANTE

214


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.


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


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


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


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 mudará para Cena visualize (a menos que já seja exibido) para que você possa examinar os detalhes da cena. Pressionando Pausa novamente fará com que o jogo continue de onde parou. Se, enquanto estiver em pausa, você quiser determine o que acontecerá no próximo ciclo, você pode pressionar o botão Play. Pressionando o botão Avançar enquanto um jogo estiver sendo jogado fará com que ele entre em um estado pausado (PIERCE, 2012, p. 25).

O jogo é exibido através da câmera e irá mostrar o que o jogador veria quando estivesse jogando, porém, ao vermos no Unity, nossa exibição do jogo somente é interativa se o botão de reprodução (Play) estiver ativo (BUTTFIELD-ADDISON et al., 2019). Na figura 35 temos um exemplo de como o jogo será exibido. Podemos observar na figura que diversos controles são exibidos para que podemos alterar as configurações de visualização do jogo.

Neste vídeo podemos conhecer mais sobre a iluminação dos jogos no Unity: <https://www.youtube.com/watch?v=G6O3DA3nZZY>.

INTERESSANTE


219

FONTE: Fowler e Chu (2017, p. 50)

Através do menu Exibir (Display), iremos controlar o que será exibido na tela. Em Free Aspect, podemos trocar a resolução e proporção da exibição do jogo. Ao utilizar o botão deslizante Scale, podemos aumentar ou diminuir o zoom de visualização do jogo, se clicarmos em Maximize On Play, o jogo será maximizado, preenchendo toda a janela do editor quando o jogo estiver em reprodução. O botão Mute permite desabilitar o som do jogo. Além destas ações, podemos ver as estatísticas do jogo ao clicar no botão Stats, as quais serão exibidas em um painel sobressalente e, por último, temos o botão Gizmos, o qual nos permite controlar os objetos em cena (BUTTFIELD-ADDISON et al., 2019).

8 MELHORAR O JOGO

Para melhorar nossos jogos, devemos sempre ter as versões mais recentes e estáveis do ambiente, dos plugins e assets que utilizarmos em seu desenvolvimento. É claro que em algum momento devemos dar o desenvolvimento como encerrado e nos dedicar a sua promoção e divulgação. Por isso, seguir o cronograma do seu desenvolvimento à risca é uma boa prática, além de não adicionar a todo momento novos recursos, fases e desafios. É normal encontrarmos jogos infinitos, mas uma hora os jogadores cansam da mesmice e trocam por outro.

A melhoria contínua do jogo, ou seja, a inclusão de novas fases e novas tecnologias devem ser realizadas, ao ponto em que a cada versão lançada gera novidades e são apresentadas ao jogador, além de melhorias gráficas e de jogabilidade, assim como na história do jogo.

O feedback do jogador pode implicar que você ou a equipe reconheça problemas ou melhorias não identificados até o momento. O mesmo ocorre quando a equipe de desenvolvimento informa o que foi alterado. Borromeo (2020) diz que:

FIGURA 35 – EXEMPLO DE EXIBIÇÃO DO JOGO NO UNITY

220


O feedback é um tópico importante nos videogames. Ele fornece informações valiosas ao jogador, como a localização dos inimigos, se houver uma configuração de som 3D, tiro distante representado por focinho pisca em segundo plano, barras de vida indicando que o jogador está prestes a morrer, animações que reagem de acordo com os movimentos do jogador, e assim por diante (BORROMEO, 2020, p. 577).

A otimização do nosso jogo é uma das últimas atividades a serem executadas. Sinicki (2017, p. 199) afirma que a otimização é “fazer seu jogo funcionar sem problemas e seja fácil de editar, melhorar e atualizar daqui para frente”. As técnicas de otimização do Unity permitem melhorar o jogo e seu desempenho. O desempenho do jogo pode ser melhorado ao otimizar os gráficos, o processamento e a memória (BORROMEO, 2020). Essas técnicas são aplicadas pelo Unity quando iniciamos o processo de depuração do jogo, ao “ativar o modo de depuração no Inspetor podemos ficar de olho em todas as variáveis públicas e privadas durante o tempo de execução, certificando-se de que nenhuma variável receba um valor inesperado” (WELLS, 2020, p. 104). Para ativar o modo de depuração, basta seguir o exemplo apresentado pela figura 36, sendo que podemos ativá-lo para analisar o jogo e por objetos.

FIGURA 36 – ATIVANDO O MODO DE DEPURAÇÃO

FONTE: Wells (2020, p. 104)

9 PUBLICANDO O JOGO

Já vimos como salvar nosso jogo no Tópico 2. Para a versão iOS a sequência é similar. No entanto, não é somente publicar no App Store e pronto, pois “Apple App Store exige que todos os jogos publicados tenham algum tipo de opção de login social (como Facebook, Google etc.) e também para oferecer suporte à entrada da Apple . Eles simplesmente não admitirão seu jogo se você não cumprir” (BORREMEO, 2020, p. 524).

Além de termos criado o perfil de desenvolvedor e uma máquina Mac para publicar nosso jogo, uma taxa anual deve ser paga para que nosso jogo seja incluído na App Store e permaneça na loja.


221

Para publicar, é utilizado o iTunes Connect (itunesconnect.apple.com). Se “você pretende vender seus aplicativos, também será obrigado a acessar o Acordos, impostos e bancos seção e coloque suas informações bancárias” (DORAN, 2017). A figura 37 demonstra a tela inicial do iTunes Connect.

FIGURA 37 – ITUNES CONNECT

FONTE: Doran (2017, p. 327)

Após incluir os dados bancários (se aplicável), devemos acessar My App para incluir nosso jogo. Na figura 38, na primeira imagem, temos a tela com os nossos aplicativos. Ao clicar em +, uma janela sobressalente é exibida, a qual devemos preencher as informações do nosso jogo, conforme podemos observar na segunda imagem da figura 38.

Neste menu, preencha iOS como seu Plataforma e coloque o nome do seu jogo abaixo Nome (A Apple exige que cada nome seja único, portanto, lembre-se de que você não poderá usar). (...) Debaixo Língua Primária, selecione Inglês (EUA) e depois selecione o seu ID do pacote e depois abaixo SKU colocar em um identificador (...). Então, clique no Criar botão. (DORAN, 2017, p. 329).

Criar um perfil de desenvolvedor Apple é uma atividade que requer muitos detalhes e informações. Confira o vídeo a seguir: https://www.youtube.com/watch?v=L7SSg05JvZQ.

DICAS

https://www.youtube.com/watch?v=L7SSg05JvZQ

https://www.youtube.com/watch?v=L7SSg05JvZQ

222


FIGURA 38 – ADICIONANDO UM NOVO APLICATIVO

FONTE: Doran (2017, p. 328-329)

Na sequência, uma nova tela (primeira imagem da figura 39) será exibida para o preenchimento das informações do jogo, onde devemos definir o nome, a página oficial, um subtítulo (se aplicável) e definir sua categoria. Em seguida, devemos criar uma breve descrição do jogo, (segunda imagem da figura 39).

FIGURA 39 – INFORMAÇÕES DO APLICATIVO – CATEGORIA - DESCRIÇÃO

FONTE: Doran (2017, p. 330-331)

Na sequência, devemos incluir o ícone e as imagens do jogo, que serão apresentadas aos usuários da App Store, conforme podemos observar na figura 40.


223


Por último, devermos editar as informações sobre o preço e a disponibili-dade (Figura 41). Caso o jogo seja gratuito, deixe como USD 0, caso ele venha ser pago, inclua o valor desejado.

FIGURA 41 – ADICIONANDO UM NOVO APLICATIVO – PREÇO E DISPONIBILIDADE


FIGURA 40 – ADICIONANDO UM NOVO APLICATIVO – ÍCONE E IMAGENS

Publicar um aplicativo na App Store pode ser considerado difícil. COnfir ao vídeo a seguir: https://www.youtube.com/watch?v=NV9qv4YVNtE.

INTERESSANTE

224


No caminho até aqui conhecemos um pouco sobre o ambiente de desenvolvimento de jogos Unity. É claro que não o conhecemos totalmente, mas ao longo de nossa trajetória podemos conhecer o básico dos seus aspectos no desenvolvimento de jogos utilizando este ambiente. Em alguns outros ambientes, a maioria das ações que realizamos podem ser aplicadas. Por isso, utilize-o sem medo, nada que um Ctrl + Z ou iniciar um novo projeto não resolva. Explore-o, assim como outros ambientes para o desenvolvimento de jogo. Explore seus recursos e decida qual o melhor software para desenvolver seus jogos.


225

DESENVOLVIMENTO DE JOGOS: COMO DOCUMENTAR SEU CÓDIGO

Anderson Queiroga

Ter bom conhecimento de uma linguagem específica de programação, ser capaz de escrever códigos de alta complexidade, convenção de nomes, classes, variáveis, etc. são pontos importantes para um profissional da área de criação ou manutenção de software. Além dessas características, é necessário que o profissional tenha outras qualidades que farão grande diferença durante o andamento de um projeto, saber documentar desde a proposta até a entrega do projeto, expor as ideias através de diagramas e fluxos. Elementos estes que ajudaram durante os passos de uma equipe durante o início do desenvolvimento ou durante uma possível manutenção, são importantes no desenvolvimento de qualquer tipo de sistemas, e claro, não poderiam deixar de ser importantes no desenvolvimento de jogos. Neste artigo mostraremos alguns elementos relevantes para uma boa documentação de projeto voltado para jogos, uma breve representação da parte inicial de um projeto a partir da proposta, passando por uma descrição de alguns diagramas e chegando ao início da codificação. O objetivo desse documento não é um detalhamento de uma linguagem específica, de um banco específico e sim as aptidões necessárias para um bom andamento de um projeto de jogo, práticas e situações que são consideráveis no desenvolvimento de qualquer sistema.

Conforme o decorrer desse jogo, cada fase alcançada ficará mais difícil, o jogo tem um perfil de aventura com foco educativo; será para plataforma web com elementos do mundo real. Este jogo é para fins acadêmicos e não comerciais. Serão implementadas funcionalidades como ranking de jogadores e para isso será necessário conexão com um bando de dados.

A principal vantagem desse jogo é que será de fácil entendimento e jogabilidade simples, onde o único objetivo é fazer com que o personagem resgate o máximo de livros com suas limitações de andar para frente, para trás e saltar.

Relato do Processo de Desenvolvimento

A primeira etapa de um projeto é a proposta, momento onde é exposta para o cliente qual a intenção que levou a necessidade do desenvolvimento de um sistema. No PMBOK, que é um manual que descreve um universo de conhecimentos para gerenciamento de projetos, o documento que representa esse momento é o “project charter”. Vamos elencar os passos que fazem parte desse documento.


226


Passo 1 - Designação: onde são mostradas as responsabilidades e competências de cada envolvido no projeto, onde deve ser descrito exatamente como vai ser sua participação no projeto, exemplo, quem é o gerente do projeto, como ele vai integrar toda equipe, como ele vai cumprir os prazos, etc.

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

Passo 3 - Premissas: informa o que é indispensável para a realização de todo o trabalho. Exemplo: equipamentos, infraestrutura, softwares e licenças necessárias.

Passo 4 - Riscos: a seguir, temos uma tabela simplificada com grupos de risco, suas descrições, e seus níveis (Tabela 1).

Grupo de Riscos Descrição de riscos Nível do

Risco

Organização

Falta de dedicação total dos funcionários envolvidos no projeto Alto

Análises e capturas de informações erradas fornecidas pelo cliente Baixo

FundosExceder o valor estimado para a conclusão do projeto Baixo

Solicitação de empréstimos Baixo

PessoalPerda de colaboradores relacionados ao projeto MédioEliminação de pessoas de nível hierárquico da empresa Alto

Tempo Tempo suficiente para a homologação do Projeto Médio

Riscos do Negócio

E se os fundos para o projeto estiverem comprometidos "O que pode garantir fundos adequados"?

Baixo

Não foram realizados os pré-requisitos para a implantação do sistema Baixo

Riscos Técnicos

O escopo do projeto continua sendo aumentando. BaixoSolicitação de customizações de programas durante o período de adaptação do sistema Alto

Interface de difícil administração e visualização BaixoFalta de preparo técnico dos funcionários na utilização do sistema Médio

A solução de o sistema ser muito complexa para a organização. Baixo


227

Descrição de Grupos de Risco no Desenvolvimento do Jogo (Project Management Docs, 2013 - http://www.projectmanagementdocs.com/)

Passo 5 - Principais fases do projeto: são descritas na Tabela 2 as atividades e o prazo para finalização de cada uma. Assim podemos identificar o início, como está o andamento, se houve atrasos ou não e a finalização de todo o projeto.

Descrição das Atividades propostas para o desenvolvimento do jogo

Passo 6 - Principais envolvidos: indicação da participação de cada envolvido- quem é o gerente, o responsável pelos custos, pelo escopo, riscos, qualidade, etc. Para cada área deve ser indicado o nome do principal envolvido.

Passo 7 - Comentário: breve descrição sobre o desenvolvimento do projeto, no caso desse documento trata-se da prática em projetos de jogos - “O jogo possui uma série de controles e processos que serão desenvolvidos dentro de um curto espaço de tempo e com grande qualidade e tecnologia para exceder as necessidades do patrocinador (sponsor) controlando de forma ágil o processo e proporcionando maior agilidade e qualidade dos participantes do jogo”.

Passo 8 - Cenário: conjunto de informações que darão uma primeira visão do sistema, por exemplo, na interface do sistema devem ser apresentadas as primeiras interfaces, momento onde os patrocinadores terão suas primeiras percepções no que diz respeito ao jogo.

Passo 9 - Diagrama de casos de uso: neste caso demonstraremos um diagrama de casos de uso para a proposta de desenvolvimento de um jogo. Esse diagrama mostra as atividades de um ator dentro do ambiente do jogo, detalha quais as funcionalidades dele e o que o jogador poderá fazer dentro do jogo em questão (Figura 1).

Riscos da Tecnologia

Danos físicos aos equipamentos de tecnologia MédioDependência de suporte técnico de equipamentos com contrato de manutenção Médio

Riscos de dependência externa

Suporte com contrato de manutenção não possui componentes para substituição Alto

Legalização de licenças de softwares BaixoComprometimento de entrega do hardware com os fornecedores Alto

228


Diagrama de Casos de Uso desenvolvido no contexto do jogo

Passo 10 - Diagrama de classes: representa as classes necessárias para o desenvolvimento do sistema, muito útil para o programador, pois simplifica a escrita do código e incrementa as funcionalidades descritas no diagrama de casos de uso. No início do desenvolvimento de qualquer sistema, isso é uma fase muito importante, é uma ótima representação gráfica dos códigos em orientação a objetos, e também um primeiro esboço das funcionalidades de um programa, e claro, não poderia deixar de ser menos importante no desenvolvimento de um jogo (Figura 2).

Diagrama de Classes desenvolvido no contexto do jogo


229

Passo 11 - Tabela de requisitos: trata-se da tabela com informações e requisitos necessários para o funcionamento correto do sistema (Tabela 3). Funcionalidades estas que envolvem a segurança do sistema (controle de acesso, validação de usuário, etc.), funcionalidades de configuração, etc.

Definição de Requisitos Funcionais e Não-Funcionais Associados no Contexto do Jogo, baseado no Processo Unificado – UP (Wazlawick, 2013)

Passo 12 - Um sistema geralmente tem conexão com um bom banco de dados. O projeto inicial de um BD é feito através do Diagrama Entidade Relacionamento (DER). Com esse diagrama em mãos é possível entender o processo de normatização do banco. Na Figura 3 temos um simples DER com script SQL. No caso de um jogo simples, geralmente essas informações só dizem respeito à parte de controle de acesso e andamento do jogo. Na figura consta a parte de usuário e navegação no contexto do jogo.

Diagrama Entidade Relacionamento desenvolvido no contexto do jogo

Na Listagem 1 temos um script SQL para banco de dados MySQL, que implementa o diagrama entidade relacionamento (DER) descrito anteriormente.

230


Listagem 1. Script SQL para criação das tabelas de banco de dados do jogo

Passo 13 - Para finalizar, na Figura 4 temos um fluxograma que trata-se de uma prática que auxilia na programação. Basicamente envolve a lógica do funcionamento do sistema através de um diagrama.


231

Figura 4. Fluxograma representando o funcionamento do jogo

Uma boa documentação reduz riscos em momentos iniciais do projeto e facilita a manutenção, é útil também na integração de novos profissionais. Boas práticas no desenvolvimento de qualquer sistema são sempre bem vindas e lógico que as técnicas não param por aqui, existem muitas outras técnicas e benefícios relacionados a cada um dos itens que discutimos aqui; este artigo dá apenas uma visão de uma pequena parte das práticas necessárias para um bom desenvolvimento de um projeto.

FONTE: QUEIROGA, A. Desenvolvimento de Jogos: Como documentar seu código. DevMedia. 2013. Disponível em: https://www.devmedia.com.br/desenvolvimento-de-jogos-como-docu-mentar-seu-codigo/29565. Acesso em: 25 ago. 2021.

Início

Criar Save

Criar Usuário Usuárioexiste?

Ator Pega livros?

qtdLivros = qtdLivros+1

qtdVidas= qtdVidas+1

Ator é atacado?

qtdLivros = 0?

qtdLivros = 0

qtdVidas = qtdVidas-1 qtdVidas = 0?

Game Over!!!

Jogar novamente?

Atualizar save

Venceu!!!

Carregarinformações do save

Retorna informaçõesda fase (vidas, pontos)

Iniciar fase

Animar ator

End

qtdLivros % 100 = 0?

qtdLivros % 0000 = 0

Fase = Fase +1

Fase > 3

232

RESUMO DO TÓPICO 3


• Jogos desenvolvidos pelo ambiente Unity podem utilizados em multiplataformas, bastando a criação de sua versão.

• Podemos criar um projeto diretamente no Unity, ou utilizar o Unity Hub, que também poderá ser utilizado para gerenciar nossos projetos e recursos baixados/instalados.

• O background ou plano de fundo pode ser fixo ou dinâmico, além de podermos criar uma para cada ambiente, fase ou nível de dificuldade. A logo deve ser criada ainda na fase de pré-produção, assim como os backgrounds utilizados (tipo fixo). O ícone deve representar a essência do jogo, e ele será utilizado quando o jogo for publicado nas lojas de aplicativos.

• As transições de tela são realizadas principalmente na sequência de passagem de fases. Ao iniciar o jogo e ao acessar as configurações, podemos representar essas transições utilizando o diagrama de telas, onde podemos identificar todas a telas e como deverá ser seu comportamento ao passar de uma para outra.

• Pode-se escolher três opções de iluminação no Unity: a direcional, a pontual ou a local.

• Ao se exibir o jogo no Unity, temos uma perspectivas do que estamos criando e da visão do jogador, podemos utilizar os controle para controlar a exibição do jogo, assim como podemos personalizar as propriedades de exibição para analisar o jogo sob diferentes configurações.

• O feedback é importante no desenvolvimento dos jogos, uma vez que fornece informações aos jogadores e os jogadores podem contribuir com a melhoria do jogo.

233


CHAMADA

• Para se publicar um jogo na Apple App Store é necessário que tenhamos um perfil de desenvolvedor, que seja publicado utilizando uma máquina Mac e que seja paga uma taxa anual.

234

1 As cenas do jogo é onde iremos representar o mundo do jogo que estamos desenvolvendo, onde serão inseridos os objetos, a física e a iluminação. Podemos criar cenas de três maneiras deferentes. Sobre essas três maneiras de criação de cena, assinale a alternativa CORRETA:

a) ( ) Modelo vazio, a partir de um recurso em cena ou a partir da cena atual.b) ( ) Modelo personalizado, a partir de um objeto em cena ou a partir de um

objeto atual.c) ( ) Modelo personalizado, partir de um objeto em cena ou a partir da cena

atual.d) ( ) Modelo vazio, a partir de um recurso em objeto ou a partir da objeto

atual.

2 A transição de tela é utilizada quando passamos do jogo para o menu ou vice e versa, assim como acessamos as configurações do jogo. Pode ser utilizado um diagrama para criar ou representar como serão realizadas as transições de tela. Sobre o diagrama, assinale a alternativa CORRETA:

a) ( ) Fluxograma.b) ( ) Diagrama de Transições.c) ( ) Diagrama de Estados.d) ( ) Diagrama de Status.

3 A iluminação é um dos elementos utilizados nas cenas e nos objetos mais importantes, sendo que a posição e a rotação determinam qual a parte do GameObject será visível, sem a iluminação o jogo seria escuro e sem vida. Podemos utilizar três tipos de iluminação no Unity. Sobre o exposto, classifique V para as sentenças verdadeiras e F para as falsas:

( ) Focal, sequencial e local.( ) Focal, pontual e central.( ) Direcional, pontual e local.


a) ( ) V – F – F.b) ( ) V – F – V.c) ( ) F – V – F.d) ( ) F – F – V.

AUTOATIVIDADE

235

4 A visualização do jogo na view Game nos possibilita analisar o que vem sendo desenvolvido sob a perspectiva do jogador, onde podemos utilizar os controle de exibição para iniciar o jogo. Disserte como podemos utilizar os três botões de controle de exibição do jogo.

5 Uma cena do jogo pode ser criada a qualquer momento em que estamos desenvolvendo, por padrão o Unity cria sempre uma cena em branco, mas pode-se ser criadas outros tipos de cena. Neste contexto, disserte sobre a importância de se criar as cenas em nossos jogos.

236

REFERÊNCIAS

AGRELA, L. O que é realidade aumentada, chave do sucesso de Pokémon Go. EXAME. 2016. Disponível em: https://exame.com/tecnologia/o-que-e-realidade--aumentada-chave-do-sucesso-de-pokemon-go/. Acesso em: 25 ago. 2021.

BLANCO, J. Zo. Uma abordagem holística para o desenvolvimento de softwa-re multiplataforma. 2020. Disponível em: https://repositorio.ufscar.br/bitstream/handle/ufscar/13517/TeseVFinal.pdf. Acesso em: 22 ago. 2021.

BORROMEO, N. A. Hands-On: Unity 2020 Game Development. Birmingham: Packt Publishing, 2020.

BUTTFIELD-ADDISON, P. et al. Unity Game Development Cookbook: From the Basics to Virtual Reality. Sebastop: Editora O’Reilly Media, 2019.

CARDOSO, B. 9 em cada 10 brasileiros usam celular Android, diz relatório do Google. TechTudo. 2020. Disponível em: https://glo.bo/3bxeumo. Acesso em: 22 ago. 2021.

CHANDLER. H. M. The Game Production Toolbox. Boca Raton: Editora CRC Press, 2020.

CHANDLER, H. M. Manual de Produção de Jogos Digitais. 2ª ed. Porto Alegre, Bookman, 2012.

CHANDLER, H. M. The Game Production Handbook: 3rd Edition. Burlington: Editora Jones & Bartlett Learning, 2013.

CHANDLER, H. M. The Game Production Handbook: Second Edition. Burl-ington: Editora Jones & Bartlett Learning, 2009.

COHEN, D. S.; BUSTAMANTE II, Sergio A.. Producing Games: From Business and Budgets to Creativity and Design. Burlington: Editora Elsevier, 2010.

DORAN, J. P. Unity 2017 Mobile Game Development: Build, deploy, and mon-etize games for Android and iOS with Unity. Birmingham: Packt Publishing, 2017.

EDUARDO, D. Porque Utilizar o Unity? 2015. Disponível em: https://www.eng.com.br/artigo.cfm?id=17. Acesso em: 22 ago. 2021.

FERRÃO, C. Introdução à Unity. 2020. Disponível em: https://www.ufsm.br/pet/sistemas-de-informacao/2020/07/07/introducao-a-unity/. Acesso em: 28 ago. 2021.

237

FLEURY, A. et al. I Censo da Indústria Brasileira de Jogos Digitais, com Voca-bulário Técnico sobre a IBJD. 2014. Disponível em http://www.abragames.org/uploads/5/6/8/0/56805537/i_censo_da_industria_brasileira_de_jogos_digitais_2.pdf. Acesso em: 29 jun. 2021.

FOWLER, A.; CHU, P. Learn Unity 2017 for iOS Game Development Create Amazing 3D Games for iPhone and iPad. Second Edition. New York: Apress, 2017

HOCKING, J. Unity in Action: Multiplatform game development in C# - Second Edition. Shelter Island: Manning Publications, 2018.

IRISH, D. The Game Producer’s Handbook. Boston: Editora Thomson, 2005.

JAMES, D. Android™ Game Programming For Dummies. Hoboken: John Wi-ley & Sons, 2013.

KUCERA, J. R. F. Desenvolva jogos com a Unity 3D. DevMedia. 2013. Disponí-vel em: https://www.devmedia.com.br/desenvolva-jogos-com-a-unity-3d/29125. Acesso em: 22 ago. 2021.

LEAL, F. Tutorial de Física no Unity – Parte 1 – RigidBody. 2016a. Disponível em: https://www.fabricadejogos.net/posts/tutorial-de-fisica-no-unity-parte-1-ri-gidbody/. Acesso em: 2 set. 2021.

LEAL, F. Tutorial de Física no Unity – Parte 2 – Colliders. 2016b. Disponível em: https://www.fabricadejogos.net/posts/tutorial-de-fisica-no-unity-parte--2-colliders/. Acesso em: 2 set. 2021.

LLAGOSTERA, E. Documentação e GDDs. 2016. Disponível em: http://puccjo-gos.github.io/proj1-2016-2s/aulas/documentacao-gdd/. Acesso em: 22 ago. 2021.

MANNING, J; BUTTFIELD-ADDISON, P. Mobile Game Development with Unity: Build Once, Deploy Anywhere. Sebastop: Editora O’Reilly Media, 2017.

MARINHO, J. Apple ultrapassa 1 bilhão de usuários de iPhone. 2020. Disponí-vel em: https://www.tecmundo.com.br/dispositivos-moveis/205904-apple-ultra-passa-1-bilhao-usuarios-iphone.htm. Acesso em: 9 set. 2021.

MASTER.D. O que é o Unity e para que serve? 2021. Disponível em: https://www.masterd.pt/noticias/o-que-e-o-unity-e-para-que-serve. Acesso em: 26 ago. 2021.

MENGE, L. Desenvolvendo Jogos para iOS. 2013. Disponível em: https://www.cin.ufpe.br/~game/aulas/Jogos-iOS-2013.pdf. Acesso em: 9 set. 2021.


238

PANKIEWICZ, I. Consumidores gastaram US$ 40 bilhões na App Store no primeiro semestre de 2021. 2021. Disponível em: https://mundoconectado.com.br/noticias/v/20275/consumidores-gastaram-us-40-bilhoes-na-app-store-no-pri-meiro-semestre-de-2021. Acesso em: 9 set. 2021.

PASSOS, E. B. et al. Desenvolvimento de jogos com unity 3d. In: VIII Brazilian Symposium on Games and Digital Entertainment. 2009. Disponível em: https://www.sbgames.org/~sbgameso/papers/sbgames09/computing/tutorialCompu-ting2.pdf. Acesso em: 22 ago. 2021.

PIERCE, G. Unity iOS Game Development: Beginner's Guide - Develop iOS games from concept to cash flow using Unity. Birmingham: Packt Publishing, 2012.

PRODUÇÃO DE JOGOS. Unity – Guia Completo sobre a Game Engine. 2018. Disponível em: https://producaodejogos.com/unity/. Acesso em: 22 ago. 2021.

ROGERS, S. Level Up: The Guide to Great Video Game Design. Chichester: John Wiley & Sons, 2010.

ROSÁRIO, F. C. do. Desenvolvimento de Aplicativos Móveis Multiplata-forma. 2015. Disponível em: http://repositorio.roca.utfpr.edu.br/jspui/bitstre-am/1/14106/1/MD_COADS_2015_2_05.pdf. Acesso em: 22 ago. 2021.

SAKUDA. L. O.; FORTIM, I. (Org.). 2o Censo da Indústria Brasileira de Jogos Digitais. Ministério da Cultura: Brasília, 2018.

SCHAUKOSKI, E. D. Análise comparativa de frameworks open source para o desenvolvimento de jogos multiplataforma. 2018. Disponível em: http://reposi-torio.unesc.net/bitstream/1/8154/1/EDERSON%20DUARTE%20SCHAUKOSKI.pdf. Acesso em: 22 ago. 2021.

SCHMITZ, L. Análise de Ferramentas de Desenvolvimento Multiplataforma para Criação de Aplicativos Móveis. 2016. Disponível em: https://repositorio.unisc.br/jspui/handle/11624/2149. Acesso em: 22 ago. 2021.

SINICKI, A. Learn Unity for Android Game Development: A Guide to Game Design, Development, and Marketing. Guildford: Apress, 2017.

SPROVIERI, I. Como baixar a unity 2021 [Atualizado]. 2021. Disponível em: ht-tps://www.crieseusjogos.com.br/como-baixar-a-unity-2021-atualizado/. Acesso em: 25 ago. 2021.

TAKOORDYAL, K. Beginning Unity Android Game Development From Be-ginner to Pro. Apress: New York, 2020.

239

TOLLIN, M.; GOMES, R.; LEITE, A.. Desenvolvimento de Jogos para Android: Explore sua imaginação com o framework Cocos2D, Casa do Código, 2012.

UNITY DOCS. Documentation: The Toolbar. 2021a. Disponível em: https://docs.unity3d.com/Manual/Toolbar.html. Acesso em: 28 ago. 2021

UNITY DOCS. Documentation: GameObjects. 2021b. Disponível em: https://docs.unity3d.com/Manual/GameObjects.html. Acesso em: 28 ago. 2021.

UNITY DOCS. Documentation: Using Components. 2021c. Disponível em: https://docs.unity3d.com/Manual/UsingComponents.html. Acesso em: 28 ago. 2021.

UNITY DOCS. Documentation: Prefabs. 2021d. Disponível em: https://docs.unity3d.com/Manual/Prefabs.html. Acesso em: 28 ago. 2021.

UNITY DOCS. Documentation: Physics Section. 2021e. Disponível em: https://docs.unity3d.com/Manual/PhysicsSection.html. Acesso em: 28 ago. 2021.

UNITY DOCS. Documentation: Scenes. 2021f. Disponível em: https://docs.uni-ty3d.com/Manual/Scenes.html. Acesso em: 9 de set. 2021.

UNITY DOCS. Documentation: Creating Scenes. 2021g. Disponível em: https://docs.unity3d.com/Manual/CreatingScenes.html. Acesso em: 9 de set. 2021.

UNITY DOCS. Documentation: Scenes Template Creating. 2021h. Disponível em: https://docs.unity3d.com/Manual/scene-templates-creating.html. Acesso em: 9 de set. 2021.

UNITY. A plataforma líder para criação de conteúdo interativo em tempo real. 2021a. Disponível em: https://unity.com/pt. Acesso em: 22 ago. 2021.

UNITY. Conjunto de ferramentas completo para videogames em 2D e 3D. 2021c. Disponível em: https://unity.com/pt/how-to/difference-between-2D-and--3D-games#unity-2d-and-3d-games. Acesso em: 22 ago. 2021.

UNITY. Get Unity. C2021b. Disponível em: < https://unity3d.com/pt/get-unity/download>. Acesso em: 22 ago. 2021.

WELLS, R. Unity 2020 By Example: A project-based guide to building 2D, 3D, augmented reality, and virtual reality games from scratch. Third Edition. Bir-mingham: Packt Publishing, 2020.

WIEBE, R. Unity iOS Essentials: Develop high performance, fun iOS games using Unity 3D. Birmingham: Packt Publishing, 2011.

desenvolvimento de jogos multiplataformas

Documents