Práctica

En la Facultad de Informática solemos trabajar las prácticas en los laboratorios. Para usar los puestos de laboratorio, el alumno debe solicitar su cuenta siguiendo el procedimientos correspondiente. Habitualmente el material de nuestras prácticas es digital (software, documentación, etc.) y por eso se utilizan repositorios con sistemas de control de versiones para almacenarlas y trabajar sobre ellas, al mismo tiempo que damos visibilidad a nuestros profesores sobre el estado actual del proyecto y todas las aportaciones que ha ido realizando cada alumno.

Aunque posteriormente puedan publicarse, lo deseable es que estos repositorios sean privados al menos durante el periodo de realización de las prácticas, para evitar plagios por parte de otros alumnos. Sólo los compañeros del grupo y los profesores tendrán acceso a los repositorios de un cierto grupo; no sólo para evaluar el resultado final sino que, para hacer un seguimiento detallado de 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 (normalmente en menos de 10 días laborables), 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.

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.

Google Drive

Es suficiente con una carpeta compartida en Google Drive entre los alumnos del grupo de trabajo y los profesores de la asignatura. Esta carpeta suele nombrarse como IDXX-GYY donde ID es el código de la asignatura, XX el año en que se imparte e YY la numeración del grupo dentro de la lista de clase. Las subcarpetas correspondientes a cada una de las prácticas (IDXX-GYY-PZ) se crearán dentro de esta carpeta.

GitHub

Lo razonable es crear una organización de GitHub compartida entre los alumnos del grupo de trabajo y los profesores de la asignatura. Esta organización suele nombrarse como IDXX-GYY donde ID es el código de la asignatura, XX el año en que se imparte e YY la numeración del grupo dentro de la lista de clase. Los repositorios correspondientes a cada una de las prácticas (IDXX-GYY-PZ) se crearán dentro de esta organización.

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) en 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.

Entornos de desarrollo

Las versiones actuales de Visual Studio ya incorporan la posibilidad de tener Microsoft Copilot integrado. Si tenemos una cuenta UCM en GitHub basta con añadirla a Visual Studio para tener ese servicio de asistencia gratuito en forma de chatbot con IA generativa.

Eso sí, siempre que se utilice información de terceros o generada por una IA, ese hecho debe referenciarse y marcarse debidamente en la práctica.

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. El repositorio y la documentación debe ser accesible al profesorado. Además debe haber contribuciones identificables y frecuentes sobre la documentación.

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.

En cualquier caso la documentación debe contener:

• Datos básicos del grupo de alumnos y de sus integrantes (nombres completos, correo electrónico…).
• Enlace al enunciado de la práctica y un breve resumen del mismo, ya que son las restricciones creativas que nos vienen impuestas. Lo más importante del enunciado suelen ser las características que se nombran con las letras A, B, C, D y E… normalmente A consiste en adaptar el punto de partida para que sirva como base, B y C contienen los requisitos funcionales más simples y D y E los requisitos funcionales y no funcionales más avanzados y desafiantes de la práctica. La consideración de los requisitos del enunciado es «Adecuada» si se tiene en cuenta lo más destacado del enunciado, si se presta atención hasta el más mínimo detalle será «Excelente»… pero si se ignora algún aspecto clave «Insuficiente».
• Descripción del punto de partida de la práctica (material disponible, plantillas, ejemplos o bases de código que son proporcionados en clase, axiomas o guías de diseño que nos autoimponemos…) desde el que se comienza a trabajar. La consideración del punto de partida es «Adecuada» si se utiliza bien lo más destacado del punto de partida, si se comprende y aprovecha hasta el más mínimo elemento será «Excelente»… pero si se ignora lo que se ha proporcionado será «Insuficiente».
• Datos de los referentes utilizados durante vuestra investigación, cualquier obra (similar o no), documento o información que nos ha inspirado para hacer la práctica. La investigación de posibles referentes es «Adecuada» si se incluyen todas las referencias del enunciado más alguna nueva, si además se citan todas correctamente (con todos los datos, URL, estilo APA, etc.) será «Excelente»… pero si no se añade ninguna referencia nueva será «Insuficiente».
• Análisis del problema y diseño de la solución. Ya sea el desarrollo de un prototipo software o el diseño de algoritmos, heurísticas o «trucos», se explicará su funcionamiento adecuadamente con texto, diagramas y/o pseudocódigo, según el convenio acordado con el profesor. La estructura y redacción del texto es «Adecuada» si no todo lo escrito es legible y no contiene errores, si la redacción es clara, concisa pero a la vez rica en detalles será «Excelente»… pero si hay errores graves, partes incomprensibles o faltan cosas por explicar será «Insuficiente». La utilización de diagramas y/o imágenes es «Adecuada» si los principales aspectos se reflejan visualmente y de forma correcta, si hay abundante información visual y la ejecución es impecable, será «Excelente»… pero si faltan diagramas o imágenes importantes (no vale recurrir a fotos y capturas de pantalla) o son incomprensibles será «Insuficiente». Si se han hecho borradores en papel conviene escanear y asegurarse de que hay suficiente definición y contraste para leer y ver todas las líneas bien… pero lo mejor es acabar convirtiéndolos en imágenes vectoriales.
• Documentación sobre las pruebas realizadas, generalmente en forma de enlace a un video-documental «oculto» en YouTube. Capturar siempre los prototipos en ejecución como procesos independientes con la propia herramienta Game Bar de Windows, en formato horizontal de 16:9, resolución mínima de 1920×1080 y un máximo de 5 minutos de duración. Titular el video con asignatura, curso, nombres de los alumnos, título de la práctica y mostrando cada prueba de cada característica rotulada con su código (A1, A2, B1, B2, B3…) y nombre, procurando comentar todo por voz o al menos tener subtítulos. Podéis usar YouTube Studio para hacer algunos recortes, aunque para añadir rótulos hace falta usar una herramienta de edición como CapCut. ¡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. En la descripción del video incluid algo de información básica sobre la práctica, como vuestros datos o un enlace al repositorio de la práctica.
• Como parte de las pruebas a veces se pide documentar algunas métricas de los resultados. Ello implica añadir todos los datos numéricos que tengamos sobre la ejecución del prototipo y relacionarlos para, por ejemplo, ver qué cantidad de operaciones se pueden realizar en un cierto tiempo o sin bajar de un cierto número de fotogramas estables.
• Es comprensible que hasta la entrega final no haya conclusiones en la documentación o no estén los resultados de las pruebas, pero en la entrega final deben incluirse, resumiendo lo que se ha hecho y aprendido en el proceso. Si se implementan ampliaciones que van más allá de lo que pide el enunciado, hay que documentarlo también en una sección aparte… y si se quieren proponer otras ampliaciones, mejor enviárselas al profesor como ideas para añadir al enunciado.

