Monthly Archives

August 2013

By | Uncategorized | 4 Comments

E ai galera!

Estou aqui hoje para começar uma seção de  posts um pouco diferente, o tema dessa vez é Game Design. Não vou falar necessariamente de Game Design do Projeto Tilt (apesar de eu poder sim falar dele em algum post mais pra frente), vim aqui agora pra falar um pouco sobre algo que é – estranhamente – muito ignorando em vários, e vários jogos por aí (até mesmo em Triple As e Indies lá de fora!) e que não deveria ser ignorado por ninguém, que é o “Feel” do seu jogo.

Disclaimer: Bom, primeiramente o que vamos tratar aqui é algo COMPLETAMENTE subjetivo, não existe formula correta nem maneira certa de fazer e tudo que eu escrevi aqui é baseado em experiências minhas. O ideal é que você tenha esse conceito na sua cabeça na hora que estiver “designando” o seu jogo pois você verá seu design com uma outra ótica. Fortes agradecimentos ao Marcos Venturelli da Critical Studio por ter destrinchado esse assunto na minha cabeça.

Mas o que é “Feel” em termos de Game Design?

Feel é o sentimento que você quer passar com seu jogo em termos de jogabilidade. Você tem um personagem que é um robô gigante super poderoso? Então provavelmente você vai designar ele de forma que se mova mais lento, tenha ataques lentos e pesados que dão muito dano. Seu jogo é sobre um garoto feito de carne que pula plataformas impossíveis no menor espaço de tempo possível? Então provavelmente seu controle deve ser trabalhado pra ser ultra responsivo durante qualquer momento de jogo (seja no ar, ou na terra ou na parede). Você tem um jogo de puzzle misturado com RPG pra iOS? Então a resposta ao toque e o feedback tátil talvez seja seu foco para tornar o jogo o mais suave possível, fazendo o jogador sentir que o jogo é super fluido.

Até agora eu falei dos controles, mas o feel é o todo. O feel vai desde o tempo de resposta do apertar de seu botão até a animação do personagem (se houver) tocar e você obter a resposta de feedback até o flow de interface do seu jogo ser bem planejada.

Vamos a um estudo de caso: Killzone vs. Call of Duty

Killzone

Movimentação do Personagem em Killzone

Gameplay de tiro no Killzone

Execuções e sprint em Killzone

Call of Duty

Movimentação e tiros no CoD

Tempo de resposta da arma em CoD

Observando os dois jogos será que você consegue responder qual a diferença do Feel entre os dois?

Killzone é um jogo mais pesado e mais lento enquanto Call of Duty tem um feel dinâmico e rápido, menos tático.

Se você perceber nos GIFs acima, tem detalhes que destacam os princípios de design de ambos os jogos. Primeiro nós podemos ver o contraste de velocidade entre os personagens de ambos os clipes. No Killzone a movimentação do personagem é bem mais lenta, existe até um pequeno aumento do tempo de resposta entre o movimento do analógico do controle até o personagem começar a se movimentar (apesar disso você só perceber jogando). Outras coisas que denunciam a velocidade e o peso do jogo é a quantidade de frames de animação durante um tiro, deem uma olhada no gif 2 do Killzone e percebam a diferença que demora pra metralhadora do jogador disparar, em contraste com a do COD (tudo bem, cada arma tem uma qualidade diferente! mas não é isso que estamos discutindo) perceba como os movimentos tanto de atirar quando de entrar no “Iron Sights” é BEM mais lenta que nos GIFs do CoD.

