¿Cuáles son algunos enfoques posibles para superar el problema de latencia con juegos renderizados de forma remota?

Pensé en esto por un momento y no estoy seguro de si hay algo que pueda hacer con un cliente simple que pueda reducir la latencia. La latencia es inherentemente un problema de red: combínelo con un cliente tonto cuya potencia de procesamiento es suficiente para simplemente quitar los bits renderizados del cable y mostrarlos, y no hay margen de maniobra para hacer nada inteligente.

Así que creo que algunas restricciones tienen que estar necesariamente relajadas.

Desde el punto de vista del diseño del juego, los tiradores de contracción estilo Quake que requieren latencias súper bajas ya no son tan populares; Para la mayoría de los juegos, es aceptable tener una latencia de menos de 100 ms y un ancho de banda suficiente que se puede lograr ahora con OnLive.

Desde un punto de vista gráfico, si hay una manera de obtener algo de potencia de procesamiento adicional en el cliente (ahora tenemos clientes baratos y la tecnología dice que tendremos mejores en el futuro por precios aún más baratos), puede haber técnicas en las que el El cliente representa una parte de la escena y descarga el resto a la nube. Por ejemplo, el mapeo de relieve de textura es un cálculo costoso, por lo tanto, deje que los servidores en el cielo descubran cómo representar eso y recompongan esa información como información de textura simple en el cliente. Por otra parte, la sincronía de la información gráfica debería ser aún más complicada que nuestras interacciones actuales de usuario cliente-servidor, por lo que no estoy completamente seguro de que valga la pena el esfuerzo.

Esta es una modificación de la sugerencia de Allen y dependería del tipo de juego, pero debería funcionar para algo como un FPS o un juego de carreras.

Almacenamiento en caché de un único cuadro “siguiente” en el cliente que se recibe antes de que se procese la entrada del cliente. El marco es una ‘predicción’ de cuál debería ser la siguiente imagen. Este “siguiente” cuadro podría enviarse desde el servidor como una imagen o enviarse como una instrucción para repetir el cuadro anterior. Si después de procesar la entrada del cliente, el servidor decide que la “siguiente” imagen del cliente es precisa dentro de una tolerancia, se le indica al cliente que muestre el marco. Si está fuera del margen de error, se envía un nuevo marco como el ‘siguiente’ marco y se muestra.

y / o …

Si el cliente tiene alguna capacidad para múltiples capas (es decir, tiene un motor 2D pero no un motor 3D), esta técnica podría extenderse a múltiples capas: fondo, jugadores (o jugador 1, jugador 2, jugador 3), etc. -la capa de fondo podría contener un atributo de posición. Si la imagen “siguiente” actual para esa capa es “lo suficientemente precisa” en 3D, pero no “lo suficientemente precisa” en el espacio de la pantalla, se envían nuevas coordenadas del espacio de la pantalla. Si no es lo suficientemente preciso en 3D, se reemplaza como se indicó anteriormente. Esto tiene un mayor potencial porque cuanto más rápido se mueve un elemento o más pequeño es en el espacio de la pantalla, menos preciso debe ser en 3D. Por ejemplo, un jugador gira 40 grados en la predicción, pero después de procesar la entrada, debe girar 50 grados. Si el reproductor es más pequeño o se mueve más rápido que algún umbral según el espacio de la pantalla y los atributos psicovisuales, la diferencia estaría dentro de la tolerancia y no se volvería a representar en 3D, sino que simplemente se traduciría en el espacio de la pantalla enviando nuevas coordenadas para esa capa al cliente .

Uso de ancho de banda OTOH …