Definir el componente

Crea un Componente que represente el comportamiento de la entidad.

public class Unidad : Componente
{
    public void CambiarVida(int valor)
    {
        Set("vida", valor);
    }
}

El Componente utiliza su Objeto asociado para acceder al estado de red.

Escribir el estado

El estado puede escribirse mediante Set:

Set("vida", 100);
Set("nivel", 5);

También puedes utilizar rutas jerárquicas cuando el estado tenga más estructura:

Set("estadisticas/vida", 100);
Set("estadisticas/defensa", 25);

El valor se actualiza localmente antes de que Eco determine cómo debe propagarse.

Leer el estado

Cualquier participante que disponga del objeto puede consultar los datos mediante Get:

int vida = Get<int>("vida");
int nivel = Get<int>("nivel");

La lectura no implica comunicación con el servidor: consulta el estado local conocido por ese objeto.

Entender la autoridad

El punto más importante es decidir quién puede producir el estado.

                 Objeto
                    │
              propietario
                    │
          ┌─────────┴─────────┐
          │                   │
        Propietario        Otros clientes
          │                   │
       produce             consumen
        estado               estado

Cuando el cliente local es propietario, Eco puede distribuir el cambio y actualizar el estado persistente cuando corresponde.

Cuando el cliente no es propietario, un cambio puede requerir una solicitud al propietario en lugar de modificar unilateralmente la autoridad remota.

Sincronizar un estado sencillo

Para una propiedad discreta, el flujo normal puede ser tan simple como:

public void RecibirDaño(int daño)
{
    int vida = Get<int>("vida");
    Set("vida", Mathf.Max(0, vida - daño));
}

Aquí vida es estado. No hace falta convertir cada valor en una llamada remota diferente como CambiarVida(99), CambiarVida(98), etc.

¿Qué ocurre si todavía no se puede enviar?

Durante determinadas fases de conexión o entrada a canales, el objeto puede existir localmente pero todavía no estar listo para transmitir.

En ese caso, Eco puede mantener los cambios pendientes y procesarlos cuando PuedeEnviar vuelva a ser verdadero.

Set()
  ↓
actualización local
  ↓
¿Puede enviar?
 ├── Sí → sincronizar
 └── No → mantener pendiente
              ↓
        objeto preparado
              ↓
          sincronizar

Esto evita que el gameplay tenga que conocer todos los estados transitorios de la conexión.

Sincronización automática

Cuando una propiedad de Unity debe sincronizarse periódicamente, AutoSincronizar puede evitar tener que escribir manualmente el código de comparación y envío.

Es especialmente útil durante prototipos o para componentes sencillos.

Transform / campo
       ↓
AutoSincronizar
       ↓
cambio detectado
       ↓
Send / SendQuickly

AutoSincronizar comprueba valores mediante reflexión y puede limitar la frecuencia de actualización con updatesPerSecond.

Elegir el mecanismo correcto

Una regla útil es distinguir estado de acción.

"Mi vida es 80"   → estado
"He atacado"      → acción

El primero suele ser candidato a sincronización; el segundo suele expresarse mediante una comunicación de evento o RFC.

Ejemplo completo

public class Unidad : Componente
{
    protected override void Start()
    {
        base.Start();

        if (isMine && !Has("vida"))
            Set("vida", 100);
    }

    public void RecibirDaño(int daño)
    {
        if (!isMine) return;

        int vida = Get<int>("vida");
        Set("vida", Mathf.Max(0, vida - daño));
    }

    public int ObtenerVida()
    {
        return Get<int>("vida");
    }
}

La idea importante del ejemplo no es la clase concreta, sino el reparto de responsabilidades:

Unity / gameplay
      ↓
Componente
      ↓
Objeto
      ↓
Estado + propietario
      ↓
Eco