[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