Modelo de autoridade do servidor

Em um modelo de autoridade do servidor, o servidor é a única fonte de 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 da rede de um jogo justo e competitivo, pois impede classes inteiras de trapaças, como flyhacks ou speedhacks, ao nunca confiar em um cliente para 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, um sistema desse tipo enfrentaria uma latência de entrada significativa, pois cada ação do jogador precisaria 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, não responsiva e injogável.

No modelo de autoridade do servidor do Roblox, a latência é compensada ao fazer com que os clientes instantaneamente predigam 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 a resposta do servidor; em vez disso, ele prediz 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 fazendo o jogo parecer 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:

Quando uma previsão errada é 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 desfazer e resimular seus quadros previstos. Esse sistema de previsão do lado do cliente, desfazer e resimulação é conhecido como "compensação de latência" e ajuda a fazer jogos multiplayer com autoridade de servidor parecerem suaves e responsivos.

Configuração

O modelo de autoridade do servidor requer certas outras tecnologias do motor para funcionar corretamente. Confirme as seguintes configurações de propriedade no objeto Workspace no Explorer:

1. Workspace.AuthorityMode deve ser Server (configurar isso define automaticamente os próximos cinco).
2. Workspace.NextGenerationReplication deve estar habilitado.
3. Workspace.PlayerScriptsUseInputActionSystem deve estar habilitado.
4. Workspace.SignalBehavior deve ser Deferred.
5. Workspace.UseFixedSimulation deve estar habilitado.
6. Workspace.StreamingEnabled deve estar habilitado.

Conceitos

O sistema de autoridade do servidor opera em alguns conceitos centrais, 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 os efeitos das entradas do jogador imediatamente. Isso oculta a latência da entrada, mas a previsão pode depois ser incorreta (misprediction) e, portanto, necessitar de correção. O cliente tenta simular apenas até certo ponto à 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 prevê à frente do estado conhecido do servidor é baseado na latência entre o cliente e o servidor.

Previsão errada do cliente

Quando o cliente recebe o estado autoritativo do servidor, ele verifica esse estado contra um registro histórico do que previu localmente para aquele quadro. Quando há uma diferença entre o que o cliente predisse e o que o servidor realmente fez, isso é uma previsão errada. Previsões erradas podem ocorrer por várias razões, incluindo variações na latência da rede, outros jogadores atuando de maneiras que o cliente não previu, o jogo rodando certa lógica exclusivamente no servidor, etc.

Se o estado autoritativo for diferente do estado previsto pelo cliente, o cliente deve desfazer e resimular.

Desfazer e resimulação

Quando um cliente detecta uma previsão errada, ele deve redefinir para o estado autoritativo do servidor e então resimular para voltar ao seu quadro previsto. Com base na latência da rede, o cliente tenta simular apenas até certo ponto à frente do último estado autoritativo do servidor conhecido para que suas entradas cheguem ao servidor no quadro pretendido.

Em resumo, o cliente:

1. Recebe o estado autoritativo do servidor e o compara ao seu próprio estado previsto.
2. Se a previsão do cliente estiver incorreta:

   1. O cliente volta ao último estado autoritativo conhecido recebido do servidor.
   2. O cliente resimula do estado autoritativo ao seu estado previsto, reaplicando quaisquer entradas locais.

Implementação

Propriedade e previsão de rede

No modelo de autoridade do servidor, você pode manter os objetos de jogo fundamentais com 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 com propriedade do servidor, mesmo ao interagir com outros jogadores.

Por padrão, o Roblox irá automaticamente prever propriedades com acesso à simulação próximas ao personagem do jogador local Character, mas se você quiser mais controle fino, pode forçar explicitamente a previsão de uma instância com RunService:SetPredictionMode().

Sincronização de simulação

No modelo de autoridade do servidor, o cliente e o servidor devem ambos rodar a simulação central, e a simulação do cliente precisa ser capaz de desfazer e resimular quando ocorre uma previsão errada. Para permitir isso, escreva sua lógica central dentro de funções vinculadas através de RunService:BindToSimulation() em um ModuleScript que é inicializado tanto no cliente quanto no servidor.

Durante uma resimulação, o Roblox irá reexecutar as funções vinculadas à simulação via BindToSimulation(). Processar entradas de jogadores, interagir com objetos físicos sincronizados e atualizar o estado central do jogo devem viver dentro dessas funções vinculadas.

ModuleScript chamado Simulação em ReplicatedStorage:

local RunService = game:GetService("RunService")
local Players = game:GetService("Players")

local Simulacao = {}

Simulacao.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- Ler entradas de jogadores
		-- Atualizar estado do jogo
	end)
end

return Simulacao

Sincronização de estado com atributos

O Roblox sincroniza automaticamente todas as propriedades com acesso à simulação em instâncias previstas. Para dados personalizados, atributos são a principal maneira de sincronizar instâncias marcadas como previstas; em tais instâncias, qualquer discrepância nos valores dos atributos entre a fonte de verdade do servidor e a previsão do cliente acionará um desfazimento e resimulação completo.

Limites dos atributos

Para ser replicado, um atributo deve atender a todos os seguintes critérios:

• Ele deve estar entre os primeiros 64 atributos em sua Instance.
• Seu nome deve conter no máximo 50 caracteres.
• Se um atributo do tipo string, seu valor deve conter no máximo 50 caracteres.

Acesso à simulação

Muitas propriedades e métodos na referência da API do motor incluem o rótulo Acesso à Simulação, por exemplo BasePart.CFrame. Propriedades com este rótulo serão previstas pelo sistema de autoridade do servidor. Além disso, apenas propriedades e métodos com este rótulo podem ser acessados dentro de funções vinculadas com RunService:BindToSimulation().

Ações de entrada

Em um jogo com autoridade de 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 reproduzidas durante a resimulaçã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.

Observe que InputContexts deve ser um descendente de um Player para que o motor saiba quem tem propriedade sobre o InputContext. Uma abordagem é adicionar seu InputContexts a uma pasta sob ReplicatedStorage e usar um Script sob ServerScriptService para clonar o InputContexts por jogador:

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 determinado 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 acionada.

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 divulgar dados sobre jogadores pontuando 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.

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 é meramente uma previsão do estado autoritativo do servidor. BindToSimulation() limita quais propriedades e métodos podem ser chamados a partir 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.

Orientações adicionais sobre a renderização de uma simulação prevista estão cobertas no guia de técnicas avançadas.

Projetos de exemplo

Além desta documentação, os seguintes templates podem ajudar você a começar: