Crear una partida
Flujo completo para conectar jugadores, crear un canal y preparar el estado inicial de una partida.
Crear una partida
Una partida en Eco puede entenderse como la combinación de una conexión de red, un canal y el estado de juego que vive dentro de ese canal.
Conexión
↓
Canal
↓
Nivel / escena
↓
Objetos de red
↓
Estado sincronizadoConectar el cliente
El cliente necesita establecer primero una conexión con el servidor.
ClienteJuego cliente = ...;
cliente.Connect(endpoint);Antes de intentar entrar en la partida conviene esperar a que isConnected sea verdadero.
Crear o seleccionar el canal
El servidor es quien mantiene el estado del canal. El cliente solicita entrar mediante JoinChannel.
cliente.JoinChannel(
channelID: 10,
levelName: "Arena",
persistent: false,
playerLimit: 4,
password: ""
);La unión no es instantánea. Eco mantiene la solicitud como pendiente hasta recibir la respuesta del servidor.
El canal es el ámbito de la partida
Los jugadores, objetos dinámicos y estado asociado a la partida deben entenderse dentro del contexto del canal. La conexión puede permanecer activa mientras el cliente cambia de un canal a otro o participa en varios simultáneamente.
Esperar la entrada al canal
No es recomendable empezar a crear lógica de partida inmediatamente después de llamar a JoinChannel. Primero debe completarse la unión y, cuando corresponda, la carga del nivel asociado.
JoinChannel()
↓
Solicitud pendiente
↓
Respuesta del servidor
↓
Canal activo
↓
Nivel preparadoDurante esta transición Eco protege el flujo de paquetes para evitar que operaciones pertenecientes a una escena anterior sean procesadas fuera de contexto.
Crear el estado de la partida
Una vez dentro del canal se pueden crear los objetos dinámicos que representan el estado de la partida.
Por ejemplo:
Canal
├── Jugadores
├── Objetos de la partida
│ ├── Objetivo
│ ├── Unidad
│ └── Estado de partida
└── Datos persistentesLos objetos deben tener un propietario claro cuando su estado vaya a ser modificado por un cliente.
Sincronizar el estado inicial
El estado que necesitan los demás jugadores debe modelarse como datos de red, no como una sucesión de acciones.
objeto.Set("fase", "Preparacion");
objeto.Set("tiempo", 30);Si el estado debe actualizarse de forma continua puede utilizarse un sistema de sincronización apropiado. Para prototipos sencillos, AutoSincronizar puede servir como punto de partida.
Enviar acciones de juego
Las acciones puntuales de la partida deben utilizar el sistema de comunicación correspondiente.
Estado
→ Set / sincronización
Acción
→ RFCPor ejemplo, cambiar la vida actual de una unidad representa un cambio de estado, mientras que solicitar que una unidad ejecute una habilidad representa una acción.
Un segundo jugador entra
La partida debe poder reconstruirse desde el estado del canal y de sus objetos.
Jugador A
│
└── crea estado
↓
Canal
↓
Jugador B entra
↓
estado inicial sincronizadoDependiendo de cómo se configure el objeto o componente, el estado puede conservarse en servidor o ser enviado explícitamente al nuevo participante.
Finalizar la partida
Al terminar una partida pueden utilizarse distintos niveles de limpieza:
Salir del canal
↓
conservar conexión
Desconectar
↓
finalizar sesión completa
Eliminar canal
↓
eliminar el ámbito de partidaLa elección depende de si el cliente debe continuar conectado a otros canales o sesiones.
Flujo completo
Cliente conecta
↓
Servidor acepta
↓
JoinChannel
↓
Canal activo
↓
Carga de nivel
↓
Creación de objetos
↓
Sincronización del estado inicial
↓
Juego
├── acciones → RFC
└── estado → sincronización
↓
Fin de partida
↓
LeaveChannel / DeleteChannelErrores habituales
Crear objetos antes de completar la unión
Puede producir objetos locales que todavía no están correctamente registrados en el contexto de red de la partida.
Utilizar RFC para representar todo el estado
Las RFC son adecuadas para acciones. El estado debe modelarse como estado para que un jugador que entre posteriormente pueda obtener los valores actuales.
Confundir desconexión con salida del canal
Salir de un canal no obliga a desconectar al cliente. Eco permite mantener la conexión y continuar en otros canales.
No definir la autoridad
Si varios clientes pueden modificar el mismo dato sin una autoridad clara, el estado puede entrar en conflicto. Define el propietario antes de diseñar la sincronización.
Véase también
Canales
Ciclo de vida y gestión de los canales.
Objetos
Identidad, propiedad y ciclo de vida de los objetos de red.
Sincronización
Cómo mantener el estado coherente entre participantes.
Comunicación
RFC, destinatarios y comunicación de alto nivel.