Jogos em rede, como seus jogos no Roblox, vêm com o frustrante e inevitável problema de lag. Se o seu jogo for FilteringEnabled, você provavelmente usará um número decente de 
RemoteFunctions ou 
RemoteEvents. Se você usar RemoteFunctions ou RemoteEvents, haverá necessariamente lag em seu jogo. Felizmente, existem algumas estratégias que você pode usar para adotar esse atraso e integrá-lo perfeitamente à funcionalidade do jogo.
Conteúdo
- 1 A fonte do atraso
- 2 canhões laggy
- 2.1 O Canhão Azul
- 2.2 Lição 1: Tenha cuidado com seu código
- 2.3 O Canhão Laranja
- 2.4 Lição 2: Sincronizar a Experiência
- 2.5 O Canhão Vermelho
- 2.6 Lição 3: Sem atraso de entrada!
- 2.7 O Alvo Roxo
- 2.8 Lição 4: Divida seus scripts
- 3 lag no mundo real
- 4 Teste de lag no Studio
A fonte do atraso
Antes de aprender algumas estratégias que escondem o lag, é importante ter um modelo mental preciso de por que o lag deve existir em jogos com chamadas remotas.
Digamos que você seja um de nossos usuários no Reino Unido e esteja jogando um jogo ROBLOX FilteringEnabled. Neste jogo, um script local permite que você pressione a tecla 'F' para disparar um canhão. O desenvolvedor deste jogo decidiu que balas de canhão são muito importantes para o cliente manipular. Conseqüentemente, o script local faz uma chamada remota ao servidor para que seja o servidor a disparar. Quando o cliente detecta que a tecla 'F' foi pressionada, ele contata o servidor, o servidor dispara o canhão e o servidor permite que o cliente saiba o que aconteceu como resultado. No entanto, como seu computador está no Reino Unido e os servidores Roblox estão nos Estados Unidos, isso exige que um sinal seja transmitido por todo o Oceano Atlântico. Duas vezes. Isso leva tempo, e agora vem na forma de um atraso irritante entre pressionar a tecla 'F' e realmente ver o tiro de canhão.
Laggy Cannons
Para tornar o último exemplo um pouco menos hipotético, este tutorial é acompanhado por um jogo ROBLOX simples chamado "Laggy Cannons". Você pode jogá-lo online aqui, e também pode baixar a versão Studio para você mesmo, se desejar.
Em Laggy Cannons, existem quatro canhões apontados na direção de quatro alvos móveis. Cada par de canhão-alvo é afetado pelo mesmo tempo de retardo artificialmente exagerado, mas cada par de canhão-alvo aborda esse retardo de uma maneira ligeiramente diferente. Alguns pares lidam com esse lag melhor do que outros. O par roxo é melhor do que o vermelho, o par vermelho é melhor do que o laranja e o par laranja é melhor do que o azul.
Antes de ler o resto deste tutorial, agora seria um bom momento para jogar Laggy Cannons e ver se você pode sentir as diferenças entre os quatro. Para jogar Laggy Cannons, use os quatro teletransportadores próximos ao ponto de desova para se teletransportar para os blocos de canhão com as cores correspondentes. Quando estiver em uma base de canhão, você pode pressionar 'F' para disparar uma bala de canhão e tentar acertar o alvo móvel do canhão. Pise na área colorida da plataforma do canhão para retornar às plataformas de teletransporte e tente outro canhão. Você pode manipular o número de segundos de lag artificial clicando nos botões '+' e '-' no painel de controle próximo ao ponto de desova. O restante deste tutorial explica em detalhes como o canhão ou alvo de cada cor se comporta e por quê. Também generalizaremos as estratégias que cada par usa para que você possa aplicá-las mais facilmente aos seus jogos.
O canhão azul
Vamos começar com o canhão que realmente não tenta: o canhão azul. Se você pressionar a tecla 'F', verá e ouvirá imediatamente a explosão do tiro do canhão, mas não verá a bala por um bom tempo. Esta é a função que é chamada em um script local quando você dispara o canhão azul:
--Em um script local função local badCannonStrategy () Workspace.FireCannonEvent: FireServer (activeCannon) createExplosion (activeCannon) end
A primeira linha desta função usa um RemoteEvent chamado “FireCannonEvent” para pedir ao servidor para disparar uma variável global chamada “activeCannon”. O canhão ativo aqui é, obviamente, o canhão azul. FireCannonEvent é uma solicitação unilateral para o servidor. Depois de enviar ao servidor uma mensagem pedindo para disparar o canhão azul, este script local imediatamente passa a mostrar uma explosão na tela usando a função auxiliar não mostrada “createExplosion”. Não há nenhum esforço aqui para trabalhar com o lag que é inerente ao RemoteEvent. A mensagem é enviada, a explosão é criada e então esperamos que o servidor dispare o projétil.
Lição 1: Tenha cuidado com seu código
A função badCannonStrategy () parece inocente o suficiente. Ele dispara o canhão e provoca uma explosão, não é isso que queremos? O problema é que ele ignora o lag completamente, e isso é muito fácil de fazer. Se você quer fazer jogos excelentes, deve notar que aqui haverá lag. Continue lendo para saber o que você pode fazer a respeito.
O canhão laranja
O canhão laranja modifica ligeiramente a estratégia do canhão azul para sincronizar o disparo do projétil com a explosão. A função que dispara o canhão laranja é assim:
--Em um script local função local okCannonStrategy () local waitForResponse = Workspace.FireCannonFunction: InvokeServer (activeCannon) createExplosion (activeCannon) end
Você pode ver que a única mudança aqui é a primeira linha da função. Em vez de usar um RemoteEvent para disparar a bala de canhão, o canhão laranja usa um RemoteFunction chamado “FireCannonFunction”. Um RemoteFunction difere de um RemoteEvent porque tem um valor de retorno. Enquanto um RemoteEvent é apenas um sinal do cliente para o servidor, um RemoteFunction é um sinal do cliente para o servidor e também um valor de retorno do servidor para o cliente. Além disso, como o cliente espera um valor de retorno, ele realmente aguardará esse valor de retorno antes de prosseguir em seu script local. Este é exatamente o recurso do qual o script do canhão laranja tira vantagem. Esta função de disparo de canhão ligeiramente melhor espera que o servidor diga que disparou uma bala de canhão antes de prosseguir para criar a explosão que a acompanha.
Lição 2: sincronizar a experiência
O canhão azul não faz sentido porque você vê a explosão do canhão muito antes de ver a bala. No mundo real, explosões e disparos de balas de canhão ocorrem simultaneamente. Para que um jogo seja divertido e envolvente, ele não deve violar as expectativas do jogador sobre coisas bobas como essa. Siga o exemplo do canhão laranja e use RemoteFunctions para sincronizar eventos no cliente e no servidor.
O canhão vermelho
Embora o canhão laranja resolva o problema de balas de canhão não sincronizadas e explosões, ele na verdade expõe outro problema com o lag. Quando o jogador pressiona a tecla 'F' para disparar, há um atraso significativo antes de o jogo responder. Isso é chamado de lag de entrada e é uma das coisas que os jogadores mais odeiam. Existe um truque simples que você pode usar para remover o atraso de entrada. Você não pode acelerar o tempo que o canhão leva para disparar. Não importa o que aconteça, isso vai levar o tempo de ida e volta que leva para uma mensagem ir do cliente ao servidor e ao cliente. Você pode, entretanto, dar ao jogador algum outro feedback imediato que o fará sentir que o jogo está respondendo aos seus comandos. O feedback imediato que o canhão vermelho escolhe dar é um som. Quando o jogador pressiona 'F', o canhão vermelho imediatamente começa a tocar o som de um fusível de canhão queimando. Este som será reproduzido pelo tempo que levar para o servidor responder ao RemoteFunction. Assim que o servidor responde, o canhão vermelho desliga o som do fusível em chamas e cria uma explosão que acompanha o projétil que o servidor acabou de disparar.
--Em um script local função local bestCannonStrategy () Workspace.Sounds.BurningFuse: Play () local waitForResponse = Workspace.FireCannonFunction: InvokeServer (activeCannon) Workspace.Sounds.BurningFuse: Stop () createExplosion (activeCannon) end
Se você for brincar com o canhão vermelho, deve parecer totalmente natural. Ainda há um atraso entre pressionar a tecla 'F' e ver o disparo da bala de canhão, mas é imperceptível porque o canhão incorpora esse atraso na maneira como funciona.
Lição 3: Sem atraso de entrada!
Os jogadores odeiam lag de entrada. É frustrante sentir uma desconexão entre você e o jogo. Embora possa ser necessário ter uma resposta lenta para a entrada do jogador, você sempre pode dar a eles algo pequeno para indicar que seu pedido foi ouvido. Pode ser um som, uma mudança na cor do tijolo ou realmente qualquer coisa. Deixe os jogadores saberem que estão sendo ouvidos e você terá jogadores felizes.
O Alvo Roxo
O canhão roxo funciona exatamente da mesma maneira que o canhão vermelho. A diferença entre a plataforma roxa e todas as outras cores é a funcionalidade do alvo móvel.
Ao atingir o alvo azul, laranja ou vermelho, você notará que há um atraso entre ver o alvo ser atingido e o som de “ding” resultante e atualização da pontuação. Como exemplo, o “ding” e a atualização de pontuação para o alvo azul são executados pela seguinte função de servidor:
--Server script Workspace.Blue.Target.Face.Touched: connect (function (projectile) wait (_G.artificialLag) - Como Laggy Cannons cria lag artificial --Reproduzir som de acerto de alvo Workspace.Sounds.TargetHit: Play () - -Atualizar pontuação azul blueScore = blueScore + 1 Workspace.Blue.Scoreboard.SurfaceGui.ScoreLabel.Text = blueScore end)
Sabemos que algo tão importante quanto a pontuação do jogador deve ser tratado pelo servidor. Portanto, deve haver um atraso ao atualizar a pontuação de um alvo. Mas e quanto ao som de acertar o alvo?
Embora seja o servidor quem decide se o alvo foi atingido ou não, o cliente é perfeitamente capaz de reproduzir imediatamente o próprio som de acerto do alvo. Na pior das hipóteses, se o cliente e o servidor têm uma rara discordância sobre se o alvo foi atingido, o jogador experimentará uma discrepância entre o som de “ding” e a atualização da pontuação. Isso pode acontecer uma em cinco mil vezes e é um custo que vale a pena dar um feedback imediato ao jogador. Portanto, podemos realmente dividir o script de servidor anterior em um script de servidor e um script local:
--Script de servidor Workspace.Purple.Target.Face.Touched: Connect (function (projectile) wait (_G.artificialLag) -– (Como Laggy Cannons cria lag artificial) --Update purple score purpleScore = purpleScore + 1 Workspace.Purple. Scoreboard.SurfaceGui.ScoreLabel.Text = purpleScore end) - Script local Workspace.Purple.Target.Face.Touched: connect (função (projétil) --Reproduzir som de hit de destino Workspace.Sounds.TargetHit: Play () end)
Lição 4: Divida seus scripts
Às vezes, você precisa fazer metade do trabalho no servidor e metade no cliente. Não tenha medo de detectar o mesmo evento duas vezes. A detecção local fornece feedback ao jogador, e a detecção do servidor lida com importantes lógicas do jogo.
Atraso no mundo real
O atraso artificial padrão para Laggy Cannons é de um segundo. Isso é adicionado a qualquer lag que sua máquina experimente naturalmente ao jogar um jogo ROBLOX. Em nossa base de jogadores, vemos jogadores com lag variando de 0.1 a 1.5 segundos. O atraso médio parece pairar em torno de 0.3 segundos. Felizmente, agora você está equipado com as ferramentas para lidar com esse atraso.
Teste de atraso no Studio
Se você deseja simular lag no ROBLOX Studio, você pode ir para Arquivo -> Configurações -> Rede -> IncomingReplicationLag e ajustar o número de segundos de lag que o Studio irá simular ao executar um servidor de teste.
