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

Mie Sep 1 09:34:48 EDT 2010

Hola,
   No tengo mucha idea en python pero puede ser algo como crear un bytearray
de largo indefinido, ingresarle los datos y después pasarle al socket el
largo del bytearray.

Una suerte de codigo puede ser esto:

new BA as bytearray[];
BA.addInt(PosX);
BA.addInt(PosY);
int lenght = BA.lenght;

Ariba flavio con ese LanTankJam :P

El 31 de agosto de 2010 23:29, juan carlos escobar samurio <
juanescobarsamurio en gmail.com> escribió:

> Me presento. Mi nombre es Juan Carlos Escobar Samurio, soy estudiante del
> 3º de Informática de la UTU. Este año nos enseñaron, aunque refiriendonos a
> Visual Basic 6, de que cada caracter Unicode (los cuales en Visual basic se
> declaran como string) ocupan un byte por caracter. Tengo la vaga idea de que
> en ese caso puede que multiplicando la cantidad de caracteres por el tamaño
> que ocupa un caracter en memoria podrían saber el espacio que ocupa en
> memoria la cadena que escribas.
>
> El 31 de agosto de 2010 22:54, Flavio Danesse <fdanesse en gmail.com>escribió:
>
> *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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>

-- 
Felipe Schneider

*"La complacencia es
ignorancia
gritar por gritar
es mas bien rebuznar"*
*Sin Dios - Leer para luchar*
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://lists.laptop.org/pipermail/olpc-uruguay/attachments/20100901/e5fa8ef8/attachment-0001.htm 