Microsoft presenta DeLorean, un sistema predictivo que reduce el lag de los juegos en streaming

rudedude escribió:No entiendo como funciona esto, en teoría predice tus posibles movimientos y los recibes más rápido que si no hiciera ese cálculo, pero si hay lag tu puedes estar moviéndote a derecha o a izquierda y estar ya muerto porque aparece uno de repente y te mete un cholazo y tu todavía no has visto la animación del tío saliendo por la puerta.

a ver, no predice tus movimientos, y esto es lo que se lía la gente. Dada tu posición y situación actual, el sistema te envía la información de TODOS los posibles estados que tendrás en el siguiente frame. Si estás jugando al Doom y estás en un frame X, el sistema considera todas las variables que te afectan directametne y según eso, por ejemplo, si estás frente a frente a un enemigo y de forma muy simplificada
si tus posibilidades son (de forma muy simplificada, insisto):
mover a la izquierda = L
mover a la derecha = R
mover hacia atrás = B
mover hacia adelante = F
saltar = J
disparar = S

tus posibilidades serían:
*, L, R, B, F, J, S = 7 acciones (* es hacer nada)
J + (L, R, B, F) = 4 acciones
S + (L, R, B, F) = 4 acciones
J+S+ (L, R, B, F) = 4 acciones

he omitido diagonales, etc...
En total tienes 19 posibles acciones a tomar desde el frame X

ahora,si asumimos que el enemigo tiene las mismas posibilidades que tu (mover, saltar, disparar), entonces el también tendrá 19 posibles acciones desde el mismo frame

luego, la red de posibilidades del frame X+1 (el siguiente frame) es (voy a apuntar en minúsculas los movimientos del enemigo y en mayúsculas los tuyos propios. agrupo los movimientos en pares que corresponden al movimiento propio y del enemigo):

Primera rama de posibilidades, el player se queda quieto (*) y el enemigo toma alguna de sus posibles acciones.
*#, *l, *r, *b, *f, *j, *s = 7 posibles frames que se pueden generar con el player quieto, y el enemigo tomando cualquiera de sus posibles acciones simples (sin combinar).
*j + (l , r , b, f) = 4 posibles frames con el enemigo saltando en alguna dirección
*s + (l, r, b, f) = 4 posibles frames con el enemigo disparando en alguna dirección
*j+s+ (j, r, b, f) = 4 posibles frames con el enemigo saltando y disparando en alguna dirección

Segunda rama de posibilidades, el player se mueve hacia la izquierda (L) y el enemigo toma alguna de sus posibles acciones.
L#, Ll, Lr, Lb, Lf, Lj, Ls = 7 posibles frames que se pueden generar con el player quieto, y el enemigo tomando cualquiera de sus posibles acciones simples (sin combinar).
Lj + (l , r , b, f) = 4 posibles frames con el enemigo saltando en alguna dirección
Ls + (l, r, b, f) = 4 posibles frames con el enemigo disparando en alguna dirección
Lj+s+ (j, r, b, f) = 4 posibles frames con el enemigo saltando y disparando en alguna dirección

Tercera rama de posibilidades, el player se mueve hacia la derecha (R) y el enemigo toma alguna de sus posibles acciones.
R#, Rl, Rr, Rb, Rf, Rj, Rs = 7 posibles frames que se pueden generar con el player quieto, y el enemigo tomando cualquiera de sus posibles acciones simples (sin combinar).
Rj + (l , r , b, f) = 4 posibles frames con el enemigo saltando en alguna dirección
Rs + (l, r, b, f) = 4 posibles frames con el enemigo disparando en alguna dirección
RJ+s+ (j, r, b, f) = 4 posibles frames con el enemigo saltando y disparando en alguna dirección

... así por cada posibilidad, sacamos la combinatoria entre las acciones del player y el enemigo, y obtenemos:
19 posibilidades del player 1 * 19 posibilidades del player 2 = 361 posibles acciones a tomar desde el frame X

actualmente, el servidor envía la posición actual (frame X) y va enviando esta información por cada frame que necesita. Si hay lag, veremos que se saltan algunos frames por que no es capaz de establecer el estado del frame X+n, por que n no le llega (puede que n+1 o n+2 si le llegue, pero un n+j fallará)

