<aside>
Objetivo: Este bloque pretende que el alumnado comprenda cómo entra y sale un objeto de la simulación de red en Photon Fusion 2, qué callbacks deben emplearse para inicialización, simulación, presentación y cierre, y por qué esos métodos de NetworkBehaviour sustituyen a los equivalentes habituales de Unity dentro de un juego multijugador.
</aside>
En Fusion, un objeto compartido no debe tratarse como un GameObject local normal. Si el objeto forma parte de la sesión, necesita un ciclo de vida de red propio: entra mediante Spawn, vive dentro de la simulación del Runner y sale mediante Despawn. Ese ciclo no debe mezclarse con la lógica habitual de Instantiate() y Destroy() como si el objeto solo existiera en un cliente.
Además, NetworkBehaviour introduce callbacks específicos que sustituyen a varios métodos clásicos de Unity cuando se trabaja con objetos de red:
Spawned() sustituye el papel de Start()Despawned(NetworkRunner runner, bool hasState) sustituye el papel de OnDestroy()FixedUpdateNetwork() sustituye el papel de FixedUpdate()Render() sustituye el papel de Update() para la parte visual ligada a la simulación de redLa razón es sencilla: en un juego de red no basta con “tener un frame local”. Hace falta distinguir entre:
RunnerSpawn y Spawned()Runner.Spawn(...) es el mecanismo correcto para introducir un objeto en la simulación compartida. Un objeto generado así recibe identidad de red y pasa a existir para la sesión. Una vez adjunto al Runner, Fusion invoca Spawned(), y a partir de ese momento el objeto ya puede utilizar con seguridad sus propiedades de red y sus RPCs. De hecho, Photon indica expresamente que las Networked Properties no deben accederse antes de que Spawned() haya sido llamado.
Por eso, dentro de esta práctica, Spawned() es el lugar lógico para: