Movimiento sincronizado

Drumpi · March 11, 2011, 04:22:00 AM

Hombre, ¿ves? eso del x=x+5 es una de las cosas de las que hablaba: esa asignación es dependiente de los FPS, ya que a más FPS, más distancia recorre en el mismo tiempo real. En todo caso tendrías que multiplicar los pixels que se recorren en una unidad de tiempo, por el número de unidades de tiempo transcurridas (decimales incluidos).

Lo elegante es tener un frameskip adecuado, como te dice Splinter ¿nunca has jugado en red y, en un momento dado, tu PC ha hecho un extraño y los personajes se han quedado congelados un momento y después se han teletransportado a donde deberían estar? eso ha sido un frameskip: ha dejado de dibujar algunas imágenes (solo que en lugar de ser el propio ordenador el que va calculando el movimiento, recibe del servidor la posición, gráfico, etc de todos los elementos del juego).

Y en Bennu porque tienes los FPS como referencia, no quiero ni pensar en sincronizar juegos en C donde tú mismo debes definir el tiempo de retardo entre imagen e imagen según la cantidad de cálculos realizados :S

Arcontus · March 11, 2011, 02:52:02 PM

Quote from: SplinterGU on March 11, 2011, 12:01:20 AM
yo no creo que windgate haya dicho eso de que el frameskip penalizaria en maquinas chicas, si lo dijo, esta mal... yo entiendo que windgate quiso decir otra cosa.

Humm, no Windgate no ha dicho eso. He sido yo que he malinterpretado el funcionamiento de frameskip y de hecho trás la explicación, sigo teniendo dudas:
SplinterGU corigeme si me equivoco (o cualquiera), si deseo hacer una sincronización que vaya desde máquinas a 60fps a máquinas a 10fps, ¿debo poner set_fps(60,6); asegurando que dentro de ese rango de FPS SI estará sincronizado? En caso de haberlo entendido correctamente, ¿Contabilizará collisions y otras historias en esos frames no dibujados?

Gracias de nuevo por todos los comentarios.

SplinterGU · March 11, 2011, 03:17:18 PM

si, no se si 6 fps sera lo que te dara 60fps de logica en maquinas donde tiene 10fps de render, eso depende, pero posiblemente si, y si funcionaran todas las colisiones y todo.

DCelso · March 11, 2011, 03:34:02 PM

yo estoy deacuerdo con usar fps.
Debes de poner en todas las máquinas el mismo valor de fps y sincronizar tus movimientos con éste.
Pon el valor de fps más bajo que te den todas las máquinas que van a implicarse en tu juego y punto, ya todas irán a ese mismo fps y todo se moverá a la vez. frame, hace pausas haciendo así que todos los procesos acaben su frame antes de seguir.
El problema se encontraría sí y solo sí una máquina fuese tan mala que no fuera capáz de correr a ese fps asignado, con lo que usando frameskip harías que se saltase algunos frames para poder ir al fps asignado.
Hablando en números: si pones fps a 25 y usas la palabra frame en todos tus procesos, cada frame durará 1/25 segundos, así que si las instrucciones que hay antes de la palabra frame son más rápidas que eso, pues frame hará que se espere hasta pasar justo 1/25 segundos antes de continuar.
El problema radicaría sí y solo sí, como dije antes, las instrucciones antes de la palabra frame fuesen muchísimas y muy lentas y durasen más de 1/25 segundos, por eso si sacas el rendimientó máximo de frames por segundo que te da el juego en todas las máquinas puedes usar este para usarlo en la función set_fps y hacer que todos esperen a estas intrucciones tan lentas que pusiste en determinado proceso.

Arcontus · March 11, 2011, 04:36:50 PM

Al final, dado que es tan sencillo de implementar estoy probando el frameskip y tiene buena pinta. El contador FPS a veces muestra 59 otras hasta 62, pero es bastante estable, así que creo que usando esto y sincronizando todo de tanto en tanto funcionará bastante bien.

Karma SplinterGU ;D

Drumpi · March 11, 2011, 06:04:23 PM

El frameskip lo que hace es saltarse las rutinas de dibujado, sólo eso, por lo que los demás cálculos se harán. Pero ojo, si esos cálculos superan el tiempo como te ha indicado XCelso, ni el frameskip te librará, se retrasarán e intentará sincronizarse cuando haya momentos de menos cálculos.

Por eso se recomienda optimizar el juego para que funcione en la máquina más pequeña. Es más, se recomienda que el servidor sea una máquina potente para que realice todos los cálculos, de forma que los clientes sólo se limiten a mostrar los gráficos tal como se lo indique el servidor, y que dicho servidor sea rápido en las comunicaciones, para manejar todo el volumen de datos entrantes y salientes.

Por ejemplo: un cliente hace un salto, pues se lo dice al servidor, que realiza los cálculos del movimiento parabólico con complejas ecuaciones físicas, y luego le dice al cliente "píntate en las coordenadas (x,y)".

De todas formas, ten en cuenta que hay cosas peores que un ordenador lento en la red, y es que hay que contar con el retardo de la propia línea, el tiempo que pasa entre el envío y la recepción de datos, y la posibilidad de que algunos paquetes se pierdan por el camino. Por eso se dice que es difícil hacer un juego en red, pero vamos, no te asustes, que hay librerías que ya tratan con algunas cosas de estas, y a menos que estés haciendo un juego en el que el tiempo sea crítico (léase carreras con tiempos muy ajustados), tampoco pasa nada por tener un poco de lag ;)

DCelso · March 11, 2011, 06:16:45 PM

umn, hombre un lag en un juego es la diferencia entre estar vivo o muerto :D.
Lo que se debería de hacer es que el servidor mida los lags de todos los usuarios involucrados en el juego y sabiendo el del más lento, ajuste el envío a los otros demendiendo de éste para que todos reciban la orden al mismo tiempo (o casi al mismo tiempo :D).

Arcontus · March 11, 2011, 07:01:30 PM

Quote from: DCelso on March 11, 2011, 06:16:45 PM
umn, hombre un lag en un juego es la diferencia entre estar vivo o muerto :D.
Lo que se debería de hacer es que el servidor mida los lags de todos los usuarios involucrados en el juego y sabiendo el del más lento, ajuste el envío a los otros demendiendo de éste para que todos reciban la orden al mismo tiempo (o casi al mismo tiempo :D).

Aun no he empezado con la tortura de red a nivel del juego, antes quería que los PC's estubieran sincronizados, ya que los calculos NO quiero que los haga el servidor. Quiero que el servidor sea únicamente el puente para comunicar clientes, pero deberán ser los clientes los que tengan en cuenta sus latencias y tal. De hecho, estoy valorando que los clientes no ejecuten una orden, hasta un segundo después de recibirla, de modo que el resto ya esté al tanto de dicho cambio antes de que suceda.

De todas maneras, esta es otra guerra y es probable que merezca un nuevo post si necesito ayuda. Por lo pronto, el frameskip parece la más sencilla solución al problema de sincronismo. Relamente me sorprende muchisimo lo que hace dicha función, y aparentemente funciona.

Saludos!

SplinterGU · March 11, 2011, 07:14:02 PM

no se como lo tenes pensado, pero la logica deberia estar en el servidor, sino que cada cliente se sincronice y mantenga logica de cada otro cliente y otras tantas cosas mas, no solo te vas a volver loco, sino que va a ser una tarea titanica ver algo sincronizado.

sin contar lo facil que va a ser trucar el juego...

Drumpi · March 12, 2011, 01:11:31 AM

Ya estaba Splinter tardando demasiado ;D

Hombre, trucar el juego siempre es "fácil", pero como alguien dijo hace poco, si el sistema es de código abierto, pues mucho más :D :D :D

En este caso, la solución es sencilla: jugar con amigos y gente de confianza :D

SplinterGU · March 12, 2011, 01:30:57 AM

drumpi, no... en un juego con logica bien desarrollada en el servidor no es simple trucarlo... y ahi no importa que se tenga o no el codigo fuente... la cuestion radica en que la logica esta protegida fisicamente fuera de nuestra alcance... y es el servidor quien decide que asignar o no (dinero, objetos, niveles de experiencia, energia, muerte, etc...)

Drumpi · March 12, 2011, 02:23:19 PM

Hombre, claro, si el servidor se encarga de todo y los cliente sólo se dedican a enviar los botones pulsados, las coordenadas de destino o cosas así, es casi imposible de trucar, pero entonces se necesita una máquina que sea (n_clientes+1)*bucle_juego veces más potente que las demás, y en ocasiones eso no es posible.

Imagina el Echo en red: o cada WIZ hace sus propios cálculos, o la WIZ servidor explota :D

SplinterGU · March 12, 2011, 02:55:32 PM

no es tan asi como enviar botones, coordenadas destino y cosas asi...

el servidor se encarga de la logica del juego, que asignar, que dar, que eventos disparar, etc.

el cliente se encarga de hacer todas las animaciones secundarias (escenarios, efectos climaticos, etc), recoger pulsaciones y procesar las coordenadas (que despues seran validadas o no por el servidor), realizar por si mismo todo lo que no sea critico para la logica y seguridad del juego.

Windgate · March 31, 2011, 07:09:48 PM

Me había perdido la conversación, en lo último que escribí, sí, quise decir "variable" intermedia xD

Splinter, lo del frameskip no me gusta usarlo, prefiero la solución del deltaTime porque te asegura exactitud ante cualquier situación. Pero a ver si es que yo estoy equivocado, ¿Tú quieres decir que si deseas un framerate de 60 tendrías que hacer set_mode ( 60 , 60 ) para que sincronice perfectamente en el peor de los casos?

SplinterGU · March 31, 2011, 09:06:58 PM

lo de los deltaTime no es un buen metodo, no solo en situacion normal, sino en situacion donde estamos faltos de fps, porque no solo puede ser un problema de dibujado, sino tambien de procesamiento, y en ese caso podemos incluso calcular menos, y un juego no es solo el dibujado, la fluidez logica es lo mas importante cuando necesitamos sincronia.

es un poco complicado de explicar... pero los delta servirian en un esquema donde trabajamos con set_fps(0,0), y donde no nos importa nada salvo el tiempo para dibujar y procesamos a la mayor velocidad posible, pero eso puede ser muy complicado de implementar para muchos usuarios.

perdon, si no logro explicarlo correctamente.