En Google Docs es sencillo corregir errores ortográficos o gramaticales; basta con comprobar que en Archivo > Idioma tenemos elegido el español y luego activar todas las opciones dentro de Herramientas > Ortografía y gramática. Si lo quieres hacer en la documentación o el código de GitHub, o quieres hacer una revisión más profunda, hay que recurrir a herramientas externas como Code Spell Checker, Grammarly, LanguageTool, etc.

Para mantener una lista tareas en las prácticas de programación se recomienda usar la funcionalidad Projects de GitHub (o simplemente los issues) o, en el caso de Azure Repos, Azure Boards.

Es bastante útil mantener un registro de cambios para cada documento, cuya nomenclatura puede estar basada en Keep a Changelog, e incluso en cierto 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.

Lo razonable es ir implementando las características en orden de complejidad (habitualmente A tan sólo es adaptar el punto de partida a nuestras necesidades, luego podemos desarrollar B y C, y finalmente -tras comprobar que todo lo anterior funciona bien- se desarrollarán las características más complejas D y E).

Si el profesor proporciona un proyecto base, ese debe ser el punto de partida, y mencionarse y usarse explícitamente. A la hora de descargarlo hay que tener cuidado y, si usa Git LFS, usar un cliente (como GitHub Desktop) que permita descargar los ficheros guardados en el almacén LFS; o si se hace desde la consola, utilizar este comando:
git clone –depth=1 <enlace al repo>

Lo ideal sería que el repositorio de los alumnos se crease explícitamente como bifurcación (fork) del proyecto original del profesor, pero GitHub obliga a que el repositorio mantenga la visibilidad del original. Como el repositorio del profesor suele ser público y el del alumno debe ser privado (al menos durante el curso, por evitar plagios), en GitHub existe la posibilidad de hacer un duplicado «espejo» (mirroring) del repositorio (en este repositorio se dan instrucciones de cómo hacerlo).

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.

Para facilitar la revisión de la práctica, los recursos del proyecto conviene organizarlos con un criterio híbrido: en un primer nivel separar los recursos propios de los ajenos (tal vez por paquetes de contenido o autoría), quizá en un segundo nivel separar por tipo de contenido… pero en tercer y último nivel llevar una organización por tipo de recurso (modelos, sonidos, texturas, etc.).

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.

Será práctico y fácil de usar, comprendiendo -con la calidad mínima esperable- las características principales que se piden en el enunciado, además de los recursos audiovisuales adecuados para representar el entorno propuesto.

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 desarrollo software (commits frecuentes en la rama principal, organización de recursos en el proyecto y de objetos en la escena, escritura sistemática de los comentarios, etc.), de la manera más organizada, genérica y elegante posible. 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. Limitarse, en la medida de lo posible, a los recursos del punto de partida proporcionado por el profesor, evitando el uso de recursos audiovisuales pesados, extraños, o que ralenticen la ejecución.
• 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, o con ratón si fuera más cómodo, será posible hacer las pruebas necesarias y superar los retos de manera razonablemente rápida, intuitiva o frecuente. Por ejemplo, habilitando una “consola de trucos” (o teclas rápidas) que permitan ver los datos de los desarrolladores, reiniciar la ejecución, cambiar la cámara, establecer situaciones específicas para hacer pruebas, hacer invencible al avatar, etc.
• 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 otorgarles explícitamente derecho para que puedan corregir y evaluar los trabajos legalmente. Una vez concluido el plazo de reclamación contra la calificación final de la asignatura (salvo que esté pendiente de resolución una reclamación) se entenderá «devuelto» el control de los trabajos y memorias prácticas a los alumnos, como dice el Estatuto del Estudiante artículo 18.2, quienes podrán hacer lo que deseen con ese material.

Nuestra recomendación es 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), o al menos conceder permiso para que los profesores puedan usar el material en futuras labores docentes e investigadoras, incluyendo desde el primer momento en todos los entregables 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.»