Memoria PFG

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA
Proyecto de Fin de Grado en Ingeniería en Tecnologías de la Información
JUEGOS PARA EL APRENDIZAJE
EN UN AULA DE EDUCACIÓN
POST-SECUNDARIA
Sergio González Molina
Dirigido por: Dr. Salvador Ros Muñoz
Curso: 2015/2016 (convocatoria de septiembre)

JUEGOS PARA EL APRENDIZAJE EN UN AULA DE EDUCACIÓN POST-SECUNDARIA
Proyecto de Fin de Grado en Ingeniería en Tecnologías de la Información de
modalidad específica
Dirigido por: Dr. Salvador Ros Muñoz
Fecha de lectura y defensa: 27 de septiembre de 2016

Universidad Nacional de Educación a Distancia (UNED)
El contenido de este documento (Juegos para el aprendizaje en un aula de educación
post-secundaria) puede ser publicado y distribuido total o parcialmente bajo los términos
de la licencia Creative Commons Reconocimiento-CompartirIgual 4.0 Internacional
(CC BY-SA 4.0).

Agradecimientos
Con algunas ideas en mente sobre las áreas de sistemas y seguridad, que son
aquellas en las que tengo experiencia profesional y en las que me siento cómodo, se me
vino encima el inicio del curso 2014/2015 sin haber hecho una propuesta de proyecto a un
departamento.
No obstante, grata fue mi sorpresa cuando mi actual tutor, el Dr. Salvador Ros, del
Departamento de Sistemas de Comunicación y Control de la Escuela Técnica Superior de
Ingeniería Informática, me indicó la idea general del proyecto que me había sido
asignado. Por un lado, el hecho de tener que diseñar y desarrollar un juego no casaba ni
con mis intereses ni con mi experiencia. Sin embargo, el objetivo real del proyecto, los
juegos para el aprendizaje, era un área de estudio que me llamaba mucho la atención
(como informático y como profesor), a pesar de la nula experiencia previa.
Así pues, quiero agradecer a mi tutor y director del proyecto que me diera la
oportunidad de involucrarme en un área tan gratificante como la tecnología aplicada a la
educación. Y también que me permitiera aparcar el proyecto un año para continuarlo al
siguiente.
Quiero dedicar este proyecto a mi hija Carla y a mi mujer Laura, por la paciencia que
han tenido conmigo durante las largas horas de trabajo. Saben ellas bien que, en última
instancia, esto lo hago por ellas, por mejorar como profesional que optará a mejores
condiciones laborales, con la esperanza de poderles dar lo que necesitan y poder pasar
más tiempo en familia en lo venidero. Aunque hayan encontrado a faltar a su padre y
marido, en el futuro espero poder recompensarlas.
La más pequeña de la familia, en tamaño aunque no en edad, es nuestra perrita Pippa,
que también ha sufrido las consecuencias de no poder pasearla como es debido, así que
a ella también va dedicado el proyecto.

Resumen
Este proyecto persigue analizar y profundizar en las posibilidades que los Serious
Games pueden tener en la docencia desde un punto de vista general y, en particular, en
asignaturas denominadas STEM (science, technology, engineering, math) que se
caracterizan por tener una complejidad y dificultad reconocida haciendo que, en
ocasiones, su estudio no entusiasme a los estudiante.
Para ello se ha realizado el diseño y desarrollo de un juego para el aprendizaje desde
una perspectiva didáctica.
En primer lugar, se describe el trasfondo pedagógico de la enseñanza para continuar
con algunas bases, buenas prácticas y metodologías para el diseño de juegos para el
aprendizaje.
A continuación, se describe el estado del arte sobre juegos para el aprendizaje,
indicando algunos proyectos existentes.
Seguidamente, se dan detalles de las herramientas utilizadas para el diseño y el
desarrollo del juego.
Posteriormente, se entra a explicar los pasos seguidos para diseñar y desarrollar el
juego producto de este proyecto, al que se ha llamado Max y el Dr. Mannhausen.
En última instancia, se comentan algunas posibilidades de mejora del proyecto.
Palabras clave
juegos para el aprendizaje, metodología de diseño y desarrollo, entorno virtual de
enseñanza (EVE), Moodle, constructivismo, pedagogía, SCORM

Abstract
This project is intended to analyze the possibilities of games for learning, aka Serious
Games, in all teaching areas but specially in STEM subjects (science, technology,
engineering, math), whose well known complexity and difficulty are sometimes cons for
students engagement.
In order to do so, a Serious Game was design and developed from a didactic point of
view.
First of all, the pedagogical background of learning is described as well as some guides,
best practices and methodologies to design games for learning.
Next, the state of art of games for learning is described, with emphasis in some existing
projects.
Then, the details of the tools used to design and develop the game are described.
Finally, the steps followed to design and develop the product of this project, a game
named Max and Dr. Mannhausen, are explained.
In addition, some future possible improvement for the project are commented.
Keywords
games for learning, serious games, methodologies for design and development,
constructivism, pedagogy, Moodle, Virtual Learning Environment (VLE), SCORM

Tabla de contenidos
1 Introducción, motivación y objetivos................................................................................17
1.1 Introducción..............................................................................................................17
1.2 Motivación.................................................................................................................17
1.3 Objetivo principal......................................................................................................18
1.4 La influencia del constructivismo..............................................................................18
1.5 Los 7 principios del aprendizaje...............................................................................20
1.6 Diseño y desarrollo de juegos para el aprendizaje..................................................22
1.6.1 Los 4 niveles de libertad....................................................................................22
1.6.2 Los 5 principios de los juegos...........................................................................23
1.7 Metodologías para el diseño de juegos para el aprendizaje....................................23
1.8 Estado del arte..........................................................................................................26
1.8.1 Referencias a juegos para el aprendizaje.........................................................26
1.8.2 Proyectos sobre juegos para el aprendizaje.....................................................26
2 Entorno de desarrollo.......................................................................................................29
2.1 Herramientas para el desarrollo de videojuegos......................................................29
2.2 Motor eAdventure.....................................................................................................32
2.2.1 Características principales................................................................................33
2.2.2 Casos de uso.....................................................................................................34
2.2.3 Funcionalidades presentes...............................................................................34
2.2.4 Funcionalidades ausentes.................................................................................36
2.3 Diseño de imágenes.................................................................................................38
2.4 Diseño de vídeos......................................................................................................38
2.5 Diseño de sonidos....................................................................................................39
3 El juego: Max y el Dr. Mannhausen.................................................................................41
3.1 Metodología empleada.............................................................................................41
3.1.1 Principios del aprendizaje.................................................................................42
3.1.2 Niveles de libertad.............................................................................................43
3.1.3 Principios del juego...........................................................................................44
3.2 Contexto educativo...................................................................................................44
3.3 Objetivos didácticos..................................................................................................45
3.4 Herramienta de desarrollo........................................................................................46
3.5 Tipo de juego............................................................................................................46
3.6 Diseño y descripción general de las escenas..........................................................47
3.6.1 Objetivo real del juego.......................................................................................47
3.6.2 Especificación de las metáforas........................................................................48
3.7 Descripción detallada de las escenas......................................................................49
3.7.1 Despacho del Dr. Mannhausen.........................................................................51
3.7.2 Entrada a Quantum Corp desde la calle...........................................................53
3.7.3 Puerta de entrada a Quantum Corp..................................................................55
3.7.4 Recepción de la empresa..................................................................................55
3.7.5 Sala del personal de limpieza...........................................................................58
3.7.6 Departamento de I+D........................................................................................58
3.7.7 Reunión de la Dirección de la empresa............................................................60
3.8 Evaluación del estudiante.........................................................................................62

3.9 Validación..................................................................................................................63
3.10 Errores conocidos...................................................................................................64
4 Integración en Moodle como paquete SCORM...............................................................67
4.1 Preparar el perfil de evaluación................................................................................67
4.2 Exportar el proyecto..................................................................................................69
4.3 Importar el paquete...................................................................................................72
4.4 Comunicación de datos............................................................................................75
5 Posibles mejoras..............................................................................................................77
6 Valoración económica......................................................................................................79
7 Licenciamiento del proyecto............................................................................................81
8 Bibliografía en formato electrónico..................................................................................83
9 Glosario de siglas.............................................................................................................85
10 Anexo: Manual del estudiante........................................................................................87
10.1 Objetivo del juego...................................................................................................87
10.2 Información de los elementos de la escena...........................................................87
10.3 Movimiento del protagonista...................................................................................88
10.4 Acciones sobre objetos...........................................................................................88
10.5 Acciones sobre personajes.....................................................................................89
10.6 Inventario................................................................................................................89
10.7 Datos de la partida en curso...................................................................................89

Tabla de figuras
Figura 1: Metodología propuesta por El Aachak et al..........................................................25
Figura 2: Algunas de las opciones de eAdventure..............................................................35
Figura 3: Implementación de la traducción a diversos idiomas...........................................37
Figura 4: Texto asociado a un personaje.............................................................................38
Figura 5: Fases de diseño utilizadas (metodología propia).................................................42
Figura 6: Flujo entre las escenas.........................................................................................49
Figura 7: Pantalla inicial para escoger el idioma.................................................................50
Figura 8: Pantalla de la escena en el despacho del Dr. Mannhausen................................51
Figura 9: Pantalla de la escena en la calle..........................................................................53
Figura 10: Pantalla de la escena de la entrada a la empresa.............................................54
Figura 11: Pantalla de la escena de la recepción................................................................56
Figura 12: Pantalla de la escena en el cuarto de limpieza..................................................57
Figura 13: Pantalla de la escena en el departamento de I+D.............................................59
Figura 14: Pantalla de la escena de la reunión...................................................................61
Figura 15: Informe de evaluación........................................................................................63
Figura 16: Efectos de la regla de evaluación del tiempo de juego......................................68
Figura 17: Efectos de la regla de evaluación de consulta del libro sobre criptografía........69
Figura 18: Efectos de una de las reglas de evaluación de respuestas incorrectas............69
Figura 19: Primera pestaña de metadatos..........................................................................70
Figura 20: Segunda pestaña de metadatos.........................................................................70
Figura 21: Tercera pestaña de metadatos...........................................................................71
Figura 22: Cuarta pestaña de metadatos............................................................................71
Figura 23: Cuadro de diálogo de exportación como SCORM.............................................72
Figura 24: Aspecto de un curso de Moodle con la opción de edición activada...................72
Figura 25: Actividades y recursos de Moodle......................................................................73
Figura 26: Parte de las opciones del recurso SCORM........................................................73
Figura 27: Opciones de cualificación...................................................................................73
Figura 28: Curso de Moodle con el juego disponible..........................................................74
Figura 29: Ventana emergente de confirmación de ejecución de la aplicación Java.........74
Figura 30: Mensajes generados por el SCO en Moodle.....................................................75
Figura 31: Seguimiento de una sesión en Moodle..............................................................76
Figura 32: Tablas de Moodle con datos SCORM................................................................76
Figura 33: Contenido de la tabla mdl_scorm_scoes_track..................................................76
Figura 34: Valoración económica.........................................................................................79
Figura 35: Max sin caracterizar............................................................................................88

