Práctica

Para el uso de los puestos de laboratorio, el alumno debe haber solicitado su cuenta siguiendo los procedimientos correspondientes. En la Facultad de Informática las prácticas que se realizan son a menudo digitales (software, documentación, etc.) y se utilizan repositorios con sistemas de control de versiones para almacenarlas y trabajar sobre ellas, al mismo tiempo que los profesores tienen visibilidad sobre el estado actual y todos los cambios que cada alumno ha ido realizando.

Lo deseable es que estos repositorios sean privados al menos durante el periodo de realización de las prácticas, para evitar plagios y problemas con otros grupos de alumnos. Sólo los compañeros del mismo grupo y los profesores tendrán acceso a los repositorios, no sólo para evaluar el resultado final sino que, para hacer un seguimiento detallado de todos los cambios, puede ser necesario dar de alta a los profesores como administradores de las “organizaciones” de cada grupo de alumnos.

Las revisiones y calificaciones se realizan sobre el grupo en su conjunto, en tiempo y forma, asumiendo que se documente y acredite un reparto justo del trabajo. En caso de que alguno de los alumnos no haya participado lo suficiente, puede sufrir una penalización correspondiente o directamente no obtener puntuación alguna por dicha práctica.

Repositorios

Para las prácticas más sencillas es suficiente con usar Google Drive como repositorio tanto para la documentación como para otros ficheros que queramos subir e ir “versionando” a medida que trabajamos.

Para las prácticas donde es necesario hacer un seguimiento del código fuente, se suele utilizar GitHub, un entorno más profesional donde documentar el proyecto, mantener distintas ramas y versiones del código, etc. El cliente GitHub Desktop es suficiente para trabajar con este tipo de repositorios, aunque alumnos alumnos prefieren GitKraken.

Cada repositorio de GitHub se recomienda que ocupe menos de 5 GB (idealmente menos de 1 GB para mayor agilidad). Los ficheros deben ocupar menos de 100 MiB (si superan 50 MiB ya te dan un aviso), a excepción de los lanzamientos (releases) cuyo límite es 2 GiB. Mediante el fichero de configuración .gitignore nos aseguramos de que sólo se suban al repositorio aquellos ficheros fuente estrictamente necesarios.

En videojuegos es habitual trabajar con ficheros binarios de mayor tamaño, para lo cual se necesita la extensión Git LFS o Git Large File Storage (habiendo instalado antes la versión de Git de escritorio), que mejora la comunicación porque mantiene los ficheros grandes en un almacén aparte y en el repositorio sólo utiliza “punteros” a estos ficheros. Ese almacén aparte tiene un límite de 2 GB en las cuentas gratuitas. Mediante el fichero de configuración .gitattributes nos aseguramos de dar el tratamiento de “fichero grande” únicamente a los ficheros que lo necesitan.

A pesar de todo esto, los límites de espacio en GitHub suelen obligarnos a tener que alojar partes del proyecto (carpetas enteras de contenido de terceros, que no van a sufrir cambios) a Google Drive, teniendo que subirlas y bajarlas manualmente cada vez que sea necesario.

Como alternativa a GitHub tenemos -también de Microsoft- Azure Repos. Se trata de un servicio que forma parte de la gran oferta de Azure DevOps y que tiene la ventaja de ofrecer 10 GB de espacio gratis (compartidos con un máximo de 5 usuarios) que pueden usarse íntegramente como repositorio Git con almacén LFS. El tamaño máximo del push “normal” es de 5 GB, límite que no tenemos trabajando con LFS. Aunque como cliente lo natural es usar Visual Studio Team Explorer u otras extensiones de Git para Visual Studio, se puede usar GitHub Desktop o clientes de pago especializados para manejar recursos pesados como Anchorpoint.

Se evita trabajar directamente con el control de versiones de Git integrado en Unreal Engine porque está algo obsoleto y no permite bloqueo de ficheros. Pero para este entorno de desarrollo existe UEGitPlugin de Project Borealis, basado en UEGitPlugin de SRombauts, que funciona bastante bien.

Otra alternativa, no sólo a GitHub sino a Git en general, es Perforce. Si cuentas con tu propia infraestructura, es posible montar un repositorio gratis (compartido con un máximo de 5 usuarios) y se trata de una de las herramientas más utilizadas para videojuegos en el mundo profesional.

Sea cual sea el repositorio utilizado, allí debe encontrarse la documentación, el código fuente y los recursos del proyecto, y cualquier ejecutable final que generemos.

Documentación

La documentación de las prácticas es una cuestión importante. No se trata sólo de documentar el resultado final, sino de también documentar el diseño y el proceso de desarrollo.

Lo habitual cuando el repositorio es Google Drive es aprovechar Google Docs para documentar, la aplicación ofimática de Google Workspace.

Cuando se utiliza Markdown, como es habitual en los repositorios de GitHub o Azure Repos, debe haber un fichero README.md en la raíz del repositorio que contendrá:

• Datos del grupo de alumnos.
• Enlace al enunciado y un breve resumen del mismo (lo más importante son las características que se nombran con las letras A, B, C…).
• Descripción del punto de partida proporcionado desde el que se comienza a trabajar.
• Análisis del problema y diseño de la solución. Si se trata de desarrollar un prototipo software, se explicará su funcionamiento con diagramas y/o pseudocódigo.
• Documentación de las pruebas realizadas, incluyendo el enlace a un video oculto en YouTube, en formato horizontal de 16:9, resolución mínima de 1920×1080 y un máximo de 5 minutos de duración titulado con el nombre de la práctica y mostrando cada prueba de cada característica (A1, A2, B1, B2, B3…) convenientemente rotulada y comentada por voz. ¡Evitad usar música o fragmentos de video con copyright! Si lo hacéis, aplicad filtros para evitar que YouTube os penalice por infringir derechos de autor.

