[Olpc-uruguay] JAMtank (sólo para divertirse)
Flavio Danesse
fdanesse en gmail.com
Jue Jul 29 21:13:37 EDT 2010
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/20100729/c5e7ed8e/attachment.htm
More information about the Olpc-uruguay
mailing list