Figura 36: Max caracterizado de Dr. Mannhausen..............................................................88
Figura 37: Menú contextual Usar.........................................................................................88
Figura 38: Menú contextual Hablar con...............................................................................89
Figura 39: Menú contextual Opciones.................................................................................90

Introducción, motivación y objetivos
1 IN TR O D U C CI Ó N , MOT I VA CI Ó N Y O B JE TI V O S
1.1 Introducción
Durante las diferentes etapas educativas por las que pasa un estudiante, desde
primaria pasando por secundaria hasta la educación post-obligatoria, se le intenta inculcar
el hábito de estudio basado en métodos ancestrales de concentración, lectura, retención,
memorística. Sin embargo, el ser humano está más capacitado para incorporar conceptos
a su saber relacionándolos con los que ya posee que como un elemento aislado del resto.
En casa, en la calle, con amigos, con familiares o incluso solos los niños aprenden
jugando, que es el método más natural para ellos. Este juego se va transformando con la
edad hasta llegar a ser adultos, cuando se pierde, aunque no debería ser así, ya que los
adultos siguen capacitados para jugar.
Así pues, parece más indicado hacer que los estudiantes aprendan jugando que
utilizando métodos clásicos. Y, por qué no, los juegos electrónicos, por ordenador y
consolas son una manera más de aprender si el juego está pensado para ello.
1.2 Motivación
La idea de que se pudieran utilizar los ordenadores para aprender sobre ordenadores
no es descabellada, más bien al contrario. Y el mundo de las redes y la seguridad
informática es lo suficientemente nuevo como para que lo hecho hasta hoy pueda ser
revisado, mejorado o ampliado.
Tal y como se expondrá en el apartado 1.8.1 Referencias a juegos para el aprendizaje,
existen algunos recursos disponibles para el aprendizaje de conceptos sobre redes y
seguridad. Sin embargo, ni son muchos ni abarcan todo lo que deberían.
Por otro lado, los juegos para el aprendizaje representan una disciplina relativamente
nueva, ya que, aunque hace años que existen, no se ha implantado una metodología
estandarizada, como se comentará en el apartado 1.7 Metodologías para el diseño de
juegos para el aprendizaje.
17

Juegos para el aprendizaje en un aula de educación post-secundaria
Así pues, existen lagunas tanto en la metodología a emplear como en los juegos
diseñados específicamente para el área de la seguridad en redes de telecomunicaciones.
1.3 Objetivo principal
Aunque el diseño del juego para el aprendizaje, al que en una etapa avanzada se le
acabó llamado Max y el Dr. Mannhausen, haya pasado por diferentes etapas iniciales
que han lo modificado hasta dar con lo que se pretendía, las ideas básicas del juego no
han cambiado sustancialmente.
Desde las etapas más tempranas estaba claro que el juego debía ayudar a los
estudiantes, convertidos en jugadores, a entender conceptos relacionados con las redes
de telecomunicaciones y la seguridad de sistemas y redes, de una forma entretenida y
lúdica.
1.4 La influencia del constructivismo
Durante la segunda mitad del s. XX la educación en primaria y la enseñanza en
secundaria se vio influida por los estudios en psicología infantil del biólogo suizo Jean
Piaget, nacido en Ginebra en 1896, quien dedicó gran parte de su vida a casar la ciencia y
la filosofía creando un marco teórico de estudio del conocimiento desde una perspectiva
biológica.
Piaget abogaba por el aprendizaje individual en los niños en etapas o estadios que se
tienen que dar secuencialmente y mediante los cuales el conocimiento se adquiere en dos
fases: en primer lugar, el niño lo asimila y, en segundo lugar, adapta o acomoda sus
estructuras del conocimiento para darle cabida, lo cual conlleva a una reestructuración del
esquema interior. Los estadios, que son sensoriomotor, preoperacional, operacional
concreto y operacional formal, no están ligados estáticamente a un rango de edades, sino
que cada individuo va pasando de uno al otro según sus propias experiencias.
Justamente, por esta construcción del conocimiento en el interior del individuo más que
a venir éste del exterior y ser introducido tal cual, a esta corriente filosófica y pedagógica
se le llamo constructivismo.
Según F. Villar: “Quizá la tesis fundamental de la teoría de Piaget es que todo
18

conocimiento y desarrollo cognitivo es producto, en último término, de la actividad
constructiva del sujeto.” (2003: 300)
Además, Piaget no pensaba en la aplicación de sus ideas al ámbito de la educación,
sino que estaba más preocupado por crear un marco teórico que explicara la adquisición
del conocimiento desde las más tempranas edades hasta la adolescencia. De hecho, la
aplicación práctica de su teoría es mucho posterior a sus estudios.
En la interpretación más radical de las ideas del constructivismo, se podría pensar que
ni el profesor ni el entorno influyen en el proceso de aprendizaje. Sin embargo, de
acuerdo con F. Villar, “desde la posición del desajuste óptimo […] las actividades
apropiadas, que más fomentan el crecimiento cognitivo, serán aquellas que se sitúan un
poco por encima del nivel actual de desarrollo, de manera que planeen un desafío, un
conflicto a las estructuras de conocimiento.” (2003: 303)
Así pues, la función del profesor es la de crear el entorno adecuado de adquisición de
nuevos conocimientos de forma autónoma por parte del alumno, presentándolos como un
reto y no como una dificultad infranqueable.
Como comentan M. L. Barba et al.: “El profesor debe evitar, siempre que sea posible,
ofrecer la solución a un problema o transmitir directamente un conocimiento, ya que esto
impediría que el estudiante lo descubriese por sí mismo, además debe contribuir a que el
alumno comprenda que no sólo puede llegar a conocer a través de otros (maestros,
libros), sino también por sí mismo, observando, experimentando.” (2007: 5)
En este sentido, los juegos en general y los videojuegos para el aprendizaje en
particular suponen una herramienta útil de creación de entornos de aprendizaje con los
que experimentar y en los que se pueden ajustar los niveles de dificultad.
Además, teniendo en cuenta que, citando a F. Villar, “para Piaget […] la actividad del
sujeto en la construcción del conocimiento es fundamental” (2003: 268), la interacción con
un juego facilitaría la adquisición de conceptos con respecto a otras actividades pasivas
como, por ejemplo, una clase magistral.
Por otro lado, según F. Villar: “Piaget sostenía que las propias acciones del individuo
sobre los objetos generan el feedback que contribuye a la modificación de esas acciones
19

(y, en concreto, de los esquemas que subyacen a ellas) y a su reorganización y
coordinación con otras acciones. Desde este punto de vista, el individuo es el causante de
su propio desarrollo y el fundamento de la cognición humana lo hemos de encontrar en la
actividad del sujeto sobre los objetos del mundo que le rodea.” (2003: 282).
Se da el caso que, en un mundo virtual, se pueden disponer los objetos y las acciones
de la manera más adecuada para provocar un reajuste de la estructura de conocimiento
del alumno que le permita desarrollarse.
Como contrapartida, como comenta F. Villar, “el aprendizaje depende en todo caso de
las competencias previas que mostraba el sujeto, ya que este aprendizaje implica recurrir
a las estructuras cognitivas ya presentes para intentar dar sentido a las nuevas
experiencias.” (2003: 295). Esto implica que un juego para el aprendizaje, para ser
efectivo, tendría que dejar claro el nivel educativo y/o la edad de sus participantes, así
como requerir el soporte del profesor para cubrir los requisitos previos ausentes.
1.5 Los 7 principios del aprendizaje
Para diseñar un juego para el aprendizaje, hay que tener en cuenta el proceso
cognitivo y de adquisición de nuevos conocimientos y/o conceptos.
Por la especial relevancia que podrían tener para el diseño de juegos para el
aprendizaje, se indican a continuación cuáles son los 7 principios del aprendizaje del
Carnegie Mellon's Eberly Center for Teacher Excelence1
.
1. El conocimiento previo puede ayudar o dificultar el aprendizaje.
El conocimiento previo de un estudiante interfiere en cómo adquiere el nuevo
conocimiento. Si éste es correcto, preciso y activado en un momento apropiado,
supone una buena base para el nuevo conocimiento. En cambio, si es incorrecto,
impreciso, insuficiente o activado cuando no es el momento adecuado, puede
incluso impedir que se adquiera un nuevo conocimiento.
2. La organización del conocimiento influye en cómo se aprende y en cómo se
aplica lo que se se sabe.
1 https://www.cmu.edu/teaching/principles/learning.html
20

La adquisición del conocimiento se organiza de forma natural en estructuras del
conocimiento que interconectan las diferentes partes. Cuando las conexiones entre
las partes de la estructura del conocimiento se forman adecuadamente y con
significado, el estudiante puede tener acceso al conocimiento de forma efectiva y
eficiente. Por contra, si dichas conexiones se forman aleatoriamente, el estudiante
podría no acceder al conocimiento o hacerlo inapropiadamente.
3. La motivación determina y dirige qué se hace para aprender.
La motivación juega un papel fundamental en la intensidad, la perseverancia, la
calidad y la dirección de aprendizaje de tal manera que, cuando un estudiante
encuentra atractiva una meta, una actividad, espera conseguir un objetivo y percibe
suporte por parte del entorno que le rodea, se encuentra muy motivado para
aprender.
4. Para dominar un conocimiento, se deben adquirir competencias básicas,
integrarlas con las que ya se poseen y saber cuándo aplicar lo aprendido.
El estudiante no tiene simplemente que aprender algo nuevo, sino que debe
aprender a combinar competencias básicas y aplicarlas luego rápida y
autónomamente. Además, es necesario que sepa cuándo y cómo aplicar lo que ha
aprendido. Para ello, tiene que ser consciente de qué competencias posee, para
qué sirven y cómo aplicarlas.
5. La práctica junto con el retorno mejora la calidad del aprendizaje.
El aprendizaje y el rendimiento se fomentan mejor cuando el estudiante practica el
conocimiento orientado a un objetivo, con unos criterios claros, con un nivel de
dificultad adecuado y de forma lo suficientemente frecuente como para mejorar el
rendimiento. De esta práctica tiene que recibir un retorno sobre la consecución de
los objetivos, si se han cumplido o no y, además, en el momento necesario para
que dicho retorno sea útil.
6. La adquisición de conocimiento interactúa con el entorno.
Teniendo en cuenta que el estudiante no está desarrollando sólo su capacidad de
21

aprender sino también sus competencias sociales y emocionales, un clima
adecuado potencia la adquisición de conocimiento mientras que un entorno poco
favorecedor podría incluso impedirla.
7. Para llegar a ser autosuficientes, es necesario monitorizar y ajustar el
aprendizaje.
El estudiante podría estar involucrado en una serie de procesos cognitivos para
monitorizar y controlar su aprendizaje: evaluar la tarea a realizar, evaluar sus
fortalezas y debilidades, planificar, aplicar diversas estrategias y conocer en qué
manera sus técnicas funcionan. Desgraciadamente, esto no ocurre de forma
natural.
1.6 Diseño y desarrollo de juegos para el
aprendizaje
Consultando edX (2016), se pueden extraer ideas y orientaciones para el diseño y
desarrollo de juegos para el aprendizaje que resultan interesantes. Algunas de ellas se
van a comentar en los siguientes subapartados.
1.6.1 Los 4 niveles de libertad
Según Scot Osterweil2
del MIT (Massachusetts Institute of Technology) y creador de la
mítica serie Zoombinis, los juegos para el aprendizaje deben permitir al jugador tomar
decisiones, equivocarse y aprender de los errores. Para ello, pensó en 4 niveles de
libertad (edX; 2016):
1. Libertad de explorar: el juego tiene que permitir que el jugador investigue las
posibilidades que tiene e incluso que determine su objetivo particular.
2. Libertad de equivocarse: se tienen que poder deshacer los cambios.
3. Libertad de probar identidades: diferentes roles del jugador.
4. Libertad de esforzarse: conviene que el jugador pueda mejorar su estrategia.
2 http://education.mit.edu/about/our-team/scot-osterweil/
22

