<aside>

Objetivo: Este bloque pretende que el alumnado comprenda por qué el cambio de Master Client no debe romper la continuidad de la partida y qué decisiones de arquitectura permiten que el estado global siga existiendo y pueda seguir siendo gestionado por un nuevo referente de autoridad.

No se trata aquí de una migración manual de datos entre clientes, sino de una idea mucho más importante: si el Master Client valida las reglas globales, eso no significa que el estado global de la partida deba existir solo en su memoria local.

</aside>

1.- Conceptos clave

Dentro de esta práctica, el Master Client actúa como referencia de autoridad para reglas globales del sistema. Eso significa que puede ser el responsable de validar acciones que afectan al conjunto de la partida, por ejemplo:

• Eliminaciones
• Score
• Rachas
• Entidades compartidas
• Estado general del combate

Pero aquí hay una diferencia fundamental que conviene dejar muy clara:

• Una cosa es tener autoridad para modificar el estado
• Otra muy distinta es ser el único lugar donde ese estado existe

Si el Master Client es el único que “posee” el estado global en variables locales, cuando abandona la sesión la partida pierde su contexto real.

Si, por el contrario, el estado global vive en objetos de red persistentes de la sesión, entonces el nuevo Master no necesita reconstruir la partida desde cero. Solo necesita continuar gestionando el mismo estado compartido que ya existía.

Esa es la idea importante de este bloque:

el Master Client no debe ser el único propietario real de la persistencia del combate; debe ser el referente que tiene autoridad para modificar un estado global que ya pertenece a la propia sesión.

2.- Implementación recomendada

2.1.- Qué no puede depender solo del Master local

Si un dato forma parte real de la partida, no puede existir únicamente en la memoria local del cliente que en ese momento actúa como Master.