Ahora como esta cada object_id es un char. Esto implica que unicamente tendremos 256 posibles game objects por juego. Si contamos jugadores y tortugas me parece que alcanza, el problema viene si queremos modelar disparos como game objects, porque seguro que nos pasamos de 256 disparos en una partida.

En el after_success de Travis habría que correr doxygen. Una opción es usar mi imagen tinchou/envc, que lo tiene instalado.

Necesitamos poner toda la logica del juego de mover tortugas, hacer disparos, cambiar los estados del jugador dependiendo de un powerup.

Creo que lo mejor va a ser usar cmake porque anda con clion, que es un IDE que quiero probar jaja. Además, Pablo lo recomendó y en Travis también viene integrado (aunque no es el build system por defecto, que es Autotools).

Para nuestro caso con varios proyectos ver: https://cmake.org/examples/

Ahora andamos pasando mutex por ahi, cosa que Martin me recordo que no esta bueno. Por ahora anda todo, pero si queda tiempo podriamos hacer un GameRunnerMonitor.

Ya generé un request para que habiliten esta biblioteca: travis-ci/apt-package-safelist#1775

El editor debe generar mapas que el servidor debe leer y crear un juego.
Revisar bien la estructura que tendra el archivo y como parsearlo y crear los game objects.

Sistemas como Android usan una unidad de medida que se llama "dp" o device independent pixel. Gracias a esto, las aplicaciones no se ven muy chiquitas en pantallas con mucha resolución y muy grandes en el resto. La conversión a pixeles es simplemente multiplicando por la cantidad de dots per inch.

Veo ventajas en pensar nuestra arquitectura desde el principio con esto en mente.

https://en.wikipedia.org/wiki/Device_independent_pixel

Es algo que les pasa a muchos objetos:

• bala -> explota
• conejo -> muere
• tortuga -> muere
• power-up -> desaparece (picked up o timeout)

Actualmente es un step fijo de 20 milisegundos, pero podría recibir en el constructor un step distinto.

El server debe hacer logging usando una de las siguientes: log4cplus, glog o log4cpp.

Parece que cppunit es la biblioteca copada para testing.

TODO: setup

Primero haria circulos de distintos colores para ir probando. Recordar que necesitamos poner los sprites en el juego para la entrega final.

Waiting on travis-ci/apt-package-safelist#1397

Si juegan en single player ahora (con #54), van a ver que no se puede mover para los costados sin hacer un saltito.

Habría que implementar una normal y el tema del salto (o doble salto).

Sumado a los tipos obviamente hay que construir distintos renderers para los distintos objects.
Esto implica tocar el RemoteServerProxy, ClientProxy y el constructor de Renderers.

Agregar valgrind a Travis

Mas que solo configuracion del IPS, revisaria toda la configuracion que pide el tp y la liquidamos de una cuando se revise esto.

Deberíamos poner reglas muy estrictas de cpplint para tener un estilo uniforme.

Compartir un Gdoc o algo como para ir escribiendo algo a presentar el martes.

Hookeé el ganador en el PR #77 y te muestra un log en la consola de quién ganó, pero habría que mostrarlo por pantalla.

Por otro lado, solamente hay ganador del "juego", y todavía no hay ganador del "nivel" (un juego está compuesto de niveles).

Compartir un Gdoc o algo como para ir escribiendo algo a presentar el martes.