<aside>
Objetivo: Este bloque tiene como propósito que el alumnado sea capaz de justificar y aplicar una arquitectura base clara para el proyecto, separando la infraestructura persistente de las escenas funcionales para evitar que se mezclen conexión, sesión, gameplay y reglas de juego.
Su relevancia dentro del enunciado es directa, ya que la práctica exige un flujo completo y funcional con menú inicial, conexión a red, lobby y salas, inicio de partida, partida multijugador y fin de partida con retorno. Además, dicho flujo debe poder probarse con dos clientes conectados desde redes distintas.
</aside>
Una arquitectura de red no se reduce a conseguir que dos clientes entren en una misma sesión. En un proyecto multijugador, la estructura del cliente condiciona cómo se organiza el estado persistente, dónde vive la conexión, cómo se conserva la sesión entre escenas y de qué forma se evita que el proyecto se vuelva caótico a medida que se añaden sistemas.
Para esta práctica, conviene separar el proyecto en tres niveles funcionales:
Este reparto simplifica el flujo sin perder claridad. La sala deja de ser una fase intermedia separada y pasa a ser directamente el espacio donde los jugadores conectan, aparecen y juegan. Aun así, sigue siendo importante distinguir entre infraestructura persistente y lógica específica de la sesión.
También conviene fijar desde esta fase el papel del NetworkRunner. El Runner es la pieza central del peer local dentro de Fusion y es el componente encargado de crear o unirse a una sesión, mantenerla activa y sostener la simulación de red.
La arquitectura base del proyecto puede entenderse como una separación entre infraestructura persistente y escenas funcionales.
DDOL debe contener los sistemas que no conviene recrear cada vez que cambia la escena. En este proyecto, su papel principal es mantener viva la infraestructura necesaria para que el flujo de red no dependa de una escena concreta.
En términos prácticos, DDOL es el lugar natural para alojar elementos como: