Category

Programming

Tools, a developer best friends

By | General, Programming | 8 Comments

Olá galera, eu sou o Perdiga ( ou Vallcrist ( ou Jefferson ) ), o último dos programadores da BitCake a se apresentar por aqui. 🙂 O post de hoje vai falar de uma coisa muito importante pra qualquer equipe de desenvolvimento de jogos ( principalmente para aquelas que usam Unity, como a BitCake ), as ferramentas! O que são ferramentas? Ferramentas são coisas que buscam

Olá galera, eu sou o Perdiga ( ou Vallcrist ( ou Jefferson ) ), o último dos programadores da BitCake a se apresentar por aqui. 🙂 O post de hoje vai falar sobre uma coisa muito importante pra qualquer equipe de desenvolvimento de jogos (principalmente para aquelas que usam Unity, como a BitCake), as tools (Ferramentas em pt-br)!

O que são tools?

Tools são coisas que buscam estender a sua engine ou facilitar o fluxo de trabalho da sua equipe, podem ser divididas em 2 categorias : 3rd Party tools e In-house tools.

In-House Tools

Conforme você e sua equipe desenvolvem o jogo, os programadores muitas vezes irão se deparar com situações do tipo :

  • O sound designer querendo substituir um som no jogo.
  • A artista querendo testar aquela nova partícula hiper irada que acabou de fazer durante o gameplay.
  • O level designer enchendo a paciência porque quer mudar uma rampa de lugar na fase.

Então, como programadores são seres preguiçosos e que ODEIAM coisas repetitivas, nascem as In-House Tools. Nada mais são do que ferramentas que os programadores acabam desenvolvendo pra facilitar o trabalho de outros membros da equipe sem domínio de programação a fazer alterações no jogo, por exemplo :

  • Uma tool que define quais sons tocam quando uma determinada ação no jogo acontece, assim o sound designer pode simplesmente arrastar um som pra essa tool e ele está dentro do jogo.
  • Uma tool que permita que a artista configure quando, onde, e com que parâmetros um efeito de partícula será executado durante o jogo.
  • Uma tool que facilite o fluxo Programa de Modelagem Engine para que o level designer não precise de um programador do lado sempre que quiser alterar o level.

3rd Party tools

Nessa categoria estão as tools que outras pessoas de fora da equipe fizeram e que geralmente servem pra incrementar o poder da sua engine, seja melhorando funcionalidades existentes ou adicionando funcionalidades completamente novas!
Algumas engines possuem repositórios dessas tools, pagas ou gratuitas, facilmente acessíveis, como é o caso da Unity com a Asset Store.
No resto desse post vou dar exemplos de tools que usamos aqui na BitCake para desenvolver o Projeto Tilt, explicando por alto cada uma e mostrando qual o valor que elas agregam a nossa equipe.
Vale lembrar que usamos a Unity, então todas as tools que aparecerem estarão disponíveis para compra na Asset Store

NGUI


Link na Asset Store

Descrição :
Ah… a NGUI. Talvez o melhor investimento que fizemos em tool para o Projeto Tilt, e acho que qualquer um que já tenha tentado fazer uma GUI ( Graphical User Interface ) com a solução nativa da Unity me entende quando digo isso.
A NGUI facilita muito a prototipagem e desenvolvimento de interfaces para o seu jogo e é altamente otimizada para que rode sem problemas de travamento, inclusive em plataformas mobile.
Possui um suporte excelente e muitos exemplos pra explicar o funcionamento da tool.

Quer fazer um botão que ao você clicar nele aumente 10x de tamanho e deslize pra fora da tela? Sem problema.
Quer fazer uma imagem aparecer com fill radial? Sem problema
Quer fazer uma interface com barra de rolagem que funcione parecido com o Iphone? Sem problema

Resumindo, NGUI é facilmente a melhor tool atualmente para desenvolver GUI na Unity, vale facilmente o investimento .

Audio Toolkit


Link na Asset Store

Descrição :
O Audio toolkit é uma ótima ferramenta pra melhorar a qualidade sonora do seu jogo, essa tool possui várias funcionalidades muito legais que adicionam um dinamismo sonoro no seu jogo, principalmente quando sua equipe não tem um sound designer e você se vê obrigado a improvisar com sons grátis achados pela internet afora.
Algumas das features mais legais são :

Definir que um evento de som pode tocar um entre X sons diferentes, pense em uma metralhadora e o quão irritante seria se fosse o MESMO SOM em todos os tiros.
Definir variações aleatórias no pitch e no volume de cada som.
Fade-In e Fade-Out de sons com menos de 2 cliques.

GameAnalytics


Link na Asset Store
Link do site para registro

Descrição :
O GA é uma tool para colher métricas do seu jogo, coisas como DAU (Daily Active Users), MAU (Monthly Active Users), Heatmaps, tempo médio de jogo por jogador… Não vou me aprofundar muito nesse tópico pois provavelmente métricas terão um post só pra elas no futuro. 😉

Melhor coisa do GA :

Photon Networking


Link na Asset Store
Link do site para registro

Descrição :
O Photon é o que usamos para fazer o multiplayer do Tilt, foi uma alternativa melhor e mais simples ao networking padrão da Unity.
Apesar de não possuir uma documentação digna de elogios, é bem simples de se utilizar e, para os preguiçosos, eles oferecem uma opção de servidor cloud pra você nem ter que se preocupar com manutenção de servidores.

Os outros programadores já falaram um pouco sobre o Photon em outros posts ( Aqui, Aqui e Aqui ), então não vou me aprofundar.

E você, caro leitor, quais tools você e sua equipe usam no desenvolvimento dos seus jogos?
Deixe um comentário aqui embaixo nos contando quais são.

Um grande abraço,
Perdiga / Vallcrist / Jefferson
Programmer / Hater @ BitCake Studio

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!