Jogos Eletronicos Na Pratica 2 Ed

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 1
Associação Pró-Ensino Superior em Novo Hamburgo - ASPEUR

Universidade Feevale
Jogos Eletrônicos na Prática

Livro de Tutoriais do SBGames 2012
2ª edição - Revisada e Ampliada
Organizadores
Marsal Branco (Universidade Feevale)
Silvano Malfatti (Univ. do Tocantins)
Marcus Vinicius Lamar (UnB)
Novo Hamburgo - Rio Grande do Sul - Brasil

2013
expediente
Presidente da Aspeur Organização do Evento

Argemi Machado de Oliveira
Coordenador Geral Games for Change
Reitor da Universidade Feevale
Carla Castanho (UnB) Gilson Schwartz (USP - Cidade do
Ramon Fernando da Cunha
Conhecimento)
Pró-Reitora de Ensino Trilha de Computação
Inajara Vargas Ramos Ricardo Nakamura (USP) Mostra de Artes
Licínio Gomes Roque (Universidade de Suzete Venturelli (UnB)
Pró-Reitora de Extensão e Assuntos
Comunitários Coimbra, Portugal) Felipe Ferreira Costa (IESB)
Gladis Luisa Baptista Rodrigo Bonifácio (UnB)
Coordenadores de Publicação
Pró-Reitor de Pesquisa e Inovação Trilha de Arte e Design (Publication Chairs)
João Alcione Sganderla Figueiredo Maria das Graças Chagas (PUC-Rio) Luciana Rocha Clua (PUC-Rio)
Pró-Reitor de Planejamento e Tiago Barros P. e Silva (UnB) Luiz Gonzaga (Unisinos)
Administração
Alexandre Zeni Trilha da Indústria Comissão Especial de Jogos e
Fred Vasconcelos (Abragames) Entretenimento Digital da SBC
Coordenação Editorial
Saulo Camarotti (IESB/Behold Studios) Esteban Clua (UFF)
Inajara Vargas Ramos
Luiz Sakuda (USP) Bruno Feijó (PUC-RIO)
Realização Soraia Musse (PUC-RS)
Instituto de Ciências Sociais Aplicadas – ICSA Trilha de Cultura Carla Castanho (UnB)
Curso de Jogos Digitais Roger Tavares (UFRN) Ricardo Nakamura (USP)
Nelson Zagalo (Univ. do Minho, Portugal)
Editora Feevale
Celso Eduardo Stark Mauricio Miranda Sarmet (UnB) Steering Committee
Daiane Thomé Scariot (Comitê Volante)
Graziele Borguetto Souza Tutoriais Luiz Gonzaga (Unisinos)
Marsal Branco (Universidade Feevale) João Mattar (Univ. Anhembi Morumbi /
Capa
Silvano Malfatti (Univ. do Tocantins) PUC-SP)
Eduardo Fernando Müller
Gabriel Hilgert Marcus Vinicius Lamar (UnB) Joao Ricardo Bittencourt (Unisinos)
Juliano Barbosa Alves (Abragames)
Editoração Eletrônica Festival de Jogos Independentes
Daiane Thomé Scariot Lynn Alves (UNEB)
Bruno Campagnolo (PUC-PR)
Rafael Dubiela (UFPR)
Organização Editorial Artur Mittelbach (PUC-PR)
Kaline Hilgert Perius Guilherme Novaes Ramos (UnB)
Revisão Textual
Dos autores.
Dados Internacionais de Catalogação na Publicação (CIP)

Universidade Feevale, RS, Brasil
Bibliotecário responsável:
Jogos
Jogos eletrônicos na prática : livro de tutoriais do SBGames 2012 [recurso
eletrônico] / organizadores Marsal Branco, Silvano Malfatti, Marcus
Vinicius Lamar. – 2. ed., rev. e ampl. - Novo Hamburgo : Feevale,
2013
125 p. : il.
Modo de acesso: World Wide Web

<www.feevale.br/editora>
Inclui bibliografia.
ISBN: 978-85-7717-159-0
l. Jogos Eletrônicos - Simpósios. 2. Games. 3. Tecnologia. I. Branco,

Marsal. II. Malfatti, Silvano. III. Lamar, Marcus Vinicius. IV. Simpósio Brasi-
leiro de Jogos e Entretenimento Digital.
CDU 794:004
© Editora Feevale – Os textos assinados, tanto no que diz respeito à linguagem como ao conteúdo, são de inteira responsabilidade dos autores
e não expressam, necessariamente, a opinião da Universidade Feevale. É permitido citar parte dos textos sem autorização prévia, desde que
seja identificada a fonte. A violação dos direitos do autor (Lei n.° 9.610/98) é crime estabelecido pelo artigo 184 do Código Penal.
Universidade Feevale
Campus I: Av. Dr. Maurício Cardoso, 510 – CEP 93510-250 – Hamburgo Velho – Novo Hamburgo – RS
Campus II: ERS 239, 2755 – CEP 93352-000 – Vila Nova – Novo Hamburgo – RS
Fone: (51) 3586.8800 – Homepage: www.feevale.br
O Brasil da Tecnologia:
Uma Visão da Intel
Qual é a imagem que o mundo tem do Brasil? O mundo conhece a tecnologia que
se desenvolve aqui? Para tentar responder a estas perguntas resolvi pesquisar na Internet,
e como qualquer outra pessoa interessada em ver o Brasil pelo mundo “online” eu
simplesmente digitei “Brasil” e <enter>, o que eu recebi foi uma coleção infinita de belas
imagens de nossas paisagens, pontos turísticos, do povo bonito e claro, do futebol... mas de
tecnologia não se vê quase nada... O que leva a crer, para os leigos, que o Brasil consome
sim muita tecnologia, mas pouco se produz aqui. O que é um engano.
O Brasil produz sim, muita tecnologia local, nas mais diversas áreas – da televisão
digital à aviação, passando pelas urnas eletrônicas, tecnologias embarcadas, automação
comercial e bancária, extração de petróleo, entretenimento e muitas outras áreas em que o
país se destaca e é referência mundial. O que todas estas áreas têm em comum? O uso de
Software que também em muitos casos se desenvolve aqui.
O Brasil já é uma potência em desenvolvimento de software, contando hoje com
aproximadamente 350 mil profissionais da área de desenvolvimento. E as previsões indicam
que em 2015 o país já terá mais de 500 mil profissionais e será o sexto maior país em número
de desenvolvedores de software no mundo (fonte: Evans Data Corp).
Impressionante? Sim. Por acaso? Não. Isto se deve à união da indústria, sociedade
e governo que abraçaram juntos o desafio de desenvolver aqui mesmo as soluções para
nossos problemas. Alguns podem até dizer que o período da reserva de mercado da década
de ’80 foi o grande responsável por deflagrar o “Brasil tecnológico”, talvez tenha sido em
parte um catalisador importante, mas na verdade a reserva acabou há mais de 20 anos e o
Brasil continua trilhando seu próprio caminho e liderando em diversas áreas.
E o futuro? O futuro é o da criatividade e inovação, como mostra este livro. Da mesma
maneira que o brasileiro cria conteúdo de entretenimento consumido no mundo todo e dá
dribles desconcertantes no futebol, também é capaz de criar software e serviços inovadores.
Nós da Intel apostamos nisso, estamos no Brasil há mais de 25 anos, e neste período
participamos ativamente do desenvolvimento das indústrias de hardware e software
nacionais, tanto apoiando-a comercialmente como estabelecendo acordos de colaboração

tecnológica com empresas do setor aqui presentes. Temos apoiado também a indústria com
os Investimentos da Intel Capital, presente há mais de 10 anos no Brasil, e nos engajamos
em projetos de relevância nacional como, por exemplo, o apoio ao uso de tecnologia na
educação. Já treinamos no Brasil mais de 250 mil professores no uso de tecnologia em sala
de aula e foi aqui que os primeiros computadores para o uso dos alunos foram concebidos,
os “Classmate PC”.
Voltando à pergunta inicial, “O mundo conhece a tecnologia que se desenvolve aqui?
Talvez muitos ainda não conheçam... Mas a Intel conhece e se orgulha de ter feito parte do
processo de desenvolvimento da indústria nacional nos últimos 25 anos.
E como tecnologia é uma língua que já se fala aqui há muito tempo, deixo esta
mensagem em hexadecimal para os “iniciados”:
6120496e74656c206163726564697461206e6f2042726173696c2c2071
75652076656e68616d206f73207072f378696d6f7320323520616e6f732121
Nuno Simões
Intel – Diretor de Iniciativas de Software
Brasil

Caro Leitor
Neste ano, o Simpósio Brasileiro de Jogos e Entretenimento Digital (SBGames) chega

a sua XI edição. Considerado o evento de pesquisa mais importante na área de jogos e
entretenimento digital da América Latina, o SBGames faz parte de um mercado que cresce
a cada ano e que possui como diferenciais a diversão, a criatividade e a inovação.
Durante sua realização, o SBGames proporciona espaços voltados à discussão e
pesquisa relacionadas as diversas áreas que atravessam a produção dos jogos eletrônicos:
Arte e Design, Computação e Indústria. Esses fóruns não apenas representam pontos de
encontros e de trocas, como marcam um momento em que desenvolvedores/pesquisadores
organizam sua produção e apresentam resultados.
Paralelamente, e para além da pesquisa, o SBGames marca de maneira forte a
produção de jogos propriamente dita. Uma das formas como faz isso – um dos pontos
altos do evento – é através do Festival de Jogos Independentes, uma competição de jogos
desenvolvidos de forma Indie sem apoio de empresas ou órgãos financiadores.
A outra maneira é através dos Tutoriais. Os tutoriais têm como objetivo estimular
e propor práticas de desenvolvimento de jogos. São criados por profissionais experientes
e de renome, com o intuito de proporcionar a troca de conhecimentos entre tutoriantes,
comunidade acadêmica e desenvolvedores. Neste ano, uma das principais novidades – que
nos deixa muito orgulhosos – é a publicação desse livro que constitui uma memória física
dos cursos apresentados durante o evento.
Além do registro, espera-se que este livro cumpra sua função de estímulo à produção
e multiplique conhecimentos para que alunos, professores e profissionais da área aprendam
e contribuam cada vez mais com a pesquisa e desenvolvimento de jogos em um país que
vem se destacando como um celeiro de bons profissionais nessa área.
A equipe do XI SBGames deseja a todos uma boa leitura.

Este livro é a concretização de uma vontade antiga. Um velho desejo que de tão
maduro, quando acontece, nos dá não apenas o prazer de vê-lo realidade, mas vem
acompanhado de um senso de realização, de um trabalho (em todos os sentidos) construído
sobre a paciência e disciplina.
O SBGames se faz maduro. Como tal, conquista o livro que você tem em mãos e o
faz da melhor forma possível: pela mistura improvável de habilidades, pessoas, instituições
e embates que caracterizam o processo de maturação pela qual passa a indústria de jogos
brasileira.
Uma indústria que sofre as dores da profissionalização, que tensiona e obriga mudanças
e adaptações rápidas. Indústria que se vê representada nesse novembro de 2012 em Brasília,
reunindo em um evento só articulações científicas, educacionais, políticas comunicacionais
e tecnológicas, alinhadas apontando um futuro brilhante.
Os Tutoriais são fruto de uma demanda técnica. Demanda que representa uma
dimensão fundamental nos alicerces da indústria de jogos. Não basta apenas levantarmos
as bandeiras – necessárias, todas – do reconhecimento do uso dos jogos na sociedade, das
regulamentações, dos processos de gestão e na formação de recursos humanos. Os tutoriais
não nos deixam esquecer as bases: é preciso saber fazer jogos, colocar a mão na massa, se
sujar em arte e código. Os tutoriais representam a paixão silenciosa que nos faz atravessar as
noites testando coisas, criando soluções e novos problemas. Criando jogos.
É com esse sentido que entregamos a vocês o primeiro livro impresso dos tutoriais do
SBGames. Um rebento modesto, mas um rebento e, sobretudo, uma vitória.
Tá vivo, tá aí. Use-o sem moderação.
Dos chairs dos tutorias SBGames 2012

Marsal Branco, Silvano Malfatti e Marcus Vinicius Lamar

Sumário
A Evolução das Técnicas de Inteligência Artificial..............................10
Bruno Duarte Correa
Thiago Dias Pastor
Gameficação - Uma Análise das Técnicas de Engajamento

Atualmente Utilizadas...........................................................................23
Alexandre Sena
Dennis Kerr Coelho
Introdução ao Desenvolvimento de Games com GWT e HTML5........35

Ely Fernando do Prado
Introdução ao Unity...............................................................................53
Jay Clei Garcia dos Santos
Organizando os Mapas de Iluminação dos Assets de Arte para os

Motores de Jogos: Considerações Metodológicas para o Caso da
Produção Voltada ao Motor de Jogos UDK...........................................84
Luís Carlos Petry
Eliseu de Souza Lopes Filho
Maigon Nacib Pontuschka
Felipe Dacal Fragoso
Gabriel Cavalcanti Marques
Winna Hita Iturriaga Zansavio
Point Based Graphics e Aplicações em Jogos......................................103

Luciano Silva
Sumário
A Evolução das Técnicas

de Inteligência Artificial
Bruno Duarte Correa1
Thiago Dias Pastor2
Abstract
Since the dawn of the digital games there is a desire to replicate situations that make us
somehow part of a context and closer to reality. The importance of artificial intelligence
is at the convergence of this longing in simulating increasingly challenging realities. The
techniques of artificial intelligence for games in general are part of a trend that argues that
the role of IA is to simulate the behavior near human and not like other environments eg
optimization objectives, seek to achieve levels of decision making and speed of reasoning
very above an ordinary human being. Artificial intelligence in games is beginning to maximize
the fun emulating a smart player just right, neither too smart nor too dumb demonstrating
weaknesses purposeful. The purpose of this article is to demonstrate some techniques used
in some classic and current games showing their uses and problems.
1 Introdução
Desde os primórdios dos jogos digitais existe a vontade de replicar situações que
nos façam de certa forma fazer parte de um contexto.Quanto mais próximo da realidade
1 Department of Computer and Digital Systems Engineering, Escola Politécnica da Universidade de São
Paulo, Brazil.
2 Department of Computer and Digital Systems Engineering, Escola Politécnica da Universidade de São
Paulo, Brazil.

Sumário
melhor é tal experiência. A importância da inteligência artificial está na convergência

desse anseio em simular realidades cada vez mais desafiadoras. As técnicas para jogos
em geral fazem parte de uma vertente que defende o papel da IA como o de simular
um comportamento próximo do humano, não como em outros ambientes com objetivos
por exemplo de otimização buscam atingir níveis de decisão e velocidade de raciocínio
muito acima de um ser humano comum. A inteligência artificial em jogos tem por princípio
maximizar a diversão emulando um jogador inteligentes na medida certa, demonstrando
fraquezas propositais. A proposta desse artigo é demonstrar algumas técnicas clássicas e
algumas utilizadas nos jogos atuais mostrando os seus usos e problemas com o intuito de
desmistificar a IA de alguns jogos e, como em um PostMortem, estimular o uso de tais
técnicas.
2 Histórico
No princípio, a inteligência artificial nos jogos tinha o papel de alimentar máquinas
caça níquel com o objetivo de manter o jogador por horas e horas entretido e gastando
dinheiro. Jogos como Pong e Pac-Man utilizavam listas pré determinadas de ações e
algumas poucas tomadas de decisão aleatórias na tentativa de tornar os jogos um pouco
mais interessantes. Com o tempo, jogos começaram a utilizar técnicas um pouco mais
avançadas, mas ainda assim incipientes. Entretanto na década de 80 e 90 houve uma grande
reviravolta com jogos preocupando-se com o papel da inteligência artificial em títulos como
Age of Empires II e Warcraft II. Em 1998 a Valve revoluciona com HalfLife e um incrível
avanço nos jogos em primeira pessoa. Em 2000 jogos como The Sims, totalmente focados
na experiência do jogador com a inteligência artificial em jogos que aprendiam com os
jogadores, também contribuiram para a evolução do mercado. A grande realidade é que a
inteligência artificial começou a tomar corpo nos jogos quando as empresas começaram a
levá-la a sério como realmente uma área de desenvolvimento que deve entrar no processo
e não encarada como um adicional no jogo que em geral poderia ser desenvolvido no
último quarto de tempo do projeto, o que acabava por gerar comportamentos previsíveis
e jogos nem tão desafiadores quanto poderiam ser. A visão atual da inteligência artificial é
a de que ela seja totalmente direcionada a contribuir com o gamedesign de tal forma que
facilite as modificações de acordo com a concepção do jogo, podendo traduzir sentimentos
e sensações de forma a tornar a imersão dos jogos muito maior, e não mais encarar as
técnicas de inteligência artificial como uma ferramenta para simplemente melhorar a
experiência do usuário.
3 Motivação
A evolução das técnicas utilizadas em jogos eletrônicos é evidente nos últimos anos,
tornando a experiência muito mais imersiva e trazendo jogos cada vez melhores.É de suma
importância conhecer o estado da arte atual para aplicar tais recursos.

Sumário
4 Técnicas básicas
A classificação quanto às técnicas clássicas e técnicas atuais aqui empregada foi feita
pensando na utilização das mesmas e não por questões temporais como as mais antigas ou
mais recentes.
4.1 Agentes
Agentes são entidades capazes de perceber o ambiente através de sensores e modificá-
lo através de atuadores. O nível de percepção e o raio de atuação dos mesmos determina
diretamente a qualidade da nossa abstração do agente. A maneira como o conhecimento
de um novo acontecimento no mundo é transmitido entre outros agentes pode determinar
uma reação justa ou não por parte dos agentes que não participaram de fato do evento. Um
exemplo clássico desse problema é demonstrada em um jogo de tiro, quando o personagem
principal é avistado por um inimigo e imediatamente todos os outros sabem sobre a sua
localização sem um prévio aviso.
4.1.1 Percepção
Como explicitado no tópico anterior, a modelagem da percepção que o agente faz
do cenário dita em muito a qualidade da inteligência artificial. Uma abordagem é colocar
sensores representando os cinco sentidos. Os mais comuns em ordem de usabilidade são
visão e audição, mas podemos ter representações de olfato ou tomadas de sensação de
temperatura dando uma maior relevância para as informações de cena, auxiliando na
decisão dos agentes. Outra abordagem colocando em evidência a percepção de cena como
um todo e não a percepção micro de um só agente são os blackboards, que tem por objetivo
compartilhar informações de acontecimentos em uma base comum de tal forma que todos
os agentes tenham conhecimento. Essa abordagem é a mais utilizada, porém é preciso tomar
cuidado para não tornar injusta a reação dos agentes.
Figure 1: Sátira da percepção de um agente

Sumário
4.2 Maquinas de estado

O controle de eventos ou comportamentos é totalmente ligado ao contexto do jogo.
Sendo assim, separar em momentos bem definidos facilita em muito a segregação de eventos,
uma melhor depuração de problemas e implementação de novos comportamentos.
Figure 2: Maquina de estados de um agente
Máquinas de estado são úteis em todos os tipos de jogos por facilitarem a organização
de informação em momentos e servir como controle de tomada de decisão.
4.3 Navegação
Os algoritmos de busca de caminho são a implantação de inteligência artificial mais
utilizadas em jogos eletrônicos, tendo soluções das mais rudimentares às mais avançadas e
em essência podem ser divididos em:
• busca cega: é a busca em que o agente não tem conhecimento do cenário tendo
apenas como indicador do caminho a seguir os sensores e uma função objetivo que dita o
quão bom é tomar o próximo passo
• busca informada: o agente de alguma forma tem informação do ambiente em que
se encontra, podendo formular uma solução, conectando o ponto de origem ao ponto
de destino de forma mais acertiva, em geral são soluções mais elegantes, nos dando a
impressão de um movimento mais fluido. Devemos entretanto nos preocupar em dosar o
conhecimento dos personagens para não acabarmos com a naturalidade de uma busca por
caminho que um ser humano comum precisa fazer para ir de um ponto A a um ponto B.
Os algoritmos de navegação, por serem um grande objeto de estudo da robótica,
são uma área muito desenvolvida e geralmente subdividida em um nível mais alto de
abstração em busca de caminho (pathfinding) e fuga de obstáculos (obstacle avoidance).
Nos jogos atuais essa diferença foi desaparecendo gradativamente, visto que raramente
encontramos situações em que no meio de nosso caminho não existam outros agentes ou
mesmo obstáculos móveis.

Sumário
4.3.1 A star
É uma busca do tipo informada, ou seja, o agente tem conhecimento do cenário em
que se encontra. Tem como algoritmo geral a Busca pela Melhor Escolha (best-first-search).
De posse de uma árvore de possibilidades do próximo passo a tomar, ou próximo nó a
escolher. A grande diferença do A star para as outras implementações de best-first-search é
que além de levar em conta o melhor próximo nó também leva em consideração a distância
já percorrida na equação, não somente o custo da expansão do nó atual.
4.3.2 WayPoints
Uma abordagem um pouco mais refinada para a busca de caminho é o uso de
WayPoints [~blog 2008], muito famosos em jogos como Counter Strike.
Figure 3: WayPoints em Halaa
Assim como as árvores de possibilidades nas busca informadas, os WayPoints são

utilizados como modelo de representação do cenário, porém de forma mais visual e intuitiva.
Os WayPoints são nós bases sob os quais são interpoladas as posições intermediárias. Como
observado nessa imagem, em alguns casos é necessário um número muito grande de nós
e caso esses não forem bem posicionados podem causar zig-zags na movimentação dos
personagens. Para ambientes mais complexos não é difícil notar que essa é uma fonte de
erro muito grande. É possível notar também que mesmo com um número bem grande de
pontos, ainda assim existem áreas em que a qualidade da solução está totalmente ligada à
maneira como interpolamos as informações, visto que elas de fato não existem, o que pode
ocasionar no clássico problema do personagem andando rente à paredes ou estruturas.
A utilização dessa técnica não prevê qualquer informação fora do grafo, o que dificulta
a retomada do caminho no advento de um obstáculo móvel ou mesmo a mudança do
cenário por exemplo com a geração de um buraco durante uma batalha. Os WayPoints

Sumário
ainda são muito utilizados em jogos eletrônicos e muitas vezes se mostram suficientes para
resolver o problema da navegação, mas em situações um pouco mais complexas e querendo
representar a movimentação de forma mais fluida ela se torna inviável.
4.4 Algoritmos Genéticos

Algoritmos genéticos (AG) são em essência ferramentas de busca local com um toque
elevado de aleatoriedade, em geral utilizado para procurar soluções fugindo do problema
dos mínimos locais, atingindo resultados inesperados, o que para o universo dos jogos
eletrônicos se torna muito interessante. Assim como o processo de evolução humana, os
AG passam por etapas como:
• Herança: durante o processo de geração da próxima geração alguns genes são
herdados do “pai” ou da “mãe”, portanto de forma aleatória é selecionada a origem de cada
um.
• Mutação: alguns genes após o processo de herança formando o descendente
canônico são modificados para aumentar o fator aleatório da próxima geração.
• Seleção: segundo uma função objetivo que dita o quão bom uma solução é, alguns
descendentes são eliminados ou selecionados
• Cruzamento: assim como no processo de mutação alguns genes foram modificados,
na etapa de cruzamento de cromossomos uma fatia do mesmo é trocada com outro
cromossomo.
Um grande desafio de se obter AGs usuais para o universo de jogos eletrônicos é o
fato que esse processo assim como o processo de evolução natural demorar para convergir
para uma solução ótima, nesse caso devemos com uma função objetivo bem calibrada
atingir uma solução boa. A decisão de como utilizar AG na solução do problema em geral
também esbarra na definição do cromossomo. Uma boa solução é totalmente dependente
de uma boa modelagem do seu cromossomo. Em geral AGs são bem empregadas para
definir comportamentos de personagens obtendo a partir de um dicionário de possibilidades
uma enorme variedade de personagens únicos e inusitados, sendo utilizado portanto
massivamente em jogos de estratégia.
4.5 Redes Neurais

As redes neurais, como citado em [~Charles1], assim como os algoritmos genéticos,
tentam imitar um comportamento da natureza, nesse caso buscam emular o funcionamento
do nosso cérebro que como já sabemos transmite e armazena informações através de
neurônios por meio de suas conexões e sinapses. A proposta das redes neurais é formar
a partir de uma base de dados conhecida e um processo de treinamento uma simulação
de aprendizado, modificando conexões entre neurônios e seus pesos de importância.
Assim como nos algoritmos genéticos a modelagem dos neurônios é diretamente ligada

Sumário
à qualidade da solução e à velocidade de aprendizado. A idéia de criar um jogo que

aprenda com o jogador ou mesmo treiná-lo na fase de balanceamento sempre empolgou
os desenvolvedores, entretanto raramente é feito de maneira aceitável. O aprendizado é
basicamente dividido em:
• Supervisionado: fornecemos para a rede neural dados de entrada e a resposta
desejada, sendo assim o sinal de entrada é propagado por toda a rede e caso atinja uma
solução, tal comportamento é reforçado, do contrário as conexões e pesos são refeitas de
forma a aderir á solução.
• Não Supervisionado: tenta a partir de uma base de dados inicial representar a
estrutura estatísticas dos dados de entrada, sem saber na verdade a solução, tenta a partir
dos dados interpretar o comportamento esperado.
• Reforço: é o comportamento que mais se assemelha à maneira como aprendemos
sozinhos, por tentativas e erro avaliando se estamos mais próximos de atingir o resultado
esperado. Por exemplo como aprendemos a andar, a dirigir ou a lutar.
Figure 4: Aprendizado por reforço
O grande problema da rede neural mal desenvolvida é o aprendizado não convergir

para a solução esperada, podendo, no extremo, por exemplo com um aprendizado não
supervisionado após varias entradas erradas, treinar a rede para responder de forma
inesperada. As redes neurais podem ser empregadas em dois momentos:
• Balanceamento: de posse de uma massa de dados de testes feitos por testers
calibramos a rede para responder de acordo com um comportamento previamente
conhecido.
• Durante o jogo: com o uso de sensores e atuadores a rede interpreta durante o
jogo os comportamentos e balanceia constantemente os pesos e conexões. Essa abordagem
se não bem dosada pode gerar partidas muito difíceis e desestimular o jogador, além de ser
mais complexa a formulação do algoritmo de aprendizado. Jogos como Black and White

