Em um modelo de autoridade do servidor, o servidor é a única fonte da verdade para todo o estado do jogo, e os clientes são apenas confiáveis para relatar suas próprias entradas. Essa arquitetura é a base fundamental do código de rede de um jogo justo e competitivo, pois evita classes inteiras de trapaças, como flyhacks ou speedhacks, ao nunca confiar que um cliente relatará sua própria posição ou estado.
Vantagens
Em um sistema ingênuo de propriedade do servidor, os clientes simplesmente enviariam suas entradas para o servidor e exibiriam os resultados do jogo enviados de volta pelo servidor. Embora tecnicamente correto, tal sistema enfrentaria uma latência de entrada significativa, pois cada ação do jogador teria que viajar até o servidor, ser processada e ter o resultado enviado de volta ao cliente antes que pudesse ser exibido. Para a maioria dos jogos, especialmente aqueles de ritmo acelerado, esse atraso de ida e volta faria com que a jogabilidade parecesse lenta, sem resposta e injogável.
No modelo de autoridade do servidor do Roblox, a latência é compensada fazendo com que os clientes prevejam instantaneamente os efeitos de suas entradas, além de enviá-las ao servidor. Por exemplo, quando um jogador pressiona uma tecla, o cliente não espera que o servidor responda; em vez disso, ele prevê alguns quadros à frente do último estado conhecido do servidor. Isso permite que o cliente mostre o resultado da ação de entrada instantaneamente, efetivamente ocultando a latência da rede e tornando o jogo mais responsivo.
Às vezes, o cliente pode errar em sua previsão (misprediction) e, devido à latência da rede, o cliente não saberá que cometeu um erro por alguns quadros. Por exemplo:
Seu cliente prevê que você se moveu para frente, mas no servidor, outro jogador usou uma habilidade de atordoamento que o impediu de se mover. O cliente e o servidor agora têm estados diferentes.
Quando uma mispredição é detectada, o cliente deve corrigir sua previsão com base no estado autoritativo do servidor. Se o estado autoritativo for diferente do estado previsto pelo cliente, o cliente deve reverter e ressatualizar seus quadros previstos. Esse sistema de previsão do lado do cliente, reversão e ressatualização é conhecido como "compensação de latência" e ajuda a fazer jogos multiplayer com autoridade do servidor parecerem suaves e responsivos.
Mispredictions são uma parte normal e esperada da arquitetura de autoridade do servidor porque os clientes, por sua natureza, não conseguem prever as entradas de outros jogadores, portanto, ações de outros jogadores sempre desencadearão alguma quantidade de mispredição. Quando ajustadas corretamente, as correções resultantes são pequenas e não devem ser perceptíveis para os jogadores. Leia mais sobre técnicas avançadas para suavizar e mascarar artefatos de rede.
Configuração
Como o modelo de autoridade do servidor requer certas outras tecnologias do motor para funcionar corretamente, você deve primeiro definir as seguintes propriedades no objeto Workspace no Explorer:
- Workspace.NextGenerationReplication deve ser habilitado
- Workspace.PlayerScriptsUseInputActionSystem deve ser habilitado
- Workspace.SignalBehavior deve ser Deferred
- Workspace.UseFixedSimulation deve ser habilitado
- Workspace.StreamingEnabled deve ser habilitado
- Workspace.AuthorityMode deve ser Server (todas as opções acima devem ser configuradas primeiro)
Conceitos
O sistema de autoridade do servidor opera com alguns conceitos fundamentais, conforme segue.
Previsão do cliente
Por meio da previsão do cliente, o cliente simula alguns quadros à frente do último estado conhecido do servidor para prever imediatamente os efeitos das entradas dos jogadores. Isso oculta a latência de entrada, mas a previsão pode se revelar incorreta posteriormente (client misprediction) e, portanto, requer correção. O cliente tenta simular apenas o suficiente à frente do último estado autoritativo do servidor conhecido para que suas entradas cheguem ao servidor no quadro pretendido. O número de quadros que o cliente preverá à frente do estado conhecido do servidor baseia-se na latência entre o cliente e o servidor.
Misprediction do cliente
Quando o cliente recebe o estado autoritativo do servidor, ele verifica esse estado em relação a um registro histórico do que previu localmente para aquele quadro. Quando há uma diferença entre o que o cliente previu e o que o servidor realmente fez, isso é uma misprediction. As mispredictions podem ocorrer por várias razões, incluindo variações na latência de rede, outros jogadores agindo de maneiras que o cliente não previu, o jogo executando certa lógica exclusivamente no servidor, etc.
Se o estado autoritativo for diferente do estado previsto pelo cliente, o cliente deve reverter e ressatualizar.
Reversão e ressatualização
Quando um cliente detecta uma misprediction, ele deve redefinir para o estado autoritativo do servidor e, em seguida, ressatualizar para voltar ao seu quadro previsto. Com base na latência da rede, o cliente tenta simular apenas o suficiente à frente do último estado autoritativo do servidor conhecido para que suas entradas cheguem ao servidor no quadro pretendido.
Em resumo, o cliente:
- Recebe o estado autoritativo do servidor e o compara com seu próprio estado previsto.
- Se a previsão do cliente estava incorreta:
- O cliente reverte para o último estado autoritativo conhecido recebido do servidor.
- O cliente ressatualiza do estado autoritativo para seu estado previsto, reaplicando quaisquer entradas locais.
Implementação
Propriedade de rede e previsão
No modelo de autoridade do servidor, você pode manter os objetos centrais de jogabilidade sendo de propriedade do servidor sem incorrer no custo de latência de entrada normalmente associado à propriedade do servidor. Coisas como carros, personagens de jogadores ou outros objetos críticos para a jogabilidade podem permanecer sob a propriedade do servidor, mesmo quando interagem com outros jogadores.
Por padrão, o Roblox preverá automaticamente propriedades com acesso de simulação próximas ao personagem local Character, mas se você quiser um controle mais detalhado, pode forçar explicitamente a previsão de uma instância ativando ou desativando com RunService:SetPredictionMode().
Sincronização de simulação
No modelo de autoridade do servidor, o cliente e o servidor devem executar a simulação central, e a simulação do cliente precisa ser capaz de reverter e ressatualizar quando ocorrer uma misprediction. Para habilitar isso, escreva sua lógica central dentro de funções vinculadas por meio de RunService:BindToSimulation() em um ModuleScript que é inicializado tanto no cliente quanto no servidor.
Durante uma ressatualização, o Roblox executará novamente as funções vinculadas à simulação por meio de BindToSimulation(). Processar entradas de jogadores, interagir com objetos de física sincronizados e atualizar o estado central do jogo devem viver dentro dessas funções vinculadas.
ModuleScript chamado Simulação em ReplicatedStorage:
Simulação
local RunService = game:GetService("RunService")
local Players = game:GetService("Players")
local Simulação = {}
Simulação.Initialize = function()
RunService:BindToSimulation(function(deltaTime)
-- Ler entradas dos jogadores
-- Atualizar estado do jogo
end)
end
return Simulação
Sincronização de estado com atributos
O Roblox sincroniza automaticamente todas as propriedades com acesso de simulação em instâncias previstas. Para dados personalizados, atributos são a principal maneira de sincronizar instâncias marcadas como previstas; nessas instâncias, qualquer discrepância nos valores dos atributos entre a fonte de verdade do servidor e a previsão do cliente desencadeará uma reversão e ressatualização.
Use atributos para armazenar dados do jogo que afetam sua simulação central, incluindo saúde do jogador, munição, inventário ou regras personalizadas (consulte limitações).
Escreva apenas em atributos em instâncias previstas a partir de dentro de funções vinculadas por meio de BindToSimulation() para garantir que o Roblox possa rastrear integralmente os estados de jogo relevantes e ressatualizar corretamente.
Limites de atributos
Para serem replicados, um atributo deve atender a todos os seguintes critérios:
- Deve estar entre os primeiros 64 atributos em sua Instance.
- Seu nome contém no máximo 50 caracteres.
- Se um atributo do tipo string, seu valor contém no máximo 50 caracteres.
Acesso de simulação
Muitas propriedades e métodos na referência da API do motor incluem o rótulo Acesso de Simulação, por exemplo, BasePart.CFrame. Propriedades com esse rótulo serão previstas pelo sistema de autoridade do servidor. Além disso, apenas propriedades e métodos com esse rótulo podem ser acessados dentro de funções vinculadas com RunService:BindToSimulation().
Ações de entrada
Em um jogo com autoridade do servidor, a principal maneira para um cliente afetar o estado do jogo é através do Sistema de Ação de Entrada. Essas entradas são enviadas ao servidor e são reproduzidas durante a ressatualização no cliente. Como resultado, InputActions deve ser usado para todas as entradas que afetam a simulação central e devem ser verificadas quanto à sanidade antes de serem processadas.
Para reiterar, não use eventos tradicionais como UserInputService.InputBegan na simulação central de um jogo com autoridade do servidor.
Observe que InputContexts deve ser um descendente de um Player para que o motor saiba quem tem propriedade sobre o InputContext. Uma abordagem é acrescentar seus InputContexts a uma pasta sob ReplicatedStorage e usar um Script sob ServerScriptService para clonar o InputContexts por jogador:
InputSetup
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local InputsFolder = ReplicatedStorage:WaitForChild("Inputs")
local function onPlayerAdded(player)
local clone = InputsFolder:Clone()
clone.Parent = player
end
Players.PlayerAdded:Connect(onPlayerAdded)
for _, player in Players:GetPlayers() do
onPlayerAdded(player)
end
Usando esse padrão, você pode ler InputActions para todos os jogadores em RunService:BindToSimulation() tanto no cliente quanto no servidor para receber os mesmos dados para um dado quadro e registrar a entrada do quadro anterior em um atributo, por exemplo, para acionar uma corrida do personagem quando uma ação de entrada RunAction for ativada.
Observe que, se você precisar escrever dados personalizados no Sistema de Ação de Entrada, deve usar uma função conectada a RunService.RenderStepped ou RunService:BindToRenderStep(), não RunService:BindToSimulation(). Disparar um InputAction em BindToSimulation() pode fazer com que os clientes produzam resultados incorretos durante uma ressatualização.
local Players = game:GetService("Players")
local RunService = game:GetService("RunService")
local Workspace = game:GetService("Workspace")
RunService:BindToRenderStep("CameraInput", Enum.RenderPriority.Last.Value, function()
-- Enviar o vetor para frente da câmera do cliente para o servidor através de um InputAction
local cameraForwardInputAction = Players.LocalPlayer.PlayContext.CameraForward
local cameraForwardVector = Workspace.CurrentCamera.CFrame.LookVector
cameraForwardInputAction:Fire(cameraForwardVector)
end)
Eventos remotos
Eventos remotos ainda podem ser usados dentro do modelo de autoridade do servidor para facilitar a comunicação discreta entre cliente e servidor. Por exemplo, os servidores podem usar eventos remotos para transmitir dados sobre jogadores marcando pontos ou pegando objetos, e os clientes podem usar eventos remotos como uma API alternativa para enviar entradas ao servidor, como pressionar botões ou tocar em objetos no mundo 3D.
RemoteEvents podem não ser ordenados consistentemente com atualizações de propriedades e atributos pela rede. Por exemplo, se você alterar uma propriedade antes de disparar um evento remoto em um cliente, o servidor pode receber a alteração da propriedade após o evento remoto. Para saber mais, consulte ordem de replicação.
Animações, sons e efeitos
Efeitos do lado do cliente, como animações e sons, devem ser escritos sabendo que a simulação do cliente é apenas uma previsão do estado autoritativo do servidor. BindToSimulation() limita quais propriedades e métodos podem ser chamados dentro de funções vinculadas para ajudar a guiá-lo a escrever apenas para o estado de simulação sincronizado. Exibir os resultados dessa simulação, acionar efeitos e sons, etc. deve ser feito em uma função separada conectada a RenderStepped que lê os resultados da simulação e aciona os efeitos desejados.
Mais orientações sobre a renderização de uma simulação prevista são abordadas no guia de técnicas avançadas.
Projetos de exemplo
Além desta documentação, os seguintes modelos podem ajudá-lo a começar:
