Sincronización
Cómo Eco mantiene el estado de objetos y propiedades coherente entre participantes.
Sincronización
La sincronización responde a una pregunta distinta de una RFC: ¿cómo hago que todos conozcan el estado actual de una entidad?
Acción vs estado
Una RFC representa normalmente un evento puntual. Un dato sincronizado representa el estado actual y puede necesitar volver a enviarse o reconstruirse para un jugador que entra más tarde.
Modelo de datos
Objeto
└── Nodo
├── vida
├── posición
├── inventario
└── estadoLas operaciones principales son Get y Set.
objeto.Set("vida", 100);
int vida = objeto.Get<int>("vida");Qué ocurre al llamar a Set
Estado local [step]
Eco actualiza primero el Nodo local. Esto permite que el código que acaba de cambiar el dato lo vea inmediatamente.
Comprobación de capacidad [step]
Se comprueba que el objeto tenga identidad válida, pertenezca a un contexto enviable y no esté atravesando una transición donde la transmisión todavía no sea posible.
Comprobación de autoridad [step]
Si el llamador es propietario, puede distribuir el cambio. Si no lo es, la operación se dirige al propietario para que siga el flujo de autoridad.
Propagación [step]
El cambio se comunica a los destinatarios y el estado puede actualizarse también en la representación persistente del servidor.
Cola temporal [step]
Si el objeto no puede enviar todavía, el cambio puede quedar pendiente hasta que la transmisión vuelva a estar disponible.
Autoridad
Cliente A
│
│ Set("vida", 80)
▼
¿A es propietario?
│
├── Sí ──► distribuir + actualizar estado persistente
│
└── No ─► solicitar al propietarioEsto evita que varios clientes actúen como fuente de verdad simultánea para una propiedad.
Qué sincronizar
Vida, inventario, reglas de partida y cualquier valor cuyo estado actual deba ser consistente. Prioriza claridad y autoridad sobre frecuencia extrema.
Transformaciones o valores que cambian muchas veces por segundo pueden usar mecanismos rápidos si perder estados intermedios es aceptable.
Datos necesarios para reconstruir un objeto cuando aparece o cuando entra un jugador nuevo deben formar parte de un estado que pueda recuperarse.
AutoSincronizar
AutoSincronizar automatiza parte de este trabajo para campos y propiedades de componentes de Unity. Su configuración incluye conceptos como frecuencia, persistencia y autoridad del propietario.
AutoSincronizar
├── entries
├── updatesPerSecond
├── isSavedOnServer
├── isImportant
└── onlyOwnerCanSyncConveniencia, no arquitectura
AutoSincronizar es útil para prototipos y propiedades sencillas. En sistemas de producción conviene controlar explícitamente qué datos viajan, quién los modifica y con qué frecuencia.
Frecuencia
Si una propiedad cambia a alta frecuencia, transmitir todos sus valores puede generar tráfico innecesario.
100 cambios locales / s
│
├── enviar todos ───────► tráfico alto
│
└── muestrear / agrupar ─► tráfico controladoupdatesPerSecond establece una frecuencia máxima para el sistema automático.
Persistencia
La sincronización de estado y la persistencia no son lo mismo:
| Concepto | Pregunta |
|---|---|
| Sincronización | ¿Quién necesita conocer el estado ahora? |
| Persistencia | ¿Debe poder reconstruirse el estado después? |
| RFC guardada | ¿Debe reproducirse una operación al reconstruir? |
Consulta Persistencia cuando el objetivo sea sobrevivir a la ausencia de jugadores.
Errores habituales
No conviertas el estado en eventos
Si una unidad tiene vida = 74, no necesitas una RFC por cada cambio si lo único importante es que los clientes conozcan el valor actual. Sincroniza el estado.
No sincronices cada frame por defecto
La frecuencia debe depender de la percepción del jugador y de la necesidad real del sistema, no del Update() de Unity.
Relación con TNet
El modelo procede conceptualmente de TNObject.Set/Get y TNAutoSync, pero los nombres y el comportamiento deben comprobarse en la implementación de Eco.