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

[Flavio Danesse]

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.
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://lists.laptop.org/pipermail/olpc-uruguay/attachments/20100831/2788ff07/attachment.htm