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 se confía en que los clientes solo informen sus propias entradas. Esta arquitectura es la base del netcode central de un juego justo y competitivo, ya que 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 que les devolviera el servidor. Aunque técnicamente correcto, tal sistema enfrentaría una latencia de entrada significativa porque cada acción de un jugador tendría que viajar al servidor, ser procesada y tener el resultado enviado de vuelta al cliente antes de poder ser mostrado. Para la mayoría de los juegos, especialmente aquellos de ritmo rápido, ese retraso de ida y vuelta haría que el juego se sintiera lento, poco receptivo 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 que el servidor responda; en su lugar, predice algunas tramas adelante 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 red y haciendo que el juego se sienta receptivo.

A veces el cliente fallará en su predicción (misprediction) y, debido a la latencia de red, el cliente no sabrá que cometió un error durante unas pocas tramas. Por ejemplo:

Cuando se detecta una mala predicción, el cliente debe corregir su predicción basada en el estado autoritativo del servidor. Si el estado autoritativo es diferente del estado predicho del cliente, el cliente debe retroceder y rescenar sus tramas predichas. Este sistema de predicción del lado del cliente, retroceso y rescena se conoce como "compensación de latencia" y ayuda a que los juegos multijugador autoritativos por servidor se sientan suaves y receptivos.

Configuración

Dado que el modelo de autoridad del servidor requiere ciertas tecnologías del motor para funcionar correctamente, primero debes establecer las siguientes propiedades en el objeto Workspace en el Explorador:

1. Workspace.NextGenerationReplication debe estar habilitado
2. Workspace.PlayerScriptsUseInputActionSystem debe estar habilitado
3. Workspace.SignalBehavior debe ser Deferred
4. Workspace.UseFixedSimulation debe estar habilitado
5. Workspace.StreamingEnabled debe estar habilitado
6. Workspace.AuthorityMode debe ser Server (todos los anteriores deben estar configurados primero)

Conceptos

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

Predicción del cliente

A través de la predicción del cliente, el cliente simula unas cuantas tramas adelante 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 lo suficiente adelante del último estado autoritativo conocido del servidor para que sus entradas lleguen al servidor en la trama destinada. El número de tramas que el cliente predecirá adelante del estado del servidor conocido 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 esa trama. 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 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 del cliente, el cliente debe retroceder y rescenar.

Retroceso y rescena

Cuando un cliente detecta una mala predicción, debe restablecerse al estado autoritativo del servidor y luego rescenar para volver a su trama predicha. Basado en la latencia de red, el cliente intenta simular lo suficiente adelante del último estado autoritativo conocido del servidor para que sus entradas lleguen al servidor en la trama destinada.

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 rescena 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 como propiedad del servidor sin incurrir en el costo de latencia de entrada que normalmente se asocia con la propiedad del servidor. Cosas como coches, personajes de jugador u otros objetos críticos para el 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 fino, 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, tanto el cliente como el servidor deben ejecutar la simulación central, y la simulación del cliente necesita poder retroceder y rescenar 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 rescena, Roblox volverá a ejecutar las funciones vinculadas a la simulación a través de BindToSimulation(). Procesar entradas de jugadores, interactuar con objetos físicos sincronizados y actualizar el estado central del juego debería realizarse dentro de esas funciones vinculadas.

ModuleScript llamado Simulación en ReplicatedStorage:

Simulación
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 forma principal 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 rescena completos.

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 string, su valor contiene como máximo 50 caracteres.

Acceso de simulación

Muchas propiedades y métodos en la API del motor incluyen la etiqueta de 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 se pueden acceder a propiedades y métodos con esta etiqueta dentro de funciones vinculadas con RunService:BindToSimulation().

Acciones de entrada

En un juego autoritativo por 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 rescena en el cliente. Como resultado, InputActions debe ser utilizado para todas las entradas que afecten la simulación central y deben ser verificadas por su validez antes de procesarlas.

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 añadir tus InputContexts a una carpeta bajo ReplicatedStorage y usar un Script bajo ServerScriptService para clonar el InputContexts por jugador:

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

Ten en cuenta que si necesitas escribir datos personalizados en el Sistema de Acción de Entrada, deberías usar una función conectada a RunService.RenderStepped o RunService:BindToRenderStep(), no RunService:BindToSimulation(). Disparar un InputAction en BindToSimulation() puede hacer que los clientes produzcan resultados incorrectos durante una rescena.

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

RunService:BindToRenderStep("EntradaCamara", Enum.RenderPriority.Last.Value, function()
	-- Envía el vector hacia adelante de la cámara del cliente al servidor a través de un InputAction
	local cameraForwardInputAction = Players.LocalPlayer.PlayContext.CameraForward
	local cameraForwardVector = Workspace.CurrentCamera.CFrame.LookVector
	cameraForwardInputAction:Fire(cameraForwardVector)
end)

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 anotan puntos o recogen objetos, y los clientes pueden usar eventos remotos como una API alternativa para enviar entradas al servidor, como para presionar 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 meramente una predicción del estado autoritativo del servidor. BindToSimulation() limita qué propiedades y métodos pueden ser llamados desde dentro de funciones vinculadas para ayudarte a escribir solo en el 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 representar 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: