Conceptos básicos

Los términos que el resto de estas páginas usa sin explicarlos. Cada uno trae una definición breve y un enlace a la página donde vive el mecanismo que hay detrás.

Tres temas son demasiado amplios para una entrada y tienen su propia página: Quién toma las decisiones — quién hace la llamada y qué decide eso por sí solo; Cómo está construido el SDK — de qué está hecho el SDK; Herencia y composición — cómo se construyen los módulos unos sobre otros.

Las cuatro formas de trabajar con un módulo

Cada módulo expone exactamente cuatro cosas, y cada página de módulo se organiza en torno a ellas. Este es el modelo de programación:

Forma	Qué significa
Declaraciones	qué existe y cómo se comporta. Se escriben en código o en el panel de administración, y el modelo es el mismo en ambos casos
Hooks	tus reglas, que la plataforma llama en pasos con nombre. Se despliegan como funciones en la nube
Eventos	lo que la plataforma te avisa que ya ocurrió: te suscribes en lugar de consultar periódicamente
Operaciones	lo que pides u ordenas, desde una función o desde un cliente

Actor

Quién hace la llamada. Lo que una llamada puede hacer lo decide el actor que está detrás de ella, nunca la compilación en la que quedó el código. El argumento está en Quién toma las decisiones; el mecanismo (permisos atómicos, roles compuestos, InterfaceGrant), en Access & Roles.

Los nombres de actores que usan estas páginas vienen de los presets que incluye la plataforma. Un proyecto puede nombrar a sus propios actores; los presets son:

player · backend-service · operator · host · moderator · schema-author · architect · bot-brain · room-owner · room-visitor · entry-validator · spectator · match-organizer · warehouse-keeper · seller — y any cuando una página se refiere a todos ellos.

Lugar de ejecución

Dónde se ejecuta el código. Todas las tablas de operaciones usan estas cuatro etiquetas:

Etiqueta	Lugar de ejecución
`fn`	Función en la nube (C# · TypeScript · Python · Go). La autoridad está en el servidor, y aquí viven principalmente tus reglas
`cl`	Cliente del juego (Unreal C++ / Unity C#). La API es simétrica, pero los roles desbloquean menos
`mc`	El lugar de ejecución del host de la sala (room): un cliente maestro (un cliente que es dueño de una sala) o un servidor dedicado de Unreal con su clave de host (host key)
`adm`	Panel de administración / CLI / MCP: aquí el SDK y el plano de operador (operator plane) comparten un modelo

Dónde se ejecuta el código no dice en nombre de quién actúa

Dónde se ejecuta el código y qué interfaz de actor tiene son preguntas distintas. El mismo código tiene los mismos derechos dondequiera que lo pongas; lo único que cambia son los permisos otorgados (grant).

Proyecto y entorno

Un proyecto es el backend de un juego, con un esquema y sus datos en entornos aislados (dev, prod). Cada llamada se ejecuta dentro de un proyecto y un entorno.

Entidad

Es el concepto central. Una entidad es una declaración del esquema más sus aspectos vivos: datos 0..*, estados 0..*, RPC 0..*, eventos 0..*, hooks e historial de cambios. Un tanque, una puerta, una barra de estadística y una misión son entidades por igual, y solo se diferencian en los aspectos que llevan. Las combinaciones más comunes vienen como presets (GameObject, Stat, Character, Interactable, Projectile). Consulta Entity.

Estado esperado

Una solicitud de transición puede nombrar el estado que espera, y entonces el resultado es ese estado o un rechazo. Una solicitud que no nombra ninguno se evalúa contra el estado que tiene la máquina cuando la plataforma la procesa, nunca contra el estado del momento en que se envió.

La respuesta describe ese momento y no promete nada sobre lo que venga después: si la transición de alguien más llega mientras la respuesta va en camino, la respuesta sigue siendo cierta y no se anula.

Nombra el estado esperado cuando importe

Cuando el resultado depende de lo que había antes, nombra el estado esperado. Si no lo haces, no leas la respuesta como un snapshot que sigue valiendo después de la llamada.

Sala

Una sala es una sesión de juego, no un lugar donde se ejecuta tu código. A la plataforma no le importa qué la aloja: un servidor dedicado, un cliente maestro o el propio backend. El funcionamiento interno de la sala es cosa nuestra; tú la manejas desde afuera, desde funciones en la nube y clientes, con declaraciones, hooks, eventos y operaciones. Consulta Rooms.

Canal y flujo

Son las primitivas asíncronas que están debajo de todo. Un canal es un tema pub/sub direccionable: una sala, un grupo, una entidad o uno propio. Un flujo (stream) transmite datos por fragmentos en cualquier dirección: los archivos se consumen a medida que llegan los fragmentos, las consultas pueden devolver un flujo y una RPC puede enviarse a todo un grupo y reunir las respuestas. Consulta Core.

Primitiva

Una de las cuatro piezas con las que se arma cada módulo: eventos (declarar, emitir, suscribirse), RPC (invocar a través de la red), datos y suscripciones (la mecánica de sincronización) y grupos (una lista, muchos oyentes). Una sala, un chat y un pool de emparejamiento (matchmaking) son la misma primitiva de grupo con reglas distintas.

Contrato de hooks

Hay un solo contrato en todas partes. Un hook before se ejecuta antes de la validación, recibe el payload tipado y puede modificarlo o rechazarlo. Un hook after se ejecuta cuando la operación ya se confirmó, recibe la solicitud y el resultado, y solo puede agregar efectos secundarios: nunca puede hacer que la operación falle. Los hooks se ejecutan en orden, y cualquier paso registrado de la plataforma puede tenerlos. Consulta Extensibility.

Delta y revisión

Los clientes reciben el estado como deltas: solo los campos que cambiaron, codificados respecto del último estado del que el receptor acusó recibo. Cada registro lleva una revisión, y una escritura condicional se rechaza si la revisión no coincide. Un único concepto de versionado sirve para la sincronización, la concurrencia y el historial. Consulta Data & Subscriptions. (Lo que Unreal llama replicación — qué cliente ve qué estado y con qué frecuencia — vive aquí, en Visibility y en Prediction & Lag Comp. La página Qué sobrevive a la pérdida de un host trata de lo otro: qué máquina es dueña de una entidad y cuál lo será después.)

Tick

Las salas simulan con un paso fijo. Cada cambio de estado lleva la marca de su tick; la sincronización, la predicción, la compensación de lag y el historial cuentan en ticks, no en tiempo de reloj. Los datos conservan el momento real del evento, y eso hace que el rebobinado y la reconciliación sean exactos. Consulta Prediction & Lag Comp.