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

Mar Ago 31 21:54:05 EDT 2010

*Gracias a ambos.

Pregunto:*

¿Alcanza con mandar una cadena de longitud fija en cada envío?
¿Cúanto ocupa un caracter? Los Unicode, ocupan desde 2 a 4 bytes? no? Cómo
se cuanto ocupará mi cadena?

El 31 de agosto de 2010 22:30, Fabian Peña <fapenia en adinet.com.uy> escribió:

>  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>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 listOlpc-uruguay en lists.laptop.orghttp://lists.laptop.org/listinfo/olpc-uruguay
>
>
>
> _______________________________________________
> Olpc-uruguay mailing listOlpc-uruguay en lists.laptop.orghttp://lists.laptop.org/listinfo/olpc-uruguay
>
>
>
> _______________________________________________
> Olpc-uruguay mailing listOlpc-uruguay en lists.laptop.orghttp://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/250b4278/attachment-0001.htm 