Para llevar las tareas se puede usar la funcionalidad Projects de GitHub o Azure Boards en el caso de Azure Repos, por ejemplo.

Es bastante útil mantener un registro de cambios para cada documento, que puede estar basado en Keep a Changelog, e incluso usar versionado semántico para numerar cada versión.

Código fuente y recursos

El código fuente debe incluir en carpetas separadas cualquier recurso o plugin de terceros que sea necesario para la correcta compilación del proyecto.

Si el profesor proporciona un proyecto base, ese debe ser el punto de partida, y mencionarse explícitamente. Incluso el repositorio con la práctica de los alumnos debería crearse explícitamente como bifurcación (fork) del proyecto original del profesor. Aunque el alumno trabajará principalmente sobre su repositorio, si encuentra errores podría corregirlos y pedirle al profesor que extraiga dichos cambios (pull request) y los incorpore en el repositorio base para que todos sus compañeros, presentes y futuros, se puedan beneficiar de la corrección. De hecho ese tipo de participación proactiva y solidaria se valora mucho en la calificación. Cuando el repositorio del profesor es público y se requiere que el del alumno sea privado (por evitar plagios durante el curso), en GitHub quizá la única solución es hacer un duplicado “espejo” (mirroring) del repositorio…

Ejecutables

Al menos 1 fichero ejecutable para Windows de 64bits debe estar publicado como lanzamiento descargable en el repositorio. Habitualmente es un simple fichero ZIP, que si ocupase demasiado se enlazaría en el repositorio desde en algún almacén externo, como Google Drive.

Condiciones

A la hora de desarrollar cualquier práctica deben respetarse estas condiciones generales:

• Investigad a fondo el género de juego a realizar (títulos originales, aunque sean antiguos, mods o niveles creados por los fans).
• No plagiar juegos o prototipos ya existentes. Es posible estudiarlos y tenerlos como referencia (citándolos debidamente), pero lo principal de la propuesta de los alumnos debe ser original.
• No asumir permiso de uso de ningún material distinto al mencionado explícitamente en el enunciado de la práctica (plantillas, paquete Starter Content, etc.). No utilizar herramientas o plugins de terceros, ni reutilizar código distinto del proporcionado por el entorno de desarrollo utilizado o los propios profesores. Evitar complejidades innecesarias (expandir con más recursos lo propuesto haciendo el proyecto pesado o su ejecución lenta, subvertir las reglas, etc.).
• Aprended a usar las herramientas de diseño e implementación, para identificar sus límites y conocer de primera mano los recursos y opciones de que se disponen para desarrollar.
• Documentad el diseño de manera accesible a los profesores, siempre editando el mismo fichero para que quede patente en el historial de versiones que se ha repartido el esfuerzo equitativamente entre todos los miembros del grupo. Documentad en el repositorio el proceso de producción, incluyendo los algoritmos y las estructuras de datos más importantes (en el caso de Unreal Engine, mediante enlaces a Blueprints), así como, de nuevo, el reparto del trabajo y el esfuerzo. Si la práctica se centra en un aspecto, por ejemplo la Mecánica de un juego, puede haber secciones de Dinámica y Estética, pero serán más breves.
• Escribid en español y utilizando la terminología en español que vemos en clase, comentando y aclarando toda aquella decisión de diseño o desarrollo que no sea trivial.
• Programad el código y cread los recursos necesarios, siempre siguiendo buenas prácticas: de la manera más organizada, genérica y elegante posible. Sin olvidar los comentarios. Y trabajando de forma iterativa, consiguiendo lo antes posible una versión funcional (aunque sea muy incompleta) para asegurarnos de que realmente estamos haciendo las cosas bien.
• Desarrollad prototipos funcionales, usables y cómodos: con leer las instrucciones una vez será posible empezar a jugar. Preferiblemente con mando y algunas teclas rápidas será posible hacer las pruebas necesarias y superar los retos de manera razonablemente rápida, intuitiva o frecuente.
• Personalizad el contenido con el número de grupo, nombre de los alumnos u otros rasgos inequívocos que subrayen la autoría sobre el resultado.

Derechos de uso

Aunque los profesores tengan acceso al contenido de las prácticas y los proyectos de algún modo, es conveniente otorgar explícitamente derecho a los profesores para que puedan manipular y evaluar los trabajos legalmente. Una vez superada con éxito la asignatura lo ideal sería publicar todo en abierto (la documentación con licencia Creative Commons Attribution 4.0 International (CC BY 4.0) y el código con licencia GNU Lesser General Public License 3.0); mientras tanto se aconseja conceder al menos permiso para que los profesores puedan usar el material en sus labores docentes e investigadoras, incluyendo en el material una fórmula como esta:

“A, B y C, autores de la documentación, código y recursos de este trabajo, concedemos permiso permanente a los profesores de la Facultad de Informática de la Universidad Complutense de Madrid para utilizar nuestro material, con sus comentarios y evaluaciones, con fines educativos o de investigación; ya sea para obtener datos agregados de forma anónima como para utilizarlo total o parcialmente reconociendo expresamente nuestra autoría.”