Jogos Eletrônicos na Prática - 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 Argemi Machado de Oliveira Reitor da Universidade Feevale Ramon Fernando da Cunha Pró-Reitora de Ensino Inajara Vargas Ramos Pró-Reitora de Extensão e Assuntos Comunitários Gladis Luisa Baptista Pró-Reitor de Pesquisa e Inovação João Alcione Sganderla Figueiredo Pró-Reitor de Planejamento e Administração Alexandre Zeni Coordenação Editorial Inajara Vargas Ramos Realização Instituto de Ciências Sociais Aplicadas – ICSA Curso de Jogos Digitais Editora Feevale Celso Eduardo Stark Daiane Thomé Scariot Graziele Borguetto Souza Capa Eduardo Fernando Müller Gabriel Hilgert Editoração Eletrônica Daiane Thomé Scariot Organização Editorial Kaline Hilgert Perius

Organização do Evento Coordenador Geral Carla Castanho (UnB) Trilha de Computação Ricardo Nakamura (USP) Licínio Gomes Roque (Universidade de Coimbra, Portugal) Rodrigo Bonifácio (UnB)

Games for Change Gilson Schwartz (USP - Cidade do Conhecimento) Mostra de Artes Suzete Venturelli (UnB) Felipe Ferreira Costa (IESB) Coordenadores de Publicação

Trilha de Arte e Design Maria das Graças Chagas (PUC-Rio) Tiago Barros P. e Silva (UnB)

(Publication Chairs) Luciana Rocha Clua (PUC-Rio) Luiz Gonzaga (Unisinos)

Trilha da Indústria Fred Vasconcelos (Abragames) Saulo Camarotti (IESB/Behold Studios) Luiz Sakuda (USP)

Comissão Especial de Jogos e Entretenimento Digital da SBC Esteban Clua (UFF) Bruno Feijó (PUC-RIO) Soraia Musse (PUC-RS) Carla Castanho (UnB) Ricardo Nakamura (USP)

Trilha de Cultura Roger Tavares (UFRN) Nelson Zagalo (Univ. do Minho, Portugal) Mauricio Miranda Sarmet (UnB) Tutoriais Marsal Branco (Universidade Feevale) Silvano Malfatti (Univ. do Tocantins) Marcus Vinicius Lamar (UnB) Festival de Jogos Independentes Bruno Campagnolo (PUC-PR) Artur Mittelbach (PUC-PR) Guilherme Novaes Ramos (UnB)

Steering Committee (Comitê Volante) Luiz Gonzaga (Unisinos) João Mattar (Univ. Anhembi Morumbi / PUC-SP) Joao Ricardo Bittencourt (Unisinos) Juliano Barbosa Alves (Abragames) Lynn Alves (UNEB) Rafael Dubiela (UFPR)

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


4

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


5

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


6

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.


7

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


8

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.


10

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.


11

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


12

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.


13

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


14

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


15

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


16

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


17

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


18

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


19

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


20

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


21

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.


22

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.


23

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)


24

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


25

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.


26

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.


27

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)


28

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


29

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) Técnicas de Engajamento Achievements ou Badges

Características Reforçadas

Perfil do Jogador

Autonomia, auto-confiança, desafio, feedback, metas, escapismo, compulsão.

Realizadores, Socializadores, Exploradores

Motivação intrínseca, Desafios e

auto-confiança,

Missões

desafio, feedback, metas, escapismo, compulsão.

Rankings e Leader Boards

Autonomia, auto-confiança, desafio, metas, interação

Realizadores, Exploradores

Predadores, Socializadores

social. Motivação intrínseca, Progress Bar

auto-confiança, desafios, feedback, metas, compulsão.

Todos

Gifting

Interação social.

Socializadores


30

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


31

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.


32

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


33

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.


34

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: [email protected]


35

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


36

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.


37

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.


38

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.


39

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. Referese ao contexto de renderização, podendo ser utilizado para desenhar formas e imagens no objeto Canvas. 3.3.1 Principais métodos 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


40

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. 3.4.1 Principais métodos 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,


41

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:

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

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


42

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


43

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. public class Main implements EntryPoint { private Canvas canvas; private Context2d context; private static final int WIDTH = 800; private static final int HEIGHT = 600; private Timer timer; @Override public void onModuleLoad() { canvas = Canvas.createIfSupported(); if (canvas == null) { RowotPanel.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”); canvas.setCoordinateSpaceWidth(WIDTH); canvas.setCoordinateSpaceHeight(HEIGHT); 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(“rgba(0,50,255,1)”); context.setFillStyle(cor); context.fillRect(0, 0, WIDTH, HEIGHT); } }

Quadro 2 – Game Loop


44

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.height)){ return true; } else { return false; } } }

Quadro 3 – Objeto Retangulo


45

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.


46

Sumário