Sumário
usam massivamente o aprendizado por reforço durante o jogo, retirando feedbacks dos
jogadores na tentativa de compreender os seus desejos.
Figure 5: Cena de Black and White
Jogos sociais como The Sims também utilizam aprendizado por reforço em tempo
real para compreender o modo como o jogador gostaria que o seu avatar se comporte.
5 Técnicas atuais
5.1 Behavior Tree

É uma máquina de estados finitos hierárquicos disposta na forma de uma árvore. De
forma mais explícita é um grafo direto aciclico e cada nó pode ter várias conexões permitindo
o reuso de sub behavior trees como citado em [2009]. As behavior trees vieram para substituir
a intangível solução de construir um grafo como uma máquina de estados com transições
e ações definidas por uma abordagem mais simples com uma passagem por uma árvore de
comportamentos hierarquicamente aninhados, além de permitir a modificação em tempo
real de maneira bastante intuitiva.
Figure 6: Árvore de comportamento

Sumário
Inicialmente o agente deve ser modelado como uma tabela de características e flags que
serão modificados e consultados durante cada ciclo de passada pela árvore, formando a base
de conhecimento do agente. Tal tabela deve ser feita com o mínimo possível de informações
para facilitar a depuração. A cada ciclo, rodamos a base de conhecimento de cada agente na
árvore, fazendo testes condicionais com o objetivo de atingir uma folha da árvore e executar
uma ação. As ações usualmente são pedaços de código que serão executados caso a folha
seja atingida na passagem da árvore executando uma busca em largura. Uma característica da
behavior tree é a fácil adição de novos comportamentos mesmo em tempo real, simplesmente
anexando uma folha a algum nó. Cada nó é composto basicamente por uma condição,
uma lista de filhos e uma ação, podendo a lista e a ação serem nulas. Podemos adicionar
táticas de grupos por exemplo simplesmente adicionando ao nó uma quantidade máxima
de participantes além da sua condição. Atualmente utilizado em jogos como Halo 2, Halo 3,
Crysis, Left 4 Dead e vários outros títulos.
5.2 Navegação
Os jogos atuais tem abordagens com resultados mais fluidos do que os apresentados
na seção anterior, conferindo ao movimento mais naturalidade e possibilitando uma melhor
manipulação do mundo, facilitando a criação e modificação.
5.2.1 Steering Behavior

Steering Behaviors é um tópico bastante grande e não restrito à navegação. Diversos
efeitos interessantes como Flocking podem ser obtidos com o uso desta técnica. Neste artigo
nos restringimos a Steering Behaviors aplicado a navegação, em especial aos behaviors:
AvoidObstacle, Seek, StayOnPath e AvoidNeighbors. Existem diversas maneiras de enxergar
os Steering Behaviors, foi escolhida a abordagem baseada em campos elétricos pela sua fácil
compreensão. Cada objeto no mundo virtual cria uma campo atrator ou repulsor. (Conceito
bastante semelhante aos campos elétricos). Se um agente estiver sob o raio de ação de um
destes campos, uma força proporcional ao valor dele irá aparecer no agente. A intensidade
e o decaimento destes campos são parâmetros de difícil medição cujos valores vêm da
experiência do designer e da experimentação.
Figure 7: Campo sobre um agente

Sumário
O projeto de um sistema de navegação seguindo Steering Behaviors é completamente

diferente dos sistemas clássicos usando PathFinding. Não existe fase de pré-processamento
para geração de WayPoints além da diferença na semântica das variáveis que neste caso
estão sempre relacionadas com a física. O primeiro passo de um sistema de Steering
Behaviors é definir um agente(o agente de Steering contém alguns atributos a mais do que
um agente de PathFinding) que normalmente é modelado como um veículo (entidade
que possui uma aceleração, um torque e uma velocidade máximas, além de um vetor
direção que aponta para a sua frente e um sistema auxiliar que irá converter a resultante
que o agente está submetido em variáveis físicas como aceleração). Este agente irá possuir
alguns comportamentos chamados na técnica de Behaviors. Um comportamento descreve
como o agente irá enxergar os campos do mundo virtual (atrator ou repulsor). A seguir os
comportamentos usados pelo sistema de navegação serão descritos:
• AvoidObstacle: comportamento bastante simples que consiste em enxergar os
campos dos obstáculos estáticos como repulsores que decaem com a distância.
• Seek: comportamento que consiste em enxergar o Destino como um atrator, ele
será um campo uniforme e não decairá com a distância. O Parâmetro de entrada é a posição
do destino.
• AvoidNeighbors: comportamento bastante complexo (sua explicação detalhada
esta fora do escopo do artigo) que consiste em evitar colisões com outros agentes. O método
usado é baseado em previsão futura de posição (supor que os agentes manterão a mesma
aceleração e velocidade, e prever sua posição em um tempo futuro próximo, verificar se
existe alguma colisão em potencial e, se houver, enxergar a posição da colisão com o campo
repulsor.
Figure 8: Comportamento AvoidNeighbors
• StayOnPath: comportamento que mantém o agente atraído a um percurso.

Fazendo uma analogia, seria como se o agente estivesse dentro de um tubo com atração
elétrica alta, sendo assim o agente sempre tenderia a voltar para a sua envoltória.
Existem muitos outros comportamentos para o Steering Behavior. A grande vantagem
de se utilizar essa abordagem é obtermos comportamentos mais dinâmicos e podermos
adicionar novos comportamentos a qualquer momento visto que com a abordagem de

Sumário
campos elétricos, cada comportamento não passa de um vetor a mais, somado ao movimento
do agente. A utilização isolada entretanto pode causar problemas muito sérios, como por
exemplo o personagem ficar preso em quinas ou devido ao mal calibramento dos campos,
um objeto não conseguir chegar ao seu objetivo. Uma forma de corrigir tal problema é
com uma abordagem híbrida com A star, criando previamente um caminho entre origem
e destino, e com um comportamento StayOnPath garantir que o caminho traçado teria os
pontos bons do A star, a garantia de convergência, e do Steering Behavior, movimentação
fluida e com adição de comportamentos.
5.2.2 Navigation Mesh

Os Navigation Mesh como citado em [~blog 2008] são representações do mundo
assim como os WayPoints citados na seção anterior, entretanto ao invés de representar o
modelo como uma lista de pontos, utiliza um modelo que demonstra os locais onde os
agentes podem se locomover. Os meshes podem ser gerados em modeladores 3D em geral
no mesmo momento que o designer está desenvolvendo o modelo do cenário, já tem a
possibilidade de desenvolver o terreno de locomoção. Como os meshes são representações
de posições livres para andar enquanto não houver movimentação ou modificação do
cenário, os testes de colisão podem ser reduzidos consideravelmente pois garantimos que
nenhum NPC vai tentar atravessar alguma parede ou colidir com algum objeto. Com o
uso dos WayPoints, tinhamos regiões que eram interpoladas, com o uso dos Navigation
Mesh, temos uma densidade de informação bem maior com uma quantidade de dados
armazenado muito menor como mostra na figura:
Figure 9: Navigation Mesh em Halaa
Como temos uma densidade de informação bem maior, podemos ter uma interpolação
entre pontos muito mais suave, e reações para desviar de obstáculos moveis que não tinham
sido previstos no advento da criação da cena, por exemplo. Ao invés de representar o mapa
como um grafo de pontos conectados, utilizamos como um grafo de polígonos convexos.
Navigation Mesh são muito utilizados ultimamente por exemplo em jogos como: Halo 2, Halo
3, First Encounter Assault Recon (F.E.A.R.), Counter-Strike: Source, Metroid Prime, Metroid

Sumário
Prime 2: Echoes, Metroid Prime 3: Corruption, Jak and Daxter: The Precursor Legacy, Jak II,
Jak 3, Uncharted: Drake’s Fortune, Scarface: The World is Yours e muitos outros.
5.3 Planning GOAP (Goal-Oriented Action Planning)

GOAP como citado em [2003] e [2006] é uma técnica para tomadas de decisões que
produz uma sequência de ações (plano) para atingir objetivos. O sistema é composto por:
• Goal: É qualquer condição que o agente deseja satisfazer;
• Action: é um passo atômico no Plan que faz o personagem fazer algo;
• Plan: uma lista de Actions.
É um processo que não elimina as máquinas de estado mas simplificam em muito
a sua utilização além de tornar dinâmica a sua criação, sendo composto por um estado
inicial, uma meta (Goal) e ações atômicas para concluir, assemelhando bastante com a idéia
de uma maquina de estados, entretanto, ao contrário desta, as conexões podem ser várias,
obtendo uma grande gama de possibilidades, o que aumenta em muito a diversidade das
soluções, impedindo que o jogador aprenda como o jogo se comporta e burle a inteligência
artificial. Essa estrutura dinâmica possibilita tanto soluções inesperadas quanto uma fácil
adição de novos comportamentos.
Figure 10: Processo de formação de solução
A criação dos planos é feita por uma busca em um grafo de ações em geral utilizando
A star, considerando os nós como os estados e as arestas como ações. As vantagens sobre
a solução clássica de tomada de decisão das maquinas de estado é que a princípio não
é necessário determinar previamente todas as conexões que levam até as metas sendo
que a única coisa que temos que especificar são pré-condições e efeitos para cada ação.
Devido à flexibilidade e a facilidade de depuração e criação dos planos esta técnica, apesar
de considerada nova, está tomando força frente aos novos jogos utilizada em jogos como
F.E.A.R.(X360/PS3/PC), Condemned:Criminal Origins (X360/PC), S.T.A.L.K.E.R.: Shadow
of Chernobyl (PC), Mushroom Men: The Spore Wars(Wii), Ghostbusters(Wii), Silent Hill:
Homecoming ( X360/PS3), Fallout 3 ( X360/PS3/PC), Empire: Total War (PC), F.E.A.R. 2: Project
Origin (X360/PS3/PC), Demigod (PC), Just Cause 2 (PC/X360,PS3), Transformers: War for
Cybertron (PC/X360/PS3), Trapped Dead (PC), Deus Ex: Human Revolution (PC/X360/PS3).

Sumário
6 Tendências
A evolução da inteligência artificial tem de estar sempre junto com a evolução da
qualidade gráfica dos jogos, do contrário todo o esforço em computação gráfica será em
vão, obtendo jogos frustrantes. A simulação de eventos ou comportamentos tem de ser cada
vez mais verossímil. Por isso existem desenvolvimentos de ferramentas de teste e calibração
dos algoritmos de forma mais intuitiva para que o designer possa modificar os dados sem
a ajuda de um programador. Com a migração de parte do processamento da inteligência
artificial para as placas de vídeo, o poder computacional empregado crescerá bastante,
sendo possível por exemplo o desenvolvimento de simulação de multidão mais realista e
cut scenes interativas eliminando os cinematics pré renderizados. Uma forte tendência é
aumentar o poder das IAs online, podendo evoluir o aprendizado de redes neurais a partir
de informações dos jogadores.
7 IA na GPU
Devido ao crescente papel da inteligência artificial nos jogos eletrônicos o percentual
ocupado de cada ciclo de atualização começou a tornar-se significativo, influenciando
no tempo de renderização, simulação física ou gameplay. Como não podemos reduzir a
qualidade das simulações físicas ou diminuir a qualidade visual do jogo, a única solução
era utilizar o tempo ocioso da placa de video enquanto não estivesse renderizando para
fazer cálculos para IA. É fato que ainda são poucas as implementações que se utilizam de tal
benefício, mas a tendência é a de cada vez mais migrar para a GPU, visto que a mesma possui
poder de processamento muito superior ao da CPU para cálculos vetoriais ou repetitivos.
References
[~blog 2008] ai blog, 2008. Why waypoints aren’t for pathfinding, 7.
[and Mcglinchey] Charles, D., and Mcglinchey, S. The past, present and future of
artificial neural networks in digital games.
[2003] Orkin, J., 2003. Applying goal-oriented action planning to games.
[2006] Orkin, J. 2006. Three states and a plan: The a.i. of f.e.a.r. GDC.
[2009] Pilosu, R., 2009. Coordinating agents with behaviour trees.
[2004] Reynolds, C. W., 2004. Steering behaviors for autonomous characters.

Sumário
Gameficação - Uma Análise

das Técnicas de Engajamento
Atualmente Utilizadas
Alexandre Sena1
Dennis Kerr Coelho2
Resumo
O sucesso que os jogos eletrônicos, ou games, vêm fazendo em todas as faixas etárias é
inegável e grande parte deste sucesso só pode ser explicado analisando certos aspectos
do game relacionados com sua habilidade de manter o jogador o maior tempo possível
interessado. Para entender o que cativa um jogador é importante descobrir suas motivações
e de que formas os games trabalham seus desejos e geram novas motivações. Estudos
demonstram que é possível a utilização de técnicas de engajamento idealizadas para incutir
no jogador emoções e sentimentos, conforme o seu perfil, para garantir seu interesse no game,
aumentando o tempo dedicado ao mesmo. Este tutorial apresenta alguns cases de softwares
de setores considerados tradicionais que utilizaram tais técnicas e assim se beneficiaram de
um processo de gameficação, o qual pode ser definido como o uso das mecânicas de game
em aplicativos e software. A ideia é encorajar os usuários a adotar comportamentos desejáveis
por meio de técnicas que tiram vantagem das características psicológicas humanas. Mas vale
a pena ressaltar que a gameficação pode auxiliar em muito o setor tradicional de software,
mas não se deve esperar que a ela seja a solução mágica para qualquer coisa. Ou seja, estas
1 Universidade Federal de Santa Catarina, Departamento de Engenharia e Gestão do Conhecimento, Brasil.

2 Universidade do Vale do Itajaí, Centro de Ciências Tecnológicas da Terra e do Mar, Brasil.

Sumário
técnicas podem agir como ferramentas complementares, mas não oferece vantagem se o
serviço/atividade onde estão sendo implementados, não ofereçam a sensação de realização.
Palavras-chaves: Games. Motivação. Perfil do jogador. Técnicas de engajamento.
Introdução
O sucesso que os jogos eletrônicos, ou games, vêm fazendo em todas as faixas etárias
é inegável. Segundo a consultoria online (Newzoo, 2011), há nos Estados Unidos 145
milhões de jogadores (43% da população), os quais passaram 215 milhões de horas jogando
videogame por dia.
Grande parte deste sucesso só pode ser explicado analisando certos aspectos do game
relacionados com sua habilidade de manter o jogador o maior tempo possível interessado.
Deste modo, a primeira seção deste tutorial se dedicará a apresentar conceitos
teóricos que auxiliarão na contextualização da base dos estudos. Em especial alguns aspectos
psicológicos, como a motivação.
A segunda seção do tutorial apresenta a motivação no contexto apresentado pela
indústria de games, por meio de seus desenvolvedores. Pois como diz Ghozland (2010), a
importância do game está relacionada com a capacidade do mesmo em gerar e manter o
interesse dos jogadores, sendo a motivação o fator que define o tempo que este jogador se
manterá jogando, alguns minutos ou várias horas.
A terceira seção dedica-se demonstrar um resumo das diversas técnicas de
engajamento e alguns exemplos de games que as utilizaram, bem como uma proposta dos
melhores usos de cada técnica, tendo em vista o perfil do jogador.
Para finalizar é feito um levantamento na quarta seção sobre como as técnicas
identificadas anteriormente estão sendo implementadas por softwares tradicionais, por
meio da gameficação.
Conceituação Teórica
Antes do estudo dos cases esta seção se dedica a apresentar alguns conceitos básicos
no que se refere aos aspectos psicológicos deste tema.
Os primeiros conceitos são aqueles relacionados a dimensão subjetiva, a qual pode
ser reconhecida também em produções para games por meio de representações sociais,
identidade social, ideologia, valores, rituais, hábitos, costumes, leis e regras. A subjetividade
cria produtos coletivos, nos quais se percebe a participação de sujeitos. (Gonçalves & Bock
2009)
O psiquismo é uma chave para entender esta subjetividade, sendo suas principais
categorias: atividade, consciência, identidade e afetividade. Tais categorias permitem pensar
a realidade psíquica em seu movimento de transformação e nas relações que se estabelecem
para a produção do que é chamado subjetividade. (Gonçalves & Bock 2009)

Sumário
E um fator que influencia definitivamente na criação da subjetividade é a motivação.

Em seus estudos, Matlin (2004) faz uma grande pesquisa sobre motivação, utilizando como
referência diversos autores. Como base nestes estudos, algumas considerações podem ser
feitas sobre este assunto.
Há, por exemplo, dois tipos de motivação: a intrínseca e a extrínseca. A primeira se
refere à motivação para se trabalhar com aquilo que se considere interessante, empolgante
ou pessoalmente desafiador. O segundo tipo, por sua vez trata da motivação para se trabalhar
em um determinado assunto com a promessa do recebimento de uma recompensa.
A autora identificou ainda uma relação entre motivação intrínseca e a criatividade,
ou seja, as pessoas tendem a ser mais criativas quando fazem algo que lhes dá prazer.
Mas não se pode simplesmente descartar a motivação extrínseca como forma de
alcançar resultados criativos. Uma análise mais detalhada sugere que alguns tipos de
motivação extrínseca na verdade podem melhorar a criatividade. Um exemplo é o proveito
que se pode ter da motivação extrínseca quando ela vem na forma de informações úteis e
quando ajuda a executar uma tarefa com mais eficiência.
Figura 1 – Resumo de teorias clássicas (Vassileva 2012)
Finalizando esta seção, a figura 1 apresenta um interessante resumo de teorias

clássicas que podem auxiliar a entender aspectos psicológicos importantes para o estudo da
motivação, os quais valem destacar (Vassileva 2012):
Garantir recompensas, segundo a teoria da motivação extrínseca, leva o sujeito a realizar

uma determinada ação ou apresentar um determinado comportamento;
Todos os seres humanos necessitam socializar e procuram por formas de reconhecimento
social e de status; Reconhecimento e reputação estão associados com as capacidades do
sujeito (Teoria da auto-eficácia de Bandura);
A teoria da cognição dissonante cita que as pessoas tendem a comparar-se àquelas que
consideram semelhantes a elas, e objetivam com isto avaliar formas de melhoria.
A comparação social parece ser um poderoso incentivo para aumentar a contribuição em
comunidades online.
Motivação do Jogador
Para entender o que cativa um jogador é importante descobrir suas motivações e de
que formas os games trabalham seus desejos e geram novas necessidades. O santo graal da

Sumário
indústria dos games é decifrar o mecanismo da motivação do jogador. Game Designers ao

redor do mundo estão tecendo suas teorias sobre a motivação dos jogadores e como tirar
proveito dela em seus games.
Segundo Ghozland (2010):
“A importância da experiência de um jogo depende de quanto interesse ele pode gerar. Criar
e manter o interesse dos jogadores é a maneira de gerir a sua motivação. Sua motivação é
o fator que irá determinar se um jogador vai continuar a jogar depois de alguns minutos,
bem como quanto tempo ele vai jogar e se ele vai terminar o jogo.”
O objetivo desta seção é mesclar o conteúdo prévio apresentado com a visão de

mercado. O primeiro passo é entender como os game designers utilizam a motivação, em
especial a intrínseca. Em 1996, Bartle publicou um estudo onde propõe uma taxonomia para
entender como os diversos perfis de jogadores são motivados. Como pode ser observado
na figura 2, os jogadores foram divididos em quatro categorias: Realizadores, Exploradores,
Socializadores e Predadores.
Figura 2 - Taxonomia de Jogadores (Bartle, 1996)
Os realizadores são motivados por fazer o que o game lhes pede (missões, quests,
etc.) e em agir sobre o mundo virtual. O ambiente do game é um mundo pleno e ele pode
mergulhar da maneira que achar mais atraente. O compartilhamento deste mundo com
outros jogadores normalmente apenas adiciona um pouco de autenticidade à imersão e,
talvez, um elemento competitivo. Realizadores se orgulham de seu status formal na hierarquia
do game e do pouco tempo que eles levaram para alcançá-lo.
Já os exploradores estão interessados em serem surpreendidos pelo game, ou seja,
em interagir com o mundo criado e descobrir seus segredos. É o sentimento de admiração
que os motivam a seguir em frente. Outros jogadores adicionam profundidade ao game,
mas eles não são componentes essenciais para sua permanência, exceto, talvez, como
meios de acesso a novas áreas. Exploradores se orgulham de seu conhecimento dos pontos
mais delicados do game e gostam de se considerarem “gurus” para os jogadores menos
experientes.

Sumário
A terceira categoria, os socializadores, estão interessados em interagir com outros

jogadores. Isso geralmente significa conhecer, informar-se e comunicar-se com outros
jogadores. Muito mais do que tratá-los como um simples meio de atingir seus objetivos, o
socializador se orgulha de suas amizades, seus contatos e sua influência.
Finalmente, os predadores estão interessados em demonstrar sua superioridade
sobre outros jogadores. Normalmente veem estes outros jogadores como adversários ou
meras ferramentas para seus objetivos, não se importando com a interação social. Usam
o mundo do game como uma catarse, realizando ações que no mundo real não seriam
permitidas. Predadores se orgulham da sua reputação e de suas habilidades frequentemente
praticadas em combate.
Fica claro que o entendimento dos perfis dos jogadores auxilia os desenvolvedores
a incluir elementos que garantem a existência da motivação intrínseca. Contudo, tal fator
isolado não pode garantir o sucesso de um game.
Além deste aspecto, Clark (2007) identificou outras seis características subjetivas que
fazem os games cativantes: autonomia, auto-confiança, desafios, feedback, metas e interação
social.
Uma análise mais aprofundada demonstra que entre estas sete características, uma é
relativa aos aspectos do relacionamento coletivo (interação social); três estão focadas com
aspectos inseridos no game (desafio, feedback e metas); e os três últimos necessitam ater-se
a uma dimensão subjetiva da realidade, pois dependem da produção de certas emoções no
indivíduo para gerar os efeitos desejados (motivação intrínseca, autonomia, autoconfiança).
Para tanto é importante a inserção no game de uma narrativa criativa e não- linear,
que tenha suporte nos diferentes elementos hipermidiáticos fornecidos por videogames e
computadores.
Há três elementos que devem ser inseridos nesta narrativa, assim como no próprio
design do game: necessidade, desafios e recompensas. Deste modo, gerenciando essas três
variáveis seria possível gerenciar a motivação do jogador assim como os demais elementos
subjetivos.
Tendo isto em vista, Ghozland (2010) argumenta que o design do game deve construir
o ciclo de necessidades do jogador e depois respondê-las com uma sucessão de desafios e
recompensas. Esta estrutura inerente a um game é construído em torno dos princípios de
crescimento, progressão e realização do individuo, afetando diretamente seu sentimento de
autonomia e autoconfiança.
Além dos fatores previamente apresentados, Novak (2010) apresentou
complementarmente em seu livro outros fatores que motivam os jogadores a continuarem
jogando:
Escapismo: Muitos jogadores indicam que tendem a jogar para escapar das tensões e
dos desafios da vida real. O mundo imaginário do game segue suas próprias regras, algumas
das quais são menos restritivas que as da vida real.

Sumário
Compulsão: Alguns jogadores afirmam que são motivados pela tendência de

concentrar-se em uma atividade em prejuízo de todas as demais. Uma dos maiores elogios
que um game designer pode receber de um jogador e ele dizer que o game é viciante.
Técnicas de Engajamento
Com base no exposto, é possível a utilização de determinadas técnicas para incutir no
jogador emoções e sentimentos, conforme o seu perfil, para garantir seu interesse no game,
aumentando o tempo dedicado ao mesmo.
Estas técnicas de engajamento são recursos de game design utilizados para motivar
e manter um jogador interessado no game. Existem várias técnicas que vêm sendo usadas
nos mundos dos games a bastante tempo, mas foi a partir do sucesso dos games para redes
sociais que mais pesquisas foram feitas.
Essa popularização fez com que fossem criadas pequenas “receitas de bolo” que
podem ser utilizadas nos mais diversos games ou aplicativos. A seguir são apresentadas
algumas destas técnicas.
Achievements ou Badges são pequenos prêmios virtuais na forma de bottons ou
insígnias, esses prêmios são oferecidos aos jogadores depois de realizarem alguma tarefa ou
obterem alguma conquista. Segundo Zichermann e Cunningham (2011), badges são uma
excelente maneira de incentivar a promoção social de produtos e serviços relacionados ao
game. Badges também marcam a conclusão das metas e o progresso constante dentro do
sistema do game.
Figura 3 – Exemplo de badges do game Battlefield: Bad Company 2
Desafios e Missões são técnicas muito utilizadas para manter o jogador ocupado ou
evitar a sensação de fim do game. Além disso, essas técnicas fazem com que o jogador siga um
caminho no mundo virtual condizente ao planejado pelo game designer. Algumas pessoas
entram no game sem a menor ideia de seus objetivos ou fundamentos, assim, mesmo se
um desafio não está no centro da experiência do game, utilizar desafios é uma opção para
adicionar profundidade e significado para o jogador. (Zichermann & Cunningham 2011)

Sumário
Figura 4 - No Game CityVille quests são uma forma do game designer orientar
o jogador na forma deste interagir com o mundo criado
Rankings e Leader Boards objetivam incentivar a competição entre os jogadores,

fortalecendo assim sua motivação para jogar e evoluir.
Figura 5 - A utilização de Learder Boards é peça fundamental no game Fruit Ninja
Progress Bar demonstra a evolução do jogador ao longo do game, assim o jogador

sabe o quão perto de completar algum desafio ou objetivo ele se encontra.
Uma recurso muito adotado pelos desenvolvedores é sempre manter o jogador perto
de finalizar uma progress bar, seja mudar de nível de experiência, melhorar uma habilidade
ou adquirir uma arma melhor. Deste modo, no momento que um objetivo é alcançado,
outro está muito próximo de ser completado, o que aumenta o tempo de permanência.
Figura 6 - Exemplo da progress bar do MMO World of Warcraft

Sumário
Gifting é um sistema implementado no game para aumentar a interação social. Com

esse sistema o jogador é estimulado a dar presentes para seus amigos, os quais são
atraídas ao game. A troca diária de presentes pode criar grupos fiéis de jogadores que
retornam periodicamente.
Figura 7 - Opções de presentear amigos se tornou rapidamente item obrigatório de qualquer jogo
em redes sociais, como é o caso do game FrontierVille
Como base no exposto, a tabela a seguir apresenta uma proposta dos autores do
melhor uso de técnicas de engajamento, tendo em vista o perfil do jogador e os aspectos
subjetivos envolvidos.
Tabela 1 - Relação entre técnicas de engajamento e subjetividade (fonte: autores)
Características
Técnicas de Engajamento Perfil do Jogador
Reforçadas
Achievements Autonomia, auto-confiança,

Realizadores, Socializadores,
desafio, feedback, metas,
ou Badges Exploradores
escapismo, compulsão.
Motivação intrínseca,
Desafios e auto-confiança,
Realizadores, Exploradores
Missões desafio, feedback, metas,
escapismo, compulsão.
Autonomia, auto-confiança,
Rankings e Leader Boards desafio, metas, interação Predadores, Socializadores
social.
Motivação intrínseca,
Progress Bar auto-confiança, desafios, Todos
feedback, metas, compulsão.
Gifting Interação social. Socializadores

Sumário
A proposta apresentada na tabela 1 é uma simples generalização, pois como Bartle

também mencionou em seu trabalho, os jogadores podem apresentar, mesmo e menor
grau, características de diversos perfis simultaneamente.
Cases
A presente seção apresenta alguns cases de softwares de setores considerados
tradicionais que utilizaram técnicas de engajamento e assim se beneficiaram de um
processo de gameficação.
Gameficação é o uso das mecânicas de game em aplicativos e softwares. A ideia é
encorajar os usuários a adotar comportamentos desejáveis por meio de técnicas que tiram
vantagem das características psicológicas humanas. Essas técnicas encorajam o usuário
a realizar tarefas consideradas normalmente entediantes como completar uma pesquisa,
comprar algo, ou manter um cadastro atualizado.
O Foursquare, por exemplo, é um serviço baseado em localização com mais de
20 milhões de usuários em sua plataforma. O serviço foi construído em torno de técnicas
de engajamento. Os usuários podem reclamar de prefeituras, destravar os badges, receber
ofertas especiais e recompensas, tais como descontos, e disputar contra amigos por meio
de um ranking.
Utilizando as técnicas de engajamento o Foursquare cria e mantém uma base de
dados da localização de locais e construções de interesse das pessoas. Pessoas que acabam
buscando no Foursquare informações mais detalhadas sobre esses lugares. Com essa
estratégia o Fousquare construiu essa base de dados com um custo infinitamente menor
ao de outras empresas que construíram através de suas próprias forças.
Figura 8 - Exemplo de aquisição de Badge

Sumário
Apesar da falta de estudos científicos, outra área que parece se beneficiar do potencial
das técnicas aqui apresentadas são as soluções para ERP e CRM. Entendendo este potencial,
a Salesforce.com permitiu que terceiros desenvolvessem soluções que se integrasse ao seu
CRM com utilização de leaderboards e badges, como demonstrado na figura 9.
Figura 9 - Exemplo de ranking e badges
Um fator apontado por JP Rangaswami, cientista chefe da Salesforce.com é que o uso

de badges e ranking traz inúmeras vantagens.
Para o funcionário da empresa, ao receber um distintivo virtual toda vez que ele
realiza uma ação a favor da empresa, ou toma a iniciativa de capacitar-se, fica evidente aos
indivíduos que a empresa está acompanhado os esforços e motivando o crescimento.
Como empresa, ter um resumo visual de cada colaborador da forma apresentada na
figura 9 facilita em muito o processo de criação de equipe de trabalho ou acompanhar a
performance de uma equipe de vendedores, por exemplo.
A rede social LinkedIn também oferece um pequeno exemplo de gameficação ao
incentivar usuários a completar seu perfil, por meio de uma barra de progresso sempre visível.
Ao fornecer este recurso, os desenvolvedores esperam desencadear um comportamento
que impele o usuário tentar chegar aos 100%.
O gerenciado financeiro pessoal Mint oferece um score para seu desempenho
em gestão financeira baseada em técnicas de engajamento associadas com a progressão
do usuários na conclusão de tarefas e quests. Ao tornar uma atividade comum em uma
experiência de game casual, o Mint cria uma oportunidade para impulsionar a aquisição de
novos usuários de uma forma criativa.
Para finalizar, vale ressaltar que a gameficação pode auxiliar em muito o setor
tradicional de software, visto que a geração atualmente ativa no mercado de trabalho,
mesmo aqueles que não são gamers, com certeza estão familiarizados com os mecanismos
utilizados nos games (competividade, rankings, etc.)
Contudo, não se pode esperar que a gameficação seja a solução mágica para
qualquer coisa. Ou seja, estas técnicas podem agir como ferramentas complementares a
uma estratégia da empresa, mas não oferece vantagem se o serviço/atividade onde estão
sendo implementados não ofereçam a sensação de realização.

Sumário
Referências
Anderson et al., 2004. Continental Airlines Flies High with Real-time Business Intelligence
Continental Airlines Flies High with Real-time Business Intelligence Introduction. MIS
Quarterly Executive 3, (4), pp.163 – 176.
Bartle, R., 1996. Heart , Clubs , Diamond , Spades: players who suit muds. The Journal
of Virtual Environments, 1(1). Available at: http://www.mud.co.uk/richard/hcds.htm
[Accessed February 9, 2012].
Clark, D., 2007. Games , motivation & learning, Sunderland, UK. Available at: www.
caspianlearning.co.uk.
Cooper, B.L. et al., 2000. Data Warehousing Supports Corporate Strategy at First American
Corporation. MIS Quarterly, 24(4), pp.547–567.
Cooper, S. et al., 2010. Fold it. Available at: http://fold.it/portal/about [Accessed June 12,
2012].
Coren, M.J., 2011. Foldit Gamers Solve Riddle of HIV Enzyme within 3 Weeks. Scientific
American, p.1.
Garrido-Moreno, A. & Padilla-Meléndez, A., 2011. Analyzing the impact of knowledge

