Integrantes: Francis Birck Moreira & Henrique Dallas Costa Lovison

Transcrição

1 Integrantes: Francis Birck Moreira & Henrique Dallas Costa Lovison I - Introdução No trabalho final da disciplina de Computação Gráfica temos a oportunidade de colocar em prática os conhecimentos adquiridos e conceitos observados ao longo do semestre. Uma escolha usual para um projeto final é o desenvolvimento de um jogo. Nossa opção não foi diferente. Em virtude do tempo disponível para a conclusão do trabalho, decidimos melhorar um jogo anteriormente desenvolvido na disciplina de Projetos em Computação Gráfica. Com o nome de RocketRider, ele foi desenvolvido na Unity Engine por Henrique Dalla Costa Lovison, Kassius Vargas Prestes e Jorge Vale Luz. Basicamente, era um jogo de shooter 2D, apesar da modelagem utilizada ser toda em três dimensões. Como esse jogo nada mais era do que uma demonstração, várias melhorias ficaram pendentes para uma nova versão a ser lançada no futuro. É justamente nesse ponto que focamos nosso trabalho, com o intuito de melhorar a jogabilidade e alguns aspectos visuais do jogo original. II Desenvolvimento Nossa ideia inicial era utilizar a engine de jogos Panda3D para a criação de um jogo simples em que pudéssemos aplicar iluminação, sombras, texturização, entre outras coisas. O Panda3D possui código aberto e é utilizado pela Disney para a criação de alguns jogos como o Piratas do Caribe Online. O framework pode ser utilizado nas linguagens de C++ ou, preferencialmente, Python. Depois de termos estudado brevemente a engine, mudamos de ideia quanto à sua utilização: apesar de permitir C++, todos os exemplos que vinham com ela eram escritos em Python. Concluímos que a biblioteca foi pensada para ser usada quase que totalmente nessa linguagem e o C++ aparece apenas como uma linguagem auxiliar; ou seja, é a linguagem core da engine, devido à necessidade de desempenho, e serve na maior parte do tempo apenas para estender o Panda3D. Como, no entanto, nenhum de nós dois tem experiência considerável com Python, decidimos por desistir do plano inicial e seguir uma outra vertente. Unity A Unity Engine surgiu então como uma possibilidade. A ela foi dada grande ênfase na disciplina de Projeto em Computação Gráfica. Nela pode-se programar nas linguagens C#, JavaScript e Boo. Um das principais características é o fato de que assets (os recursos do jogo) são automaticamente importados (e reimportados) se são atualizados. Basta arrastá-los para a pasta do projeto e a Unity se encarrega da importação, permitindo uma grande variedade de formatos. A Unity disponibiliza um editor de cenas e terrenos básico (no qual foram desenvolvidos os