como no puede "dibujar" el estado en el frame X+n, dibujará el siguiente, y puede que el siguiente, o 2 mas, o los que necesite para retomar el flujo de datos. En estos frames que se pierden para el jugador, la partida se sigue desarrollando normalmente, y cuando el usuario por fin ve el renderizado en su pantalla, puede estar muerto (por ejemplo), por que en los frames anteriores que el no ha visto, le ha llegado un disparo.

retomando el ejemplo de las posiciones, DeLorean envía las 361 posibles acciones a tomar desde el frame X, y por tanto en el frame X+1, en el caso de que esta información no llegase al cliente, no hay problema por que el frame anterior (Frame X) ya tenía los posibles estados para Frame X+1 y por tanto lo puede dibujar y establecer el estado completamente. Así, si en el frame X+1 que no le ha llegado al usuario resulta que el enemigo dispara, el Player podrá ver esta acción y por tanto tomar la medida oportuna, todo esto sin tener salto de frames y con un tiempo de respuesta muy bajo, ya que no ha perdido frames, y no ha sucedido nada "inesperado" en esa "pérdida de frames" que vienen desde el servidor (claro, ya lo había calculado el sistema y ha mostrado lo que correspondía al frame X+1 sin problemas)

es un tanto complejo de explicar, pero una vez que entiendes de que va, resulta clarísimo y sobre todo, se entiende hasta cuanto podría mejorar la experiencia online (que no digo streaming, que también se vería beneficiada), todo esto sin necesidad de cambiar tu conexión ADSL.

evidentemente, mientras mas ancho de banda, mejor (mas frames posibles te podrá enviar. por ejemplo, podría calcular los frames X+2, que eso ya sería una burrada de información, si estamos hablando de renders de pantalla)

Buena noticia

Deen0X escribió:

rudedude escribió:No entiendo como funciona esto, en teoría predice tus posibles movimientos y los recibes más rápido que si no hiciera ese cálculo, pero si hay lag tu puedes estar moviéndote a derecha o a izquierda y estar ya muerto porque aparece uno de repente y te mete un cholazo y tu todavía no has visto la animación del tío saliendo por la puerta.

a ver, no predice tus movimientos, y esto es lo que se lía la gente. Dada tu posición y situación actual, el sistema te envía la información de TODOS los posibles estados que tendrás en el siguiente frame. Si estás jugando al Doom y estás en un frame X, el sistema considera todas las variables que te afectan directametne y según eso, por ejemplo, si estás frente a frente a un enemigo y de forma muy simplificada
si tus posibilidades son (de forma muy simplificada, insisto):
mover a la izquierda = L
mover a la derecha = R
mover hacia atrás = B
mover hacia adelante = F
saltar = J
disparar = S

tus posibilidades serían:
*, L, R, B, F, J, S = 7 acciones (* es hacer nada)
J + (L, R, B, F) = 4 acciones
S + (L, R, B, F) = 4 acciones
J+S+ (L, R, B, F) = 4 acciones

he omitido diagonales, etc...
En total tienes 19 posibles acciones a tomar desde el frame X

ahora,si asumimos que el enemigo tiene las mismas posibilidades que tu (mover, saltar, disparar), entonces el también tendrá 19 posibles acciones desde el mismo frame

luego, la red de posibilidades del frame X+1 (el siguiente frame) es (voy a apuntar en minúsculas los movimientos del enemigo y en mayúsculas los tuyos propios. agrupo los movimientos en pares que corresponden al movimiento propio y del enemigo):

Primera rama de posibilidades, el player se queda quieto (*) y el enemigo toma alguna de sus posibles acciones.
*#, *l, *r, *b, *f, *j, *s = 7 posibles frames que se pueden generar con el player quieto, y el enemigo tomando cualquiera de sus posibles acciones simples (sin combinar).
*j + (l , r , b, f) = 4 posibles frames con el enemigo saltando en alguna dirección
*s + (l, r, b, f) = 4 posibles frames con el enemigo disparando en alguna dirección
*j+s+ (j, r, b, f) = 4 posibles frames con el enemigo saltando y disparando en alguna dirección

Segunda rama de posibilidades, el player se mueve hacia la izquierda (L) y el enemigo toma alguna de sus posibles acciones.
L#, Ll, Lr, Lb, Lf, Lj, Ls = 7 posibles frames que se pueden generar con el player quieto, y el enemigo tomando cualquiera de sus posibles acciones simples (sin combinar).
Lj + (l , r , b, f) = 4 posibles frames con el enemigo saltando en alguna dirección
Ls + (l, r, b, f) = 4 posibles frames con el enemigo disparando en alguna dirección
Lj+s+ (j, r, b, f) = 4 posibles frames con el enemigo saltando y disparando en alguna dirección