1.6.2 Los 5 principios de los juegos
Según Eric Kopfler3
del MIT, los juegos en general y los de aprendizaje en particular
deben cumplir con 5 principios (edX; 2016):
1. Tomar decisiones interesantes: el jugador debe tomar el control del juego.
2. Consecuencias de las decisiones: cada decisión tomada va a tener una
consecuencia, inmediata (acciones prohibidas) o a medio plazo (tener que volver
atrás), en forma de castigo o de recompensa, según el caso.
3. Retorno o feedback: el jugador tiene que poder ver el resultado de cada acción,
sea positivo o negativo.
4. Objetivos claramente identificados: el jugador debe saber siempre cuál es el
objetivo y cómo llevarlo a cabo.
5. Existencia de un sistema subyacente: detrás del juego, debe haber una historia.
1.7 Metodologías para el diseño de juegos para el
aprendizaje
Aunque el diseño de videojuegos es una disciplina con muchos años de bagaje, la
vertiente educativa y pedagógica de los mismos es demasiado reciente como para que
existan metodologías, buenas prácticas o guías que estandaricen tanto el diseño de
juegos para el aprendizaje como su integración en un entorno educativo.
Aun así, diversos estudios muestran el interés cada vez más creciente de crear
metodologías para el diseño de Serious Games, evaluar los resultados de aplicarlas en
proyectos específicos y mejorarlas en función de los mismos.
Se van a analizar a continuación algunas de las que se han considerado más
relevantes para este proyecto.
Según el estudio realizado por C. E. Catalano, A. M. Luccini y M. Mortara, una posible
metodología para el diseño de juegos para el aprendizaje podría implicar los siguientes
pasos (2014: 5-7):
3 http://education.mit.edu/about/our-team/eric-klopfer/
23

1. Situar el aprendizaje: diseñar el contexto, el entorno y las interacciones adecuadas
para que el aprendizaje sea óptimo; por ejemplo, un diseño 3D no siempre va a ser
el adecuado y las comunicaciones verbales entre personajes puede ayudar en
determinados casos.
2. Minimizar la carga cognitiva: reducirla ayuda a mantener el nivel de atención en el
juego; se consigue diseñando juegos en que el aprendizaje es rápido.
3. Implicar al estudiante: es necesario hacer que el estudiante se sienta involucrado y
motivado durante una sesión de juego.
4. Facilitar el aprendizaje: se realizaría en tres pasos, que son (1) indicar las reglas
del juego, poner de manifiesto el conocimiento previo e indicar los objetivos de
aprendizaje; (2) guiar al estudiante durante las sesiones de juego; y (3) evaluar el
aprendizaje realizado y transferirlo a un entorno real.
5. Flexibilidad, reusabilidad y explotación: por un lado, disponer de una variedad de
situaciones y escenarios va a permitir reutilizar el juego en diversos contextos; por
otro lado, las posibilidades de explotación del juego van a depender de su
portabilidad y capacidad de exportación a varias plataformas.
De acuerdo con el estudio llevado a cabo por I. Marfisi-Schottman, S. George y F.
Tarpin-Bernard, el proceso de ingeniería para diseñar un juego para el aprendizaje
pasaría por siete etapas en las que intervendrían diferentes roles (2010: 4).
Estas etapas o pasos, que no tienen por qué ser seguidos en estricto orden, son:
1. Especificar los objetivos pedagógicos: tras un estudio del dominio de aprendizaje y
de los conocimientos y habilidades necesarios en el mismo, se marcan unos
objetivos pedagógicos a cumplir por el Serious Game.
2. Elección del modelo: en este punto se debe escoger el tipo de juego; por ejemplo,
tablero, investigación, aventuras o puzzle.
3. Descripción general del escenario y el entorno virtual: definición de la historia, los
personajes y los lugares en que ésta transcurre.
24

4. Búsqueda de componentes reusables: si se dispone de una base de datos de
componentes software, se tendrían que buscar los que pudieran ser reusables y no
tener que diseñarlos desde cero.
5. Descripción detallada del escenario: para cada una de las escenas hay que
describir qué personajes intervienen, los diálogos, las características de la escena,
etc.
6. Control de calidad pedagógico: se deben realizar simulaciones para verificar que
no existen callejones sin salida y que se cumplen los requisitos pedagógicos.
7. Especificaciones precisas para las subcontratas: en el caso de intervenir personal
externo en el proyecto, deben quedar especificadas las condiciones de la
subcontrata.
Por último, cabe comentar la propuesta de L. El Aachak, A. Belahbib y M. Bouhorma,
consistente en una metodología no lineal sino cíclica compuesta de cinco etapas
principales (2013: 2).
Éstas serían (véase la Figura 1):
1. Análisis de necesidades: definición de las características del juego, de las
habilidades y conocimientos a adquirir y de los objetivos pedagógicos a cumplir.
2. Diseño: desarrollo de la historia, los
escenarios, el flujo de la historia por los
mismos, descripción de los personajes y
sus características, diálogos, niveles del
juego, objetos con sus características,
interacciones, etc.
3. Prototipo y desarrollo: en una etapa
temprana se puede modelar con UML el
juego pero posteriormente se tendrá que
desarrollar un prototipo intentando que,
al final, el juego sea compatible con el
25
Figura 1: Metodología propuesta por El Aachak et al.
Análisis de necesidades
Diseño
Evaluación
ValidaciónPrototipo y desarrollo

mayor número de plataformas y además extensible o escalable.
4. Validación: ya desde el primer prototipo, se deberá realizar una comprobación de
que se cumplen los objetivos pedagógicos marcados y de que el juego no tiene
errores o funcionamientos erróneos o no deseados.
5. Evaluación: entre otros criterios, comprobar la robustez, fiabilidad, portabilidad,
eficiencia y mantenibilidad del juego creado.
1.8 Estado del arte
1.8.1 Referencias a juegos para el aprendizaje
Hoy en día existen muchas páginas web que ofrecen juegos en línea, aunque la gran
mayoría sólo contemplan la vertiente lúdica.
Acotando un poco, interesa centrarse en los juegos para el aprendizaje y, concretando
algo más, en los que permiten aprender conceptos sobre redes y seguridad.
Algunos ejemplos son:
• The Cisco Learning Network4
: juegos para aprender a manejar encaminadores,
conceptos sobre VPN o el sistema binario.
• NICCS5
: recursos relacionados con la seguridad informática, desde juegos para el
aprendizaje hasta cursos en línea.
• CyberCIEGE6
: juego para el aprendizaje de conceptos sobre ciberseguridad creado
en parte por la Marina de los EEUU.
1.8.2 Proyectos sobre juegos para el aprendizaje
El desarrollo de Serious Games ha tomado cada vez más relevancia, especialmente en
universidades e institutos de investigación.
Prueba de ello es la existencia de cada vez más proyectos sobre juegos para el
4 https://learningnetwork.cisco.com/games
5 National Initiative for Cybersecurity Careers and Studies – Department of Homeland Security – EEUU
https://niccs.us-cert.gov/education/cyber-games-and-programming
6 http://cisr.nps.edu/cyberciege
26

aprendizaje, como por ejemplo:
• En el ámbito nacional:
◦ Proyecto eAdventure de la Universidad Complutense de Madrid, compuesto de
un editor de juegos de aventuras y simuladores y de un motor para la ejecución
de los mismos. Se explicará en detalle en el apartado 2.2 Motor eAdventure.
◦ Proyecto Beaconing, en el que participa la Universidad Complutense de Madrid
y dirigido desde la Universidad de Coventry, Reino Unido. Está basado en la
mezcla de espacios físicos y virtuales.
◦ Aprendizaje activo y adaptativo con herramientas innovadores adaptadas en el
juego, proyecto de la Universidad Carlos III de Madrid.
• En el ámbito internacional:
◦ SGI7
(Serious Game Institute), University of Coventry, Reino Unido.
◦ Game Design Project8
, Delft University of Technology, Holanda.
◦ Media and Information department at Michigan State University9
, EEUU.
7 http://www.seriousgameinstitute.co.uk/applied-research/research-links.aspx
8 http://www.tbm.tudelft.nl/en/cooperation/facilities/serious-gaming/serious-gaming-education
9 http://seriousgames.msu.edu
27

Entorno de desarrollo
2 EN TO RN O D E DE S A R R OL LO
En este apartado se relacionan las herramientas utilizadas para el diseño y desarrollo
del juego.
Cabe destacar que, en la medida de lo posible, se han buscado herramientas Open
Source disponibles también para sistemas operativos diferentes del utilizado: Ubuntu
GNU/Linux.
2.1 Herramientas para el desarrollo de videojuegos
De los programas o software para el diseño y desarrollo de videojuegos, sean o no de
la categoría de juegos para el aprendizaje, conviene citar los siguientes:
• Construct 2:
Es una herramienta muy intuitiva y adecuada para principiantes de creación de
código HTML5 basada en entidades, elementos, sucesos y comportamientos.
Permite exportar el código también para Windows, Mac, Linux, Android e iOS
utilizando wrappers, que se encargan de que éste sea ejecutable en el sistema
anfitrión.
• CryEngine:
Se trata de un entorno de desarrollo para juegos con grandes efectos especiales y
realismo.
Permite diseñar juegos para Windows, Android, iOS, PS3, PS4, Xbox 360, Xbox
One y Wii U.
• eAdventure:
Entorno de desarrollo creado por un grupo de investigación de la Universidad
Complutense de Madrid, especialmente pensado para el diseño de juegos para el
aprendizaje de tipo aventura y/o simulación.
29

Es multiplataforma y permite la exportación a diversos formatos, entre los cuales:
ejecutable Java, eAdventure (para su ejecución en el motor), paquete SCORM o
paquete AGREGA.
• Game Maker Studio:
Es una herramienta de desarrollo que permite crear proyectos ya sea arrastrando
elementos al juego o codificando con un lenguaje de script propio llamado GML. El
proyecto puede ser exportado como una aplicación para iOS, Android, un
ejecutable para Windows o código HTML5 para subirlo a la web.
• GameStylus:
Se trata de un motor gratuito para el diseño y la ejecución de juegos especialmente
creado para juegos de aventuras en plataformas móviles, como por ejemplo
Android.
• ITyStudio:
Herramienta de creación de Serious Games y simulaciones 3D pensada para
responsables de formación, jefes de proyectos e-learning, desarrolladores de
contenidos pedagógicos, etc.
Dispone de una biblioteca de personajes y escenarios cuyas características se
pueden modificar. Es posible también elegir entre diferentes movimientos y
comportamientos de los personajes.
• Leadwerks:
Esta herramienta está especializada en el desarrollo de juegos para Linux, aunque
también es posible crear código para Mac y Windows.
Dispone de un motor OpenGL, un editor de código script y un editor de grafos
dirigidos.
30