2 estágios do RocketRider). Além disso, dá suporte ao uso de shaders e ao PhysX, com detector de colisão, soft bodies e ragdoll. O plano B consistiu de uma expansão do jogo RocketRider, criado para a disciplina de PCG por um dos integrantes da dupla, mais Kassius Prestes e Jorge Luz. A ideia apareceu quando discutíamos o quão versátil parecia ser a Unity. Foi então sugerida a ideia de que melhorássemos o jogo, que ficou com vários defeitos em aberto para serem corrigidos da época em que foi mostrado para a professora Luciana, em dezembro de O jogo basicamente é um shooter 2D, ao estilo de games clássicos como Contra e Metal Slug. O personagem controlado pelo jogador é um soldado que conta com sua arma e granadas para destruir robôs ao longo das duas fases. Deve-se ressaltar que todos os modelos utilizados no jogo não foram criados pelos desenvolvedores. O soldado, por exemplo, é oriundo de um tutorial - Bootcamp - da empresa Aquiris para a Unity. Nossa intenção era, entre outras coisas: Melhorar a animação dos personagens. No caso do soldado, a arma não apontava para onde ele estava atirando. Apesar de a animação estar presente desde o Bootcamp, no jogo original não havia sido possível colocá-la para funcionar da maneira correta. Consertar os projéteis: Os tiros disparados pelo soldado eram nada mais do que esferas claras sobre as quais eram calculados os testes de colisão. A granada do soldado tinha o mesmo modelo que os foguetes dos robôs, e isso ficava bastante estranho, se considerarmos qual a trajetória que um corpo daqueles fazia no jogo. Criar uma terceira fase, dentro de uma torre, na qual ocorresse vertical scrolling. Consertar texturas das armas e dos terrenos do jogo. Arrumar o respawn do soldado. Se esse perdia uma vida - para isso basta levar um tiro de foguete -, ele era reposicionado no mesmo local, podendo sofrer danos sem nenhum intervalo de tempo no mesmo lugar. Criar novo ataque para o soldado e para os robôs. Criar um novo tipo de inimigo. III - Conclusão, Resultados e Dificuldades Um dos primeiros e últimos itens a serem consertados foi a animação do personagem em relação à arma. Não havia iluminação e muzzle flash para os tiros disparados pela arma, além do GameObject Shooter (script controlando o disparo de projéteis) estar como objeto filho do soldado, ou seja, seguiria apenas o soldado para definir a posição inicial dos projéteis. Isto fazia com que os projeteis saíssem da cara do soldado, e não se adaptassem à mudanças na posição da arma (diferenciada na animação de corrida e posteriormente nas animações de mira pra baixo e pra cima). Além disso, os projéteis eram bolas com uma textura amarelada, o que dava a impressão de jogo. Para obter um efeito mais realístico, usou-se um emissor de partículas (objeto pronto da unity) para emitir partículas e escondeu-se os bullets através de um simples Hide no campo do projetil

3 (embora estes ainda fossem gerados para os testes de colisão). O resultado não ficou muito bom, pois as balas atravessavam os inimigos e morros como se estivessem à frente destes (o emissor não faz teste de colisão para as partículas geradas). Então, voltou-se para os projéteis normais, e aplicou-se uma textura metálica escura para os projéteis. O objeto shooter foi conectado como filho do modelo da arma do soldado, e posicionado na ponta deste. Isto fez com que os projéteis sempre aparecessem a partir do cano da arma. No cano da arma também foram adicionados um ponto de luz e um emissor de partículas: o primeiro servia para realizar a iluminação sempre que ocorresse um tiro, e o segundo produzia focos de luz no cano da arma (efeito conhecido como muzzle flash ), devido à explosão do tiro. O mesmo foi feito para os inimigos. A animação de mira para cima e para baixo posteriormente teve efeitos sobre esta mudança do objeto Shooter, que será explicado posteriormente, na ordem que o projeto foi feito. Seguem ilustrações mostrando a diferença entre as animações de tiro. Antes: Depois:

4 Para as granadas, foi obtido um modelo da internet, e facilmente importado para dentro da Unity; após organizar a hierarquia de modelo, textura e shader, obtemos um projétil novo para a granada. Para corrigir o som da explosão da granada do soldado que estava faltando, fora conectado o mesmo som de explosão dos rockets usados pelos inimigos. Além disso, normalizamos a velocidade e o ângulo de arremesso da granada, pois este se encontrava diferente nas duas fases, além de permitir ao personagem uma forma de suicídio: ao lançar duas granadas rapidamente, uma colidia com a outra, gerando uma explosão na cara do personagem, matando-o. Ilustrações mostrando as granadas abaixo. Antes:

5 Depois:

6 Suicídio na versão antiga:

7 Outro problema consertado em sequência foi o respawn do soldado. Anteriormente, caso este sofresse dano suficiente para uma morte (uma explosão era o suficiente), apenas perdia uma vida e ficava no mesmo lugar, sendo possível perder 2 vidas para a mesma explosão. Para evitar tal problema, o SpawnPoint do soldado foi conectado a ele como filho e posicionado aproximadamente 8 unidades atrás do soldado, e 11 unidades acima. Isto faz com que o soldado renasça um pouco mais longe do perigo, e o tempo de queda serve como proteção para o jogador ter tempo de reação e calcular os próximos passos para evitar mais uma morte. Ilustração do respawn na Unity::

