Tres topologías: local, host-and-play y servidor dedicado¶

La arquitectura contempla los tres modos. Buscamos reutilizar la lógica autoritativa sin que un juego local cargue artificialmente con red, sockets o serialización innecesaria.

Single-player con servidor interno lógico¶

El proceso puede incluir cliente, render, UI y simulación autoritativa. El «servidor» es una responsabilidad, no un proceso separado. Las intenciones pueden circular mediante métodos directos o colas en memoria.

flowchart TB
  subgraph ProcesoLocal["Un proceso"]
    C["Cliente / presentación"] --> A["Autoridad local"]
    A --> W[("Mundo")]
    W --> C
  end

Host-and-play o listen server¶

El anfitrión ejecuta autoridad y su cliente local. Los clientes externos envían intenciones al mismo anfitrión. Evitá que el host posea permisos adicionales solo por dibujar localmente: las reglas deben pasar por la autoridad.

flowchart TB
  HC["Cliente del anfitrión"] <--> HS["Host autoritativo"]
  RC["Clientes remotos"] <--> HS
  HS <--> W[("Mundo")]

Servidor dedicado¶

La simulación corre en un proceso headless. Los clientes mantienen representación, entradas, predicción opcional y réplicas del estado relevante.

flowchart TB
  C1["Cliente A"] <--> DS["Servidor dedicado"]
  C2["Cliente B"] <--> DS
  DS <--> W[("Mundo autoritativo")]

Qué conviene mantener común¶

La semántica de intenciones, la validación, las reglas de gameplay y el ciclo de simulación. Qué puede variar: transporte, serialización, autenticación, frecuencia de replicación, tolerancia a latencia y políticas de reconstrucción.

Cliente-servidor no significa que todos los juegos deban replicar cada componente. Enviar el estado del mundo completo cada tick casi nunca es sostenible. Elegí relevancia, frecuencia y granularidad según el género.

Opcionales de red¶

Predicción y reconciliación mejoran acciones inmediatas; interpolación suaviza entidades remotas; rollback puede ser adecuado para ciertos juegos de pelea o simulaciones reproducibles; los servidores persistentes requieren reconexión y recuperación. Cada opción debe medirse y probarse.

Pruebas de arquitectura¶

Una misma operación de inventario o combate debería producir consecuencias semánticas equivalentes en las tres topologías. El servidor dedicado debe funcionar sin renderer; el cliente remoto no puede modificar arbitrariamente salud, recursos o posición.

Relacionado: Autoridad: quién puede cambiar el mundo, Núcleo de simulación y scheduler, Intenciones, acciones y eventos, Guardado, versionado y replay, Probar la simulación y medir antes de optimizar.

Fuentes: Unreal Networking Overview, Dedicated Servers, Godot High-level multiplayer.