• Project Anarchy:
Este entorno de desarrollo, de la compañía Havok, está orientado al desarrollo de
videojuegos para móvil (iOS, Android y Tizen). La exportación a ejecutable
Windows requiere el pago de una licencia.
• Scratch:
Creado y mantenido por el MIT y pensado especialmente para niños y jóvenes
entre 8 y 16 años, esta herramienta permite diseñar juegos fácilmente mientras se
aprenden las bases de la programación.
• ShiVa:
Entorno que, en su versión 2, permite desarrollar tanto para PC como para móvil.
Dispone de un lenguaje de script propio basado en Lua y de un editor para
texturas, terrenos y océano.
Permite el desarrollo para Android, Blackberry, iOS, Linux, Mac, Windows, PS3,
StreamOS, Vita, Wii y Xbox 360.
• Sploder:
Es una herramienta web basada en Flash de creación de juegos mediante el
arrastre de elementos a las escenas. Los juegos que permite crear son de cinco
tipo: Retro Arcade, Platformer, Physics Puzzle, Classic Shooter y 3D Adventure.
Dispone además de una herramienta para crear elementos gráficos.
• Storyline 2:
Herramienta de la compañía Articulate de creación de entornos de e-learning y
juegos para el aprendizaje. Permite la creación de preguntas, bancos de preguntas,
cuestionarios y árboles de decisión. Los diseños se pueden exportar como HTML5,
Flash e incluso SCORM para su integración en un entorno de aprendizaje.
31

• Turbulenz:
Herramienta de desarrollo exclusivamente para HTML5. Es gratuita aunque el
alojamiento y compartición en la web del proyecto tiene coste.
• UDK:
Unreal Development Kit es la versión gratuita de Unreal Engine 3 de Epic Games.
Al tratarse de un entorno completo de programación, se puede utilizar para un
amplio rango de videojuegos, aunque está más bien pensado para juegos de tipo
arcade en primera persona.
Requiere de conocimientos de programación en la versión propia de JavaScript del
entorno, llamada UnrealScript.
Además, para juegos que salgan al mercado, Epic Games puede solicitar hasta un
25% de los beneficios.
• Unity3D:
Es un entorno de desarrollo de videojuegos que permite al desarrollador centrarse
en la interfaz de usuario (acabados, efectos, animaciones, etc.), especialmente en
juegos 3D, aunque se siguen necesitando conocimientos de programación.
Unity potencia los videojuegos de tipo arcade con grandes efectos especiales y
realismo. En sus últimas versiones, se ha hecho un gran esfuerzo por que sea la
herramienta de desarrollo de juegos realistas para Android. Soporta el desarrollo
para Windows, Mac, Linux, Android, iOS, PS3, Xbox360, Wii U y para entorno web.
La gran baza de Unity es el Asset Store, un almacén de creaciones de usuarios
que permite compartir elementos entre desarrolladores para no tener que crear lo
que otro ya ha diseñado.
2.2 Motor eAdventure
Una vez logrado un objetivo y con una primera idea en mente, se empezaron a buscar
entornos de desarrollo que pudieran facilitar el diseño y desarrollo teniendo en cuenta que
32

sólo una persona con un tiempo limitado no puede realizar todas las tareas de diseño del
juego, diseño de las imágenes, desarrollo y programación, pruebas, etc.
Así pues, después de tener en cuenta entornos de prestigio y reconocidos comentados
en el apartado 2.1 Herramientas para el desarrollo de videojuegos, se escogió el
framework eAdventure10
desarrollado en la Facultad de Informática de la Universidad
Complutense de Madrid dentro del proyecto e-UCM. Más específicamente, se ha utilizado
la versión 1.5 RC4 del motor de eAdventure.
El principal motivo es que, como entorno creado para el diseño de juegos para el
aprendizaje, eAdventure permite adaptar el juego a diferentes perfiles (por ejemplo, edad
de los jugadores) y evaluar al jugador, lo cual es ideal en un entorno educativo.
Hay que añadir que eAdventure iba a simplificar mucho el desarrollo del juego
permitiendo el centrar los esfuerzos en la historia, las escenas y los objetivos didácticos,
ya que este entorno tiene la particularidad de no tener que programar ni una sola línea de
código, sino que basa en escenas, personajes y objetos, las acciones que unos pueden
realizar sobre otros y los efectos que producen estas acciones.
Además, se trata de un software sin licencia comercial, multiplataforma y con soporte
técnico a través de foros.
2.2.1 Características principales
El entorno eAdventure permite el diseño y desarrollo de juegos para el aprendizaje por
parte de docentes o profesionales no cualificados específicamente en el desarrollo de
videojuegos.
Entre las características, las más relevantes son:
• Diseño por escenas, personajes, diálogos y objetos sobre los que se pueden
realizar determinadas acciones como usar, coger o examinar.
• Ideal para juegos donde tiene más protagonismo la historia que la acción.
• Permite la creación de libros en formato HTML, en los que se muestra información
10 http://e-adventure.e-ucm.es
33

adicional al estudiante.
• Permite la exportación como Objetos de Aprendizaje (OA) para integrar el juego en
Entornos Virtuales de Enseñanza (EVE), como por ejemplo Moodle, o para incluirlo
en repositorios como AGREGA11
.
• Permite realizar una adaptación del juego a las necesidades de los estudiantes.
• Permite crear informes de evaluación que, además, pueden ser enviados por
correo electrónico o incluso suponer una evaluación en el EVE, facilitando la tarea
del docente.
• No es necesario un ordenador con características especiales para su ejecución.
2.2.2 Casos de uso
Además del repositorio existente en la web oficial del proyecto, se han encontrado
estos otros:
• Centro aragonés de tecnologías para la educación12
.
• Grupo de investigación LibreSoft de la Universidad Rey Juan Carlos de Madrid.
• Proyecto de la Universidad Francisco de Paula Santander de Cúcuta (Colombia) de
desarrollo de 8 juegos para la enseñanza del inglés a niños de 6 a 10 años13
.
2.2.3 Funcionalidades presentes
Para obtener una descripción completa de las funcionalidades del entorno eAdventure
es preferible remitirse al manual de usuario disponible en la web del proyecto. No
obstante, se van a comentar aquí las funcionalidades presentes que más han influido en
la elección de este entorno de diseño y desarrollo de juegos para el aprendizaje (véase la
Figura 2).
11 http://www.proyectoagrega.es
12 http://www.catedu.es/webcateduantigua/index.php/descargas/e-adventures
13 http://www.emadridnet.org/experiencia-eadventure-colombia
34

Cabe destacar:
1. Escenas:
El juego se compone de escenas que se van sucediendo y de las que es posible
recoger objetos para utilizarlos en otras.
En ellas el protagonista puede ser mostrado (juegos en tercera persona) o no
(juegos en primera persona). En general, los primeros suelen contener escenas
ficticias o fantásticas mientras que los segundos suelen contener escenas realistas
e incluso fotografías de escenas reales.
2. Libros:
El aprendizaje de los estudiantes se puede reforzar con la introducción de libros
35
Figura 2: Algunas de las opciones de eAdventure

creados en formato HTML accesibles desde el juego.Estos libros pueden ayudar a
comprender conceptos introducidos en las escenas que de otro modo podrían ser
malinterpretados o requerirían la intervención del docente.
3. Conversaciones:
Los personajes tienen conversaciones con el protagonista, la estructura de las
cuales tiene forma de grafo, es decir, que no son lineales. El flujo de la
conversación hacia uno u otro nodo es fruto de la decisión del jugador.
4. Perfiles:
El juego permite crear perfiles de adaptación y perfiles de evaluación. Los primeros
sirven para adaptar el juego a distintos tipos de estudiantes. Por ejemplo, se
podrían mostrar botones de ayuda en unos casos y ocultarlos en otros. Los
segundos se utilizan para evaluar el progreso del estudiante creando un informe en
el que se le indica qué acciones han sido correctas y cuáles es necesario corregir o
evitar.
5. Integración:
Cabe la posibilidad de exportar el juego como un módulo SCORM para ser
integrado posteriormente en un EVE.
En el apartado 4 Integración en Moodle como paquete SCORM, se explicará en
detalle cómo realizar la integración del juego como un módulo SCORM en un curso
Moodle, aunque el proceso es aplicable a cualquier otro EVE.
2.2.4 Funcionalidades ausentes
Lo cierto es que eAdventure es un entorno muy completo y se podría decir que pocas
son las funciones que se han echado en falta. Aun así, hay algunas que cabría citar aquí:
1. No siendo una funcionalidad en sí, habría sido de gran ayuda un foro con soporte
técnico, ni que fuera de otros usuarios registrados con más experiencia.
2. Por otro lado, un banner en la parte superior con el estado del juego habría sido
36

muy interesante para indicar el tiempo transcurrido, la puntuación obtenida al coger
o usar un objeto, la puntuación total y algún otro parámetro de progreso de la
partida.
Si bien cabe la posibilidad de definir temporizadores y variables, quedan
restringidos al uso interno del juego, ya sea para hacer o no disponible un objeto,
una escena, cambiar una salida o calcular tiempos para el informe de evaluación.
3. Asimismo, sería un avance importante en el motor de eAdventure el soporte para
diversos idiomas, en relación al juego desarrollado.
De esta manera, el jugador podría seleccionar el idioma de los diálogos y las
descripciones de los objetos sin necesidad de crear un juego para cada idioma o
aumentar la complejidad del desarrollo, ya que actualmente los textos están
integrados en el propio juego (hardcoded).
En la Figura 3 se muestra cómo se ha implementado el soporte para múltiples
idiomas. Las características de los objetos, los diálogos y, como se puede observar,
los textos en las acciones, se han triplicado añadiendo una condición según el valor
de la variable idioma: 1 para español, 2 para inglés y 3 para francés.
No obstante, en algunos casos, aunque afortunadamente no muchos, no ha sido
posible implementar una traducción, ya que no había condiciones para, en función
37
Figura 3: Implementación de la traducción a diversos idiomas