8 Por final, fora consertada a animação do soldado para permitir movimentos de mira para cima e para baixo. Devido à falta de entendimento em relação ao funcionamento de animações na Unity (o tutorial de criação de jogo não ensinava sobre animações), foi demorado e exigiu um pouco de leitura e adivinhação (os exemplos do site da Unity3d estavam errados e não usavam o comando crucial: animation.blend). Porém, com a animação, ocorreu um problema grave com o script Shooter: a direção dos projeteis em relação ao eixo y estava mudando devido ao quaternion usado para rotação da arma no modelo, o que, portanto, mudava o filho do modelo da arma, o script Shooter. Para consertar isto, foi necessário ler como a Unity armazenava e realizava rotações. A engine guarda rotações como quaternions por questões de desempenho e genericidade, oferecendo poucas funções para realizar rotações em relação aos eixos principais, as quais não geravam os resultados desejados (pois não tinhamos noção de que direção estava sendo rotada, e a rotação realizada na animação parecia ser cumulativa, fazendo com que as balas às vezes fossem na direção da tela, outras na direção oposta, etc). Ao observar o tutorial de quaternions, o próprio tutorial avisava: apenas mude estes campos se souber quaternions de cabo a rabo ( inside out foi o termo usado no site). Após releitura dos slides da disciplina e da observação do quaternion que estava sendo usado para rotação, foi calculado qual seria o quaternion que deveria fazer a rotação da arma e de shooter individualmente, e após um pouco de tentativa e erro com o quaternion a ser aplicado para realizar a rotação de compensação no Shooter, o

9 problema pareceu ter sido resolvido. Após a resolução deste problema, foi aplicada uma rotação sobre o eixo X dadas as teclas pressionadas, para que o script Shooter atirasse de acordo com a animação em 4 posições adicionais (para cima, diagonal para cima, diagonal para baixo alta e diagonal para baixo baixa ). O último caso era pra ser completamente pra baixo, caso o jogador quisesse pular por cima de um inimigo e atirar pra baixo, mas teve de ser modificado pois os projéteis estavam colidindo com o pé do soldado, resultando em suicídio. Fotos das novas animações:

10

11 De resto foram facilmente adicionados áudios e telas de abertura, game over, final e música de fundo facilmente, mas estes não são tão relevantes devido à trivialidade (embora importantes para o feel correto de um jogo). A maior dificuldade para o desenvolvimento do trabalho foi, claramente, o tempo do qual a gente dispunha, o que nos impediu de realizar mais mudanças aprendidas ao longo do tutorial da Unity, tal como a técnica de blob shadow, utilizada para gerar uma sombra redonda apenas para dar a noção de posição do personagem. Decidimos nos esforçar o máximo nesse tempo para tentar obter o melhor resultado possível para a nova versão do RocketRider. Apesar de parecer algo simples de ser feito para um trabalho final de uma disciplina de Computação Gráfica, para nós o desenvolvimento levou um tempo realmente razoável de esforço, da ordem de 5 a 6 dias de dedicação. Isso ocorreu pois ambos tivemos de estudar bastante a engine. No caso de um, o conhecimento na plataforma era zero e ele teve de compreender todos os mecanismos, ao seguir um tutorial e produzir um jogo completo. No de outro, teve de haver um reestudo da plataforma para poder corrigir os erros que na disciplina original não havia sido possível arrumar. Mais importante do que isso, é o fato de que o estudo dessa game engine é altamente relacionado com a cadeira cursada e grande parte do funcionamento desse framework tem origem no conhecimento que as aulas de computação gráfica nos deram. Embora a engine

12 seja fácil de usar, apenas o é para quem tem os conceitos de computação gráfica bem fundamentados, então o termo fácil aqui é relativo: se trata de fácil pois a engine e o ambiente de produção são de uma abstração de nível mais alto que uma linguagem. Em média, é possível dizer que o trabalho realizado na engine em termos de codificação no scripts não passa de 40%, sendo o resto apenas drag & drop no cenário, entre scripts e campos dos scripts (estes interagem entre si, e vários scripts comuns a jogos já são fornecidos como default pela engine, tal como AI para inimigos) e os recursos disponíveis, acelerando em muito a produção de um jogo. Porém, estes 40% relacionados às interações dos modelos em geral utilizam conhecimentos avançados, tal como o uso de quaternions.