Ver la versión completa : Ayuda: Protocolo de juegos "en tiempo real".
Hola !
Hace tiempo que programo juegos por intermet/red, pero siempre han sido juegos por turnos, así que no he tenido muchas dificultades con el "tiempo real".
Ahora estoy haciendo para la GP32 un bomberman multijugador .... y queria preguntar si alguien me puede iluminar sobre que protocolo es mejro utilizar.
- Una GP hace de servidor, i las otras envian "keystrokes", i la GPservidor envia el resultado ??
- Un jugador se mueve i envia el resultadoi del movimiento ??
Hay algun truco ? algun manual ??
Adios !
A ver, yo lo veo así. Tienes un mapa que es identico en las 2 GP's, pues solo tendrias que enviar las coordenadas del muñeco y sus acciones (poner bomba en tal posicion). Si lo codificas bien lo harías enviando poca información...
LukStarkiller
19/01/2006, 01:43
Haz que simplemente se envien los datos sobre coordenadas y acciones (las muestras por segundo que tu veas convenientes, y que se encargue la otra GP que las recibe de interpretarlas (asi funcionaban muchos juegos antiguos), el problema es que si la conexion es mala, en una GP se realizara una accion, esta la enviara y la otra sino la recibe no la ejecutara, asique lo mas logico es que se vayan enviando alguna especie de feedback. Aunque asi pierdes ancho de banda y tiempo es mas seguro, depende del tipo de juego.
La otra idea seria hacer una GP como host y server, es decir que controla todas las acciones, y la otra depende al 100% de lo que interprete la servidor, como se hace esto a lo rapido?
Pues simplemente lo mismo de antes, pero que la GP cliente, envia lo que hace al server, y el server responde con su informacion + la que ha interpretado de la GPcliente, y que la GPcliente muestre lo que la GP servidor le envia.
La idea es bastante chapuza pero puede funcionar bastante bien si la conexion es buena ^^
Bueno, yo he dado por supuesto el protocolo en si de enviar los datos (envio+confirmación) ya que por lo que dices has hecho ya varios juegos en red y supongo que tendras experiencia en esos temas.
Damizean
19/01/2006, 02:07
Es mucho mas facil y rapido enviar simplemente la informacion de la tecla en el momento en que estas cambien. Y por si acaso, cada X tiempo enviar la informacion de la posicion o si ha creado una bomba.
Lizardos
19/01/2006, 07:45
El problema fundamental es la pérdida de paquetes, creo yo. Si es una conexión a través de internet se pueden perder paquetes, por lo que el envío de keystrokes llegará un momento en que no indiquen las acciones con precisión, por lo que sería mejor enviar la posición del jugador y sincronizar los mapas (bombas, objetos, ladrillos...). Si es una conexión serie, ahí no hay pérdida de datos y puedes enviar directamente los keystrokes.
En cuanto a la sincronización, he visto una técnica llamada "dead reckoning" que consiste en enviar la velocidad y dirección (el vector) además de la posición, con lo que puedes anticipar el movimiento desde el otro cliente incluso con una latencia excesiva. Si programas juegos multijugador seguramente la conocerás (ejemplo "Space Brouhaha" del SDK de DirectX), por si no mirando un poco en el google me ha salido http://www.revista.unam.mx/vol.2/num4/art1/ aunque seguramente habrá explicaciones mucho mejores.
Saludos
Gracias a todos por responder .... mañana hago un resumen de todo a ver si me decido :-p
Bye !
PharaOnyx
19/01/2006, 08:36
Si no recuerdo mal, Petiso (corrígeme si me equivoco) había contemplado la posibilidad de pasarse al cable serie GP32-GP32 en vez del módulo RF (al menos con el RF-Pong sucedió esto). No sé si esto abarca también a ese Bomberman que andas desarrollando.
Dicho esto, me parece que nos estamos desviando un poco del tema. Perder paquetes en una conexión por Internet es relativamente sencillo, tanto por calidad de conexión como por distancia, pero en un cable serie de unos pocos centímetros me parece un poco exagerado :S (o incluso con el módulo RF tampoco es demasiada distancia - ¿quién juega a metros y metros de los colegas? :D)
Soy de la opinión que transferir las pulsaciones de las teclas de cada GP32 a la otra es lo más sencillo para tí (si me apuras incluso eficiente). Ten en cuenta que los sprites de los jugadores los vas a tener que mover igual en ambas consolas. Recibiendo la pulsación de teclas del otro jugador incluso podrías reutilizar rutinas/funciones (me explico mejor en '1'). Además, las pulsaciones son fácilmente codificables con unos pocos bytes, usando poco ancho de banda del cable y dejándote la posibilidad de usar ese ancho de banda 'extra' para otras cosas (incluso para no sobrecargar la CPU/UART con demasiados datos de entrada/salida)
Saludos
'1': imagina que tienes una función procesarPulsación(Jugador,Tecla) que hace una determinada función según la tecla que recibe (dibujar el sprite del Jugador en determinada posición y demás). Sólo tendrías que almacenar en cada GP32 una 'colección' de Jugadores y aplicarles las acciones correspondientes, independientemente de si es un jugador 'local' (GP32 en la que juegas) o un jugador 'remoto' (otro jugador conectado por cable/RF). Espero haberme explicado bien :)
Si no recuerdo mal, Petiso (corrígeme si me equivoco) había contemplado la posibilidad de pasarse al cable serie GP32-GP32 en vez del módulo RF (al menos con el RF-Pong sucedió esto). No sé si esto abarca también a ese Bomberman que andas desarrollando.
Dicho esto, me parece que nos estamos desviando un poco del tema. Perder paquetes en una conexión por Internet es relativamente sencillo, tanto por calidad de coneíón como por distancia, pero en un cable serie de unos pocos centímetros me parece un poco exagerado :S (o incluso con el módulo RF tampoco es demasiada distancia - ¿quién juega a metros y metros de los colegas? :D)
Soy de la opinión que transferir las pulsaciones de las teclas de cada GP32 a la otra es lo más sencillo para tí (si me apuras incluso eficiente). Ten en cuenta que los sprites de los jugadores los vas a tener que mover igual en ambas consolas. Recibiendo la pulsación de teclas del otro jugador incluso podrías reutilizar rutinas/funciones (me explico mejor en '1'). Además, las pulsaciones son fácilmente codificables con unos pocos bytes, usando poco ancho de banda del cable y dejándote la posibilidad de usar ese ancho de banda 'extra' para otras cosas (incluso para no sobrecargar la CPU/UART con demasiados datos de entrada/salida)
Saludos
'1': imagina que tienes una función procesarPulsación(Jugador,Tecla) que hace una determinada función según la tecla que recibe (dibujar el sprite del Jugador en determinada posición y demás). Sólo tendrías que almacenar en cada GP32 una 'colección' de Jugadores y aplicarles las acciones correspondientes, independientemente de si es un jugador 'local' (GP32 en la que juegas) o un jugador 'remoto' (otro jugador conectado por cable/RF). Espero haberme explicado bien :)
Si no me equivoco, Petiso el tema de GP32-GP32 ya lo tiene solucionado, lo que quiere hacer es GP32- INTERNET -GP32..... creo :D
Exacto PharaOnyx, es para el puerto serie de la GP/RF. Así que teoricamente no habrá perdida de paquetes. Igualmente, si estamos en internet bajo TCP, tampoco habria perdida de paquetes ... pero esto es otro tema.
TRaFuGa, no està solucionado al 100% todavia .... el problema sigue siendo GP32-GP32 (en "tiempo real"). Pasarlo luego a GP32-internet-GP32 será facil ...
La idea es hacer un protocolo que sea adaptable a qualquier juego.
Pro lo tanto, demomento me decanto por enviar keystrokes:
En cada frame, cada jugador envia el estado de sus teclas.
Si suponemos que tenemos un juego de a 25fps (por decir algo), quiere decir que tenemos 0.04 segundos para enviar nuestras pulsaciones/recivir la de los demà.
En la GP tenemos pocas teclas, 10, que son 2 bytes.
Por lo tanto, se ha de enviar sunpongamos un maximo de 2 jugadores, 2 bytes por jugador. Son un total de 4 bytes (2 que envio, 2 que recivo).
Y a 9600 bps, son 0.0033333 segundos. De sobras :-p
He estado mirando, y esto es lo que hace el kaillera (http://www.kaillera.com/).
En cada frame envia las pulsaciones de las teclas de cada jugador.
Pero esto implica que se ha de tener el MISMO mapa de antemano en cada consola. No sirve hacer un "random" de si sale un monstruo o no.
Weno ... ahora toca programarlo :loco: .
Adios y gracias de nuevo.
Lizardos, esto del "dead reckoning", es lo que hago para el NETpong (sin saberlo), envio posicion de la pala/pelota y que direccion y velocidad tiene.
Y funciona "bien", el problema es que cada juego necessita su implementacion especifica. No puedes haver un protocolo general para todos los juegos.
En el RFpong tienes uan pelota, en el juego X de naves, tendràs 3 naves, en otro una pelota de funbol ... etc.
Con keystrokes, se puede hacer un protocolo generico que sirva para qualquier emulador/juego.
Bye !
PharaOnyx
20/01/2006, 10:45
Pero esto implica que se ha de tener el MISMO mapa de antemano en cada consola. No sirve hacer un "random" de si sale un monstruo o no.
Ciertamente es un problema, al menos en parte. En el Dynablasters/Bomberman original los enemigos siempre aparecen en el mismo sitio (se guardan en un archivo de 'configuración' y se precarga al inicio junto con la imagen de fondo). Y en una partida multijugador ni siquiera hay enemigos, sólo los jugadores 'humanos'. Si quieres hacer un juego 'aleatorio 100%' (pongamos un matamarcianos) entonces si se presentarían complicaciones por el hecho de tener que sincronizar la aparición de enemigos en ambas consolas (aunque se podría hacer mediante una función apareceEnemigo(TipoEnemigo,PosiciónPantalla) que se ejecute al recibir ciertos datos por el puerto que sí podría darse de forma aleatoria). La verdad, creo que los juegos que más me gustaron siempre tenían aparición fija de enemigos: de plataformas la saga Mario, de matamarcianos la saga Gradius/Parodius, etc. Creo que donde mayor problema habría sería al hacer un juego deportivo (de fútbol por ejemplo), que son los que más imprevisibles me parecen. El resto de géneros son relativamente 'fáciles' de llevar haciéndolos 'fijos'
Si se te puede ayudar en algo, no dudes en decirlo :)
Saludos
anibarro
20/01/2006, 16:52
Estaria bien enviar el numero de fotograma ademas de las teclas, por si hiciese falta sincronizar eventos como el de aparicion de enemigos o cosas asi
Pos si, mi idea era NO usar mapas predefinidos ... que sino ya te sabes de memoria donde sale cada item y donde no.
Demomento barajo 2 posibilidades:
a) al empezar cada partida, que una GP se encargue de enviar el mapa a las otras. De esta forma, se usará siempre el mismo mapa. Problema: ya no solo envias keystrokes.
b) (teoria loca ... :loco:). El protocolo durante la inizialización envia un numero aleatorio a todas als GP's. Este numero se usarà como semilla del generador de numeros pseuso-aleatorios.
Asi con esta semilla, cada GP generarà teoricamente el mismo mapa.
En resumen ... la idea es hacer los mapas aleatorios ... ya veremos como :-p
anibarro, lo del numero de frame es buena idea, ni que demomento no lo hago ... ya que presunpongo que no hay perdidas de paquetes.
El "pseudocodigo" es:
for(;;)
- Leo teclas.
- Envio teclas.
- Recivo teclas de otros jugadores.
- Trato las teclas de todos los jugadores (incluso las mias), i siempre en el mismo orden: j1, j2 j3, j4 ...
- Pinto pantalla
Adios !
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.