del idioma, mostrar un texto u otro. Es el caso, por ejemplo, del texto de
información de los personajes (véase la Figura 4).
2.3 Diseño de imágenes
Prácticamente todas las imágenes utilizadas durante el diseño del juego han sido
descargadas de www.freepik.es, quien otorga licencia de uso no comercial si se informa
de la fuente. Algunas imágenes estaban en formato PNG, pero la mayoría eran dibujos
vectoriales, lo cual ha permitido hacer modificaciones mucho más fácilmente, aunque
cierto es que ha sido necesario aprender a utilizar la herramienta Inkscape Vector
Graphics Editor. Una vez modificadas, eran exportadas como PNG para importarlas
luego en GIMP, ya que algunas herramientas (como el uso de transparencias, las capas o
aplicar perspectiva) son allí más fáciles de utilizar o más intuitivas.
Se ha intentado que todas las imágenes tengan un tamaño en píxels adecuado a la
escena y un tamaño en disco mínimo disminuyendo su resolución. El nombre de fichero
está estandarizado a esc_escena_objeto.png, donde escena hace referencia a la escena
donde se va a utilizar y objeto es el nombre o breve descripción del mismo.
2.4 Diseño de vídeos
Para la composición de vídeos al principio y final del juego, después de buscar
programas no licenciados comercialmente y que pudieran hacer lo que se necesitaba
(mover texto por la pantalla o, como se le conoce, kinetic typography), el elegido fue
Synfig Studio.
Lo cierto es que no es una herramienta muy intuitiva y su uso costó muchas horas de
aprendizaje. No obstante, al final ha valido la pena, no sólo por permitir crear los vídeos
para el proyecto, sino por haber aprendido a utilizar una herramienta de este tipo.
38
Figura 4: Texto asociado a un personaje

Una vez creados los vídeos, surgió el problema de exportarlos a AVI o MPEG, ya que
no podían ser utilizados directamente por el motor de eAdventure. El motivo es que Synfig
utiliza MPEG-4 por defecto y, en las opciones de exportación, no permite seleccionar más
que las librerías de conversión, pero no el formato.
Después de mucho probar con unas librerías, con otras, con un tipo de contenedor, con
otro, una primera solución fue utilizar avconv, herramienta de línea de comandos, que
permite la conversión de formatos de vídeo. Sin embargo, avconv introducía a su vez otro
problema, el de la mala calidad de la imagen generada.
Entonces, hubo que buscar otra solución, que pasó por ser el uso de un conversor en
línea. En este sentido, la web www.online-convert.com ofrece un servicio muy adecuado
de conversión de varios formatos, entre los cuales MPEG-1, de calidad aceptable.
2.5 Diseño de sonidos
Los sonidos han sido descargados de www.sshhtt.com y posteriormente modificados
mediante el programa Audacity, que permite, entre muchas otras opciones, cortar, copiar y
pegar partes de una pista de audio, aplicar fade in y fade out para suavizar el comienzo y
fin de la pista, respectivamente, o acotar el nivel de decibelios de la pista.
39

El juego: Max y el Dr. Mannhausen
3 EL J UE G O : MA X Y E L DR. MA NNH AU S E N
3.1 Metodología empleada
Teniendo en cuenta que este proyecto no está enfocado al desarrollo de software sino
a la aplicación pedagógica y didáctica de los videojuegos, que está realizado por una sola
persona y, como se expuso en el apartado 1.7 Metodologías para el diseño de juegos
para el aprendizaje, que no existe una metodología única y estandarizada para el diseño
de Serious Games, el diseño de Max y el Dr. Mannhausen pasó por un conjunto de
fases muy similar al propuesto por I. Marfisi-Schottman, S. George y F. Tarpin-Bernard
pero sin las etapas de reutilización de componentes y especificaciones para las
subcontratas, ya que ni hay componentes a reutilizar ni existe una subcontratación de
partes del desarrollo.
Estas etapas, que se van a comentar en detalle en los siguientes subapartados, fueron
las siguientes:
1. Especificación del contexto educativo y de los objetivos didácticos.
2. Elección del tipo de juego y la herramienta de diseño.
3. Descripción general de las escenas y la historia.
4. Descripción detallada y especificación de las metáforas.
5. Validación.
El proceso de diseño y desarrollo ha seguido una metodología de tipo Agile, compuesta
de esas fases, que han sido cíclicas en los últimos pasos, ya que la validación se ha
realizado escena por escena, comprobando que el diseño de nuevos elementos cumplía
con los objetivos pedagógicos y se correspondían con la historia del juego y, sobretodo,
que no interferían con los elementos ya diseñados al integrarlos. En la Figura 5 se
muestran las fases por las que pasó el diseño del juego.
41

En una primera fase, fue importante plantearse qué realizar y para quién. Eran
condiciones necesarias para empezar incluso a pensar en una idea. Así pues, había que
encontrar el destinatario del aprendizaje y los objetivos didácticos.
3.1.1 Principios del aprendizaje
Los principios del aprendizaje del Carnegie Mellon's Eberly Center for Teacher
Excelence comentados en el apartado 1.5, una vez aplicados a Max y el Dr.
Mannhausen, serían:
1. El conocimiento previo sólo es importante en cuanto a conceptos generales de
redes de telecomunicaciones, aunque cabe comentar que es preferible que los
estudiantes no tengan ningún conocimiento de seguridad, pues en muchas
ocasiones suele éste ser poco preciso o incluso erróneo.
2. Se espera que la organización del conocimiento se realice constructivamente en
base a la experiencia que el juego permite al estudiante.
3. Por un lado, el uso de tecnologías para la educación suele ser un primer promotor
de la motivación del estudiante y, por otro lado, tratarse de un juego con un
personaje con el que se pueden sentir en cierta manera identificados, debería
motivar a los estudiantes aún más si cabe.
4. El juego ayudará a los estudiantes a dominar un conocimiento al permitirles
asociar los conceptos a una situación concreta en la que estos tienen uso.
5. La práctica junto con el retorno mejora la calidad del aprendizaje y esto se
consigue gracias a la gran interacción que supone el juego.
6. El aula como entorno va a permitir que los estudiantes interactúen no sólo con el
juego sino entre sí, comentando antes, durante o después de la partida los
42
Figura 5: Fases de diseño utilizadas (metodología propia)
Especificar objetivos Tipo de juego Descripción general Descripción detallada
Validación

conceptos que consideren claves.
7. Los estudiantes podrán ser autosuficientes con varias sesiones de juego que les
permitan mejorar hasta comprender los conceptos, los objetivos del juego y los
objetivos didácticos; incluso se puede plantear que los estudiantes colaboren entre
sí, creando grupos o bien haciendo que los más aventajados ayuden a los que van
a la zaga.
3.1.2 Niveles de libertad
Los 4 niveles de libertad de Scot Osterweil comentados en el apartado 1.6.1, al
aplicarlos a Max y el Dr. Mannhausen, serían:
1. Libertad de explorar:
El jugador podrá coger unos objetos, intentar combinarlos con otros, dárselos a
otros personajes o incluso arrastrarlos a otros objetos o zonas. Tendrá que
investigar qué posibilidades hay y cuáles convienen según el caso.
2. Libertad de equivocarse:
El jugador podrá moverse de una escena a otra y volver a la anterior si así le
conviene.
3. Libertad de probar identidades:
Este nivel de libertad es más difícil de integrar en el juego una vez descartada la
idea del “bueno” y el “malo”. No obstante, en cierta manera, el hecho de que el
jugador tiene que disfrazar a Max de Dr. Mannhausen para poder continuar en
cierto momento hace que el jugador pruebe ambos roles. Concretamente, en la
entrada a Quantum Corp, el comportamiento del guarda de seguridad es diferente
según Max vaya disfrazado o no.
4. Libertad de esforzarse:
Durante la partida, las acciones a emprender no son obvias, aunque se pueden
deducir y/o ir probando. Y al recibir el informe de evaluación, el estudiante podrá
43

volver a jugar esforzándose más en hacer un mejor tiempo o en responder más
adecuadamente en los diálogos.
3.1.3 Principios del juego
Los 5 principios de los juegos de Eric Kopfler comentados en el apartado 1.6.2,
aplicados a Max y el Dr. Mannhausen, serían:
1. Tomar decisiones interesantes: en Max y el Dr. Mannhausen, las decisiones
hacen que el jugador tome el control del juego (coge o no un objeto, entra en una
sala u otra, prueba diferentes combinaciones de objetos).
2. Consecuencias de las decisiones: en algunos casos, el jugador simplemente
perderá tiempo en acciones inertes, que no llevan a nada, mientras que, en otros
casos, las decisiones llevarán al avance de la partida.
3. Retorno o feedback: los comentarios de Max, el protagonista, informan al jugador
sobre la consecuencia de sus decisiones, sean correctas o no.
4. Objetivos claramente identificados: existen varios objetivos (mejor tiempo y
mínimos errores en las respuestas de los diálogos, a lo que se suma la consulta o
no de libros durante el juego), todos ellos comentados en el informe de evaluación
final.
Existencia de un sistema subyacente: en el juego a desarrollar, sería la historia de
Max buscando a su tío y los documentos del proyecto del ordenador cuántico.
3.2 Contexto educativo
Este proyecto ha sido concebido para estudiantes del ciclo formativo de grado medio
de Sistemas Microinformáticos y Redes, más específicamente en los del primer curso,
ya que es donde se adquiere el conocimiento básico de redes y se asientan las bases
para las habilidades en seguridad informática.
Si bien la normativa no impide hacerlo de otra manera, la mayoría por no decir todos
los centros educativos de Catalunya imparten durante el primer curso el módulo
44

profesional MP05 de Redes Locales (165 horas) y durante el segundo curso MP06 de
Seguridad Informática (132 horas).
A pesar de que está diseñado para alumnos del ciclo formativo de grado medio de
Sistemas Microinformáticos y Redes, se podría utilizar en alumnos de educación
secundaria para los que se quiera extender el currículo en tecnología e informática.
3.3 Objetivos didácticos
Este proyecto consiste en el diseño y desarrollo de un juego para el aprendizaje o
Serious Game sobre redes de telecomunicaciones y seguridad informática aplicada las
mismas.
Antes incluso del diseño del juego, se planteaban una serie de objetivos didácticos que
justificarían el fin mismo de éste. Se podrían citar los siguientes:
• Distinguir entre distintas topologías de redes
• Entender el concepto de encaminamiento o routing
• Entender y contrarrestar los ataques MITM (man in the middle)
• Entender el concepto de servicio
• Entender el concepto de vulnerabilidad
• Entender y contrarrestar los ataques DoS (Denial of Service) y DDoS (Distributed
Denial of Service)
• Aprender el uso de medidas de seguridad como cortafuegos, IDS / IPS, honeypots,
etc
No obstante, a medida que se desarrollaba el juego, se pudo constatar que no todos
los objetivos se podrían lograr, ya fuera por falta de tiempo ya fuera por no ser posible
adaptar o modificar el juego para incluirlos.
45

