Más de una vez algún alumno me planteó la intención de hacer un video juego como trabajo final de carrera en FIUBA pero hasta el momento he tenido la oportunidad de dirigir solo un trabajo de este tipo. Sin embargo ese único caso, el video juego Fira de Facu Gertsner y Mati Feld, me permitió entender varias cuestiones del tema.

Hacer un juego implica al menos 3 cuestiones. En primer lugar tenemos la idea, el argumento, las reglas, en gran medida un trabajo creativo. En segundo lugar tenemos la parte artística: imágenes, sonido, animaciones, etc, lo tiene un parte creativa pero también una parte técnica. Finalmente está la programación. Podríamos ir un poco más allá y pensar en cuarta cuestión: la coordinación de tres cuestiones anteriores. La importancia y complejidad de cada una de estas cuestiones varia dependiendo del tipo de juego. Claramente la tarea de un ingeniero pasa por la programación pero también podríamos agregar la gestión.

Cuando un alumno se plantea hacer un juego como trabajo final debe considerar estas cuestiones. Asimismo, dependiendo también del tipo de juego, la programación puede no ser una tarea trivial. Otra vez dependiendo del tipo de juego puede ser necesario aprender algún lenguaje y/o framework particular y la mayor complejidad aquí no pasa por aprender el lenguaje/framework, sino por el hecho de tener que estimar y hacer un plan de trabajo sin tener un conocimiento del lenguaje/framework.

Teniendo en cuenta todo esto yo veo al menos 3 formas de plantear el trabajo final:

1. La primera opción es tomar el paquete entero y hacer «todo», lo digo entre comillas porque la parte de artística podría hacerlo el alumno o bien la podría subcontratar pues es una cuestión que excede a lo que se espera de un estudiante de ingeniería.
   
2. Una segunda opción es aprender el lenguaje/framework en la previa, o sea, dejar esa parte de investigación/aprendizaje fuera del alcance del trabajo final. En términos del esfuerzo total, la cuestión pareciera no cambiar pero hay una diferencia grande: si nos mandamos de una a hacer todo (opción 1) corremos el riesgo de armar un plan para X tiempo/esfuerzo y que luego termine llevando mucho más. En cambio, si hacemos la investigación en la previa, eso nos debería dar una mayor certeza para la planificación del proyecto disminuyendo así los riesgos de desvio.
   
3. Otra opción podría ser no hacer el juego en sí, sino hacer un prototipo que si bien puede sonar a poco, puede igualmente ser un trabajo considerable si hay que aprender un framework como Unreal.

En lo personal creo que en todos los casos el alcance del trabajo debe incluir la distribución del juego, no necesariamente en un marketplace de juegos pero al menos en una página web donde resulte accesible al público en general.

Aclaro: lo que menciono aquí es una opinión personal, o sea: no es una posición oficial de la institución.

El lunes pasado fue la presentación formal Fira, el trabajo final de carrera de Facundo Gertsner y Matias Feld y del cual fuí director. La presentación la hicimos presencialmente en la facultad acorde a la normativa vigente pero adicionalmente fue transmitida por Twitch, donde quedó disponible para posterior visualización.

Comparto algunas métricas que pueden resultar de interés para otros alumnos:

• 23 iteraciones de desarrollo
  
• Más de 860 horas de desarrollo
  
• Más de 600 pruebas automatizadas
  
• ~1300 commits
  
• Más de 20 GB de assets

A estos números hay que contextualizarlos considerando:

• Desde que comenzamos a hablar sobre el trabajo con los alumnos (fines de 2020) hasta que se presentó el trabajo (mazo 2022) pasaron más de 14 meses.
  
• Adicionalmente a las horas de desarrollo, los alumnos invirtieron una cantidad no menor de horas en capacitación e investigación, principalmente dedicadas a aprender Unreal (el motor sobre el que está construido el juego)

Algunas otras cuestiones que me parecen interesantes para destacar por no ser tan habituales en los trabajos finales de carrera:

• Matias y Facundo decidieron aprovechar el trabajo final de carrera para comenzar un emprendimiento comercial. Esto resulta muy interesante pero trae también algunos desafíos como ser el hecho de regular las potenciales tensiones entre el aspecto comercial y el aspecto académico. Ejemplo: comercialmente el producto podría requerir más tiempo de desarrollo que el inicialmente estipulado; al mismo tiempo desde el punto de vista académico pretendemos que los alumnos terminen su formación en un tiempo acotado. Es justamente en este tipo de cuestiones donde el director debe guiar a los alumnos.
  
• Al momento de finalización del trabajo académico, el producto no se encontraba comercialmente finalizado pero sí había tenido una validación de mercado (como director no habría podrido dar el trabajo por finalizado sin esta validación). El juego tuvo ~400 descargas de la versión beta y más de 25 mil visitas a la página de promoción.
  
• El desarrollo de un juego de este tipo requiere del desarrollo de piezas artísticas (imágenes, texturas, animaciones, sonidos, música, etc). Esto implicó que parte del trabajo de los alumnos incluyera la gestión con los artistas/profesionales proveedores/creadores de estas piezas. Este trabajo de gestión es una tarea habitual para un ingeniero pero resulta algo casi inédita en un trabajo final de carrera.

Bueno, esto es todo sobre Fira. Felicito a Matias y Facundo por el trabajo realizado y les agradezco por haberme permitido ser parte de esta aventura.

En las últimas semanas he recibido varias consultas sobre trabajos finales de carrera en FIUBA. Más allá de siempre recomendar dejar en claro el objetivo personal del trabajo, en estas ocasiones me encontré recurrentemente explicando una cuestión sobre la definición del trabajo y la presentación del proyecto. Lo escribo aquí para futuras referencias.