management on CRM success: The mediating effects of organizational factors.
International Journal of Information Management, 31(5), pp.437–444. Available at:
http://linkinghub.elsevier.com/retrieve/pii/S026840121100003X [Accessed July 20, 2012].
Ghozland, D., 2010. Designing for Motivation. Gamasutra, pp.1–9. Available at: http://
www.gamasutra.com/view/feature/1419/designing_for_motivation.ph p.
Gonçalves, M. da G.M. & Bock, A.M.B., 2009. A dimensão subjetiva dos fenômenos sociais.
In M. da G. M. Gonçalves & A. M. B. Bock, eds. A dimensão subjetiva da Realidade -
Uma leitura sócio-histórica. São Paulo: Cortez Editora, p. 160.
Hajji, A. et al., 2012. Dynamic pricing models for ERP systems under network externality.
International Journal of Production Economics, 135(2), pp.708–715. Available at:
http://linkinghub.elsevier.com/retrieve /pii/S0925527311004348 [Accessed August 5, 2012].
Matlin, M.W., 2004. Psicologia Cognitiva 5a Ediçao., Rio de Janeiro: LTC.
Newzoo, 2011. Infograph US. Newzoo. Available at: http://www.newzoo.com/templates/

dispatcher.asp?page_id=1589 [Accessed February 11, 2012].
Novak, J., 2010. Desenvolvimento de Games, São Paulo: Cengage Learning.
Polat, K. & Durduran, S.S., 2011. Subtractive clustering attribute weighting (SCAW) to

Sumário
discriminate the traffic accidents on Konya– Afyonkarahisar highway in Turkey with the
help of GIS: A case study. Advances in Engineering Software, 42(7), pp.491–500.
Available at: http://linkinghub.elsevier.com/retrieve /pii/S0965997811000573 [Accessed
August 5, 2012].
Ramakrishnan, T., Jones, M.C. & Sidorova, A., 2012. Factors influencing business
intelligence (BI) data collection strategies: An empirical investigation. Decision Support
Systems, 52(2), pp.486–496. Available at: http://linkinghub.elsevier.com/retrieve /pii/
S0167923611001722 [Accessed July 25, 2012].
Vassileva, J., 2012. Motivating participation in social computing applications: a user

modeling perspective. User Modeling and User- Adapted Interaction, 22(1-2), pp.177–
201. Available at: http://www.springerlink.com/index/10 .1007/s11257-011-9109-5 [Accessed
March 26, 2012].
Wybo, M., Robert, J. & Léger, P.-M., 2009. Using search theory to determine an
applications selection strategy. Information & Management, 46(5), pp.285–293.
Available at: http://linkinghub.elsevier.com/retrieve /pii/S0378720609000597 [Accessed
August 5, 2012].
Zichermann, G. & Cunningham, C., 2011. Gamification by Design: Implementing

Game Mechanics in Web and Mobile Apps 1st ed., Sebastopol (CAN): O’Reilly Media,
Inc.

Sumário
Introdução ao Desenvolvimento
de Games com GWT e HTML5
Ely Fernando do Prado1
Figura 1: Logotipos do
Google Web Toolkit
e do HTML 5
Resumo
O advento da tecnologia do HTML 5 tem aberto um novo mercado de jogos para
internet, onde os usuários podem interagir com o game através de diferentes equipamentos,
como computadores, tablets e celulares sem a necessidade de instalação prévia da aplicação
ou mesmo algum plug-in. Por outro lado o framework Google Web Toolkit tem se mostrado
uma boa alternativa para desenvolvimento de aplicações ricas para internet, utilizando a
linguagem Java para gerar códigos HTML, CSS e JavaScript. Assim este trabalho tem por
objetivo apresentar o framework GWT como solução para o desenvolvimento de jogos para
1 Departamento de Computação, Universidade Federal de São Carlos (UFSCar), São Carlos, SP; Libertas
Faculdades Integradas, São Sebastião do Paraíso, MG; Universidade de Franca (Unifran), Franca, SP. Authors’
contact: ely.prado@dc.ufscar.br

Sumário
internet em HTML5, demonstrando todos os passos necessários para codificação de um

game loop, animações e interação com o usuário.
Keywords: GWT. HTML5. Jogos. Canvas.
1. Introdução
Atualmente estamos presenciando um grande crescimento na demanda por jogos
para internet. Outro acontecimento que está em bastante evidencia hoje é o surgimento e
amadurecimento do HTML 5, que tem possibilitado a criação de jogos que rodam direto no
navegador de maneira leve e prática.
A principal motivação para este tutorial é o grande crescimento no mercado de jogos
para internet. O surgimento do HTML 5 permitiu que passássemos a desenvolver aplicações
complexas para internet, sem ter que depender de algum plug-in específico. Além disso,
aplicações desta natureza podem ser executadas em qualquer dispositivo que possua
internet, como computadores, tablets e celulares de qualquer sistema operacional atual.
Um bom exemplo que tem alcançado bastante sucesso entre o público são os jogos
adicionados no logotipo do Google, chamados doodles. Os doodles games são adicionados
ao site de pesquisa do Google em comemoração a alguma data ou evento especial, e são
jogáveis no próprio site.
Graças a grande experiência alcançada pelos engenheiros da Google no setor de
aplicações ricas para internet, foi criado por eles o framework Google Web Toolkit (GWT),
que tem facilitado muito criação de aplicações complexas na web, incluindo os jogos.
O objetivo deste tutorial é apresentar o framework GWT como uma alternativa
para o desenvolvimento de jogos para internet. Para isso será apresentado como se dá o
desenvolvimento de um jogo nesta tecnologia, sendo um jogo com poucas funcionalidades,
porém o suficiente para dar os primeiros passos neste framework.
2. HTML 5
O padrão HTML5 complementa as capacidades das normas existentes no HTML com
vários novos recursos. Embora o HTML5 seja um padrão web de propósito geral, muitos
dos novos recursos são destinados diretamente para tornar a Web um lugar melhor para
aplicações web com estilo desktop.
Dentre os novos recursos estão a capacidade das aplicações executarem em modo
off-line e de armazenar dados localmente no computador ou dispositivo. Um recurso
importante, especialmente quando se trata de desenvolvimento de jogos é o elemento
Canvas, que oferece uma tela de desenho 2D, permitindo o desenho de formas gráficas,
imagens e texto em tempo de execução. Outros recursos disponibilizados pelo HTML5 são
para permitir que arquivos de mídia (áudio e vídeo) sejam executados no navegador sem
necessidade de plug-in externo, também há elementos para carregamento de dados de

Sumário
forma assíncrona e apoio para eventos de arrastar e soltar. Além dos recursos citados, a
especificação HTML5 define inúmeros outros acréscimos, mas muitas destas especificações,
bem como a especificação do HTML5 em si, estão ainda em definição, de modo que na
versão final os seus detalhes podem variar. (Taivalsaari e Mikkonen, 2011)
Para o desenvolvimento de jogos o HTML por si só não é suficiente. O HTML é uma
linguagem de marcação, que permite incluir elementos em uma página, como campos de
formulário, texto, imagens, canvas, etc. Mas todos esses elementos são estáticos. Para superar
as limitações do HTML podemos utilizar o Javascript, pois a ação toda precisa ser escrita em
uma linguagem de programação. Javascript é uma linguagem de programação poderosa,
com sintaxe baseada em C++, porém com suporte apenas parcial à orientação a objetos.
Javascript é uma linguagem interpretada, sendo assim sua velocidade de execução e sua
compatibilidade depende da máquina interpretadora que o navegador possui. (Nörnberg,
2011)
3. Google Web Toolkit

O framework GWT (Google Web Toolkit) foi criado para facilitar o desenvolvimento
de aplicações ricas para web fornecendo uma camada de abstração, que esconde os detalhes
do Javascript e também as diferenças entre os ambientes específicos dos navegadores. Toda
aplicação é escrita utilizando a linguagem Java, e o framework GWT traduz este código
em JavaScript, DHTML e CSS. Ao efetuar esta compilação são geradas versões especificas
da aplicação para cada tipo de navegador, tornando a aplicação compatível com os mais
variados ambientes, e também com as diferentes versões desses navegadores. (Smeets,
Boness e Bankras, 2009)
Seu objetivo é permitir o desenvolvimento produtivo de aplicações Web de alto
desempenho sem que o desenvolvedor necessite ser um especialista nas peculiaridades de
cada navegador, XMLHttpRequest e JavaScript
GWT é um framework essencialmente para o lado do cliente (cliente-side) e dá
suporte à comunicação com o servidor através de RPCs (Remote Procedure Calls). Ele não é
um framework para aplicações clássicas da web, pois deixa a implementação da aplicação
web parecida com implementações em desktop. Para quem está habituado a desenvolver
aplicações desktop, especialmente na linguagem Java se sente familiarizado com o uso do
framework GWT. (Geary, 2008)
O GWT é utilizado por muitos produtos do Google, incluindo o Google Wave e Google
AdWords. Tem sido utilizado também para a construção de jogos para internet, como por
exemplo, a versão web do jogo Angry Birds.
GWT é de código aberto, totalmente gratuito, e utilizado por milhares de
desenvolvedores ao redor do mundo. Está disponível sob a Licença Apache v. 2.0,
concedendo-lhe uma licença perpétua, mundial, não exclusiva, sem nenhum custo, isenta
de royalties, direitos autorais irrevogáveis para reproduzir, preparar trabalhos derivados,
publicamente exibir, executar publicamente, sublicenciar e distribuir o trabalho.

Sumário
Já que GWT compila código Java para JavaScript, é importante questionarmos

quais são as vantagens de se desenvolver a aplicação em Java com GWT, ao invés de
escrever diretamente em código JavaScript. A vantagem mais óbvia está no fato de GWT
criar JavaScript perfeitamente compatível com os diferente navegadores, sendo assim não
precisamos escrever estruturas condicionais para cuidar das diferenças do navegadores.
Mas Dwyer, 2008, ainda faz a seguinte afirmação: “há três áreas específicas em que o GWT
supera o JavaScript: escalabilidade, suporte à refatoração, e familiaridade.”. Isso se deve ao
fato de GWT utilizar a linguagem Java, que apesar de seu nome sugerir o contrário, Java
tem mais diferenças com JavaScript do que igualdades.
3.1 Ambiente de Desenvolvimento

Como o framework GWT executa sobre a plataforma Java, você pode preparar seu
ambiente de desenvolvimento nos principais sistemas operacionais disponíveis (Windows,
Linux ou MacOS), porém é necessário ter instalado o Kit de Desenvolvimento Java em seu
computador. Além disso, é requisito básico ter feito download e descompressão do Google
Web Toolkit SDK. Ambas ferramentas citadas podem ser encontradas nos links a seguir:
• Java SE Development Kit (JDK):
http://java.sun.com/javase/downloads/
• Google Web Toolkit SDK:
https://developers.google.com/web-toolkit/download
Apesar de não ser um pré-requisito, é bastante interessante utilizar uma IDE de
desenvolvimento. Dentre as principais IDEs utilizadas para desenvolvimento de aplicações
Java, podemos destacar o Eclipse que possui um plug-in oficial da Google para trabalhar
com GWT. Tanto a IDE como o plug-in para desenvolver em GWT podem ser encontrados
no link a seguir:
• IDE Eclipse: http://www.eclipse.org/downloads/
• Google Plugin for Eclipse: http://dl.google.com/eclipse/plugin/4.2
Para este tutorial foi utilizado a versão 4.2 do Eclipse, apelidada de Juno.
Para configurar o plug-in do GWT no Eclipse, basta clicar no menu do Eclipse “Help”,
logo em seguida em “Install New Software”. Depois clique no botão “Add” e digite no campo
“Location” o endereço http://dl.google.com/eclipse/plugin/4.2 e clique em “Ok”. Marque os
itens “Google Plugin for Eclipse”, “GWT Designer for GPE” e “SDKs”.Clique no botão “Next”,
aguarde o download ser terminado e clique em “Finish”.
Com essas etapas, o Eclipse está preparado para ser utilizado com ferramente de
desenvolvimento para o framework GWT.

Sumário
3.2 Objeto Canvas

O objeto Canvas representa o elemento de mesmo nome do HTML 5, e pode ser
utilizado para processamento de gráficos em tempo de execução. Uma característica
importante deste elemento é que ele consegue redimensionar seu conteúdo para adequar à
resolução do navegador do usuário. Pode ser executado na maioria dos navegadores atuais,
porém em versões antigas de navegadores ele não é aceito, por se tratar de uma tecnologia
recente.
3.2.1 Principais métodos
setCoordinateSpaceWidth (int width)

Argumento:
• width: largura em pixels
Descrição:
• Define a largura do espaço interno do Canvas, fazendo com que independente da
resolução do dispositivo do usuário, as coordenadas dos objetos sejam sempre as mesmas.
setCoordinateSpaceHeight(int height)
Argumento:
• height: altura em pixels
Descrição:
• Define a altura do espaço interno do Canvas.
setWidth (String width)

Argumento:
• width: largura do objeto, em unidades de CSS (por exemplo: “10px”, “1em”)
Descrição:
• Define a largura do objeto Canvas na página.
setHeight(String height)
Argumento:
• height: altura do objeto, em unidades de CSS (por exemplo: “10px”, “1em”)
Descrição:
• Define a altura do objeto Canvas na página.

Sumário
setFocus(boolean focused)
Argumento:
• focused: indica se o objeto receberá o foco ou se perde o foco.
Descrição:
• Indica o objeto como focado ou não focado. Apenas um objeto da página pode ter
o foco por vez, e este é o que receberá todos os eventos de teclado.
3.3 Objeto Context2d

O objeto Context2d faz referência ao elemento de mesmo nome do HTML 5. Refere-
se ao contexto de renderização, podendo ser utilizado para desenhar formas e imagens no
objeto Canvas.
setFillStyle(String fillStyleColor)
Argumento:
• fillStyleColor: cor como uma String no formato CssColor.
Descrição:
• Define a cor de preenchimento dos elementos que forem desenhados em seguida.
fillRect (double x, double y, double w, double h)

Argumentos:
• x: posição horizontal do canto superior esquerdo do retângulo
• y: posição vertical do canto superior esquerdo do retângulo
• w: largura do retângulo
• h: altura do retângulo
Descrição:
• Desenha um retângulo.
drawImage (ImageElement image, double dx, double dy)

Argumentos:
• image: imagem no formato de um objeto ImageElement

Sumário
• dx: posição horizontal do canto superior esquerdo da imagem

• dy: posição vertical do canto superior esquerdo da imagem
Descrição:
• Desenha uma imagem previamente carregada.
3.4 Objeto Timer

O objeto Timer é um temporizador, que tem por finalidade fazer chamada automática
a um método qualquer em um tempo pré-programado.
scheduleRepeating (int periodMillis)

Argumento:
• periodMillis: o tempo de espera em milissegundos entre cada repetição da chama
do método.
Descrição:
• Ativa um temporizador que decorre repetidamente com um tempo determinado.
4. Desenvolvimento de Projeto
Para facilitar a compreensão das ferramentas aqui citadas, será descrito neste capitulo
um guia passo a passo de como se dá o desenvolvimento de um jogo em HTML 5 utilizando
o framework GWT.
4.1 Projeto Inicial

Para criar uma nova aplicação GWT no Eclipse, basta clicar no menu “File -> New ->
Project”. Selecione o tipo de projeto “Google -> Web Application Project” e clique em “Next”.
Digite o nome do projeto e o nome do pacote padrão. Desmarque a opção “Use Google
App Engine” e também “Generate project sample code” para que não seja criada nenhuma
classe de exemplo no projeto, deixando assim o projeto apenas com as configurações iniciais
básicas. Por fim clique no botão “Finish”.
O próximo passo após a criação do projeto é criar um novo Módulo GWT clicando
o botão direito do mouse no projeto e depois na opção “New->Other”. Selecione o item
“Google Web Toolkit->Module” e clique em “Next”. Informe o nome do pacote e do modulo,

Sumário
preferencialmente coloque o mesmo nome de pacote mencionado na criação do projeto e

clique em Finish.
Em seguida configure uma classe java como ponto de entrada do sistema. Para isso,
clique com o botão direito do mouse no pacote “client”, que foi criado automaticamente na
criação do módulo. Vá em “New->Other”, selecione o item “Google Web Toolkit->Entry Point
Class” e clique no botão “Next”. Preferencialmente digite o nome da classe como “Main” e
clique em “Finish”.
Um recurso importante no projeto é a pasta ‘war’, onde estarão localizados todos os
recursos externos do projeto como imagens, folhas de estilo e arquivos HTML. Nesta pasta
também deverá estar uma página HTML que irá iniciar a aplicação. Para criar este arquivo
clique com o botão direito do mouse na pasta war e depois em “New->Other” e selecione
o item “Google Web Toolkit->HTML Page”. Digite o nome do arquivo como ‘index’ e clique
em “Finish”.
Por fim, é necessário fazer uma pequena configuração para que o aplicativo inicialize
o módulo corretamente. Supondo que o módulo criado se chame ‘jogo’, abra o arquivo
‘jogo.gwt.xml’ localizado no pacote principal e adicione um apelido ao módulo editando
sua tag inicial como:
<module rename-to="modulo">
Para editar o arquivo XML é necessário clicar na aba “source” na parte inferior do
Eclipse e editar a linha mencionada, que é a terceira linha do código.
Edite também o arquivo index.html localizado na pasta war, para que sua chamada
ao módulo gwt, na sexta linha, fique da seguinte forma:
<script type="text/javascript"
language="javascript"
src="modulo/modulo.nocache.js"></script>
Após essas tarefas podemos executar o aplicativo, porém não será mostrado nada no
navegador ainda, pois teremos que codificar a classe Main.
Ao abrir a aplicação pela primeira vez é solicitada a instalação de um plugin no
navegador. Este plugin é utilizado para depuração do código em tempo de desenvolvimento,
e não será solicitado quando o usuário acessar a aplicação final compilada.
Todo esse processo de configuração do projeto poderia ser simplificado apenas
deixando a opção “Generate project sample code” marcada, porém isso faria com que fosse
gerada uma série de códigos desnecessários para nossa aplicação.
Como o objetivo deste projeto é desenvolver um jogo em HTML 5, sua codificação
deve ser iniciada com o acréscimo de um elemento Canvas e definição de seus parâmetros.
Primeiro deve ser feita uma verificação se o navegador do usuário dá suporte ao elemento

Sumário
Canvas do HTML 5. Depois devem ser removidas a margem e a barra de rolagem da página.
Por fim são definidos o tamanho e a resolução do elemento Canvas e logo em seguida
adiciona-o na página do usuário, conforme mostrado no quadro 1.
public class Main implements EntryPoint {

private Canvas canvas;
private Context2d context;
private static final int WIDTH = 800;
private static final int HEIGHT = 600;

@Override
public void onModuleLoad() {
canvas = Canvas.createIfSupported();
if (canvas == null) {
RootPanel.get().add(
new Label(“Navegador sem suporte ao
Canvas”));
return;
}
Window.setMargin(“0px”);
Window.enableScrolling(false);
canvas.setWidth(Window.getClientWidth() +
“px”);
canvas.setHeight(Window.getClientHeight() +
“px”);
//define resolução do objeto canvas
canvas.setCoordinateSpaceWidth(WIDTH);
canvas.setCoordinateSpaceHeight(HEIGHT);
//adiciona o elemento na interface
RootPanel.get().add(canvas);
context = canvas.getContext2d();
}
}
Quadro 1 – Configurações Iniciais o Projeto
4.2 Game Loop

Os jogos são dirigidos por um loop que executa uma série de tarefas a cada frame,
construindo a ilusão de um mundo animado. No caso de um jogo que roda a 30 frames por
segundo, cada execução das tarefas de um frame devem ser feitas em 33,3 milissegundos.
(Rabin, 2012).
Para conseguir executar este loop no tempo previsto, pode-se utilizar o objeto Timer,
o qual controlará o tempo de execução de cada frame. A principio as duas tarefas executadas
pelo frame serão desenvolvidas nos métodos “update” e “draw”. O método “update” é
responsável pode atualizar a posição dos objetos do jogo, assim como as transformações
necessárias para prover os efeitos de animação. O método “draw” é responsável por
renderizar as imagens no objeto canvas. Pode-se ver a estrutura de um game loop no

