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

Fabian Peña fapenia en adinet.com.uy
Mar Ago 31 21:06:34 EDT 2010


  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

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


More information about the Olpc-uruguay mailing list