Requisitos y limitaciones
Compatibilidad, dependencias, restricciones y condiciones que afectan a una integración de Eco.
Requisitos y limitaciones
Esta página define las condiciones que debes comprobar antes de construir gameplay dependiente de Eco. La implementación del repositorio Nervelink/eco es la fuente de verdad cuando exista una diferencia con ejemplos antiguos de TNet.
No asumas compatibilidad por herencia
Que TNet documente una API no significa que Eco la exponga con el mismo nombre, ciclo de vida o restricciones.
Matriz de integración
Requiere la parte cliente de Eco, sus dependencias de Unity y acceso a la fachada Eco/ClienteJuego que utilice tu proyecto.
Requiere ServidorJuego, configuración de persistencia y los transportes habilitados por la build objetivo.
Puede combinar cliente y servidor dentro del mismo proceso para pruebas sin sockets.
Componentes del entorno
Unity
├── Código de Eco
├── Runtime cliente
├── Runtime servidor (si aplica)
└── Configuración de transporteLa ruta principal del código de red en el repositorio es:
src/Assets/Pandora/Logica/Nucleo/Core/RedTransporte
Es el transporte principal del cliente y proporciona el camino fiable de conexión y protocolo.
Es opcional y está pensado para determinados paquetes frecuentes o sensibles a latencia. Su uso depende de la plataforma y de la configuración compilada.
Limitaciones del modelo
Canales
Son ámbitos lógicos, no conexiones físicas. Un cliente puede participar en varios simultáneamente.
Ownership
La visibilidad de un objeto no otorga autoridad para modificarlo.
Transiciones
Entrada a canales y cambios de nivel pueden dejar operaciones temporalmente pendientes.
Servidor local
El modo sin sockets no reproduce todas las condiciones de una conexión real entre procesos.
Rendimiento
La red no debe modelarse como una extensión directa de Update().
Update de Unity
│
├── ¿Cambió el dato?
│ │
│ └── no → no transmitir
│
└── sí
│
├── ¿Necesita sincronización?
├── ¿Con qué frecuencia?
├── ¿Quién tiene autoridad?
└── ¿Debe persistir?Los sistemas automáticos que utilizan reflexión, como AutoSincronizar, son convenientes pero deben evaluarse con el perfil real de la aplicación.
Seguridad y autoridad
Eco proporciona infraestructura de comunicación, no reglas de confianza de tu juego.
El servidor sigue siendo la autoridad crítica
No aceptes directamente desde el cliente valores que puedan decidir resultados importantes sin validación. Una RFC correctamente deserializada puede seguir siendo una petición inválida para tu juego.
Escenas y canales
El estado de red y el estado de Unity no son intercambiables. Una escena puede cambiar mientras un canal conserva identidad y estado lógico.
Por eso los flujos de cambio de nivel y transferencia de objetos deben tratarse como operaciones de red coordinadas.
Qué debe considerarse estable
| Parte | Recomendación |
|---|---|
| API de alto nivel de Eco | Utilízala como contrato de gameplay |
| Implementación interna | Puede evolucionar sin aviso de API estable |
| TNet upstream | Referencia histórica/comparativa |
| Ejemplos antiguos | No utilizarlos como fuente normativa |
| DeepWiki | Útil para explorar, pero verificar contra el código |
Checklist
Compatibilidad
Comprueba la versión de Unity y la build objetivo del proyecto que integra Eco.
Dependencias
Verifica que cliente, servidor y paquetes de transporte requeridos estén presentes.
Autoridad
Define quién puede modificar cada estado antes de diseñar las RFC y sincronizaciones.
Persistencia
Decide qué estado debe sobrevivir a la salida de todos los jugadores.
Transporte
Elige TCP o UDP según las garantías que realmente necesite la operación.
Fuente de verdad
Cuando exista una contradicción entre documentación, TNet antiguo y Eco:
Código actual de Eco
↑
Implementación real
↑
Documentación de Eco
↑
TNet / DeepWiki como referencia