public class Main implements EntryPoint { private Canvas canvas; private Context2d context; private static final int WIDTH = 800; private static final int HEIGHT = 600; 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(); } public void draw() { //desenha fundo CssColor cor; cor = CssColor.make(“rgba(0,50,255,1)”); context.setFillStyle(cor); context.fillRect(0, 0, WIDTH, HEIGHT); //desenha bola e base cor = CssColor.make(“rgba(0,255,50,1)”); context.setFillStyle(cor); context.fillRect(bola.getX(), bola.getY(), bola.getWidth(), bola.getHeight()); context.fillRect(base.getX(), base.getY(), base.getWidth(), base.getHeight()); } }

Quadro 4 – Animação


47

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. public class Main implements EntryPoint { ... private boolean keyLeft = false; private boolean keyRight = false; @Override public void onModuleLoad() { ... 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; } } }); }


48

Sumário

public void update() { ... if ((keyLeft) && (base.getX()>0)) { base.setX(base.getX()-10); } if ((keyRight) && (base.getX()+base.getWidth()
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. public class Main implements EntryPoint { ... @Override public void onModuleLoad() { ... initMouseHandlers(); } public void initKeyHandlers() {... public void initMouseHandlers() { canvas.addMouseMoveHandler(new MouseMoveHandler() { @Override public void onMouseMove( MouseMoveEvent event) { int x = event.getX();


49

Sumário

x = x*WIDTH/Window.getClientWidth(); base.setX((x-base.getWidth()/2)); } }); canvas.addTouchMoveHandler( new TouchMoveHandler() { @Override public void onTouchMove(TouchMoveEvent event) { int x = event.getTouches().get(0). getClientX(); x = x*WIDTH/Window.getClientWidth(); 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. public class Main implements EntryPoint { ... private ImageElement imgBola = ImageElement.as(new Image(“bola.png”).getElement()); private ImageElement imgBase = ImageElement.as(new Image(“base.png”).getElement()); @Override public void onModuleLoad() {... public void initKeyHandlers() {... public void initMouseHandlers() {... public void update() {... public void draw() { //desenha fundo CssColor cor; cor = CssColor.make(“rgba(0,50,255,1)”);


50

Sumário

context.setFillStyle(cor); context.fillRect(0, 0, WIDTH, HEIGHT); //desenha bola e base context.drawImage(imgBase, base. getX(), base.getY()); context.drawImage(imgBola, 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.


51

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 Acessado em setembro, 2011. Google Web Toolkit API Reference. Disponível em Acessado em setembro, 2011. Google Web Toolkit. Disponível em Acessado em setembro, 2011. Rabin, S., 2012. Introdução ao desenvolvimento de games, São Paulo: Cengage, 2ª Edição.


52

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.


53

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.


54

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


55

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.


56

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.


57

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


58

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


59

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.


60

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


61

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.


62

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.


63

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.


64

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.


65

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


66

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


67

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


68

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


69

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.


70

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.PlayQueued (“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 BulletSpawn); - 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 é disparada;


71

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


72

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:


73

Sumário

public class BulletHit : MonoBehaviour { void OnCollisionEnter (Collision other) { if (other.gameObject.tag == “Bullet”) { Destroy (gameObject); Destroy (other.gameObject); } } } 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).


74

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


75

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


76

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


77

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


78

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


79

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


80

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.


81

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.


82

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


83

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 Inteligência e Design Digital (TIDD); [email protected], [email protected]. 2 Pontifícia Universidade Católica de São Paulo - Brasil; Programa de Pós-graduação Inteligência e Design Digital (TIDD); [email protected]. 3 Universidade Federal de Rondônia (UNIR); [email protected]. 4 Pontifícia Universidade Católica de São Paulo - Brasil; Programa de Pós-graduação Inteligência e Design Digital (TIDD); [email protected]. 5 Pontifícia Universidade Católica de São Paulo - Brasil; Programa de Pós-graduação Inteligência e Design Digital (TIDD); [email protected]. 6 Pontifícia Universidade Católica de São Paulo - Brasil; Programa de Pós-graduação Inteligência e Design Digital (TIDD); [email protected].


em Tecnologias da em Tecnologias da

em Tecnologias da em Tecnologias da em Tecnologias da

84

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


85

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.


86

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.


87

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.


88

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.


89

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


90

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


91

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


92

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 visualperceptivo-afetivo do jogo, sendo inclusive a responsável pelo ocultamento ou revelaçãoacentuamento 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].


93

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.


94

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


95

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.


96

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.


97

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 aplanamento completo de uma das faces do cubo; 7. Mostra do processo realizado em todas as seis faces do cubo, resultando no aplanamento completo do mapa UV.


98

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.


99

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.


100

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.


101

Sumário

Millan, Ian. 2011. Dead Space 2 Lighting Developer Diary. Video depoimentodocumentá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ósgraduaçã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 [online] 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ósgraduaçã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.


102

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.


103

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


104

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:


105

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:


106

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.


107

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


108

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


109

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.


110

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:


111

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


112

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


113

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.


114

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


115

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:


116

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


117

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


118

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-oforder 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-items 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)


119

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


120

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.


121

Sumário


122

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 primeiro 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, contexto 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.


123

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.


124

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.


125

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 Eletrônicos na Prática - 2ªed

Recommend Documents