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 informar 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 enviados de vuelta por el servidor. Si bien es técnicamente correcto, tal sistema enfrentaría 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 ser mostrado. Para la mayoría de los juegos, especialmente aquellos de ritmo rápido, ese retraso de ida y vuelta haría que la jugabilidad se sintiera lenta, poco receptiva e injugable.

En el modelo de autoridad del servidor de Roblox, la latencia se compensa haciendo 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 pocos fotogramas por delante del último estado conocido del servidor. Esto permite que el cliente muestre el resultado de la acción de entrada instantáneamente, ocultando efectivamente la latencia de la red y haciendo que el juego se sienta receptivo.

A veces, el cliente se equivoca en su predicción (misprediction) y, debido a la latencia de la red, el cliente no sabrá que ha cometido un error durante unos pocos fotogramas. Por ejemplo:

Cuando se detecta una mala predicció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, el cliente debe retroceder y volver a 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 con autoridad del servidor se sientan suaves y receptivos.

Configuración

El modelo de autoridad del servidor requiere ciertas otras 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 establece automáticamente 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 se indica a continuación.

Predicción del cliente

A través de la predicción del cliente, el cliente simula unos pocos 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 incorrecta más tarde (mala predicció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 predecirá por delante del estado conocido del servidor se basa en la latencia entre el cliente y el servidor.

Mala predicción del cliente

Cuando el cliente recibe el estado autoritativo del servidor, verifica 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 el servidor realmente hizo, esto es una mala predicción. Las malas predicciones pueden ocurrir por varias razones, incluyendo 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, el cliente debe retroceder y volver a simular.

Retroceso y re-simulación

Cuando un cliente detecta una mala predicción, debe restablecerse al estado autoritativo del servidor y luego volver a simular para regresar a su fotograma predicho. Basado en la latencia de la 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 vuelve a simular desde el estado autoritativo hasta su estado predicho, reaplicando cualquier entrada local.

Implementación

Propiedad de red y predicción

En el modelo de autoridad del servidor, puedes mantener los objetos centrales del juego como propiedad del servidor sin incurrir en el costo de latencia de entrada normalmente asociado con la propiedad del servidor. Cosas como coches, personajes de jugadores u otros objetos críticos para la jugabilidad pueden seguir siendo propiedad del servidor, incluso al interactuar con otros jugadores.

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

Sincronización de simulación

En el modelo de autoridad del servidor, el cliente y el servidor deben ejecutar ambos la simulación central, y la simulación del cliente necesita poder retroceder y volver a simular cuando ocurre una mala predicción. Para habilitar esto, escribe tu lógica central dentro de funciones vinculadas a través de RunService:BindToSimulation() en un ModuleScript que se inicializa 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(). Procesar las entradas de los jugadores, interactuar con objetos físicos sincronizados y actualizar el estado central del juego debe realizarse dentro de esas funciones vinculadas.

Usa time() para cualquier lógica basada en el tiempo dentro de una función de simulación vinculada, como conducir una velocidad de animación u oscilar un valor a lo largo del tiempo. Cuando Workspace.AuthorityMode es Enum.AuthorityMode.Server, time() está sincronizado entre el cliente y el servidor y utiliza tiempo de simulación de paso fijo. Durante la re-simulación, retrocede al fotograma autoritativo y avanza a medida que el cliente reproduce fotogramas, por lo que devuelve un valor consistente cada vez que se simula un fotograma.

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 los jugadores
		-- Actualizar el estado del juego
	end)
end

return Simulación

Sincronización de estado con atributos

Roblox sincroniza automáticamente todas las propiedades con acceso a simulación en instancias predichas. Para datos personalizados, los atributos son la forma principal de sincronizar instancias marcadas como predichas; en tales instancias, cualquier discrepancia 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 que un atributo sea replicado, 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 a simulación

Muchas propiedades y métodos en la referencia de la API del motor incluyen la etiqueta de Acceso a 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 con autoridad del servidor, la forma principal en que un cliente puede afectar 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 verificadas 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 tus 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 del personaje cuando se activa una acción de entrada RunAction.

Eventos remotos

Los eventos remotos aún se pueden usar 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 anotan 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 toques en objetos en el mundo 3D.

Animaciones, sonidos y efectos

Los efectos del lado del cliente, como animaciones y sonidos, deben escribirse sabiendo que la simulación del cliente es simplemente una predicción del estado autoritativo del servidor. BindToSimulation() limita qué propiedades y métodos se pueden llamar desde dentro de 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 cómo renderizar 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: