Nota: Usaremos 30 fps como referência neste blog por ser o ponto em comum de For Honor em todas as plataformas.
GÊNESE DO AJUSTE DE TEMPO
A Arte da Batalha tem sido o núcleo do design de For Honor desde o princípio. Portanto, sempre foi muito importante para nós garantir que o ataque e defesa baseados em postura fossem os mais claros possíveis e fáceis de interpretar. Aqui está um pequeno exemplo do problema inicial que nossa equipe enfrentou enquanto desenvolvia o jogo:
No Vídeo 1, é possível ver uma mudança de postura que bloqueia com sucesso o ataque quando o jogador defensor realiza o comando no último segundo.
Comparamos com esta falha ao bloquear, no qual o defensor altera a postura 33 ms mais tarde. Como visto no Vídeo 2, consideramos que a diferença não era clara o suficiente e causaria frustração no jogador defensor. Decidimos que para ser mais fácil de interpretar, a diferença entre um bloqueio bem-sucedido e malsucedido deveria ser ao menos 100 ms.
Para conseguir isso, criamos o sistema de "Ajuste de Tempo", que alinha as ações de todos os jogadores pelos próximos 100 ms em um relógio global. Como exibido na Imagem 1, embora o Jogador 1 tenha pressionado o botão de ataque 33 ms antes do Jogador 2, eles acontecerão ao mesmo tempo, levando a um caso de acerto duplo.
PROBLEMAS COM AJUSTE DE TEMPO
O maior problema do Ajuste de Tempo é que ele introduz um atraso de comando aleatório de 0 ms, 33 ms ou 66 ms, dependendo de quando o jogador realizou o comando no relógio global. No momento, ainda durante o desenvolvimento, nossa equipe achou que seria um impacto aceitável, mas rapidamente mudamos de opinião sobre isso.
Continuamos trabalhando no balanceamento e conforto, recebemos feedback de testes internos e externos e ficamos insatisfeitos com a resposta do comando de mudança de postura. Escolhemos remover o Ajuste de Tempo da mudança de postura, o que resolveu alguns dos problemas de resposta de comando, mas enfraqueceu fortemente o objetivo inicial do recurso.
Após lançarmos o jogo, decidimos remover o Ajuste de Tempo completamente por desejarmos remover a inconsistência na resposta do comando. Como o sistema agia para compensar a latência de rede, removê-lo causaria outros impactos à jogabilidade.
Vamos ver os diferentes casos usados para explicar melhor como este sistema funcionava quando estava ativo. Por questões de simplicidade, vamos assumir que temos uma latência de 100 ms para o agressor e defensor.
Na Imagem 2, o agressor realizar o comando aos 400 ms, então o ataque inicia imediatamente. O defensor recebe este comando com 100 ms de atraso, então perde os primeiros 100 ms do ataque.
Se olharmos na Imagem 3, o agressor realiza o comando aos 366 ms, então o ataque começa aos 400 ms. Este atraso de comando de 33 ms age como compensação de latência de rede, já que agora o defensor perde apenas os primeiros 66 ms do ataque.
Finalmente, na Imagem 4, o agressor realiza o comando aos 333 ms e o ataque inicia aos 400 ms. Aqui temos 66 ms de atraso de comando que permite o defensor perder apenas os primeiros 33 ms do início do ataque.
Considerando que essa compensação de latência de rede era aleatória e incerta, não era o ideal para os jogadores reagirem de forma segura aos ataques. Nós pensamos que, já que 1 de 3 vezes o ataque não tinha compensação de latência, remover o Ajuste de Tempo não afetaria negativamente a capacidade de reação dos jogadores. Porém, o feedback da comunidade deixou claro que, para substituir o sistema inconsistente do Ajuste de Tempo, precisávamos encontrar uma solução para a perda de informação extra gerada pela remoção dele.
IMPLEMENTAÇÃO ATUAL
A implementação proposta aqui é uma abordagem híbrida de atraso de comando: todos os comandos considerados "ofensivos" (veja a lista abaixo) serão atrasados em 33 ms. Este valor não afeta muito a reatividade de comando, já que afeta apenas as ações "ofensivas" que são, por design, longas. Como explicado na Imagem 5, se um agressor ativa um ataque a partir do personagem ocioso, em vez de iniciar o ataque imediatamente localmente, ele iniciará 33 ms depois. Desta forma, a parte oculta do ataque para o defensor será reduzida pelo atraso de comando (de 100 ms para 66 ms), melhorando o período de reação.
Mas o que é um comando ofensivo?
- Ataques Fracos sempre são considerados ofensivos
- Ataques Fortes são considerados ofensivos, exceto quando é uma aparada, que não sofre atraso
- Quebra de Guarda é considerada ofensiva exceto quando usada defensivamente para responder uma Quebra de Guarda, que não sofre atraso
- Alteração de postura no mesmo quadro de um Ataque Forte ou Fraco atrasará a mudança de postura para iniciar o ataque
- Esquiva ou Cancelamento/Finta são considerados ofensivos se forem ativados enquanto um comando ofensivo já foi atrasado, evitando inversão que poderia gerar piscadas
- Soltar a Quebra de Guarda, Ataque Fraco ou Ataque Forte também é considerado um comando ofensivo, já que pode ativar ataques para certos personagens (Corrida Tempestuosa de Orochi, por exemplo)
PRÓXIMOS PASSOS
Após testar isso internamente e com membros da comunidade, consideramos ser um bom primeiro passo para melhorar a capacidade de reação nas lutas. Isso causará um leve impacto no tempo de execução de certas ações como sequências, combinações ou cancelamentos, sendo necessário realizar os comandos 33 ms mais cedo. Estamos atualmente investigando formas adicionais de melhorar nosso gerenciamento de latência da rede no jogo, mas queríamos lançar isso primeiro para fornecer uma experiência melhor o mais cedo possível. Como sempre, vamos mantê-los atualizados sobre quaisquer atualizações quanto a este assunto.
