<aside>

Objetivo: Este bloque persigue que el alumnado comprenda qué son las Networked Properties en Photon Fusion 2, cómo se definen, qué papel cumplen dentro del estado replicado de un objeto de red y de qué manera puede reaccionarse a sus cambios sin mezclar lógica autoritativa con presentación visual.

Su importancia dentro de la práctica es especialmente alta, porque muchas de las mecánicas exigidas por el enunciado dependen de un estado persistente y consistente entre clientes, por ejemplo:

Además, el enunciado exige distinguir con claridad entre estado persistente y eventos temporales, por lo que entender bien las Networked Properties resulta imprescindible para no convertir eventos efímeros en datos permanentes ni intentar replicar gameplay con mecanismos incorrectos.

</aside>


1.- Conceptos clave

Photon Fusion utiliza Networked Properties para representar estado replicado dentro de un NetworkBehaviour. Photon documenta que estas propiedades forman parte del estado de red del objeto y que deben declararse como auto-properties con el atributo [Networked]. También indica que solo el peer con autoridad de estado debe modificar ese estado.

En otras palabras, una Networked Property no es una variable cualquiera. Es un dato que Fusion incorpora al snapshot de red del objeto y que, por tanto, debe tratarse como parte del estado real de la simulación.

Aplicado a las Networked Properties, la decisión concreta ante cada dato del proyecto es:

Esta clasificación tiene consecuencias directas en el diseño, porque cada propiedad [Networked] consume espacio en el snapshot de red del objeto y se transmite de forma continua mientras el objeto exista en la sesión.


2.- Implementación recomendada

2.1.- Qué tipo de información debe ir en una Networked Property

Conviene usar Networked Properties para todo aquello que forme parte del estado estable o relevante de una entidad de red y que deba ser coherente para todos los clientes.

En el contexto de esta práctica, ejemplos razonables serían: