[Olpc-uruguay] JAMtank (sólo para divertirse)

Flavio Danesse fdanesse en gmail.com
Mie Ago 4 18:20:50 EDT 2010


Alguien sabe como hago para pasar por un socket otra cosa que no sea una
cadena de texto ??



El 29 de julio de 2010 22:13, Flavio Danesse <fdanesse en gmail.com> escribió:

> Bueno, la cosa está compleja.
>
> A ver, como primera medida voy a dejar de lado por completo a sugar que
> lejos de ayudar complica y bastante y voy a desarrollar todo para correr
> sobre gnome.
>
> La idea es que el usuario ejecute el juego y elija entre crear un juego en
> red o conectarse a un juego ya existente en la red.
>
> Cuando crea el juego en la red, debe levantar el juego y un servidor UDP.
> Quien se conecte, debe conectarse al servidor del primero y levantar su
> juego.
>
> Acá ya hay un problema porque cada usuario tendría 2 bucles corriendo a la
> vez con lo cual hay que hacer threading, entonces:
>
> ¿deben correr en hilos separados el juego y el socket?
>
> Estoy utilizando la clase SocketServer.BaseRequestHandler sobreescribiendo
> el método handle() para escuchar y procesar las solicitudes mediante
> serve_forever()
>
>
>
>
> El 29 de julio de 2010 10:36, Flavio Danesse <fdanesse en gmail.com>escribió:
>
> Ok, un montón de cosas a considerar sin dudas. Voy a seguir tu guia a ver
>> como sale, gracias !!!
>>
>>
>>
>> El 28 de julio de 2010 23:27, Pablo Moleri <pmoleri en gmail.com> escribió:
>>
>>> 2010/7/27 Flavio Danesse <fdanesse en gmail.com>
>>>
>>>> No se exactamente que modelo seguir para implementar la red. Se como
>>>> hacerlo por socket y como utilizar thelepathy de sugar, pero necesito un
>>>> marco conceptual para seguir la implementación.
>>>>
>>>
>>> Las premisas son que es un juego muy dinámico y pueden haber varios
>>> jugadores conectados, con estos supuestos me parece que es escencial que la
>>> comunicación sea lo más liviana posible para que permita un intercambio de
>>> mensajes fluidos. Otra cosa que es conveniente es que no haya un "host",
>>> sinó que la comunicación sea entre todos, para que no haya problemas si se
>>> pierde la comunicación con el host.
>>>
>>>
>>> Utilizando el modelo telepathy/d-bus, siempre sabemos cuando alguien
>>> entra o sale y se pueden emitir *señales* que le llegan a todos (incluso
>>> a quien las manda).
>>>
>>> Haría una comunicación de este estilo:
>>> 1. Una vez cada 1/2 segundo todos mandan una señal que indica su color de
>>> tanque, su posición (x,y), su dirección, su velocidad.
>>> 2. Cada vez que alguien dispara una bala manda una señal indicando la
>>> coordenada de origen y la dirección.
>>> 3. Cada vez que alguien es interceptado por una bala de un enemigo, manda
>>> una señal *acusa*ndo su posición y quien le pegó.
>>>
>>> Responsabilidades:
>>> i. Cada computadora está encargada de dibujar todos los tanques en su
>>> pantalla y simular su movimiento utilizando las coordenadas, la dirección y
>>> la velocidad informadas.
>>>
>>> Cosideraciones:
>>> > Habría que limitar la cantidad de balas por segundo que se pueden
>>> disparar para no sobrecargar la red.
>>> > Se simula el movimiento de cada tanque hasta que llegue un nuevo dato
>>> que indica su nueva posición, su nueva dirección y su nueva velocidad.
>>> > Tanto los tanques como las balas pueden no estarse dibujando en la
>>> posición adecuada, ya que desde que se emite el dato hasta que la otra
>>> computadora lo procesa puede haber un pequeño lapso de tiempo.
>>>
>>> Otras consideraciones:
>>> > Para disminuir las impresiciones del juego en red y simplificar la
>>> implementación, puede hacerse que incluso la computadora que realiza el
>>> disparo dibuje la bala recien cuando le llega la señal, ya que las señales
>>> llegan incluso a quien las manda. En otras palabras, cuando un tanque
>>> dispara, manda un mensaje indicando el disparo (pero no dibuja la bala) y
>>> cuando le llega a si mismo el mensaje del disparo, lo dibuja en la pantalla.
>>>
>>> Otras consideraciones más:
>>> > Con este modelo, alguien podría hackear su versión para que las balas
>>> no lo afecten, haciendo su tanque invensible. Por más que sea un defecto, me
>>> parece un desafío interesante para un niño  :)
>>>
>>>
>>> _______________________________________________
>>> 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/20100804/da8ed53f/attachment.htm 


More information about the Olpc-uruguay mailing list