Servidor interno

Servidor y ServidorJuego forman el lado servidor del runtime de Eco. El primero integra el servidor con Unity; el segundo contiene la lógica de juego y gestión de clientes, canales y estado.

Capas

Eco
 │
 └── Servidor
       │
       └── ServidorJuego
             ├── Jugadores
             ├── Canales
             ├── Objetos
             ├── Datos
             ├── Persistencia
             └── Protocolos TCP / UDP

ServidorJuego puede funcionar como servidor local o como núcleo independiente dentro de un proceso servidor.

Flujo de una conexión

Canales y autoridad

El servidor mantiene los canales como unidades lógicas aisladas. Cada canal tiene sus propios jugadores, objetos y datos.

Servidor
├── Canal 100
│   ├── Jugadores
│   ├── Objetos
│   └── Datos
│
└── Canal 200
    ├── Jugadores
    ├── Objetos
    └── Datos

La conexión de un jugador puede participar en varios canales, por lo que el servidor no debe modelar un jugador como perteneciente exclusivamente a una única sala.

Persistencia

El servidor puede guardar estado de canales, objetos persistentes, datos de jugadores y operaciones remotas guardadas. Esto explica por qué Eco no trata la red y la persistencia como dos sistemas completamente separados.

Modo de baja memoria

El material de TNet documenta un modo de bajo consumo de memoria que descarga datos de canales vacíos para reducir el footprint del servidor. En Eco debe considerarse una característica dependiente de la implementación actual del servidor antes de habilitarse en producción.

La idea es:

Último jugador abandona
        ↓
Canal sin participantes
        ↓
Guardar estado
        ↓
Liberar memoria de la representación activa
        ↓
Recargar cuando vuelva un jugador

Servidor local

El servidor interno también puede ejecutarse dentro del mismo proceso de Unity. Esto permite conectar un ClienteJuego contra el servidor local sin depender de sockets externos.

Código fuente