Além disso tudo tem um elemento presente aqui que talvez vocês nunca imaginariam que seria um fator: os Gráficos. Não estamos falando de mais polígonos ou textura melhor, estamos falando de Frame Rate (frame rate é a quantidade de quadros que o console desenha por segundo). O Call of Duty se preza como um shooter (jogo de tiro) que é produzido desde o início com 60 Quadros por Segundo (FPS) em mente, já o Killzone planeja atingir os melhores gráficos possíveis no console, então eles sacrificam um pouco de Frame Rate pra poder utilizar o processamento restante em melhores texturas, IA melhor, mais polígonos, etc. O que isso influencia no peso e no feel do jogo? Com menos quadros pra se desenhar as animações são tocadas com menos fluidez, o jogo passa se tornar um pouco mais lento por natureza (Battlefield também é feito em 30 FPS). Veja bem, nenhuma das opções são boas ou ruins! Isso é uma escolha de DESIGN, isso foi pensado pelos designers e pela equipe, não foi algo que eles começaram a fazer e aí falaram: PUTZ! O jogo agora tá com 30 FPS, tem que ver isso aí! Podem ter certeza que se alguém quis fazer alguma cena ou adicionar alguma mecânica de jogo que era impossível de reproduzir em 60 FPSs no Call of Duty ela foi cortada ou modificada para não perder a experiência  de jogo.

Também existem coisas que eu não tratei nem demonstrei nesses jogos em termos de Gameplay. No Killzone 2 existe uma mecânica de cobertura onde o jogador é incentivado a se esconder atrás de objetos do cenário pra conseguir sobreviver (nos Killzones mais novos eles deixaram ela bem mais rápida). O Call of Duty tem uma mecânica de se agachar duas vezes (agachado e deitado) mas que pode ser usada rapidamente no meio de um sprint, mais versátil e efetiva como Run & Gun (Correr e atirar) do que como mecânica de cobertura atrás de objetos – veja ela em ação no GIF  acima. Então podemos ver que ambos os jogos possuem uma ou mais mecânicas parecidas mas que foram desenhadas pelos Designers para agirem de maneira a dar suporte ao Feel do jogo.

Ou seja: o Feel do jogo é algo delicadamente trabalhado e deve ser pensado desde o início da producão, tenha sempre em mente o objetivo que você quer atingir com as mecânicas que estiver desenvolvendo pois é melhor um jogo feio ou sem todas as features mas com um Feel FODA (Minecraft) do que uma sequencia de um jogo FODA que tem um feel de merda, e é com isso que vamos pro meu segundo ponto.

Onde mais eu posso entender sobre Feel de jogos?

O Egoraptor tem uns vídeos onde ele destrincha alguns jogos maravilhosamente bem com uma visão de Game Designer. Vale MUITO a pena assistir todos, só precisa saber inglês!

Tudo bem, mas issaí são jogos Triple A e eu que sou indie, comofaz?

Meu segundo ponto virá na Parte 2, onde eu vou fazer mais um estudo de caso. Dessa vez de um jogo que me decepcionou bastante pois eu esperava que fosse tão bom quanto seu precursor.

 

Aguardem!

Enquanto esperam a parte 2 e agora que vocês estão refletindo sobre o assunto, aproveitem para jogar e estudar o feel do nosso jogo: o Projeto Tilt. O jogo está em Closed Pré-Alpha mas vocês podem se tornar Closed Testers se inscrevendo no grupo de Facebook: bitcakestudio.com/testers/. Depois de se inscreverem podem jogar no Facebook mesmo através do link: bitcakestudio.com/tilt/.

Até a próxima!

Escondendo o Lag – O que os olhos não vêem, o coração não sente

By | Programming | 12 Comments

Bom pessoal, eu sou o Vinícius Pachá, mais um dos programadores do Projeto Tilt. E estou aqui para falar um pouco do Networking das nossas armas, em especial a nossa Sniper!

Em primeiro lugar, O que é uma Sniper no nosso jogo? Bom, em termos técnicos eu diria que é uma arma de longo alcance onde o dano é instantâneo, ou seja, não existe nenhum projetil correndo pelo cenário, não existe nenhuma trajetória, nós apenas traçamos uma reta a partir do personagem na direção que ele está mirando até bater em alguma coisa.

Ok, Let’s Do This!

Definido o que é a Sniper do Tilt… Vamos programar! (Parece bem fácil né?)
1° Passo: Quando eu atirar eu mando uma mensagem chamada “FeedbackDaSniper” pra todos os players dizendo: Atirei na posicao X e na direção Y;
2° Passo: Se acertei alguém, manda uma mensagem de Dano para esse player com a quantidade de dano e se eu matei, Instantaneamente manda um feedback de que o outro player morreu;
3° Passo: Cada player assim que recebe a mensagem “FeedbackDaSniper” renderiza na tela um efeito de laser partindo da posição do tiro;

