Planet

Tras un par de semanas escribiendo el anteproyecto para presentarlo en mi facultad, ya está hecho y presentado. La solicitud de estudio del mismo la presenté el 14 de Enero.En el anteproyecto he hecho una presentación del estado general de la cuestión: la necesidad tener mejores mecanismos de interacción y comunicación entre dispositivos multimedia, debido al crecimiento que ha sufrido el mundo en este ámbito durante los últimos años (teléfonos, videoconsolas o hasta despertadores...).En el anteproyecto también he querido darle una utilidad práctica dentro del mundo de la enseñanza, ya que al fin y al cabo este documento trata sobre "vender la moto" para que valoren de forma positiva que tu "pierdas" tu tiempo en hacer ese trabajo.En el documento también explico la metodología de trabajo que voy a seguir. En principio, RUP, aunque debido a la naturaleza modular del proyecto, que estará compuesto de muchas "piezas" que funcionarán juntas, puede que en alguna de esas "piezas" se utilice alguna otra metodología (como TDD, que personalmente a mi director de proyecto y a mi nos gusta bastante, pero no es aplicable en algunos de los elementos del proyecto).Cómo ya hice en mi post sobre selección de herramientas, en el anteproyecto también he hablado de los lenguajes y herramientas que voy a utilizar.Dado que el PFC lo estoy haciendo en mi ámbito de trabajo (el grupo de investigación ARCO) voy a disponer de algunos recursos, sobre todo hardware, que me permitirán desarrollar algunas cosas interesantes, como un servidor de medios de cámaras AXIS, otro para cámaras web que usen Video For Linux... y en fin, muchos aparatitos donde implementar partes de mi sistema de cara a una buena demostración.¡Ah! Se me olvidaba. El anteproyecto está hecho usando LaTeX, y la futura documentación del PFC también lo estará...

Después de la mejora de la página Web, y a pesar de disponer actualmente de poco tiempo para continuar con el proyecto, tenemos en mente algunos planes:

• Gracias a los comentarios de usuarios y amigos, nos hemos planteado una serie de tareas para mejorar la aplicación, aunque sin fecha fija de realización.

• En los próximos meses escribiremos un artículo para la revista ATI.

Hola a todos camaradas.
Estoy “la mar” de contento con el proyecto poco a poco vamos mejorando,aunque la cosa va lenta ( por culpa de mis estudios ).
He avanzado bastante pero queda muchisimo por hacer, Roma no se hizo en un día.
Avances:

• Por fin un menú
• Nuevos jugadores ( falta todavía por subir a la forja )  y por supuesto GPL.
• Mejorado los controles ( pero aún petan , hay que mejorar el autómata y organizar el spagetti formado después de varias madrugadas y noches desvariantes )
• Introducida formas de juego contra la máquina (pero aún no hay IA, que digo aún no se mueve la máquina, solo hay una clase Máquina ).

Retos para el Nuevo Año

