Crear el comportamiento remoto

El comportamiento de red vive normalmente en un Componente asociado a un Objeto.

public class Unidad : Componente
{
    public void Atacar()
    {
        ero.Send("Atacar", Objetivo.Otros);
    }
}

Componente proporciona acceso al Objeto mediante ero, por lo que el código de gameplay no necesita construir manualmente el Paquete.

Enviar la acción

El envío se realiza con Send, indicando el nombre de la función y el objetivo de la comunicación.

ero.Send("Atacar", Objetivo.Otros);

Cuando la acción necesita argumentos, estos forman parte de la llamada:

ero.Send("RecibirDaño", Objetivo.Otros, 25);

La serialización de esos argumentos termina formando parte del Buffer asociado al paquete de protocolo.

Elegir destinatarios

El objetivo determina quién debe recibir la operación. No debe asumirse que una RFC siempre significa «todos».

La elección debe responder a la semántica de la acción:

El conjunto exacto de objetivos disponibles debe consultarse en la API de Eco, ya que los nombres y combinaciones forman parte de su implementación actual.

No mezclar acción y estado

Un error habitual es utilizar RFC para representar continuamente un valor que realmente es estado.

Evita un flujo como:

CambiarVida(100)
CambiarVida(99)
CambiarVida(98)
CambiarVida(97)
...

cuando el verdadero modelo es:

Objeto
└── vida = 97

En ese caso, Set y la sincronización de estado son más apropiados.

Por el contrario, una acción como:

Atacar()
AbrirPuerta()
RecogerObjeto()

representa un evento que debe ejecutarse y no necesariamente mantenerse como estado actual.

Autoridad

Enviar una RFC no elimina la necesidad de definir autoridad.

Por ejemplo, si un cliente solicita:

ero.Send("RecibirDaño", Objetivo.Propietario, 25);

la arquitectura debe determinar quién puede realizar la acción y quién conserva la verdad del estado resultante.

Una arquitectura habitual es:

Cliente atacante
      │
      │ Solicitud
      ▼
Servidor / propietario
      │
      │ valida y aplica
      ▼
Estado actualizado
      │
      └── sincronización a participantes

La RFC transporta la intención. La autoridad determina si la intención debe modificar el estado.

Acciones y múltiples canales

Una RFC está asociada al contexto del objeto y, por extensión, a su canal.

Canal 10
└── Objeto 100
     └── Atacar()

Canal 20
└── Objeto 100
     └── Atacar()

Que dos objetos tengan el mismo identificador numérico no significa que una RFC enviada en un canal deba ejecutarse en el otro.

Antes de enviar una acción, asegúrate de que el objeto pertenece al canal correcto y que el cliente está correctamente integrado en ese canal.

Persistencia

Eco también contempla RFC persistentes. En ese caso, la llamada no debe interpretarse simplemente como un mensaje efímero: puede formar parte del estado almacenado del canal u objeto y utilizarse posteriormente para reconstruir el estado de participantes que entren más tarde.

Utiliza una RFC persistente cuando el hecho de haber ejecutado o registrado la operación forme parte del estado que debe conservarse.

No utilices persistencia sólo porque necesites fiabilidad inmediata; son conceptos distintos.

Cuándo usar cada mecanismo

¿Estoy comunicando una acción?
        │
       sí
        ↓
       RFC

¿Estoy comunicando el estado actual de un dato?
        │
       sí
        ↓
   Set / sincronización

¿Necesito conservarlo para futuros participantes?
        │
       sí
        ↓
Estado persistente / RFC persistente