Modelo de autoridad del servidor

En un modelo de autoridad del servidor, el servidor es la única fuente de verdad para todo el estado del juego, y los clientes solo son confiables para informar sus propias entradas. Esta arquitectura es la base del netcode de un juego competitivo y justo porque previene clases enteras de trampas como flyhacks o speedhacks al no confiar nunca en un cliente para reportar su propia posición o estado.

Ventajas

En un sistema ingenuo de propiedad del servidor, los clientes simplemente enviarían sus entradas al servidor y mostrarían los resultados del juego devueltos por el servidor. Si bien es técnicamente correcto, tal sistema enfrentarían una latencia de entrada significativa porque cada acción del jugador tendría que viajar al servidor, ser procesada y tener el resultado enviado de vuelta al cliente antes de que pudiera mostrarse. Para la mayoría de los juegos, especialmente aquellos de ritmo rápido, esa demora de ida y vuelta haría que el juego se sintiera con retraso, sin respuesta e injugable.

En el modelo de autoridad del servidor de Roblox, la latencia se compensan al hacer que los clientes predigan instantáneamente los efectos de sus entradas además de enviarlas al servidor. Por ejemplo, cuando un jugador presiona una tecla, el cliente no espera a que el servidor responda; en su lugar, predice unos fotogramas adelante del último estado conocido del servidor. Esto permite que el cliente muestre el resultado de la acción de entrada al instante, ocultando efectivamente la latencia de la red y haciendo que el juego se sienta responsivo.

A veces, el cliente puede equivocarse en su predicción (mispredicción) y, debido a la latencia de red, el cliente no sabrá que ha cometido un error durante algunos fotogramas. Por ejemplo:

Cuando se detecta una mispredicción, el cliente debe corregir su predicción basándose en el estado autoritativo del servidor. Si el estado autoritativo es diferente del estado predicho por el cliente, este debe retroceder y re-simular sus fotogramas predichos. Este sistema de predicción del lado del cliente, retroceso y re-simulación se conoce como "compensación de latencia" y ayuda a que los juegos multijugador autoritativos del servidor se sientan fluidos y responsivos.

Configuración

El modelo de autoridad del servidor requiere ciertas tecnologías del motor para funcionar correctamente. Confirma la siguiente configuración de propiedades en el objeto Workspace en el Explorador:

1. Workspace.AuthorityMode debe ser Server (configurar esto automáticamente establece los siguientes cinco).
2. Workspace.NextGenerationReplication debe estar habilitado.
3. Workspace.PlayerScriptsUseInputActionSystem debe estar habilitado.
4. Workspace.SignalBehavior debe ser Deferred.
5. Workspace.UseFixedSimulation debe estar habilitado.
6. Workspace.StreamingEnabled debe estar habilitado.

Conceptos

El sistema de autoridad del servidor se basa en algunos conceptos clave como sigue.

Predicción del cliente

A través de la predicción del cliente, este simula unos fotogramas por delante del último estado conocido del servidor para predecir los efectos de las entradas del jugador de inmediato. Esto oculta la latencia de entrada, pero la predicción puede resultar ser incorrecta posteriormente (mispredicción del cliente) y, por lo tanto, requerir corrección. El cliente intenta simular solo lo suficiente por delante del último estado autoritativo conocido del servidor para que sus entradas lleguen al servidor en el fotograma previsto. El número de fotogramas que el cliente predice por delante del estado conocido del servidor se basa en la latencia entre el cliente y el servidor.

Mispredicción del cliente

Cuando el cliente recibe el estado autoritativo del servidor, comprueba ese estado contra un registro histórico de lo que predijo localmente para ese fotograma. Cuando hay una diferencia entre lo que el cliente predijo y lo que realmente hizo el servidor, esto es una mispredicción. Las mispredicciones pueden ocurrir por varias razones, incluidos cambios en la latencia de la red, otros jugadores actuando de maneras que el cliente no anticipó, la lógica del juego ejecutándose exclusivamente en el servidor, etc.

Si el estado autoritativo es diferente del estado predicho por el cliente, este debe retroceder y re-simular.

Retroceso y re-simulación

Cuando un cliente detecta una mispredicción, debe restablecerse al estado autoritativo del servidor y luego re-simular para volver a su fotograma predicho. Basado en la latencia de red, el cliente intenta simular solo lo suficiente por delante del último estado autoritativo conocido del servidor para que sus entradas lleguen al servidor en el fotograma previsto.

En resumen, el cliente:

1. Recibe el estado autoritativo del servidor y lo compara con su propio estado predicho.
2. Si la predicción del cliente fue incorrecta:

   1. El cliente retrocede al último estado autoritativo conocido recibido del servidor.
   2. El cliente re-simula desde el estado autoritativo hasta su estado predicho, reaplicando cualquier entrada local.

Implementación