3.4 Herramienta de desarrollo
Después de considerar varias herramientas de desarrollo de videojuegos, comentadas
en el apartado 2.1 Herramientas para el desarrollo de videojuegos, el entorno escogido
fue eAdventure.
Las características de este singular framework se comentaron en detalle en el apartado
2.2 Motor eAdventure.
Tras comprobar el potencial de eAdventure, las posibilidades que tiene y conocer sus
limitaciones, el siguiente paso fue centrarse en tener una idea sobre la cual trabajar.
3.5 Tipo de juego
Se valoró en un principio diseñar un juego en primera persona (sin personaje principal)
que pudiera jugar tanto el rol de “bueno” como de “malo” en un juego consistente en
atacar o defender un conjunto de servidores y redes, dependiendo del rol. El objetivo del
“bueno” sería mantener las medidas de seguridad correctas instalando equipos como
cortafuegos, IDS/IPS, honeypots, etc., configurar subredes, actualizar las aplicaciones y
los sistemas operativos, etc. El objetivo del “malo” sería buscar sistemas vulnerables
(poco actualizados, con varios servicios o mal configurados). Sin embargo, esta opción se
desechó porque era demasiado explícita y los objetivos didácticos quedaban al
descubierto en el juego. Dicho de otra manera, el uso de metáforas se tenía que imponer
frente a un juego directo sobre redes y seguridad, ya que el estudiante suele poner más
empeño en aquello que no está directamente relacionado con sus estudios.
Fijando entonces la atención fuera de ese modelo de juego directo, había que
encontrar un juego divertido, implementable a medio plazo, didáctico y relacionado con las
redes y la seguridad. Todo un reto.
Después de mucho pensar, tomaba cada vez más forma la idea de que la historia del
juego podría tener algunos componentes relacionados con la informática para hacerla
más afín al contexto educativo para el que iba a ser diseñado el juego, sin desplazarse de
la idea de utilizar metáforas para comprender los conceptos de interés.
De esta manera nació la idea de un personaje llamado Max, estudiante del grado de
46

ingeniería informática, que se moviera por distintas escenas recogiendo, combinando y
utilizando objetos con la finalidad de encontrar a un tío suyo, el Dr. Mannhausen,
encargado de llevar adelante un proyecto de diseño de un ordenador cuántico.
En la actualidad puede parecer absurdo, pero a mediados de los 90, se comentaba que
aplicar nanotecnología al diseño de procesadores cada vez más pequeños, más rápidos y
con más transistores llevaría a que los electrones saltarían de una pista a otra, siendo
necesario aplicar leyes de la física cuántica en lugar de la física tradicional. De ahí que el
proyecto novedoso del Dr. Mannhausen pudiera estar relacionado con ese área de la
informática y la electrónica.
3.6 Diseño y descripción general de las escenas
El tipo de juego escogido es el de un protagonista en tercera persona que se moverá
por diferentes escenas de las que tendrá que recoger algunos objetos para utilizarlos
posteriormente.
En las escenas se encontrará con personajes con los que podrá mantener diálogos y
que le darán información sobre como continuar o qué pasos seguir. Además, habrá libros
para aclarar conceptos o dar información adicional al jugador.
Este tipo de juego es muy frecuente al margen de los Serious Games. Algunos
ejemplos clásicos son: Monkey Island, The Day of the Tentacle o Alone in the dark. Como
sucede en el mundo de la música, en que un artista es, en parte, una mezcla de la música
que ha escuchado previamente, las ideas para escoger el tipo de juego han estado muy
influenciadas por esos juegos.
3.6.1 Objetivo real del juego
En los sistemas de información de Quantum Corp, una empresa al borde de la quiebra
por falta de presupuesto para su proyecto estrella, el ordenador cuántico, se halla la clave
para diseñar un ordenador 30 veces más potente que el más potente de los
supercomputadores actuales. Al cargo estaba uno de los científicos de más renombre, el
Dr. Mannhausen, que desapareció meses atrás misteriosamente.
Una organización criminal anda tras ello, así que el protagonista, un recién graduado
47

de informática llamado Max y sobrino del científico, tendrá que seguir las pistas hasta
encontrar las ideas del Dr. Mannhausen y evitar que caigan en manos de mentes
malévolas.
3.6.2 Especificación de las metáforas
El enfoque para aprender determinados conceptos es el de las metáforas, es decir,
que en lugar de presentar una serie de situaciones, objetos o planteamientos propios del
dominio de las redes y de la seguridad informática, se va a optar por situaciones, objetos
o planteamientos cotidianos que, en cierta manera, hagan pensar o tengan relación con
los del dominio anterior, que es el que interesa.
En la siguiente tabla se muestran los conceptos que, a priori, iban a estar presentes en
el juego y las metáforas que se iban a usar:
Concepto Metáfora
Cifrado del César
En determinadas partes del juego, se presentará como
reto descifrar un mensaje utilizando el método del César.
Cifrado con escítala
En diferentes escenas del juego aparecerán objetos
cilíndricos que se podrán combinar con un papel que
contiene un mensaje cifrado con el método de la
escítala. Sólo uno de los objetos, que representará la
clave de cifrado, será el que permita descifrar dicho
mensaje.
Ataque MITM (man in the
middle)
En un momento dado, se hará que un personaje se
tenga que comunicar con otro de manera que no estén
los dos en la misma escena y el mensaje será
interceptado y modificado por un tercero. Para evitarlo y
continuar con el juego, habrá que cifrar el mensaje.
Ataques DoS (Denial of
Service) y DDoS
(Distributed Denial of
Service)
Para avanzar en el juego, en una determinada escena,
habrá que cansar a un personaje solicitándole algo (un
servicio). Como el personaje cumplirá con su cometido,
el protagonista tendrá que solicitar a otros personajes
que hagan lo mismo, hasta cansar al que proporciona el
servicio.
Ataque por fuerza bruta
En un momento dado, el protagonista tendrá que probar
varias llaves para entrar en una sala.
48

Concepto Metáfora
Suplantación de identidad
El acceso a determinadas escenas del juego estará
limitado a algunos personajes, así que el protagonista
tendrá que disfrazarse de uno de ellos para conseguirlo.
Algunos objetos de otras escenas se podrán usar sobre
el protagonista para disfrazarlo, por ejemplo, una bata de
médico, unas gafas de aumento de empollón, una
camisa azul y una gorra de policía, etc. No obstante, sólo
uno de ellos le dará el acceso.
Cortafuegos
Un personaje prohibirá el acceso a determinadas zonas
o escenas y el protagonista tendrá que convencerle para
que le deje pasar.
Encaminamiento o routing
En una determinada escena el protagonista tendrá que
hacer llegar cierto objeto a un punto lejano y, para ello,
tendrá que entregárselo a un personaje para que lo lleve.
Encapsulamiento
Habrá algún objeto que, para poder ser entregado a otro
personaje, tendrá que ser embalado en un papel que se
encontrará en otra escena.
Vulnerabilidad
El personaje tendrá que aprovechar la imperfección de
algún objeto o elemento para lograr su objetivo.
Sin embargo, conforme el diseño del juego avanzaba escena a escena, algunas
metáforas fueron cambiadas ya fuera por dificultad de implementación ya fuera por
encontrar una más adecuada a la escena en curso de diseño.
Las metáforas finalmente empleadas se describen detalladamente para cada una de
las escenas en el siguiente apartado.
3.7 Descripción detallada de las escenas
El juego se compone de 7 escenas, de las cuales la primera es también la última, es
decir, que el juego empieza y termina en la misma escena. En la Figura 6 se puede
observar el flujo del juego.
49
Figura 6: Flujo entre las escenas
Inicio
Despacho del
Dr. Mannhausen
Fin
Recepción
Departamento
I+D
Entrada a
Quantum Corp
(desde la calle)
Sala del personal
de limpieza
Despacho de la
Dirección
Entrada a
Quantum Corp
(puerta de cerca)

Como se puede observar, una vez que se entra a Quantum Corp no es posible volver
atrás. Desde la recepción sí que se puede ir y volver al resto de escenas directamente
conectadas tantas veces como sea necesario.
Al iniciar el juego, la primera interacción del estudiante será escoger el idioma, como se
muestra en la Figura 7.
A continuación, para cada una de las escenas, se va a comentar los elementos que
contiene, cómo debe interactuar el estudiante con ellos, los objetivos didácticos de cada
una y algunos trucos a tener en cuenta. Además, se indicarán las metáforas presentadas
en cada una.
50
Figura 7: Pantalla inicial para escoger el idioma

3.7.1 Despacho del Dr. Mannhausen
Objetivo en el juego: en el despacho del Dr. Mannhausen (Figura 8), como primera
escena Max tiene que recoger la bata, las gafas, el libro sobre criptografía y obtener un
mensaje cifrado que está guardado en su memoria de proyecto de final de grado, sólo
accesible si previamente se ha visualizado el mensaje que hay sobre la mesa; como
escena última, Max debe devolver el libro sobre criptografía antigua a su lugar en la
estantería, lo que provoca que se desplace el cuadro y tenga acceso a un lugar secreto
donde estarán los documentos sobre el ordenador cuántico dejados ahí por su tío.
Objetivo didáctico: por un lado, el estudiante puede examinar el libro sobre criptografía y
conocer algunas técnicas antiguas de sustitución y de trasposición de caracteres; por otro
lado, comprobará que para descifrar el mensaje que estaba oculto en su memoria de
proyecto de fin de grado no necesita más que conocer el algoritmo o método, que es el
51
Figura 8: Pantalla de la escena en el despacho del Dr. Mannhausen

del César, puesto que este método lleva implícita la clave de cifrado (desplazamiento de 3
posiciones en el alfabeto).
Tabla de objetos, acciones y efectos:
Objeto Acciones14
Efectos Trucos
Bata Coger Lleva el objeto al inventario
Gafas
Coger Lleva el objeto al inventario
Usar con... Se combina con la bata
Permitirá a Max caracterizarse
de Dr. Mannhausen
Mensaje sobre la mesa Examinar Habilita el acceso al libro del
estante superior
Libro del estante
superior
Coger
Lleva al inventario un mensaje
oculto dentro del libro
Libro del estante medio
Durante el juego, muchos
objetos se podrán usar con
este libro para averiguar cómo
funcionan distintos tipos de
cifrado
Usar con...
Al arrastrarlo al hueco se
mueve el cuadro y queda al
descubierto el documento del
proyecto que buscaba Max
Esta acción sólo está
disponible al final del juego
Sillón Usar Ninguno Mejor no perder el tiempo
Cuaderno de notas Coger Finaliza el juego
Este objeto estará disponible
al finalizar el juego cuando se
mueva el cuadro que lo oculta
Metáforas:
• Cifrado del César: el mensaje que el Dr. Mannhausen deja para su sobrino tiene
que ser descifrado utilizando el método del César.
• Seguridad por ofuscación: el cuadro oculta el cuaderno de notas del Dr.
Mannhausen con toda la información relativa al proyecto del ordenador cuántico;
siempre había estado ahí pero, en cambio, Max debe pasar toda una serie de
peripecias para llegar hasta él, cuando en realidad estaba al alcance de su mano
con sólo mover el cuadro.
Personajes: en esta escena no hay personajes secundarios.
14 Sólo se indica la acción Examinar si ésta conlleva un efecto diferente de mostrar una descripción detallada del objeto.
52

3.7.2 Entrada a Quantum Corp desde la calle
Objetivo en el juego: si no se ha descifrado todavía el mensaje en la escena anterior
(Figura 8), éste es el momento, pues contiene la frase que Max debe contestar al guarda
de seguridad para poder entrar en Quantum Corp; además, se tienen que combinar las
gafas y la bata para dar lugar a un disfraz de Dr. Mannhausen, lo cual sólo se puede
realizar en esta escena, pues Max es tímido y necesita esconderse detrás del árbol
(véase la Figura 9).
Objetivo didáctico: el estudiante tendrá la oportunidad de aprender el concepto de
suplantación de identidad.
53
Figura 9: Pantalla de la escena en la calle

