[Olpc-uruguay] Difícil la Red !!

Mar Ago 31 21:19:12 EDT 2010

  Otra que se me ocurre tambien , que por ahi vi un recvfrom ( 1000 )
Si no hay otro seteo por ahi que no vi , hasta que no tengas 1000 bytes 
el recvfrom no te suelta.

Si es asi tenes que tener alguna forma de normalizar el tamaño de lo que 
lees , o sea si mandas coordenadas  formatealas
para que siempre sean 3 o 4 digitos tipo para x = 5 , y = 1024       
envia 0005,1024 cosa que el tamaño del envio para todos los mensajes
sea el mio asi el recvfrom te suelta ni bien recibe 1 envio del cliente.
Podrias tambien antes de enviar los datos enviar primero el tamaño del 
paquete ( siempre un numero fijo  de bytes ) 09 o 26 etc , y  luego si
enviar los datos tal cual lo haces hoy.
Al recibir haces un revcfrom(2) obtenes el tamaño y luego si 
recvfrom(tamaño) para que nunca te tranque.Eso en una red local sin 
cambiar mucho el
juego como esta hoy ( nada de lo de las velocidades etc etc del mail 
anterior ) te debe mejorar mucho el comportamiento.

El 31/08/2010 10:06 p.m., Fabian Peña escribió:
> Bue , una respuesta no muy trabajada.
> Segun veo mandas a los clientes la posicion x,y de cada tanque a 
> medida que estos se van moviendo.Eso te obliga a tener una velocidad 
> de comunicaciones tal que te permita un movimiento fluido.
> Yo creo que cada cliente debiera poder mover un tanque o bala por si 
> solo dado un angulo y velocidad y recibir datos solo cuando alguno 
> cambie de direccion.
> En si toda la mecanica del juego , movimientos de tanques, balas , 
> deteccion de explosiones suma de puntajes bla bla bla queda del lado 
> del cliente y la mision del servidor es avisar cuando un nuevo tanque 
> entra y su posicion inicial y avisar un cambio de angulo o detencion.
> Fijate si cambia las cosas que en el servidor no tenes porque saber 
> que una bala le dio a un tanque ya que no hay porque informarselo a 
> nadie ( ya todos lo saben )
> Esos cambios ( de concepto , que son los peores ) te permitirian mas 
> independencia del rendimiento de la red.
>
>
> Salu 2
>
>
>
>
>
>
> El 31/08/2010 09:07 p.m., Flavio Danesse escribió:
>> Suave con las respuestas por favor que me están agobiando a correos.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> El 29 de agosto de 2010 19:38, Flavio Danesse <fdanesse en gmail.com 
>> <mailto:fdanesse en gmail.com>> escribió:
>>
>>     Bueno, tengo el juego andando en la red aunque me he encontrado
>>     con cosas bastante complejas.
>>
>>     Gracias al código de ejemplo que me mandó Andrés, adapté mi juego
>>     intentando seguir su modelo.
>>     Sin este ejemplo no hubiera encontrado la manera de hacerlo, de
>>     modo que mi agradecimiento por tomarse un rato para construirlo y
>>     por aguantarme sobre todo.
>>
>>     El problema que tengo en el código es que demora mucho la
>>     actualización de los datos en los clientes y que los tanques de
>>     las máquinas remotas, se ven a los saltos en los clientes
>>     locales, así que no tiene nada que ver lo que pasa en el servidor
>>     con lo que pasa en los clientes y además en todos los clientes
>>     las cosas son distintas. Se supone que debe pasar lo mismo en
>>     todos lados, de lo contrario es mejor jugar solo.
>>
>>     Paso zipeado el código que tengo hasta ahora, a ver si alguien
>>     tiene ganas y tiempo de mirarlo y encuentra alguna cosa que puada
>>     servirme de guia.
>>     Como verán, deshabilité todos los disparos para simplificar hasta
>>     resolver este tema. Para correr el juego deben ejecutar el
>>     archivo gtk_JAMtank_Ventana.py
>>
>>     Una de las cosas que encontré es que los clientes deben escribir
>>     obligatoriamente en el socket en cada pasada del bucle de pygame,
>>     de lo contrario, cuando el tanque está quieto, todo se le
>>     enlentece (las balas por ejemplo), esto no debiera ser bueno
>>     porque estoy ocupando al servidor sin necesidad ya que si no hay
>>     cambios en el cliente, no tiene sentido actualizar sus datos en
>>     el servidor.
>>
>>     De modo que, en el cliente, mientras el tanque local se mueva,
>>     todo anda bien, (menos los tanques remotos que saltan y se
>>     atrasan), si el tanque local se queda quieto, todo lo demás se
>>     enlentece.
>>
>>     Seguramente estoy haciendo algo mal o me falta algo, me gustaría
>>     que quienes sepan de redes, aunque no miren el código, me
>>     expliquen si lo que trato de hacer es posible a este nivel,
>>     porque en una de esas estoy perdiendo el tiempo al santo botón.
>>
>>     *Es decir:*
>>
>>        1. ¿Un juego en red se puede hacer medianamente bién con estos
>>           recursos?
>>        2. ¿Está a mi alcance? o se necesita seber muuuucha cosa que
>>           yo no se?
>>        3. ¿Se puede hacer en python?
>>
>>
>>     *PD:*
>>     Cómo veo que en la lista se plantea una discusión sobre los tipos
>>     de juegos y además se que aveces suena mal un nombre como
>>     CeibalWar (mi primer experiencia con pygame), supongo que habrá
>>     gente en la lista a la que le rechine el nombre de JAMtank de
>>     este juego, por eso quiero aclarar que este jueguito, al igual
>>     que CeibalWar son simplemente un pretexto para aprender "cosas
>>     nuevas" sobre python. No necesariamente son objetivo de
>>     desarrollo, de hecho CeibalWar nunca lo terminé, pero me permitió
>>     hacer algo que funcionara con pygame. En el caso de JAMtank, he
>>     aprendido mucho más sobre pygame, mirando código de gabriel, con
>>     ayudas e ideas de pablo en la captura de eventos y actualización
>>     de imágenes en pantalla y un aporte gigante de andrés en lo
>>     referente a la red que hasta ahora había sido una zona muy oscura
>>     de python para mi. También aprendí mucho sobre hilos en python.
>>
>>     Gracias a todo esto, recién ahora me animaría a hacer un juego o
>>     actividad educativa sobre pygame y terminarlo, incluso, que
>>     permita la conexión en red, aunque un juego del tipo de JAMtank
>>     todavía no podría por obvias razones (origen de este mail), sin
>>     embargo una actividad en red por turnos (tipo juego de cartas o
>>     de mesa), pienso que funcionaría bien con lo poco que se sobre la
>>     red al día de hoy.
>>
>>     Además de esta aclaración, aveces los nombres de los juegos
>>     pueden inducir a confusiones, nadie que haya jugado al War
>>     (pienso yo), lo catalogaría como un juego violento, incluso
>>     JAMtank, difícilmente entraría en esta categoría según creo. Pero
>>     bueno, simplemente me interesaba aclarar que estos jueguitos son
>>     mis pretextos para aprender y no proyectos de desarrollos en si
>>     mismos.
>>
>>     *PD 2:*
>>     En cuanto tenga un lugarcito, haré una guia de uso de las clases
>>     utilizadas en este juego, donde muestre como hacer para integrar
>>     la transmisión de datos por la red con un juego o actividad
>>     desarrollada en pygame, de forma que al menos quienes deseen
>>     aprender sobre el tema tengan un punto de partida con ejemplo
>>     sencillo y práctico que funcione en la xo.
>>     Explicar esto probablemente sea más difícil que hacerlo andar,
>>     pero creo que será el mejor aporte que puedo hacer a quienes
>>     están aprendiendo.
>>
>>     *PD 3:*
>>     Un problema en pygame es la integración con gtk, de hecho en el
>>     sitio de pygame se dice claramente que no es buena idea.
>>     Es una lástima porque de poder utilizar gtk se resulven muchos
>>     problemas y se ahorra tiempo ya que se pueden utilizar los
>>     botones, menús, etc.
>>     El adaptador pygame_sugar hace esto esto, utiliza como canvas de
>>     la ventana de la actividad al juego hecho en pygame, traduciendo
>>     la captura de eventos entre gtk y pygame a través de un socket.
>>     Ahora, si se intentara hacer un juego o actividad compartida o
>>     multiplayer en red con pygame, la cosa se complica mucho porque
>>     además de tener que utilizar el adaptador pygame-sugar habría que
>>     construir un wrapper para telephaty (un segundo adaptador).
>>
>>     Todo esto además, tiene el inconveniente de que, (de poder
>>     hacerlo), solo funcionará sobre sugar, así que lo mejor es usar
>>     pygame separado de gtk y la red sin tomar en cuenta las clases de
>>     sugar. Además, considerando que en ciclo básico, (según tengo
>>     entendido), las máquinas vienen con sugar y gnome, me inclino a
>>     pensar que sugar prácticamente no se va a utilizar (en principio
>>     en ciclo básico), me parece que lo mejor es que las actividades
>>     que se construyan funcionen en gnome ya que en sugar se podrán
>>     ejecutar o adaptar si es necesario, pero si se desarrolla
>>     específicamente para sugar, despúes se puede complicar más para
>>     que funcionen en gnome, ya que en gnome hay que utilizar gtk
>>     directamente por ejemplo, mientras que en sugar se puede utilizar
>>     clases de sugar que en realidad reimplementan clases u objetos de
>>     gtk.
>>
>>
>>
>> _______________________________________________
>> Olpc-uruguay mailing list
>> Olpc-uruguay en lists.laptop.org
>> http://lists.laptop.org/listinfo/olpc-uruguay
>
>
> _______________________________________________
> Olpc-uruguay mailing list
> Olpc-uruguay en lists.laptop.org
> http://lists.laptop.org/listinfo/olpc-uruguay

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://lists.laptop.org/pipermail/olpc-uruguay/attachments/20100831/074e776d/attachment.htm 