Existem vários métodos para reduzir ou disfarçar atrasos, embora muitos destes tenham os seus inconvenientes e possam não ser aplicáveis em todos os casos. Se a sincronização não for possível pelo próprio jogo, os clientes podem optar por jogar em servidores na proximidade geográfica de si próprios, a fim de reduzir as latências, ou os servidores podem simplesmente optar por abandonar clientes com latências elevadas, a fim de evitar ter de lidar com os problemas resultantes. No entanto, estas dificilmente são as melhores soluções. Em vez disso, os jogos serão muitas vezes concebidos com a compensação de atrasos em mente.
Muitos problemas podem ser resolvidos simplesmente permitindo aos clientes manter o controlo do seu próprio estado e enviar estados absolutos para o servidor ou directamente para outros clientes. Por exemplo, o cliente pode indicar exactamente em que posição se encontra o personagem de um jogador ou quem o personagem filmou. Esta solução funciona e eliminará praticamente todos os problemas relacionados com o atraso. Infelizmente, também se baseia no pressuposto de que o cliente é honesto. Não há nada que impeça um jogador de modificar os dados que envia, directamente ao cliente ou indirectamente através de um procurador, a fim de garantir que atingirá sempre os seus alvos. Nos jogos online, o risco de fazer batota pode inviabilizar esta solução, e os clientes limitar-se-ão a enviar estados relativos (ou seja, em que vector se moveu ou disparou).
Client-sideEdit
Como normalmente os clientes não estão autorizados a definir o estado principal do jogo, mas sim a recebê-lo do servidor, a principal tarefa da compensação do lado do cliente é tornar o mundo virtual tão preciso quanto possível. Como as actualizações vêm com um atraso e podem até ser abandonadas, é por vezes necessário que o cliente preveja o fluxo do jogo. Uma vez que o estado é actualizado em etapas discretas, o cliente deve ser capaz de estimar um movimento com base nas amostras disponíveis. Dois métodos básicos podem ser utilizados para o conseguir; extrapolação e interpolação.
Extrapolação é uma tentativa de estimar um estado futuro do jogo. Assim que um pacote do servidor é recebido, a posição de um objecto é actualizada para a nova posição. À espera da próxima actualização, a posição seguinte é extrapolada com base na posição actual e no movimento no momento da actualização. Essencialmente, o cliente assumirá que um objecto em movimento continuará na mesma direcção. Quando um novo pacote é recebido, a posição pode ser ligeiramente corrigida.
Interpolação funciona, essencialmente, amortecendo um estado de jogo e tornando o estado de jogo para o jogador com um ligeiro e constante atraso. Quando um pacote do servidor chega, em vez de actualizar imediatamente a posição de um objecto, o cliente começará a interpolar a posição, começando a partir da última posição conhecida. Ao longo de um intervalo de interpolação, o objecto será renderizado movendo-se suavemente entre as duas posições. Idealmente, este intervalo deve corresponder exactamente ao atraso entre pacotes, mas devido a perda e atraso variável, este é raramente o caso.
Ambos os métodos têm vantagens e desvantagens.
- Interpolação assegura que os objectos se moverão apenas entre posições válidas e produzirão bons resultados com atraso constante e sem perda. Se os pacotes caírem ou ficarem fora de ordem, o tampão de interpolação será bloqueado pelo cliente até à chegada de um novo pacote, ou, em vez disso, cair por extrapolação. O lado negativo da interpolação é que faz com que o mundo seja rendido com latência adicional, aumentando a necessidade de alguma forma de compensação de atraso a ser implementada.
li> O problema da extrapolação de posições é bastante óbvio: é impossível prever com precisão o futuro. Só renderizará correctamente o movimento se este for constante, mas nem sempre será esse o caso. Os jogadores podem mudar tanto a velocidade como a direcção ao acaso. Isto pode resultar numa pequena quantidade de “empenos” à medida que novas actualizações chegam e as posições estimadas são corrigidas, e também causar problemas para a detecção de acertos, uma vez que os jogadores podem ser renderizados em posições em que não estão de facto em.
Muitas vezes, a fim de permitir uma jogabilidade suave, o cliente é autorizado a fazer alterações suaves ao estado do jogo. Enquanto o servidor pode, em última análise, manter o registo das munições, saúde, posição, etc., o cliente pode ser autorizado a prever o novo estado do jogo do lado do servidor com base nas acções do jogador, tal como permitir que um jogador comece a mover-se antes de o servidor ter respondido ao comando. Estas alterações serão geralmente aceites em condições normais e tornam o atraso mais transparente. Os problemas só surgirão no caso de grandes atrasos ou perdas, quando as previsões do cliente forem muito notoriamente desfeitas pelo servidor. Por vezes, no caso de pequenas diferenças, o servidor pode mesmo permitir alterações “incorrectas” ao estado com base em actualizações do cliente.
Server-sideEdit
Unlike clients, o servidor conhece o estado actual exacto do jogo, e como tal a previsão é desnecessária. O principal objectivo da compensação de atraso do lado do servidor é, em vez disso, fornecer efeitos precisos das acções do cliente. Isto é importante porque, quando o comando de um jogador chegar, o tempo terá passado, e o mundo já não estará no estado que o jogador viu ao emitir o seu comando. Um exemplo muito explícito disto é a detecção de acertos de armas disparadas em atiradores em primeira pessoa, onde as margens são pequenas e podem potencialmente causar problemas significativos se não forem devidamente manuseadas.
Rewind timeEdit
Outra forma de abordar a questão é armazenar estados de jogo passados durante um certo período de tempo, depois rebobinar as localizações dos jogadores ao processar um comando. O servidor utiliza a latência do jogador (incluindo qualquer atraso inerente devido a interpolação; ver acima) para rebobinar o tempo por uma quantidade apropriada, a fim de determinar o que o cliente do tiro viu no momento em que o tiro foi disparado. Isto resultará normalmente em que o servidor verá o cliente a disparar na posição antiga do alvo e assim atingir o alvo. Na pior das hipóteses, um jogador estará tão atrasado que o servidor ficará sem dados históricos e terá de começar a liderar os seus alvos.
Esta é uma solução WYSIWYG que permite aos jogadores apontar directamente para o que estão a ver. Mas o preço é um agravamento dos efeitos da latência quando um jogador está debaixo de fogo: não só a sua própria latência desempenha um papel, mas também o do seu atacante. Em muitas situações, isto não é perceptível, mas os jogadores que acabam de se abrigar notarão que continuam a receber mensagens de danos/morte do servidor durante mais tempo do que a sua própria latência pode justificar. Isto pode levar mais frequentemente à (falsa) impressão de que foram alvejados através da cobertura e à (não totalmente imprecisa) impressão de “caixas de acerto atrasadas”.
Um problema de concepção que surge da rebobinagem é se devem parar de rebobinar os comandos atrasados de um jogador morto assim que morrem no servidor, ou se devem continuar a executá-los até “apanharem” até à hora da morte. O corte da compensação evita imediatamente que as vítimas ataquem postumamente os seus assassinos, o que corresponde às expectativas, mas preserva a vantagem natural de mover os jogadores que se aproximam de uma esquina, adquirem um alvo e os matam em menos tempo do que uma ida e volta ao cliente da vítima estacionária.
p>Rewinding pode ser criticado por permitir que a alta latência de um jogador afecte negativamente a experiência dos jogadores com baixa latência. Servidores com compensação de atraso irão por vezes reduzir a duração do histórico do jogador armazenado, ou impor limites de ping, para reduzir este problema.
Confiar nos clientesEditar
É possível aos clientes dizerem ao servidor o que estão a fazer e ao servidor confiarem nos dados que recebem. Este método é evitado se de todo possível devido à sua susceptibilidade à fraude: é uma questão simples encaminhar os dados da rede através de um segundo computador que insere mensagens de acerto fabricadas ou modifica as existentes, uma técnica que não pode ser detectada por ferramentas anti-batota.
No entanto, a escala pura de alguns jogos torna impossível soluções computacionalmente caras como a rebobinagem. No Battlefield 3, por exemplo, é utilizado um sistema de “detecção de acerto híbrido” onde os clientes dizem ao servidor que acertaram e o servidor efectua apenas um vago teste de plausibilidade antes de aceitar a reclamação.
Confiar nos resultados de um cliente tem as mesmas vantagens e desvantagens que rebobinar.
Fazer os clientes extrapolarEditar
Uma solução de atraso menos comum é não fazer nada no servidor e ter cada cliente a extrapolar (ver acima) para cobrir a sua latência. Isto produz resultados incorrectos, a menos que os jogadores remotos mantenham uma velocidade constante, concedendo uma vantagem àqueles que se esquivam para trás e para a frente ou simplesmente começam/páram de se mover.
Uma extrapolação alargada também resulta em jogadores remotos se tornarem visíveis (embora não vulneráveis) quando não deveriam estar: por exemplo, se um jogador remoto saltar até uma esquina e depois parar abruptamente na borda, outros clientes irão torná-los a saltar para a frente, para o aberto, durante a duração da sua própria latência. Do outro lado deste problema, os clientes têm de dar aos jogadores remotos que acabaram de começar a mover-se uma explosão extra de velocidade, a fim de os empurrar para uma localização teoricamente precisa.
DesignEdit
É possível reduzir a percepção de atraso através do design do jogo. As técnicas incluem jogar animações do lado do cliente como se a acção tivesse tido lugar imediatamente, reduzindo/removendo temporizadores incorporados na máquina anfitriã, e utilizando transições de câmara para esconder deformações.