Sumário
Quadro 2, onde o método “update” ainda não possui nenhuma funcionalidade efetiva e o
método “draw” apenas pinta uma cor de fundo no objeto canvas. O restante do código será
demonstrado nos próximos capítulos.

private Timer timer;
@Override
canvas = Canvas.createIfSupported();

if (canvas == null) {
RowotPanel.get().add(new La-
bel(“Navegador sem suporte ao Canvas”));
return;
}
Window.setMargin(“0px”);
Window.enableScrolling(false);
canvas.setWidth(Window.getClientWid-
th() + “px”);
canvas.setHeight(Window.getClientHeight() +
“px”);
canvas.setCoordinateSpaceWidth(WID-
TH);
canvas.setCoordinateSpaceHeight(HEI-
GHT);
RootPanel.get().add(canvas);
context = canvas.getContext2d();

timer = new Timer() {
@Override
public void run() {
update();
}
};
timer.scheduleRepeating(33);
}
public void update() {

//lógica do jogo

draw();
}
public void draw() {

//desenha o fundo
CssColor cor;
cor = CssColor.make(“r-
gba(0,50,255,1)”);
context.setFillStyle(cor);
context.fillRect(0, 0, WIDTH, HEI-
GHT);
}
}
Quadro 2 – Game Loop

Sumário
4.3 Animação
Já que GWT permite a codificação da aplicação na linguagem Java, nada mais justo
que tirar proveito dos recursos da orientação em objetos para desenvolver seu game. Uma boa
metodologia é criar uma classe java para cada tipo funcionalidade, pensando nas técnicas de
reuso que a linguagem disponibiliza.
Desta forma, para criar um objeto retangular que será desenhado no jogo, pode-se
definir atributos encapsulados para determinar sua posição nos eixos horizontal e vertical,
além de declarar um método capaz de fazer a detecção da colisão entre outro retângulo. O
resultado desta Classe Java pode ser visto no Quadro 3.
public class Retangulo {

private int x;
private int y;
private int height;
private int width;
public Retangulo(int x, int y, int height,
int width) {
this.x = x;
this.y = y;
this.height = height;
this.width = width;
}
public int getX() {return x; }
public void setX(int x) {
this.x = x;
}
public int getY() {return y; }
public void setY(int y) {
this.y = y;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public boolean colide(Retangulo c) {
if ((c.getX()+c.getWidth() >= getX())
&& (c.getX() <= getX() + this.width)
&& (c.getY() + c.getHeight() >=
getY())
&& (c.getY() <= getY() + this.hei-
ght)){
return true;
} else {
return false;
}
}
}
Quadro 3 – Objeto Retangulo

Sumário
Desta forma já podemos construir toda a lógica do jogo. Como a ideia é apenas
apresentar a tecnologia, iremos demonstrar o desenvolvimento de um jogo simples, apenas
com as classes Main e Retangulo. Assim a estrutura do jogo deve ficar igual à mostrada na
figura 2.
Figura 2 – Exemplo de imagens
O escopo do projeto ficará então como sendo um jogo onde o usuário irá controlar
uma plataforma, a qual irá rebater uma bola em movimento. A partir deste exemplo o
desenvolvedor poderá facilmente estender suas funcionalidades para tornar o jogo parecido
com um Pong ou Breakout mostrados na figura 3. Podem ser utilizados gráficos com ótima
qualidade já que as imagens que serão inseridas são no formato PNG, bem diferente do que
se tinha na época em que esses dois jogos citados foram criados.
Figura 3 – Jogos Pong (1972) e Breakout (1976)
Para continuar o desenvolvimento, deve ser declarado dois atributos retângulo na

classe Main, um para a plataforma base e outro para a bola. Também declare atributos
para armazenar a direção a qual a bola deverá se movimentar. A cada frame, incremente a
posição da bola para dar a ilusão de movimento, e desenhe os dois retângulos na tela.
Sobre a movimentação da bola, é importante que ela mude de direção sempre que
colidir com alguma das extremidades da tela, ou mesmo com a plataforma base também.
Algumas estruturas condicionais podem realizar esta tarefa, além de fazerem a validação,
caso a bola encontre a extremidade inferior da tela informando ao usuário que ele perdeu
o jogo.
Considerando os critérios mencionados, a classe Main deverá ficar conforme está
mostrado no quadro 4.

Sumário

private Timer timer;
private Retangulo base
= new Retangulo(350, 550, 25, 100);
private Retangulo bola
= new Retangulo(0, 0, 25, 25);
private int dirX = 3;
private int dirY = 3;
@Override
public void onModuleLoad() {...
public void update() {

bola.setX(bola.getX()+dirX);
bola.setY(bola.getY()+dirY);
if (bola.getX()+bola.getWidth()>=WIDTH) {
dirX *= -1;
}
if (bola.getX()<=0) {
dirX *= -1;
}
if (bola.getY()<=0) {
dirY *= -1;
}
if (base.colide(bola)) {
dirY *= -1;
}
if (bola.getY()+bola.getHeight()>=HEIGHT)
{
Window.alert(“Você Perdeu!”);
bola.setX(0);
bola.setY(0);
dirX = Math.abs(dirX);
dirY = Math.abs(dirY);
}

draw();
}
//desenha fundo
CssColor cor;
cor = CssColor.make(“rgba(0,50,255,1)”);
context.fillRect(0, 0, WIDTH, HEIGHT);

//desenha bola e base
cor = CssColor.make(“rgba(0,255,50,1)”);
context.fillRect(bola.getX(), bola.getY(),
bola.getWidth(), bola.getHeight());
context.fillRect(base.getX(), base.getY(),
base.getWidth(), base.getHeight());
}
}
Quadro 4 – Animação

Sumário
4.4 Interação por Teclado

Em se tratando de interação do usuário com o jogo, uma das formas muito utilizadas é a
interação por teclado. No exemplo apresentado neste tutorial, vamos controlar a plataforma
base com as setas do teclado para direita e para esquerda. Para esta tarefa foram declaradas
duas variáveis booleanas, as quais indicarão o estado de cada tecla. Também foi criado
um método chamado ‘initKeyHandlers’ responsável por inicializar a captura das ações de
pressionar alguma tecla (KeyDownHandler) e de soltar alguma tecla (KeyUpHandler).
Através das variáveis de estado para as setas esquerda e direta do teclado, podemos
movimentar a plataforma base nesses mesmos sentidos. Esta tarefa é realizada no método
“update” conforme pode ser visto no Quadro 5.

...

private boolean keyLeft = false;
private boolean keyRight = false;

@Override
...
initKeyHandlers();
canvas.setFocus(true);
}

public void initKeyHandlers() {
canvas.addKeyDownHandler(
new KeyDownHandler() {
@Override
public void onKeyDown(KeyDownEvent event)
{
int key = event.getNativeKeyCode();
if (key == 37) {
keyLeft = true;
} else if (key == 39) {
keyRight = true;
}
}
});
canvas.addKeyUpHandler(
new KeyUpHandler() {
@Override
public void onKeyUp(KeyUpEvent event) {
int key = event.getNativeKeyCode();
if (key == 37) {
keyLeft = false;
} else if (key == 39) {
keyRight = false;
}
}
});
}

Sumário
public void update() { ...

if ((keyLeft) && (base.getX()>0)) {
base.setX(base.getX()-10);
}
if ((keyRight) && (base.getX()+base.ge-
tWidth()<WIDTH)) {
base.setX(base.getX()+10);
}

draw();
}
public void draw() { ...
}
}
Quadro 5 – Interação por Teclado
4.5 Interação por Mouse e Toque

Frequentemente o teclado pode não ser a única forma utilizada para interação do
usuário com o jogo, podendo este utilizar o mouse ou até mesmo o toque em dispositivos
que disponibilizam tal entrada.
Quando estamos tratando de um jogo para internet, temos que ter a consciência
de que este aplicativo pode ser acessado por uma diversa quantidade de dispositivos,
como computadores, celulares, tablets e até mesmo videogames. Portanto, tratar outros
tipos de entrada, como mouse ou toque passa a ser uma exigência do jogo, caso queira ter
compatibilidade com todos esses dispositivos.
No framework GWT, o mouse e o toque são tratados por métodos distintos. Sendo
assim, vamos criar um método chamado initMouseHandlers, para cuidar destes tipos de
entrada. A intenção é movimentar a plataforma base do jogo de acordo com a posição
do mouse ou do toque. Muito cuidado ao atribuir a posição da base, pois o objeto Canvas
estará na resolução 800x600 independente da resolução e tamanho do navegador, porém o
mouse ou toque retornarão a posição relativa ao dispositivo. Sendo assim deve ser realizado
um calculo de conversão como mostrado no Quadro 6.

...
@Override
...
initMouseHandlers();
}
public void initKeyHandlers() {...
public void initMouseHandlers() {
canvas.addMouseMoveHandler(new Mou-
seMoveHandler() {
@Override
public void onMouseMove(
MouseMoveEvent event) {
int x = event.getX();

Sumário
x = x*WIDTH/Window.getClientWid-
th();
base.setX((x-base.getWidth()/2));
}
});
canvas.addTouchMoveHandler(
new TouchMoveHandler() {
@Override
public void onTouchMove(TouchMoveE-
vent event) {
int x = event.getTouches().get(0).
getClientX();
x = x*WIDTH/Window.getClientWid-
th();
base.setX((x-base.getWidth()/2));
}
});
}
public void update() {...
public void draw() {...
}
Quadro 6 – Interação por Mouse e Toque
4.6 Imagens
A última etapa deste tutorial se refere ao uso de imagens no jogo, ao invés de
simplesmente desenhar formas geométricas. É aconselhável que seja usado o formato de
imagens PNG, devido ao seu ótimo algoritmo de compressão.
Desenhe no editor de imagens de sua preferência uma figura para a bola, na largura
de 25px e altura de 25px. Depois desenhe uma figura para a plataforma base com largura de
100px e altura de 25px. Salve ambas figuras na pasta ‘war’ do seu projeto.
Para utilizar as imagens, deverá ser declarado na classe Main, objetos do tipo
ImageElement, os quais terão funcionalidade de carregar as imagens para que sejam
desenhadas no objeto Canvas. O código para tal tarefa pode ser visto no Quadro 7.

...

private ImageElement imgBola = ImageEle-
ment.as(new Image(“bola.png”).getElement());
private ImageElement imgBase = ImageEle-
ment.as(new Image(“base.png”).getElement());

@Override
public void onModuleLoad() {...
public void initKeyHandlers() {...
public void initMouseHandlers() {...
public void update() {...
//desenha fundo
CssColor cor;
cor = CssColor.make(“r-
gba(0,50,255,1)”);

Sumário
context.fillRect(0, 0, WIDTH, HEI-
GHT);

//desenha bola e base
context.drawImage(imgBase, base.
getX(), base.getY()); context.drawImage(im-
gBola, bola.getX(), bola.getY());
}
}
Quadro 7 – Renderização e imagens
Após a inserção das imagens o jogo fica semelhante ao que está mostrado na Figura
4. Caso queira fazer animações, basta trocar as imagens a cada frame, o que torna o visual
do jogo bem mais agradável. Para isso pode ser utilizada a técnica de sprites. Outra sugestão
interessante é o uso de uma imagem de fundo, que pode ser desenhada da mesma forma
que as imagens da base e da bola.
Figura 4 – Exemplo de imagens
5. Perspectivas
O objetivo deste tutorial foi apresentar o framework GWT como alternativa para o
desenvolvimento de jogos para internet. Percebemos que este jogo pode ser implementado
com facilidade e que o framework GWT proporciona um bom ambiente de desenvolvimento
e uma boa organização do código.
A partir dos conceitos demonstrados aqui, este jogo pode ser estendido, aumentando
sua complexidade e melhorando sua jogabilidade. Com os recursos proporcionados pela
programação orientação a objetos, pode-se criar uma aplicação com muitas linhas de código,
sem perder a organização do projeto. Estes recursos também proporcionam a utilização de
técnicas de reuso do código, como encapsulamento, herança e outros.
Apesar do HTML 5 ser uma tecnologia recente já é possível desenvolver jogos
com qualidade e a tendência é melhorar ainda mais, tanto na compatibilidade com os
navegadores, quanto na velocidade de renderização proporcionado pelos mesmos.

Sumário
Ainda poderemos ter alterações no que se refere ao HTML 5 e até mesmo nas técnicas
para desenvolvimento de jogos para internet, já que o consórcio internacional W3C ainda
não homologou oficialmente esta linguagem. Mas o framework GWT tem se adaptado bem
às ultimas mudanças e é de interesse da Google continuar a manter o framework o mais
atualizado possível, continuando a nos proporcionar compatibilidade garantida com os mais
diversos navegadores da internet.
Referências
Smeets, B., Boness U. e Bankras R., 2009. Programando Google Web Toolkit, Rio de
Janeiro: Alta Books, 1a edição.
Geary, D., 2008. Google Web Toolkit solutions. Boston: Pearson.
Dwyer. J., 2008. Pro Web 2.0 Application Development with GWT. New York: Apress.
Taivalsaari, A. e Mikkonen, T., 2011. The Web as an Application Platform: The Saga
Continues. 37th EUROMICRO Conference on Software Engineering and Advanced
Applications.
Nörnberg, L. HTML 5 – futuro dos jogos para web. Disponível em <http://abrindoojogo.

com.br/html-5-futuro-dos-jogos-para-web> Acessado em setembro, 2011.
Google Web Toolkit API Reference. Disponível em <http://google-web-toolkit.googlecode.

com/svn/javadoc/2.4/index.html> Acessado em setembro, 2011.
Google Web Toolkit. Disponível em <https://developers.google.com/web-toolkit/>

Acessado em setembro, 2011.
Rabin, S., 2012. Introdução ao desenvolvimento de games, São Paulo: Cengage, 2ª

Edição.

Sumário
Introdução ao Unity
Jay Clei Garcia dos Santos1
Resumo
Este tutorial tem como objetivo demonstrar a facilidade de criação de um nível de
jogo em primeira pessoa (First Person Shooter) desde o zero.
Introdução
A Unity é uma ferramenta de desenvolvimento de jogos 2D / 3D multiplataforma que
tem como principais características a facilidade de uso, rápida prototipagem e integração
com ferramentas externas como Maya, 3D Studio, Photoshop, Blender, entre outras.
O objetivo da empresa é democratizar o desenvolvimento de jogos. Sua facilidade
de uso e preço acessível fizeram com que a Unity atingisse mais de 50% de penetração no
mercado de desenvolvimento mobile mundial.
Hoje a Unity conta com 1,5 milhões de usuários registrados no mundo, desde
desenvolvedores amadores fazendo um jogo em seu tempo livre, até grandes empresas
como Electronic Arts, BigPoint e Nintendo.
Conceitos básicos
OBS.: Todos os materiais e conteúdos utilizados neste tutorial podem ser baixados no link
http://tinyurl.com/sbgames-unity.
1 Unity Technologies.

Sumário
OBS. 2: Na parte de animação do robô (“8. Criando um inimigo”) é utilizado o sistema de

animação Mecanim, presente na nova versão 4.0 do Unity. Todo o resto do tutorial pode
ser feito na versão 3.x
1. Criando o Projeto
Caso você ainda não tenha o Unity instalado em sua máquina, você pode baixá-lo em
http://unity3d.com/unity/download/.
Ao iniciar o Unity clique em File -> New Project defina onde seu projeto vai ser salvo
e na janela “Import the following packages” selecione Character
Controller, Skyboxes e Water (Pro Only) (Fig. 1) e clique em “Create Project”.
OBS.: O package Water (Pro Only) está disponível apenas na versão Pro do Unity. Ao
baixar do site você tem 30 dias de trial da versão Pro. Caso seu trial tenha expirado, utilize
a Water (Basic).
Fig. 1: Janela “Project Wizard”
2. Criando o personagem de primeira pessoa

Ao terminar a criação do projeto, a tela abaixo é exibida (Fig. 2)
Fig. 2: Tela inicial do projeto.

Sumário
Clique na aba “Game”, arraste ela um pouco para baixo e para a direita para
separarmos ela da janela “Scene” (Fig. 3)
Fig. 3: Tela inicial com a janela “Game” separada.
Agora vamos criar o controle de primeira pessoa. Vamos iniciar criando um plano,
que vai servir de chão. Clique em “Game Object -> Create Other > Plane”. Após acrescentar
o plano, clique na tela scene e aumente o zoom (usando o mouse scroll) para deixar o plano
mais próximo para editar. Expanda as pastas “Standard Assets” e “Character Controllers”,
clique e arraste o “First Person Controller” para a janela “Scene” e coloque-o sobre o plano
(Fig. 4).
Fig. 4: Plano e controle de primeira pessoa acrescentados
Clique o botão “Play” na parte central no topo da tela e clique na janela “Game”.
Você agora pode controlar o personagem usando W, S, A e D e espaço para pular. Você
pode notar também que a gravidade já está atuando na cena: Caminhe com o personagem
até além do plano criado e você vai notar que o personagem vai cair. Na janela “Inspector”
se você expandir a opção “Movement” dentro de “Character Motor (Script)” você têm todos
os parâmetros de movimento do personagem, que podem ser configurados diretamente no
editor, sem a necessidade de alterar código-fonte (Fig. 5).

Sumário
Fig. 5: Parâmetros de configuração de movimento.
3. Acrescentando elementos a cena: Luz, objetos, Skybox e texturas

A cena que criamos está escura. Vamos agora adicionar iluminação. Clique em “Game
Object -> Create Other -> Directional Light”. Você vai notar que o chão da cena já irá ficar
muito mais iluminado. Por enquanto vamos manter a luz assim (Fig. 6).
Fig. 6: Mesma cena, agora iluminada.
Vamos agora criar duas plataformas. Clique em “Game Object -> Create Other ->
Cube”. O Cubo vai ser criado aproximadamente na mesma posição que o personagem. Na
tela “Scene” clique na seta vermelha e arraste o cubo para o lado. Quando a tela “Scene”
está com esta funcionalidade ativada você pode mover objetos através da cena. Clique
também na seta verde e arraste um pouco o cubo para cima.
No canto superior esquerdo da tela existem quatro botões com as funcionalidades da
tela “Scene”, da esquerda para a direita:
• Primeiro Botão (mão): Arrasta a cena inteira para facilitar a visualização.
• Segundo Botão (tooltip: move the selected objects): Move o objeto dentro da
cena.
• Terceiro Botão (tooltip: rotate the selected objects): Rotaciona o objeto na cena.
• Quarto Botão (tooltip: scale the selected objects): Altera o tamanho do objeto
na cena.

Sumário
Os atalhos para este botões são Q, W, E e R, respectivamente. Após arrastar o cubo

vamos alterar suas dimensões, transformando-o em uma plataforma e colocando-o um
pouco acima do chão. Uma vez feito isso digite CTRL+D (ou command+D no MacOS)
para duplicar a plataforma e coloque a nova plataforma um pouco mais a frente e um pouco
mais alto da primeira plataforma (Fig. 7).
Fig. 7: Plataformas criadas.
Clique em “Play” e mova seu personagem para cima das plataformas. Se as

plataformas estiverem muito altas e você não conseguir alcança-las pulando, diminua
um pouco a distância entre elas. Agora vamos adicionar um Skybox (uma imagem que
envelopa a cena e da sensação de profundidade). Clique em “Edit -> Render Settings”, uma
série de parâmetros serão exibidos na janela “Inspector”, clique no botão a direita da opção
“Skybox Material” e selecione qualquer uma das opções apresentadas no pop-up. Uma vez
selecionado o material feche o pop-up (Fig. 8).
Fig. 8: Cena com o Skybox “Sunny 2 Skybox” aplicado.
Porém os objetos continuam apenas brancos, o próximo passo é adicionar uma textura
aos nossos pisos. Clique com o botão direito na janela “Project”, selecione “Create -> Folder”
e crie uma pasta “Textures”. A criação de pastas não é necessária mas é recomendada para
a organização do projeto.

Sumário
Arraste o arquivo “Sand.psd” para dentro da pasta “Textures”, uma vez feito isso arraste o
“Sand.psd” de dentro da pasta “Textures” para cima do plano (Fig. 9).
Fig. 9: Plano com a textura de areia aplicada.

Repare que as plataformas estão sem textura.
No Unity você também pode trabalhar com texturas procedurais. Primeiro crie um
novo cubo (como já feito anteriormente) e altere as dimensões e posição para que ele fique
como um muro saindo do chão de areia. Arraste o arquivo “bricks_008.sbsar” para dentro
da pasta “Textures” na janela “Project”, expanda o object “bricks_008” criado e arraste o
“bricks_008” para cima do muro na janela “Scene” (Fig. 10).
Fig. 10: Muro com a textura procedural aplicada. Você pode ver qual
o “bricks_008” que deve ser arrastado indicado na janela “Project”.
Com o “bricks_008” selecionado no “Project” você pode ver na janela “Inspector”

diversos parâmetros que podem ser alterados para modificar a textura (Fig. 11).

Sumário
Fig. 11: Muro após alterar alguns parâmetros da textura. Compare com o muro da Fig. 10.
4. Acrescentando elementos a cena: Modelos 3D e texturas

Vamos substituir nossas plataformas brancas e sem forma por modelos 3D. Na janela
“Projects” crie uma nova pasta chamada “3D Models”. Arraste os arquivos “platform_LOD0.
fbx” e “platform_DIF.tga” para dentro da pasta “3D Models”. O arquivo .fbx é o modelo 3D
e o arquivo .tga é a textura a ser aplicada a esse modelo. Como o nome dos dois é igual a
textura é imediatamente aplicada ao modelo. Se você clicar no objeto “platform_LOD0”
dentro da pasta “3D Models” você já vai ver na janela “Inspector” o modelo com a textura,
altere o “Scale Factor” dentro da janela Inspector para 0.5 (Fig. 12).
Fig. 12: Modelo 3D da plataforma com a textura já aplicada.

Note que o Scale Factor já foi alterado para 0.5.
Clique no objeto “platform_LOD0” e arraste-o até a janela “Scene” para acrescentar

uma plataforma a cena. Clique em Play e tente pular em cima da plataforma. Você caiu
direto por ela! O que aconteceu?
Porque apesar de você já ter o modelo 3D da plataforma ela ainda não tem uma caixa
de colisão para impedir sua queda. Vamos criar uma agora.
Selectione o objeto “platform_LOD0” na janela “Hierarchy” e clique em “Components
-> Physics -> Box Collider”. Você pode ver na janela “Scene” que uma grade verde aparece
em volta da plataforma. Clique em Play e agora você pode subir na plataforma (Fig. 13).

Sumário
Uma explicação rápida sobre a diferença entre as janelas “Project” e “Hierarchy”: A

janela “Project” mostra todos os elementos disponíveis no seu projeto, e “Hierarchy” mostra
todos os elementos que estão sendo utilizados neste exato momento na cena em que você
está trabalhando.
Fig. 13: Personagem em cima da plataforma após adição do Box Collider.

Repare na caixa verde em volta da plataforma.
Seria possível também criar um Mesh Collider na plataforma. A diferença é que o Mesh
Collider se ajusta exatamente ao modelo 3D da plataforma. A vantagem de usar um Mesh
Collider é que você não terá colisões inexistentes, principalmente nas bordas dos objetos. A
desvantagem é que o custo de processamento de um Mesh Collider é muito mais alto do que
de um Box Collider. Normalmente é recomendado utilizar Box Collider (ou um conjunto de
Box Colliders distribuídos pelo objeto) ao invés de Mesh Collider, o resultado é satisfatório e
é muito mais barato em termos de processamento.
Vamos agora criar um muro e entender como duplicar e conectar elementos. Arraste
os arquivos “EV_Wall.FBX” e “EV_Wall_DIF.tga” para a janela “Project” e clique no objeto
EV_Wall criado dentro da pasta 3D Models.
Você vai reparar que o nosso modelo está sem textura. Para aplicar uma textura a um
objeto de scroll na janela “Inspector” até o final. Uma pequena janela quadrada com o texto
“None (Texture)” vai aparecer. Arraste o objeto “EV_Wall_DIF.tga” de dentro da pasta 3D
Models para esta janela e a textura vai ser aplicada (Fig. 14).
Fig. 14: Modelo 3D EV_Wall com a textura já aplicada.

Sumário
Para trabalhar com o EV_Wall vamos limpar nossa cena um pouco. Na janela
“Hierarchy” apague todos os objetos (selecione o objeto, clique com o botão direito e
selecione “Delete”) com exceção de:
• First Person Controller
• Plane
• Directional Light
Clique em EV_Wall na janela Project e arraste para a janela Scene para adicionarmos
uma parede a cena. Agora queremos fazer com que essa parede comece exatamente em
cima do nosso chão, para fazer isso vamos usar o comando de “Vertex Lock”.
Para fazer isso, clique na parede na janela Scene e clique no botão “Move the selected
objects” no canto superior esquerdo da janela (ou use o atalho “W”). Feito isso ponha o cursor
em cima do muro e aperte a tecla “V”, você vai notar que o cubo para movimentação do
muro vai se mover para cima do cursor, e se você mover o cursor o cubo vai acompanhar.
Posicione o cursor em um dos cantos inferiores do muro, depois clique no muro e arraste.
Você vai notar que a movimentação do muro agora se dá em pulos. Isso porque com o “V”
pressionado, o vértice selecionado do muro está se conectando diretamente ao vértice do
chão mais próximo. Dessa maneira você garante que o muro está começando assim que o
chão termina (Fig. 15).
Fig. 15: Muro “preso” ao chão após o uso do comando Vertex Lock.
Podemos usar o Vertex Lock para facilmente expandir o muro. Selecione o muro na
janela “Scene” e pressione CTRL+D (ou command+D) para duplicar o objeto, feito isso
arraste o muro duplicado para o lado usando a seta verde para arrastá-lo e afaste-o do muro
original. Depois disso pressione o “V”, selecione um vértice do canto inferior e prenda-o a
um vértice do canto inferior do muro original. Repita o procedimento algumas vezes até
você se sentir confortável com esse procedimento (Fig. 16).

Sumário
Fig. 16: Muro copiado cinco vezes (Note cinco objetos

EV_Wall na janela “Hierarchy”).
Se você pressionar Shift e clicar em cada um dos muros criados na janela “Scene”,
você pode selecionar todos os muros e trabalhar com todos ao mesmo tempo.
5. Prefabs e Packages
Prefabs (de prefabricated, pré-fabricado), são objetos que você pode replicar e utilizar
diversas vezes durante seu projeto. O uso de prefabs facilita muito a criação de itens iguais
ou mesmo com comportamento similares. Vamos criar um prefab contendo o muro com
vários segmentos que criamos.
Colapse todas as pastas da janela “Project” e clique em “GameObject -> Create Empty”.
Você vai notar um novo objeto na janela “Hierarchy” chamado GameObject.
Todo objeto de um projeto Unity é um “GameObject”. É importante saber isso para a
programação de scripts pois praticamente todas as classes são herdeiras da classe GameObject.
Selecione todos os EV_Wall da janela “Hierarchy” utilizando Shift e clicando nos EV_
Wall e arraste todos para cima do GameObject recém- criado. Você vai notar que todos os
EV_Wall agora estão abaixo do GameObject, isso significa que agora todos eles são filhos
do GameObject (vamos falar mais a respeito no futuro). Agora arraste o GameObject para a
janela “Project”. Foi criado um objeto novo com um cubo como ícone. Esse cubo significa
que esse objeto é um prefab (Fig. 17).
Fig. 17: Prefab recém criado na janela “Project”.

Note no preview o muro mais extenso que criamos.

Sumário
Para entender como funcionam os prefabs, selecione o objeto chamado “GameObject”

na janela “Hierarchy” e apague-o (clique com o botão direito e selecione “Delete”). Todos os
muros da cena irão sumir. Agora clique no Prefab criado na janela “Project” e arraste para
dentro da janela “Scene“. Você vai notar que um muro extenso foi criado. Como esse prefab
está disponível no meu Projeto ele pode ser usado em qualquer cena do meu jogo.
Mas você também pode usar o prefab em outros projetos, criando um Package. Para
criar um package, clique com o botão direito no prefab GameObject na janela “Project” e
selecione “Export Package”. Um pop-up mostrando os elementos que serão inclusos no
package é exibido. Note no pop-up que além do prefab também são inclusos todos os
modelos 3D, materiais e scripts que estão associados a esses objetos (no nosso caso não
temos nenhum script associado ainda), clique em export, dê um nome ao package, defina
onde você vai salvá-lo e clique em “Save”. Será criado um arquivo .unitypackage contendo
o prefab que foi criado.
Agora esse package pode ser importado para outros projetos.
6. Importando um Package
Já temos tudo que precisamos para criar nossa fase do FPS, mas para acelerar o
processo vamos importar um arquivo .unitypackage com nossa fase já pronta.
Apague todos os elementos da cena e deixe apenas:
• First Person Controller
• Plane
Agora clique em “Assets -> Import Package -> Custom Package...” e selecione o arquivo
game_level_prefab.unitypackage e clique “Import” no pop-up. Na janela “Project” dentro de
“Game_level_and_Props -> Prefab” há um prefab chamado “Level”, arraste-o para a janela
“Scene”. Ajuste a posição do First Person Controller e do Plane dentro da janela Scene para
que o First Person Controller fique em cima de uma das plataformas e o Plane cubra toda a
parte debaixo da fase (Fig. 18).
Fig. 18: Janela Scene mostrando o First Person Controller

em cima de uma plataforma e o Plane cobrindo a fase todas.

Sumário
Já temos tudo que precisamos para criar nossa fase do FPS, mas para acelerar o
processo vamos importar um arquivo .unitypackage com nossa fase já pronta.
A cena está bastante escura, vamos ajustar a iluminação, mudando a iluminação
ambiente e acrescentando um Directional Light.
Para mudar a iluminação ambiente clique em “Edit -> Render Settings” e clique em
“Ambient Light”, e ajuste-a para aproximadamente o exibido na Fig. 19, você vai perceber
que a cena já ficará um pouco mais clara.
Fig. 19: Configuração do Ambient Light.
Agora clique em “Game Object -> Create Other -> Directional Light”, na janela
“Inspector” na sessão “Light”, mude a opção “Shadow Type” para “Soft Shadows”, e você vai
perceber que a cena ficará mais iluminada e aparecerão sombras. Após acrescentar a luz,
na janela “Inspector” altere a propriedade “Rotation” para:
- X: 50
- Y: 260
- Z: 0
Dessa maneira teremos algumas áreas de sombra que utilizaremos para a parte de
Lightprobing (Fig. 20).
Fig. 20: Fase com a Directional Light acrescentada,

note a configuração de rotação e a área de sombra abaixo do túnel.

Sumário
7. Acrescentando água, arma e animação da arma

Para acrescentar a água, na janela “Project”, na pasta “Standard Assets-> Water (Pro
Only) ou Water (Basic)”, clique em “Daylight Simple Water” e arraste-a para a tela “Scene”.
Ajuste o tamanho para cobrir toda a fase e coloque-a um pouco acima do plano original
(Fig. 21).
Fig. 21: Água acrescentada ao projeto.
Após colocar a água, vamos acrescentar uma arma ao nosso jogador. Arraste para
dentro da pasta “3D Models” na janela “Projects” os arquivos:
- bazooka.fbx
- bazooka_colormal.tga
- bazooka_normalmap.tga
Se um pop-up aparecer, pode clicar em “Fix now”. Como os arquivos já estão com
os nomes corretos, se você clicar no prefab bazooka dentro da pasta “3D Models”, na janela
inspector já será exibido o modelo 3D com a textura aplicada corretamente.
Agora clique no prefab bazooka dentro de “3D Models” e arraste-o para cima do
objeto Main Camera dentro de First Person Controller na janela “Hierarchy”. Dessa maneira
o objeto bazooka ficará dentro do Main Camera, isso significa que bazooka agora é filho de
Main Camera, e sempre que Main Camera se mover, bazooka se moverá também (fig. 22).
Fig. 22: Bazooka como filho de Main Camera na janela Hierarchy.

Sumário
Precisamos ajustar a posição da bazooka para que ela fique no canto inferior direito da
tela. Você pode ajustar manualmente através da janela “Scene”, ou então selecione bazooka
na janela “Hierarchy”, e configure o parâmetro “Position” da janela “Hierarchy” para:
- X: 0.7
- Y: -0.1
- Z: 0.7
Sua janela “Game” ficará similar a da Fig. 23.
Fig. 23: Posição da arma após ajuste da posição.
Clique em Play, você pode perceber que a animação da arma é executada apenas
uma vez e a arma pára. Isso acontece pois as duas animações associadas a esse modelo (a
animação quando a arma está “Idle” e quando a arma é disparada) estão salvas como uma
animação só. Agora vamos dividir estas animações e aplicar a animação de “Idle”. Na janela
“Project” embaixo da pasta “3D Models” clique no prefab Bazooka. Na janela “Inspector”,
procure a seção “Animations”, logo abaixo de “Split Animations” há uma lista por enquanto
vazia (Fig. 24).
Fig. 24: Seção “Animations” do prefab. A tabela está na parte debaixo da imagem.
Clique no “+” para acrescentar uma animação a lista, os parâmetros da animação são:
- Name: O nome da animação, pode manter “idle”;

Sumário
- Start: Quadro de início da animação, pode manter 1;

- End: Quadro de término da animação, configure para 60;
- WrapMode: Modo de Wrap da animação, para esta animação
configure como “Loop”.
Clique novamente no “+” para acrescentar mais uma animação, a configuração da
nova animação deve ser:
- Name: “shoot”;
- Start: 61;
- End: 75;
- WrapMode: Once.
Desça um pouco mais na janela “Inspector” e clique no botão “Apply”. Clicando em
“Play” você pode notar que a animação de idle (a arma subindo e descendo) fica ativada
em loop.
8. Criando a munição e o processo de disparo

O próximo passo é criar a munição da arma. Vamos usar um cubo como munição.
Clica em “GameObject -> Create Other -> Cube”, diminua o tamanho do cubo (na janela
“Inspector”, configure os parâmetros X, Y e Z de “Scale” para 0.15) e aperte Play. Você pode
notar que o cubo fica flutuando no espaço. Para que possamos aplicar outras forças no
cubo, você deve adicionar um Rigidbody ao cubo. Na janela “Hierarchy” selecione o Cubo,
depois clique em “Components -> Physics -> Rigidbody”, após fazer isso se você apertar Play
você vai notar que o cubo vai cair.
Agora vamos definir a Tag associada a nosso cubo. A Tag vai ser utilizada à frente
quando analisarmos a colisão da bala com o inimigo. Na janela “Inspector”, clique no pull-
down ao lado de Tag no canto superior esquerdo e selecione a opção “Add Tag...”, expanda
a opção “Tags” (primeira linha) e na linha “Element 0” escreva “Bullet”
Vamos definir um tempo para o cubo desaparecer após ser disparado. Na janela
“Project” clique em “Create -> C# Script”, procure o objeto NewBehaviourScript e renomeie-o
para “BulletController” e clique duas vezes no objeto para abrir o editor. Uma vez aberto,
altere o nome da classe para BulletController. A classe que foi criada já tem duas funções:
- Start(): Essa função é chamada sempre que o GameObject ao qual o script está
associado é criado;
- Update(): Essa função é chamada toda vez que um frame é desenhado.
O que queremos é que, depois de um determinado tempo, o cubo desapareça. Na
função Start() acrescente a seguinte linha:

Sumário
Destroy(gameObject, 5.0f);
O que essa linha faz é destruir o gameObject ao qual o script está associado em cinco
segundos. Salve o script, volte ao Unity e na janela “Project”, clique no BulletController e
arraste-o ao objeto Cube na janela “Hierarchy”, se depois disso você clicar no Cube em
“Hierarchy”, você vai notar no “Inspector” que surgiu uma nova sessão chamada “Bullet
Controller (Script)” (Fig. 25).
Fig. 25: “Inspector” do Cube com o Bullet Controller na parte de baixo.

Note também a Tag “Bullet” já associada ao Cube
Clique em Play, depois de cinco segundos o cubo desaparece do jogo e desaparece

também do “Hierarchy” (lembre-se, o Hierarchy mostra apenas os objetos que existem na
cena, como destruímos o objeto ele deixa de existir).

Sumário
Mas da maneira como o tempo para destruição do cubo está configurado, a única
maneira de alterá-lo é entrando no código fonte e alterando o valor, vamos facilitar esse
processo, volte ao editor do código, e crie uma variável na classe:
public float timeToLive = 5.0f;
Depois disso, altere a chamada de Destroy para:
Destroy(gameObject, timeToLive);
Depois disso, volte ao Unity, clique no Cubo na janela “Hierarchy” e repare no

“Inspector” que dentro da seção “Bullet Controller” você agora pode configurar a variável do
tempo de destruição do cubo sem ter que alterar o código fonte (Fig. 26).
Fig. 26: Inspector agora com o parâmetro Time To Live.
Arraste o Cube da janela “Hierarchy” para a janela “Project”. Dessa maneira vamos
criar um prefab do Cube que usaremos no futuro para criar as balas que são disparadas pela
nossa arma. Agora você já pode apagar o Cube da Scene.
Agora vamos criar o processo de disparo da arma, o processo é basicamente o
seguinte:
- Quando o botão de disparo for pressionado:

• Uma bala será criada na frente da arma;
• A arma vai tocar a animação de “Shoot” e depois voltar para “Idle”;
• Um som será tocado.
Primeiramente vamos definir a posição onde serão geradas as balas que são disparadas.
Clique em “GameObject -> Create Empty”. Esse GameObject será “vazio”, apenas com um
script associado, portanto para facilitar sua visualização vamos acrescentar um label a esse
GameObject. Selecione o GameObject criado na janela “Hierarchy” e clique no cubo verde,
vermelho e azul no canto superior esquerdo da janela “Inspector” e selecione um dos ícones
apresentados. Agora um label com o nome do GameObject estará presente na janela Scene
sempre (Fig. 27).

Sumário
Fig. 27: Label GameObject presente na janela Scene.
Antes de posicionar o GameObject vamos renomeá-lo e torná-lo filho da bazooka

(para que ele acompanhe o objeto bazooka), clique com o botão direito no GameObject
na janela “Hierarchy” e selecione “Rename” e altere o nome para “BulletSpawn”. Agora
posicione o GameObject vazio em frente a arma arrastando o objeto na janela “Scene” ou
selecione o objeto “BulletSpawn” na janela “Hierarchy”, e na janela “Inspector” configure os
parâmetros de position para:
- X: 0;
- Y: -7.7;
- Z: -1.2.
Feito isso, selecione o arquivo BulletShooter.cs e arraste para dentro do diretório
“Project” e depois arraste-o da janela “Project” para o objeto BulletSpawn na janela “Hierarchy”.
Feito isso, clique no objeto BulletSpawn na janela “Hierarchy” e verifique se agora há uma
seção chamada “Bullet Shooter (Script)” (Fig. 28).
Fig. 28: Janela “Inspector” do BulletSpawn com o script.

Sumário
Vamos analisar o que está sendo feito no script BulletShooter.cs, a função Start() não
faz nada, ou seja, quando o cubo é criado nada acontece, na função Update():
void Update ()
{
if(Input.GetButtonDown(“Fire1”))
{
Rigidbody bullet = Instantiate(myBulletPrefab,
transform.position, transform.rotation) as Rigidbody;
bullet.velocity =
transform.TransformDirection(new Vector3
(0,0,shootForce)); audio.PlayOneShot(shootClip); gun.
animation.Play (“shoot”); gun.animation.Play-
Queued (“idle”);
}
}
Toda vez que a tela é redesenhada, eu verifico se o botão foi pressionado (if(Input.
GetButtonDown(“Fire1”))):
- Rigidbody bullet = Instantiate(myBulletPrefab,

transform.position, transform.rotation) as
Rigidbody; - Eu crio uma cópia do prefab myBulletPrefab na
posição e rotação do objeto ao qual está associado o script (no caso, o Bul-
letSpawn);
- bullet.velocity = transform.TransformDirection(new
Vector3 (0,0,shootForce)); - Defino a velocidade do prefab
instanciado para X = 0,Y = 0 e Z = shootForce;
- audio.PlayOneShot(shootClip); - Começo a tocar o audio
- gun.animation.Play (“shoot”);- Começo a tocar a animação
“shoot”;
- gun.animation.PlayQueued (“idle”); - Assim que a anima-
ção atual terminar, começo a tocar a animação “idle”;
Agora é necessário definir as variáveis utilizadas pela classe, que são:
public Rigidbody myBulletPrefab; public int shootForce =

20; public AudioClip shootClip; public GameObject gun;
- Rigidbody myBulletPrefab: Esse é o prefab da bala que criamos;

- int shootForce: Velocidade inicial da bala;
- AudioClip shootClip: O som a ser tocado quando a arma é dispa-
rada;

Sumário
- GameObject gun: A arma, precisamos saber qual é a arma para poder

tocar as animações shoot e idle;
Como demonstramos quando criamos a bala, como essas variáveis são públicas elas
podem ser alteradas dentro do editor:
- Variável myBulletPrefab: Arraste o prefab Cube da janela “Project” para o
campo My Bullet Prefab da seção “Bullet Shooter (Script)”;
- Variável shootForce: Mantenha o valor 20;
- Variável shootClip: Arraste o arquivo bang.wav para a janela “Project” e depois
arraste o objeto bang da janela “Project” para o campo Shoot Clip da seção “Bullet Shooter
(Script)”;
- Variável Gun: Arraste o objeto bazooka da janela “Hierarchy”
para o campo Gun Clip da seção “Bullet Shooter (Script)”.
Sua configuração deve estar igual a Fig. 29.
Fig. 29: Janela “Inspector” do objeto BulletSpawn

após configuração das variáveis.
Clique Play e teste o disparo clicando o botão esquerdo do mouse. Tudo funciona
exceto o som. Isso porque é necessário também acrescentar um componente chamado
AudioSource ao objeto BulletSpawn, para que o som possa ser executado. Clique no objeto
BulletSpawn na janela “Hierarchy”, depois clique em “Component -> Audio -> Audio Source”.
Clique Play e agora o áudio deve estar funcionando corretamente.
9. Criando um inimigo
Agora vamos criar um robô que será o nosso alvo. Clique em “Assets -> Import Package
-> Custom Package” e selecione o arquivo robot.unitypackage, clique em “Import” no pop-up.
Selecione o prefab Robot_Animated e arraste- o para a janela “Hierarchy”, depois posicione o
robô em frente a câmera (Fig. 30).

Sumário
Fig. 30: Robô criado e em frente a câmera.
Aperte Play. Você vai notar que o Robô já tem uma animação de Idle (ele fica
balançando). Tente disparar no robô, você vai notar que a bala passa através dele. Esse é o
mesmo problema da plataforma que tivemos no início do tutorial, o robô não tem um box
collider.
Na janela “Hierarchy”, clique no objeto Robot_Animated, depois clique em “Component
-> Physics -> Box Collider. Depois você deve ajustar o tamanho e posição do Box Collider de
acordo com a Fig. 31.
Fig. 31: Configuração do Box Collider para o robô,

note o Box Collider (caixa verde) na janela “Scene”.
Clique Play, agora as balas “param” no Robô. O próximo passo e fazer o tratamento
da colisão da bala com o robô.
Arraste o arquivo BulletHit.cs para a janela “Project”, depois arraste o objeto BulletHit
para o objeto Robot_Animated na janela “Hierarchy”.
Vamos analisar a classe BulletHit:

Sumário
public class BulletHit : MonoBehaviour

{
void OnCollisionEnter (Collision other)
{
if (other.gameObject.tag == “Bullet”)
{
Destroy (gameObject); Destroy (other.ga-
meObject);
}
}
}
O primeiro detalhe é a falta das funções Start() e Update(), na verdade estas funções
não são necessárias, você pode ter uma classe sem ambas sem problemas.
A função OnCollisionEnter() é chamada no momento em que um objeto entra
numa área de colisão pertencente ao objeto ao qual este script está associado. Neste caso, é
o Box Collider do robô que acabamos de criar, e o objeto que entrou na área de colisão é o
parâmetro other da função. O que está acontecendo dentro desta função:
- if (other.gameObject.tag == “Bullet”): Verifica se o objeto

que colidiu com a caixa de colisão (other) tem a Tag “Bullet”;
- Destroy (gameObject): O objeto ao qual o script está associado é
destruído;
- Destroy (other.gameObject): O objeto que colidiu com a caixa
de colisão é destruído;
Após arrastar o script para o objeto Robot_Animated, clique em Play e tente atirar no
robô, agora tanto o robô quanto a bala desaparecem, conforme explicado acima.
10. Acrescentando um Navigation Mesh

Vamos fazer agora com que o inimigo nos siga pelo nível. Para isso vamos criar um
Navigation Mesh (mapa indicando os caminhos que podem ser percorridos) e adicionar o
NavMesh Agent ao nosso robô.
Para fazer parte de um Navigation Mesh, um objeto deve ser “Navigation Static”, para
verificar o status de um objeto, clique nele na janela “Scene”, ou “Hierarchy”, e no canto
superior direito da janela “Inspector” você tem um pull-down com todas as configurações de
estática do objeto (Fig. 32).

Sumário
Fig. 32: Configurações de static para um objeto. Como ele é “Navigation Static”
ele pode ser utilizado num Navigation Mesh.
Para começar é necessário selecionar todos os pisos que farão parte do nosso
Navigation Mesh, faça isso clicando em cada uma das partes do chão da nossa fase na
janela “Scene” (para selecionar mais de um objeto utilize CTRL+click no Windows ou
command+click no MacOS) (Fig. 33).
Fig. 33: Todas as partes de chão selecionadas que farão parte do Navigation Mesh (o chão
dentro do túnel também foi selecionado).
Uma vez selecionados os segmentos de chão que farão parte do Navigation Mesh,
clique em “Window -> Navigation” e clique no botão “Bake” no canto inferior direito (Fig.
34).

Sumário
Fig. 34: janela Navigation.
Após o termino do Bake, adicione um Nav Mesh Agent ao objeto Robot_Animated: Clique
em Robot_Animated na janela “Hierarchy” e depois clique em “Components -> Navigation ->
Nav Mesh Agent”. Depois arraste os arquivos agentLocomotion.js e robotController.js para a
janela “Project” e depois arraste os objetos agentLocomotion e robotController para o objeto
Robot_Animated na janela “Hierarchy”, depois disso clique em Clique em Robot_Animated na
janela “Hierarchy” e na seção “Robot Controller (Script)” altere a variável Nav Distance para
3 e arraste o objeto First Person Controller da janela “Hierarchy” para a variável Nav Target
(Fig. 35).

Sumário
Fig. 35: Configuração do objeto Robot_Animated. Notle os componentles

adicionados e as configurações do Robot Controller
11. Adicionando uma explosão ao robô

Vamos criar um efeito de explosão no momento em que o robô é destruído.
No script BulletHit.cs, descomente as linhas 6 (public GameObject explosion;) e 14
(Instantiate(explosion, transform.position, transform.rotation);).
Depois, clique em Assets -> Import Package -> Custom Package… e importe o pacote
fireExplosion.unitypackage.
Feito isso, selecione o objeto Robot_Animated na aba “Hierarchy”, note que dentro
do script “BulletHit” Você agora tem uma variável “Explosion”. Na janela “Project” expanda as

Sumário
pastas “Explosion -> Effects” e arraste o prefab fireExplosionBase para a variável “Explosion”
(Fig. 36).
Fig. 36: Script Bullet Hit do objeto Animated_Robot com a variável Explosion configurada.
Aperte play. Agora quando você atirar no robô o mesmo desaparece e uma explosão
aparece no chão.
12. Otimização: Lightmapping

Neste exato momento, toda a iluminação da sua cena está sendo calculada em tempo
de execução. Porém para a grande maioria dos elementos da sua cena esse cálculo não
é necessário, as paredes e plataformas por exemplo não mudam de posição, portanto a
iluminação e sombreamento destes elementos será sempre a mesma. A fim de economizar
processamento fazemos o lightmapping da fase, que substitui as sombras dinâmicas por
texturas.
O lightmapping gera um mapa que é aplicado aos elementos estáticos da fase. Todos
os elementos que estamos utilizando já estão configurados como estáticos (ou não). Na aba
“Hierarchy”, clique em First Person Controller, no canto superior direito da aba “Inspector”
há o pull-down menu de “Static”, expanda ele e você verá que o First Person Controller não
está configurado para ser estático, isso significa que ele não será afetado pelo lightmapping
(Fig. 37).
Fig. 37: Configuração estática do First Person Controller
Porém, se você selecionar qualquer um dos objetos dentro de Level na aba “Hierarchy”,
você vai notar que estes elementos estão configurados como static, e serão afetados pelo
lightmapping (Fig. 38).

Sumário
Fig. 38: Configuração de um dos elementos da fase
Para configurar o lightmapping clique em Window -> Lightmapping, uma nova janela
será aberta, clique no botão “Bake” na parte superior da janela e certifique-se que o “Mode”
está configurado para “Single Lightmapping” e configure o valor de “Resolution” para 5. Feito
isso, clique no botão “Bake Scene” no canto inferior direito e aguarde o término da criação
do lightmapping (Fig. 39).
Fig. 39: Aba lightmapping após a conclusão. Note o mapa de texturas de sombras no “Preview”.

Sumário
13. Otimização: Occlusion Culling
OBS: Occlusion Culling está disponível somente na versão “Pro” do Unity. Caso você tenha
a versão básica e seu trial de 30 dias da Pro expirou, você não conseguirá executar esse
capítulo do tutorial.
Por default, o Unity utiliza Frustum Culling desenha todos os polígonos que estão
dentro da área de visão da câmera, independente se eles estão “escondidos” atrás de outros
objetos (Fig. 40).
Fig. 40: Exemplo de Frustum Culling. Esta é nossa fase vista de cima, o cone branco mostra o cone
de visão da câmera. Todos os polígonos neste cone são desenhados, inclusive os que estão atrás
da parede destacada em vermelho e que não podem ser vistos pelo jogador.
Para otimização, é possível utilizar Occlusion Culling nos jogos feitos em Unity. O
Occlusion Culling vai desenhar somente os objetos que são efetivamente vistos pelo jogador,
mesmo que estejam no cone de visão da câmera.
Para ativar o Occlusion Culling, clique em Window -> Occlusion Culling. O grid
branco do Occlusion Culling vai aparecer na janela “Scene”, ajuste o tamanho do grid com a
ferramenta de Scale e certifique-se que toda a cena está dentro do grid (Fig. 41).

Sumário
Fig. 41: Janela “Scene” com o grid de Occlusion Culling aplicado em toda a cena
Feito isso, clique no botão “Bake” no canto inferior direito da aba “Occlusion”. Uma
vez terminado o Bake, aperte Play, e note na aba “Scene” que agora só os polígonos que
estão sendo desenhados são exibidos
Fig. 42: Aba “Scene” com Occlusion Culling ativado.

Compare com os polígonos que seriam desenhados na Fig. 40.
14. Otimização: Lightprobing
OBS: Lightprobing está disponível somente na versão “Pro” do Unity. Caso você tenha a
versão básica e seu trial de 30 dias da Pro expirou, você não conseguirá executar esse
capítulo do tutorial.

Sumário
Com a ativação do lightmapping surgiu um problema: Os elementos que tem

iluminação dinâmica passam a não ter sua iluminação alterada quando passam de uma
zona iluminada para uma zona com sombra.
Você pode notar essa diferença ao passar pelo túnel indicado na Fig. 43. Além disso
note a diferença de iluminação na Fig. 44.
Fig. 43: Mapa da fase destacando em vermelho o local da análise da Fig. 45
Fig 44: As figuras de cima mostram o jogo com Lightmapping desativado, note que a diferença
de iluminação na arma na imagem da esquerda (região iluminada) e na imagem da direita
(região com sombra). As figuras de baixo mostram o jogo com Lightmapping ativado, note que a
iluminação na arma não muda entre as duas imagens.
A solução é usar lightprobes. Lightprobes coletam informação de iluminação nos

pontos onde são colocados e geram um efeito similar a iluminação dinâmica com baixo
custo de processamento.

Sumário
Para acrescentar Lightprobes a sua cena clique em “GameObject -> Create Empty”, e
um objeto chamado GameObject vai surgir na aba “Hierarchy”, clique com o botão direito
no GameObject criado e o renomeie para Lightprobe. Com esse objeto selecionado clique
em “Component -> Rendering -> Light Probe Group” e agora vamos criar os Light Probes.
Como melhor prática o ideal é criar um volume com os Light Probes para que a coleta
seja eficiente. Para adicionar Light Probes selecione o objeto Lightprobe na aba “Hierarchy” e
clique no botão “Add Probe” na aba “Inspector”. Você vai notar que uma esfera azul vai surgir na
janela “Scene”, altere a posição dela e inclua mais probes no formato de um volume (Fig. 45).
Fig. 45: Sistema de Light Probes criado na cena. Note que parte dos probes
está na parte iluminada e parte está na parte sombreada da plataforma.
Uma vez criado o conjunto de Light Probes, procure o objeto Bazooka1 dentro da
aba “Hierarchy”, e dentro do Mesh Renderer na janela “Inspector”, ative a opção “Use Light
Probes” (Fig. 46). Feito isso clique em “Window -> Lightmapping e clique no botão “Bake
Scene”, pois uma vez criados os light probes é necessário refazer o bake do Lightmapping.
Uma vez feito o bake clique em play e passe pelos probles criados, você vai notar que a
iluminação na arma é modificada (Fig. 46).
Fig. 46: Cena com Lightmapping e Light Probes ativados, note a diferença de iluminação
na arma entre a região iluminada (esquerda) e região sombreada (direita).

Sumário
Organizando os Mapas de Iluminação dos

Assets de Arte para os Motores de Jogos:
Considerações Metodológicas para o Caso da
Produção Voltada ao Motor de Jogos UDK
Luís Carlos Petry1
Eliseu de Souza Lopes Filho2
Maigon Nacib Pontuschka3
Felipe Dacal Fragoso4
Gabriel Cavalcanti Marques5
Winna Hita Iturriaga Zansavio6
1 Pontifícia Universidade Católica de São Paulo - Brasil; Programa de Pós-graduação em Tecnologias da

Inteligência e Design Digital (TIDD); petry@pucsp.br, alletsator@gmail.com.
Inteligência e Design Digital (TIDD); eliseulopes@pucsp.br.
3 Universidade Federal de Rondônia (UNIR); maigonp@gmail.com.
Inteligência e Design Digital (TIDD); fefragoso@gmail.com.
Inteligência e Design Digital (TIDD); arzael_wolf@hotmail.com.
Inteligência e Design Digital (TIDD); vampyr_flicka@hotmail.com.

Sumário
Figura 1: Cena temática renderizada do motor UDK.
Resumo
O presente artigo apresenta uma metodologia que se propõe a organizar os mapas de
iluminação7 dos objetos tridimensionais que são produzidos para o motor de jogos8 UDK.
Identifica a problemática na comunidade de produtores, realiza um apanhado das soluções
encontradas e propõe uma metodologia que pode ser aplicada de modo rápido e eficiente.
Tal metodologia se embasa em pesquisas acadêmicas e nos ensinamentos da história do
desenho e da pintura Ocidentais. Mostra que com uma rigorosa metodologia científica que
oriente o labor tridimensional é possível a produção de recursos tridimensionais no padrão
da indústria internacional de jogos (triple A).
Palavras-Chave: Metodologia 3D. Modelagem 3D. Lightmap. Topofilosofia. UDK. Maya.
1. Introdução
Todos os dias os artistas tridimensionais enfrentam problemas técnicos e conceituais
na dura tarefa de produzir recursos de qualidade para os motores de jogos. Mas, quando
uma dificuldade combina ambos, tanto os requisitos técnicos como os conceituais é que eles
são alertados para a importância de uma atitude e uma disciplina de trabalho organizada
metodologicamente.
No presente artigo enfocamos um destes momentos comuns que tem exasperado
inúmeros usuários do motor de jogos UDK no mundo inteiro e tem sido fonte para debates
em fóruns, artigos e extensa documentação: a importação de recursos de arte que tenham
uma apresentação e performance de qualidade profissional, quando submetidos ao sistema
de Lightmass do motor. Para alcançar este objetivo, os artistas têm de lidar com os requisitos
envolvidos na produção de um mapa de iluminação para os objetos tridimensionais, fato
que envolve tanto aspectos conceituais dos mais diversos, desde conhecimentos referentes
a teorias da luz, da parametrização dos objetos, da organização de mapas de UV, etc.
7 Os termos técnicos utilizados pela comunidade de produção são traduzidos na versão portuguesa do
presente artigo visando a sua máxima inteligibilidade conceitual. Lightmap é traduzido por mapas de iluminação;
assets por recursos
8 Os termos engine e game engine, foram respectivamente traduzidos por motor e motor de jogo

Sumário
É nesse sentido que o presente artigo enfoca a produção de recursos de arte

tridimensional e seus requisitos técnico-conceituais envolvidos, a fim de serem integrados
em ambientes digitais pelo motor de jogos UDK no quesito da produção de mapas de
iluminação.
Nossa pesquisa abarca os seguintes aspectos: a identificação dos problemas mais
comuns na importação de assets de arte (objetos tridimensionais) no motor de jogos UDK
relacionados com os requisitos técnicos do plano UV, nos mapas de iluminação para a
ação do Lightmass; a apresentação de uma metodologia normativa e sequencial para a
preparação de recursos de arte para sua importação no motor de jogos; a estruturação das
etapas de trabalho para a produção de assets de arte em uma pipeline exequível, rápida
e eficaz; a demonstração das etapas da metodologia proposta em um exemplo prático
de trabalho de produção de um recurso de arte padrão; a mostração [Petry 2003] da
possibilidade da produção de assets de arte de qualidade superior para o uso em produções
de jogos comerciais e acadêmicos no Brasil; finalmente, estimular a colaboração conceitual
e pragmática possíveis entre as pesquisas acadêmicas de jogos e os esforços da indústria
nacional de jogos.
O relatório completo da pesquisa do grupo pode ser acessado no site de pesquisa
topofilosofia.net, na seção pesquisa. Nele o interessado terá acesso a todo o material, bem
como a uma documentação que contempla a teoria e o conjunto de tutoriais e recursos
produzidos9.
2. Aspectos da problemática metodológica envolvida

A produção de recursos tridimensionais para motores de jogos envolve um conjunto
de conhecimentos de amplo escopo e o seu domínio técnico e conceitual demanda
uma curva de aprendizagem considerável. Ele está inserido em um campo que mescla
dinamicamente habilidades e competências artísticas e requisitos técnicos. Como muito
bem diz Rabin [2012], o modelador 3D profissional é um escultor e um técnico. Ele é um artista
e um engenheiro.
Uma análise da situação mostra que o domínio dos processos de produção de recursos
de arte tridimensional para o motor de jogos UDK exige do designer um grande esforço de
formação e a constante busca de atualização dos conhecimentos técnicos relacionados, tanto
no que diz respeito à modelagem 3D, bem como aos requisitos estabelecidos pelo motor de
jogo. Inúmeros são os exemplos de solicitações de ajuda por parte dos iniciantes nos usos do
motor UDK em relação aos problemas de sangramento (bleeding) na produção dos mapas
9 A metodologia sintetizada no presente artigo é o resultado de parte de uma pesquisa acadêmica (no TIDD)
que tem como enfoque central o estudo das capacidades técnicas dos softwares tridimensionais e dos motores
de games para a produção de ambientes (e seus objetos) e recursos expressivos para o estabelecimento de
uma linguagem dos jogos (sintaxe e semântica) ao modo das pesquisas já realizadas para as linguagens do
teatro, cinema e hipermídia.

Sumário
de luz para o Lightmass10. É o caso do pedido de ajuda do usuário SeBeQ (Iron Guard, dos
EUA), do qual recolhemos uma amostra imagética (figura 2) do problema apresentado por
ele:
Figure 2: Imagem apresentando o problema de “sangramento” do mapa de luz. Modelo

apresentado pelo usuário SeBeQ no fórum da EPIX em fevereiro de 2010. As marcas de vermelho
indicam as regiões de “sangramento”.
Outro usuário, Philhowlett, no fórum do game-artist.net, coloca o problema do mapa

de iluminação em uma construção urbana tridimensional: “Se alguém pudesse me ajudar
com isso seria brilhante!” E expõe a sua problemática dizendo, “estou tendo um momento
muito difícil em meu trabalho e luto para conseguir que meus objetos tenham um bom mapa
de iluminação no UDK”, situação que mostramos na figura 3 postada por ele no fórum.
Figura 3: As setas brancas indicam os pontos de problemas com o mapa de iluminação.
Foi a partir dos inúmeros problemas identificados, tanto nos fóruns dos
desenvolvedores como no estudo que realizávamos do motor de jogos, que nossa equipe
resolveu transformar o chamado problema de produção em uma problemática de pesquisa, ao
modo da metodologia topofilosófica11: quais os fundamentos e passos metodológicos a serem
realizados para a produção de mapas de iluminação adequados para o motor de jogo UDK?
3. O motor de jogos UDK e seus mapas de iluminação

O motor de jogos UDK12, sigla do Unreal Development Kit, é derivado do motor Unreal
3 da EPIC e teve a sua abertura gratuita para a comunidade em novembro de 2009. Pautado
10 Exemplos da problemática podem ser encontrados nos inúmeros pedidos de ajuda postados nos fóruns de
usuários. Citamos dois deles aqui: http://forums.epicgames.com/archive/index.php/t-743360.html; http://www.
game-artist.net/forums/support-tech-discussion/13168-udk-light-mapping-help-pretty-urgent.html
11 Detalhes sobre a metodologia topofilosófica podem ser encontrados em Petry (2003).
12 O UDK possui seu site em: udk.com.

Sumário
por uma política audaciosa, o UDK desde o início foi balizado por atualizações mensais. Com
essa política ele estimulou a comunidade de desenvolvedores e estudiosos na produção de
jogos, comerciais e indie dentro do padrão de qualidade da indústria internacional (triple A).
Ainda que a ferramenta não fosse desconhecida pela comunidade internacional de
desenvolvedores, uma vez que se aproximava muito do editor de níveis da franquia de jogos
também pertencentes à Epic, o Unreal Tournament 3, o lançamento do Unreal Development
Kit foi acompanhado da promessa de que os produtores seriam capazes de gerar um
executável de seu projeto e não mais apenas Mods da franquia13.
Nesse sentido, o lançamento do UDK se constituiu em um marco no desenvolvimento
de jogos, principalmente do ponto de vista dos desenvolvedores indie e da academia.
Porém, cada motor de jogos possui peculiaridades técnicas e conceituais que devem
ser observadas, as quais estruturam pré-requisitos para um adequado desenvolvimento. É o
caso do motor de jogos UDK, que mesmo com a sua liberação gratuita para a comunidade,
mantém seu padrão de funcionalidade dentro de escopo profissional internacional. Neste
sentido, uma das mais importantes e poderosas funcionalidades do motor, a iluminação
baseada no Lightmass14, tem como pré-requisito a organização prévia de mapas de iluminação
(lightmaps).
Tal aspecto, fez com que uma comunidade de desenvolvedores, acostumada a trabalhar
privilegiando o estilo de modelagem intuitiva em detrimento dos preceitos técnicos da teoria
parametrizada dos objetos, enfrentasse um grande desafio. Foi a partir da constatação dessa
necessidade e oportunidade metodológica que estruturamos a problemática indicada no
tópico 2 acima.
4. Trabalhos relacionados
Muitos profissionais dedicados ao desenvolvimento com o motor de jogos UDK e
envolvidos com o ensino da utilização das ferramentas de modelagem associada ao motor
de jogo produziram materiais bibliográficos que discutem amplamente o conceito e a
produção dos mapas de iluminação.
Richard Moore, autor do Unreal Development Kit: Beginner´s Guide, reserva toda uma
seção de seu livro para a discussão geral do conceito relacionado aos objetos BSP15 e aos
13 Um dos aspectos já referidos é que um grande diferencial a ser observado, foi a coerente continuidade
que a equipe da EPIC manteve nas atualizações mensais do motor de jogos, sem restrições de uso e aplicação
técnicas, as quais permitiram inúmeros lançamentos de jogos e metaversos em um alto padrão de qualidade.
14 O Lightmass com a estrutura de lightmap foi introduzida em Junho de 2009 no UDK com o Build: QA_
APPROVED_BUILD_JUN_2009.
15 Objetos BSP: é o termo utilizado para designar um tipo especial de objeto interno ao motor de jogo. A sigla
BSP significa: Binary Space Partitioning, divisão (partição) binária do espaço. Eles são objetos criados que têm a
finalidade de compor parte de uma cenário, unicamente a partir dos brushes disponibilizados pelo motor UDK.

Sumário
chamados Static Meshes16 [Moore 2012]. Thomas Mooney, autor de Unreal Development Kit
Game Design Cookbook, discute a resolução a ser utilizada nos lightmaps de objetos e a
necessidade de se manter os múltiplos de 2 [Mooney 2012].
Jason Busby, Zak Parrish e Jeff Wilson, os autores do Mastering Unreal Technology I e
II, discutem detalhadamente a questão da iluminação e dos mapas de iluminação dentro do
Unreal Engine 3 [Busby et al. 2009].
O site educacional criado por Jason e Angela Busy, o 3dbuzz.com, dentre as centenas
de vídeos didáticos sobre o UDK, possui 14 vídeo-aulas dedicadas especificamente ao tema
dos mapas de iluminação e do sistema de Lightmass, constituindo-se em uma referência
para quem deseja dominar a problemática [Busby 2012].
Temos também o Belga, Sjoerd “Hourences” De Jong, notório artista e didata no
mundo do Unreal, que nos apresenta uma sólida introdução ao Lightmass e ao lightmap
nos seus artigos, Introduction to using the Lightmass system e Lightmapping Meshes In The
Editor: How to set up lightmapping on a mesh [Hourences 2010]. Ainda que ambos sejam
direcionados ao UT3 (Unreal tournament 3) a sua estrutura conceitual e de parametrização
é inteiramente aplicável ao UDK.
Por outro lado, Stephen Jameson escreveu um artigo no qual, dentre outras coisas,
demonstra a necessidade da produção de mapas de iluminação diferenciados para os
objetos e a sua disposição em um alinhamento parametrizado na grade do mapeamento
UV [Jameson 2009].
Outro grande designer, Alex Galuzin, em seu site didático, World of Level Design,
apresenta inúmeros artigos que tratam de forma concisa e eficaz a problemática em questão.
São eles: UDK: Lightmap Basics and 18 Important Principles for Creating and Using Lightmaps;
UDK: Lightmap UV Layout Techniques and How to Create a Second UV Channel in Maya;
UDK: How to Fix Lightmap Light/Shadow Bleeding and Seams; UDK: Lightmap Resolution for
Static Meshes and BSP; UDK: Lightmap Common Problems and Solutions. [Galuzin 2012] O
trabalho de Galuzin pode ser considerado uma das maiores, mais generosas e importantes
contribuições realizadas até o momento para o entendimento e entrelaçamento entre o
UDK e as ferramentas de modelagem tridimensional, especialmente o Maya.
Finalmente, no próprio sistema de documentação da EPIC Games, a partir da
introdução do sistema de Lightmass, em 2009, Daniel Wright publica um artigo intitulado,
Lightmass Static Global Illumination [Wright 2009]. Nesse artigo ele nos indica a correlação
16 Static Meshes: é o nome dado para os objetos poligonais 3D que compõem um cenário, cena de um
jogo ou espaço navegável. São chamados de “static”, porque esses objetos são estáticos, ou seja, não estão
animados, muito menos sofrem qualquer reposicionamento no campo paramétrico do mapa durante o jogo.
Eles servem ao propósito de compor, dar identidade e decorar o cenário. Assim, eles são construídos nos
softwares de modelagem e são exportados para o motor de jogo. Sem os static meshes, não há ambiente do
jogo, nem espaço navegável; restaria apenas uma cena vazia. Dessa forma, tudo aquilo que ocupa a cena
3D, objetos, móveis, vegetações, entre outros, e que não é animado, é uma static mesh. É neles que incide a
problemática dos mapas de iluminação.

Sumário
entre o Lightmass e o lightmap, mostrando que o segundo é uma direta e consequente

construção do primeiro17.
Todos esses trabalhos nos incitam a pesquisar também os fundamentos presentes no
conceito de mapa de iluminação no UDK, dado que ele implica em uma teoria da luz e uma
normatização na produção dos objetos tridimensionais.
Enfim, uma miríade de materiais de qualidade sobre o tema que hoje estão
disponíveis na Rede para os pesquisadores. A cada dia [,] novos materiais que discutem
propriedades conceituais ou técnicas do tema são disponibilizados para a comunidade de
desenvolvimento, enriquecendo a base de informação sobre esse campo de conhecimento.
Nossa conclusão é que a literatura encontrada sobre o tema dos mapas de iluminação
deixa absolutamente claro que devemos sempre nos armar de uma metodologia na
produção tridimensional que permita a construção de mapas de iluminação parametrizados
para nossos objetos. Mais do que uma recomendação simplesmente operacional, ela nos
indica um alerta que combina técnica e conceito na visada da qualidade da produção de
recursos para jogos.
5. A teoria da parametrização dos objetos e da luz e sua relação com

o mapa de iluminação no UDK
Dois aspectos são fundamentais para a organização dos mapas de iluminação dos
objetos tridimensionais: [1] a sua parametrização no espaço tridimensional e [2] a sua
organização em relação à luz que será produzida no motor de jogo. Enquanto a luz organiza
as massas dentro do mundo digital do jogo, a parametrização dos objetos no espaço digital,
no que tange aos seus mapas UV, estrutura “a própria área do objeto” e “o seu como” o
objeto será afetado pela luz dentro do ambiente digital. É o que discutiremos a partir de
agora.
5.1 A estrutura parametrizada do ambiente de construção tridimensional

Todo objeto tridimensional que importamos para o ambiente de produção do motor
de jogo é um recurso que é compreendido pelo sistema do motor a partir de parâmetros,
a partir do que, na tradição Ocidental, ficou conhecido como parametrização dos objetos.
A teoria da parametrização dos objetos remonta aos trabalhos renascentistas de
Leonardo Da Vinci [1452-1519] e Albrecht Dürer [1471-1528]. Enquanto que do primeiro
nós recebemos a perspectiva de organização formal da figura humana [Mussara 2011],
o segundo nos conduziu ao sistema de parametrização dos objetos na grade de desenho
paramétrico (figura 4), o qual pode ser utilizado de inúmeras formas para a produção de
representações artísticas e paramétricas.
17 “O Lightmass cria lightmaps com interações complexas de luz como áreas de sombreamento e inter-reflexões
difusas. Ele é ortogonal ao restante da renderização do pipeline (iluminação dinâmica e sombreamento. Ele
apenas substitui os lightmaps e mapas de sombras estáticas por outros de qualidade superior” [Wright 2009].

Sumário
Figura 4: Duas representações artísticas da Grade de Dürer (1 e 2)

e uma reconstrução atual dela (3)
Do trabalho conceitual de Dürer deriva o ambiente das Janelas de visualização em

grade dos softwares de modelagem 3D atuais. Dele também derivam as técnicas de desenho
projetivo e os seus correlatos designados por diversos nomes, tais como blueprint, model
sheet em alguns casos, etc. Todos os desenhos que inserem um dado objeto em uma grade
orientada, seja para reprodução pantográfica, modelagem 3D, etc., possuem no trabalho
de Dürer o seu fundamento formal. Considere em um Cubo a transposição do esquema de
Dürer para o software de modelagem 3D (figura 5).
A parametrização, esse importante elemento que conjuga arte e ciência, oferece-nos
a chave para entender que todo objeto tridimensional deve ser compreendido dentro de
um campo de coordenadas espaciais delimitadas pelos eixos X (horizontais) e Y (verticais) de
um dado plano. É a partir dessa racionalidade que temos os mapas de iluminação, derivados
de uma organização de mapas UV, orientados por coordenadas.
Dessa premissa deriva que, dado que todo objeto construído no campo tridimensional
é compreendido entre coordenadas tridimensionais, a representação de seu mapeamento
UV, que poderá ser utilizado para a construção de seu mapa de iluminação, deve ser
pensado dentro do campo abrangido pelas coordenadas UV (nos eixos X e Y do plano
do mapa)18. Demonstra-se assim, com a teoria da parametrização, o primeiro construto de
nosso fundamento técnico-conceitual.
18 Isso sem falar aqui por falta de espaço do trabalho do filósofo francês Blaise Pascal que, em 1639, com seu
Ensaio sobre cônicas, organiza a ideia das projeções sobre um plano que servirá, duzentos anos depois, como
base para o desenho projetivos de objetos e máquinas [Attali 2003].

Sumário
Figura 5: À esquerda um Cubo na janela frontal e à direita

a sua disposição nas coordenadas do mapa UV.
5.2 A estrutura da luz nos jogos e a sua relação com a teoria da

parametrização dos objetos
É a luz que dá volume, forma, cor e sentido aos objetos no mundo real e, da mesma
forma, no mundo digital. “Light, seeking light, doth light of light beguile; So are you find
where light in darkness lies, Your light grows dark by losing of your eyes” disse William
Shakespeare [1598]19.
Desde os gregos, com seu teatro, a questão da luz ocupava um papel fundamental.
Tendo um forte impacto na estruturação dos elementos cênicos e na produção de sentido,
do teatro ao cinema, temos todo um desenvolvimento de linguagem que faz com que a
iluminação se constitua em um elemento nuclear da linguagem, em um real produtor de
sentido, de sentimentos e vida, como muito bem já havia nos mostrado, Goethe [1810] já no
Século XIX, com a sua Zur Farbenlehre, (Sobre a Teoria das Cores) (figura 6).
Figura 6 : Retrato de Goethe e sua Roda das Cores,

hoje usada como estrutura do padrão cromático e da luz digital.
19 “Luz, buscar a luz, por ventura a luz nos desvia da luz? Então se você buscar a luz onde há trevas, A sua
luz se esmaece na escuridão pela perda de sua visão”.

Sumário
Nos jogos, a luz comporta em funções (e propriedades) técnicas e semânticas. Ela

participa da construção formal do objeto; dirige e molda o sentido perceptivo20 do jogador
em tempo real durante todo o processo do jogo. A luz acentua ou diminui um conceito ou
ideia durante o jogo, dependendo de sua estrutura, sua cor, sua intensidade, de seu FOV
ou de seu Falloff, de seu foco, de seu ponto de origem, de sua animação, etc. Pode ser a
responsável pelo anúncio sígnico de que algo irá acontecer, ser o detonador de um estado
de tensão ou de medo no jogo, de êxtase e assim por diante. Ela é a alma oculta e amorosa
de todas as coisas que existem, seu fundamento ontológico mais íntimo.
Enfim, a iluminação possui um papel fundamental na constituição do quadro visual-
perceptivo-afetivo do jogo, sendo inclusive a responsável pelo ocultamento ou revelação-
acentuamento de todos os demais elementos tridimensionais do jogo. A sua presença, regulada
dentro de princípios de iluminação que conduzem parte da estrutura do jogo, é responsável
pela valorização e ênfase das personagens e dos objetos e da arquitetura (static meshes). Sem
a sua presença os elementos do jogo se tornam artificiais, pois perdem o elemento mais básico
de sua ligação com o ambiente. Este é dado pela sombra, que na sua ausência, transforma o
que poderia ser um cenário realista em um ambiente plastificado, incidindo drasticamente na
redução da sensação de presença [Pinheiro 2012] e do sentimento de imersão [Murray 2003].
Nessa direção é que Bahia [2006] nos chama a atenção para a relação existente entre
iluminação e história da arte. Em diferentes momentos e períodos os artistas trabalhavam
pontos de luz que estruturavam semanticamente o trabalho representado, transmitindo
maior ou menor realismo, conduzindo ou se afastando de uma produção estética que
produzisse a verossimilhança.
Ao pensar a questão do ponto de luz na produção de sentido da obra de arte, em uma
comparação entre o trabalho de Da Vinci e Tintoretto [1518-1594], Bahia [2008] identifica
neste último qualias simbólicas que o colocam como um construtor de cena na qual a luz
evidencia o seu papel formador: ao colocar a cena em ruínas, com seu anjo entre dois
mundos e com a luz divina projetando-se sobre ele, o artista estrutura uma densidade sem
par para a cena pictórica (figura 7).
Figura 7 : Anunciação de Tintoretto, entre 1583 e 1587.
20 Referências que aqui podem ser muito elucidativas quanto à função da luz na percepção humana do
mundo são as produzidas pelo fenomenólogo Merleau-Ponty [1945 e 1964].

Sumário
Esta mesma estrutura superlativa aparece nas pinturas de Caravaggio [1571-1610]

e Rembrandt [1606-1669]. Isso nos leva ao fato de que em termos de artes visuais, um dos
elementos mais importantes a serem ressaltados é a iluminação, a qual se faz presente e
notada inclusive desde os primeiros estilos e movimentos artísticos. No caso da percepção
barroca, a iluminação adquire contornos fortes no elemento visual final, passando a ser mais
trabalhada e adquirindo uma superlativa importância na composição final da cena.
É o caso da inspiração temática, pictórica e de iluminação dos jogos Dead Space
2 [2011] e Deus Ex Human Revolution [2011], que inspiram-se fortemente no modelo de
iluminação pictórica do barroco rembrandtiano. Dead Space 2 foi o primeiro jogo a adotar o
conceito de uma equipe dedicada de light design [Milhan 2011], os quais igualmente tomaram
como inspiração o modo de ser da luz barroca, especialmente a pintura de Rembrandt, A
aula de anatomia do Dr. Tulp [1632] (figura 8), na qual o próprio ponto de emissão de luz
tende a se construir como uma personagem própria21.
Figura 8 : A incrível e expressiva iluminação da Aula de anatomia

do Dr. Tulp de Rembrandt.
A união destes dois elementos: parametrização dos objetos e estruturação da luz,

joga um papel fundamental na composição de uma cena com objetos dentro do motor de
jogo. De acordo como organizarmos a parametrização dos mapas de iluminação de nosso
objeto e a disposição das luzes na cena teremos diferentes resultados.
6. Aplicação dos conceitos até aqui desenvolvidos na parametrização

do mapa de iluminação de um objeto tridimensional
Na presente seção iremos aplicar as ideias até aqui delineadas, sobre mapas de
iluminação e parametrização de objetos, na organização de um mapa de iluminação de
um objeto tridimensional, que se destina a ocupar um importante espaço dentro de uma
cena em um mapa no UDK. Enquanto que mostraremos aqui o processo da organização
21 Rachel Cross é a light artist ou light designer de Dead Space 2 que fala sobre o desenvolvimento desta ideia.

Sumário
do mapa de iluminação no software de modelagem Maya 2012 (em nosso site de pesquisa
apresentamos também o tratamento realizado no Cinema 4D para o problema), a versão
utilizada do build, para mostrar os resultados, será a de Julho 2012 UDK Beta - MD5
661430d4df82c524b07a1f4f6c955f90 (figura 9).
Figura 9 : Imagem da referência da Versão de Julho de 2012 do UDK.
O objeto escolhido, dentro dos vários objetos trabalhados em nossa pesquisa será o
de um cubo que sofreu uma transformação homogênea de extrusão em suas seis faces, com
a consequente aplicação de uma textura conceitual. Nós o intitulamos tematicamente com
o nome de Cubo Metafísico.
Figura 10: Apresentação do Cubo Metafísico: nosso objeto de trabalho aqui.
O cubo metafísico (figura 10) foi concebido em 1998 a partir de um curso que um dos
membros da equipe realizou com a artista digital Eni Oken, uma das designers tridimensionais
da Série Zork Nemesis: The Forbidden Lands [1996] e Zork, Grand Inquisidor [1997] e desde
então fez parte de projetos de games e metaversos, como por exemplo, a Ópera Quântica
AlletSator 4.5 [2008].
6.1 A parametrização do mapa de iluminação no Maya 2012

O mapa de iluminação utilizado pelo UDK para o Lightmass se constitui em uma
projeção ortogonal da superfície total do objeto disposta em um plano que segue as
coordenadas XY [Wright 2009]. Como mapa de iluminação, o UDK utiliza um canal de UV

Sumário
do objeto importando, por default, no canal Um de UV do objeto. Ele é armazenado em

uma variável, no painel de Edição do Objeto, designada por Light Map Coordinate Index.
Para o mapa de texturização, o UDK reservará o canal 0 (Zero) das UVs do objeto.
Assim, esse canal Um de UV, produzido no software de modelagem, será utilizado
para a produção do mapa de iluminação do objeto a ser exportado para o UDK. Este canal
corresponderá a um segundo canal de UV criado manualmente no Maya.
Figura 11: Correspondência dos Canais de UV: UDK e Maya
Reservamos então o primeiro canal de UV no Maya para a organização da textura

do objeto e, deste modo ele pode permitir, caso necessário, a sobreposição de faces para
o incremento da resolução da textura, fenômeno designado em inglês pelo termo overlay.
No painel de Edição do Objeto no UDK (figura 13) podemos ter uma ideia da
organização do mapa de iluminação dos objetos e avaliá-la visualmente.
Figure 12 : O painel de Edição do Objeto. Legendas: 1. canais de UV;

2. malha do mapa de iluminação; 3. o Light Map Coordinate Index.
Para mostrarmos a nossa perspectiva metodológica iniciaremos apresentando uma

situação de erro, na qual um mapa de iluminação é construído de forma automatizada
e incidindo em problemas de iluminação dentro do UDK. Após constatarmos o erro, nós
iremos apresentar uma forma de tratar adequadamente o mapa de UV do objeto para a
produção de um mapa de iluminação de qualidade para ser utilizado no UDK.
É comum os usuários dos Softwares de modelagem utilizarem os recursos automáticos
do mesmo e plug-ins para facilitar, automatizar e acelerar o processo de produção.

Sumário
Entretanto, nem sempre um recurso automático permite alcançar resultados melhores

do que os alcançados pelo trabalho manual.
Figura 13 : Mapa UV resultante da opção Automatic Mapping.

Legendas: 1. Cubo; 2. Mapa de UV (Automatic Map).
Figura 14: Os dois erros evidenciados no render:

1. sangramento da textura e da luz; 2. vincos e rupturas nas faces.
Aqui enfocamos a situação dentro do Maya, no qual a opção de mapeamento

Automatic Mapping produz uma versão do mapa UV do objeto, a partir dos eixos X, Y e Z
colocando-o em uma projeção UV que aplana o objeto em coordenadas XY.
Apresentamos um dos objetos de nossa pesquisa, o cubo metafísico com o
correspondente resultado da utilização do processo do Automatic Mapping (figura 13). O
mapa de UV gerado para o objeto com este método produzirá um mapa de iluminação
organizando as faces do objeto nas coordenadas bidimensionais do plano UV, na região
cinza no painel à direita na imagem da figura 13.
No caso apresentado, a organização das faces do objeto poligonal dispostas no plano
UV segue a orientação de cada um dos seis lados do campo tridimensional, correspondendo
às faces correlatas aos eixos X (vista esquerda e direita), Y (vista superior e inferior) e Z (vista
frontal e traseira) das janelas de trabalho do software de modelagem.

Sumário
Com isso cortes na malha do objeto são realizados respeitando a orientação de um

mapeamento cúbico, sem que seja permitido nenhum controle ou ajuste.
O resultado que esse procedimento produz dentro do motor, após o processo do
Lightmass, permite mostrar os erros visíveis do mapa de iluminação gerado com o método
Automatic Mapping (figura 14).
Na imagem capturada do render do objeto na UDK, pode-se visualizar os erros de
iluminação quando adotamos o método do Automatic Mapping. Esse método pode ser
considerado como NÃO ADEQUADO para a produção de um mapa de iluminação de
qualidade [Galuzin 2012 and Hourences 2010], a não ser que, partindo do Automatic Mapping,
o mapa de UV passe por uma profunda edição e modificação manual. Mas será que esta
forma derivada de ajuste da malha no canal de UV se constitui na melhor solução para o
problema? Mostramos agora que na maioria dos casos sempre será necessária a edição da
malha do objeto na UV. Entretanto, nossa pesquisa mostrou que o caminho começado com
o Automatic Mapping, ainda que julgado tentador por muitos, não se constitui no método
mais eficiente, dado que demanda um intenso labor e destreza manual por parte do artista
digital na edição de faces, vértices e pontos dentro do plano UV.
Em nossa pesquisa observamos que se não for possível produzir-se naturalmente um
mapa planar do objeto com todas as suas faces desdobradas e aplanadas na superfície, para
a geração do segundo canal de UV, o método de mapeamento mais adequado geralmente
está relacionado com a forma topológica do objeto. Tomando por base a topologia do
objeto, podemos utilizar o sistema de projeção do mapa de UV que mais se aproxima dela.
No caso modelo do Cubo Metafísico, a topologia mais próxima é a cúbica. Apresentamos na
Figura 15 uma síntese dos passos para se construir o mapa de iluminação.
A figura 15 sintetiza os seguintes passos:
1. Aplanamento das faces selecionadas de acordo com a orientação de seus eixos
guiado pelo gizmo do eixo universal;
2. Reescalonamento e reposicionamento da face central do cubo para abertura de
espaço para encaixe das faces transversais da secção do cubo;
3. Após o aplanamento da face transversal do cubo (ao modo do feito em 1 acima),
reposicionamento dela com relação às demais faces de sua continuidade no plano UV;
4. Seleção de pontos soldagem dos pontos (UV together);
5. Resultado da soldagem dos pontos indicados em 4 acima;
6. Resultado da soldagem de todas as faces transversais resultando em um aplana-
mento completo de uma das faces do cubo;
7. Mostra do processo realizado em todas as seis faces do cubo, resultando no apla-
namento completo do mapa UV.

Sumário
Figura 15 : Passos do processo realizado em todas as seis faces do cubo,

resultando no aplanamento completo do mapa UV.
O resultado obtido por este procedimento pode ser observado na figura 16, a qual
apresenta a renderização do cubo dentro do UDK.
Com isso nós estamos no caminho de produzir um mapa de iluminação de qualidade
para o nosso objeto a ser importando pelo UDK. Dois requisitos ou passos ainda precisam
ser cumpridos.
Em primeiro lugar é importante lembrar que a organização das faces poligonais
do objeto no plano UV corresponde ao que já apresentado na seção 5.1 acima, a uma
parametrização do objeto (um aplanamento do mesmo em termos topológicos).
Então, para que esta parametrização alcance o maior resultado possível na geração
de um mapa de iluminação de qualidade, será necessário que os limites topológicos das
áreas abrangidas pelas linhas exteriores dos grupos contínuos estejam alinhados com a
própria grade do plano UV e, inclusive, respeitando distâncias entre elas que devem ser
múltiplos de 2 (2, 4, 8 pixeis, por exemplo).
Dado este importante passo estamos prontos para exportar o Cubo Metafísico do Maya
para o UDK. Recomendamos que o objeto passe pelo processo de triangulação de suas faces
e seja conferido se as mesmas seguem todas a mesma orientação.
A possibilidade de produzir uma triangulação sem uma adequada e mesma
orientação topológica para o objeto pode incidir em problemas com o mapa de iluminação.
Em exemplos com polífonos com este tipo de triangulação não orientada uniformemente,
a luz pode tender a colidir com uma face e produzir manchas, cortes ou os chamados
sangramentos (bleedings) no material do objeto distorcendo a sua visualização.
O objeto pode ser exportado nos formatos FBX ou ASE. Ainda que o formato ASE
tenha sido descontinuado como plug-in, ele continua funcional. Entretanto, como o objeto
foi modelado e trabalhado em seus mapas UVs no Maya ele foi exportado no formato FBX.

Sumário
As notas do UDK, July 2012 Unreal Development Kit Beta, trazem informações
importantes para orientar os usuários quanto aos requisitos da exportação de recursos no
formato FBX: http://www.unrealengine.com/news/epic_games_releases_july_2012_unreal_
development_kit_beta/.
A figura 16 mostra o Cubo Metafísico em uma cena no UDK e o mapa UV utilizado
para a produção do mapa de iluminação. Ela se constitui na apresentação do corolário
imagético de um processo metodológico que mostra a efetiva possibilidade de se produzir
recursos de arte com qualidade no padrão da indústria internacional de jogos para os artistas
tridimensionais e reforça a necessidade de conceito e técnica trabalharem solidariamente
em nossas atividades.
Figura 16: O resultado final do processo no UDK, com um mapa de iluminação

que valoriza a qualidade artística do objeto.
7. Conclusão
Com o presente artigo buscamos mostrar que seguindo uma metodologia científica,
orientada por conceitos e técnicas, é possível trabalharmos na produção de recursos de arte
de qualidade para o motor de jogos UDK. O apresentado no espaço do artigo se constitui
em um resumo parcial de um relatório de pesquisa no qual trabalhamos detalhadamente
os aspectos apresentados e outros. Para os que tiverem interesse no tema pesquisado,
indicamos o nosso site de pesquisa, topofilosofia.net, na sua seção Pesquisa, dentro da qual
publicamos nosso relatório e suas fontes na íntegra.
Agradecimentos
A Pesquisa tem financiamento parcial da CAPEs, na modalidade de Bolsa de Mestrado
para um dos membros da equipe. Os autores agradecem a leitura da Prof.ª. Dr ª. Arlete dos
Santos Petry que acompanhou e estimulou ao grupo durante todo processo. Agradecemos
ao estímulo dado pelo grupo de pesquisa do CNPq, do Projeto de Pesquisa “Diálogos entre
Arte e Design: Processo de avaliação e revisão de jogo eletrônico educativo em arte” que nos
motivou para a inscrição na Trilha de Tutoriais. Dedicamos o presente artigo, in memoriam,
ao Prof. Ernest Sarlet, filósofo e pedagogo.

Sumário
Referências
Attali, Jacques. 2003. Blaise Pascal ou o gênio francês. Bauru. EDUSC.
Bahia, Ana Beatriz. 2008. Jogando arte na WEB: educação e museus virtuais. Tese
de Doutorado apresentada ao Programa de Pós-graduação em Educação da UFSC.
Orientador Wladimir Antônio da Costa Garcia. Florianópolis.
______. 2006. Iluminação. Artigo digital no Site do Educador do jogo artístico Mansão
de Quelícera. Avaliable from: http://www.casthalia.com.br/a_mansao/preste_atencao/
iluminacao.htm [Consult. em aug 2012].
EPIC Games. Community Forum. BSP. Disponível [on-line] em: http://forums.epicgames.

com/threads/751939-Quais-os-modelos-que-o-UDK-importa. [Consult. em Set 2012].
Galuzin, Alex. 2012. World of Level Design Tutorials: (1) UDK: Lightmap Basics
and 18 Important Principles for Creating and Using Lightmaps; (2) UDK: Lightmap UV
Layout Techniques and How to Create a Second UV Channel in Maya (3) UDK: How
to Fix Lightmap Light/Shadow Bleeding and Seams; (4) UDK: Lightmap Resolution for
Static Meshes and BSP; (4) UDK: Lightmap Common Problems and Solutions. Artigos
[online] do Blog do Autor: World of Level Design (EUA). Avaliable from: http://www.
worldofleveldesign.com/articles.php. [Consult. em Maio 2012].
Game Developers Brasil. Tópico Básico de Edição 1. Disponível [on-line] em:

gamedevelopersbrasil.net/2011/01/19/120/ . [Consult. em Set 2012].
Goethe, Johann Wolfgang. 1810. Zur Farbenlehre. Disponível [on-line] em: http://www.
zeno.org/Literatur/M/Goethe,+Johann+Wolfgang/Naturwissenschaftliche+Schriften/
Zur+Farbenlehre, and see also: http://www.seilnacht.tuttlingen.com/Lexikon/goethe1.htm.
[Consult. em Set 2012].
Bonin, Vincent 2004. Interview with Steve Heimbecker, postado no site da Canadian
Electroacoustic Community (CEC). Disponível [on-line] em: http://cec.sonus.ca/
econtact/9_2/heimbecker.html. [Consult. em Set 2012].
FEIJO, Bruno, CLUA Esteban in SILVA Flávio S. Correia. 2010. Introdução à Ciência da
Computação com Jogos. Elsevier. Rio de Janeiro.
Jameson, Stephen. 2009. Lightmap UVs Tutorial. Artigo do Blog do Autor [online].
Avaliable from: http://stephenjameson.com/tutorials/lightmap-uvs-tutorial/ [Consult. em Set
2012].
Merleau-Ponty, Maurice. 1945. Phénoménologie de la perception. Paris. Gallimard.
______. 1964. Le Visible et l’invisible, suivi de notes de travail. Paris. Gallimard.

Sumário
Millan, Ian. 2011. Dead Space 2 Lighting Developer Diary. Video depoimento-
documentário. Machinima.com. Publicado no YouTube. Disponível [on-line] em: http://youtu.
be/GdM3UnW7J3s. [Consult. em Set 2012].
Murray, Jannet. 2003. Hamlet no holodeck: o futuro da narrativa no ciberespaço. São

Paulo. UNESP.
Mussara, Fábio Luiz Livramento Barreto. 2011. A concepção e criação de caracteres

tridimensionais: metodologia da criação e desenvolvimento de personagens
tridimensionais para games. Dissertação de Mestrado apresentada ao Programa de Pós-
graduação em Tecnologias da Inteligência e Design Digital da PUCSP. Orientador: Luís
Carlos Petry. São Paulo.
Petry, Luís Carlos. 2003. Topofilosofia: o pensamento tridimensional na hipermídia. Tese

de Douturado no Programa de Pós-graduação em Comunicação e Semiótica da Pontífica
Universidade Católica de São Paulo. Orientador: Sérgio Bairon. São Paulo. Disponível [on-
line] em: http://www.topofilosofia.net/textos/index.html. [Consult. em Set 2012].
Pinheiro de Souza, Carlos Augusto. 2012. Imersão e presença nos jogos FPS: uma
aproximação qualitativa. Dissertação de Mestrado apresentada ao Programa de Pós-
graduação em Tecnologias da Inteligência e Design Digital da PUCSP. Orientador: Luís
Carlos Petry. São Paulo.
Rabin, Steve. 2012. Introdução ao desenvolvimento de games: criação e produção

audiovisual. São Paulo. CENGAGE.
Shakespeare, William. 1598. Love´s labour´s lost. London: Cuthbert Burby. Disponível
[on-line] em: http://shakespeare.mit.edu/lll/full.html [Consult. em Set 2012].
Wikipédida. The free encyclopedia. 2012. Static mesh. Disponível [on-line] em: http://
en.wikipedia.org/wiki/Static_mesh [Consultado em Set 2012].
Zork Nêmesis: The Forbidden Lands. 1996. Zombie LLC. Activision. Jogo para as
Plataformas Apple Macintosh , PC : MS-DOS /Windows 95.
Zork, Grand Inquisidor. 1997. Activision. Jogo para as Plataformas Mac OS, Microsoft
Windows.

Sumário
Point Based Graphics e

Aplicações em Jogos
Luciano Silva1
Abstract
Point based Graphics embraces a set of processes, techniques and algorithms for the
acquisition, representation, processing and storage of point clouds, aiming at applications
in graphics processing. As multi and manycore processors have increased their storage and
processing powers, this area has become very attractive for applications that require high
performance graphics, eg, digital games. Within this context, this chapter introduces the
basics of Point Based Graphics, highlighting the main applications in modeling, rendering
and animation in GPU.
Resumo
Point based Graphics refere-se a um conjunto de processos, técnicas e algoritmos para
aquisição, representação, processamento e armazenamento de nuvens de pontos, visando
às aplicações em processamento gráfico. Com o aumento da capacidade de processamento
e armazenamento de processadores multi e many-cores, esta área tornou-se bastante
atrativa para aplicações gráficas que requerem alto desempenho como, por exemplo, jogos
digitais. Dentro deste contexto, este capítulo apresenta as bases de Point Based Graphics,
evidenciando as principais aplicações em modelagem, renderização e animação em GPU.
1 Laboratório de Processamento Gráfico e Mídias Digitais; Faculdade de Computação e Informática,

Universidade Presbiteriana Mackenzie.

Sumário
Introdução
A tecnologia de Point Based Graphics, com o aumento do poder de processamento das
unidades de processamento gráfico (GPU), tem oferecido ao segmento de desenvolvimento
de jogos digitais novas possibilidades para aumento de desempenho das aplicações. Neste
contexto, ao invés de se trabalhar com estruturas de dados complexas, que envolvem, por
exemplo, vértices, arestas e faces, utiliza-se somente uma nuvem de pontos para representar
o objeto a ser processado.
A partir desta nuvem de pontos, com o poder de processamento gráfico e genérico
das GPUs, procedimentos como modelagem, transformações, renderização e animação
são efetuados diretamente nesta nuvem. Mesmo procedimentos considerados não-gráficos
como, por exemplo, simulações de Física ou inferências em Inteligência Artificial podem ser
efetuadas nas nuvens com o auxílio de linguagens como CUDA ou OpenCL.
Assim, dentro deste contexto, este texto tem como objetivo introduzir os conceitos
fundamentais de nuvens de pontos para suporte a Point Based Graphics e processamento
dentro de GPUs, visando às aplicações de desenvolvimento de jogos digitais.
O texto está organizado da seguinte forma:
• a Seção 1.2 traz o conceito de nuvens de pontos e algumas formas para sua
representação
• a Seção 1.3 discute o processo de aquisição de nuvens de pontos através de
scanning 3D
• a Seção 1.4 apresenta funcionalidades de processamento gráfico de nuvens de
pontos através de shaders
• a Seção 1.5 apresenta detalhadamente as funcionalidades de processamento
genérico de nuvens de pontos em GPU, com as arquiteturas CUDA e OpenCL. Como o
processamento de nuvens muitas vezes não requer saída gráfica, deu-se uma atenção
especial a este tópico.
• finalmente, a Seção 1.6 apresenta o fechamento do capítulo e, em seguida, são
apresentadas algumas sugestões de referências bibliográficas.
O autor deseja que este texto possa disponibilizar um suporte simples e direto para
todos aqueles que queiram iniciar trabalhos na área de Point Based Graphics, especialmente
aplicados os aplicados em jogos.
Nuvens de Pontos e Fundamentos de Representação

A estrutura básica em Point Based Graphics é uma nuvem de pontos (point cloud).
Essencialmente, uma nuvem de pontos é uma coleção de pontos com coordenadas
tridimensionais e, normalmente, sem relações entre os pontos. A Figura 1 mostra dois exemplos
de nuvens de pontos, onde se pode ver um cenário (à esquerda) e dois objetos (à direita):

Sumário
Figura 1: Exemplos de nuvens de pontos (cenário e objetos).

Fonte: Jogo Just Cause 2.
A partir de uma nuvem de pontos, pode-se construir uma visualização básica, através
de acumulação de patches, ou se aproximar ou interpolar uma superfície pelos pontos. A
Figura 2 mostra três níveis usuais de visualização de uma malha de pontos: a própria nuvem,
uma acumulação de patches e uma superfície interpolada (já com renderização):
(a) Nuvem (b) Patches acumulados (c) Superfície
Figura 2: Níveis de visualização de uma nuvem de pontos.

Fonte: (Linsen, 2001)
Uma das grandes vantagens de falta de relações entre os pontos reside no fato da
velocidade de alteração das estruturas de representação das nuvens de pontos, uma vez
que, normalmente, não há necessidade de atualização de arestas, faces ou mesmo objetos.
Formalmente, um ponto P em uma nuvem de ponto é uma t-upla formada, geralmente,
pela sua posição (x,y,z) e alguma informação de cor (r,g,b):
Outras informações podem incluir, por exemplo, informações de normais, curvatura,

tangentes, dentre outros. A partir do conceito de ponto, define-se uma nuvem de pontos
como uma coleção indexada de pontos:

Sumário
Para se representar eficientemente pontos e nuvens de pontos, existem diversas

alternativas interessantes para o segmento de jogos digitais. O framework PCL (Point Cloud
Library) (PCL, 2012), por exemplo, é um conjunto de classes em C++ para representação
tanto de nuvens de pontos 2D quanto 3D. A definição de uma nuvem de pontos em PCL
toma, como base, uma estrutura para representar cada ponto e, a partir de um ponto,
constrói-se a nuvem. Abaixo, tem-se um exemplo de representação de nuvem de ponto em
PCL:
A classe PointCloud disponibiliza uma série de métodos básicos para manipulação

de pontos isolados ou conjuntos de pontos. Além desta classe, bastante eficiente para
representação de nuvens de pontos, a PCL ainda disponibiliza duas outras formas básicas
para representação de nuvens: quadtrees e octrees, conforme mostrado na Figura 3:
Figura 3: Quadtree (à esquerda) e Octree (à direita).
Normalmente, uma quadtree é utilizada para representação de nuvens de pontos

bidimensionais, enquanto que octrees são utilizadas para nuvens de pontos tridimensionais.
Aquisição de Nuvens de Pontos

Existem diversas estratégias para aquisição de nuvens de pontos (Gross & Pfister, 2007).
No contexto de jogos digitais, uma maneira bastante comum é via scanners tridimensionais,
como mostrado na Figura 4:

Sumário
Figura 4: Scanner 3D manual, baseado em Visão Estéreo e projeção laser.
A projeção laser permite indicar qual segmento de reta está sendo escaneado. O
sistema duplo de câmeras permite utilizar técnicas de reconstrução 3D, baseadas em Visão
Estereoscópica. A coordenada do ponto que está sendo escaneado pode ser obtida através
de uma intersecção de retas definidas pelas duas câmeras e os planos de projeção das
imagens, conforme mostra a Figura 5:
Figura 5: Esquema de obteção das coordenadas de um ponto baseado em Visão Estereoscópica.
Este esquema exige uma calibração de todo o sistema de aquisição como, por
exemplo, distância entre as câmeras ou estimação das distâncias focais das duas câmeras.
Uma vez calibrado o sistema, a granularidade dos pontos escaneados pode ser controlada
tanto no processo de aquição, quanto no processo de pós-processamento. A Figura 6 mostra
duas nuvens de pontos, com as respectivas superfícies rescontruídas:
Figura 6: Resultado de um processo de scanning para um modelo de jogo.

Sumário
Na imagem da esquerda, tem-se uma nuvem de pontos bastante regular, resultado

comum de um processo de scanning. Na imagem da direita, os pontos foram processados e,
regiões que não necessitam de muitos detalhes podem e devem ser simplificadas.
Os equipamentos para scanning 3D, mesmo para pequenos objetos, ainda tem um
custo elevado. Uma alternativa bastante interessante atualmente é o uso do gadget de
interação para jogo Kinect. Para reconhecer profundidade dos objetos, o Kinect projeta uma
nuvem estruturada de pontos, que pode ser percebida e capturada por câmeras de infra-
vermelho. A Figura 7 apresenta um exemplo de nuvem projetada de pontos pelo Kinect:
Figura 7: Nuvem de pontos projetada pelo Kinect.
O processo de obtenção da nuvem de pontos pelo Kinect pode ser feita através do
Kinect SDK. A seguir, tem-se um exemplo de código que realiza esta tarefa:

Sumário
A partir deste processo de obtenção de imagens e extração de pontos, pode-se

obter nuvens de pontos como mostrado a seguir, onde os pontos foram renderizados como
triângulos (Figura 8):
Figura 8: Nuvem de pontos extraída de imagens do Kinect.
Além dos pontos, o Kinect ainda permite obter animações baseadas em um esqueleto
humano de referência.
Uma vez obtida a nuvem de pontos, as próximas seções abordarão como processá-
las dentro de uma GPU com propósitos gráficos (via shaders) ou com propósitos gerais (via
CUDA ou OpenCL).
Processamento Gráfico de Nuvens de Pontos com Shaders

Shaders são pequenos programas executados dentro de unidades gráficas de
processamento (GPU) e são extremamente adaptados para processamento de nuvens de
pontos devido a sua natureza.
Existem, essencialmente, três tipos de shader:
• Vertex Shaders
• Pixel Shaders
• Geometry Shaders
Os vertex shaders recebem como entrada um vértice (ponto) e retornam um outro
vértice, resultado de alguma transformação. No contexto de nuvens de pontos para jogos,
este tipo de shader é muito utilizado para os mecanismos de modelagem (transformações)
e animação. O código abaixo mostra o código de vertex shader utilizado na simulação de
líquidos baseados em nuvens de pontos em OSGL (OpenGL Shading Language):

Sumário
Outro exemplo bastante importante em animação de nuvens de pontos é conhecido

comumente como sistemas de partículas, conforme mostra o exemplo do vertex shader
abaixo, onde, além da posição, controla-se também parâmetros de ordem física:
Os pixel shaders recebem como entrada um vértice (ponto) e retornam uma cor
associada ao vértice. No contexto de nuvens de pontos de jogos, este tipo de shader é muito
utilizado para os mecanismos de renderização. O trecho de código a seguir mostra parte do
cálculo do Modelo de Phong para nuvens de pontos:
Finalmente, existem os geometry shaders, que permitem, dentro do contexto de

nuvens de pontos, a geração de novos pontos. Como são executados depois dos vertex
shaders, possuem aplicação imediata nos processos de refinamento de nuvens de pontos.

Sumário
Processamento Genérico de Nuvens de Pontos com CUDA e OpenCL

Atualmente, existem duas tecnologias (e linguagens) importantes para processamento
genérico de nuvens de pontos em GPU: CUDA e OPENCL (Silva e Stringhini, 2012).
Linguagem CUDA C
A arquitetura CUDA (Compute Unified Device Architecture) (NVIDIA, 2011) unifica
a interface de programação para as GPUs da NVIDIA, assim como define um modelo de
programação paralela que pode ser usado de forma unificada em dezenas de dispositivos
diferentes. A linguagem CUDA C possibilita que se inclua comandos direcionados às GPUs
da NVIDIA em programas escritos em linguagem C/C++.
Apesar de ser uma interface unificada que possibilita a programação em diferentes
placas gráficas, CUDA possui características intrínsecas ao hardware das placas NVIDIA.
Assim, antes de apresentar o modelo de programação CUDA, uma breve descrição da
arquitetura Fermi será apresentada a fim de justificar o modelo de programação CUDA e
familiarizar o leitor com este tipo de dispositivo que tem sido referenciado como acelerador.
Arquitetura FERMI
As GPUs são compostas de centenas de núcleos (cores) simples que executam o
mesmo código através de centenas a milhares de threads concorrentes. Esta abordagem se
opõe ao modelo tradicional de processadores multicore, onde algumas unidades de núcleos
completos e independentes são capazes de processar threads ou processos. Estes núcleos
completos, as CPUs, possuem poderosas unidades de controle e de execução capazes
de executar instruções paralelas e fora de ordem, além de contarem com uma poderosa
hierarquia de cache. Já as GPUs contam com unidades de controle e de execução mais
simples, onde uma unidade de despacho envia apenas uma instrução para um conjunto
de núcleos que a executarão em ordem. O modelo de execução das GPUs é conhecido
como SIMT (Single Instruction Multiple Threads), derivado do clássico termo SIMD (Single
Instruction Multiple Data). A Figura 9 apresenta as diferenças nas arquiteturas de CPU e GPU.
Figura 9: arquitetura de CPU e de GPU (fonte: NVIDIA, 2011).
A arquitetura Fermi da NVIDIA segue este princípio de dedicar uma maior quantidade
de transístores às unidades de execução, ao invés de dedica-los às unidades de controle e
cache. A Figura 10 apresenta uma visão geral da arquitetura Fermi:

Sumário
Figura 10: visão geral da arquitetura Fermi (fonte: NVIDIA, 2009).
A arquitetura conta com 16 SM (streaming multiprocessors), cada um composto por 32

núcleos de processamento (cores), resultando num total de 512 núcleos. É possível observar
uma cache de segundo nível (L2) compartilhada por todos os SM. A cache de primeiro nível
(L1) é compartilhada pelos 32 núcleos de cada SM. A Figura 11, próxima página, mostra
a hierarquia de cache da Fermi, juntamente com dois outros tipos de memória presentes
na arquitetura. A memória compartilhada (shared memory) pode ser usada explicitamente
pelo programador como uma memória de “rascunho” que pode acelerar o processamento
de uma aplicação, dependendo do seu padrão de acesso aos dados. Esta memória é
dividida fisicamente com a cache de primeiro nível com um total de 64KB, cujo tamanho
é configurável: 16 KB – 48KB para cache e memória compartilhada respectivamente ou ao
contrário. Além dos dois níveis de cache e da memória compartilhada, a Fermi conta com
uma memória global (DRAM) de até 6GB.
Figura 11: hierarquia de memória da FERMI (fonte: NVIDIA, 2009).

Sumário
A Figura 12 apresenta a arquitetura dos SM. Cada um é composto por quatro blocos
de execução controlados por duas unidades escalonamento de warps (grupos de 32 threads).
Figura 12: arquitetura de um SM (Streaming Multiprocessor) (fonte: NVIDIA, 2009).
Além disso, cada SM conta com uma memória cache L1/memória compartilhada de
64KB, já mencionada, e com 32KB de registradores, compartilhados entre todas as threads
que executarão no SM.
Programação CUDA
O modelo de programação de CUDA C é composto de uma parte sequencial executada
na CPU (host) e de uma parte paralela executada na GPU (device). O programador desenvolve
uma função especial chamada kernel que será replicada em até milhares de threads durante
a execução na GPU. As threads realizam as mesmas operações simultaneamente, porém
atuam ao mesmo tempo sobre dados diferentes.
Em primeiro lugar, é importante observar a organização das threads em CUDA (figura
5). Elas são organizadas em blocos e, dentro destes blocos, podem estar dispostas em 1, 2
ou até 3 dimensões. Os blocos são organizados em grades de uma ou duas dimensões. Da
mesma forma, cada thread também terá disponível a informação de a qual bloco dentro da
grade ela pertence. Por exemplo, numa grade 1D, pode-se dizer que a primeira thread entre
todas pertencerá ao bloco 0 e terá seu índice dentro do bloco como 0 (bloco 0, thread 0).

Sumário
A Figura 13 mostra uma representação clássica desta organização, apresentando uma

grade bidimensional (2D), com blocos de threads também bidimensionais (2D) (NVIDIA,
2011). Estas dimensões, assim como a quantidade de threads e blocos em cada uma delas,
são definidas pelo programador no momento em que ele inicia (lança) o kernel.
Figura 13: Organização de blocos e threads (fonte: NVIDIA, 2011).
Além disso, CUDA suporta uma série de tipos de memória que podem ser usadas
pelos programadores para que possam acelerar a velocidade de execução de um kernel.
A Figura 14 mostra de forma esses tipos de memória num dispositivo CUDA. A memória
global (global memory) pode ser escrita ou lida a partir do código que executa na CPU,
chamado usualmente de host. Estas operações são realizadas utilizando-se funções da API
(Aplication Programming Interface) de CUDA.
Internamente, a memória global pode ser acessada por qualquer thread em execução
no dispositivo. Entretanto, a tecnologia usada no desenvolvimento de tal memória não
possui taxa de velocidade de acesso que acompanhe a velocidade dos cálculos que pode ser
obtida pela GPU, tornando-se um gargalo de desempenho. Por conta disso, a organização de
memória conta com outros tipos de memória que podem ser usadas pelo programador para
otimizar o desempenho de acesso à memória. São elas a memória local (shared memory),
compartilhada apenas por threads num mesmo bloco, e os registradores (registers), que não
são compartilhados entre as threads e são alocados previamente pelo compilador. Existe
ainda uma memória somente de leitura, também compartilhada entre todas as threads de
um grid, a memória constante (constant memory), que possui um tempo de acesso melhor
que o da memória global.

Sumário
Figura 14: Organização de memória em CUDA (fonte: NVIDIA, 2011).
Embora os registradores e a memória local possam ser extremamente efetivos na

redução da quantidade de acessos à memória global, o programador deve ser cuidadoso para
que não exceda a capacidade efetiva destas memórias considerando os limites de hardware
da GPU. Cada dispositivo oferece uma quantidade limitada de memória CUDA, que pode
limitar a quantidade de threads que pode executar simultaneamente nos multiprocessadores
de um dispositivo.
Como os registradores e a memória local são compartilhados entre as threads, quanto
maior for a quantidade destes recursos que cada thread necessitar, menor será a quantidade
de threads que poderão executar num processador.
O esquema de escalonamento de threads depende de uma boa quantidade threads
em execução para que se obtenha uma boa utilização do dispositivo. Todas as threads em
um bloco são executadas em conjunto num SM, que por sua vez pode ter múltiplos blocos
concorrentes em execução. Assim, a quantidade de blocos (ocupação) será limitada pela
quantidade de recursos de hardware disponíveis no SM (como a quantidade de registradores
e memória local, por exemplo).
O esquema de escalonamento é baseado em warps – cada bloco é divido em warps
de 32 threads cada, ou seja, o número de warps de um bloco é igual ao número de threads
no bloco dividido por 32. Visto que o escalonamento é realizado em grupo de threads, a
organização em warps serve para que o processador não fique parado quando ocorrer
algum bloqueio num grupo de threads – este será desescalonado e um outro grupo (warp)
poderá ser imediatamente executado. Daí a importância de se ter uma boa quantidade de
threads em execução em cada SM.
CUDA para a linguagem C consiste numa série de extensões de linguagem e de
biblioteca de funções. O modelo de programação assume que o sistema é composto de um
host (CPU) e de um dispositivo (device ou GPU).

Sumário
A programação consiste em definir o código de uma ou mais funções que executarão

no dispositivo (kernel) e de uma ou mais funções que executarão no host (a main(),
por exemplo). Quando um kernel é invocado, centenas ou até milhares de threads são
iniciadas no dispositivo, executando simultaneamente o código descrito no kernel. Os dados
utilizados devem estar na memória do dispositivo e CUDA oferece funções para realizar esta
transferência.
Exemplo: soma de nuvens de pontos em CUDA

O código a seguir apresenta um exemplo que código em CUDA que implementa a
soma de vetores no dispositivo. O comando de invocação do kernel define a quantidade de
threads e as dimensões do bloco e da grade.
A partir deste código, é possível observar algumas das principais características da

programação CUDA. São elas:

Sumário
• uso da palavra-chave __global__ que indica que a função é um kernel e que só

poderá ser invocada a partir do código do host, criando uma grade de threads que
executarão no dispositivo (linha 05);
• uso das variáveis pré-definidas blockDim.x, blockIdx.x e threadIdx.x que identificam
o bloco e a thread dentro do bloco através de suas coordenadas (linha 06);
• uso da função cudaMalloc() que aloca memória no dispositivo (linhas 21 a 23);
• uso da função cudaMemcpy(), que copia os dados da memória do host para a me-
mória do dispositivo (linhas 27 e 28) e vice-versa (linha 40);
• invocação do kernel e definição de suas dimensões (linha 36);
• uso da função cudaFree(), para liberar a memória do dispositivo (linhas 43 a 45).
Linguagem OpenCL
OpenCL (Munchi, 2011) possui uma filosofia ligeiramente diferente de CUDA. A ideia
é que a linguagem e seu sistema de tempo de execução sirvam como uma camada de
abstração ao hardware heterogêneo que é extremamente comum nos dias de hoje. Assim,
um programa OpenCL tem o objetivo de aproveitar todos os dispositivos presentes na
máquina, tais como processadores multicore, GPUs, DSPs (Digital Signal Processors), entre
outros. Uma aplicação que executa em um hardware heterogêneo deve seguir os seguintes
passos:
1. Descobrir os componentes que compõem o sistema heterogêneo.
2. Detectar as características do hardware heterogêneo tal que a aplicação possa se
adaptar a elas.
3. Criar os blocos de instruções (kernels) que irão executar na plataforma heterogênea.
4. Iniciar e manipular objetos de memória.
5. Executar os kernels na ordem correta e nos dispositivos adequados presentes no
sistema.
6. Coletar os resultados finais.
Estes passos podem ser realizados através de uma série de APIs do OpenCL juntamente
com um ambiente de programação e execução dos kernels. Esta seção apresenta um resumo
do modelo de abstração do OpenCL juntamente com um exemplo simples de código.
Em primeiro lugar, é importante conhecer o modelo de plataforma heterogênea do
OpenCL. Ele é composto por um host e um ou mais dispositivos OpenCL (devices). Cada
dispositivo possui uma ou mais unidades de computação (compute units), que por sua vez
são compostos por um conjunto de elementos de processamento (processing elements). A
Figura 15 apresenta esta organização.

Sumário
Figura 15: modelo de plataforma do OpenCL (fonte: Munchi, 2011)
O host é conectado a um ou mais dispositivos e é responsável por toda a parte

de inicialização e envio dos kernels para a execução nos dispositivos heterogêneos. Os
dispositivos normalmente são compostos por unidades de computação que agrupam uma
determinada quantidade de elementos de processamento. Em relação a CUDA, as unidades
de computação correspondem aos Streaming Multiprocessors da GPU (dispositivo) e os
elementos de processamento correspondem aos núcleos (cores). Um dispositivo, portanto,
pode ser uma CPU, GPU, DSP ou outro qualquer, dependendo da implementação do
OpenCL.
O modelo de execução define que uma aplicação OpenCL é composta por um
programa host e um conjunto de kernels. O programa host executa no host (normalmente
uma CPU) e os kernels executam nos dispositivos disponíveis.
O programa host, ou simplesmente host, envia o comando de execução de um kernel
para um dispositivo. Isto faz com que várias instâncias da função que implementa o kernel
sejam executadas no dispositivo alvo. Em OpenCL estas instâncias são chamadas de work-
items (itens de trabalho) e correspondem às threads de CUDA. Assim como em CUDA, cada
thread ou work-item é identificado por suas coordenadas no espaço de índices (que aqui
também pode ter até 3 dimensões) e correspondem ao seu global ID.
Os work-items são organizados, por sua vez, em work-groups. Estes, oferecem uma
maneira de estabelecer granularidades diferentes aos grupos de itens de trabalho, o que
normalmente facilita a divisão de trabalho e a sincronização. Os work-groups correspondem
aos blocos de CUDA e podem ser situados num espaço de até três dimensões. Assim, os work-
items possuem dois tipos de coordenadas: local (dentro do work-group) e global (dentro do
conjunto completo de work-items em execução).
O host deve ainda definir um contexto (context) para a aplicação OpenCL. Um
contexto define o ambiente de execução no qual os kernels são definidos e executam e
é definido em termos dos seguintes recursos: dispositivos, conjunto de kernels, objetos de
programa (códigos fonte e executável dos kernels que executam a aplicação) e objetos de
memória (dados que serão utilizados pelos kernels durante o processamento). Assim, um
contexto é todo o conjunto de recursos que um kernel vai utilizar durante sua execução.

Sumário
O contexto é definido em tempo de execução pelo host de acordo com os dispositivos

disponíveis na máquina alvo. Para possibilitar uma escolha dinâmica do dispositivo onde os
kernels vão executar o OpenCL compila os kernels dinamicamente, gerando os objetos de
programa, portanto, em tempo de execução.
A interação entre o host e os dispositivos é realizada através de uma fila de comandos
(command-queue). Os comandos são colocados nesta fila e aguardam seu momento de
executar. A fila é criada pelo host e conectada a um dispositivo logo após a criação do
contexto. Esta fila suporta três tipos de comandos: execução de kernel, transferência de
dados (objetos de memória) e comandos de sincronização.
Os comandos colocados em uma fila executam de forma assíncrona com relação ao
host. Comandos de sincronização podem ser utilizados caso uma ordem deva ser estabelecida.
Os comandos na fila normalmente executam em ordem (in-order execution), porém algumas
implementações de OpenCL podem oferecer o modo de execução fora de ordem (out-of-
order execution), que prevê uma execução assíncrona dos comandos enfileirados.
O modelo de memória do OpenCL define dois tipos de objetos de memória: buffers
(blocos contíguos de memória aos quais é possível mapear estruturas de dados) e imagens.
Estas, podem ser manipuladas através de funções específicas presentes na API do OpenCL.
O modelo de memória define cinco diferentes regiões (Figura 16, próxima página):
• Host memory: visível apenas ao host.
• Global memory: permite acesso para leitura e escrita a partir de todos os work-i-
tems em todos os work-groups.
• Constant memory: é uma memória global que é inicializada pelo host e permite
acesso somente de leitura aos work-items.
• Local memory: é compartilhada apenas entre os work-items de um mesmo work-group.
• Private memory: é privada a cada work-item.
Figura 16: Regiões de memória de OpenCL (fonte: Munchi, 2011)

Sumário
A interação entre o host e o modelo de memória pode ocorrer de duas maneiras:

cópia explícita ou mapeamento de regiões de um objeto de memória. Na cópia explícita,
comandos de transferência entre host e dispositivos são enfileirados na fila de comandos
e podem ser executados de forma síncrona ou assíncrona. No método de mapeamento,
os objetos de memória são mapeados na memória do host, que pode também realizar
acessos a estes objetos. O comando de mapeamento também deve ser enfileirado na fila de
comandos.
Exemplo: soma de nuvens de pontos em OpenCL

Os códigos a seguir apresentam um exemplo de soma de vetores em OpenCL. Este
exemplo é baseado em um tutorial oferecido pelo OLCF (Oak Ridge Leadership Computing
Facility), um dos maiores centros de processamento de alto desempenho do mundo (OLCF,
2012).
O primeiro código apresenta o código do kernel, que pode ficar num arquivo separado
(.cl) ou pode ser formatado no próprio código como uma string-C. Este código será passado
como argumento à função OpenCL que o compilará em tempo de execução.
A partir deste código é possível observar algumas características de OpenCL:

• A definição de um kernel é feita através de uma função que utiliza o modificador __kernel
(linha 01).
• O modificador __global indica que os parâmetros estão na memória global do
dispositivo (linhas 01 a 03).
• A função get_global_id() retorna o identificador global da thread (work item) na
dimensão 0 (linha 06).
• A verificação do identificador (linha 07) é comumente realizada neste tipo de
computação, pois por motivos de desempenho é possível que threads a mais venham a ser
lançadas. A verificação serve para que somente as threads “dentro do problema” executem
o trabalho. Este tipo de verificação também é comum em CUDA.
• Na linha 08 a soma é realizada (n threads serão iniciadas e cada uma realizará uma
soma).

Sumário
O código a seguir apresenta a main() juntamente com funções auxiliares do OpenCL

que devem ser executadas pelo host. Para reduzir o tamanho do código os testes de erro
retornados pelas funções não foram realizados.

Sumário

Sumário
A seguir, destaca-se as principais características de OpenCL presentes no código:

• Na linha 55 é definido o localSize que é a quantidade de work items em cada work
group – 64 neste caso. Isto equivale em CUDA a definir a quantidade de threads em cada
grupo.
• A linha 59 define a quantidade total de work items lançados (globalSize). Num pri-
meiro momento pensaríamos que este número deve ser igual ao tamanho do vetor (n).
Porém, globalSize deve ser divisível por localSize, por isso o arredondamento realizado nesta
linha.
• Entre as linhas 61 e 72 é realizado o setup do OpenCL: plataforma, dispositivo, con-
texto e fila de comandos (command queue).
• Entre as linhas 75 e 88 o kernel é lido e compilado.
• Entre as linhas 90 e 105 os dados são enviados ao kernel no dispositivo.
• Na linha 108 o kernel é enfileirado e por fim lançado no dispositivo.
• Na linha 112 o host espera a finalização do kernel (sincronização).
• Na linha 115 o resultado é lido da memória do dispositivo.
Comentários Finais
Conforme evidenciado no texto, um dos grandes motores propulsores da tecnologia
atual de Point Based Graphics são GPUs, que disponibilizam, além de suporte a operações
gráficas como modelagem, renderização e animação, suporte a operações como Física e
Inteligência Artificial.
Esta área em jogos digitais, apesar de recente, tem oferecido diversas oportunidades
de pesquisas tanto no desenvolvimento de novas técnicas e algoritmos para nuvens de
pontos, como também de aplicação direta em game engines.
Espera-se, com o caráter introdutório deste texto, que as bases de nuvens de pontos
tenham sido compreendidas, assim como as possibilidades de desenvolvimento tanto para
o contexto gráfico como para contextos mais genéricos.

Sumário
Referências
FARBER, R. CUDA Application Design and Development. New York: Morgan
Kaufmann, 2011.
FARIAS, T.S.M.C., TEIXEIRA, J.M.N.X., LEITE, P.J.S., ALMEIDA, G.F., TEICHRIEB, V.,
KELNER, J. High Performance Computing: CUDA as a Supporting Technology for Next
Generation Augmented Reality Applications. In: RITA, 16(1), 2009, pp. 71-96.
GASTER, B., HOWES, L., KAELI, D.R., MISTRY, P. Heterogeneous Computing with
OpenCL. New York: Morgan Kaufmann, 2011.
GROSS, M., PFISTER, H. Point-Based Graphics. New York: Morgan Kaufmann, 2007.
KIRK, D.B., HWU, W.W. Programming Massively Parallel Processors: A Hands-on

Approach. New York: Morgan Kaufmann, 2010.
LINSEN, L. Point Cloud Representation. Karlsruhe, Alemanha: Universität Karlsruhe,

2001.
MUNSHI, A., GASTER, B., MATTSON, T.G., FUNG, J., GISBURG, D. OpenCL
Programming Guide. New York: Addison-Wesley Professional, 2011.
NVIDIA Corporation, FERMI Whitepaper, 2009.
NVIDIA Corporation, NVIDIA CUDA C Programming Guide - 4.0, 2011.
OLCF, Oak Ridge Leadership Computing Facility Tutorial, disponível em http://www.

olcf.ornl.gov/training_articles/opencl-vector-addition/, acessado em abril de 2012.
OPENCV, OpenCV GPU, disponível em http://opencv.willowgarage.com/ wiki/OpenCV_

GPU, acessado em abril de 2012.
PCL. (2012). Point Cloud Library. Fonte: Point Cloud: http://pointclouds.org, Acesso em
01/08/2012.
SANDERS, J., KANDROT, E. CUDA by Example: An Introduction to General-Purpose

GPU Programming. New York: Addison-Wesley, 2010.
SCARPINO, M. OpenCL in Action: How to Accelerate Graphics and Computations. New

York: Manning Publications, 2011.
SILVEIRA, C.L.B., SILVEIRA, L.G.S. Programação Introdutória em OpenCL e Aplicações

em Realidade Virtual e Aumentada. In: Tendências e Técnicas em Realidade Virtual e
Aumentada (Capítulo 3), Anais do SVR’2010, pp. 65-101.

Sumário
STRINGHINI, D., SILVA, L. Programação em CUDA e OpenCL para Realidade Virtual

e Aumentada. In: Tendências e Técnicas em Realidade Virtual e Aumentada
(Capítulo 1), Anais do SVR’2012, pp. 1-35.
SINHA, S.N., FRAHM, J.M., POLLEFEYS, M., GENC, Y. GPU-based Video Feature
Tracking and Matching. Relatório Técnico TR 06-012, Departamento de Ciência da
Computação, Universidade da Carolina do Norte – Chapel Hill, 2006.
SIZINTESEV, M., KUTHIRUMMAL, S., SAMARASEKERA, S., KUMAR, R., SAWHNEY,

H.S., CHAUDHRY, A. GPU Accelerated Real-time Stereo for Augmented Reality. In:
Proceedings of the 5th International Symposium 3D Data Processing, Visualization
and Transmission (3DPVT), 2010.

Sumário
A diagramação deste livro eletrônico foi realizada pela Editora Feevale. O arquivo está em PDF e
formato A4 para que seja possível a impressão de partes do texto. Os botões interativos presentes no
arquivo digital não aparecerão na impressão caso ela seja feita. E-book de distribuição gratuita.

Jogos Eletronicos Na Pratica 2 Ed

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Jogos Eletronicos Na Pratica 2 Ed

Enviado por

Direitos autorais:

Formatos disponíveis

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 1

Associação Pró-Ensino Superior em Novo Hamburgo - ASPEUR

Jogos Eletrônicos na Prática

Novo Hamburgo - Rio Grande do Sul - Brasil

Presidente da Aspeur Organização do Evento

Dados Internacionais de Catalogação na Publicação (CIP)

Modo de acesso: World Wide Web

l. Jogos Eletrônicos - Simpósios. 2. Games. 3. Tecnologia. I. Branco,

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 5

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 6

Neste ano, o Simpósio Brasileiro de Jogos e Entretenimento Digital (SBGames) chega

A equipe do XI SBGames deseja a todos uma boa leitura.

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 7

Tá vivo, tá aí. Use-o sem moderação.

Dos chairs dos tutorias SBGames 2012

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 8

Gameficação - Uma Análise das Técnicas de Engajamento

Introdução ao Desenvolvimento de Games com GWT e HTML5........35

Organizando os Mapas de Iluminação dos Assets de Arte para os

Point Based Graphics e Aplicações em Jogos......................................103

A Evolução das Técnicas

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 10

melhor é tal experiência. A importância da inteligência artificial está na convergência

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 11

Figure 1: Sátira da percepção de um agente

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 12

4.2 Maquinas de estado

Figure 2: Maquina de estados de um agente

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 13

Figure 3: WayPoints em Halaa

Assim como as árvores de possibilidades nas busca informadas, os WayPoints são

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 14

4.4 Algoritmos Genéticos

4.5 Redes Neurais

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 15

à qualidade da solução e à velocidade de aprendizado. A idéia de criar um jogo que

Figure 4: Aprendizado por reforço

O grande problema da rede neural mal desenvolvida é o aprendizado não convergir

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 16

Figure 5: Cena de Black and White

5.1 Behavior Tree

Figure 6: Árvore de comportamento

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 17

5.2.1 Steering Behavior

Figure 7: Campo sobre um agente

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 18

O projeto de um sistema de navegação seguindo Steering Behaviors é completamente

Figure 8: Comportamento AvoidNeighbors

• StayOnPath: comportamento que mantém o agente atraído a um percurso.

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 19

5.2.2 Navigation Mesh

Figure 9: Navigation Mesh em Halaa

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 20

5.3 Planning GOAP (Goal-Oriented Action Planning)

Figure 10: Processo de formação de solução

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 21

[2003] Orkin, J., 2003. Applying goal-oriented action planning to games.

[2009] Pilosu, R., 2009. Coordinating agents with behaviour trees.

[2004] Reynolds, C. W., 2004. Steering behaviors for autonomous characters.

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 22

Gameficação - Uma Análise

1 Universidade Federal de Santa Catarina, Departamento de Engenharia e Gestão do Conhecimento, Brasil.

Jogos Eletrônicos na Prática Livro de Tutoriais do SBGames 2012 23