Objeto Acciones Efectos Trucos
Disfraz Usar
Caracteriza a Max de Dr.
Mannhausen
Sólo tiene efecto en esta
escena
Mensaje Usar con...
Al usarlo con el libro de
cifrados antiguos, se descifra
el mensaje
Se tiene que realizar 3 veces
y el mensaje obtenido servirá
como contraseña para el
guarda de seguridad de la
puerta
Metáforas:
• Suplantación de identidad: en forma de disfraz, ya que Max se disfraza de Dr.
Mannhausen para poder acceder a Quantum Corp.
Personajes: el único personaje secundario en esta escena es el guarda de seguridad que
54
Figura 10: Pantalla de la escena de la entrada a la empresa

se encuentra en la puerta de entrada; no obstante, para hablar con él es necesario
acercarse, con lo que se pasa a la siguiente escena (véase la Figura 10).
3.7.3 Puerta de entrada a Quantum Corp
Objetivo en el juego: llegar disfrazado para engañar al guarda de seguridad y, cuando
éste le haga un comentario respecto a su bata, dar la respuesta adecuada para poder
entrar (véase la Figura 10).
Objetivo didáctico: conocer el concepto de autenticación.
Tabla de objetos, acciones y efectos: No hay ningún objeto que recoger o utilizar.
Desde esta escena se puede tener una conversación con el guarda de seguridad, durante
la cual la respuesta correcta a la pregunta por éste planteada es “No se puede mejorar lo
que es perfecto”.
Metáforas:
• Autenticación: hasta que Max, ya disfrazado, no indica la respuesta correcta, el
guarda de seguridad no le permite acceder a la empresa; la respuesta a una
determinada pregunta es la manera que el guarda tiene para autenticar a la
persona que intenta entrar, lo que en el ámbito de la seguridad de la información se
conoce como autenticación desafío-respuesta o challenge-reponse authentication.
Personajes: se trata de una escena en la que sólo aparece el protagonista, Max, junto al
guarda de seguridad de Quantum Corp, con el que deberá entablar una conversación y
convencerle para que le deje entrar.
3.7.4 Recepción de la empresa
Objetivo en el juego: al examinar la puerta de acceso a I+D (véase la Figura 11), la
recepcionista entrega a Max un mensaje del Dr. Mannhausen que está cifrado con el
método de la escítala; más adelante, cuando encuentre unas llaves en la sala del
personal de limpieza, las podrá utilizar para abrir la puerta del despacho de Dirección.
Objetivo didáctico: aprender el concepto de ataque por fuerza bruta, al tener que probar
sistemáticamente con una llave tras otra para abrir la puerta de Dirección, y conocer otro
55

método de autenticación, en este caso mediante un panel numérico que requiere un
código de acceso.
Ascensor Usar Ninguno Mejor no perder el tiempo
Planta Coger Ninguno Mejor no perder el tiempo
Paraguas Coger Lleva el objeto al inventario
Se podrá usar el paraguas
plegado para descifrar un
mensaje con el método de la
escítala, pero el objeto
correcto es en realidad una
escoba
Puerta I+D
(clic)
Sale de la escena Se necesita averiguar el
código del panel digital
Examinar
La recepcionista empieza a
hablar con Max
Le entregará un mensaje
cifrado
56
Figura 11: Pantalla de la escena de la recepción

Panel acceso I+D Usar Permite acceder a I+D
Averiguar el código
descifrando el mensaje que la
recepcionista entrega a Max
Puerta Dirección (clic) Sale de la escena
Para abrirla hay que probar
varias veces con una llave
que está en la sala del
personal de limpieza
Puerta Limpieza (clic) Sale de la escena
Metáforas:
• Cifrado con el método de la escítala: Max tiene que descifrar el mensaje que le
entrega la recepcionista utilizando el método de la escítala.
• Ataque de fuerza bruta: Max tiene que probar con varias llaves del llavero, una a
una, hasta que da con la que abre la puerta del despacho de dirección.
57
Figura 12: Pantalla de la escena en el cuarto de limpieza

Personajes: Max se encuentra con la recepcionista de Quantum Corp, con la que no
puede hablar porque está muy ocupada, salvo en el caso en que intenta entrar a I+D,
siendo ésta quien inicia la conversación.
3.7.5 Sala del personal de limpieza
Objetivo en el juego: en esta escena, que se muestra en la Figura 12, hay que usar la
tira de papel con el libro para descubrir el tipo de cifrado y luego con el palo de la escoba
para descifrar el mensaje; además, recoger un juego de llaves que cuelgan del bolsillo del
uniforme.
Objetivo didáctico: conocer otro método de cifrado antiguo, el de la escítala.
Producto de limpieza Coger Ninguno Mejor no perder el tiempo
Mensaje Usar con...
Al usarlo con el libro se
averigua el tipo de cifrado y al
usarlo con la escoba se
descifra el mensaje
No se puede usar ni con el
paraguas (aunque esto no
sirva de mucho) ni con la
escoba hasta que no se use
primero con el libro
Llaves
Permitirán abrir la puerta de la
sala de reuniones de la
Dirección y el archivador del
Dr. Mannhausen en el
departamento de I+D
Usar con... Abren el archivador de I+D
Metáforas: en esta escena no existe ninguna nueva metáfora que comentar.
Personajes: en esta escena no hay personajes secundarios.
3.7.6 Departamento de I+D
Objetivo en el juego: acceder a los archivadores del final (véase la Figura 13) tras dar la
respuesta correcta al guarda de seguridad y, usando las llaves, obtener un mensaje que
dejó el Dr. Mannhausen para el presidente de la compañía; además, visualizar el mural de
la pared sobre ataques informáticos.
58

Objetivo didáctico: experimentar lo que sería un cortafuegos humano que sólo deja
pasar a Max para algo muy concreto, conocer el concepto de ataque DDoS en particular y
una clasificación general de ataques informáticos a sistemas y redes.
Esquema de la pared Examinar
Muestra uno de los libros del
juego con información sobre
ataques informáticos
Es uno de los elementos de
evaluación y aparecerá en el
informe
Archivadores
Examinar
Comienza el diálogo con el
guarda de seguridad
Escogiendo las opciones
correctas se permitirá a Max
acceder a la zona más alejada
de la sala
Usar
Se obtiene un mensaje para el
Presidente de Quantum Corp
Esta acción sólo está
disponible si el archivador se
ha abierto con la llave
59
Figura 13: Pantalla de la escena en el departamento de I+D

Durante la conversación con el guarda de seguridad, la mayoría de opciones son
cíclicas o finalizan la conversación. La única opción correcta es “Sólo he venido a recoger
mis cosas” y, posteriormente, “No me queda más remedio que realizar un ataque DDoS”.
Metáforas:
• Cortafuegos: el guarda de seguridad no permite entrar a Max (disfrazado de su tío)
hasta que no le queda claro qué tarea o servicio va a realizar (recoger sus cosas).
• Ataque DDoS: entre todos los empleados se consigue que el empleado de
seguridad ceda ante los requerimientos de Max.
Personajes: en esta escena aparecen seis personajes secundarios, de los cuales sólo el
guarda de seguridad es susceptible de entablar una conversación; el resto sólo
intervienen cuando Max comenta que se ve en la obligación de realizar un ataque DDoS,
de manera que los cinco oficinistas hacen las veces de BOTs15
cuyo objetivo sería el
guarda de seguridad.
3.7.7 Reunión de la Dirección de la empresa
Objetivo en el juego: combinar el mensaje del papel doblado con el libro sobre
criptografía para cifrarlo con la clave pública del Presidente y, después, entregárselo a
través de la ejecutiva (véase la Figura 14).
Objetivo didáctico: conocer el funcionamiento del cifrado asimétrico, la importancia de
cifrar mensajes que van a viajar por un canal inseguro, el concepto confidencialidad, el de
escucha o eavesdropping y el de encaminamiento.
15 Robots u ordenadores zombie en un ataque DDoS
60

Papel doblado
Usar con...
Al usarlo con el libro cifra el
mensaje para que sólo el
Presidente lo pueda leer
Dar a...
A través de la ejecutiva se
puede entregar al Presidente
Max sólo lo hará si el mensaje
ha sido previamente cifrado
Al entregar el mensaje a la ejecutiva, se lanza un diálogo la opción correcta del cual es
“No le cuesta nada, se lo pido por favor”.
Metáforas:
• Cifrado simétrico: el mensaje para el Presidente de la compañía tiene que cifrarse
con la clave pública del mismo para que Max se decida a hacérselo llegar.
61
Figura 14: Pantalla de la escena de la reunión

• Encaminamiento: Max entrega el mensaje al Presidente pasándolo a través de la
ejecutiva y éste, a su vez, le responde también a través de aquélla.
• Confidencialidad: los mensajes que pasan a través de terceros como texto en claro
son susceptibles de ser leídos, como en un ataque de escucha o eavesdropping.
Personajes: en esta escena aparece tres personajes secundarios; el ejecutivo que está
exponiendo su presentación no entabla conversación; con la ejecutiva sí se puede hablar,
para poder hacer llegar el mensaje al Presidente; y éste sólo habla con su ejecutiva, pero
no con Max.
3.8 Evaluación del estudiante
Tras finalizar una partida, el estudiante tiene acceso a un informe con su evaluación y
los puntos en los que tiene que mejorar, si aplica, como el que se muestra en la Figura 15.
Este informe evalúa las siguientes capacidades del estudiante:
• Investigación y descubrimiento: si el estudiante consulta alguno de los libros del
juego, con información sobre los conceptos tratados, este hecho queda reflejado en
el informe.
• Concentración y comprensión lectora: durante los diálogos, las respuestas
incorrectas o inadecuadas se van contabilizando y, si se sobrepasa cierto umbral,
se le notifica en el informe; se considera normal equivocarse y forma parte del
juego, pero pasado cierto límite se podría pensar que el estudiante no está
concentrado en la tarea o tiene que revisar su comprensión lectora.
• Mejora continua: se contabiliza el tiempo total de juego y, en función de la escala
en la que se encuentra, se muestra un mensaje en el informe instando al
estudiante a mejorar su tiempo.
62

3.9 Validación
Al finalizar el diseño de cada una de las escenas, se realizaban pruebas exhaustivas
para verificar que no había bucles sin fin en los diálogos, que las acciones sobre los
objetos producían los efectos deseados y que era posible avanzar en el juego con un nivel
de dificultad adecuado.
Además, al realizar la traducción a inglés y francés, se tuvieron que volver a probar
exhaustivamente todas las escenas, con sus objetos, personajes, diálogos, etc. tanto para
validar que al seleccionar un idioma sólo aparecía texto del mismo y no de otros como
para verificar que al seleccionar español el juego continuaba cumpliendo los requisitos
funcionales y no funcionales.
No obstante, como en algunos aspectos se necesitaba la opinión de estudiantes ajenos
63
Figura 15: Informe de evaluación

