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

Mar Ago 31 21:30:30 EDT 2010

  Ta , dale bola a mi segundo mail nomás, que lo mire mejor y ( nunca 
hice eso en python ) casi seguro
que es el recvfrom que te suelta cada 1000 bytes y todo va a los saltos.

El otro tema dejalo para mas adelante :-P

El 31/08/2010 10:19 p.m., Fabian Peña escribió:
> 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
>
>
> _______________________________________________
> 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/014697ac/attachment.htm 