1. Introducir un modo contra la máquina
2. Mejorar el búfer para las magias y movimientos especiales.
3. Introducir un modo de entrenamiento contra objetos y jugadores , a modo de tutorial.
4. Introducir un modo eliminatorio
5. Introducir un menú para controlas los controles del teclado o joystick totalmente funcional ( ahora esta dibujado )
6. MEJORAR LOS GRÁFICOS E INTRODUCIR EFECTOS guapos en todo lo que son las magias, movimientos etc..
7. Mejorar los controles hasta que no quede ningún Bug ( con el mando analógico del joystick maltratando y dando a lo loco a los botones a veces me casca.

Un saludo a tod@s.
NO NOS ATREVEMOS A MUCHAS COSAS PORQUE SON DIFÍCILES, PERO SON DIFÍCILES PORQUE NO NOS ATREVEMOS A HACERLAS.
Lucio Anneo Séneca

Ahora me encuentro mejorando la jugabilidad y sincrnnizando el escenario  y  su movimiento.
Tarea un poco peñazo
Sin embargo estoy avanzando bastante en estas vacaciones y me estoy centrando en perfeccionar lo que ya tengo hecho, para luego someterlo a una fase de pruebas , con mis amigos ( que es allí donde saco mis fallos y los mejoro )
He introducido una mejora en Jugabilidad, debido a que he tenido en cuenta dos cosas :  “El autómata” ya definido  y las pulsaciones de los mandos o teclados.
Un aspecto a mejorar es el buffer de los eventos, ya que debido a las prisas inexplicablemente se confunden los bufferes de ambos jugadores, una vez que termine este contratiempo y generalize las llaves , movimientos especiales y magias , tendre por fin una pequeña Beta.
Las colisiones es otra de las asignaturas pendientes ya que el sistema esta muy automatizado , en la clase Colisiones y cuando salta y golpeas pueden pasar cosas extrañas
NO NOS ATREVEMOS A MUCHAS COSAS PORQUE SON DIFÍCILES, PERO SON DIFÍCILES PORQUE NO NOS ATREVEMOS A HACERLAS.
Lucio Anneo Séneca

Por alguna extraña razón que investigaré en breve , mi proyecto de wxdev++ no compila si no le pongo un Winmain e incluyo windows.h . cosa extraña, pero la quiestión es que ahora funciona.
dejaré un fichero proyecto de wxdevc++ en el directorio gnu_xff/trunk.
ahí dejo unas cuantas imagenes:

Ahora me dedicaré a meter efectos de sonido y algún que otro personaje nuevo. que esta el juego un poco soso, y encima hay moviminetos que no tiene animación este personaje.
Un saludo a todos.
LA MAYOR PARTE DE LOS FRACASOS NOS VIENEN POR QUERER ADELANTAR LA HORA DE LOS ÉXITOS.
Amado Nervo

He  sacado un wiki que complementada con este blog espero que le sirva al usuario.
La wiki al igual que este blog estará en continuo desarrollo.  pensad en la wiki como el sitio ideal para tener conceptos de como se juega, se instala , etc.. y en el blog como un contenedor de noticias, detalles técnicos , inquietudes etc…
Enlace :
http://gnuxfreefighter.wikiole.com/Inicio
Un saludo a tod@s.
Lo difícil no es encontrar la verdad: es organizarla.

Ahora como debido al curro debo estar en windows todo el tiempo  usando por supuesto software libre  : wxwidgets junto con un IDE bastante bonito llamado  wxDevC++, que es como el devc++ de  toda la vida pero incluyendo un enterno tipo Borland para formularios , etc …
Yo he instalado la SDL , en el Dev c++ anteriormente  pero en wxDevC++ este es una maravilla , así que cuando haya pasado el proyecto a este entorno, a lo mejor ya me planteo hacer un manual de instalación en condiciones y una wiki, para ambos sistemas operativos ( windows y GNU/linux  ) .
Además  como ahora le estoy cogiendo un poco de mania a ubuntu , a lo mejor veís en próximos videos al juego rulando en otras distribuciones como  slax o  zenwalk.
GRANDE ES EL ARTE DE COMENZAR, PERO MAYOR ES EL ARTE DE CONCLUIR.
Henry Wadsworth Longfellow

Ante todo darle las gracias al principal Player que  ha participado conmigo de manera desinteresada, sin él no hubiese encontrado ni la mitad de los bugs y ahora mismo estaría seguramente con otro proyecto:
Gracias  Alfonso, conocido por nuestros amigos Alfonso Porras .
La técnica que he usado para las pruebas  es ir escribiendo un fichero  global “registro.txt” todo lo relevante que iba pasando: valores de los estados, acciones .. etc , de manera que cuando Alfonso y yo jugabamos  y el juego “petaba o hacia algo extraño” siempre podia echar el vistazo a ese fichero”.Así he encontrado centenas de bugs ( no exagero ) .
Mi gran fallo fue que me lancé muy pronto a programar, entonces me pregunté lo siguiente:
¿ Seré capaz de hacer un juego de lucha ?
Esta claro que me puse a programar sin haber echo un análisis  ni diseño  serio , sin documentar , simplemente guiándome de los pseudocódigos que fui escribiendo  un cuaderno.
La cosa se empezó a poner fea ,  fallos cuando te cubres , cuando saltas y aprietas otro botón , cuanto te agachas y le das adelante ….. etc , he tenido  que crearme un autómata , controlar el búfer del teclado , vaciarlo, en fin el que ve la documentación un poco lo verá.
Ahora mismo me encuentro un poco de parón y pensando como quitaré varios bugs  y comportamientos anómalos como el cubrirse  que no se comporta nada bien, como el movimiento del escenario ( que en versiones antiguas del juego se mueve , pero no muy bien que digamos ) …etc … a ver si me acuerdo y publico todos los bugs
Lo bueno que ya por fin una vez que realicé  un  análisis y  un diseño  medianamente buenos y ayudado por el bendito Doxygen , me han echo que  “yo mismo” ,imagínate el lector de mi código ( pobre mortal ….) ,entienda el código.
Moraleja y consejo de un pobre aprendiz de programador o violador de segmento:
Para un proyecto medianamente grande: Análisis y Diseño obligatoria, documentar te ayudará. Y sobre todo a la hora de las pruebas buscarse a un amigo o alguien ajeno a tu proyecto  para que pruebe tu software.
Un saludo a todos.
PREFIERO EL BASTÓN DE LA EXPERIENCIA QUE EL CARRO RÁPIDO DE LA FORTUNA.
Pitágoras

Como comentaba en la entrada anterior he podido subir el vídeo a youtube donde controlo una bombilla con una placa relé bastante simple, Mister House y las librerías desarrolladas.
Espero que os guste.

Tras unas semanas de aunar y aclarar ideas con mis tutores (y cotutores!!) de proyecto, y determinar así los objetivos en relación a la idea que tenemos de como mejorar eOPSOA, llegó el momento de realizar la primera aportación a este blog. Como bien ha comentado David, con objetivo de poder terminar mi PFC y poder aportar así mi granito de arena a eOPSOA, me voy a ocupar de investigar cómo integrar la herramienta de testeo funcional Marathon al proyecto comentado. Para quién a Marathon le suene a la famosa trilogía de videojuegos, o simplemente a la conocida prueba atlética de resistencia, comentar que Marathon es una herramienta de libre distribución, la cual podemos extender fácilmente y que nos ayuda en el desarrollo de conjuntos de pruebas automatizadas para aplicaciones Java / Swing . Marathon nos ofrece un entorno integrado en el que puede crear conjuntos de pruebas. Además, incluye un grabador, un reproductor y un editor de scripts para facilitar la automatización de pruebas. Marathon se utiliza principalmente para la automatización de pruebas funcionales, aunque también puede ser utilizado para crear conjuntos de pruebas para desarrolladores. Cuando se lleva tiempo realizando pruebas en los diferentes proyectos entregados, nos damos cuenta que hay cosas que son particularmente difíciles de probar de forma automática y otras donde ocurre todo lo contrario, al existir medios suficientes para abordar la prueba automática. Un ejemplo claro son las interfaces gráficas de usuario. Para la ejecución de pruebas de forma automática existen numerosas herramientas. No ocurre lo mismo para la generación de los casos de prueba, por ello intentaremos con esta herramienta abordar los objetivos que no se pudieron completar el año pasado (debido a que la herramienta elegida no cumplió las expectativas creadas), con la incorporación de automatización de pruebas, en la parte de Generación y Ejecución de pruebas de eOPSOA. Más adelante, iremos ampliando con más detalle la idea que perseguimos en el proyecto. Finalmente, no quería terminar este primer cometario, sin dar las gracias a todas las personas que me están ayudando en el desarrollo de mi propósito. Especialmente quería agradecer a mi compañero David Castellanos, la ayuda, disposición y paciencia mostrada, desde el primer día (23 de octubre) que se enteró de mi incorporación al equipo. Gracias deivis!!