Tercera rama de posibilidades, el player se mueve hacia la derecha (R) y el enemigo toma alguna de sus posibles acciones.
R#, Rl, Rr, Rb, Rf, Rj, Rs = 7 posibles frames que se pueden generar con el player quieto, y el enemigo tomando cualquiera de sus posibles acciones simples (sin combinar).
Rj + (l , r , b, f) = 4 posibles frames con el enemigo saltando en alguna dirección
Rs + (l, r, b, f) = 4 posibles frames con el enemigo disparando en alguna dirección
RJ+s+ (j, r, b, f) = 4 posibles frames con el enemigo saltando y disparando en alguna dirección

... así por cada posibilidad, sacamos la combinatoria entre las acciones del player y el enemigo, y obtenemos:
19 posibilidades del player 1 * 19 posibilidades del player 2 = 361 posibles acciones a tomar desde el frame X

actualmente, el servidor envía la posición actual (frame X) y va enviando esta información por cada frame que necesita. Si hay lag, veremos que se saltan algunos frames por que no es capaz de establecer el estado del frame X+n, por que n no le llega (puede que n+1 o n+2 si le llegue, pero un n+j fallará)

como no puede "dibujar" el estado en el frame X+n, dibujará el siguiente, y puede que el siguiente, o 2 mas, o los que necesite para retomar el flujo de datos. En estos frames que se pierden para el jugador, la partida se sigue desarrollando normalmente, y cuando el usuario por fin ve el renderizado en su pantalla, puede estar muerto (por ejemplo), por que en los frames anteriores que el no ha visto, le ha llegado un disparo.

retomando el ejemplo de las posiciones, DeLorean envía las 361 posibles acciones a tomar desde el frame X, y por tanto en el frame X+1, en el caso de que esta información no llegase al cliente, no hay problema por que el frame anterior (Frame X) ya tenía los posibles estados para Frame X+1 y por tanto lo puede dibujar y establecer el estado completamente. Así, si en el frame X+1 que no le ha llegado al usuario resulta que el enemigo dispara, el Player podrá ver esta acción y por tanto tomar la medida oportuna, todo esto sin tener salto de frames y con un tiempo de respuesta muy bajo, ya que no ha perdido frames, y no ha sucedido nada "inesperado" en esa "pérdida de frames" que vienen desde el servidor (claro, ya lo había calculado el sistema y ha mostrado lo que correspondía al frame X+1 sin problemas)

es un tanto complejo de explicar, pero una vez que entiendes de que va, resulta clarísimo y sobre todo, se entiende hasta cuanto podría mejorar la experiencia online (que no digo streaming, que también se vería beneficiada), todo esto sin necesidad de cambiar tu conexión ADSL.

evidentemente, mientras mas ancho de banda, mejor (mas frames posibles te podrá enviar. por ejemplo, podría calcular los frames X+2, que eso ya sería una burrada de información, si estamos hablando de renders de pantalla)

Ahora ya me queda algo más claro, otra cosa, si el jugador que aparece de repente y te mete un cholazo juega a 60 fames estables y tu a 30, se podría seguir aplicando este método de predicciones?

claro. a ver, esto es para que tu reduzcas tu lag. si tienes demasiado lag, evidentemente que perderás frames, pero no tanto como jugar sin DeLorean (que se me cuela una "L") .

sobre todo, el tiempo de respuesta que tendrás es mucho mejor que con un lag mas alto.

y se supone que a la larga lo que debería hacer este sistema es suplir a aquellos jugadores con mas lag, para que se iguales a los que tienen menos lag.

Deen0X escribió:claro. a ver, esto es para que tu reduzcas tu lag. si tienes demasiado lag, evidentemente que perderás frames, pero no tanto como jugar sin DeLoreal.

sobre todo, el tiempo de respuesta que tendrás es mucho mejor que con un lag mas alto.

y se supone que a la larga lo que debería hacer este sistema es suplir a aquellos jugadores con mas lag, para que se iguales a los que tienen menos lag.

Lo has explicado genial, era la idea básica que tenía en mi cabeza pero no me atrevía a explicarlo tan detallado