Após tudo programado fomos testar e tivemos uma surpresa…

1VersaoMatando
Quando eu mato alguém


Quando eu morro

Mesmo com todo mundo com ping por volta de 40ms, 30ms, aconteceram coisas estranhas. Para o jogador que matou, tudo era bom: ele atirava em alguem, e se acertava e havia dano suficiente para matar o alvo morria na mesma hora. Porém, para quem morria, mesmo em 30ms ele já havia mudado de posição e quando a mensagem do tiro chegava o jogador não estava mais na reta do tiro, e morria mesmo assim pois recebeu o dano do primeiro player. Para quem morria era muito frustante, a galera reclamava: “Pô, morri mas o tiro nao me acertou =( “.
Não adianta fazer um jogo multiplayer onde 1 lado fica satisfeito, porém o outro se sente injustiçado.

A importância do Feedback

Quando falamos de jogos Multiplayer e Netcode temos que encarar o nosso pior inimigo, o lag. Para quem não sabe, lag é uma entidade maligna, que refere-se ao intervalo de tempo entre o início de uma atividade e o momento em que os efeitos desta se tornam aparentes. E não adianta, sempre existiu e sempre existirá lag. Então nossa maior duvida era, como disfarçar o lag?? Então, vamos relembrar o que aconteceu, eu atirei, ele morreu pra mim, ele morreu pra ele também, porém ele não teve o Feedback de que o tiro acertou nele. Ok, achamos o problema. Então tudo que tinhamos que fazer era achar um jeito do jogador que morreu ter o feedback de que ele foi realmente atingido pelo raio da sniper para ele ficar feliz!

Como Prever o Imprevisível

Muitas vezes em jogos Multiplayer nos deparamos com ações que são imprevisíveis, ações instantaneas que só conseguiriamos prever se estivessemos dentro da mente do jogador. E a Sniper é uma arma instantanea, é impossivel prever quando o player vai apertar o botão do tiro, entao a solução que achamos foi enganar o player.
E esse foi o resultado:

2VersaoMatando
Quando eu mato alguém

2VersaoMorrendo
Quando eu morro

Vendo as 2 imagens claramente o raio da sniper está em direções diferentes, mas… Será que isso é problema?
Bom, desse jeito quem matou fica feliz, quem morreu fica “feliz”, e o jogo não parece nem um pouco lagado, então é claro que não tem problema, o mais importante é fazer com que os jogadores não sintam o lag, mesmo que ele exista.
Ta bom ta bom… mas como fizemos isso?
Ao invés de mandar uma mensagem avisando Atirei na posicao X e na Direção Y, o player assim que atira, verifica se o outro player está na reta do tiro dele e se estiver manda uma mensagem “Acertei no player X”, e quando o outro player recebe essa mensagem, ele recalcula a direção a qual a sniper deve atirar para que a sniper o acerte. Assim o lag fica escondido por causa do feedback.

É isso aí galera, se você quiser testar a nossa Sniper, faça logo sua inscrição no nosso grupo de testers www.projecttilt.com/bitcakestudio/testers e venha jogar conosco por www.projecttilt.com/bitcakestudio/tilt.
Obs: Nossos testes acontecem todas as quintas de 20:00 às 21:00

Bom Teste!Bom pessoal, eu sou o Vinícius Pachá, mais um dos programadores do Projeto Tilt. E estou aqui para falar um pouco do Networking das nossas armas, em especial a nossa Sniper!

Em primeiro lugar, O que é uma Sniper no nosso jogo? Bom, em termos técnicos eu diria que é uma arma de longo alcance onde o dano é instantâneo, ou seja, não existe nenhum projetil correndo pelo cenário, não existe nenhuma trajetória, nós apenas traçamos uma reta a partir do personagem na direção que ele está mirando até bater em alguma coisa.

Ok, Let’s Do This!

Definido o que é a Sniper do Tilt… Vamos programar! (Parece bem fácil né?)
1° Passo: Quando eu atirar eu mando uma mensagem chamada “FeedbackDaSniper” pra todos os players dizendo: Atirei na posicao X e na direção Y;
2° Passo: Se acertei alguém, manda uma mensagem de Dano para esse player com a quantidade de dano e se eu matei, Instantaneamente manda um feedback de que o outro player morreu;
3° Passo: Cada player assim que recebe a mensagem “FeedbackDaSniper” renderiza na tela um efeito de laser partindo da posição do tiro;

Após tudo programado fomos testar e tivemos uma surpresa…

1VersaoMatando
Quando eu mato alguém


Quando eu morro

Mesmo com todo mundo com ping por volta de 40ms, 30ms, aconteceram coisas estranhas. Para o jogador que matou, tudo era bom: ele atirava em alguem, e se acertava e havia dano suficiente para matar o alvo morria na mesma hora. Porém, para quem morria, mesmo em 30ms ele já havia mudado de posição e quando a mensagem do tiro chegava o jogador não estava mais na reta do tiro, e morria mesmo assim pois recebeu o dano do primeiro player. Para quem morria era muito frustante, a galera reclamava: “Pô, morri mas o tiro nao me acertou =( “.
Não adianta fazer um jogo multiplayer onde 1 lado fica satisfeito, porém o outro se sente injustiçado.

A importância do Feedback

Quando falamos de jogos Multiplayer e Netcode temos que encarar o nosso pior inimigo, o lag. Para quem não sabe, lag é uma entidade maligna, que refere-se ao intervalo de tempo entre o início de uma atividade e o momento em que os efeitos desta se tornam aparentes. E não adianta, sempre existiu e sempre existirá lag. Então nossa maior duvida era, como disfarçar o lag?? Então, vamos relembrar o que aconteceu, eu atirei, ele morreu pra mim, ele morreu pra ele também, porém ele não teve o Feedback de que o tiro acertou nele. Ok, achamos o problema. Então tudo que tinhamos que fazer era achar um jeito do jogador que morreu ter o feedback de que ele foi realmente atingido pelo raio da sniper para ele ficar feliz!

Como Prever o Imprevisível

Muitas vezes em jogos Multiplayer nos deparamos com ações que são imprevisíveis, ações instantaneas que só conseguiriamos prever se estivessemos dentro da mente do jogador. E a Sniper é uma arma instantanea, é impossivel prever quando o player vai apertar o botão do tiro, entao a solução que achamos foi enganar o player.
E esse foi o resultado:

2VersaoMatando
Quando eu mato alguém

2VersaoMorrendo
Quando eu morro

Vendo as 2 imagens claramente o raio da sniper está em direções diferentes, mas… Será que isso é problema?
Bom, desse jeito quem matou fica feliz, quem morreu fica “feliz”, e o jogo não parece nem um pouco lagado, então é claro que não tem problema, o mais importante é fazer com que os jogadores não sintam o lag, mesmo que ele exista.
Ta bom ta bom… mas como fizemos isso?
Ao invés de mandar uma mensagem avisando Atirei na posicao X e na Direção Y, o player assim que atira, verifica se o outro player está na reta do tiro dele e se estiver manda uma mensagem “Acertei no player X”, e quando o outro player recebe essa mensagem, ele recalcula a direção a qual a sniper deve atirar para que a sniper o acerte. Assim o lag fica escondido por causa do feedback.

É isso aí galera, se você quiser testar a nossa Sniper, faça logo sua inscrição no nosso grupo de testers www.projecttilt.com/bitcakestudio/testers e venha jogar conosco por www.projecttilt.com/bitcakestudio/tilt.
Obs: Nossos testes acontecem todas as quintas de 20:00 às 21:00

Bom Teste!

Networking Code: Runas, Búzios e Tarot (Parte 1)

By | Programming | 3 Comments

Olá pessoal, aqui é o Matheus Lessa, um dos programadores por trás do projeto Tilt. Este é mais um da série de posts para nosso blog sobre os bastidores de nosso jogo em desenvolvimento. Para o bem ou para o mal, o assunto da vez não é sobre algo audiovisual, mas sim sobre aquilo que está implícito, que está lá mas ninguém vê, que não dá para ser mostrado para a sua mãe :D. Estamos falando sobre a programação de um jogo. No caso, já que se trata de um jogo multiplayer através da internet, por quê não começarmos o primeiro post de programação de nosso blog com um que trata justamente de nosso “netcode”?

Pois bem, nós sabemos que fazer um jogo com networking não é tarefa fácil. Há quem diga que “a melhor maneira de fazer um jogo com networking é NÃO fazendo um jogo com networking”. Além disso, um de nossos programadores sempre diz: “fazer um jogo com networking é aumentar sua complexidade por 10 vezes”. Eu, particularmente, creio que ele seja um otimista! 😀

E antes que você, caro leitor, ache que o grupo BitCake é composto por programadores masoquistas, saiba que se foi possível chegarmos até aqui com nosso jogo, foi porque escolhemos mecânicas simples e conhecidas para sincronizar através da internet. Onde quero chegar é que, abordar toda nossa infraestrutura de “netcode” em apenas um post, não é possível. Assim, nesse post focaremos sobre a questão da sincronização do movimento do
personagem e de projéteis atirados dentro do jogo.

Creio que seja importante ressaltar que nosso jogo é feito em Unity e usamos Photon (http://www.exitgames.com/Photon/Unity) para a parte de networking. Photon é uma excelente ferramenta em que é possível tratar tarefas básicas como sincronizar um “Transform” (Componente em Unity) automaticamente e “out-of-the-box”. Porém, tudo é muito bonito até termos de lidar com o nosso maior inimigo: o “ping”!

Explicando o “ping” e seus problemas. “Ping” é como chamamos o delay de troca de mensagens entre computadores. Por exemplo, o “ping” médio dos jogadores de Tilt é de 70 milisegundos aproximadamente. Isto é, o tempo que leva para uma mensagem sair de um jogador e chegar a outro é de mais ou menos 70 milisegundos. Por mais que pareça pouco tempo, um “ping” de 200ms já é suficiente para prejudicar o gameplay de um jogo de tempo real (como o caso de Tilt ;)).

Vamos tomar, como exemplo, a sincronização da posição do player. Um “ping” grande, para a sincronização da posição de um player em outro computador, faz com que ele tenha um movimento “teleportoso” (nós costumamos chamar assim). Isto é, ele ficará “pipocando” de um lado para o outro (o que não é legal :P). O que gostaríamos que acontecesse era que, entre uma mensagem e outra (tempo do “ping”), o player se movimentasse suavemente entre a posição antiga e a nova (que ainda está por vir na mensagem). Isso poderia ser resolvido facilmente com uma simples interpolação entre vetores (na Unity: “Vector3 pos = Vector3.Lerp(posAntiga, posNova, t);” – onde “t” é o tempo que passou desde a última mensagem dividido pelo tempo total entre as mensagens).

5209650e84870

Poderia… Poderia CASO soubéssemos as informações que ainda estão CHEGANDO na mensagem! E agora? Como resolver o problema? Afinal, muito feio seria se o jogo final tivesse esse comportamento (“teleportoso”), certo? Uma solução conhecida e adotada em diversos jogos “networkados” é a de tentar PREVER qual a posição que está chegando na mensagem enviada. Afinal, não deve ser tão difícil pois a posição do player não varia muito entre uma mensagem e outra! Na verdade, mais do que isso: a nova posição TENDE a ficar a uma distância da antiga com um valor igual ao tamanho da velocidade antiga do player e dependendo de quanto tempo passou! Calma, calma. Vamos devagar. Não entraremos em muitos detalhes aqui já que estes são conhecimentos básicos de Física e Álgebra Linear (crianças, não deixem de estudar!) e eles podem ficar para um outro post. 😉

Bom, dado que existem duas variáveis (na Unity: “Vector3”): “pos” e “vel” que representam a posição e velocidade atual do player respectivamente, temos que a nova “pos” que está chegando por mensagem TENDERÁ a ter valor próximo a “Vector3 posNova = pos + vel * dt;” (para os curiosos, essa fórmula é conhecida como integração de Euler. Sim, você está integrando tipo cálculo – só que não :D). Aquele “dt” na fórmula deve ter valor igual (dentro do possível) ao quanto de tempo passou desde a chegada do último pacote, e esta é uma das partes interessantes e importantes da solução apresentada! Ele pode ser calculado (estimado) a partir do “time stamp” da Unity menos aquele da mensagem recebida do Photon. Ou seja, algo do tipo: “float dt = Time.timeStamp – photonMessageInfo.timestamp;”

Bom, ainda existem alguns (muitos na verdade… D:) detalhes e refinamentos a serem discutidos para completarmos nosso estudo sobre o nosso netcode. Por exemplo: podemos tratar melhor o quanto de “ping” cada player tem a fim de refinar nossa estimativa a respeito de sua nova posição. É possível também que o “time stamp” do player remoto esteja à frente do player local (lol, wut?). Nesse caso, nossa estimativa irá se tratar de uma interpolação de posições conhecidas e não mais um chute (extrapolação) como vimos acima.

Entretanto, o post já está bem longo e já serviu como uma boa introdução a respeito da programação em Tilt e de “networking” em geral. Então, deixaremos para a próxima mas não se preocupem que ainda iremos explicar o que ficou faltando!

Fiquem atentos para a parte 2!

É isso aí galera, se você está interessado testar nosso networking code pra ver se aguenta mesmo, peça sua inscrição no nosso grupo de testers Facebook: www.projecttilt.com/bitcakestudio/testers. Depois de aceitos, vocês ganham acesso do jogo através do link: www.projecttilt.com/bitcakestudio/tilt ou pelo seus APPs do Facebook.

Bom Teste!

Testes da Vida – a história do nosso health HUD até aqui

By | Art | 8 Comments

Olá pessoal, eu sou Camilla Slotfeldt, a artista 2D do projeto Tilt! 🙂 Estamos começando com nossos posts contando o desenvolvimento do projeto, e vocês devem estar se perguntando: “… artista 2D? Mas não tem nada de arte nesse jogo ainda!”. Pois é. Eu entrei no projeto bem mais tarde que os outros membros da equipe (e agora recentemente recebemos um novo modelador 3D, o Daniel, para nos ajudar), e com a saída de alguns membros anteriores, acabei sendo a única pessoa de arte por algum tempo! Mas a primeira coisa que eu fiz no jogo quando entrei foi trabalhar na interface de vida (health) do jogador e da barra de uso do jetpack. A equipe já tinha várias ideias para essa parte da interface, que na época consistia em  barras no canto inferior da tela. (Na imagem abaixo há também uma terceira barra, de munição da arma).

screenshot tilt

A questão é que a posição dessas barras na tela não estava funcionando muito bem. Olhar para esquerda/baixo para ver o health do seu jogador era um pouco demorado, especialmente em um jogo onde você pode morrer com 1 tiro. Por isso, começamos a experimentar novas opções e testá-las semanalmente com nosso grupo de teste, o que foi uma oportunidade bem interessante, que nem todo projeto consegue ter.

Teste da vida na retícula

A primeira opção que testamos foi uma ideia bem diferente, que sabíamos que tinha uma grande chance de não funcionar: colocar o health e o jetpack na mira (a retícula, ou a “setinha do mouse”, onde fica a mira para o tiro do jogador). Essa seria uma interface não-usual, mas que poderia ficar interessante graficamente e ser um diferencial se funcionasse. Além disso, íamos testar a hipótese de que o jogador olha bastante para a mira, mais do que para os cantos ou até para o próprio personagem no centro da tela.

Screenreticula     Interfacereticula01

Aproveitamos a forma circular da retícula e a dividimos em dois semi-círculos: um na esquerda para a vida e outro na direita para o jetpack. Nós queríamos que o health fosse dividido em pedaços bem marcados, como “quadradinhos”, para que as linhas entre eles servissem de marcação e ajudassem o jogador a saber melhor com quanto de vida ele está no momento. O personagem tem 100 de vida, então dividimos o semi-círculo em 10 partes, e acreditamos que assim ficava mais fácil saber se o jogador tem no momento 50 ou 70% de vida, por exemplo, vendo pelo número de partes. O resultado desse teste foi bem interessante! Diferente do que achávamos, as pessoas do grupo, que jogaram conosco usando a interface nova, não fizeram tantas queixas nem falaram ter achado estranho. Muito poucas pessoas deram algum feedback negativo sobre o novo HUD e o teste até fluiu normalmente. Porém, nossos testes são online e muitas vezes as pessoas não se expressam tanto, e a nossa própria opinião sobre o jogo tambem é muito importante para nós. E por uma avaliação da equipe, percebemos que não olhamos tanto assim para a mira quando jogamos, e, apesar das pessoas não terem falado muito, o gameplay ficou sim um pouco prejudicado.

Vida em volta do player

Resolvemos então partir para um próximo teste! Dessa vez, a hipótese era de que olhamos mais para o nosso personagem do que para a vida ou para os cantos. Essa hipótese faz bastante sentido se formos ver outros jogos parecidos com os nossos, que usam o health embaixo do personagem com uma pequena barra, por exemplo. Como nós precisamos de duas barras, a de vida e a do jetpack, resolvemos experimentar uma ideia mais diferente mais uma vez e fazer o HUD circular, em volta do personagem. Uma das referências que usamos na época foi o Ice HUD, uma modificação de Word of Warcraft:   3a7e39cabb7a40eb5e46fb8b35e412a8

O nosso resultado foi o seguinte:

Screenshot---Health-HUD-em-volta-do-player

Mais uma vez testamos a interface nova e a aceitação dessa foi melhor. A equipe tambem ficou bem mais satisfeita com o resultado, e resolvemos manter essa forma por enquanto. Ao mesmo tempo, nós  também trabalhamos em outra parte importante da interface do jogo, o radar, que ficou muito interessante em conjunto com o health HUD. O radar reconhece jogadores que estejam lutando (atirando) e possam representar perigo, ou que estejam usando o jetpack  nas redondezas, e mostra setas em volta do personagem, indicando a direção da ameaça. Quando refizemos o radar, colocamos as setas para girar em volta do HUD, e a forma circula dos dois combinou muito bem!

Screenshot health hud + radar

Conclusões! Porque esses testes foram bons?

Aprendemos algumas coisas interessantes com os testes, tirando conclusões tanto de ver como ficam opções diferentes de interface (experimentar coisas que ninguem te aconselharia a fazer é muito legal tambem), quanto de avaliações nossas para o que queremos ver no nosso jogo, e de feedbacks de usuários. Algumas coisas que percebemos:

  • O usuário olha bastante para o player e isso faz mais sentido para ele
  • O jogador não olha tanto para mira quanto se poderia imaginar, ou pelo menos não com um intuito diferente de atirar
  • Quanto de vida o jogador tem no momento não faz TANTA diferença no nosso jogo, porque é muito dinâmico. Algumas armas matam com apenas um tiro, e o jogador pode preferir olhar para a vida somente quando já tomou dano, para saber se ainda pode aguentar lutar ou deve correr para procurar um health pick-up (item de recuperar vida) no cenário
  • Mais interessante ainda que o health HUD  para o nosso jogo é dar um bom feedback de dano, tanto visual quanto sonoro. Para isso adicionamos bordas vermelhas na tela quando o jogador toma dano, baseado na conclusão dos testes

Por mais que algumas conclusões sejam óbvias, ou não, tivemos a oportunidade de testar sem nos apoiar em concepções pré-estabelecidas e decidir o que era melhor para o nosso jogo, e acho que é assim que pretendemos continuar trabalhando daqui pra frente 🙂  Ainda queremos fazer novos testes, mas agora estamos focando em outros pontos. Provavelmente vamos fazer uma reavaliação do health HUD quando finalizarmos a arte do personagem, e aí vamos ver como ela se comporta. É isso! Espero que tenham gostado e que esse tipo de post possa ser útil e/ou interessante para outras pessoas desenvolvendo jogos no futuro! Qualquer coisa, dexem um comentário, quero muito conversar com outras pessoas e ver o que vocês tem a dizer sobre o que estamos fazendo!

É isso aí galera, se você está interessado em participar do jogo e ver de perto nosso processo de desenvolvimento é só pedir sua inscrição no nosso grupo de Facebook: www.projecttilt.com/bitcakestudio/testers, depois de aceitos vocês ganham acesso do jogo através do link: www.projecttilt.com/bitcakestudio/tilt ou pelo seus APPs do Facebook. Bom Teste!