Comunidad Game Maker

Si, si se programa bien funciona de maravilla. Además no hay que ser tan pesimistas con los fps, lo que más falla en un juego online es el envío de datos, los fps son muy secundarios

Cita de: Texic en Enero 11, 2013, 01:16:52 AMAdemás no hay que ser tan pesimistas con los fps, lo que más falla en un juego online es el envío de datos, los fps son muy secundarios

No es que sea pesimista, es que no se puede asegurar que los fps van a ser constantes durante el juego entero. Incluso, por ejemplo, usando el método que proponés, el usuario servidor podría bajar sus fps deliberadamente para que el usuario cliente no vea los objetos en donde realmente se encuentran.

Por otro lado, no entiendo por qué decís que lo que más falla es el envío de datos. En mi experiencia los datos se suelen enviar sin problema ninguno. Como mucho algún paquete se puede perder, si se envía por UDP. Sería un desastre que no existiera una manera fiable de enviar un paquete por internet.

Nono, digo por el ancho de banda que consume enviar muchas cantidades de datos, imaginate la cantidad de balas que pueden llegar a haber en pantalla, sumado al movimiento sprite, etc de los personajes, sumado a cuanto dato haga falta enviar, recibir, y eso para cada jugador conectado, es mucho. Cuando hacés un juego online tenés que optimizar más que nada el envío (y recepción por ende) de datos. Puede llegar a ocurrir deincronización si los fps fluctúan mucho, si, pero mucho peor sería la desincronización si terminás con datos que tardan 1 segundo o medio segundo en llegar al receptor, una catástrofe total, porque por más que trates de sincronizar luego las balas, los datos van a seguir llegando horrendamente tarde y eso no lo podés solucionar con ningún código. Hay ventajas en reajustar la posición de las balas, pero las desventajas las superan ampliamente, no resulta conveniente para nada. No voy a decirte que tengo razón porque creo que la tengo o porque teóricamente debería ser así, lo digo porque he probado ambos métodos y para wan conviene infinitamente lo que dije, cada byte cuenta

Me parece que estás confundiendo la dessincronización con la latencia. Latencia siempre va a haber, en WAN, LAN y hasta MAN, y no es tan grave. Los jugadores más afectados tardan un poco más en recibir y enviar datos, que puede suponer una desventaja, pero nada más. En cualquier caso, la latencia rara vez se ve afectada por la cantidad de datos que envíes (a no ser que envies una cantidad realmente descomunal); más bien por la conexión de los jugadores y el ping.
En cambio la des-sincronización de datos es un verdadero problema. Un jugador puede ver una cosa y otro puede ver otra completamente distinta, aunque la conexión sea perfecta y con latencia mínima. Y la mejor manera de tratar con la des-sincronización es evitar que pase.

No he confundido nada, a lo mejor has malinterpretado la parte en la que mencioné la desincronización y la latencia al mismo tiempo, pero me refería a que un juego en tiempo real no se puede mantener sincronizado con más de 500ms y es muy común obtener esas cifras con la 39dll. Además tené en cuenta que en una conexión p2p con la 39dll no se suelen obtener altas velocidades, de una conexión con una subida de 40kbps te quedarán 5 o 10 y se dividen entre la cantidad de jugadores, si en cada step tenés que enviar más datos de los que puede la conexión entonces se embotellan y se obtiene un asqueroso efecto, mucho peor que la latencia. Los bytes no sobran, todo suma y al final hay que andar rehaciendo códigos por no optimizar el envío de datos. La optimización de fps o la mecánica de sincronía se puede hacer después, primero lo primero, que es ahorrar cada bit como si de oro se tratase

   ¡Esto muy bueno!  XD XD XD


   Sería interesante poner a prueba todas las posibilidades para determinar cual es más eficiente en cada caso.

  Me interesa mucho el tema... 8)

Texic, el "asqueroso efecto" que mencionás es producido por la latencia; la des-sincronización es más grave y no se puede arreglar de forma ninguna. Si ocurre, básicamente lo único que podés hacer es reiniciar el juego y probar otra vez.

Me suena a kaillera xD
La desincronización de un juego así no es muy grave, es más que esperable, no es como en kaillera que los emuladores tienen que estar completamente sincronizados para funcionar. Con respecto al efecto que mencioné, no hablo de la latencia, hablo de datos que quedan en cola, y más datos que quedan en cola, y así infinitamente hasta que la cola es tan grande que lo que haces llega 20 segundos después a los demás. Como bien dijo ferhand, habría que hacer pruebas, pero es imposible probar lo que digo en un ejemplo dedicado, tendría que estar incrustado en un juego con mucho envío de datos, porque sino no saturarían el servidor.
PD: Con tu método sucedería otra cosa que no me gusta, recuerda que la latencia sube y baja constantemente, y la actualización de coordenadas a veces llegaría antes y a veces más tarde, produciría un efecto muy extraño en el movimiento de la bala, parecería una bala con epilepsia xD

