Hasta ahora la arquitectura de red que me he planteado es muy simple, una arquitectura cliente-servidor utilizando la librería de red ENet (parte del motor libre "Cube" y "Cube 2") pudiendo verse en marcha en el videojuego Sauerbraten.
Mi decisión principal ha sido separar el motor de físicas al lado del servidor lo cual me evita el engorro de sincronizar el motor de física de todos los clientes, para pasar a sincronizar unicamente las posiciones/orientaciones calculadas por el servidor.
Pero hagamos unos calculos para comprobar la viabilidad del sistema. Vamos a centrarnos en la subida del servidor que es donde se centra el cuello de botella del tráfico del juego.
Supongamos una conexión normal/baja de hoy día que soporte 512Kbps de subida. A este servidor se conectarán hasta digamos 16 personas.
512 Kbps * 1024 / 8 = 65.536 Bytes por segundo.
65.536 Bps / 16 clientes = 4096 Bps / persona
Tenemos 4KB de información para enviar a cada cliente por segundo, en esos 4KB debemos incluir toda la información de los demás clientes y la suya incluida, y deberemos mandar un número constante de reportes cada segundo, digamos 30.
4096 Bps / 16 clientes / 30 reportes = 8,5 Bps en cada paquete de datos.
Una posición x,y,z son 3 float y una orientación puede medirse como mínimo con 3 variables (la direccion de la normal), con lo cual minimo en esos reportes necesitamos enviar 6 float, que como minimo pueden ocupar 2 bytes cada uno. 6 float * 2 Bytes = 12 Bytes necesarios como mínimo.
Mi conclusión es o que en algo me estoy equivocando en los cálculos o sincronizar los clientes a tiempo real cada frame no es la solución.
De momento solo se me ocurre que en vez de sincronizar continuamente la posición/orientación etc, solo se sincronicen eventos entre los clientes, pero eso implica que las físicas esten en todos los clientes y sean deterministas, para que no se ejecuten diferente en ningún cliente.
0 comentarios:
Publicar un comentario