Lo que está claro es que se sigue necesitando ancho de banda de subida (ahora mucho más) y sigue siendo la carencia en el 95% de las líneas de conexión a Internet

al revés, necesitas ancho de banda de bajada. es el servidor quien lleva la partida quien necesita el ancho de banda, y DeLorean instalado para que funcione en cada cliente... y un poder de procesamiento bastante grande para realizar todos los cálculos de posibilidades y enviarla a cada jugador. (o por lo menos, a los que tienen un lag mayor, para equipararlo con el resto)

esto está pensado mas para servidores grandes de juegos, no para un pc de casa que haga de servidor con los colegas

Deen0X escribió:...pero no tanto como jugar sin DeLoreal...

¡Porque yo lo valgo!

La explicación por otro lado, perfecta. Un saludo y no te lo tomes a mal, es que no he podido evitarlo.

leapfrog escribió:

Petete_torete escribió:

seguipowers escribió:aun así no es un sistema que me llame mucho la atención, prefiero tener el juego descargado que los discos duros tampoco son tan caros, sale mucho mas barato tener un GRAN disco duro que una GRAN conexión

Uno que no anda perdido

Vamos que los discos duros son los que realizan todo el calculo relacionado con la ejecución del juego y comprandote uno de un par de teras todo solucionado.

Creo que el que anda un pelin perdido eres tu.

Lo que dice el compi es que con un disco duro tocho, el juego lo descargas en LOCAL, lo renderiza TU CONSOLA y tienes lag 0, al contrario que con una linea gorda, donde el juego se renderiza en Marte. (Y ya sabes, la fisica es una putada y las ondas electromagneticas tardan tiempo en viajar de A a B)

Para la proxima, la prepotencia mejor en casa y con tus colegas.

¿Pero que os pasa, entrais en una noticia de una tecnología que no teneis ni zorra y os poneis a decir chorradas a lo loco?
Si esto va de que tu PC no tenga que realizar el proceso, es la base de esta puta tecnología ¿a que viene tu comentario?

¿Para que quieres un disco de 2teras si tu PC no puede mover el juego y tienes un server que te lo mueve el ultra sin gastarte el dinero en componente?

Para la próxima deja de ir de salva internecs y piensa un poco antes de darle al teclado sin usar el coco.

Cualquier cosa que se investiguen más a fondo o que se inventen algo novedoso a algunos os parece directamente HUMO. Yo no se como pensáis que surgen las soluciones a los problemas actuales o los inventos.

Si por alguno del foro fuese aun pensaríamos que la tierra es plana.

Pararegistros escribió:

Deen0X escribió:...pero no tanto como jugar sin DeLoreal...

¡Porque yo lo valgo!

La explicación por otro lado, perfecta. Un saludo y no te lo tomes a mal, es que no he podido evitarlo.

DDDDDDDDDDD si, se me coló.. (fixed)

por cierto, todo lo que comento es considerando que el servidor envía el árbol de posibilidades en forma de renders. También puede ser (y de echo, creo que es mucho mas práctico) que el servidor envíe toda la información del árbol de posibilidades al cliente (PC) y sea éste el que, dependiendo de las acciones que realiza el jugador en el frame X+1, selecciona la información correspondiente a ese frame en el árbol de datos, y el PC renderea la pantalla (tiene mas sentido, claro).

El funcionamiento en general seguiría siendo el mismo que he comentado, con la diferencia que la carga de procesamiento para generar los renders se reduce drásticamente, ya que cada PC rendearía solo el frame correspondiente al X+1, y no se perdería tiempo ni potencia de procesamiento en el render de todas las otras posibilidades para ese mismo frame X+1 (basicamente, el servidor enviaría la información de posibles estados actuales de X+1, que eso si es mucho menos información que procesar)

lo que implicaría que el PC Cliente, debería tener una interfaz de DeLorean (un cliente) para entregar al procesador la información corresondiente al frame X+1 que realmente ha sido la "seleccionada" por el jugador gracias a sus acciones.

y por tanto... si el poder de procesamiento de renderizado se deja al PC, esta tecnología no sirve de nada para el streaming de juegos (ya que en ese caso, si que habría que realizar el renderizado de cada frame X+n, siendo n el nivel de "predicción" o grados de posibilidades que tiene el juego desde el frame X)

jur... mientras mas lo leo y comento, mas interesante y útil me parece todo esto.