Cita de: Texic en Enero 11, 2013, 06:42:24 PM
Me suena a kaillera xD

Sí, con Kaillera pasa seguido.

Cita de: Texic en Enero 11, 2013, 06:42:24 PMLa desincronización de un juego así no es muy grave, es más que esperable, no es como en kaillera que los emuladores tienen que estar completamente sincronizados para funcionar.

¿Cómo que no?

Cita de: Texic en Enero 11, 2013, 06:42:24 PMCon respecto al efecto que mencioné, no hablo de la latencia, hablo de datos que quedan en cola, y más datos que quedan en cola, y así infinitamente hasta que la cola es tan grande que lo que haces llega 20 segundos después a los demás.

Me pregunto cómo hiciste para lograr ese efecto...

Cita de: Texic en Enero 11, 2013, 06:42:24 PMPD: Con tu método sucedería otra cosa que no me gusta, recuerda que la latencia sube y baja constantemente, y la actualización de coordenadas a veces llegaría antes y a veces más tarde, produciría un efecto muy extraño en el movimiento de la bala, parecería una bala con epilepsia xD

Puede ser, pero el efecto no debería ser muy perceptible, a no ser que los fps de alguno de los jugadores estén muy bajos.

Bastante interesante el debate.
Me había topado, haciendo el juego, con una desincronización con los items agarrables, como ser por ejemplo las monedas.
Y mi juego solamente tiene 2 jugadores, es decir, el máximo es de 2, el Servidor y el Cliente.
Supongo que el mejor método sería el de Wadk, o no? Digo porque no son una gran cantidad de jugadores...

As you wish lady. Es velocidad contra estabilidad resumiendo, aunque a grandes razgos. Probá ambos sistemas y tomá tu propia decisión, ya tenés todos los datos sobre el funcionamiento de ambos y un largo debate sobre cuál resulta más conveniente. Lo de los items agarrables ha de haber sido un problema menor, no tienen una trayectoria movil como las balas, simplemente hay que crearlos de un lado del juego y pasar los datos al otro, lo mismo para cuando se destruyan. En ese caso se habla de un envío de datos de única ejecución, para las balas sería ejecución constante y si hay muchas balas en pantalla hay que enviar datos por cada una en cada step o intervalo de tiempo

Hoy checando la Http Dll 2 me encontré que el creador de la dll hablaba de algo parecido a lo que dice texic. cito el mensaje:

CitarThe DLL also fixes an annoying bug/feature in 39dll that can cause data to be lost. With 39dll, the maximum amount of data that can be recieved as a whole is limited by the operating system. Windows will only buffer a fixed amount of data, e.g. 64KB. This might not be enough if you're trying to send large files. If too much data is buffered by the receiver, the sender has to wait to send more data. Since 39dll's sendmessage function doesn't wait, part of the data is lost if too much data is sent at once. This DLL does additional buffering to avoid this problem, so no data is ever lost. You can buffer as much data as you want on both the sending side and the receiving side.

CitarLa DLL también repara un molesto bug/carcteristica de la 39dll que puede causar perdida de datos. Con la 39dll, el máximo numero de datos que puede ser recibido en conjunto está limitado por el sistema operativo. Windows solo procesara una cantidad fija de datos, ej. 64KB. esto puede no ser suficiente si estás intentando enviar archivos grandes. Si muchos datos son almacenados por el receptor, el emisor tiene que esperar para enviar mas datos. Como la función para enviar mensajes de la 39dll no espera, una parte de la información es perdida si se envían muchos datos a la vez. Esta DLL hace un almacenado adicional para evitar esté problema, por lo que nunca se pierden datos. Tu puedes almacenar cuantos datos quieras en ambos lados el lado del emisor y del receptor.

No se bien como traducir lo de buffer, pero bue...

Por cierto yo creo que la mejor forma de hacer balas es hacerlas instantáneas es decir que solo se vean como un destello o una linea y que apenas se crean ya se sepa a que le dieron.

Bueno, el problema que citaba Texic puede ser ese, pero en este caso creo que no aplica porque según entendí, solo ocurre al mandar muchos datos en un paquete único...

Cita de: brunoxzx en Enero 17, 2013, 06:16:24 PM
Por cierto yo creo que la mejor forma de hacer balas es hacerlas instantáneas es decir que solo se vean como un destello o una linea y que apenas se crean ya se sepa a que le dieron.

Jaja bueno, eso no estaría mal, pero ya cambia el gameplay del juego :P.