El primer paso formal del trabajo final de carrera es la presentación del plan de proyecto a la comisión curricular para su aprobación. Este un paso clave, y que a mi entender, en ocasiones subestimado. Si nos quedamos cortos en el nivel de detalle del plan de proyecto, corremos el riesgos que la comisión curricular no apruebe el proyecto. Al mismo tiempo si ponemos mucho nivel detalle sin tener suficiente conocimiento del dominio, la tecnología y el contexto, corremos el riesgos de estar embarcándonos en un trabajo mucho más extenso de lo esperado.

Entonces he aquí la clave: la formulación del plan de proyecto debe proveer el suficiente nivel detalle para que la comisión lo apruebe, pero para proveer ese nivel de detalle es necesario que tengamos suficiente conocimiento del dominio del proyecto, la tecnología que utilizaremos para la solución y el contexto del proyecto. Esta situación tiene distinto grado de «gravedad» en cada carrera/institución. En algunos casos no se pide tanto nivel de detalle en el plan de proyecto porque se espera que el proyecto incluya el esfuerzo de descubrimiento/análisis/requerimientos. Del mismo modo, en los casos en los que se pide mayor nivel de detalle se está, en cierto modo, forzando que al menos una parte importante del descubrimiento/análisis se realice previo/durante a la formulación del proyecto.

Si quisiéramos poner esto en términos formales (o de industria) podríamos pensar estas dos situaciones: en un extremo en una planificación adaptativa y en el otro en una planificación «up-front». Al mismo tiempo si analizamos los trabajos finales desde una perspectiva de gestión de proyectos tenemos que generalmente los reglamentos establecen de forma fija los recursos/esfuerzo/presupuesto del proyecto (cada alumno debe trabajar X cantidad de horas como mínimo). También se establece un tiempo calendario máximo para completar el proyecto una vez aprobada la propuesta (por ejemplo 1 año calendario). De esta forma la dimensión variable del proyecto termina siendo el alcance y ahí la paradoja: en un planificación «up-front» muchas veces los alumnos (y también las empresas) intentan fijar un alcance, teniendo así las tres dimensiones del proyecto fijas de entrada: alcance, tiempo y recursos. Típico proyecto «llave en mano» con las ¿pocas? chances de que el proyecto llegue a buen puerto. Es así que nos encontramos con alumnos haciendo interminables trabajos finales y algunos otros que nunca siquiera lo empiezan.

La clave entonces podría estar en plantear un alcance variable, lo cual a mi parecer va mucho mejor con una planificación adaptativa que con una planificación «up-front».

En términos formales, y dependiendo de las particularidades de la comisión curricular (o el organismo que sea que deba aprobar el plan de proyecto), puede que la mayor parte descubrimiento/análisis debamos hacerla antes o después de la aprobación del plan de proyecto. En base a lo que he hablado informalmente con miembros de las comisiones curriculares de FIUBA me queda la sensación de que en el caso de la Ingeniería el descubrimiento/análisis hay que hacerlo en su mayor parte antes de la presentación del plan de proyecto. En el caso de la Licenciatura el descubrimiento/análisis es en su mayor parte realizado una vez aprobado el plan de proyecto.

En este sentido, mi recomendación para los alumnos de Ingeniería en Informática es:

• Conseguir un director y comenzar a trabajar
• Presentar la propuesta formal una vez avanzando un porcentaje de ~30% del proyecto
• Obviamente esta estrategia tiene el riesgo de avanzar en el trabajo y que luego la comisión no apruebe el plan de proyecto. Justamente es aquí donde resulta clave el rol del director para minimizar la chances de que el proyecto sea rechazado.

En las carreras de informática en Fiuba no hay, a mi entender, una definición lo suficientemente clara sobre los trabajos finales de carrera. Hay documentación, pero no hay una materia (como ocurre en otras universidades) donde los alumnos sean asesorados o tengan algún tipo de seguimiento. El alumno debe encontrar un director para su trabajo y acordar con él un tema.

En este contexto suelo recibir varias consultas de los alumnos y uno de los primeros consejos que les doy es que dejen en claro el objetivo personal que persiguen con el trabajo. Con esto no me refiero a la temática del trabajo sino a su expectativa personal, doy tres posibles ejemplos:

• Recibirse y listo: la realización del trabajo final es requisito para recibirse y puede que el alumno quiera puntualmente eso. No tiene ninguna expectativa adicional. En este sentido el trabajo final es, en términos de transcendencia, como cualquier otro trabajo práctico de la carrera: una vez evaluado, ha cumplido su objetivo: la aprobación; entonces se archiva y nunca nadie lo vuelve a tocar.
  
• Iniciar un emprendimiento: dado que el trabajo final requiere típicamente al menos un cuatrimestre de trabajo, puede ser una oportunidad interesante para aprovechar y hacer que ese trabajo final sea el puntapié inicial de un potencial emprendimiento.
  
• Hacer un aporte a la comunidad: otra opción interesante para aquellos con intención de que su trabajo final tenga transcendencia más allá de la aprobación de la carrera es hacer algún tipo de aporte ya sea desarrollando una aplicación para una alguna institución, colaborando con un proyecto open source existente o incluso generando un nuevo desarrollo open source.

Esta es una clasificación muy genérica que no cubre todos los casos. De hecho mi propio trabajo final no entra en ninguna de estas categorías. De todas formas creo que plantearse la pregunta de las expectativas personales puede ser muy útil para definir el tema y sobre todo para armar el plan de trabajo.