al proyecto y verificar si el nivel de dificultad era el adecuado, una vez diseñada una
primera versión completa del juego se realizaron pruebas reales algunos estudiantes.
A continuación, en el siguiente apartado, se comentan dichas pruebas y en el apartado
3.10 Errores conocidos se comentan los errores encontrados en parte gracias a las
mismas.
3.10 Errores conocidos
Los siguientes son errores conocidos de los cuales se desconoce la causa:
1. Errores de la JVM en tiempo de ejecución en circunstancias cada vez diferentes.
Esporádica y aleatoriamente, se ha detectado el error al coger o utilizar un objeto
que normalmente no produce el error o en otras situaciones similares.
Teniendo en cuenta que el código Java es generado por el motor, resulta difícil
averiguar el origen del problema, aunque no imposible si se dispusiera del tiempo
suficiente y el error fuera reproducible, es decir, si se pudieran crear las
condiciones que lo generan.
En algunos casos el problema se ha podido subsanar, ya que error era lo
suficientemente claro, como por ejemplo un desbordamiento en un string
corregido limitando el texto que contenía parte de un diálogo.
2. Durante el diseño, la ejecución del juego desde el propio editor de eAdventure
muestra una pantalla que no contiene todos los elementos, ya que es de tamaño
inferior a la escena diseñada. Curiosamente, el tamaño reducido no siempre es el
mismo, aunque por norma general se reduce en ancho. Sin embargo, al ejecutar el
juego en modo debugger desde el editor, al ejecutarlo desde el motor, directamente
desde el fichero jar generado tras exportarlo o desde un EVE como Moodle, se
visualiza perfectamente.
Dado que no se pretende que el usuario ejecute el juego desde el motor sino que
utilice el fichero exportado o desde un EVE en línea, no se ha investigado el origen
de este comportamiento.
64

3. Dependiendo del tipo de final del juego no se muestra automáticamente el informe
de evaluación. En concreto, esto sucede cuando el final es una escena intermedia
de tipo vídeo, no siendo así si es una imagen fija.
Por este motivo, la escena intermedia para finalizar el juego mediante un vídeo,
que originalmente debía ser el final, se ha tenido que sustituir por una escena
intermedia de tipo diapositiva con una imagen fija.
4. Los valores dados a los parámetros SCORM, como por ejemplo
cmi.core.score.raw, dentro de las reglas de tipo tiempo en el perfil de
evaluación, como la de la Figura 16, no se actualizan, como sí sucede en las reglas
de tipo normal.
Se han hecho muchas pruebas, tanto con SCORM 1.2 como 2004, sin llegar a
conseguirlo, lo cual ha impedido que la cualificación de la sesión sea proporcional
al tiempo empleado por el jugador.
La conclusión a la cual se ha llegado es que debe tratarse de un bug en
eAdventure v1.5 RC4.
5. Al añadir sonidos a algunas de las escenas, el motor de eAdventure queda
completamente colgado, sin dejar trazar ni mostrar errores.
Además, el sonido de la escena intermedia del viaje en autobús desde el despacho
a la entrada de la empresa se prolonga más allá de dicha escena, mezclándose
con el sonido de la escena en la calle.
Por estos motivos, se ha optado por disponer de dos variantes del juego, una con
sonido y otra sin sonido.
65

Integración en Moodle como paquete SCORM
4 IN TE G R A CI Ó N E N MO OD L E C O MO PA Q UE T E
SCORM
Es posible preparar el proyecto para ser utilizado como un juego para el aprendizaje
dentro de Moodle (o cualquier otro EVE que soporte SCORM). Para ello, son necesarios
tres pasos:
1. Preparar el perfil de evaluación (y de adaptación, si lo hubiera) para generar datos
según el estándar SCORM que luego serán recogidos por el EVE.
2. Editar los metadatos y exportar el proyecto como un paquete SCORM.
3. Importarlo en Moodle.
4.1 Preparar el perfil de evaluación
En primer lugar, desde el motor de eAdventure, hay que configurar correctamente los
perfiles de adaptación y evaluación para que utilicen el formato SCORM 1.2.
En el proyecto de Max y el Dr. Mannhausen sólo se ha utilizado un perfil de
evaluación, así que es el único a configurar. De las opciones del menú lateral de
eAdventure (véase la Figura 2), se debe entrar en el perfil de evaluación y cambiar el tipo
de perfil a SCORM 1.2.
A partir de ese momento, en las reglas creadas se podrán añadir efectos que incluyan
la asignación de valores a determinados parámetros preestablecidos compatibles con
SCORM.
Tal y como explica Rustici (2009), el uso de la API de SCORM se debe realizar en dos
etapas:
1. Parámetros básicos tales como cmi.core.lesson_status y
cmi.core.score_raw, que son reportados directamente por el juego Max y el
Dr. Mannhausen y utilizados por el EVE.
67

2. Parámetros adicionales de las categorías interacciones (interactions) y objetivos
(objectives) de SCORM 1.2 y 2004 y de reporte del progreso, sólo en SCORM
2004.
En el juego se utilizan los parámetros cmi.objectives.n.status de la categoría
de objetivos, como se explica a continuación.
En la Figura 16, se muestra cómo se dan valores al parámetro
cmi.core.session_time en función del tiempo que ha durado la partida y el valor 10 al
parámetro cmi.core.score_raw, para cualificar el intento en el EVE.
No obstante, como se explica en el apartado 3.10 Errores conocidos, esa configuración
se tuvo que modificar porque no surtía efecto, asignándose finalmente un valor sólo a
cmi.core.session_time.
En la Figura 17, como se puede observar, el valor del parámetro
cmi.objectives.1.status tomará el valor del flag ConsultaCifrados, que será true si
se ha activado esta regla. Si, en cambio, se consulta el libro sobre criptografía, pasará a
true el parámetro cmi.objectives.2.status.
68
Figura 16: Efectos de la regla de evaluación del tiempo de juego

Como se puede observar en la Figura 18, responder inadecuadamente durante los
diálogos tiene penalización, tanto en el valor del parámetro cmi.objectives.3.status,
que se puede utilizar para indicar si se ha superado el umbral de respuestas incorrectas,
como en el valor de cmi.core.score.raw, que indica la cualificación de la sesión.
En segundo lugar, habría que editar los datos del proyecto yendo al menú Archivo →
Editor de metadatos Lom → Propiedades de Objeto de Aprendizaje para paquetes
SCORM 1.2 (IMS-LOM). La ventana emergente contiene cuatro pestañas con diversas
casillas a rellenar (véase la Figura 19, la Figura 20, la Figura 21 y la Figura 22).
69
Figura 17: Efectos de la regla de evaluación de consulta del libro sobre criptografía
Figura 18: Efectos de una de las reglas de evaluación de respuestas incorrectas

70
Figura 19: Primera pestaña de metadatos
Figura 20: Segunda pestaña de metadatos

71
Figura 21: Tercera pestaña de metadatos
Figura 22: Cuarta pestaña de metadatos

En tercer, habría que ir al menú Archivo → Exportar proyecto → Exportar como objeto
de aprendizaje (LO).
En la ventana emergente que se muestra en la Figura
23, se deben rellenar los datos del proyecto de tipo
SCORM.
Por último, se solicitará dónde guardar el fichero
comprimido resultante.
4.3 Importar el paquete
Ya dentro del curso de Moodle en el que se tiene que
crear el acceso al juego y habiendo entrado con un
usuario con privilegios suficientes (generalmente, se
tratará del profesor del curso o del administrador de
Moodle), se debe activar la edición del curso pulsando sobre el botón que
se encuentra en la parte superior derecha.
A continuación, el aspecto del curso cambiará para ofrecer una serie de opciones por
cada elemento del mismo (véase la Figura 24).
72
Figura 23: Cuadro de diálogo de
exportación como SCORM
Figura 24: Aspecto de un curso de Moodle con la opción de edición activada

Al hacer clic sobre Add an activity or
resource, se mostrará una lista con las múltiples
actividades y recursos que ofrece Moodle para
incluir en el curso (véase la Figura 25).
De entre todas, la que interesa en estos
momentos es el paquete SCORM.
Basta con darle un nombre, una
descripción y arrastrar el fichero
comprimido producto de la
exportación desde el motor
eAdventure al recuadro para subida
de ficheros, como el que se muestra
en la Figura 26.
Es importante configurar la opción Grading method (dentro de Grade) como Highest
grade, como se muestra en la Figura 27, de acuerdo a la documentación de Moodle16
.
Existen otras opciones que pueden resultar
interesantes de configurar, como mostrar el paquete
en una nueva ventana (en el momento en que los
estudiantes hagan clic para utilizar el juego).
Una vez hecho esto, los estudiantes ya podrán entrar a Moodle y utilizar el recurso
recién creado (véase la Figura 28).
16 https://docs.moodle.org/28/en/SCORM_settings#Grading_method
73
Figura 25: Actividades y recursos de Moodle
Figura 27: Opciones de cualificación
Figura 26: Parte de las opciones del recurso SCORM

Al hacer clic sobre el juego, es posible que los estudiantes tengan que habilitar el uso
de la máquina virtual
Java en su navegador
(plug-in Java).
Además, podría ser
que una ventana
emergente les pida
confirmación sobre la
ejecución de la máquina
virtual, para lo cual
tendrán que hacer clic
sobre el botón Run, como
se muestra en la Figura
29.
74
Figura 28: Curso de Moodle con el juego disponible
Figura 29: Ventana emergente de confirmación de ejecución de la aplicación Java

4.4 Comunicación de datos
Los datos generados por el SCO (Shared Component Object), es decir, el paquete
SCORM, se pasan al EVE (Moodle en el ejemplo del apartado 4.3 Importar el paquete)
para que éste los procese como crea conveniente.
Para poder comprobar el correcto funcionamiento del SCO, cabe la posibilidad de
seleccionar SCORM+DEBUGGER en lugar de sólo SCORM en las opciones de
exportación que se mostraban en la Figura 23.
Entonces, al importar el juego en Moodle y utilizar el recurso, aparecerá un signo +
que, al hacerle clic, mostrará la comunicación entre el SCO y el EVE, como se puede
observar en la Figura 30.
La explotación de estos datos puede ser de dos tipos:
1. Utilizados directamente desde Moodle, ya sea automáticamente, como es el caso
de cmi.core.score.raw, que modifica la cualificación de la sesión, ya sea
manualmente, accediendo a los datos de la sesión como profesor del curso en que
se encuentra el paquete SCORM, como se observa en la Figura 31.
75
Figura 30: Mensajes generados por el SCO en Moodle

2. Realizando una explotación externa a Moodle, lo cual requeriría o bien el acceso a
la base de datos de Moodle, donde se guardan estos valores o bien la
programación en JavaScript, PHP o algún otro
lenguaje adecuado de los módulos para extraer estos
datos y procesarlos (envío por correo electrónico,
mostrarlos en el propio curso de Moodle, etc.) previo
formateo.
En la Figura 32 se muestran las tablas que contienen
datos relevantes. De entre ellas, la más interesante es
mdl_scorm_scoes_track, que informa sobre la
comunicación entre el SCO y el EVE a través de la API
de SCORM (véase la Figura 33), en concreto sobre los
cambios en los parámetros según evoluciona la
partida o sesión.
76
Figura 32: Tablas de Moodle con
datos SCORM
Figura 33: Contenido de la tabla mdl_scorm_scoes_track
Figura 31: Seguimiento de una sesión en Moodle

Memoria PFG

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (6)

Similar a Memoria PFG

Similar a Memoria PFG (20)

Memoria PFG