Propiedad de la red y predicción

En el modelo de autoridad del servidor, puedes mantener los objetos centrales del juego en propiedad del servidor sin incurrir en los costos de latencia de entrada normalmente asociados con la propiedad del servidor. Cosas como automóviles, personajes de jugadores u otros objetos críticos del juego pueden permanecer como propiedad del servidor, incluso al interactuar con otros jugadores.

Por defecto, Roblox predecirá automáticamente las propiedades con acceso de simulación cerca del jugador local Character, pero si deseas un control más detallado, puedes forzar la predicción de una instancia explícitamente con RunService:SetPredictionMode().

Sincronización de simulación

En el modelo de autoridad del servidor, tanto el cliente como el servidor deben ejecutar la simulación central, y la simulación del cliente necesita poder retroceder y re-simular cuando ocurre una mispredicción. Para habilitar esto, escribe tu lógica central dentro de funciones vinculadas a través de RunService:BindToSimulation() en un ModuleScript que esté inicializado tanto en el cliente como en el servidor.

Durante una re-simulación, Roblox volverá a ejecutar las funciones vinculadas a la simulación a través de BindToSimulation(). El procesamiento de entradas de jugadores, la interacción con objetos físicos sincronizados y la actualización del estado central del juego deben estar dentro de esas funciones vinculadas.

ModuleScript llamado Simulación en ReplicatedStorage:

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

local Simulación = {}

Simulación.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- Leer entradas de jugadores
		-- Actualizar estado del juego
	end)
end

return Simulación

Sincronización de estado con atributos

Roblox sincroniza automáticamente todas las propiedades con acceso de simulación en instancias predichas. Para datos personalizados, los atributos son la principal manera de sincronizar instancias marcadas como predichas; en tales instancias, cualquier desajuste en los valores de los atributos entre la fuente de verdad del servidor y la predicción del cliente desencadenará un retroceso y re-simulación completo.

Límites de atributos

Para ser replicado, un atributo debe cumplir con todos los siguientes criterios:

• Está entre los primeros 64 atributos en su Instance.
• Su nombre contiene como máximo 50 caracteres.
• Si es un atributo de tipo cadena, su valor contiene como máximo 50 caracteres.

Acceso de simulación

Muchas propiedades y métodos en la referencia de la API del motor incluyen la etiqueta Acceso de Simulación, por ejemplo BasePart.CFrame. Las propiedades con esta etiqueta serán predichas por el sistema de autoridad del servidor. Además, solo las propiedades y métodos con esta etiqueta pueden ser accedidos dentro de funciones vinculadas con RunService:BindToSimulation().

Acciones de entrada

En un juego autoritativo del servidor, la forma principal para que un cliente afecte el estado del juego es a través del Sistema de Acción de Entrada. Estas entradas se envían al servidor y se reproducen durante la re-simulación en el cliente. Como resultado, InputActions debe ser utilizado para todas las entradas que afectan la simulación central y deben ser revisadas por su validez antes de ser procesadas.

Ten en cuenta que InputContexts debe ser un descendiente de un Player para que el motor sepa quién tiene la propiedad sobre el InputContext. Un enfoque es agregar tu InputContexts a una carpeta bajo ReplicatedStorage y usar un Script bajo ServerScriptService para clonar el InputContexts por jugador:

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 este patrón, puedes leer InputActions para todos los jugadores en RunService:BindToSimulation() tanto en el cliente como en el servidor para recibir los mismos datos para un fotograma dado y registrar la entrada del fotograma anterior en un atributo, por ejemplo para activar una carrera de personaje cuando se activa una acción de entrada RunAction.

Eventos remotos

Eventos remotos aún pueden ser utilizados dentro del modelo de autoridad del servidor para facilitar la comunicación discreta entre el cliente y el servidor. Por ejemplo, los servidores pueden usar eventos remotos para transmitir datos sobre jugadores que marcan puntos o recogen objetos, y los clientes pueden usar eventos remotos como una API alternativa para enviar entradas al servidor, como pulsaciones de botones o tocar objetos en el mundo 3D.

Animaciones, sonidos y efectos

Los efectos del lado del cliente como animaciones y sonidos deben ser escritos sabiendo que la simulación del cliente es simplemente una predicción del estado autoritativo del servidor. BindToSimulation() limita qué propiedades y métodos pueden ser llamados desde funciones vinculadas para ayudarte a escribir solo al estado de simulación sincronizado. Mostrar los resultados de esta simulación, activar efectos y sonidos, etc., debe hacerse en una función separada conectada a RenderStepped que lea los resultados de la simulación y active los efectos deseados.

Más orientación sobre la representación de una simulación predicha se cubre en la guía de técnicas avanzadas.

Proyectos de ejemplo

Además de esta documentación, las siguientes plantillas pueden ayudarte a comenzar: