<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Otra que se me ocurre tambien , que por ahi vi un recvfrom ( 1000 )
<br>
Si no hay otro seteo por ahi que no vi , hasta que no tengas 1000
bytes el recvfrom no te suelta.<br>
<br>
Si es asi tenes que tener alguna forma de normalizar el tamaño de lo
que lees , o sea si mandas coordenadas formatealas<br>
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<br>
sea el mio asi el recvfrom te suelta ni bien recibe 1 envio del
cliente.<br>
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<br>
enviar los datos tal cual lo haces hoy.<br>
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 <br>
juego como esta hoy ( nada de lo de las velocidades etc etc del mail
anterior ) te debe mejorar mucho el comportamiento.<br>
<br>
<br>
El 31/08/2010 10:06 p.m., Fabian Peña escribió:
<blockquote cite="mid:4C7DA71A.8090307@adinet.com.uy" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
Bue , una respuesta no muy trabajada. <br>
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.<br>
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.<br>
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.<br>
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 )<br>
Esos cambios ( de concepto , que son los peores ) te permitirian
mas independencia del rendimiento de la red.<br>
<br>
<br>
Salu 2<br>
<br>
<br>
<br>
<br>
<br>
<br>
El 31/08/2010 09:07 p.m., Flavio Danesse escribió:
<blockquote
cite="mid:AANLkTi=2ZiLqV_CLrL_5F8CR1JTVqixx-nJ3LMc_x14Z@mail.gmail.com"
type="cite">Suave con las respuestas por favor que me están
agobiando a correos.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<div class="gmail_quote">El 29 de agosto de 2010 19:38, Flavio
Danesse <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:fdanesse@gmail.com">fdanesse@gmail.com</a>></span>
escribió:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">Bueno, tengo el juego andando en la red
aunque me he encontrado con cosas bastante complejas.<br>
<br>
Gracias al código de ejemplo que me mandó Andrés, adapté mi
juego intentando seguir su modelo.<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
Como verán, deshabilité todos los disparos para simplificar
hasta resolver este tema. Para correr el juego deben
ejecutar el archivo <span style="color: rgb(0, 0, 153);">gtk_JAMtank_Ventana.py</span><br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<b>Es decir:</b><br>
<ol>
<li>¿Un juego en red se puede hacer medianamente bién con
estos recursos?</li>
<li>¿Está a mi alcance? o se necesita seber muuuucha cosa
que yo no se?</li>
<li>¿Se puede hacer en python?</li>
</ol>
<br>
<b>PD:</b><br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<b>PD 2:</b><br>
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.<br>
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.<br>
<br>
<b>PD 3:</b><br>
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.<br>
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.<br>
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).<br>
<br>
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.<br>
</blockquote>
</div>
<br>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Olpc-uruguay mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Olpc-uruguay@lists.laptop.org">Olpc-uruguay@lists.laptop.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.laptop.org/listinfo/olpc-uruguay">http://lists.laptop.org/listinfo/olpc-uruguay</a>
</pre>
</blockquote>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Olpc-uruguay mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Olpc-uruguay@lists.laptop.org">Olpc-uruguay@lists.laptop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.laptop.org/listinfo/olpc-uruguay">http://lists.laptop.org/listinfo/olpc-uruguay</a>
</pre>
</blockquote>
<br>
</body>
</html>