Se acerca junio, acechando entre los arbustos. Ayer yo había pasado por la biblioteca de proyectos para echar un ojo a otros proyectos de Lobo. Realmente, es difícil hacer documentación para algo que no sea una aplicación de ventanas para gestionar un videoclub. Y yo nunca estuve a favor de hacer documentación “porque sí”.
Ví tres tomos, los tres de videojuegos. Uno era del que hizo Vórtice en la técnica, que a muchos no os sonará, pero cuando yo hice mi proyecto, era uno de los pocos referentes que teníamos. También estaba Shift, de un alumno que lo iba a presentar a la par que nosotros pero que por motivos de trabajo lo tuvo que alargar dos años. El proyecto no ha cambiado mucho esos dos años. Aunque, eso sí, ha implementado una física sencillita (no exenta de fallos, me temo :P).
Pero lo que realmente le honra es haberlo publicado bajo licencia GPL, dando el código fuente, los ejecutables, la documentación, la presentación… todo. No se qué le pasa a la gente, especialmente con sus PFCs que lo tratan como si fuera secreto de sumario. Y la mayoría de las veces se trata de proyectos incompletos que no innovan en nada. Caray ¿ni siquiera una página web? ¿tan poco orgulloso estás de lo que has hecho?
En fin, me alegró ver mucho el Shift terminado, y he de decir que la documentación está muy bien para ser un juego, que siempre es algo peliagudo de documentar. Esperemos que los proyectos de la superior me dejen tan buenos recuerdos.
- Documentando
- Consejos para llevar mejor el PFC
- Ingeniería del Software RPG
- Stunt Challenge: el regreso
- Querido diario
Berto dice:
Yo también hice, mas bien intenté, un “juego” (Survivor) como PFC con Lobo en la técnica, si no lo encontraste en la biblioteca puedo mandártelo en PDF. Me estoy encontrando con el mismo problema que tú para realizar ahora el de la superior, y es que te sales de la típica aplicación de gestión que se ajusta a la perfección a Métrica3 y no encuentras un mísero ejemplo…
Miguel Herrero dice:
Tienes razón, cuando yo hice el PFC, los míticos eran el Vórtice y el Survivor
(juro que iba a ponerlo, pero no me acordaba del nombre).El problema como tú dices es que imponen un formato mucho más estricto que en la técnica, y adaptarlo a un juego (o a un motor, como es mi caso) resulta complicado.
Aunque he de decir, que de los tres proyectos de Lobo que consulté: Battle Arena (del de Vórtice), ProgBots y Shift, ninguno se adaptó mucho a las normas (por ejemplo, con el tema de la metodología) y aún así, la nota más baja era un 9′5…
Así que ahora intentaré hacer un documento medianamente entretenido sin sentirme demasiado forzado a hacer ‘casos de uso’ por ejemplo.
Por cierto, Berto ¿cual es tu proyecto?
Berto dice:
Es lo que yo he decidido, para el Survivor nos centramos justo en eso, en hacer una documentación amena y entrenida, y el tribunal nos lo llegó a valorar

El proyecto es de nuevo un juego, también multijugador pero en este caso educativo. Está implementado en C# con gráficos 2D hechos en Flash (limitación impuesta por el diseñador), es más, podemos decir que usamos el FlashPlayer como motor gráfico. Vamos un engendro… de momento funciona. Si me acuerdo más adelante linko la web.yayo dice:
Dentro de un par de años cuando hagas documentación de verdad, te vas a cagar en la @@$%& que parió al que inventó los proyectos de fin de carrera. Además, el día que empieces a trabajar te vas a acordar de todos los muertos del que redactó todo el chamullo de trolas, mentiras e invenciones varias que llevas escuchanding en clase desde que empezaste la carrera… Te lo dice un Team Leader ^^
Omareto dice:
“…Realmente, es difícil hacer documentación para algo que no sea una aplicación de ventanas para gestionar un videoclub…”
Este mismo inconveniente me encontré yo. Toda la carrera documentando aplicaciones de gestión, y luego “perdidos” cuando hay que documentar software de sistemas (una máquina virtual en el caso de mi PFC).
No creo que sea una cuestión de que un tipo de software es más difícil de documentar que otro, sino más bien de hábito, que no se adquiere en la carrera.
P.D.: Como “ejercicio mental” piensa que casos de uso le pondrías a una máquina virtual.
Miguel Herrero dice:
Es que los casos de uso yo los mapeo diréctamente a formularios
También (tanto en tu caso, como en el mío) ¿cómo demonios hacemos pruebas exhaustivas? como mucho probaremos todo lo que podamos…
Omareto dice:
Las pruebas yo no tengo muy claro como las voy a hacer, pero seguramente adaptaré las típicas que se hacen en los procesadores del lenguaje (test tipo A, B, C, etc…) al caso concreto de una máquina virtual; además de alguna prueba de rendimiento. Pero las pruebas para una máquina virtual las veo bastante más claras que para un motor gráfico.
“Pruebas exhaustivas” es un término un poco “vago”, al final es adaptarlo al software que estemos desarrollando, que se reduce seguramente a probar todo lo que podamos como dices, y todo lo que se nos pase por la cabeza, documentándolo, sin seguir un método claramente definido.
Sería ideal que existiera algún documento/libro con baterías de pruebas que se debieran hacer según el tipo de software, al menos el más habitual (no sé si existe ya).
El tema de las pruebas da para una asignatura.
KnudoW dice:
Alguno de todos esos proyectos de juegos tienen la documentación online como el Shift y el grandioso juego de coches Stunt Challenge (:P) ??
Es para tenerlas a mano y poder mirarlas y compararlas sin prisa ni pausa… me dais miedo con los comentarios…



