Olá Campeões de Battlerite!
Meu nome é Daniel “Prog” Fahlström e eu sou um dos programadores (Nota do editor: “Um dos desenvolvedores principais” ) aqui na Stunlock Studios. Trabalho aqui desde Janeiro de 2013. Alguns de vocês podem me conhecer da época do Bloodline Champions já que eu era um membro ativo da comunidade. Durante o desenvolvimento de Battlerite, tenho trabalhado em diversas áreas como backend da jogabilidade, UI e localização.
Neste blog irei explicar brevemente como a movimentação dos campeões funciona em Battlerite (sem ser muito técnico) e os requisitos e desafios que nós tivemos e quais as soluções nós utilizamos.
Requisitos e Desafios
Responsivo
Toda movimentação em Battlerite tem que se sentir responsiva enquanto você controla um personagem. Atrasos visuais aos comandos tem que ser evitados para uma imersão completa e para manter a jogabilidade fluida. Isso é algo que sentimos que alcançamos com a nossa solução atual. O movimento em Battlerite é responsivo independente da sua latência.
Anti-Cheat
As Battlerite is a competitive game, we put a lot of effort into making sure players are unable to cheat. Due to this, the server is the authority of the actions the player performs, meaning all the actions (Movement, Ability Cast, Projectile Collisions etc.) are fully controlled by the server.
Como Battlerite é um jogo competitivo, nos esforçamos muito em não permitir trapaças. Devido à isso, o servidor é a autoridade das ações que os jogadores fazem, ou seja, todas as ações (movimento, conjuração de habilidades, projéteis, colisões, etc) saõ controladas pelo servidor.
Latência
Um desafio que é inevitável quando se faz jogos online é a latência. É um fator comum que causa angústia em diversos jogos, especialmente os que dependem tanto em reações. Latência faz com que as ações locais sejam atrasadas para todos os outros jogadores, ao não ser que seja prevista ou simulada. Como latência não pode ser evitada, uma frase que é usada entre nós é “Você não remove a latência, você só decide aonde quer esconder ela”
Em um mundo ideal todos os jogadores teriam menos de 50ms de latência em nossos servidores, mas como isso não é o caso, um requerimento que nós temos é que a solução precisa funcionar com até 150ms.
Aqui temos um exemplo visual de como a responsividade funciona com e sem a nossa solução em uma latência alta. A linha verde representa qual a direção pressionada. Obviamente o atraso visual faz com que o jogo se sinta muito mais lento para o jogador.
Inspiração
Já que o movimento de Battlerite é baseado em WASD, similar a como funciona na grande maioria dos FPS, nós nos inspiramos em soluções utilizadas em Quake e outros jogos da Valve. Adaptamos essas soluções para funcionar corretamente com Battlerite, mas a essência das soluções é a mesma..
Uma grande diferença entre o FPS e Battlerite é que Battlerite usa projéteis mais lentos e não tiros instantâneos. Isso significa que quando a latência causa colisões incorretas (você é atingido mesmo quando parece que o projétil não te acertou) é muito mais notável. O fato de Battlerite ter uma visão de cima para baixo aumenta isso ainda mais.
Se você está interessado em ler mais sobre as soluções que usamos de inspiração, eu listei alguns artigos no fim desse blog.
Como funciona?
A maneira mais simples de explicar como o movimento funciona é pensar assim; O client simula a movimentação visual, e envia esses comandos para o servidor. Isso significa que o client está constantemente mostrando a posição que o ele acredita que o jogador está. Como o client e o servidor utilizado os mesmo cálculos, uma incompatibilidade raramente ocorre. Se acontece, o client irá modificar a simulação para que corresponda à posição esperada no servidor.
Aqui temos outra representação visual com e sem nossa solução em uma latência muito alta. Dessa vez com círculos mostrando a posição do client e do servidor. O círculo vermelho representa a posição que o jogador está no servidor. O círculo verde representa a posição que eles está no client, e a linha verde representa a direção acionada.
O circulo verde está sempre à frente quando estamos simulando os comandos de movimento no client, respondendo instantaneamente ao comando. O posição do server no entanto é atrasada por conta da latência.
Problemas
Agora, essa solução (ou qualquer outra) não é perfeita já que a latência sempre será um fator. E também, como mencionado antes, erros de colisão são muito mais fáceis de se visualizar em jogos com a câmera de cima para baixo com projéteis.
Aqui está um exemplo de um erro visual com a latência muito alta. O círculo vermelho que é mostrado é a posição de Shifu quando a colisão é detectada. Ainda que pareça errado no client, é o resultado correto no servidor.
Isso é algo que sabemos que muitos jogadores ocasionalmente se referem como “Hitbox inválidas”, mas muitas vezes na verdade é apenas um problema de latência.
Para concluir, problemas como esse são inevitáveis. Queremos permitir que o client simule o movimento, mas ainda assim permita que o servidor tenha autoridade sobre as posições. Sabemos que isso tem frustrado alguns jogadores, e estamos constantemente vendo maneiras diferentes de resolver isso para que possamos trazer a melhor experiência possível para todos os jogadores.
Obrigado por ler!
/ @ProgrammerarN
Artigos técnicos
Alguns artigos que usamos de inspiração para nosso modelo de network que usamos em diferentes áreas da jogabilidade de Battlerite.
http://fabiensanglard.net/quake3/network.php
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization