Tras entregar la aplicación, entre una cosa y otra se ha parado el desarrollo desde hace algo más de un mes. Entre la redacción de la memoria, la preparación de la presentación, una semana que me quedaba en el trabajo, la quincena de la ingeniería… vamos, que no he hecho nada. Pero cara a la edición nacional del CUSL4, hay que retomar el desarrollo de la aplicación y que no se quede en vaporware.

Además, tengo que mejorar la aplicación para que los 16 alumnos de Diseño de Videojuegos tengan los menos problemas posibles en su uso. Vamos a ver un poco cuales son las futuras líneas de actuación:

Por un lado, hay que hacer pequeñas mejoras para una mejor usabilidad propuestas por mi tutor Manuel Palomo. Estas son:

• Añadir una barra de progreso durante la simulación de rondas en las competiciones. Si cargamos competiciones con bastantes competidores, la aplicación de la impresión de quedarse bloqueada.
• Modo de reproducción de las partidas. Es decir, le damos al play para que se vayan moviendo solas las fichas.
• Algunas ediciones menores en la interfaz para que sea algo más intuitivo.
• Como comentó Antonio García Domínguez cuando defendí el proyecto, añadir metadatos de alguna forma.

No son ediciones demasiado grandes en su mayoría, así que procuraré ir haciéndolas poco a poco. Por otro lado tenemos una mejora a mayor escala, y es la de hacer una re-escritura del núcleo de la aplicación, LibGuadalete, que es la biblioteca que hace que las partidas se muevan, simular los movimientos, etcétera.

Esta re-escritura la haré para que dicho núcleo sea más modular y escalable, permitiendo eliminar y añadir reglas para modificar la lógica del juego. Es un cambio bastante grande, y ya tengo pensado y analizado la forma que va a tener, así que a ver si me animo y lo comento por aquí.

Estas dos vías de desarrollo las llevaré haciendo uso del sistema de ramas (branches) que tiene Git, y que me permitirán hacer ediciones de forma independiente entre ellas

Happy hacking!

Esta mañana hemos expuesto los 6 finalistas de la edición local del CUSL, y este proyecto ha recibido el premio al Mejor Proyecto Libre de Comunidad de la UCA 2009-10, lo cual aunque no entraba en mis cábalas (imaginaba que me darían el de Docencia) es una gran alegría porque es otra valoración positiva del proyecto, sumándose a la matrícula de honor obtenida en la presentación como Proyecto Fin de Carrera.

El premio local lo ha ganado, como yo llevaba apostando semanas, Noelia Sales Montes con su proyecto WikiUnix, de lo cual me alegro muchísimo porque se de primera mano todo lo que ha trabajado en el proyecto, y se merecía un gran reconocimiento. Desde aquí mi enhorabuena a mi gran amiga por su gran proyecto

Por tanto, la cosa ha quedado así al final:

• Francisco Javier Santacruz López-Cepero con IdiginBPEL – Accésit del mejor proyecto científico
• Rosa María Durante Lerate con Learning wX – Accésit del mejor proyecto docente
• José Tomás Tocino García con oFlute – Accésit del mejor proyecto innovador
• Pablo Recio Quijano con Resistencia en Cádiz: 1812 – Accésit del mejor proyecto comuntario
• Luis Salvador Roa Rodriguez con Sim-conducción – Accésit del mejor proyecto de ocio
• Noelia Sales Montes con wikiunix – Premio local de la 4ª edición del CUSL

Enhorabuena a todos, y a seguir currando para la edición nacional, que tenemos que dejar la OSLUCA en buen lugar

El miércoles que viene, día 17 de Marzo, se entrega el premio local del CUSL4 en Cádiz, aprovechando el marco de la JOSLUCA5. Y bueno, ya se saben los 6 finalistas de dicha edición, y Resistencia en Cádiz: 1812 está entre ellos Así que el miércoles presentaré a los compañeros que quieran venir, mi proyecto y a ver que pasa.

La lista de finalistas es la siguiente:

• Francisco Javier Santacruz López-Cepero con IdiginBPEL
• Rosa María Durante Lerate con Learning wX
• José Tomás Tocino García con oFlute
• Pablo Recio Quijano con Resistencia en Cádiz: 1812
• Luis Salvador Roa Rodriguez con Sim-conducción
• Noelia Sales Montes con wikiunix

Enhorabuena a todos los finalistas, y a los no finalistas también, que también hay muchos proyectos de calidad

Como ya comenté anteriormente, el haber entregado mi PFC no quería decir que la aplicación fuera a parar el desarrollo, es más estoy trabajando en una modificación a nivel interna bastante grande. Me hubiera gustado haberla hecho antes, pero por falta de tiempo no ha sido posible así que estoy en ello ahora mismo.

Bueno, esta entrada no es para hablaros de esos cambios, si no para introducir un poco la aplicación para los alumnos de Diseño de Videojuegos, asignatura optativa de Ingeniería Técnica en Informática de Sistemas en la UCA. Al fin y al cabo esta aplicación se hizo para su uso en dicha asignatura, y como ya han empezado, pues para que tengan el material todo junto.

A continuación tenéis los enlaces de la última versión, la 1.1:

Paquete debian(Debian, Ubuntu, Guadalinex…) -> resistencia1812_1.1-1_all.deb
Fuentes para compilar ->resistencia1812-1.1.tar.gz

Recordad que como comenté en la publicación de la versión 1.0, si optáis por la instalación mediante el paquete Debian, PyCLIPS no está en los repositorios ni de Debian ni ninguna de sus derivadas, así que tenéis que bajároslos de la web del proyecto.

Tenéis unas instrucciones más completas en el manual. En dicho documento hay manual de instalación, de uso y de programación (a nivel muy simple).

Y bueno, para lo que queráis, estoy a vuestra disposición

Que de tiempo sin escribir por aquí. Pero entre terminar la aplicación, preparar la memoria y la presentación del PFC y todo, no he tenido tiempo para nada. Pero bueno, ya está entregado y este viernes pasado lo defendí con erótico buen resultado. La calificación que me dió el tribunal fue de 10, Matrícula de Honor, por lo que estoy bastante orgulloso tanto del trabajo realizado, como de haber terminado ITIS con esta guinda tan buena.

Este fin de semana me lo he tomado de descanso, y aunque estoy algo pachucho, a volver al trabajo cara al CUSL, para seguir mejorando la aplicación. Tengo bastantes entradas en la cabeza, y ahora tendré mas tiempo para ir escribiendolas.

Subo aquí los fuentes LaTeX de la memoria y de la presentación del PFC:

Memoria

Presentación

Y nada, ya iré publicando más cosillas por aquí. Por ejemplo tengo pensado comentar mis próximos objetivos, subir los manuales de usuario y demás… Ya ireis viendo

resistencia1812_1.0-1_all.deb
resistencia1812-1.0.tar.gz

Recordad que hace falta tener instalada la biblioteca PyCLIPS, que no está todavía en ningún repositorio Debian (a la espera de sponsor que estoy):

python-clips_1.0.7.348-1_i386.deb
python-clips_1.0.7.348-1_amd64.deb

Pues bueno, si os aburrís ya sabéis Siento no poder sacar un manual de usuario todavía, pero estoy bastante liado con la memoria del PFC, que voy bastante contrarreloj.

Con el fin de facilitar la visualización de como va el desarrollo de la aplicación, he generado un screencast con una pequeña ejecución del programa, para ir viendo el estado en el que se encuentra.

El video después del salto.

Perdón por la baja resolución, pero es el primer video que subía a YouTube

Primero, hace que el código más fácil de mantener, tanto por ti como por terceras personas. Si seguimos un esquema organizado a la hora de almacenar los ficheros, siempre será más sencillo hacer ampliaciones, que una nueva tercera persona pueda añadir nuevas features, o cualquier cosa similar. También hace la aplicación un poco más «estándar», de forma que cualquier persona pueda instalarla y utilizarla sin dar muchas vueltas.

Este último es bastante importante, porque de aquí a unos meses en la asignatura de Diseño de Videojuegos de mi facultad, está aplicación la utilizarán los alumnos para una de las partes que tiene la propia asignatura. Aún no se cuantos alumnos se han matriculado, pero el año pasado fuimos 27 personas, y este año puede que sean algunos/bastantes más. Esto implica que lo van a utilizar muchas personas, las cuales tienen distintos sistemas, distintos modos de trabajar… vamos que cada uno es de su padre y de su madre. Manteniendo una mala estructura, podría provocar errores de uso en la aplicación, y luego vienen problemas.

Hace una semana, la forma que tenía mi repositorio era la siguiente:

Y bueno, tampoco voy a entrar  en demasiado detalle que me canso Podéis ver perfectamente que el orden brillaba por su ausencia. En un mismo nivel de directorio tenemos las imágenes, los registros de partidas, o módulos, provocando confusión y bastante lío. Además, no hay forma de instalar la aplicación en el sistema, si no que la ejecutaba directamente y santas pascuas. Pero esta un poco duro, ya que cualquier pequeño cambio en esta estructura, podría hacer que la aplicación dejara de funcionar.

Así que tomé la decisión de reestructurarlo todo un poco, y hacer que sea instalable en el sistema de forma sencilla. El problema es ¿cómo? Es decir, ¿dónde meto los datos? ¿y los módulos? Una vez más, la maravillosa comunidad del software libre acudió en mi ayuda. Mi idea fue buscar una aplicación de corte similar a la mía en lo que a programación se refiere, es decir, algo en Python, con varios módulos distintos y demás, y a poder ser, que usara Glade.

En esa búsqueda di con Exaile, un reproductor / organizador de música que ya había utilizado con anterioridad. Esta aplicación está escrita en Python y utiliza Glade también. Además, incorporaba un Makefile para poder instalar la aplicación en el sistema de forma cómoda, y sabía que también estaba empaquetada en Debian, de forma que si seguía una estructura similar a la de este proyecto podría facilitarme esos pasos en el desarrollo.

Pues el resultado es el siguiente:

Ahora se ve todo con un poco más de sentido, ¿no? He obviado muchos ficheros, pero imagino que se entiende de forma básica. Además, ahora con el Makefile se puede instalar la aplicación, usando rutas de XDG para generalizar el acceso a dichas rutas. Por tanto, un poco a grosso modo, la aplicación instalada usaría los directorios:

• /usr/local/lib/resistencia1812 – Aquí se instalan los distintos paquetes Python de los que hago uso en la aplicación.
• /usr/local/share/resistencia1812 – La carpeta data/ que contiene las imágenes, fuentes, ficheros glade, de layout…
• /usr/local/bin – Crea el binario para la ejecución de la aplicación.

Además, añade en /usr/local/share un fichero para que se incluya en el menú del sistema, así como en la primera ejecución del programa se crea una carpeta ~/.resistencia1812 donde se genera el fichero de configuración, se copian los sistemas expertos, y donde se guardarán las partidas y torneos jugados.

Es un poco lío quizás, pero es una forma de ser coherente con el resto de aplicaciones instaladas en el sistema. De todas formas, imagino que esto tendrá fallos de concepto, y agradecería cualquier sugerencia en la organización, sobre todo en las rutas de instalación del sistema.

Un saludo, y gracias por leer el tochaco hasta el final

Es una biblioteca que utilizo en mi aplicación, y la cual aunque está muy bien, al autor no había realizado el empaquetado. Hablando con él hace tiempo me comentó que si quería, que lo hiciera yo. Bueno, hasta ahora no me motivé en intentarlo, pero gracias a la ayuda de mi jefe en AlQuimia, Javier Carranza, y al blog de un compañero del concurso, conseguí entender el proceso y la idea básica.

Podeis descargaros el paquete (en versión i386 o amd64)  en la página del proyecto PyCLIPS. Además, el paquete está a la espera en mentors.debian.net, para ver si alguien hace de sponsor del paquete y consigo que lo metan en Debian. Sería un pelotazo, ¿verdad?

Podría poner un pequeño tutorial de como hacer el paquete, pero creo que el blog de Shakaran que he enlazado antes es bastante claro y explicativo, no es cuestión de reinventar la rueda

Estoy implementando la interfaz para el torneo, y el comportamiento de los diálogos no está siendo bastante bueno que digamos. La cosa es que no se cierran cuando yo les digo, si no cuando les da la gana practicamente.

He reducido el problema al siguiente código sencillo:

El diálogo que utilizo el siguiente:

Un diálogo muy simple. Si mirais el código, lo que hace es lo siguiente: si se pulsa salir, se destruye el diálogo y se sale del bucle, y si se pulsa repetir, se esconde y vuelve a construirse el objeto.

Sin embargo, esas dos cosas las debería hacer antes del time.sleep(5), de forma que debería destruirse/esconderse en cualquiera de los dos casos, esperar 5 segundos, y luego salir o volver a mostrarse. Pero no, lo hace después de la espera de 5 segundos, y es que no tiene ninguna lógica, ya que la función run(), «bloquea» la aplicación en un bucle hasta que haya alguna respuesta del diálogo.

¿Por qué narices, si las funciones asociadas a los eventos de los botones, se ejecutan antes del sleep, el diálogo no se esconde? No lo entiendo, no se que narices pasa.

Si alguien me echa el cable, lo agradeceré de por vida XD De todas formas, postearé la solución cuando la encuentre.

————————————

SOLUCIONADO

Gracias a la lista de correo de pygtk, y en concreto a un italiano llamado Pietro Battiston (a quien le voy a poner un monumento en Cádiz) he conseguido arreglar el problema.

Como comentaba tenía pinta de  que no se consumían todos los eventos de la cola de eventos (ye-hee-a!)  en el momento oportuno. Parece ser que hay algo raro en pygtk que intenta aprovechar los bucles externos para optimizar o yo que se. El caso que lo que hay que hacer es disparar los eventos en plan «por cojones». Para eso hay que hacer uso de dos funciones de gtk: gtk.events_pending() y  gtk.main_iteration(). La primera función devuelve un booleano si hay eventos pendientes, y la segunda itera en la cola de eventos, disparándolos si fuera necesario.

Entonces, el código resultante sería: