Gamificación de Fundamentos de la Programación: juegos serios para el aprendizaje de estructuras de código iterativas, métodos y funciones

Universidad de Valladolid Escuela de Ingenier´ ıa Inform´ atica Trabajo Fin de Grado Grado en Ingenier´ ıa Inform´ atica Gamificaci´ on de Fundamentos de la Programaci´ on: Juegos serios para el aprendizaje de estructuras de c´ odigo iterativas, m´ etodos y funciones Autor: Mario Torbado de la Rosa Tutores: Alma Mar´ ıa Pisabarro Marr´ on Carlos Enrique Vivaracho Pascual ´ INDICE GENERAL ´ Indice de figuras ....................................... 3 ´ Indice de tablas ........................................ 4 Resumen ........................................... 6 1 Introducci´ on ........................................ 7 1.1 Motivaci´ on .................................. 8 1.2 Objetivos ................................... 8 2 Herramientas Utilizadas ................................. 10 2.1 Unity ..................................... 10 2.2 Git....................................... 11 2.3 Blender .................................... 13 3 Plan de Proyecto ..................................... 14 3.1 Entregables .................................. 14 3.2 Metodolog´ ıa.................................. 15 3.3 Seguimiento.................................. 17 3.4 Gesti´ ondeRiesgos .............................. 17 3.5 Presupuesto.................................. 21 4 Documento de Dise˜ no de Juego (GDD) ......................... 22 4.1 Qu´ eesunGDD................................ 22 4.2 Introducci´ on.................................. 23 4.3 AudienciayPlataforma............................ 23 4.4 Tem´ atica.................................... 24 4.5 C´ omoseJuega ................................ 24 4.6 Niveles .................................... 26 4.7 Mec´ anicasdejuego.............................. 26 4.8 Sistema de Puntuaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1 ´ INDICE GENERAL 2 4.9 Multimedia .................................. 30 4.9.1 Assetsdeterceros........................... 31 4.10MarsMiner .................................. 32 4.11VenusMiner.................................. 32 4.12 Requisitos de aprendizaje previos . . . . . . . . . . . . . . . . . . . . . . . 32 5 Especificaci´ on T´ ecnica y Desarrollo .......................... 33 5.1 An´ alisisdeRequisitos............................. 33 5.1.1 Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.2 Requisitos No Funcionales . . . . . . . . . . . . . . . . . . . . . . 37 5.1.3 CasosdeUso............................. 39 5.2 Dise˜ no e Implementaci´ on........................... 43 5.2.1 Conceptosprevios .......................... 43 5.2.2 MonoBehaviour ........................... 44 5.2.3 Eventos................................ 46 5.2.4 Generaci´ on y Carga de Niveles . . . . . . . . . . . . . . . . . . . . 48 5.2.5 Gesti´ on del tablero de juego . . . . . . . . . . . . . . . . . . . . . 51 5.2.6 Niveles y acciones del robot. Corrutinas . . . . . . . . . . . . . . . 52 5.2.7 Interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2.8 Guardado de puntuaciones e integraci´ on con la plataforma . . . . . 58 5.2.9 Sonido ................................ 61 5.3 Pruebas .................................... 62 5.3.1 PruebasUnitarias........................... 62 5.3.2 PruebasAlpha ............................ 72 5.3.3 PruebasBeta ............................. 72 6 Conclusi´ on ........................................ 73 6.1 L´ ıneas de trabajo futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Bibliograf´ ıa .......................................... 75 2 ´ INDICE DE FIGURAS Figura 1 Editor de Unity. 10 Figura 2 Flujo de trabajo en Git. 11 Figura 3 Editor de Blender. 13 Figura 4 Tablero Kanban de Trello. 16 Figura 5 Escena de juego. 25 Figura 6 C´ odigo del robot. 27 Figura 7 Modelos 3D. 31 Figura 8 Diagrama de casos de uso: Men´ u de inicio. 39 Figura 9 Diagrama de casos de uso: Pantalla de juego. 40 Figura 10 Diagrama de casos de uso: Men´ u de pantalla superada. 41 Figura 11 Diagrama de casos de uso: Men´ u de pantalla no superada. 42 Figura 12 Ciclo de vida de script en Unity (MonoBehaviour). 45 Figura 13 Sistema de Eventos. 46 Figura 14 Diagrama de Clases: Carga de niveles. 50 Figura 15 Diagrama de Clases: Tablero de juego. 51 Figura 16 Diagrama de Clases: Scripts de nivel. 54 Figura 17 Jerarqu´ ıa de GameObjects de la interfaz de usuario. 56 Figura 18 Diagrama de Clases: Interfaz de usuario. 57 Figura 19 Diagrama de Clases: Puntuaciones. 60 Figura 20 Diagrama de Clases: Sistema de audio. 61 3 ´ INDICE DE TABLAS Tabla 1 Plantilla de riesgo. 18 Tabla 2 Riesgo R-1 18 Tabla 3 Riesgo R-2 18 Tabla 4 Riesgo R-3 19 Tabla 5 Riesgo R-4 19 Tabla 6 Riesgo R-5 20 Tabla 7 Riesgo R-6 20 Tabla 8 Riesgo R-7 20 Tabla 9 Requisito Funcional RF-01 33 Tabla 10 Requisito Funcional RF-02 34 Tabla 11 Requisito Funcional RF-03 34 Tabla 12 Requisito Funcional RF-04 34 Tabla 13 Requisito Funcional RF-05 34 Tabla 14 Requisito Funcional RF-06 34 Tabla 15 Requisito Funcional RF-07 35 Tabla 16 Requisito Funcional RF-08 35 Tabla 17 Requisito Funcional RF-09 35 Tabla 18 Requisito Funcional RF-10 35 Tabla 19 Requisito Funcional RF-11 35 Tabla 20 Requisito Funcional RF-12 35 Tabla 21 Requisito Funcional RF-13 36 Tabla 22 Requisito Funcional RF-14 36 Tabla 23 Requisito Funcional RF-15 36 Tabla 24 Requisito Funcional RF-16 36 Tabla 25 Requisito Funcional RF-17 36 Tabla 26 Requisito No Funcional RNF-01 37 Tabla 27 Requisito No Funcional RNF-02 37 Tabla 28 Requisito No Funcional RNF-03 37 Tabla 29 Requisito No Funcional RNF-04 37 Tabla 30 Requisito No Funcional RNF-05 38 Tabla 31 Requisito No Funcional RNF-06 38 4 ´ INDICE DE TABLAS 5 Tabla 32 Requisito No Funcional RNF-07 38 Tabla 33 Plantilla de prueba unitaria. 62 Tabla 34 Prueba Unitaria PU-01 63 Tabla 35 Prueba Unitaria PU-02 63 Tabla 36 Prueba Unitaria PU-03 63 Tabla 37 Prueba Unitaria PU-04 63 Tabla 38 Prueba Unitaria PU-05 64 Tabla 39 Prueba Unitaria PU-06 64 Tabla 40 Prueba Unitaria PU-07 64 Tabla 41 Prueba Unitaria PU-08 64 Tabla 42 Prueba Unitaria PU-09 65 Tabla 43 Prueba Unitaria PU-10 65 Tabla 44 Prueba Unitaria PU-11 65 Tabla 45 Prueba Unitaria PU-12 65 Tabla 46 Prueba Unitaria PU-13 66 Tabla 47 Prueba Unitaria PU-14 66 Tabla 48 Prueba Unitaria PU-15 66 Tabla 49 Prueba Unitaria PU-16 66 Tabla 50 Prueba Unitaria PU-17 67 Tabla 51 Prueba Unitaria PU-18 67 Tabla 52 Prueba Unitaria PU-19 67 Tabla 53 Prueba Unitaria PU-20 67 Tabla 54 Prueba Unitaria PU-21 68 Tabla 55 Prueba Unitaria PU-22 68 Tabla 56 Prueba Unitaria PU-23 68 Tabla 57 Prueba Unitaria PU-24 68 Tabla 58 Prueba Unitaria PU-25 68 Tabla 59 Prueba Unitaria PU-26 69 Tabla 60 Prueba Unitaria PU-27 69 Tabla 61 Prueba Unitaria PU-28 69 Tabla 62 Prueba Unitaria PU-29 69 Tabla 63 Prueba Unitaria PU-30 69 Tabla 64 Prueba Unitaria PU-31 70 Tabla 65 Prueba Unitaria PU-32 70 Tabla 66 Prueba Unitaria PU-33 70 Tabla 67 Prueba Unitaria PU-34 70 Tabla 68 Prueba Unitaria PU-35 70 Tabla 69 Prueba Unitaria PU-36 71 5 RESUMEN Esta es la memoria del Trabajo de Fin de Grado realizado por Don Mario Torbado de la Rosa, para la Facultad de Ingenier´ ıa Inform´ atica de la Universidad de Valladolid, en Julio de 2021. En ella, se describe el desarrollo de 2 videojuegos serios para la gamificaci´ on de la asignatura Fundamentos de Programaci´ on, cuyo objetivo es ayudar a los alumnos de primer curso a interiorizar los conceptos de estructuras de control y de uso de m´ etodos y funciones. A mayores, se ha realizado la integraci´ on de dichos juegos con la plataforma web Programa Jugando[1] del grupo GREIDI[2], cuyo desarrollo form´ o parte de un Trabajo Final de Grado previo, realizado por Don Juan Rodr´ ıguez Sanz. 6 1 INTRODUCCI ´ O N Los juegos serios son aquellos cuyo objetivo principal es otro que el de la diversi´ on del jugador. Existen diversos objetivos, formas y medios que puede tomar un juego serio, pero en cualquier caso, tienen como funci´ on motivar al receptor o mejorar su efectividad a la hora de realizar una tarea, cuyos resultados, en estos aspectos, podr´ ıa ser inferior si se lleva a cabo de forma tradicional. En este trabajo, abordaremos el dise˜ no y realizaci´ on de juegos serios, en la forma de videojuegos, para su aplicaci´ on en la docencia. El uso de estos en el ´ ambito educativo es un tipo de gamificaci´ on en el aula, pues su prop´ osito es servir de herramienta educativa, bien como refuerzo a las t´ ecnicas de ense˜ nanza convencionales o sustituyendo a algunas de estas. En concreto, este proyecto tiene como objetivo la creaci´ on de dos videojuegos educativos, tratando en cada uno algunos de los conceptos b´ asicos de la programaci´ on. Su p´ ublico objetivo son los alumnos de la asignatura de Fundamentos de Programaci´ on, de Grado en Ingenier´ ıa Inform´ atica de la Universidad de Valladolid, aunque su aplicaci´ on podr´ ıa expandirse a otros grados o niveles docentes. A su vez, este trabajo forma parte de un proyecto mayor, la plataforma Programa Jugando[1], iniciativa del grupo GREIDI[2], que tiene como objetivo la gamificaci´ on completa del temario de la asignatura de Fundamentos de Programaci´ on. 7 1.1 M OT I VAC I ´ O N 8 1.1 M OT I VAC I ´ O N La programaci´ on es una materia que requiere un alto grado de abstracci´ on para comprender muchos de sus conceptos, que pueden resultar complicados de transmitir de forma verbal. Conceptos de este tipo pueden ser asimilados mejor una vez que se comienzan a poner en pr´ actica, pero las herramientas de programaci´ on convencionales como compiladores o entornos de desarrollo, suelen ser complejas y poco intuitivas para un alumno que tiene su primera toma de contacto con las mismas. Esto puede resultar en una experiencia frustrante al no comprender por qu´ e algo no funciona, no entender un error de compilaci´ on o no ser capaz de visualizar qu´ e est´ a haciendo realmente un fragmento de c´ odigo. La motivaci´ on de este proyecto es la de proporcionar al alumnado de la Escuela de una herramienta de aprendizaje que sirva de puente entre las lecciones te´ oricas del profesorado y las pr´ acticas de programaci´ on. Con esta herramienta, en forma de videojuegos serios, se motiva al alumno en el proceso de asimilaci´ on de conceptos de programaci´ on b´ asicos, en un entorno controlado y que traslada la abstracci´ on del c´ odigo a una representaci´ on gr´ afica, facilitando su interpretaci´ on. 1.2 OBJETIVOS El objetivo general del proyecto, es la asistencia a la formaci´ on del alumnado de primer curso en los conceptos de programaci´ on siguientes: Estructuras de c´ odigo condicionales. Estructuras de c´ odigo iterativas. Manejo de m´ etodos y funciones. Paso por referencia y paso por variable. Para su tratamiento, el proyecto dividir´ a la carga de aprendizaje en dos videojuegos, basados en las mismas mec´ anicas, pero tratando uno los dos primeros conceptos y otro los dos ´ ultimos. 8 3.2 METODOLOG´ I A 15 Documentaci´ on para la modificaci´ on de puntuaciones: Se incluir´ a un documento que explique c´ omo modificar el c´ alculo de las puntuaciones en el c´ odigo fuente. La modificaci´ on de las puntuaciones puede ser requerida por el cliente en caso de que, tras haber sido puesto el proyecto en fase de prueba por su usuario final (alumnos), resulte que la dificultad para superar los niveles sea demasiado alta o demasiado baja. El documento indica d´ onde y c´ omo modificar estos c´ alculos para ajustar la dificultad de los videojuegos. Esta documentaci´ on aparecer´ a como una secci´ on del fichero README.md incluido en el repositorio del c´ odigo fuente del proyecto. Documentaci´ on para la edici´ on de niveles: La implementaci´ on de ambos videojuegos permite editar o crear nuevos niveles de manera eficiente, sin necesidad de usar el editor de Unity o conocer todos los detalles de la implementaci´ on. Esto da la posibilidad de expandir en un futuro el tama˜ no de los videojuegos entregados (Modificar el lenguaje de programaci´ on mostrado al jugador, a˜ nadir niveles para una dificultad, etc.). Esta documentaci´ on aparecer´ a como una secci´ on del fichero README.md incluido en el repositorio del c´ odigo fuente del proyecto. 3.2 METODOLOG´ I A Para el desarrollo del proyecto se ha utilizado la metodolog´ ıa Kanban [8], que se engloba dentro de las metodolog´ ıas ´ agiles. La implementaci´ on de la metodolog´ ıa consiste en el uso de un tablero (figura 4), que ser´ a visible para todos los integrantes del proyecto, en el que se listan tareas, su estado de progreso, y las personas implicadas en dicha tarea. Cada estado de progreso ser´ a una columna del tablero, en el que podr´ a haber un n´ umero limitado o ilimitado de tareas: En reserva: Tareas que se han creado pero no se espera comenzar a trabajar en ellas en el futuro cercano. Por hacer: Tareas que est´ an previstas iniciarse pr´ oximamente, ordenadas por prioridad. En progreso: Tareas actualmente en progreso. Como el equipo de desarrollo est´ a formado por una sola persona, s´ olo podr´ a haber una tarea en esta columna simult´ aneamente. Bloqueado: Tareas cuyo desarrollo se ha pausado temporalmente, bien por un problema que hay que investigar, la necesidad de completar otra tarea antes de poder acabar esta u otra causa t´ ecnica. Completado: Aqu´ ı tendremos todas las tareas que se han realizado con ´ exito. Archivado: Tareas que se han descartado. Las mantenemos aqu´ ı en lugar de borrarlas, para poder tenerlas de referencia o “rescatarlas” dada la circunstancia. 15 3.2 METODOLOG´ I A 16 Una tarea describe el trabajo que se debe realizar sobre el proyecto, normalmente enfocado a un ´ area determinada del mismo. Al tratarse de un proyecto unipersonal, la generaci´ on de las tareas recae sobre el propio desarrollador. Las tareas ser´ an definidas a partir de los requisitos del proyec- to dados por el cliente y los requisitos internos del propio desarrollador. Esta metodolog´ ıa se integrar´ a tambi´ en con el manejo del repositorio Git. Para cada tarea, se deber´ a crear una rama nueva, a partir de la rama de desarrollo. Una tarea no se podr´ a mover a la columna de ‘completado’ hasta que no se hayan realizado las pruebas unitarias que confirmen que el funcionamiento de los cambios implementados es correcto y se fusione la rama de la tarea con la rama de desarrollo. El tablero utilizado para la gesti´ on del proyecto, en este caso, ha sido un tablero digital de la aplicaci´ on Trello[9]. En la figura 4 se muestra una captura de pantalla del mismo, en un punto intermedio del desarrollo del proyecto. Figura 4: Tablero Kanban de Trello. 16 3.3 S E G U I M I E N T O 17 3.3 SEGUIMIENTO Kanban, la metodolog´ ıa seleccionada y descrita en la secci´ on anterior, no establece pautas de seguimiento de proyecto entre cliente y desarrolladores. Esto es as´ ı ya que Kanban est´ a pensado para poder integrarse en un sistema de producci´ on existente, u organizar a un equipo de desarrollo internamente, independientemente de la jerarqu´ ıa de mando que exista por encima. Los clientes del proyecto desarrollado son, en este caso, los mismos tutores, Do˜ na Alma Mar´ ıa Pisabarro Marr´ on y Don Carlos Enrique Vivaracho Pascual. Nos referiremos a ellos como el ‘cliente’ en este documento de aqu´ ı en adelante. Como pauta de seguimiento informal, se establecer´ a la realizaci´ on de reuniones del desarrollador con el cliente cada dos semanas, en la medida de lo posible. Dichas reuniones tienen como funci´ on informar al cliente de los cambios implementados en la ´ ultima iteraci´ on, definir nuevos objetivos y requisitos para el proyecto y corregir la trayectoria del mismo en caso de desviarse del objetivo pretendido. Estas reuniones se han llevado a la pr´ actica con la regularidad predicha, desde el comienzo del proyecto en septiembre de 2019, a excepci´ on del periodo entre junio de 2020 y marzo de 2021, meses durante los cuales el desarrollo del proyecto se detuvo, debido a la inviabilidad de congeniar su desarrollo con la vida laboral del desarrollador durante dicho periodo. 3.4 GESTI ´ ON DE RIESGOS Un riesgo es la probabilidad de ocurrencia de un suceso en el futuro que afectar´ ıa negativamente a la capacidad para cumplir los objetivos del proyecto. Para gestionar los posibles riesgos a los que se enfrenta el proyecto, se ha seguido un proceso cuyos pasos se describen a continuaci´ on: Identificaci´ on: Se identifican y se enumeran los riesgos posibles para el desarrollo del proyecto. An´ alisis: En esta etapa se analiza cada riesgo y se formaliza un plan de actuaci´ on. Este plan consiste en la especificaci´ on de unas medidas de prevenci´ on, para evitar que la situaci´ on del riesgo se haga realidad, y unas medidas de contingencia, para que, en caso de que suceda, minimizar el impacto del mismo. Priorizaci´ on: Se ordenan los riesgos seg´ un su importancia. A mayor probabilidad e impacto, mayor importancia. En tablas 2 a 8 , se enumerar´ an los riesgos del proyecto, obtenidos mediante el proceso anteriormente indicado, utilizando la plantilla expresada en la tabla 1: 17 3.4 G E S T I ´ ON DE RIESGOS 18 Identificador Identificador con forma R-0 Riesgo Descripci´ on del riesgo Probabilidad Estimaci´ on de la probabilidad de que el riesgo suceda. Puede ser: raro, poco probable, posible, muy probable o casi seguro Consecuencia Descripci´ on del resultado de suceder el riesgo Impacto Indicador de la gravedad de las consecuencias de la ocurrencia del riesgo. Puede ser: despreciable, bajo, moderado, alto o catastr´ ofico. Medidas de prevenci´ on Acciones para evitar que el riesgo suceda. Medidas de contingencia Acciones para minimizar el impacto del riesgo. Tabla 1: Plantilla de riesgo. Identificador R-1 Riesgo Disponibilidad insuficiente del desarrollador. Probabilidad Muy probable, por la conciliaci´ on con la vida laboral del desarrollador. Consecuencia El desarrollador no puede dedicar el tiempo necesario al desarrollo del proyecto para terminarlo en la fecha estimada de entrega inicial. Impacto Alto Medidas de prevenci´ on Ninguna. Medidas de contingencia Retrasar la entrega del proyecto, solicitar excedencia del puesto de trabajo para terminar el proyecto. Tabla 2: Riesgo R-1 Identificador R-2 Riesgo P´ erdida del trabajo realizado por fallo del dispositivo de almacenamiento o borrado accidental. Probabilidad Posible Consecuencia Necesidad de rehacer el trabajo perdido y/o coste monetario para recuperar el material de trabajo. Impacto Alto Medidas de prevenci´ on Utilizaci´ on de un repositorio remoto de una entidad de confianza (Git- Hub) y copias de seguridad en discos duros externos. Medidas de contingencia Retrasar la entrega del proyecto, incluir en el presupuesto del proyecto una reserva para aver´ ıas t´ ecnicas. Tabla 3: Riesgo R-2 18 3.4 G E S T I ´ ON DE RIESGOS 19 Identificador R-3 Riesgo Aver´ ıa del equipo de trabajo Probabilidad Posible Consecuencia Parada temporal en el desarrollo del proyecto y/o coste monetario para recuperar el equipo de trabajo. Impacto Moderado. Medidas de prevenci´ on Disponer de un equipo secundario con el que poder continuar el desarrollo. Medidas de contingencia Retrasar la entrega del proyecto, incluir en el presupuesto del proyecto una reserva para aver´ ıas t´ ecnicas, trasladar el desarrollo del proyecto a un equipo secundario. Tabla 4: Riesgo R-3 Identificador R-4 Riesgo Formaci´ on insuficiente. Probabilidad Posible Consecuencia Necesidad de pausar el desarrollo para aprender c´ omo implementar un requisito del proyecto. Impacto Moderado o bajo. Medidas de prevenci´ on Realizar una formaci´ on extensa en las herramientas necesarias para el desarrollo del proyecto de forma previa a iniciar su desarrollo, y reservar un margen de tiempo en la estimaci´ on del proyecto para completar el aprendizaje que fuera necesario. Medidas de contingencia Completar el aprendizaje necesario imprevisto, buscar una soluci´ on diferente, retrasar la entrega del proyecto. Tabla 5: Riesgo R-4 19 3.4 G E S T I ´ ON DE RIESGOS 20 Identificador R-5 Riesgo Disponibilidad insuficiente del cliente (tutores). Probabilidad Poco probable. Consecuencia La comunicaci´ on es insuficiente y no se pueden establecer con preci- si´ on los requisitos del proyecto. La implementaci´ on puede no ajustarse a las necesidades del cliente. Impacto Alto Medidas de prevenci´ on Comunicaci´ on frecuente con el cliente y empleo de t´ ecnicas de desarrollo ´ agil e iterativo. Medidas de contingencia Ninguna. Tabla 6: Riesgo R-5 Identificador R-6 Riesgo Cambios cr´ ıticos en los requisitos del proyecto. Probabilidad Poco probable. Consecuencia Parte del trabajo realizado debe descartarse y se necesitar´ a m´ as tiempo para implementar los cambios acordados. Impacto Moderado Medidas de prevenci´ on Comunicaci´ on frecuente con el cliente y empleo de t´ ecnicas de desarrollo ´ agil e iterativo. Medidas de contingencia Retrasar la entrega del proyecto. Tabla 7: Riesgo R-6 Identificador R-7 Riesgo Enfermedad o Incapacitaci´ on del desarrollador. Probabilidad Raro. Consecuencia El desarrollador no puede continuar trabajando el proyecto, de forma temporal, permanente o no al mismo ritmo que inicialmente. Impacto De moderado a catastr´ ofico. Medidas de prevenci´ on Ninguna. Medidas de contingencia Retrasar la entrega del proyecto. Tabla 8: Riesgo R-7 20 3.5 P R E S U P U E S T O 21 3.5 PRESUPUESTO El salario anual bruto medio de un programador de videojuegos en Espa˜ na es de 32.100e, seg´ un la web Jobted [10]. Para una estimaci´ on inicial de 300 horas de trabajo real para la realizaci´ on del proyecto, si equiparamos esto a una jornada habitual de 40 horas semanales, necesitar´ ıamos aproximadamente 2 meses para realizar el proyecto. Por tanto, tendr´ ıamos un coste de mano de obra de (32.100/12)*2 = 5.350ebrutos. En cuanto al software utilizado, al haber optado por herramientas de c´ odigo abierto o con licencias gratuitas, suficientes para cubrir el desarrollo de este proyecto, su coste total asociado es de 0e. El hardware utilizado tiene un coste aproximado de 1.000e. Se trata de un equipo cuyo motivo de adquisici´ on y uso no es exclusivamente para el desarrollo del proyecto. Contabilizaremos el coste de amortizaci´ on para las 300 horas de trabajo de la siguiente manera: Seg´ un la Tabla de coeficientes de amortizaci´ on lineal de la Agencia Tributaria, para Equipos Inform´ aticos de Procesos de Informaci´ on, se establece un coeficiente lineal m´ aximo del 25 % anual [11]. Considerando a˜ nos de 236 d´ ıas laborales, con jornadas de 8 horas durante las cuales el equipo estar´ ıa funcionando de forma continua, tendr´ ıamos un coste de 1000*0,25*(300/(236*8))= 39,72e asociado al uso del hardware durante la realizaci´ on del proyecto. Para el c´ alculo del presupuesto se han desestimado otros costes, como el asociado al consumo el´ ectrico o el correspondiente a la tarifa de la compa˜ n´ ıa que suministra acceso a la Red. Teniendo en cuenta todo lo mencionado, el presupuesto para la realizaci´ on de este proyecto ascender´ ıa a 5.389,72e. 21 4 DOCUMENTO DE DISE ˜ NO DE JUEGO (GDD) 4.1 Q U ´ E E S U N G D D GDD, del Ingl´ es Game Design Document, o Documento de Dise˜ no del Juego, es un documento est´ andar de la industria de los videojuegos que tiene como fin plasmar en texto el juego en desarrollo, desde su conceptualizaci´ on general a detalles sobre mec´ anicas de juego, historia, personajes o dise˜ no art´ ıstico [12]. Es un documento de car´ acter informal, sin estructura definida, y que se actualiza conforme avanza el desarrollo del juego. La funci´ on principal de este documento es la de servir como gu´ ıa y referencia entre los distintos departamentos y miembros de un equipo de desarrollo (dise˜ nadores, programadores, artistas, marketing, etc.) y, por lo tanto, es un documento en el que todas las partes del equipo est´ an involucradas en su edici´ on. Debido a la naturaleza din´ amica del documento, es frecuente que sea utilizado como ´ ıtem de seguimiento en t´ ecnicas de desarrollo ´ agil: Una versi´ on actualizada del documento es generada por el equipo de dise˜ no, que debe ser aprobada por el editor o cliente. Cuando este da el visto bueno, el documento pasa a manos del equipo de desarrollo, que detalla la implementaci´ on de los cambios. Por ´ ultimo, el documento pasa de nuevo por el equipo de dise˜ no, se revisa, y comienza una nueva iteraci´ on. En este caso, al tratarse de un proyecto en el que el autor ocupa todos los roles del desarrollo del proyecto, el GDD es m´ as un documento de presentaci´ on del mismo de cara al cliente, que una herramienta de comunicaci´ on interna para el desarrollo. 22 4.2 INTRODUCCI ´ O N 23 4.2 INTRODUCCI ´ O N Mars Miner yVenus Miner son dos videojuegos educativos cuyo fin es el de mejorar el aprendizaje de los alumnos en conceptos b´ asicos de programaci´ on y sus destrezas a la hora de utilizarlos. En cada nivel de cada juego, el objetivo del jugador ser´ a guiar a un robot que se desplaza por la superficie de un planeta para que recoja un n´ umero de minerales valiosos. Para que el robot consiga recoger los minerales, el jugador deber´ a analizar un fragmento de c´ odigo que se mostrar´ a en la pantalla, que representa las acciones que realizar´ a el robot de manera autom´ atica. Despu´ es, el jugador podr´ a manipular la escena moviendo algunos obst´ aculos (rocas), para que el robot logre llegar a su objetivo. Si el robot colisiona con alguna roca, se sale de la zona de juego o completa la secuencia de c´ odigo sin haber recogido los minerales necesarios, el jugador habr´ a perdido en dicha pantalla y no obtendr´ a puntos. Si por el contrario, logra recoger los minerales necesarios y completa la secuencia de c´ odigo sin colisionar, el jugador habr´ a completado la pantalla y obtendr´ a una cantidad de puntos determinada por la dificultad del nivel y el tiempo e intentos que ha necesitado para completarlo. Mars Miner yVenus Miner, aunque se entregan con el proyecto como dos juegos independientes, son en esencia el mismo, diferenci´ andose ´ unicamente en aspectos est´ eticos y el tipo de c´ odigo a analizar. Por este motivo se presentan ambos con el mismo Documento de Dise˜ no y ser´ a en las ´ ultimas secciones donde se tratar´ an sus diferencias. 4.3 AUDIENCIA Y PLATAFORMA Mars Miner yVenus Miner forman parte del proyecto de gamificaci´ on de la asignatura de Fundamentos de Programaci´ on, y su audiencia son Alumnos de primer curso de Grado de Ingenier´ ıa Inform´ atica. Ambos juegos ser´ an exportados para ser ejecutados desde la plataforma web Programa Jugando por lo que est´ an destinados a ser jugados desde un navegador web en un ordenador de sobremesa o port´ atil. 23 4.4 T E M ´ ATICA 24 4.4 T E M ´ A T I C A Mars Miner y Venus Miner no cuentan con una historia o trasfondo expl´ ıcito, pero sus dise˜ nos giran en torno a la exploraci´ on espacial y la explotaci´ on de recursos materiales de otros planetas. Del nombre, Mars yVenus hacen referencia respectivamente al planeta en el que se encuentra la escena de juego (Marte o Venus), y Miner (minero) a la labor de extraer minerales. En el juego, el “protagonista” es un robot, de dise˜ no inspirado en veh´ ıculos de exploraci´ on marciana reales como el Curiosity o el Perseverance. A dicho robot se referir´ a en el juego como el Mars Hoover oVenus Hoover, haciendo de nuevo referencia al planeta escenario, y Hoover, aspiradora en ingl´ es. El robot por tanto ser´ a una especie de aspiradora aut´ onoma que recoge minerales valiosos de la superficie de los planetas. 4.5 C´ O M O S E J U E G A Al comenzar el nivel, al jugador se le presentar´ a la escena de juego (figura 5), que representa la superficie de un planeta, sobre la que se sit´ ua el tablero de juego. En ´ el encontraremos los siguientes elementos de juego, ocupando una casilla: Mars/Venus Hoover: El robot que debe recoger los minerales. Rocas marrones: Son rocas fijas en el tablero, que no se pueden mover. Rocas plateadas: Son rocas que se pueden mover. Minerales: Gemas brillantes de minerales valiosos. El robot debe tratar de recogerlas. Por otro lado, a la derecha de la pantalla de juego, se mostrar´ a el c´ odigo con las acciones del robot, y un bot´ on para iniciar la secuencia. En la esquina inferior izquierda aparecer´ a un marcador que indica el n´ umero de minerales que debe recoger el robot para superar la pantalla actual, y el n´ umero de minerales recogidos hasta el momento. El jugador deber´ a analizar el c´ odigo del robot y, viendo en la escena la posici´ on y orientaci´ on inicial del mismo, prever c´ omo se mover´ a una vez iniciada la secuencia. El jugador entonces tratar´ a de mover las rocas plateadas hasta llegar a una configuraci´ on que evite que el robot choque con alguna roca y que gu´ ıe al robot hasta los minerales. 24 4.9 MULTIMEDIA 31 Escena de juego (figura 7, quinta imagen). Figura 7: Modelos 3D. Para las animaciones de movimiento y colisi´ on del robot, se ha usado la herramienta de animaci´ on integrada en el editor de Unity. Los efectos de movimiento de rocas, tormenta de arena y el humo de la animaci´ on de colisi´ on del robot est´ an creados con el sistema de part´ ıculas de Unity. Los efectos de sonido provienen de clips extra´ ıdos de la plataforma freesound.org [14]. 4.9.1 Assets de terceros Para algunos elementos del juego se han utilizado los Assets de terceros listados a continuaci´ on: Rocas decorativas de la escena: Low poly styled rocks, de Daniel Robnik [15]. Efecto tormenta de arena: Stard Assets, de Unity Technologies [16]. Cuadr´ ıcula del tablero de juego: SimpleGridShader, de Revision3 [17]. La m´ usica del juego ha sido compuesta y producida por Don ´ Oliver L. Sanz San Jos´ e, antiguo alumno de la Escuela, permitiendo su uso de manera libre y gratuita en el juego. Desde aqu´ ı queremos agradec´ erselo. 31 4.10 MARS MINER 32 4.10 MARS MINER Este juego servir´ a para ense˜ nar al alumno a entender estructuras condicionales e iterativas. El c´ odigo del robot contendr´ a s´ olo un m´ etodo Main, y podr´ a hacer uso de las siguientes instrucciones: if, else, else if, while yfor. Dada la ubicaci´ on del tema correspondiente en la asignatura, este juego ser´ a al que el alumno acceda primero, por lo que debe contar con un tutorial m´ as completo, que detalle todos los aspectos necesarios para que el usuario aprenda a jugar. Est´ eticamente, se diferenciar´ a por la escena de juego, que emular´ a la superficie de Marte. 4.11 VENUS MINER Este juego servir´ a para ense˜ nar al alumno a utilizar m´ etodos y funciones y a distinguir los conceptos de paso por referencia y paso por variable. El c´ odigo del robot contendr´ a un m´ etodo Main como antes, m´ as las definiciones de m´ etodos y funciones deseadas. A mayores, podr´ a hacer uso de las mismas instrucciones condicionales e iterativas que Mars Miner. Otra diferencia clave es que, en el panel de c´ odigo, aparecer´ a un campo de entrada, donde el jugador podr´ a introducir valores que corresponder´ an a algunos de los par´ ametros utilizados por el c´ odigo. Esto a˜ nade otra variable que podremos tener en cuenta en el dise˜ no de niveles. Est´ a versi´ on se jugar´ a despu´ es de Mars Miner, por lo que en el tutorial no ser´ a necesario explicar con tanto detalle los detalles t´ ecnicos del juego. Est´ eticamente, se diferenciar´ a por la escena de juego, que emular´ a la superficie de Venus. 4.12 REQUISITOS DE APRENDIZAJE PREVIOS Ambos juegos est´ an pensados para ser jugados despu´ es de que los conceptos tratados en ellos sean explicados en las aulas. As´ ı pues, el jugador deber´ a conocer las sentencias condicionales e iterativas antes de jugar Mars Miner. Lo mismo se aplica para Venus Miner respecto al paso por referencia/variable, funciones y m´ etodos. Los juegos sirven como una herramienta para el refuerzo de estos conceptos y su puesta en pr´ actica, pero en ning´ un momento sustituyen la labor docente de los profesores. 32 5 ESPECIFICACI ´ O N T ´ ECNICA Y DESARROLLO 5.1 A N ´ A L I S I S D E R E Q U I S I TO S En esta secci´ on se presentan las necesidades externas de cliente sobre los juegos, as´ ı como las necesidades internas, producto del dise˜ no de la jugabilidad de los mismos. Separaremos los requisitos en funcionales y no funcionales, siendo los primeros los que marcan el comportamiento del software, y los segundos, los que corresponden a atributos de calidad, caracter´ ısticas de funcionamiento o limitaciones. Los requisitos enumerados a continuaci´ on corresponden a los aplicados a la versi´ on final de los juegos, si bien estos han evolucionado a lo largo de las iteraciones de dise˜ no llevadas al cabo durante la realizaci´ on del proyecto. 5.1.1 Requisitos Funcionales En esta secci´ on, se define la lista de requisitos funcionales, que definen caracter´ ısticas requeridas en ambos juegos: RF-01 Iniciar juego Descripci´ on Al seleccionar el juego desde la plataforma, se deber´ a cargar el men´ u de inicio, que permitir´ a seleccionar un nivel de dificultad, ver las puntuaciones de cada nivel, cargar el men´ u de opciones y salir del juego. Tabla 9: Requisito Funcional RF-01 33 5.1 A N ´ ALISIS DE REQUISITOS 34 RF-02 Seleccionar un nivel Descripci´ on El jugador podr´ a elegir entre 4 niveles de dificultad en el men´ u de inicio: f´ acil, medio, dif´ ıcil y reto. El nivel F´ acil siempre estar´ a disponible, pero los siguientes niveles se desbloquear´ an al alcanzar una puntuaci´ on determinada en el nivel anterior. Tabla 10: Requisito Funcional RF-02 RF-03 Men´ u de opciones Descripci´ on El men´ u de opciones permitir´ a ajustar los vol´ umenes de la m´ usica del juego y de los efectos de sonido por separado. A este men´ u se podr´ a acceder tanto desde la pantalla de juego como desde el men´ u de inicio. Tabla 11: Requisito Funcional RF-03 RF-04 Tutorial Descripci´ on Al seleccionar el nivel f´ acil de dificultad, si el jugador no ha conseguido a´ un puntos en el juego (o lo que es lo mismo, no ha superado a´ un ninguna pantalla), se cargar´ a una pantalla definida que contiene el tutorial de juego, en forma de paneles con texto explicativo e im´ agenes. Tabla 12: Requisito Funcional RF-04 RF-05 Pantallas aleatorias Descripci´ on La pantalla mostrada cada vez que se juegue un nivel de dificultad, se seleccionar´ a de manera aleatoria, a excepci´ on de la pantalla para el tutorial. Al continuar jugando un nivel, la siguiente pantalla seleccionada nunca ser´ a la misma que la anterior. Tabla 13: Requisito Funcional RF-05 RF-06 Escena de juego. Descripci´ on En la pantalla de juego, visualizaremos la escena que contiene el tablero de juego desde una perspectiva elevada, con el tablero situado en el centro de la pantalla. Tabla 14: Requisito Funcional RF-06 34 5.1 A N ´ ALISIS DE REQUISITOS 35 RF-07 Panel de c´ odigo. Descripci´ on En la pantalla de juego, visualizaremos al lado derecho un panel que contenga el c´ odigo que representa las acciones del robot. En caso de que el c´ odigo no cupiese en el espacio disponible, este panel podr´ a desplazarse verticalmente (scroll) mediante el uso de la rueda del rat´ on. Tabla 15: Requisito Funcional RF-07 RF-08 HooverDoc. Descripci´ on En la pantalla de juego, habr´ a un bot´ on para mostrar el HooverDoc, un panel que contiene todas las acciones del robot (m´ etodos) y una explicaci´ on de las mismas. Tabla 16: Requisito Funcional RF-08 RF-09 Mover Roca Plateada. Descripci´ on En la pantalla de juego, el jugador podr´ a mover la posici´ on de una roca plateada en el tablero de la escena, haciendo click sobre la misma, arrastrando con el rat´ on, y soltando en la posici´ on deseada. La roca plateada no podr´ a soltarse en una casilla del tablero que ya est´ e ocupada por otro elemento de juego. Tabla 17: Requisito Funcional RF-09 RF-10 Cron´ ometro. Descripci´ on En la pantalla de juego, en la parte superior, aparecer´ a un panel que marca el tiempo desde que el jugador inici´ o la pantalla actual, y un marcador con los puntos de penalizaci´ on por tiempo. Tabla 18: Requisito Funcional RF-10 RF-11 Contador de minerales. Descripci´ on En la pantalla de juego, en la esquina inferior izquierda, aparecer´ a un panel que indica el n´ umero de minerales que el robot debe recoger para superar la pantalla y los minerales recogidos hasta el momento. Este contador se actualizar´ a en el instante que el robot recoja un mineral. Tabla 19: Requisito Funcional RF-11 RF-12 Iniciar movimiento del robot. Descripci´ on En la pantalla de juego, habr´ a un bot´ on para iniciar la secuencia de movimiento del robot. Una vez iniciada, no podr´ a detenerse. Tabla 20: Requisito Funcional RF-12 35 5.1 A N ´ ALISIS DE REQUISITOS 36 RF-13 Men´ u de la pantalla de juego. Descripci´ on En la pantalla de juego, en la esquina superior izquierda, habr´ a un bot´ on que desplegar´ a un men´ u con las siguientes opciones: Reiniciar la pantalla actual, ir al men´ u de opciones y volver a la pantalla de inicio. Tabla 21: Requisito Funcional RF-13 RF-14 Pantalla superada. Descripci´ on Una pantalla de juego se superar´ a cuando, al terminar la secuencia de c´ odigo del robot, ´ este haya recogido una cantidad de minerales igual o superior a lo indicado en el contador de minerales. El robot recoger´ a un mineral al pasar por la casilla en la que ´ este se encuentre. Tabla 22: Requisito Funcional RF-14 RF-15 Pantalla fallada. Descripci´ on Una pantalla de juego se fallar´ a cuando el robot choque con una roca, se salga de los l´ ımites del tablero o complete su secuencia de c´ odigo sin recoger los minerales suficientes. Tabla 23: Requisito Funcional RF-15 RF-16 Men´ u de pantalla superada. Descripci´ on En la pantalla de juego, al superar una pantalla con ´ exito, se mostrar´ a un panel que indique los puntos conseguidos, el tiempo que se ha tardado y los intentos realizados hasta completar la pantalla, y las siguientes opciones: Jugar otra pantalla del mismo nivel y volver al men´ u de inicio. En caso de haber conseguido suficientes puntos para desbloquear el siguiente nivel de dificultad, aparecer´ a tambi´ en la opci´ on de iniciar una pantalla del siguiente nivel. Tabla 24: Requisito Funcional RF-16 RF-17 Men´ u de pantalla no superada. Descripci´ on En la pantalla de juego, al fallar una pantalla, se mostrar´ a un panel con las siguientes opciones: Reintentar la pantalla actual, jugar otra pantalla del mismo nivel de dificultad y volver al men´ u de inicio. Tabla 25: Requisito Funcional RF-17 36 5.1 A N ´ ALISIS DE REQUISITOS 37 5.1.2 Requisitos No Funcionales En esta secci´ on, se define la lista de requisitos no funcionales, que definen caracter´ ısticas requeridas en ambos juegos: RNF-01 Lenguaje de programaci´ on mostrado. Descripci´ on El c´ odigo mostrado en las pantallas de juego deber´ a utilizar sintaxis Java. Tabla 26: Requisito No Funcional RNF-01 RNF-02 Aspecto del juego en la plataforma. Descripci´ on El juego deber´ a mostrarse correctamente al ser ejecutado desde la plataforma, en un navegador web moderno, desde un ordenador, de tal forma que la interfaz sea clara, se distingan todos los elementos que componen el juego y ninguno de estos aparezca cortado o en una posici´ on incorrecta. Tabla 27: Requisito No Funcional RNF-02 RNF-03 Legibilidad. Descripci´ on Todo el texto del juego deber´ a estar dise˜ nado para favorecer su legibilidad, y deber´ a tener un tama˜ no de fuente similar al utilizado en la plataforma. Tabla 28: Requisito No Funcional RNF-03 RNF-04 Claridad del tablero Descripci´ on Los elementos del tablero de juego deber´ an distinguirse claramente unos de otros, y las casillas del tablero deber´ an poder distinguirse con facilidad cuando se mueva una roca plateada de posici´ on. Tabla 29: Requisito No Funcional RNF-04 37 5.1 A N ´ ALISIS DE REQUISITOS 38 RNF-05 Tiempo de respuesta Descripci´ on Todas las acciones dentro del juego, tanto con la interfaz de usuario como con la manipulaci´ on de la escena de juego, deber´ an responder inmediatamente, sin retardos. Tabla 30: Requisito No Funcional RNF-05 RNF-06 Motor de desarrollo Descripci´ on Los juegos ser´ an desarrollados usando el motor Unity. Tabla 31: Requisito No Funcional RNF-06 RNF-07 Integraci´ on con la plataforma Descripci´ on Los juegos se integrar´ an con la plataforma, exportando ´ estos para la plataforma WebGL, e incorporando un sistema para leer y guardar las puntuaciones de cada juego para cada usuario. Tabla 32: Requisito No Funcional RNF-07 38 5.1 A N ´ ALISIS DE REQUISITOS 39 5.1.3 Casos de Uso Los siguientes diagramas sirven para representar gr´ aficamente la interacci´ on que el jugador podr´ a tener con los juegos. Esta interacci´ on se representar´ a aislando 4 escenas diferenciadas, que limitan la interacci´ on que es posible dentro del juego en cada una: El men´ u de inicio (figura 8), la pantalla de juego (figura 9), el men´ u tras superar una pantalla (figura 10) y el men´ u tras fallar una pantalla (figura 11). Figura 8: Diagrama de casos de uso: Men´ u de inicio. 39 5.1 A N ´ ALISIS DE REQUISITOS 40 Figura 9: Diagrama de casos de uso: Pantalla de juego. 40 5.2 D I S E ˜ NO E IMPLEMENTACI ´ O N 47 Este sistema, consiste en una clase que llamaremos EventSystem (figura 13), que declara una lista de eventos: public event Action onLevelLoad; [...] /// <summary> /// (Event) A level is loaded and ready to be played /// </summary> public void LoadLevel() { if (onLevelLoad !=null) { onLevelLoad(); } } El resto de clases, pueden suscribir m´ etodos a uno de estos eventos: GameEvents.current.onLevelLoad += ShowInGameUI; O disparar el evento, haciendo que el resto de clases ejecuten los m´ etodos suscritos: GameEvents.current.LoadLevel(); Este sistema implementa los patrones de dise˜ no Singleton y Observador. 47 5.2 D I S E ˜ NO E IMPLEMENTACI ´ O N 48 5.2.4 Generaci´ on y Carga de Niveles Cada Pantalla de juego de Mars Miner oVenus Miner est´ a definido por 3 elementos: Configuraci´ on del tablero de juego: Los elementos de juego (rocas fijas, rocas movibles, minerales y el robot) y su disposici´ on en el tablero al inicio de la pantalla. C´ odigo mostrado del robot: El texto del c´ odigo Java mostrado en el panel de la derecha de la pantalla de juego, que representa las acciones que realizar´ a el robot al iniciar su movimiento. Script de movimiento del robot: Es el c´ odigo real, en lenguaje C#, que controla las acciones del robot al iniciar su movimiento. En vez de definir una escena para cada pantalla de juego, en la cual deber´ ıamos a˜ nadir “a mano” cada uno de los elementos del tablero de juego y asignar el c´ odigo mostrado y el script de movimiento tambi´ en de manera fija en cada escena, se ha dise˜ nado un sistema para la carga din´ amica de niveles. Este sistema consiste en utilizar 3 ficheros para cada uno de los 3 elementos anteriores, y un script que los interpreta y genera los elementos de juego necesarios en cada pantalla. Para el tablero, se definir´ an archivos CSV (comma separated values). Esto es una tabla, con las mismas dimensiones que el tablero de juego, con la que indicamos qu´ e elemento de juego debe haber en cada casilla. Un script leer´ a esta tabla y generar´ a los GameObjects de cada elemento de juego a partir de Prefabs, y los colocar´ a en la casilla correspondiente. Los posibles valores son los siguientes: 0: Casilla vac´ ıa. 1: Roca fija. 2: Roca movible (plateada). 3: mineral. d: robot orientado hacia abajo (coordenada X en la escena de Unity). u: robot orientado hacia arriba (coordenada -X en la escena de Unity). l: robot orientado hacia la izquierda (coordenada Z en la escena de Unity). r: robot orientado hacia la derecha (coordenada -Z en la escena de Unity). Para el c´ odigo mostrado en cada pantalla, se utilizar´ a un fichero de texto. Para a˜ nadir coloreado, se podr´ an utilizar etiquetas XML de la forma <color=#FFFFFF>, ya que este texto ser´ a interpretado por un Componente TextMeshPro[27], que soporta texto enriquecido[28]. 48 5.2 D I S E ˜ NO E IMPLEMENTACI ´ O N 49 Para el c´ odigo de movimiento se han creado scripts en C#, con una clase que define la secuencia de movimientos del robot dentro de un m´ etodo. Esta clase deber´ a derivar de una clase abstracta llamada AbsLevel, y definir en ella un m´ etodo Play() que contiene la secuencia de acciones del robot. Las acciones posibles del robot se definen en una clase separada, RobotActions. Analizaremos en detalle este mecanismo m´ as adelante. Con la idea de que el cliente u otros futuros usuarios tengan la capacidad de crear niveles, el proyecto se entregar´ a incluyendo una gu´ ıa para ello, como ya se mencion´ o en la secci´ on de entregables. Este sistema de generaci´ on din´ amica de niveles tiene varias ventajas: R´ apida iteraci´ on en la creaci´ on de los niveles. Trabajar sobre estos archivos es m´ as r´ apido que editar escenas en Unity a trav´ es del editor. Independencia del editor de Unity. Podemos crear niveles sin necesidad de instalar esta pesada herramienta. Precisi´ on. En el editor de Unity, es f´ acil descolocar un objeto inintencionadamente dentro de la escena. Esto, para un juego de tablero, podr´ ıa dar frecuentes problemas, al no coincidir la posici´ on de los objetos con las casillas. Definiendo la posici´ on de los objetos a trav´ es de c´ odigo y utilizando una tabla, evitamos este problema. Expansibilidad. Con m´ ınimos conocimientos sobre el funcionamiento interno del juego, podr´ an a˜ nadirse nuevos niveles en el futuro. Reutilizaci´ on. El sistema ya ha servido para generar 2 variantes de juego, con tan solo modificaciones est´ eticas. En un futuro, podr´ ıa reutilizarse, al menos parcialmente, para otros juegos de tablero. En la figura 14 se muestra un diagrama de clases que refleja la implementaci´ on del sistema de lectura de los ficheros de configuraci´ on de pantalla. La clase LevelLoader es la encargada de tratar dichos ficheros. Esta clase interacciona con otras clases: BoardManager,ScoreManager y InGameUICanvasActions, que veremos m´ as a delante en esta secci´ on. 49 5.2 D I S E ˜ NO E IMPLEMENTACI ´ O N 50 Figura 14: Diagrama de Clases: Carga de niveles. 50 5.2 D I S E ˜ NO E IMPLEMENTACI ´ O N 51 5.2.5 Gesti´ on del tablero de juego Para controlar el desplazamiento de los elementos de juego dentro del tablero, se ha creado la clase Tile (figura 15). Esta clase sirve simplemente para representar una casilla del tablero, como unas coordenadas de 2 dimensiones. Aunque podr´ ıa haberse utilizado una tupla, o la clase Vector2 de UnityEngine, de esta forma podemos diferenciar de forma m´ as clara cu´ ando estamos tratando con una coordenada de nuestro tablero, y no un vector general. La clase BoardManager (figura 15) sirve para definir propiedades del tablero, como sus dimensiones y el tama˜ no de cada casilla dentro del juego. Tambi´ en sirve para traducir las coordenadas de las casillas (Tile) a coordenadas reales de la escena de juego (Vector2, Vector3) cuando se desplaza el robot o una roca. Por ´ ultimo, utilizaremos tambi´ en esta clase para asistir en el movimiento de rocas, indicando en la cuadr´ ıcula encima de qu´ e casilla estamos situados y si se puede colocar la roca en la casilla o no. Figura 15: Diagrama de Clases: Tablero de juego. 51 5.2 D I S E ˜ NO E IMPLEMENTACI ´ O N 52 5.2.6 Niveles y acciones del robot. Corrutinas El sistema utilizado para la creaci´ on de niveles y las acciones del robot est´ a representado en la figura 16, que contiene el diagrama de clases correspondiente. Para programar las secuencias de acciones del robot, una clase definir´ a el conjunto de movimientos del robot, en forma de m´ etodos. Despu´ es, para cada nivel, un script definir´ a la secuencia de movimientos concreta del nivel, utilizando dichos m´ etodos y estructuras de c´ odigo condicionales e iterativas. Esta secuencia estar´ a encapsulada en la funci´ on Play(). Este script (clase LevelN en el diagrama de la figura 16) se asignar´ a din´ amicamente a cada instancia del GameObject del robot presente en la escena por la clase LevelLoader cuando carguemos una pantalla. Para poder iniciar la secuencia de cualquier nivel, necesitaremos una interfaz que defina la funci´ on Play(). Esta es la interfaz ILevel que aparece en el diagrama de clases de la figura 16. La interfaz ILevel definir´ a tambi´ en otras funciones requeridas para los scripts de nivel. Dentro de los scripts de nivel necesitaremos definir tambi´ en mecanismos para comprobar cu´ ando se ha completado la secuencia de movimiento del robot con ´ exito o cu´ ando el robot a colisionado y por tanto debe detenerse. Este c´ odigo es com´ un para todos los scripts de nivel, e ir´ a definido en una clase Abstracta, AbsLevel (figura 16). Cada script de nivel deber´ a derivar de AbsLevel. Las diferentes acciones del robot se definir´ an en el script RobotActions (figura 16) como funciones. Cada acci´ on del robot deber´ a realizarse a tal velocidad que sea distinguible en la pantalla de juego. La clase MonoBehaviour no nos permite hacer esto a trav´ es de las funciones del ciclo de vida, por lo que deberemos utilizar otro mecanismo: corrutinas[29]. Las corrutinas nos permiten distribuir acciones en el tiempo, haciendo que su ejecuci´ on se pause en un punto, devolviendo el control a Unity, para luego retomar su ejecuci´ on en el punto donde se dej´ o. Cada acci´ on de movimiento o animaci´ on del robot se definir´ a como una funci´ on de tipo IE- numerator[30], una interfaz de C# que permite una iteraci´ on simple a trav´ es de una colecci´ on no gen´ erica, y que devuelve null mientras no se halla completado: 52 5.2 D I S E ˜ NO E IMPLEMENTACI ´ O N 53 public IEnumerator MoveFoward() { audioManager.Play("robot_motor2"); Vector3 target = boardManager.GetCenterPointOfTile(GetFowardTile(1)); float i = 0.0f; while (Vector3.Distance(transform.position, target) > 0.0f && canMove) { i += Time.deltaTime *moveSpeed; transform.position = Vector3.Lerp(transform.position, target, i); yield return null; } audioManager.Stop("robot_motor2"); } El m´ etodo Play() de cada script de nivel actuar´ a como un contenedor de estas acciones y deber´ a ser declarado tambi´ en de tipo IEnumerator. Para iniciar la secuencia de movimiento de un nivel, se har´ a a trav´ es de la funci´ on StartCorrutine de la siguiente manera: GameObject[] characterCubes = GameObject.FindGameObjectsWithTag("CharacterCube"); foreach (GameObject characterCube in characterCubes) { StartCoroutine(characterCube.GetComponent<ILevel>() .Play(programInput.GetComponent<ProgramInputScript>().GetInputArrayStr())); } A continuaci´ on, en la figura 16 , se puede ver el diagrama de clase que muestra la relaci´ oon entre las clases que implementan el sistema para la definici´ oon de los scripts de nivel del juego y la implementaci´ oon de las acciones del robot, y sus dependencias con otras clases: 53 5.2 D I S E ˜ NO E IMPLEMENTACI ´ O N 54 Figura 16: Diagrama de Clases: Scripts de nivel. 54 5.2 D I S E ˜ NO E IMPLEMENTACI ´ O N 55 5.2.7 Interfaz de usuario Para controlar la interfaz de usuario, la implementaci´ on del juego cuenta con un total de 12 scripts, que aparecen representados en el diagrama de clases de la figura 18. Es una implementaci´ on descentralizada, es decir, que no sigue una jerarqu´ ıa en la que tengamos una clase desde la que se pueda manipular o acceder a todos los dem´ as componentes o scripts que controlan la interfaz. Esta implementaci´ on descentralizada es resultado de la jerarqu´ ıa de los GameObjects que componen la interfaz de usuario en la escena (figura 17). Unity favorece una implementaci´ on de este tipo en cuanto a que, a m´ as bajo el nivel en que se integren los scripts dentro de la jerarqu´ ıa de GameObjects, m´ as f´ acil es acceder a los Componentes de los mismos. Un Componente al mismo nivel que el Componente Script que lo controla, puede ser accedido directamente con GetComponent<Tipo>(), mientras que si debemos obtener una referencia a un Componente de distinto nivel, deberemos utilizar mecanismos menos eficientes para buscarlos, o indicar las referencias a trav´ es de la interfaz del editor. A pesar de ello, se ha tratado de agrupar la funcionalidad de los distintos Canvas (figura 17) de tal forma que un script controle toda la funcionalidad del mismo, aunque con excepciones para funcionalidades aisladas. Esta es la jerarqu´ ıa resultante de la implementaci´ on: Level Selection Canvas: Agrupa todos los elementos de la pantalla de inicio. Es controlado por el script LevelSelector (figura 18). Options Canvas: Agrupa todos los elementos del men´ u de opciones. Es controlado por el script OptionsCanvasActions (figura 18). InGame UI Canvas: Agrupa todos los elementos de interfaz de la pantalla de juego. Es controlado por el script InGameUICanvasActions (figura 18). Level Finished Canvas: Agrupa los elementos de los paneles mostrados al finalizar un nivel (nivel superado / nivel no superado). Es controlado por el script LevelFinishedCanvasActions (figura 18). 55 5.2 D I S E ˜ NO E IMPLEMENTACI ´ O N 56 Figura 17: Jerarqu´ ıa de GameObjects de la interfaz de usuario. 56 5.3 P RU E B A S 63 Identificador PU-01 Elemento Men´ u de inicio - General. Descripci´ on El men´ u de inicio se muestra correctamente al cargar el juego en la plataforma. Resultado Pasada. Tabla 34: Prueba Unitaria PU-01 Identificador PU-02 Elemento Men´ u de inicio - Selecci´ on de nivel. Descripci´ on En el men´ u de inicio se muestran 4 botones, uno por nivel dificultad. Al pulsar un bot´ on de nivel, se carga la pantalla de juego, con una pantalla seleccionada aleatoriamente entre las pantallas disponibles para la dificultad. Resultado Pasada. Tabla 35: Prueba Unitaria PU-02 Identificador PU-03 Elemento Men´ u de inicio - Desbloqueo de niveles. Descripci´ on Al iniciar por primera vez el juego, aparecen bloqueados todos los botones de selecci´ on de nivel de dificultad a excepci´ on del primero. Al lograr una puntuaci´ on determinada en un nivel, se desbloquea el bot´ on de la siguiente dificultad. Resultado Pasada. Tabla 36: Prueba Unitaria PU-03 Identificador PU-04 Elemento Men´ u de inicio - Mostrar puntuaciones. Descripci´ on Debajo de cada bot´ on de selecci´ on de dificultad que est´ e desbloqueado, se muestra la puntuaci´ on obtenida hasta el momento por el jugador en esa dificultad. Resultado Pasada. Tabla 37: Prueba Unitaria PU-04 63 5.3 P RU E B A S 64 Identificador PU-05 Elemento Men´ u de inicio - Ajustes. Descripci´ on En el men´ u de inicio aparece un bot´ on para acceder al men´ u de ajustes. Este men´ u permite ajustar el volumen de la m´ usica y los efectos de sonido independientemente, mediante 2 sliders. Resultado Pasada. Tabla 38: Prueba Unitaria PU-05 Identificador PU-06 Elemento Men´ u de inicio - Salir. Descripci´ on En el men´ u de inicio aparece un bot´ on para cerrar el juego. En la plataforma, al pulsar el bot´ on, el juego se cierra y se vuelve a la pantalla de selecci´ on de juego. Resultado Pasada. Tabla 39: Prueba Unitaria PU-06 Identificador PU-07 Elemento Pantalla de juego - carga del tutorial. Descripci´ on Al cargar por primera vez una pantalla de juego, aparece el primer panel del tutorial superpuesto a la escena de juego, y se bloquea la interacci´ on con el resto de elementos de la pantalla. Resultado Pasada. Tabla 40: Prueba Unitaria PU-07 Identificador PU-08 Elemento Pantalla de juego - cerrar tutorial. Descripci´ on Al cerrar el ´ ultimo panel del tutorial, los elementos de la pantalla de juego bloqueados previamente se desbloquean. Resultado Pasada. Tabla 41: Prueba Unitaria PU-08 64 5.3 P RU E B A S 65 Identificador PU-09 Elemento Pantalla de juego - Desplazar roca. Descripci´ on En la escena de juego, se podr´ a hacer click sobre las rocas plateadas, iniciando la animaci´ on de ‘levitaci´ on’. Al arrastrar el rat´ on se desplaza la roca. Al soltar la roca, ´ esta se coloca en la casilla sobre la que levitaba en el ´ ultimo instante. Si se suelta la roca sobre una casilla ya ocupada, esta vuelve a su casilla original. Resultado Pasada. Tabla 42: Prueba Unitaria PU-09 Identificador PU-10 Elemento Pantalla de juego - Mostrar cuadr´ ıcula. Descripci´ on Mientras se arrastra el rat´ on para desplazar una roca, se muestra la cuadr´ ıcula del tablero, con la casilla sobre la que la roca levita coloreada. Si la casilla sobre la que levita est´ a libre, la cuadr´ ıcula se muestra de color verde, y roja en caso contrario. Resultado Pasada. Tabla 43: Prueba Unitaria PU-10 Identificador PU-11 Elemento Pantalla de juego - HooverDoc. Descripci´ on Al pulsar el bot´ on ‘HooverDoc’, aparece en pantalla el panel con la documentaci´ on del c´ odigo del robot. Al volver a pulsarlo, ´ este se cierra. Resultado Pasada. Tabla 44: Prueba Unitaria PU-11 Identificador PU-12 Elemento Pantalla de juego - Cron´ ometro. Descripci´ on Al iniciar una pantalla, el cron´ ometro empieza contar. Cada 30 segudos, el contador de penalizaci´ on incrementa en 50 puntos, hasta un m´ aximo de 200. Resultado Pasada. Tabla 45: Prueba Unitaria PU-12 65 5.3 P RU E B A S 66 Identificador PU-13 Elemento Pantalla de juego - Marcador de minerales. Descripci´ on Al iniciar una pantalla, el marcador de minerales muestra el n´ umero de minerales requerido para superar la pantalla. Al recoger un mineral, el n´ umero de minerales recogidos se actualiza. Resultado Pasada. Tabla 46: Prueba Unitaria PU-13 Identificador PU-14 Elemento Pantalla de juego - Bot´ on start. Descripci´ on Al pulsar el bot´ on start, ´ este se bloquea y comienza la ejecuci´ on de la secuencia de acciones del robot. Resultado Pasada. Tabla 47: Prueba Unitaria PU-14 Identificador PU-15 Elemento Pantalla de juego - Panel de opciones. Descripci´ on Al pulsar el bot´ on de la esquina superior izquierda de la pantalla de juego, aparece un panel con los botones ‘Reiniciar nivel’, ‘Opciones’ y ‘Volver a inicio’. Volviendo a pulsar el bot´ on, el panel se cierra. Resultado Pasada. Tabla 48: Prueba Unitaria PU-15 Identificador PU-16 Elemento Pantalla de juego - Reiniciar nivel. Descripci´ on Al pulsar el bot´ on de reiniciar nivel, la escena de juego vuelve a su estado inicial, y el bot´ on ‘start’ se desbloquea si estaba bloqueado. Resultado Pasada. Tabla 49: Prueba Unitaria PU-16 66 5.3 P RU E B A S 67 Identificador PU-17 Elemento Panel de pantalla superada - General. Descripci´ on Al completarse la secuencia de acciones del robot y haber recogido todos los minerales necesarios para pasar la pantalla, aparece el panel de pantalla superada y los dem´ as elementos de interfaz de usuario de la pantalla de juego desaparecen. Se muestra en esta pantalla los intentos, tiempo y puntos de la pantalla correctamente. Resultado Pasada. Tabla 50: Prueba Unitaria PU-17 Identificador PU-18 Elemento Panel de pantalla superada - Continuar. Descripci´ on Al pulsar el bot´ on ‘continuar’, se carga otra pantalla de juego aleatoria de la misma dificultad. Resultado Pasada. Tabla 51: Prueba Unitaria PU-18 Identificador PU-19 Elemento Panel de pantalla superada - Seleccionar otra dificultad. Descripci´ on Al pulsar el bot´ on ‘seleccionar otra dificultad’ se vuelve a la pantalla de inicio. Resultado Pasada. Tabla 52: Prueba Unitaria PU-19 Identificador PU-20 Elemento Panel de pantalla superada - Siguiente dificultad. Descripci´ on Cuando se supera la pantalla obteniendo suficientes puntos para desbloquear la siguiente dificultad, aparece el bot´ on ‘siguiente dificultad’. Al pulsarlo, se carga una pantalla aleatoria de la siguiente dificultad. No ocurre si ya se est´ a jugando en la ´ ultima dificultad (reto). Resultado Pasada. Tabla 53: Prueba Unitaria PU-20 67 5.3 P RU E B A S 68 Identificador PU-21 Elemento Panel de pantalla no superada - General. Descripci´ on Al colisionar el robot contra una roca o contra los l´ ımites del tablero, aparece el panel de pantalla no superada y los dem´ as elementos de interfaz de usuario de la pantalla de juego desaparecen. Resultado Pasada. Tabla 54: Prueba Unitaria PU-21 Identificador PU-22 Elemento Panel de pantalla no superada - Reintentar pantalla . Descripci´ on Al pulsar el bot´ on ‘reintentar pantalla, se vuelva a cargar la ´ ultima pantalla de juego. Resultado Pasada. Tabla 55: Prueba Unitaria PU-22 Identificador PU-23 Elemento Panel de pantalla no superada - Continuar. Descripci´ on Al pulsar el bot´ on ‘continuar’, se carga otra pantalla de juego aleatoria de la misma dificultad. Resultado Pasada. Tabla 56: Prueba Unitaria PU-23 Identificador PU-24 Elemento Panel de pantalla no superada - Seleccionar otra dificultad. Descripci´ on Al pulsar el bot´ on ‘seleccionar otra dificultad’ se vuelve a la pantalla de inicio. Resultado Pasada. Tabla 57: Prueba Unitaria PU-24 Identificador PU-25 Elemento Guardado y carga de puntuaciones. Descripci´ on En la plataforma, al salir del juego tras conseguir puntos y volver a entrar, se muestra la puntuaci´ on actualizada correctamente. Resultado Pasada. Tabla 58: Prueba Unitaria PU-25 68 5.3 P RU E B A S 69 Identificador PU-26 Elemento Efectos de sonido - M´ usica. Descripci´ on Al iniciar el juego, comienza a reproducirse el clip de sonido de la m´ usica del juego. Resultado Pasada. Tabla 59: Prueba Unitaria PU-26 Identificador PU-27 Elemento Efectos de sonido - Viento. Descripci´ on Al seleccionar una pantalla, comienza a reproducirse el clip de sonido del efecto de viento. Resultado Pasada. Tabla 60: Prueba Unitaria PU-27 Identificador PU-28 Elemento Efectos de sonido - Ruidos del robot. Descripci´ on Al seleccionar una pantalla, comienza a reproducirse el clip de sonido del efecto ruido del motor del robot. Cuando este se mueve, el tono del efecto de sonido cambia. Resultado Pasada. Tabla 61: Prueba Unitaria PU-28 Identificador PU-29 Elemento Efectos de sonido - Roca levitando. Descripci´ on Mientras se arrastra una roca, se reproduce el clip de sonido del efecto de ondas magn´ eticas. Resultado Pasada. Tabla 62: Prueba Unitaria PU-29 Identificador PU-30 Elemento Efectos de sonido - Soltar roca. Descripci´ on Al soltar una roca que se estaba desplazando, se reproduce el clip de sonido del efecto de golpe. Resultado Pasada. Tabla 63: Prueba Unitaria PU-30 69 5.3 P RU E B A S 70 Identificador PU-31 Elemento Efectos de sonido - Colisi´ on del robot. Descripci´ on Al colisionar el robot, se reproduce el clip de sonido del efecto de golpe. Resultado Pasada. Tabla 64: Prueba Unitaria PU-31 Identificador PU-32 Elemento Efectos de sonido - Recoger mineral. Descripci´ on Al recoger un mineral, se reproduce el clip de sonido del mieral recogido. Resultado Pasada. Tabla 65: Prueba Unitaria PU-32 Identificador PU-33 Elemento Efectos de sonido - Pulsar bot´ on. Descripci´ on Al pulsar cualquier bot´ on, se reproduce el sonido de bot´ on pulsado. Resultado Pasada. Tabla 66: Prueba Unitaria PU-33 Identificador PU-34 Elemento Animaciones - Colisi´ on del robot. Descripci´ on Al colisionar el robot, se reproduce la animaci´ on de colisi´ on del robot. Resultado Pasada. Tabla 67: Prueba Unitaria PU-34 Identificador PU-35 Elemento Animaciones - Tormenta de arena. Descripci´ on Al iniciar una pantalla de juego, comienza la animaci´ on de efecto tormenta de arena. Resultado Pasada. Tabla 68: Prueba Unitaria PU-35 70 5.3 P RU E B A S 71 Identificador PU-36 Elemento Animaciones - Ondas magn´ eticas. Descripci´ on Mientras se desplaza una roca, se reproduce la animaci´ on de ondas magn´ eticas. Resultado Pasada. Tabla 69: Prueba Unitaria PU-36 71 5.3 P RU E B A S 72 5.3.2 Pruebas Alpha Las pruebas Alpha de los juegos consistir´ an en la demostraci´ on de su funcionamiento frente al cliente. En estas pruebas, realizadas durante las reuniones de seguimiento una vez que se haya completado el desarrollo suficiente, el cliente propone escenarios de interacci´ on con el juego, po- ni´ endose en la piel del jugador. Se simulan dichos escenarios, y se anota cualquier fallo observado o comentarios del cliente a cerca de la mejora o modificaci´ on de la interacci´ on con el juego. Estas pruebas se han realizado de manera informal y cuando se han considerado oportunas por el desarrollador o el cliente. A continuaci´ on, se listan los cambios realizados en los juegos a ra´ ız de estas reuniones: Redise˜ no de la pantalla de inicio: Inicialmente, en la pantalla de inicio, aparec´ ıa un men´ u en el que el jugador seleccionaba qu´ e pantalla quer´ ıa jugar individualmente. Tras una prueba con el cliente, se decidi´ o cambiar este dise˜ no, para que el jugador s´ olo tuviera que seleccionar un nivel de dificultad. Selecci´ on de pantalla aleatoria: Despu´ es del cambio anterior, cuando el jugador seleccionaba una dificultad, la primera pantalla de juego que se cargaba para cada dificultad era siempre la misma. Se decidi´ o cambiar este dise˜ no, de tal forma que la pantalla cargada es siempre aleatoria, sin poder repetirse. La ´ unica excepci´ on es la pantalla cargada para el tutorial, que siempre ser´ a la primera pantalla cargada cuando sea la primera vez que se juega. Opacidad de los paneles de interfaz de usuario. Tras otra prueba con el cliente, se aument´ o la opacidad del fondo de varios de los paneles de la interfaz de los juegos, para mejorar la lectura del texto. 5.3.3 Pruebas Beta Debido a la fecha de entrega del proyecto, no ha podido ser probado a´ un por su usuario final, los alumnos. Por este motivo, se delegar´ a la responsabilidad de la realizaci´ on de las pruebas beta en el cliente. La entrega del c´ odigo fuente junto a una documentaci´ on para el ajuste de los par´ ametros del c´ alculo de puntuaciones y la creaci´ on de niveles, como se indic´ o en la secci´ on de entregables, permitir´ an al cliente ajustar estos elementos tras obtener retroalimentaci´ on de alumnos al probar los juegos. Se estima que dichos elementos ser´ an los que m´ as probablemente necesiten modificarse, pues se deber´ an ajustar en base a las capacidades observadas en los alumnos para superar con ´ exito cada uno de los niveles de dificultad. 72