desarrollo de videojuegos como herramienta educacional y
TRANSCRIPT
Desarrollo de videojuegos como
herramienta educacional y
terapéutica para niños y jóvenes con
discapacidad.
Trabajo Final
Ingeniería de Sistemas
Facultad de Ciencias Exactas UNCPBA
Marzo 2016
Mariel Ivonne
Contreras
ALUMNA
Dr. Cristian García
Bauza
DIRECTOR
Ing. Carolina
Valdez Gándara
CO-DIRECTORA
2
ÍNDICE Capítulo 1: Introducción .................................................................................................................... 4
1.1 Motivación................................................................................................................................... 5
1.2 Objetivos ...................................................................................................................................... 5
1.3 Organización del documento ............................................................................................... 6
Capítulo 2: Marco Teórico ................................................................................................................ 8
2.1 Introducción ............................................................................................................................... 8
2.2 Discapacidad y tecnología ..................................................................................................... 8
2.3 Accesibilidad en videojuegos ............................................................................................... 9
2.4 Contexto de aplicación .........................................................................................................11
2.5 Sensor Kinect ...........................................................................................................................12
2.6 Plataforma de videojuegos Simon. ..................................................................................15
2.7 Descripción de los juegos ....................................................................................................20
2.8 Conclusiones ............................................................................................................................22
Capítulo 3: Elicitación de requerimientos ................................................................................23
3.1 Introducción .............................................................................................................................23
3.2 Implantación y elicitación de requerimientos ............................................................24
3.3 Proceso de adaptación al uso de Simon por los alumnos .......................................27
3.3.1 Periodo de adaptación ..................................................................................................28
3.3.2 Estrategias de autoaprendizaje ................................................................................28
3.3.3 Contextos de uso .............................................................................................................29
3.4 Diseño de nuevos juegos .....................................................................................................30
3.4.1 Introducción .....................................................................................................................30
3.4.2 Juego “Mímica” ................................................................................................................30
3.4.3 Juego “Lluvia” ...................................................................................................................36
3
3.5 Conclusiones ............................................................................................................................38
Capítulo 4: Implementación ...........................................................................................................39
4.1 Introducción .............................................................................................................................39
4.2 Configuración de los videojuegos de la plataforma ..................................................39
4.3 Modificaciones en la plataforma.......................................................................................47
4.3.1 Elementos Clasificables ................................................................................................47
4.3.2 Mejoras en la UI ...............................................................................................................50
4.3.3 Atributos de niveles y modos de juego ..................................................................52
4.3.4 Mejoras del skeleton .....................................................................................................54
4.4 Simon Editor.............................................................................................................................57
4.4.1 Administrador de Datos o Controller .....................................................................59
4.4.1.1 Inicializar Datos ......................................................................................................59
4.4.1.2 Guardar Datos ..........................................................................................................65
4.4.2 Escena o View ..................................................................................................................68
4.4.2.1 Inicializar Interfaz ..................................................................................................69
4.4.2.2 Actualizar Datos ......................................................................................................76
4.5 Conclusiones ............................................................................................................................81
Capítulo 5: Conclusiones y trabajos futuros ............................................................................83
5.1 Conclusiones ............................................................................................................................83
5.2 Trabajos Futuros ....................................................................................................................85
Apéndice ................................................................................................................................................88
A.1 Descripción de los elementos estáticos del juego “Flechas” .................................88
Referencias ........................................................................................................................................ 100
Agradecimientos ............................................................................................................................. 103
4
CAPÍTULO 1: INTRODUCCIÓN
Durante las últimas tres décadas, los sistemas de videojuegos han evolucionado
desde su propósito original como fuente de entretenimiento, a influenciar la
manera en la que las personas perciben, aprenden e interactúan con el mundo que
los rodea. Estos sistemas involucran la interacción entre un jugador y una interfaz
de usuario mediante la cual los usuarios reciben un estímulo visual, auditivo o
háptico que responden a través de dispositivos de entrada.
Si bien el objetivo principal de los videojuegos es entretener a sus usuarios, en la
actualidad también tienen otros propósitos como educación o salud.
Por otra parte, el área de Human - Computer Interaction (HCI, por sus siglas en
Inglés) está siendo utilizado en el campo de los videojuegos, brindando la
posibilidad de generar una comunicación natural sin controles adicionales (Jacko,
2012). Uno de los campos de investigación de HCI es la interacción niño-
computadora que estudia el diseño, evaluación e implementación de sistemas
informáticos interactivos para niños, teniendo en cuenta los entornos donde estos
niños se desempeñan y los valores culturales y sociales relacionados al impacto
que los sistemas tienen en sus usuarios (Hourcade, 2015).
Los niños que utilizan sistemas informáticos tienen diferentes experiencias de
vida, habilidades, estructuras neuronales y cuerpos. Sus necesidades e intereses
son variados y algunos pueden tener discapacidades cognitivas, motoras o de
percepción.
Para adaptar los videojuegos a las necesidades de todos los usuarios, las
investigaciones en el área de accesibilidad en juegos encaran las problemáticas de
manera general o particular. En el primer caso, desarrollan guías de buenas
prácticas a tener en cuenta a la hora de desarrollar un videojuego accesible para
cualquier jugador, mientras que en el segundo apuntan una discapacidad
particular (motora, cognitiva, visual o auditiva) y proponen soluciones enfocadas
en esa área.
5
1.1 MOTIVACIÓN
Según la Organización Mundial de la Salud (OMS) un 15% de la población mundial,
padece alguna forma de discapacidad (OMS, 2011) y según una estimación
ampliamente utilizada desde el año 2004 pero especulativa, alrededor de 93
millones de niños (1 de cada 20 niños menores de 14 años) vive con alguna
discapacidad moderada o grave (UNICEF, 2013).
Las discapacidades pueden traer múltiples limitaciones y restricciones en la
participación en la sociedad para quienes las padecen. Por ejemplo, los niños con
discapacidad tienen menos probabilidades de ingresar en la escuela, permanecer
en ella y superar los cursos sucesivos. El fracaso escolar se observa en todos los
grupos de edad y tanto en los países de ingresos altos como bajos, pero con más
frecuencia en los países más pobres. Incluir niños con discapacidad en el sistema
educativo exige cambios en los planes de estudio, métodos y materiales de
enseñanza y sistemas de evaluación y examen (OMS, 2011).
Actualmente, el área de software aplicado para reducir la influencia de las barreras
para la participación de las personas con algún tipo de discapacidad, está en
crecimiento. Existen aplicaciones desarrolladas con fines pedagógicos y
terapéuticos para niños y adultos.
Por estas razones, motiva el desarrollo de este trabajo de tesis aplicar los
conocimientos tecnológicos, ingeniería de elicitación de requisitos y de desarrollo
de software a la implementación de videojuegos adaptables y accesibles para
entrenar las habilidades cognitivas y motoras de niños y jóvenes con distintos
tipos de discapacidad.
1.2 OBJETIVOS
El objetivo de esta tesis es desarrollar videojuegos accesibles, teniendo en cuenta
las habilidades y contexturas físicas de sus usuarios. Los videojuegos resultantes
serán herramientas educacionales y terapéuticas, que permitan entrenar las
capacidades cognitivas y motoras de sus usuarios.
6
Adicionalmente, se pretende acercar las tecnologías de la información y la
comunicación a la educación proporcionando una herramienta que permita crear
nuevos métodos de aprendizaje que entusiasmen y motiven a los alumnos a la hora
de aprender nuevos conceptos.
Para implementar los videojuegos, se utiliza una plataforma de desarrollo llamada
Simón (Piccolo et al., 2014), que simplifica a los programadores crear software de
entretenimiento con interacción natural provista por el sensor Kinect de Microsoft
(Abhijit, J., 2012).
La plataforma fue desarrollada durante un proyecto final de carrera, luego de su
implementación se instanciaron cuatro juegos para su validación. Si bien se
comprobó que la plataforma cumplía con su finalidad planteada de crear
videojuegos con un mínimo esfuerzo, estos no fueron usados por usuarios finales
para analizar su usabilidad y accesibilidad. Por esta razón, durante esta tesis la
plataforma ha sido adaptada a través de su implantación y la captura de
requerimientos realizada en la Asociación Tandilense de Ayuda al Discapacitado.
Este trabajo busca que la plataforma y sus juegos sean configurables para que las
maestras ajusten la dificultad de los juegos a las habilidades de sus alumnos.
1.3 ORGANIZACIÓN DEL DOCUMENTO
Este documento se organiza de la siguiente manera, en el capítulo 2 se introducen
los conceptos generales a tener en cuenta para conocer el contexto del desarrollo
del trabajo de tesis realizado.
En el capítulo 3 se describe el proceso de elicitación de requerimientos a través de
la que se obtuvieron los requerimientos para extender la plataforma y desarrollar
la herramienta de edición de configuración de los juegos y se detalla la
implementación de los nuevos juegos.
El capítulo 4 brinda los detalles del diseño, implementación y decisiones de diseño
tomadas para el desarrollo del software.
7
Por último, el capítulo 5 presenta las conclusiones y los trabajos futuros mientras
que, al final del documento se incluye un apéndice con la especificación de la
configuración de uno de los juegos de la plataforma y se detalla la bibliografía
consultada.
8
CAPÍTULO 2: MARCO TEÓRICO
2.1 INTRODUCCIÓN
En este capítulo se presenta el concepto de discapacidad y de uso de videojuegos
accesibles como herramienta educacional y terapéutica. Adicionalmente, se
exponen investigaciones en el ámbito de accesibilidad en videojuegos. Por último,
se describe la plataforma Simón y el sensor Kinect, utilizado para la interacción.
2.2 DISCAPACIDAD Y TECNOLOGÍA
"Discapacidad" es un término genérico que abarca disparidades, limitaciones de
actividad y restricción en la participación. La discapacidad no es sólo un problema
de salud, es un fenómeno complejo que refleja la interacción entre las
características del cuerpo de una persona y las de la sociedad en la que se
desempeña (WHO, 2011). La superación de las dificultades a las que se enfrentan
las personas con discapacidad requiere de intervención para remover las barreras
ambientales y sociales.
Una de las formas de reducir la influencia de estas barreras es el uso de tecnologías
asistivas. Estas abarcan productos y equipamientos personalizados para que las
personas con discapacidad puedan realizar tareas de manera fácil y segura.
Las tecnologías de información y comunicación incluyendo computadoras,
celulares estándar o smartphones y tablets, son herramientas que afectan la
manera en la que las personas aprenden, trabajan y juegan (Wright, 2004). Su
rápido desarrollo y aplicación en varias áreas muestra su potencial para mejorar el
acceso a la información, el conocimiento y las nuevas oportunidades de
aprendizaje, facilitando la obtención de empleo y la independencia (UNESCO,
2009). Por esta razón, estas tecnologías son adaptadas para satisfacer las
necesidades de personas con discapacidad y utilizadas como tecnologías asistivas
(Cook et al., 2015) en ámbitos cotidianos, terapéuticos y educacionales.
9
El uso de métodos de enseñanza combinados con estos tipos de tecnologías
estimulan a los estudiantes con discapacidad para que se comprometan con el
proceso de aprendizaje, permitiendo que alcancen su máximo potencial (Altanis et
al., 2013). Para personalizar el método de enseñanza se deben tener en cuenta las
habilidades, necesidades y estilos de aprendizaje de todos los estudiantes. El uso
de tecnología posibilita el desarrollo curricular flexible y asiste a los estudiantes
para participar en la experiencia de aprender (UNESCO, 2011).
Recientemente, los videojuegos se convirtieron en una de las herramientas
tecnológicas aplicadas al ámbito educativo y terapéutico. El uso de estos favorece
las destrezas cognitivas, el tiempo de dedicación, la motivación, el entrenamiento
de habilidades y la enseñanza de conceptos.
Para obtener los mismos beneficios en entornos donde se desempeñan personas
con algún tipo de discapacidad, es necesario que los videojuegos sean accesibles.
En la siguiente sección se describen las estrategias de accesibilidad empleadas en
diferentes investigaciones para adaptar los juegos a las necesidades de usuarios
con algún tipo de discapacidad y las consideraciones propuestas para su aplicación
en ámbitos educativos.
2.3 ACCESIBILIDAD EN VIDEOJUEGOS
Los videojuegos son herramientas tecnológicas que se pueden aplicar tanto en la
educación como en la rehabilitación de personas con el objetivo de aprender,
estimular o mejorar sus capacidades. Estas herramientas se deben adaptar a las
necesidades de los usuarios.
En las últimas décadas se han realizado gran cantidad de investigaciones en el área
de software accesible y tecnologías asistivas aplicadas a videojuegos. Para proveer
accesibilidad es necesario tener en cuenta dificultades visuales, motoras, auditivas
y cognitivas. Para esto, se han desarrollado una serie de estrategias considerando
su efecto sobre el modelo de interacción de juego que consta de tres pasos:
recepción de estímulos, elaboración de respuestas e ingreso de entradas (Yuan et
al., 2011). De la misma manera, varios grupos han encarado el desafío de la
inclusión de manera general, creando una guía que incluye los puntos, técnicas y
10
herramientas a tener en cuenta para desarrollar juegos accesibles que consideren
las cuatro categorías de dificultades antes mencionadas (Barlet et al., 2012) o
elaborando un proceso de diseño unificado para juegos universalmente accesibles
fundamentado por la definición de tareas abstractas, especialización polimórfica a
las diferentes alternativas físicas para la ejecución de las mismas, evaluación de
prototipos, usabilidad y accesibilidad de las diferentes soluciones (Grammenos,
2007).
En el área de accesibilidad, para discapacidad motora se ha elaborado un prototipo
de dispositivo llamado JPEmulator que se conecta a la consola de videojuegos
Playstation 2 para utilizar dispositivos accesibles (pulsadores, sensores, etc.).
Dependiendo de las funciones del controlador original que se les asignen, el
dispositivo modifica la comunicación joypad-consola traduciendo las señales
recibidas (Fanucci et al., 2011).
Por otra parte, Kinems es un paquete de juegos de aprendizaje a través de la
interacción con el sensor Kinect. Su objetivo es la mejora de coordinación de ojos y
manos, percepción visual, planificación motora y habilidades de ejecución (Altanis
et al., 2013).
En el entrenamiento de las habilidades motoras, se ha realizado un estudio sobre la
capacidad de los juegos de acción en ambientes 3D, especialmente los FPS, (First
Person Shooter o juego de disparos en primera persona) para inducir cambios en
las habilidades sensoriales, perceptuales y de atención, tareas importantes en la
adquisición de cognición espacial (Spence et al., 2010).
Los videojuegos aplicados en el ámbito educativo proponen un medio donde el
aprendizaje se obtiene como resultado de las tareas estimuladas por los
contenidos del juego y las habilidades cognitivas se desarrollan como resultado de
la acción de jugar, motivando la creatividad y la concentración.
Para el uso de videojuegos en educación especial, se han definido guías para
desarrollar un videojuego considerando el concepto de inteligencias múltiples
(Gardner, 1983). Este define a la inteligencia como un conjunto de capacidades o
habilidades, distintas e independientes, que se pueden relacionar. Considerando
11
esto, se pueden crear videojuegos que utilicen las habilidades adquiridas por el
jugador como mecanismos de potenciación de aquellas que estén menos
desarrolladas (González Sánchez, et al. 2007). Esta guía también considera no crear
frustración en los jugadores, crear metas claras e incrementales a través de niveles
de dificultad, otorgar recompensas y usar mecanismos realistas para resolver las
problemáticas del videojuego para alcanzar el objetivo educativo planteado.
Todas estas investigaciones, aplican de forma inteligente las tecnologías y el
conocimiento disponibles para la solución de determinadas problemáticas. En esta
tesis se utilizó y adaptó la funcionalidad de una plataforma de desarrollo de
videojuegos basados en la interacción con el sensor Kinect para implementar
juegos accesibles para alumnos con diferentes grados y tipos de discapacidad.
Tanto la elicitación de requerimientos como las pruebas y evaluación de resultados
de este trabajo han sido llevadas a cabo en ATAD, Asociación Tandilense de Ayuda
al Discapacitado, una escuela para niños y jóvenes con discapacidad donde la
plataforma Simón se utiliza regularmente como una actividad de recreación y
estímulo cognitivo de los alumnos que concurren diariamente.
2.4 CONTEXTO DE APLICACIÓN
ATAD es una institución que brinda apoyo escolar, talleres, integración y atención
temprana a sus alumnos a través de un equipo de profesionales conformado por la
directora, psicóloga, terapista ocupacional, kinesióloga, fonoaudióloga,
psicopedagoga, trabajadora social y los docentes (talleristas y maestras
integradoras).
Los profesionales ofrecen a los alumnos talleres de juego, escuela, cocina,
educación física, descubrimiento del mundo, teatro, música, plástica, entre otros.
Cada jornada, dividida en los turnos mañana y tarde, tiene tres llamados donde los
niños eligen los talleres en los que desean participar. De esta manera, en cada taller
existe heterogeneidad de edades y patologías. El trabajo con cada alumno se basa
en su potencial y en la manera en que se los asiste para jugar, aprender y
compartir.
12
2.5 SENSOR KINECT
El sensor Kinect, desarrollado por Microsoft en 2010 para su consola de
videojuegos Xbox 360, fue el primer sensor de color y profundidad en salir al
mercado. Este sensor mide aproximadamente 30 cm y su diseño se muestra en la
siguiente figura.
FIGURA 2.1 - IMAGEN FRONTAL DEL SENSOR KINECT POR FUERA Y POR DENTRO.
13
Kinect fue formalmente desarrollado para rastrear personas en partidas de
videojuegos y facilitar la interacción a través de movimientos del cuerpo y gestos,
aunque su popularidad ha crecido con el desarrollo de aplicaciones de software
para PC. Con esta tecnología se puede facilitar el desarrollo de sistemas como
pantallas interactivas (Zhang et al., 2012), asistencia para rehabilitación física
(Chang et al., 2012.), reconocimiento de lenguaje de señas (Zafrula et al., 2011),
control de robots (Ramey et al., 2011), entre otros.
El sensor es capaz de reconocer objetos y personas frente a él utilizando una
técnica llamada luz estructurada. Para esto, el sensor proyecta un patrón infrarrojo
de 307.200 puntos en una 15 malla de 640x480 pixels. Al mismo tiempo, recibe el
patrón reflejado a través de un dispositivo sensor monocromo CMOS que conforma
la cámara infrarroja. La malla de puntos es invisible al ojo humano y se muestra en
la siguiente figura:
FIGURA 2.2 - MALLA DE PUNTOS INFRARROJOS EMITIDA POR EL SENSOR KINECT.
14
Esta técnica permite al dispositivo medir la profundidad de cada punto por medio
de triangulación. Por otra parte, la cámara RGB provee información de color
sincronizada de cada punto a una tasa de 30 frames por segundo (Palacios et al.,
2013). Un ejemplo de cómo se ven los objetos en el ambiente con la cámara
infrarroja del sensor se muestra en la siguiente figura:
FIGURA 2.3 - VISTA DE UN OBJETO DESDE LA CÁMARA INFRARROJA DEL SENSOR KINECT.
Adicionalmente, el sensor posee cuatro micrófonos y un chip que permite procesar
las señales para generar una salida hacia la computadora. Esta información es
utilizada para reconocer y rastrear objetos delante de su área visible, determinar la
dirección de las señales de sonido y aislarlo del ruido ambiente.
Para poder implementar aplicaciones para PC, Microsoft lanzó en 2011 el SDK
llamado Kinect for Windows, que facilita la captura de datos del sensor a los
programadores. Para reconocer personas, el SDK simplifica el cuerpo humano
construyendo una pequeña representación del mismo.
El esqueleto humano está conformado por 206 huesos que tienen uniones o joints
entre ellos para que se puedan mover (por ejemplo, el codo y la rodilla). El SDK
construye a partir de la captura de Kinect, un esqueleto simplificado de 19 huesos
que están conectados por medio de 20 joints al que se lo conoce como skeleton
(ver Figura 2.4).
15
FIGURA 2.4 - DISTINTOS USUARIOS RECONOCIDOS CON EL SENSOR KINECT Y RECONSTRUIDOS A TRAVÉS
DEL SDK DE KINECT.
Una vez obtenido el skeleton puede comenzarse el reconocimiento de posturas
detallado a continuación.
2.6 PLATAFORMA DE VIDEOJUEGOS SIMON.
La plataforma de desarrollo de videojuegos, llamada Simón, fue implementada en
el área Media.Lab del instituto Pladema. Esta plataforma fue creada como
herramienta de soporte para el desarrollo de videojuegos utilizando el sensor
Kinect de Microsoft detallado en la sección 2.5, con los que el usuario interactúa de
manera natural sin necesidad de controles adicionales. El objetivo de Simón es
facilitar a los programadores la implementación de videojuegos con Kinect que
utilicen contenido multimedia, ofreciendo una guía para definir la mecánica de
juego.
Para su desarrollo, se utilizaron las bibliotecas Box2D y XNA. Box2D es un motor
de simulación física de elementos rígidos en dos dimensiones, mientras que XNA es
un framework de Microsoft que provee un conjunto de herramientas para el
desarrollo de videojuegos, centrando la atención del desarrollador en el diseño del
contenido y la experiencia de juego.
La plataforma está compuesta por 4 partes: un modelo de datos, una jerarquía de
pantallas, un conjunto de administradores y un grupo de elementos de juego con
16
características físicas y gráficas. El modelo de datos se utiliza para organizar la
información de los usuarios y los juegos. Simón provee una estructura de acceso a
los atributos a utilizar durante la ejecución compuesta por las clases GameInstance,
Level, User y Statistics que contienen los niveles de cada juego y las estadísticas de
cada usuario obtenidos desde XML. La clase DataManager es uno de los
administradores de la plataforma, su función es crear, mantener y gestionar el
modelo de datos. La figura 2.5 muestra esta clase y el modelo de datos.
17
FIGURA 2.5 - DIAGRAMA DE CLASES DEL MODELO DE DATOS Y LA CLASE DATAMANAGER DE SIMÓN.
La información provista por el modelo de datos es utilizada por las clases que
conforman la Jerarquía GameScreen, cuya finalidad es dar soporte para la creación
de pantallas de juego, menús y mensajes. La figura 2.6 muestra las extensiones
18
derivadas a partir de la clase raíz GameScreen y la clase ScreenManager que
coordina las transiciones entre ellas y redirige la entrada de teclado a la que se
halla activa.
FIGURA 2.6 - DIAGRAMA DE CLASES DE LA JERARQUÍA GAMESCREEN Y LOS ADMINISTRADORES DE
PANTALLAS Y CONTENIDO MULTIMEDIA.
La clase GamePlayScreen realiza las tareas comunes a todos los juegos, entre ellas
actualiza y dibuja el panel de las estadísticas de juego, inicializa las pantallas que se
usan cuando el usuario pausa o vuelve al menú principal al salir y dibuja los
elementos en pantalla.
BackgroundScreen dibuja una imagen de fondo que permanece fija
independientemente de las transiciones de las demás pantallas, mientras que
LoadingScreen coordina las transiciones entre el menú principal y la pantalla de
juego mientras se carga la partida.
Por último, MenuScreen es la clase base para las pantallas que contienen un menú
de opciones. Las clases que extienden su comportamiento son
UserFormMenuScreen, PauseMenuScreen, StatisticsMenuScreen y MainMenuScreen
19
que ofrecen una interfaz para agregar un usuario, pausar un juego, mostrar las
estadísticas de un usuario y presentar el menú principal, respectivamente. Todas
estas pantallas utilizan la clase MenuEntry para crear sus opciones de menú.
Por otra parte, la clase GameContentManager provee las texturas y fuentes de texto
para enriquecer la interfaz de usuario que utilizan todas las clases de la jerarquía
GameScreen.
Adicionalmente, las pantallas de juego utilizan elementos con propiedades físicas
que se simulan a través de Box2D. Estos elementos se definen en la Jerarquía
GameElement extendiendo la clase padre para especificar los parámetros físicos y
el aspecto visual del nuevo elemento. La figura 2.7 presenta esta jerarquía con sus
elementos de juego actuales.
FIGURA 2.7 - DIAGRAMA DE CLASES DE LA JERARQUÍA GAMEELEMENT Y EL ADMINISTRADOR
KINECTSDK.
El elemento de juego Skeleton de la Jerarquía GameElement, se utiliza para
representar al jugador en pantalla. De esta manera, este puede interactuar con los
demás elementos.
Las posiciones de las articulaciones del jugador se actualizan durante el curso del
juego con los valores de distancias de los joints del skeleton obtenidos por el
sensor Kinect.
20
Para proveer la interacción con el sensor Kinect, la plataforma utiliza el
administrador KinectSDK. Esta clase se encarga de establecer y verificar la
comunicación con el sensor, de obtener la ubicación de los joints del jugador, de
dibujar el skeleton en pantalla y de transmitir el flujo de video por pantalla cuando
se activa la cámara del sensor.
2.7 DESCRIPCIÓN DE LOS JUEGOS
Simón incluye versiones iniciales de los juegos “Círculos”, “Clasificador”, “Flechas”
y el modo libre.
El objetivo de primer juego es tocar todos los círculos que se mueven por la
pantalla para que desaparezcan. Este juego debe cumplirse dentro de en un tiempo
límite. La figura 2.8 muestra una captura de pantalla del mismo.
FIGURA 2.8 - CAPTURA DE PANTALLA DEL JUEGO “CÍRCULOS”.
El objetivo del juego “Clasificador” es clasificar círculos de colores en dos cajas
según su color, tocando el rectángulo de la derecha o el de la izquierda de acuerdo
a la caja en la que se quiere guardar el círculo. La figura 2.9 muestra una captura
de pantalla del juego.
21
FIGURA 2.9 - CAPTURA DE PANTALLA DEL JUEGO “CLASIFICADOR”.
Por otro lado, en el juego “Flechas” el jugador está ubicado entre cuatro
rectángulos (arriba, abajo, derecha, izquierda) y debe señalar el cuadro correcto
según sea la dirección de la fecha actual en la secuencia de aparición como muestra
la figura 2.10.
FIGURA 2.10 - CAPTURA DE PANTALLA DEL JUEGO “FLECHAS”.
22
Por último, el modo libre propone las mismas reglas que el juego “Círculos”, con la
diferencia de que brinda la posibilidad de agregar círculos en tiempo real y no
tiene límite de tiempo, la partida no tiene fin, el usuario finaliza la ejecución
cuando lo desea. Adicionalmente, durante este juego se puede proyectar la imagen
de video capturada por el sensor para que el jugador se identifique en pantalla.
2.8 CONCLUSIONES
En este capítulo se introdujeron los conceptos de discapacidad y tecnología
accesible, junto con distintos trabajos de investigación en el área de videojuegos
para el desarrollo cognitivo y motor.
Adicionalmente, se presentó el contexto de aplicación, la plataforma utilizada como
base de este trabajo y el sensor Kinect con el cual se ofrece una forma natural de
interactuar con videojuegos. En la siguiente sección se describen las reuniones y el
proceso de elicitación de requerimientos realizados en colaboración con los
profesionales de ATAD. Adicionalmente, se presenta la instanciación de los nuevos
juegos diseñados a partir de la elicitación con las maestras.
23
CAPÍTULO 3: ELICITACIÓN DE
REQUERIMIENTOS
3.1 INTRODUCCIÓN
Durante el último año se trabajó en mejorar la funcionalidad de una plataforma
desarrollada para facilitar la implementación de videojuegos basados en la
interacción humano - computadora utilizando como dispositivo de entrada un
sensor Kinect.
Con los videojuegos implementados se busca mejorar aspectos motores, cognitivos
y la inclusión social, por esta razón se tuvo en cuenta cubrir las necesidades de
niños con distintos tipos y grados de discapacidad para que ellos puedan disfrutar
de una sesión de juego de la misma manera que lo hacen los niños sin dificultades.
En particular, en este caso es importante remarcar que no se hacen diferencias
entre quienes tienen discapacidad y quienes no, sino que todos los niños juegan
con Simón de la misma manera sin sentir las diferencias entre ellos.
El desarrollo de este trabajo no hubiese sido posible sin comprender el contexto,
formas de trabajo, capacitación y calidad de vida de los potenciales usuarios de
Simón. Para tomar conciencia de las necesidades de las personas con discapacidad,
fue necesario tomar dos talleres de educación, inclusión y discapacidad,
organizados por ATAD, el Departamento de Educación y la Secretaría de Extensión
de la Facultad de Ciencias Exactas. Adicionalmente, trabajar para mejorar la
calidad de vida de las personas con discapacidad requiere de compromiso y, en
estos casos, desarrollar software implica ser parte del contexto para poder crear
soluciones que cubran las necesidades de manera real, teniendo en cuenta todos
los factores que puedan resultar impedimentos para los usuarios finales.
Por esta razón, es necesario salir del esquema captura de requerimientos
tradicional y de implementación de acuerdo a lo que uno como desarrollador cree
24
que es útil para el contexto en el cual se utilizará el sistema. Siendo estos factores
son de gran importancia en el marco de este trabajo, se presenta el presente
capítulo de elicitación, estudio del contexto, problemáticas e implantación y
seguimiento del sistema en ATAD. La misma tuvo una duración de
aproximadamente un año y medio, cubriendo el parte del ciclo lectivo 2014 y todo
el ciclo 2015 en los turnos mañana y tarde.
3.2 IMPLANTACIÓN Y ELICITACIÓN DE REQUERIMIENTOS
En este trabajo de tesis se contó con la colaboración de la Secretaría de Extensión
de la Facultad de Ciencias Exactas, en el marco del proyecto “Aplicaciones
interactivas para el desarrollo motor y cognitivo de niños y jóvenes con
discapacidad en espacios educativos” financiado por la convocatoria PROCODAS
del año 2014. A través de esta convocatoria se solventaron los costos del
equipamiento para el uso de Simon en ATAD. El proyecto involucró profesionales
de esta institución así como también de la mencionada Secretaría de Extensión, del
grupo ECienTec y del Instituto PLADEMA, cuyos roles se definen en la siguiente
tabla de actores relacionados al proyecto.
Actores Descripción
Profesionales de la institución Usuarios maestras, terapista, profesor de
educación física, etc.
Alumnos de la institución Usuarios niños y jóvenes con diferentes
discapacidades que concurren a la
institución.
Director del proyecto Dr. Cristian García Bauza.
Personal de ECienTec y de la
Secretaría de Extensión de la
Facultad de Ciencias Exactas.
Dra. Graciela Santos, Dra. Andrea Miranda,
Ing. Rosana Ferrati.
TABLA 3.1 - ACTORES RELACIONADOS A SIMON.
25
Durante la primer reunión en ATAD, en la cual se participó junto a uno de los
desarrolladores de la primer versión de la plataforma y el director del proyecto, se
instaló la herramienta y se enseñó a los profesionales de la institución a usar la
interfaz y los juegos de la plataforma. Un mes más tarde, se organizó otra reunión
para comenzar con la elicitación de requerimientos in situ, obtención de feedback,
corrección de bugs e implementación de nuevas funcionalidades.
La elicitación de requerimientos in situ permite conocer las dificultades de los
niños y la interacción entre ellos y los profesionales, así como también el
acercamiento con la tecnología. Cabe destacar que la mayoría de los niños no ha
tenido otro acercamiento a una computadora y que los profesionales de la
institución no están familiarizados con las mismas. Este modo de elicitación
permite comprender las necesidades de forma directa, mediante la observación de
las prácticas profesionales que se realizan habitualmente en la institución para la
que se desarrolla el software.
Para esto, se realizaron distintos tipos de entrevistas:
● Individuales con docentes de distintos turnos.
● Grupales con docentes y terapeutas.
● Con el equipo del grupo ECienTec (Educación de Ciencias con Tecnología),
docentes y terapeutas, representantes de la Secretaría de Extensión de la
Facultad de Ciencias Exactas y tutores de este trabajo.
Adicionalmente, se realizaron visitas periódicas para evaluar el funcionamiento de
la herramienta, su uso, la interacción de los niños con la misma, el acercamiento de
los docentes a la tecnología y obtención de requerimientos en base a la
observación y el trabajo de campo. También se realizan sesiones de juego en las
que participan solo las maestras y sus alumnos tomando notas sobre el
desempeño, las problemáticas y necesidades que surgen en cada sesión de juego.
Luego, estas notas fueron enviadas por mail para la implementación de mejoras.
En ambos casos, las sesiones de juego donde se usa Simon son una novedad y
entusiasman no sólo a los alumnos sino también a otros profesionales de la
26
institución que se acercan a compartir la sesión de juego. Estas tienen una
duración de una hora y media aproximadamente, y durante el transcurso de las
mismas se observa jugar a todos los alumnos por turnos.
Para unificar la información obtenida en las distintas reuniones y a través de mails,
en dos ocasiones, desde la Secretaría de Extensión de la Facultad de Ciencias
Exactas se solicitaron reuniones en horarios en los cuales se podía contar con la
mayor cantidad de profesionales presentes. Simon se utiliza en ambos turnos,
mañana y tarde, a las que concurren grupos de alumnos con diferentes habilidades
y necesidades. Los maestros y terapeutas a cargo de estos grupos tienen diferentes
puntos de vista de acuerdo a su especialidad que frecuentemente generan
requerimientos contradictorios que se tratan durante estas reuniones.
Con todo el material recolectado en la elicitación se obtuvieron distintos factores a
tener en cuenta dentro del contexto de discapacidad, adaptabilidad de la
plataforma y modificaciones para que la herramienta ofrezca entretenimiento y
educación de manera homogénea. Estos factores fueron plasmados en
requerimientos y luego en implementación de nueva funcionalidad. El próximo
paso consistió en organizar nuevas reuniones y visitas a ATAD para instalar las
actualizaciones de Simón, entrenar a las maestras en el uso de las nuevas
características, escuchar las inquietudes, nuevos requerimientos y comentarios de
los profesionales de la institución, atender consultas sobre tecnología, uso del
sistema y disposición del hardware en la habitación de juego. En la figura 4.1 se
muestran las etapas de este proceso de desarrollo y las distintas secuencias de
actividades posibles.
27
FIGURA 3.1 - ETAPAS DEL PROCESO DE DESARROLLO DE SIMON.
Es necesario notar que una reunión o sesión de juego puede ocurrir en cualquier
punto del proceso y que por esta razón ambas etapas no tienen flechas entrantes.
3.3 PROCESO DE ADAPTACIÓN AL USO DE SIMON POR LOS
ALUMNOS
La interacción a través de sistemas de interfaz natural simplifica la forma en la que
las personas utilizan sistemas de computadora. En este caso, los videojuegos que
ofrece Simón no requieren controles adicionales, lo cual en principio fue difícil de
comprender por los alumnos. Adicionalmente, Simón causó un mayor entusiasmo
por el uso de tecnología y la situación novedosa que presenta en el ámbito
educacional.
28
3.3.1 Periodo de adaptación
Para familiarizarse con el sistema, los niños pasaron por un proceso de aprendizaje
libre en el cual no tenían un gran compromiso con las reglas u objetivos del juego.
Durante este periodo, los alumnos se enfocaron en crear y llevar a cabo su propia
estrategia para comprender que el skeleton en pantalla es una representación de
ellos mismos y no simplemente un personaje moviéndose de forma aleatoria.
3.3.2 Estrategias de autoaprendizaje
En las primeras sesiones de juego, la mayoría de los niños se movían sin
comprender qué era lo que sucedía siguiendo las indicaciones de las maestras
mientras que los demás se limitaban a mirar las animaciones de los juegos sin
realizar ningún movimiento. La ubicación espacial era un concepto abstracto, ya
que la interacción con los elementos de juego se veía solo en la pantalla y no
físicamente alrededor de ellos. En estos casos, resultó de gran ayuda utilizar la
cámara del sensor para mostrar en el monitor la imagen capturada de los niños con
el skeleton sobre ellos. De este modo, ellos comenzaron a moverse mientras se
veían proyectados en pantalla, tomando conciencia de que el skeleton se movía
junto con ellos como se muestra en la figura 3.2
FIGURA 3.2 - MODO LIBRE CON VIDEO.
29
Una de las estrategias que creó uno de los niños fue escapar del área visible del
sensor. De este modo, este niño logró entender el concepto de abstracción de la
realidad realizando esta prueba varias veces, volviendo a entrar al área visible con
distintos movimientos y enseñando lo que había descubierto al resto de sus
compañeros. Con este ejemplo, los niños comenzaron a relacionar el skeleton con
su propio cuerpo y a tener un mayor compromiso con las reglas y objetivos de
juego.
Mediante la repetición de las sesiones de juego, los niños se acostumbraron al
modo de interacción, mejorando su rendimiento en cada uno de los juegos.
3.3.3 Contextos de uso
Es importante remarcar que en principio el sistema se utilizó en un aula pequeña y
de forma individual para reducir la exposición de los niños ya que muchos de estos
se inhiben fácilmente. Como contraparte, el uso de Simón en un espacio pequeño
limita los movimientos de los usuarios debido a las paredes cercanas y muebles del
aula. Por otra parte, como dispositivo de salida se utilizaba un monitor CRT de 15”
dificultando la visualización de la pantalla. Todas estas restricciones limitan la
comprensión y el desplazamiento espacial, disminuyendo el potencial de la
herramienta.
Con la compra del equipamiento, fue necesaria un aula más grande para utilizar un
proyector en vez de un monitor. Durante las primeras sesiones de juego, los
maestros notaron mejoras en los movimientos de los niños y comprendieron que
las limitaciones no se debían solamente a la falta de comprensión del juego, sino al
espacio acotado que no permitía el desplazamiento. Esto también generó que los
niños compartieran su experiencia de juego, se aconsejaran y se dieran ánimo el
uno al otro para cumplir con los objetivos. Adicionalmente, al cambiar a un espacio
mayor fue necesario delimitar el área de juego a través de marcas con tiza en el
piso, para que los niños permanecieran dentro del área visible del sensor Kinect.
Estas marcas se utilizaron en varias sesiones, hasta que los niños concientizaron el
alcance de su desplazamiento.
30
3.4 DISEÑO DE NUEVOS JUEGOS
3.4.1 Introducción
Con el objetivo de diseñar nuevos videojuegos se organizó una sesión de
brainstorming (Wilson, 2013) con los maestros. Previo a la misma, se los orientó
para que pudieran explotar su imaginación ya que al no estar familiarizados con el
contexto informático, desconocen el proceso de desarrollo y la factibilidad para
construir nuevas soluciones de software. Como resultado, se obtuvo una lista de
potenciales nuevos videojuegos que fue priorizada en base al esfuerzo técnico para
tener su implementación en el menor tiempo posible ya que se acercaba el final del
periodo lectivo y era deseable tener pruebas antes de fin de año.
Para motivar la motricidad y ofrecer contenido didáctico para reforzar
conocimientos abordados en clase, se implementaron dos juegos: “Mímica” y
“Lluvia”. El primero tiene como objetivo imitar las diferentes poses propuestas por
un personaje en pantalla, mientras que el segundo propone recolectar cierto tipo
de elementos que caen en forma de lluvia como por ejemplo letras y números,
donde el usuario debe recolectar únicamente elementos de una de estas categorías.
Las siguientes secciones detallan la instanciación de la plataforma para la
implementación de ambos videojuegos.
3.4.2 Juego “Mímica”
El objetivo del juego “Mímica” es imitar las poses que un personaje muestra en
pantalla, teniendo como limitación un cierto periodo de tiempo. Para definir la
mecánica y el objetivo de juego se implementó la clase GamePlayScreenMimic que
extiende el comportamiento de GameplayScreen, como muestra la figura 3.3.
31
FIGURA 3.3 - DIAGRAMA DE CLASES DE LA JERARQUÍA GAMEPLAYSCREEN.
GamePlayScreenMimic actualiza las poses que toma el personaje y el skeleton que
representa al usuario. La figura 3.4 muestra el personaje que propone las poses a
imitar por los jugadores.
FIGURA 3.4 - PERSONAJE DEL JUEGO “MÍMICA”.
El personaje está dividido en 4 secciones: tronco superior dividido en brazo
derecho e izquierdo y tronco inferior dividido en pierna derecha e izquierda.
Cuando el usuario adopta con alguna de sus extremidades la posición correcta, el
personaje se pinta de color verde en la sección acertada y aquellas que aún faltan
32
resolver para copiar la pose completa quedan de color blanco como muestra la
figura 3.5.
FIGURA 3.5 - PERSONAJE CON LAS EXTREMIDADES IMITADAS CORRECTAMENTE DE COLOR VERDE.
El usuario debe completar la pose en un cierto tiempo para contar como un acierto,
de lo contrario, el personaje será pintado de color rojo como se muestra en la
figura 3.6 y se contará como un fallo.
FIGURA 3.6 - PERSONAJE INDICANDO QUE SE ACABÓ EL TIEMPO.
33
Cuando la pose se imita correctamente o cuando el tiempo vence, el personaje
muestra la pose siguiente a imitar en la secuencia de poses predefinida en el editor.
Tanto el tiempo como la secuencia de poses son atributos de los niveles de juego,
siendo esta última definida por la clase Pose de la jerarquía GameElement de la
figura 3.7. Esta clase está compuesta por las posiciones esperadas para cada
extremidad. Su función es dibujar la pose en pantalla y comprobar si la postura del
skeleton es igual a la definida por el atributo posicionesEsperadas.
FIGURA 3.7- DIAGRAMA DE CLASE DE LA JERARQUÍA GAMEELEMENT.
Cada pose se compone de 4 posiciones, una para cada extremidad. Para detectar
las poses del skeleton se implementó la Jerarquía BodyPartDetection de la figura
3.8.
34
FIGURA 3.8 - DIAGRAMA DE CLASES DE LA JERARQUÍA BODYPARTDETECTION.
En esta jerarquía hay una clase por cada posición propuesta por el personaje en
pantalla. Cada una está compuesta por varios Joints e implementan el método Done
para verificar las posiciones que se muestran en la figura 3.9.
35
FIGURA 3.9 - POSICIONES POSIBLES DE LAS EXTREMIDADES SUPERIORES E INFERIORES.
La clase UtilsBodyPartDetection define los métodos cercanos, alineados y ordenados
que verifican si dos joints están aproximadamente en el mismo lugar, alineados u
ordenados en un eje. Para los dos primeros métodos se considera un rango de
aceptación. En la figura 3.10 se describen estos métodos gráficamente, siendo J1, J2
y J3 joints de la extremidad cuya posición se desea comprobar.
FIGURA 3.10 - DESCRIPCIÓN GRÁFICA DE LOS MÉTODOS CERCANOS, ALINEADOS Y ORDENADOS.
Por ejemplo, para saber si el brazo izquierdo está en posición recta hacia arriba, el
método Done de la clase LeftArmUp invoca el método ordenados para saber si la
36
muñeca, el codo y el hombro están ordenados en el eje Y y el método alineados
para verificar que tengan un desvío aceptado dentro del rango establecido en el eje
X.
Los rangos establecidos en los métodos se calculan teniendo en cuenta la
contextura física del jugador. Por ejemplo, el rango de aceptación para saber si los
joints de un brazo están alineados es la mitad de la distancia entre un hombro y el
cuello.
Las clases que verifican posiciones con una mano en la cabeza o la cintura son las
únicas que utilizan el método cercanos.
3.4.3 Juego “Lluvia”
“Lluvia” es un juego que consiste en recolectar elementos que caen desde el
margen superior de la pantalla. Estos elementos pertenecen a dos categorías
diferentes y el objetivo del juego es recolectar elementos de una única categoría.
En la figura 3.11 se muestra un ejemplo de este juego con categorías de números y
letras y donde deben recolectarse estas últimas.
FIGURA 3.11 - PANTALLA DEL JUEGO “MÍMICA”.
37
Para incluir las reglas y el objetivo de este juego se extendió la clase
GamePlayScreen implementando la clase GamePlayScreenRainingObjects como
muestra la figura 3.12.
FIGURA 3.12 - DIAGRAMA DE CLASES DE LA JERARQUÍA GAMEPLAYSCREEN.
En este caso, la clase GamePlayScreenRainingObjects crea una secuencia aparición
aleatoria de los elementos de juego teniendo en cuenta la cantidad de elementos
totales que aparecerán en pantalla y una cierta cantidad de elementos que no
deben ser recolectados. Adicionalmente, se encarga de dibujar la pantalla
incluyendo el texto que indica la categoría de elementos a recolectar y calcula los
aciertos y fallos.
Además, para dar soporte al uso de distintas categorías de elementos se reutilizan
las clases ClassifiableElements e ImageCategory creadas para agregar contenido
didáctico en el juego “Clasificador”, esta funcionalidad se detalla en la sección 4.2.1
del siguiente capítulo. Actualmente, “Lluvia” cuenta con dos tipos de elementos
clasificables disponibles: frutas y verduras y letras y números. Estos se
almacenaron en un nuevo archivo XML. En este archivo, la estructura de secciones
de los elementos clasificables es similar a la del juego “Clasificador” y se completan
como se detalla en la sección 4.2.1, con la excepción de que en este caso se definen
sólo dos categorías por elemento.
38
3.5 CONCLUSIONES
En este capítulo se describió el proceso de elicitación de requerimientos requerido
para adaptar la plataforma. Adicionalmente, se detalló el proceso de adaptación de
los alumnos a la plataforma y el diseño y la instanciación de los juegos “Mímica” y
“Lluvia”.
En la sección 4, se detalla la arquitectura, implementación y decisiones de diseño
para el desarrollo del software de este trabajo de tesis.
39
CAPÍTULO 4: IMPLEMENTACIÓN
4.1 INTRODUCCIÓN
En este capítulo se presenta la implementación de las nuevas funcionalidades de
Simon incluyendo mejoras a la UI, nuevo contenido multimedia en algunos juegos,
la edición de los niveles y los modos de usuario, entre otras. Además, se detallan
las decisiones de diseño que llevaron a las mismas.
En la sección 4.2 se describe la configuración de los videojuegos de la plataforma,
detallando los elementos y atributos que los conforman. Por otro lado, en la
sección 4.3 de este capítulo, se detallan las modificaciones realizadas en la
plataforma para adaptarla y para dar soporte a nuevas funcionalidades, mientras
que la sección 4.4 presenta la implementación de la herramienta de edición de
juegos.
4.2 CONFIGURACIÓN DE LOS VIDEOJUEGOS DE LA PLATAFORMA
Los juegos implementados utilizando la plataforma están compuestos por
elementos que tienen comportamiento dinámico es decir, que se mueven por la
pantalla de forma aleatoria o respetando un cierto patrón de movimientos, y por
elementos estáticos con comportamiento lógico, ubicados en posiciones fijas de la
pantalla de juego y representados por rectángulos. Los atributos de estos
elementos de juego se obtienen desde uno o más archivos XML de configuración.
Existen dos categorías de juegos, aquellos que solo contienen elementos dinámicos
y los que además contienen elementos estáticos. Los juegos "Círculos", "Mímica" y
modo libre pertenecen a la primera categoría, por esta razón solo utilizan un único
archivo donde se establecen las propiedades de los elementos dinámicos de cada
nivel. Estos elementos tienen características tales como: colores, gravedad,
velocidad de movimiento de los elementos, tiempo, cantidad de elementos y su
secuencia de aparición.
40
Por otro lado, los juegos "Flechas" y "Clasificador" pertenecen a la segunda
categoría de juegos, contienen elementos estáticos representados por rectángulos
cuyo tamaño y ubicación deben estar relacionados a la altura de los usuarios. En
este caso, se utiliza un segundo archivo XML que contiene las dimensiones y
posiciones de los rectángulos.
Originalmente, la ubicación y el tamaño de los elementos estáticos era única para
todos los usuarios y la disposición no beneficiaba por igual a todos los jugadores.
Las siguientes figuras presentan esta problemática.
FIGURA 4.1 - SITUACIÓN 1: ELEMENTOS ESTÁTICOS FUERA DEL ALCANCE DEL USUARIO DEBIDO A SU
ESTATURA O POR EL USO DE SILLA DE RUEDAS.
41
FIGURA 4.2 - SITUACIÓN 2: ELEMENTOS ESTÁTICOS FÁCILMENTE ALCANZABLES.
Para equiparar el esfuerzo de los usuarios se definieron los modos de juego:
Pequeño, Mediano, Alto y Sentado. Estos modos contienen valores para la
definición de la ubicación y el tamaño de los elementos estáticos.
De esta manera, se posibilita la configuración de la disposición de los elementos
estáticos de cada juego considerando las características de grupos definidos de
usuarios con características físicas similares.
La figura 4.3 describe gráficamente los valores utilizados para calcular la
disposición de los elementos estáticos de la imagen.
42
FIGURA 4.3 - DIMENSIONES Y DISTANCIAS CONFIGURABLES DEL JUEGO “CLASIFICADOR”.
Los valores detallados en la figura se utilizan para definir el tamaño y la posición
del punto central correspondiente a cada uno de los rectángulos. Para evitar su
superposición en pantalla, se han definido máximos y mínimos para los valores de
dimensión y distancia. Estos valores se obtiene dado un punto de referencia
ubicado en el centro inferior de la pantalla, en las coordenadas X e Y, teniendo en
cuenta a X como el ancho de pantalla/2 y a Y como la altura de pantalla, siendo:
● Ancho: ancho del rectángulo en relación a la resolución de pantalla. Cada
elemento puede ocupar como máximo la mitad del ancho de la pantalla,
considerando el intervalo [0, X], como indica la figura 4.4.
43
FIGURA 4.4 – ANCHO MÁXIMO DE ELEMENTOS ESTÁTICOS DEL JUEGO “CLASIFICADOR”.
● Alto: altura del rectángulo en relación a la resolución de pantalla. El
elemento puede ocupar como máximo el alto total de la pantalla,
considerando el intervalo [0, Y] como indica la figura 4.5.
FIGURA 4.5 – ALTO MÁXIMO PARA LOS ELEMENTOS ESTÁTICOS EN EL JUEGO “CLASIFICADOR”.
● Distancia Horizontal: distancia entre el punto de referencia y el centro del
rectángulo en relación a la resolución de pantalla. Esta distancia puede
tomar valores del intervalo [ancho/2, X – ancho/2]. Dado un elemento con
44
un ancho definido, este puede ubicarse entre el borde y el centro de la
misma. Cuando el elemento está junto a la línea central de la pantalla, el
valor de la distancia horizontal entre su centro y el punto de referencia es
el mínimo: ancho / 2. Por el contrario, cuando el elemento se encuentra
junto al borde horizontal de la pantalla, la distancia entre su centro y el
punto de referencia es máxima: X – ancho / 2. La figura 4.6 muestra la
distribución de los elementos en pantalla en relación a sus posiciones
mínimas y máximas.
FIGURA 4.6 – DISTANCIA HORIZONTAL MÍNIMA (ARRIBA) Y MÁXIMA (ABAJO) ENTRE EL PUNTO
DE REFERENCIA Y EL CENTRO DE LOS ELEMENTOS ESTÁTICOS.
45
● Distancia Vertical: distancia entre el punto de referencia y el centro del
rectángulo en relación a la resolución de pantalla. Esta distancia toma
valores del intervalo [alto/2, Y – alto/2]. Dado un elemento con un alto
definido, este puede ubicarse verticalmente en la pantalla dentro de los
límites superior e inferior. Cuando el elemento se ubica junto al borde
inferior de la pantalla, la distancia vertical es la mínima: alto/2. En cambio,
cuando este se ubica junto al borde superior el valor es máximo: Y – alto /
2. La figura 4.7 muestra la distribución de los elementos en pantalla en
relación a sus posiciones mínimas y máximas.
46
FIGURA 4.7 – DESCRIPCIÓN GRÁFICA DE LAS POSICIONES MÍNIMAS Y MÁXIMAS DETERMINADAS
POR LAS DISTANCIAS VERTICALES ENTRE EL PUNTO DE REFERENCIA Y EL CENTRO DE LOS
ELEMENTOS ESTÁTICOS EN Y.
Para mostrar los elementos estáticos en la vista previa, se tienen en cuenta los
valores descriptos y el lado que ocupan en la pantalla, sumando la distancia
horizontal a X si el rectángulo se ubica a la derecha y restándola en caso contrario.
Los rectángulos son creados utilizando la posición del extremo superior izquierdo
y su tamaño respetando la siguiente ecuación:
47
rectángulo = new Rectangle(X ± distancia horizontal - ancho/2, Y – distancia vertical - alto/2, ancho,
alto);
De manera similar al juego “Clasificador”, en el juego “Flechas” también se utilizan
elementos estáticos. Las fórmulas para su disposición en pantalla se detallan en la
sección Apéndice I, al final de este documento.
4.3 MODIFICACIONES EN LA PLATAFORMA
4.3.1 Elementos Clasificables
Para la creación de nuevos juegos, se trabajó en conjunto con los profesionales de
la institución, quienes sugirieron algunas ideas nuevas y otras basadas en los
juegos existentes proponiendo cambios en los objetivos de los mismos. Uno de
estos ejemplos es el “Clasificador” que en principio permitía clasificar objetos de
dos colores diferentes. Esta funcionalidad ha sido extendida para poder clasificar
distintos elementos que dan soporte a distintas áreas en las que los profesores
trabajan frecuentemente con material impreso. Generalmente, el aprendizaje se
obtiene a través de la repetición de conceptos. Al utilizar una herramienta
tecnológica, se potencia el entusiasmo y se genera el interés a través de una nueva
metodología de enseñanza que predispone al alumno a repetir los ejercicios.
Para la implementación se crearon elementos de juego clasificables siendo estos:
colores, animales y números. Al mismo tiempo, cada elemento posee tres
categorías como se muestra en la siguiente tabla.
Elementos
Clasificables
Categoría
clasificable 1
Categoría
clasificable 2
Categoría no
clasificable
COLORES ROJO VERDE AZUL, ROSA, NEGRO
ANIMALES ANIMALES
TERRESTRES
ANIMALES
ACUÁTICOS
-
NÚMEROS NÚMEROS
MENORES A 100
NÚMEROS MAYORES
A 100
-
TABLA 4.1 - ELEMENTOS CLASIFICABLES “ANIMALES”, “NÚMEROS” Y “COLORES”.
48
Los elementos clasificables pertenecen a las dos primeras categorías mostradas en
la tabla, mientras que los elementos que no deben clasificarse pertenecen a la
tercer categoría descripta como “no clasificable”. Estos se han incorporado para
agregar cierta dificultad al juego, teniendo en cuenta el razonamiento y no
únicamente el movimiento de interacción para cumplir con el objetivo del juego.
Esta tercer categoría es opcional.
Adicional a la solicitud de más categorías, los profesionales de la institución
solicitaron un nuevo juego en el cual haya una lluvia de elementos, teniendo como
objetivo recoger aquellos que pertenezcan a una categoría. En este caso, las
categorías implementadas son por un lado, frutas y verduras, y por otro, números y
letras.
Para dar soporte a esta nueva funcionalidad en ambos juegos, se implementó la
clase ClassifiableElements compuesta por categorías de tipo ColorCategory o
ImageCategory. Estas clases son extensiones de la clase Category y están
compuestas por listas de colores y de imágenes, respectivamente. La figura 4.8
muestra el diagrama de clases de los elementos clasificables y las clases
relacionadas al mismo.
49
FIGURA 4.8 - DIAGRAMA DE CLASES CLASSIFIABLEELEMENTS Y JERARQUÍA CATEGORY.
La clase DataManager descripta en la sección 2.6 como el administrador
responsable de gestionar el modelo de datos, crea los elementos clasificables y sus
categorías obteniendo sus datos desde el archivo XML que las contiene. Estos
archivos contienen una sección XML por cada tipo de elemento clasificable que
detalla los códigos RGB de los colores o las rutas relativas de las imágenes de cada
categoría. Estos datos se usan para inicializar los colores y cargar las imágenes,
respectivamente. Las últimas se obtienen a través de un método del administrador
del contenido multimedia de la plataforma, la clase GameContentManager
mencionada en la sección 6 del capítulo 2.
Además, el administrador de datos contiene un arreglo de valores por cada juego
que define los nombres de los elementos clasificables disponibles. Estos valores se
50
muestran en el menú principal como opciones de elementos a elegir previo a
comenzar una nueva partida.
En el caso del juego “Clasificador”, las categorías de los colores son de tipo
ColorCategory, mientras que las de los animales y los números son de tipo
ImageCategory. Para los primeros, se completaron las secciones en el archivo XML
con los valores RGB de los colores a utilizar y se agrega el nombre “Colores” al
arreglo del juego. Para crear los elementos clasificables de tipo ImageCategory, se
crearon las carpetas “AnimalesAcuaticos” y “AnimalesTerrestres” y se
almacenaron las imágenes a utilizar en el juego y su ruta relativa en el documento
XML. Por último, se agrega el nombre en el arreglo, en este caso la palabra
“Animales”.
Con estas modificaciones, la plataforma ofrece diversidad de contenido adaptable a
las necesidades didácticas de los alumnos. Los profesionales de la institución
consideran los juegos como material de refuerzo para el aprendizaje de temas
variados. El juego “Clasificador” permite trabajar con distintos conceptos que no
solamente ayudan a los niños a aprender conjuntos de palabras, animales o
números, sino que también permite a niños con autismo o asperger trabajar en el
desarrollo de abstracción de conceptos tales como: detectar la idea principal,
generalizar su aprendizaje a situaciones nuevas, seguir una secuencia lógica, entre
otros.
4.3.2 Mejoras en la UI
Originalmente, navegar por el menú de Simon requería el uso de combinaciones de
teclas, generando inconvenientes a los usuarios para memorizar estos atajos. Esto
fue modificado para tener un acceso más intuitivo a las opciones del sistema,
utilizando las teclas de flechas para la selección. Adicionalmente, se incorporó el
campo “Modo” en el panel de usuario actual y en el formulario para agregar un
nuevo usuario. De esta manera, se define y muestra el modo de cada usuario. La
figura 4.9 muestra el menú principal de la plataforma.
51
FIGURA 4.9 - MENÚ PRINCIPAL DE LA INTERFAZ DE USUARIO DE SIMON.
Para soportar estos cambios se modificó la clase MenuEntry que se usa para crear
opciones de menú y se mencionó al explicar las pantallas que contienen menús en
la sección 2.6. Adicionalmente, estos cambios permiten crear menús variables para
navegar entre múltiples opciones.
Antes de comenzar una partida de los juegos “Clasificador” o “Lluvia”, el menú
muestra las opciones de elementos a utilizar. La clase que gestiona el menú
principal de la plataforma fue modificada para soportar la navegación entre los
posibles elementos como se muestra en la figura 4.10.
52
FIGURA 4.10 - MENÚ DEL JUEGO “CLASIFICADOR” CON SUS OPCIONES DE ELEMENTOS.
4.3.3 Atributos de niveles y modos de juego
Durante las sesiones de juego en ATAD, los profesionales de la institución
evaluaron las dificultades de los niños para cumplir los objetivos. De estas
sesiones surgieron nuevos requerimientos para enriquecer la experiencia del uso
del sistema.
Para satisfacer algunos de estos requerimientos se agregaron los colores no
clasificables al juego “Clasificador” y diferentes colores y tamaños a los círculos del
modo libre. En ambos casos los colores se configuran en el archivo XML de los
niveles. Además se realizaron modificaciones a las clases de la plataforma
encargadas de la mecánica de juego para soportar los nuevos atributos. Por
ejemplo, para agregar colores no clasificables al objetivo de juego del
“Clasificador”, se modificó la clase que administra su pantalla de juego
GamePlayScreenChooser de la jerarquía GameScreen descripta en la sección 2.6,
para que sus métodos consideren el comportamiento del nuevo atributo. Estos
métodos se encargan de dibujar círculos con los colores establecidos en el nuevo
atributo, contar como aciertos los elementos de esta clase que no fueran
clasificados y crear la secuencia aleatoria de aparición de los elementos teniendo
en cuenta todos los colores.
53
Para agregar los modos de juego a la plataforma se agregó al modelo de datos la
clase Mode, cuyos atributos se usan para calcular las dimensiones y ubicaciones de
los elementos estáticos de los juegos que los contienen, según el perfil del usuario.
Se agregó una lista de elementos de este tipo que contiene los modos pequeño,
mediano, alto y sentado, en la clase GameInstance perteneciente al modelo de datos
descripto en la sección 2.6. La figura 4.11 muestra las clases que componen el
modelo de datos.
FIGURA 4.11 - DIAGRAMA DE CLASES DEL MODELO DE DATOS Y SU ADMINISTRADOR.
Para almacenar los modos de los juegos que utilizan elementos estáticos se usan
nuevos documentos XML. Adicionalmente, se agregó el atributo mode a la clase
User para ubicar los elementos en pantalla al alcance del jugador actual. Para poder
cargar estos nuevos archivos se agregó un método nuevo a la clase DataManager
que administra la carga y el acceso a los datos de los juegos como se explica en la
sección 2.6. Este método crea los modos y los agrega al juego al que pertenecen.
54
Por último, la clase que gestiona el menú principal MainMenuScreen de la jerarquía
GameScreen especificada en la sección 2.6, se encarga de instanciar la pantalla de
juego teniendo en cuenta el modo del usuario, el juego y los elementos elegidos en
el menú principal. Estas pantallas dibujan los elementos estáticos en pantalla
utilizando las dimensiones y distancias obtenidas desde el modo de juego con el
que fueron instanciadas.
Para permitir que estos modos sean configurados por el personal de la institución,
se desarrolló una herramienta de edición de juegos llamada "Simon Editor" que
permite a las maestras configurar los modos, atributos de niveles y dificultades de
cada juego. La implementación de este editor se detalla en la sección 4.4.
4.3.4 Mejoras del skeleton
Durante la captura de requerimientos se notó que las articulaciones del skeleton
interactuaban físicamente con los elementos de juego, mientras que las líneas que
conectan a las mismas estaban dibujadas pero no tenían propiedades físicas. Esto
confundía a los jugadores ya que cuando, por ejemplo, tocaban los elementos del
juego “Círculos” estos no desaparecían si eran tocados con una parte del cuerpo
que no fuera una articulación.
Para resolver este error, se implementó la clase SkeletonBone dentro de la
jerarquía GameElement a la cual también pertenece la clase Circle que representa a
las articulaciones o joints y el Skeleton. La figura 4.12 presenta la parte de esta
jerarquía que contiene estas clases.
55
FIGURA 4.12 - DIAGRAMA DE CLASES DE LA PORCIÓN DE LA JERARQUÍA GAMEELEMENT PROVISTA PARA
LA CREACIÓN DEL SKELETON.
La clase SkeletonBone representa cada uno de los bones del Skeleton y contiene los
dos Joints de sus extremos. Por ejemplo, el hueso del antebrazo está compuesto por
los joints de la muñeca y del codo. Esta clase utiliza Box2D para darle
comportamiento físico al bone. De esta manera, cada uno de los huesos del Skeleton
se vuelven sólidos, permitiendo rebotes. Para dibujar y actualizar las posiciones de
estos huesos, se utiliza una lista de bones en la clase Skeleton.
Por otra parte, el sensor Kinect tiene dos modos de seguimiento del jugador, el
estándar, en el cual se obtienen las veinte articulaciones, y el modo sentado, en el
cual únicamente se consideran los joints desde la cabeza hasta la cintura inclusive,
tal y como lo muestra la figura 4.13. Este modo se utiliza en las sesiones de juego
en las que participan usuarios en silla de ruedas. Con el objetivo de evitar la
56
desigualdad y la ausencia del skeleton incompleto en pantalla, las maestras de la
institución solicitaron completar la figura en pantalla para evitar que los niños se
sientan diferentes durante el uso de Simón, dando la sensación que para la
plataforma tanto los usuarios parados como los sentados no presentan ninguna
diferencia.
FIGURA 4.13 - JOINTS Y BONES DEL SKELETON EN EL MODO SENTADO QUE PROVEE KINECT (IZQUIERDA).
SKELETON EN EL MODO SENTADO CON LAS EXTREMIDADES INFERIORES DIBUJADAS POR LA PLATAFORMA
(DERECHA).
La clase Skeleton utiliza el método display de la clase KinectSDK para dibujar el
skeleton en pantalla. Este método fue modificado para incluir las extremidades
inferiores en el modo sentado.
57
4.4 SIMON EDITOR
Simon Editor ha sido desarrollado en lenguaje Java, utilizando JavaFX un conjunto
de paquetes de gráficos y multimedia para el diseño de la interfaz de usuario y
DOM como herramienta para manipulación de archivos XML para almacenar los
cambios establecidos. Como una manera de organizar la estructura y el código de
la herramienta se tomó la decisión de utilizar el patrón arquitectónico MVC, Model
View Controller (Russell et al., 2012).
Editor es el componente principal del sistema “Simon Editor” y está conformado
por los componentes Administrador de Datos y Escena, mostrados en la figura 4.14.
FIGURA 4.14 – ESTRUCTURA INTERNA DEL COMPONENTE EDITOR.
Administrador de Datos es el Controller de MVC. Este gestiona las lecturas y
escrituras de los datos en los archivos XML de configuración de los juegos. Estos
archivos representan el Model del patrón MVC y administra las unidades de datos
creadas en tiempo de ejecución.
El componente Escena representa el View de MVC, contiene todos los elementos
gráficos de la interfaz de usuario y define los manejadores de eventos que
actualizan los datos de configuración cuando se manipula un control de la interfaz.
El flujo de ejecución normal de la herramienta a través de los elementos del
sistema mostrados en la figura 4.15, comienza cuando Controller carga los archivos
XML del Model. Estos archivos contienen los datos de configuración de los juegos
58
que se utilizan para crear los objetos de juego y los atributos que componen sus
elementos estáticos y dinámicos.
FIGURA 4.15 – DIAGRAMA GENERAL DEL SISTEMA.
Luego, View inicializa la interfaz de usuario para modificar los atributos de juego y
crea los manejadores de eventos para obtener los cambios utilizando controles
gráficos.
Cuando el usuario cambia la configuración de los elementos de juego, sus eventos
asociados notifican los cambios a View. Estos cambios son gestionados por
manejadores de eventos que, al recibir el mensaje con el atributo modificado y el
nuevo valor, solicitan al Controller que modifique los atributos de los juegos.
Por último, al guardar los datos desde la interfaz, View recibe una notificación de
este evento y le pide a Controller que almacene los todos los datos en los archivos
XML.
59
4.4.1 Administrador de Datos o Controller
4.4.1.1 Inicializar Datos
El componente Inicializar Datos realiza la carga de los datos de configuración de
cada juego. En la figura 4.16, se observa que esta función pertenece al Controller y
contiene los módulos Inicializar Elementos Estáticos e Inicializar Elementos
Dinámicos.
FIGURA 4.16 – COMPONENTES DE INICIALIZACIÓN DE DATOS PERTENECIENTES AL ADMINISTRADOR DE
DATOS O CONTROLLER.
El componente Inicializar Elementos Estáticos crea e inicializa los juegos cargando
los archivos XML donde se almacenan las propiedades de ubicación y dimensión de
los elementos estáticos de los juegos.
En la figura 4.17 se presentan las clases involucradas en este componente.
60
FIGURA 4.17 – DIAGRAMA DE CLASES UTILIZADO EN LA INICIALIZACIÓN DE LOS ELEMENTOS ESTÁTICOS.
La clase Data Manager crea, inicializa y guarda los objetos del modelo de datos
(juegos, niveles y modos de juego). Estas dos últimas funciones manipulan los
datos almacenados en los archivos XML de Model. La figura 4.18 muestra sus
atributos y métodos principales.
FIGURA 4.18 – CLASE DATA MANAGER.
La Jerarquía Game está compuesta por las clases Game, PreferenceGame y
ChooserGame. Game contiene los atributos de los elementos dinámicos y define el
comportamiento para la inicialización y almacenamiento de los mismos.
PreferenceGame extiende el comportamiento de la clase Game incorporando los
atributos y métodos para la inicialización y almacenamiento de los elementos
estáticos. Por último, la clase ChooserGame mantiene en memoria la información
61
no editada de los documentos XML para guardarla en los archivos al finalizar la
ejecución.
Como se mencionó en la sección 4.1, existen dos tipos de juegos. Aquellos que
utilizan elementos estáticos y elementos dinámicos, como “Flechas” que es de tipo
PreferenceGame y “Clasificador” de tipo ChooserGame. Por el contrario, los juegos
que utilizan sólo elementos dinámicos como “Círculos”, “Mimica” y el modo libre
son de tipo Game.
La clase Game Graphics mantiene una lista de dimensiones y distancias y define los
métodos medidasDesdeXML y medidasAXML con los que inicializa y almacena sus
atributos a través de los elementos XML.
Teniendo en cuenta este diagrama de secuencia de la figura 4.19, el flujo de
ejecución se inicia en la clase Data Manager. Esta obtiene los datos desde los
archivos XML del Model, crea los juegos e invoca el método
datosEstaticosDesdeXML de cada uno, pasando por parámetro los datos de los
modos de juego. El método datosEstaticosDesdeXML crea e inicializa una instancia
de la clase Game Graphics por cada modo. Los modos se inicializan a través de la
invocación del método medidasDesdeXML. Este obtiene las dimensiones y
distancias desde el elemento XML pasado por parámetro y las guarda en una lista.
62
FIGURA 4.19 – DIAGRAMA DE SECUENCIA DE LA INICIALIZACIÓN DE LOS ELEMENTOS ESTÁTICOS.
La inicialización de los datos finaliza cuando se carga la configuración de los
elementos dinámicos a través del componente Inicializar Elementos Dinámicos. En
este caso, Data Manager instancia los juegos de tipo Game: “Círculos”, “Mímica” y
modo libre.
El comportamiento del componente Inicializar Elementos Dinámicos está definido
por la clase DataManager y las Jerarquías Game y Level. La figura 4.20 muestra en
detalle las clases mencionadas.
63
FIGURA 4.20 – DIAGRAMA DE CLASES DEL COMPONENTE INICIALIZAR ELEMENTOS DINÁMICOS.
La Jerarquía Level se utiliza para representar los niveles de cada juego. Cada uno de
estos tiene una clase que define su comportamiento.
Los juegos de la plataforma tienen algunas características en común en sus
elementos dinámicos y otras propias de cada nivel. Teniendo en cuenta la figura
anterior, las características en común son los atributos elementos, colores y tiempo.
El primero, perteneciente a la clase Level, define la cantidad de elementos
dinámicos utilizados en todos los juegos, mientras que colores de la clase LevelFree,
especifica los colores de los elementos dinámicos del modo libre y de los elementos
no clasificables del juego “Clasificador”. Por otro lado, el atributo tiempo de la clase
64
TimedLevel permite definir el tiempo para cumplir con el objetivo del juego
“Círculos”. Adicionalmente, este atributo establece la cantidad de segundos
disponibles que el jugador tiene para imitar una posición en el juego “Mímica”.
En cuanto a los atributos propios de cada nivel, en la clase LevelArrows los
atributos impulso y flechas representan la velocidad con la que se mueven los
elementos dinámicos del juego “Flechas” y la secuencia de direcciones de los
mismos, respectivamente. Los atributos gravedad y secuencia de elementos de la
clase LevelClassifier representan la velocidad con la que caen los elementos
dinámicos del juego “Clasificador” y su secuencia de colores. Por último, el atributo
poses de la clase LevelMimic es una lista que contiene la secuencia de poses a imitar
en el juego “Mímica”.
El flujo de ejecución de la inicialización de los elementos dinámicos comienza
cuando el DataManager carga el archivo XML que almacena los niveles. Este
archivo contiene la información de todos los niveles dividida en secciones
pertenecientes a cada juego. Luego, crea las instancias de los juegos que sólo
contienen elementos dinámicos y ejecuta el método nivelesDesdeXML de la clase
Game, pasando como parámetro los datos obtenidos de su sección del archivo XML.
Este método crea instancias de elementos de la Jerarquía Level con los valores
obtenidos como parámetro. En la figura 4.21 se puede observar la secuencia de
invocaciones para la inicialización de los elementos dinámicos.
65
FIGURA 4.21 – DIAGRAMA DE SECUENCIA PARA INICIALIZAR LOS ELEMENTOS DINÁMICOS.
4.4.1.2 Guardar Datos
Controller almacena los datos en los XML de configuración cuando el usuario lo
requiere a través de su componente Guardar Datos de la figura 3.22. Al mismo
tiempo, la persistencia de los datos se debe realizar de manera diferente
dependiendo del tipo de elemento a guardar, siendo estos estáticos y dinámicos
como se ha mostrado anteriormente.
66
FIGURA 4.22 - COMPONENTES UTILIZADOS PARA GUARDAR LOS DATOS PERTENECIENTES A GUARDAR
DATOS.
Guardar Elementos Estáticos almacena las características de los elementos
estáticos de los juegos “Clasificador” y “Flechas” en sus respectivos archivos XML
del Model, mientras que Guardar Elementos Dinámicos ejecuta la misma acción
para los elementos dinámicos de todos los juegos en el archivo XML de niveles.
Este componente utiliza las clases Data Manager, PreferenceGame, ChooserGame y
GameGraphics de Inicializar Elementos Estáticos mostrado anteriormente. La clase
Data Manager, invoca el método datosEstaticosAXML de los juegos que contienen
elementos estáticos para crear un elemento XML con sus datos. Este método
obtiene las dimensiones y distancias de los modos de juego invocando el método
medidasAXML de cada uno de los mismos. Luego, estos elementos son almacenados
en archivos individuales de cada juego. Este flujo de ejecución se muestra en la
figura 4.23.
67
FIGURA 4.23 - DIAGRAMA DE SECUENCIA DEL ALMACENAMIENTO DE LOS ELEMENTOS ESTÁTICOS DE LOS
JUEGOS.
Por otro lado, el componente Guardar Elementos Dinámicos almacena los niveles
utilizando las clases Data Manager, Game y la Jerarquía Level, también utilizadas
para la inicialización. A través de la clase Game, Data Manager almacena los niveles
de todos los juegos en un archivo XML ejecutando el método nivelesAXML. En este
paso, se obtiene un elemento XML con todos los niveles del juego. El flujo de
ejecución de esta funcionalidad se muestra en la figura 4.24.
68
FIGURA 4.24 - DIAGRAMA DE SECUENCIA DEL ALMACENAMIENTO DE LOS ELEMENTOS DINÁMICOS DE
LOS JUEGOS.
4.4.2 Escena o View
Hasta el momento, se han presentado los detalles de diseño del componente
Controller, encargado de inicializar y mantener la persistencia de los datos de
configuración de los juegos. Además, el sistema Editor también posee una interfaz
de usuario que permite a los usuarios manipular la configuración de los elementos
de los juegos fácilmente.
De esta manera, se posibilita la configuración de los elementos estáticos y de los
niveles de los juegos, personalizando el acceso a los elementos de la interfaz a
todos los usuarios con un esfuerzo equivalente, así como también la complejidad
de la secuencia de niveles de acuerdo a las necesidades de exigir el desempeño de
los usuarios.
La funcionalidad que permite la administración de la interfaz de usuario pertenece
a View representado por el componente Escena de la figura 4.25.
69
FIGURA 4.25 – MÓDULOS INTERNOS DE VIEW O ESCENA.
Inicializar Interfaz carga los controles gráficos de la interfaz de usuario, mientras
que Actualizar Datos administra la interacción entre el modelo de datos y los
controles utilizados para modificar sus características.
Para la implementación de este componente se utilizó JavaFX FXML, un lenguaje
basado en XML que provee la estructura para construir una interfaz de usuario
separada de la lógica de la aplicación. Este lenguaje utiliza un XML para almacenar
los elementos visuales de la interfaz de usuario y controladores que deben
definirse implementando la interfaz Initializable.
4.4.2.1 Inicializar Interfaz
La interfaz de usuario de “Simon Editor” se compone de dos tipos de elementos
gráficos: generales y particulares de cada juego. Los elementos generales cargados
desde el XML de elementos visuales de JavaFX, incluyen las solapas de cada juego y
la sección de configuración de elementos estáticos de los juegos “Flechas” y
“Clasificador”, como muestra en la figura 4.26.
70
FIGURA 4.26 – ELEMENTOS GENERALES DE LA INTERFAZ DE USUARIO DE SIMÓN EDITOR.
Por otro lado, los elementos particulares incluyen las secciones de configuración
de los niveles de cada juego, esta se muestra en la figura 4.27 delimitada con una
línea azul.
FIGURA 4.27 – INTERFAZ DE USUARIO DE SIMÓN EDITOR CON LA SECCIÓN DE CONFIGURACIÓN DE
NIVELES DEL JUEGO “CLASIFICADOR” ACTIVA.
71
El componente Inicializar Interfaz carga los elementos gráficos generales en la
interfaz desde el archivo XML sin inicializarlos y crea un controlador de tipo
RootController. Luego, ejecuta el método initialize redefinido por el controlador.
RootController crea los manejadores de eventos de los botones Guardar y Cargar
Archivo e instancia los controladores TabCirculosController, TabMimicController,
TabClasificadorController y TabFlechasController de las pestañas de configuración
de los juegos “Círculos”, “Mímica”, “Clasificador” y “Flechas”, respectivamente.
Estos controladores pertenecen a la jerarquía TabController y son presentados en
la figura 4.28.
72
FIGURA 4.28 – DIAGRAMA DE CLASES DE LA JERARQUÍA TABCONTROLLER.
Para inicializar una solapa de un juego, su controlador crea los elementos gráficos
particulares para la personalización de los niveles y configura todos los controles
de la pestaña con los valores actuales de los atributos de los elementos estáticos y
dinámicos del juego desde las unidades de datos creadas por el Administrador de
73
Datos o Controller. Adicionalmente, crea los manejadores de eventos que
administran las actualizaciones realizadas por el usuario.
El diagrama de secuencia de la figura 4.29 muestra las unidades de datos
involucradas en la creación de la solapa de configuración de niveles de la figura
4.27 presentada previamente.
FIGURA 4.29 – DIAGRAMA DE SECUENCIA DE LA INICIALIZACIÓN DE LA SECCIÓN DE CONFIGURACIÓN DE
NIVELES DEL JUEGO “CLASIFICADOR”.
Los atributos de los niveles son representados a través de instancias de las clases
de la Jerarquía Attribute en el nivel al que pertenecen. La figura 4.30 muestra está
que define los tipos de atributos simples y las herramientas gráficas para
modificarlos.
74
FIGURA 4.30 – DIAGRAMA DE CLASES DE LA JERARQUÍA ATTRIBUTE.
Los atributos de los niveles pueden ser simples, representados por un valor que
debe ser definido obligatoriamente o múltiples, que definen una característica con
uno o más atributos simples y en algunos casos son opcionales. Por ejemplo, los
colores no clasificables del juego “Clasificador” o las secuencias de aparición de los
elementos en los juegos “Flechas” y “Clasificador” que pueden ser creadas
aleatoriamente son opcionales, mientras que la secuencia de poses del juego
“Mímica” solo pueden ser configuradas por el usuario.
75
Los atributos cantidad de elementos y tiempo son de tipo ValueAttribute y se
configuran a través de un TextField, mientras que gravedad e impulso son de tipo
RangeAttribute y se modifican utilizando un Slider porque tienen límites mínimos y
máximos. La imagen 4.31 muestra los controles gráficos utilizados para configurar
estos atributos.
FIGURA 4.31 – PARTE DEL PANEL DE UN NIVEL DEL JUEGO “CLASIFICADOR” QUE MUESTRA ATRIBUTOS
DE TIPO VALUEATTRIBUTE Y RANGEATTRIBUTE.
Los atributos colores y secuencia de elementos son colecciones de objetos de tipo
ColorAttribute e ImageAttribute respectivamente. Los colores y elementos se
muestran en la interfaz como un conjunto de botones que indican su valor a través
del color o de una imagen de fondo. Adicionalmente, se provee una paleta de
colores y un menú de opciones para agregar nuevos valores. La figura 4.32 muestra
los elementos visuales de la interfaz que permiten modificar estos atributos.
FIGURA 4.32 – COLORES ADICIONALES NO CLASIFICABLES DEL JUEGO “CLASIFICADOR” Y CONTROL QUE
PERMITE AGREGAR NUEVOS COLORES (IZQUIERDA). SECUENCIA DE DIRECCIÓN DE LAS LOS ELEMENTOS
DINÁMICOS DEL JUEGO “FLECHAS” Y EL CONTROL QUE PERMITE AGREGAR NUEVAS DIRECCIONES
(DERECHA).
76
Por último, PoseAttribute define los atributos y métodos utilizados para la
configuración de las poses. Estas se muestran en la interfaz a través de cuatro
botones, como los de la figura 4.33, con los que se navega a través de las posiciones
de las extremidades.
FIGURA 4.33 – CONTROLES GRÁFICOS PARA LA EDICIÓN DE LAS POSES DEL JUEGO “MÍMICA”.
Para crear una solapa de configuración para un nuevo juego, teniendo en cuenta la
funcionalidad detallada, se debe agregar esta solapa al XML de elementos visuales
de JavaFX, incluyendo la sección de configuración de elementos estáticos si el juego
los usa. Adicionalmente, se debe crear el controlador de esta nueva solapa y la
clase que representa a sus niveles. Si en los niveles se incluyen atributos de
estructura diferente a los del resto de los juegos, se debe extender la clase
abstracta Attribute implementando el método que crea el control asociado a la
personalización del atributo.
4.4.2.2 Actualizar Datos
Para que los controles de la interfaz cumplan la función de modificar los valores
del modelo de datos, el componente Actualizar Datos define manejadores de
eventos que actualizan los atributos de juego de acuerdo a la información obtenida
desde la interfaz. Estos manejadores pueden ser de tipo ChangeListener o
EventHandler ambos son provistos por JavaFX y ejecutan sus métodos changed y
handle respectivamente, cuando reciben una notificación del valor o control gráfico
al que fueron asignados. En los casos detallados a continuación los EventHandlers
77
reciben notificaciones cuando se hace clic sobre el control gráfico al que están
asociados.
Para la actualización de las características de los elementos estáticos de los juegos
“Flechas” y “Clasificador” se utilizan controles de tipo Slider y un panel de vista
previa de tipo TabPane provisto por JavaFX que permite navegar entre un grupo de
solapas de tipo Tab también pertenecientes a la biblioteca. Este panel contiene una
pestaña por cada modo. La figura 4.34 muestra la pantalla de configuración de
elementos estáticos del juego "Clasificador".
FIGURA 4.34 - PANTALLA DE LA HERRAMIENTA "SIMON EDITOR" PARA LA CONFIGURACIÓN DEL JUEGO
"CLASIFICADOR".
El manejo de eventos en ambas secciones de configuración es similar, se utilizan
change listeners para actualizar la vista previa del modo de juego y para modificar
los atributos, máximos y mínimos cuando se utilizan los Sliders.
Para actualizar la vista previa se asigna un ChangeListener al valor de la solapa
seleccionada, que recibe una notificación cuando se selecciona una solapa y ejecuta
su método changed. Este invoca los métodos inicializarControles y
actualizarVistaPrevia implementados en el controlador de la pestaña de este juego.
IniciarControles busca el modo de juego en la lista modos de la clase
PreferenceGame utilizando el nombre de la pestaña para actualizar los valores de
los Slider. El método actualizarVistaPrevia dibuja los elementos estáticos en el
panel de vista previa del modo elegido. La figura 4.35 detalla gráficamente este
comportamiento a través de un diagrama de secuencia.
78
FIGURA 4.35 - DIAGRAMA DE SECUENCIA QUE DESCRIBE LA EJECUCIÓN DEL MÉTODO CHANGED DEL
CHANGELISTENER DE LA SOLAPA ACTUAL DE LA VISTA PREVIA.
Para modificar las dimensiones y distancias de los elementos estáticos se crea un
ChangeListener para cada Slider, que modifica el valor del atributo en el modelo de
datos y la vista previa del modo de juego actual cuando se produce un cambio en el
valor del Slider. Adicionalmente, en los casos que un cambio en el valor de una
dimensión o distancia afecta los máximos y/o mínimos de otra, invoca los métodos
que los actualizan. La figura 4.36 presenta este comportamiento gráficamente.
79
FIGURA 4.36 - DIAGRAMA DE SECUENCIA QUE DESCRIBE LA EJECUCIÓN DEL MÉTODO CHANGED
ASOCIADO A LOS SLIDERS.
Teniendo en cuenta la descripción de las dimensiones y distancias de ambos juegos
realizadas en la introducción de esta sección y en el apéndice I, la clase
TabClasificadorController define los métodos actualizarSliderDistanciaVertical y
actualizarSliderDistanciaHorizontal, estos redefinen los mínimos y máximos de los
Slider de distancia vertical y horizontal cuando se utilizan los Slider de alto y ancho,
respectivamente. TabFlechasController define los métodos
actualizarSliderDistanciaVertical, actualizarSliderDistanciaHorizontal,
actualizarSliderAlto, actualizarSliderAncho y actualizarSliderCentro. El método
actualizarSliderDistanciaVertical es utilizado para redefinir los mínimos y máximos
del Slider de distancia vertical cuando se utilizan todos los demás sliders, mientras
que actualizarSliderDistanciaHorizontal se invoca desde los ChangeListeners de los
Slider de distancia vertical, ancho y alto. Por otro lado, los mínimos y máximos para
el ancho y el alto se modifican utilizando los métodos actualizarSliderAncho y
actualizarSliderAlto cuando se modifican la distancia vertical y el alto y la distancia
vertical, el ancho y la posición vertical del centro, respectivamente. Por último, el
método actualizarSliderCentro se ejecuta para modificar los mínimos y máximos de
la posición vertical del centro cuando se utilizan los Sliders de alto y distancia
vertical.
80
Por otra parte, la sección de configuración de elementos dinámicos está compuesta
por paneles para modificar los niveles existentes y un botón para crear un nivel
nuevo. Los paneles contienen un control por cada atributo perteneciente al nivel.
Los atributos simples como tiempo, elementos, gravedad e impulso asignan
ChangeListeners a la variable que guarda el valor actual de sus controles Slider y
TextField. Estos ChangeListeners se encargan de cambiar los valores de los
atributos cuando el usuario modifica el contenido de los controles, mientras que
para modificar los atributos múltiples como colores, secuencia de elementos y poses,
se definen manejadores de eventos que eliminan o incorporan atributos simples a
las listas. La figura 4.37 muestra cómo se modifican los atributos.
FIGURA 4.37 - DIAGRAMA DE SECUENCIA DE LA MODIFICACIÓN DE UN ATRIBUTO.
De manera similar, los Handlers y ChangeListeners acceden a un atributo múltiple a
través de la secuencia de llamados que se detalla en la figura y agregan o eliminan
un elemento de la lista.
En el caso del atributo múltiple colores, la paleta incluida en el panel de
configuración de cada nivel utiliza un EventHandler que invoca su método handle
cuando se hace clic sobre un color. Este método crea una instancia de la clase
ColorAttribute, la añade al atributo colores del juego actual (“Clasificador” o modo
libre) y agrega un botón con el fondo del color elegido al panel de colores.
81
Por otro lado, para agregar nuevos elementos al atributo secuencia de elementos de
los juegos “Flechas” o “Clasificador” se utiliza un ComboBox que contiene las
direcciones de las flechas (derecha, izquierda, arriba, abajo) o los elementos
clasificables y no clasificables (derecha, izquierda, otro), respectivamente. La
variable que contiene el valor actual del control tiene un ChangeListener asignado,
cuando el valor cambia invoca el método changed. Este crea una instancia de la
clase ImageAttribute, la incorpora a la lista de elementos y crea un botón con la
imagen de una flecha de fondo rotada según el valor elegido. Las opciones de
elementos del juego “Flechas” son arriba, abajo, derecha e izquierda y las del juego
“Clasificador” son derecha, izquierda y otro.
En el caso del juego “Mímica” se asignan manejadores de eventos a los cuatro
botones de la pose y al botón “Agregar Pose”. Cuando se presiona uno de los
cuatro botones de visualización de la pose, su manejador de eventos
NextOptionBodyPartEvent cambia la imagen de fondo a la siguiente posición
disponible para esa extremidad y actualiza el contenido de la pose con el valor
actual.
El manejador de eventos HandlerNewPoseEvent del botón “Agregar Pose” inicializa
un objeto PoseAttribute con las primeras opciones para cada extremidad, crea la
visualización para esta pose y su botón “Eliminar” y agrega a ambos en el panel de
poses del nivel del juego “Mímica”.
Para eliminar un elemento perteneciente a los atributos múltiples colores y
secuencias de elementos se asignan manejadores de eventos a los botones definidos
en las clases ImageAttribute y ColorAttribute, mientras que para el caso del atributo
poses, los manejadores de eventos se asignan a los botones adicionales “Eliminar”
creados para eliminar cada pose. Los manejadores de eventos se encargan de
eliminar el elemento del modelo de datos y su representación visual del panel de
configuración del nivel al que pertenece.
4.5 CONCLUSIONES
En este capítulo, se dieron los detalles de la implementación de las modificaciones
de la plataforma y del desarrollo del editor de configuración de los elementos de
82
juego, así como también las decisiones de diseño tomadas a partir de los
requerimientos obtenidos en ATAD.
En la sección 5, se presentan las conclusiones de esta tesis y los trabajos futuros.
83
CAPÍTULO 5: CONCLUSIONES Y
TRABAJOS FUTUROS
5.1 CONCLUSIONES
En este documento se presentó la extensión de Simón, una plataforma para el
desarrollo de videojuegos, que incluye nuevas funcionalidades, corrección de
errores, nuevos videojuegos creados con la misma y “Simon Editor” una aplicación
para editar la configuración de los elementos de juego. Este conjunto de
herramientas se encuentra en uso en ATAD, Asociación Tandilense de Ayuda al
Discapacitado, una escuela especial a la que concurren niños y jóvenes con
diferentes tipos y grados de discapacidad.
El sistema implementado mejoró la movilidad de los niños de la institución y les
dio la posibilidad de generar nuevos hábitos que no habían sido tenidos en cuenta
al principio del desarrollo. A nivel individual, los niños mejoraron la ubicación
espacial1 y temporal2 y trabajaron en la percepción o conocimiento corporal3. Más
allá del entrenamiento físico y sensorial, en el transcurso del ciclo lectivo, los niños
desarrollaron un mayor compromiso con las reglas y objetivos de juego, además de
ganar confianza solicitando jugar a aquellos juegos en los que tenían mayores
habilidades. El caso más visto ha sido la selección de cualquier juego por sobre
“Flechas”, siendo este uno de los más difíciles ya que requiere una coordinación
adicional entre razonamiento y movimiento.
En cuanto a las mejoras a nivel cognitivo, los niños pudieron aprender o reforzar
conceptos tales como lateralidad, direcciones, colores y tamaños a través del
contenido de los juegos, de una forma novedosa, sin utilizar el material didáctico
tradicional como láminas o juegos de mesa.
1 2 3 http://es.slideshare.net/dixieandaur/ubicacion-temporo-espacial
84
De manera inesperada dentro de los objetivos planteados al comienzo de este
trabajo de tesis, también se obtuvieron resultados positivos a nivel grupal. Los
niños mejoraron la colaboración entre ellos, ayudándose a cumplir los objetivos de
juego de quien estaba participando, dándose ánimo o indicando los movimientos a
realizar por el jugador de turno, mejorando de esta forma la interacción social
entre ellos. Por otra parte, desarrollaron la paciencia en el proceso de espera de
instalación de la computadora y proyector en la sala común y mejoraron las
cuestiones de respeto mutuas comprendiendo que la modalidad de juego permite
que únicamente una persona esté utilizando Simón, mientras que las demás deben
esperar su turno.
En el caso de los maestros y profesionales de la institución, mientras más contacto
tenían con las herramientas desarrolladas más mejoraba la elicitación de
requerimientos. El uso de Simón facilitó los ajustes y simplificó el proceso creativo
para que pudieran imaginar los aspectos a mejorar o juegos a implementar.
Adicionalmente, destacaron la importancia de tener material didáctico novedoso,
la presencia de las TICs dentro del aula y valoraron su rol en el proceso de
desarrollo del sistema, siendo esto una experiencia nueva dentro de sus
actividades cotidianas.
Luego de un año de entrevistas y visitas a la institución, se obtuvieron algunas
devoluciones a destacar. Los siguientes párrafos describen algunos testimonios de
distintos profesionales.
“La conexión con el espacio de juego donde no hay elementos tangibles ayuda a tener
un mayor control de la motricidad cuando se trabaja con objetos reales, es un
proceso interesante y enriquecedor.” Marcelo, Profesor de educación física.
“Muy pocos chicos habían tenido la posibilidad de utilizar tecnología interactiva. Este
tipo de acceso a la tecnología es el que les abrió una nueva puerta a los niños que tal
vez, no tienen otra posibilidad de tener esta experiencia fuera de la institución.”
Belen, Terapista ocupacional.
“En el caso de los niños que juegan frecuentemente con computadoras o consolas, el
entusiasmo es el mismo que presentan aquellos que no tienen esta posibilidad ya que
85
jugar en grupo es lo que hace a la experiencia del uso de Simón”. Laura, docente de la
institución.
“Con los juegos de Simón, los niños aprendieron evaluar de manera sutil sus
movimientos ya que al principio se movían sin control alguno. El modo de interacción
con la plataforma facilitó el entrenamiento de las relaciones temporo-espaciales tan
necesarias para nuestros alumnos. Sin embargo, hay que tener en cuenta la dificultad
de realizar movimientos sin un límite concreto o sin elementos que regulen desde el
exterior el movimiento.” Marcelo, Profesor de educación física.
“Con el uso de Simón se logra una participación colectiva colaborativa entre los
chicos y las maestras que no es posible con el material didáctico convencional”.
Laura, docente de la institución.
“La sistematización del trabajo con el Juego nos permitió a todos, adultos y alumnos
una mejor aproximación a las consignas y a la organización de la actividad.” Jesus y
Laura, docentes de la institución.
“Los chicos más grandes han logrado darse cuenta oralmente de las acciones que hay
que ejecutar para cumplir con las consignas del juego. Previo a una nueva sesión de
juego, pueden explicarle a otros que deben hacer, lo que implica que interiorizaron
las acciones pertinentes que se deben ejecutar durante el juego.” Jesus y Laura,
docentes de la institución.
5.2 TRABAJOS FUTUROS
Para continuar mejorando la plataforma y los juegos a base de la colaboración con
ATAD se continuarán organizando reuniones periódicas en la institución para
asesorar a los maestros, obtener feedback y nuevos requisitos.
Algunas de las funcionalidades pendientes a implementar son:
● Mejorar la interfaz de usuario para agregar y eliminar usuarios de manera
más intuitiva.
● Agregar a la plataforma una sección de ayuda.
86
● Diseñar e implementar mecanismos para mantener o recuperar la atención
del jugador durante el juego tales como sonidos estridentes al acertar o
fallar.
● Guías de ayuda para el primer nivel de los juegos, por ejemplo animaciones
que den pistas sobre la siguiente acción a realizar.
● Agregar música o narración a los juegos.
● Corregir errores.
● Refactoring y mejoras a nivel organización de código en las herramientas
implementadas.
● Agregar nuevos elementos clasificables a los juegos “Clasificador” y “Lluvia”
según las necesidades pedagógicas de los alumnos.
● Modo multijugador para algunos juegos
Con respecto al diseño de nuevos juegos, durante las reuniones de brainstorming
se solicitaron los siguientes videojuegos que no han podido ser implementados
dentro del marco de este trabajo de tesis por falta de tiempo:
● Juegos para entrenar la memoria. Por ejemplo, un juego en el que se deban
ordenar elementos que aparecen momentáneamente al inicio del nivel y
luego se desordenan.
● Juegos de relación de conceptos cuyo objetivo sea combinar sustantivos o
adjetivos con una imagen.
● Un juego con una mecánica similar a la de “Simón dice” donde un avatar da
instrucciones orales al jugador sobre las acciones que este debe ejecutar
tales como saltar, tocar una parte de su cuerpo, hacer un paso adelante o
atrás, entre otros.
Por otro lado, se plantea el objetivo de darle más importancia a la recolección de
datos del desempeño de los usuarios a través del sistema de estadísticas que
provee Simón, para su posterior estudio. Para enriquecer esta información se
capturaran nuevos atributos como el tiempo de respuesta.
Ampliar el uso de Simón a otras instituciones y colaborar con otros proyectos
multidisciplinarios. Por ejemplo, en el área de autismo, los videojuegos
“Clasificador” y “Lluvia” pueden utilizarse para enseñar los conceptos de
87
generalización ya que los niños con autismo o asperger tienen dificultades para
comprender que dos elementos similares pertenecen a una categoría. Por otra
parte, en el área de neurociencia, los videojuegos actuales de la plataforma pueden
ser utilizados como herramienta de entrenamiento de personas en rehabilitación
por ACV y como factor sorpresa para estimular la memoria (Ballarini, 2015).
88
APÉNDICE
A.1 DESCRIPCIÓN DE LOS ELEMENTOS ESTÁTICOS DEL JUEGO
“FLECHAS”
Como se mostró previamente en la sección 3.2, en el juego “Flechas” se utilizan
elementos estáticos representados por rectángulos, cuyos valores son editados a
través de la interfaz de usuario del Editor y reflejados en la actualización de los
rectángulos de la vista previa. En la figura A.1, se muestra la sección de
configuración de los rectángulos en la herramienta Editor y las distancias y
dimensiones configurables.
89
FIGURA A.1 - PANTALLA DEL EDITOR DEL JUEGO "FLECHAS" (ARRIBA) Y PANTALLA DEL MISMO JUEGO
EN EJECUCIÓN (ABAJO).
Como se muestra en esta figura, se disponen los primeros 3/5 de la pantalla del eje
X para los elementos con comportamiento lógico. El cálculo de sus posiciones,
utiliza un punto de referencia relativo a los cuatro rectángulos, cuyas coordenadas
en X e Y están dadas por la siguiente fórmula:
X = ancho de pantalla * porción de pantalla disponible / 2
Y = alto de pantalla / 2
Para el caso de la coordenada X, se debe tener en cuenta el esquema de la figura
A.2, donde el punto se ubica en el centro de la porción de pantalla indicada en
color verde.
90
FIGURA A.2 – ESQUEMA DE LA POSICIÓN DEL PUNTO DE REFERENCIA CENTRAL EN LA PANTALLA.
De esta manera, el centro se encuentra en el punto 3/5 * 1/2 es decir, a 3/10 de
distancia del extremo izquierdo de la pantalla con respecto al ancho total en X.
Para la coordenada Y, el alto de pantalla no sufre modificaciones por lo tanto el
cálculo del centro en este eje se obtiene dividiendo el alto por 2.
Para este juego, las distancias y dimensiones se definen de la siguiente manera:
● Distancia Horizontal: distancia entre el punto de referencia y el centro de
los rectángulos izquierdo y derecho. El rango para la distancia horizontal
depende de la posición y el tamaño de los rectángulos superior e inferior y
de las dimensiones de los rectángulos izquierdo y derecho. Existen dos
casos donde el mínimo tiene diferentes valores.
En el primer caso, la distancia vertical es mayor que el alto de los elementos,
por lo cual la distancia horizontal toma valores del intervalo [ancho / 2, X -
ancho / 2]. Esto permite que los rectángulos derecho e izquierdo se ubiquen
junto al punto de referencia. De manera visual, en la figura A.3 se ilustran
ambos extremos del rango donde los elementos se separan por la distancia
mínima y máxima. Cuando los elementos horizontales están juntos, el
extremo inferior del rango es la distancia entre el punto de referencia y el
centro del elemento, siendo su valor ancho / 2.
91
FIGURA A.3 - DISTANCIA HORIZONTAL MÍNIMA (ARRIBA) Y MÁXIMA (ABAJO) ENTRE LOS
ELEMENTOS ESTÁTICOS DERECHO E IZQUIERDO Y EL PUNTO DE REFERENCIA.
En el segundo caso, la distancia vertical es menor que el alto, entonces los
elementos superior e inferior impiden la ubicación de los elementos
izquierdo y derecho junto al punto de referencia. Por esta razón, la distancia
horizontal toma valores del intervalo [ancho, X – ancho / 2]. Dado que los
anchos de todos los elementos son iguales, la distancia horizontal mínima es
igual al ancho y el cálculo de la distancia horizontal máxima no se ve
afectada. A modo visual, la figura A.4 muestra la distancia horizontal
mínima.
92
FIGURA A.4 – DISTANCIA HORIZONTAL MÍNIMA ENTRE LOS ELEMENTOS ESTÁTICOS DERECHO E
IZQUIERDO Y EL PUNTO DE REFERENCIA.
● Distancia Vertical: distancia entre el punto de referencia y el centro de los
rectángulos superior e inferior en relación a la resolución de pantalla. Los
máximos y mínimos para la distancia vertical dependen de sus dimensiones
y de la posición y el tamaño de los rectángulos derecho e izquierdo. Existen
dos casos donde el mínimo tiene diferentes valores.
En el primer caso, la distancia horizontal es mayor que el ancho de los
elementos, entonces la distancia vertical toma valores del intervalo [alto / 2,
mínimo (posición vertical del centro – alto / 2, alto de pantalla - posición
vertical del centro – alto / 2)] permitiendo ubicar los rectángulos superior e
inferior junto al centro.
El extremo superior del intervalo limita la distancia vertical. Esta aumenta
hasta que uno de los elementos se ubica junto al borde de la pantalla
superior o inferior. En este caso, se utiliza como valor máximo el mínimo
obtenido para que ambos elementos permanezcan dentro de los límites de
la pantalla. La figura A.5 muestra los segmentos a tener en cuenta para el
cálculo de esta distancia.
93
FIGURA A.5 – DISTANCIA VERTICAL MÁXIMA ENTRE EL PUNTO DE REFERENCIA Y LOS
ELEMENTOS ESTÁTICOS SUPERIOR E INFERIOR.
Como se muestra en la figura A.6, cuando no hay separación entre los
rectángulos superior e inferior, el extremo inferior del rango es la distancia
entre el punto de referencia y el centro del elemento, siendo su valor el alto
/ 2.
FIGURA A.6 – DISTANCIA VERTICAL MÍNIMA ENTRE EL PUNTO DE REFERENCIA Y EL CENTRO DE
LOS ELEMENTOS SUPERIOR E INFERIOR.
94
En el segundo caso la distancia horizontal es menor que el ancho de los
elementos, por lo cual los rectángulos derecho e izquierdo impiden que los
rectángulos superior e inferior se ubiquen junto al centro. Por esta razón, la
distancia vertical toma valores del intervalo [alto, mínimo (posición vertical
del centro – alto / 2, alto de pantalla - posición vertical del centro – alto /
2)]. La figura A.7 muestra los segmentos involucrados en el cálculo del
extremo inferior del rango.
FIGURA A.7 – DISTANCIA VERTICAL MÍNIMA ENTRE EL PUNTO DE REFERENCIA Y EL CENTRO DE
LOS ELEMENTOS SUPERIOR E INFERIOR.
● Ancho: ancho del rectángulo en relación a la resolución de pantalla. Los
máximos y mínimos para esta dimensión varían cuando se modifican el alto
del rectángulo y la distancia vertical al punto central. Existen dos casos
donde el mínimo tiene diferentes valores.
En el primer caso, la distancia vertical es mayor que el alto. La dimensión
toma valores del intervalo [0, X], aumentando hasta que los bordes de los
rectángulos izquierdo y derecho estén juntas. La figura A.8 muestra los
segmentos involucrados en el cálculo del extremo superior del rango.
95
FIGURA A.8 – ANCHO MÁXIMO DE LOS RECTÁNGULOS.
En el segundo caso, el alto es mayor que la distancia vertical y el espacio
entre los rectángulos izquierdo y derecho se encuentra parcial o totalmente
ocupado por los rectángulos superior e inferior. Por esto, el ancho del
rectángulo puede aumentar hasta que los bordes de ambos tipos de
rectángulos se junten. En este caso, el ancho toma valores del intervalo [0,
distancia horizontal]. En la figura A.9 se muestra el ancho máximo para un
valor de distancia horizontal definido previamente por el usuario.
FIGURA A.9 – ANCHO MÁXIMO DE LOS RECTÁNGULOS.
96
● Alto: altura del rectángulo en relación a la resolución de pantalla. Los
máximos y mínimos para esta dimensión cambian cuando se modifican el
ancho, el centro vertical y la distancia horizontal. Existen dos casos donde el
máximo tiene diferentes valores.
En el primer caso, la distancia horizontal es mayor que el ancho
permitiendo que el alto aumente hasta que los bordes de los rectángulos
superior e inferior se junten. Esta dimensión toma valores del rango [0, Y].
La figura A.10 describe visualmente el alto máximo.
FIGURA A.10 – ALTO MÁXIMO DE LOS RECTÁNGULOS.
En el segundo caso, el ancho es mayor que la distancia horizontal y el
espacio entre los rectángulos superior e inferior se encuentra parcial o
totalmente ocupado por los rectángulos derecho e izquierdo. Por esto, el
alto puede aumentar hasta que los bordes de los rectángulos superior e
inferior y los de los rectángulos derecho e izquierdo sean colindantes,
tomando valores del intervalo [0, distancia vertical]. En la figura A.11 se
puede observar el alto máximo para un valor de distancia vertical definido
previamente por el usuario.
97
FIGURA A.11 – ALTO MÁXIMO DE LOS RECTÁNGULOS.
● Posición Vertical del Centro: coordenada Y del punto central de referencia.
Esta posición puede ser modificada cuando los rectángulos superior e
inferior no están ubicados junto a los bordes de la pantalla. Su función es
modificar la altura a la que se encuentran los elementos, manteniendo las
demás dimensiones y distancias.
Los mínimos y máximos de la posición del centro varían cuando se
modifican el alto y la distancia vertical. La coordenada Y de la posición del
punto de referencia toma valores del rango [distancia vertical + alto/2, alto
de pantalla – alto/2 – distancia vertical].
En la figura A.12, se observa la ubicación del punto de referencia cuando su
valor vertical es mínimo. El extremo inferior del rango es la coordenada Y
del punto de referencia cuando el elemento superior limita con el borde de
pantalla.
98
FIGURA A.12 - POSICIÓN MÍNIMA DEL PUNTO DE REFERENCIA EN EL EJE Y.
La figura A.13 muestra la configuración espacial de los elementos cuando el
valor de la posición vertical del centro es máximo. En este caso, el elemento
inferior se ubica junto al borde de la pantalla.
FIGURA A.13 – POSICIÓN MÁXIMA DEL PUNTO DE REFERENCIA EN EL EJE Y.
Teniendo esto en cuenta, y considerando sumar la distancia horizontal a la
coordenada X del punto de referencia si el rectángulo se ubica a la derecha y
restándola en caso contrario. Lo mismo ocurre para la distancia vertical, la
99
coordenada Y y los rectángulos inferior y superior respectivamente. Las
ecuaciones para la creación de estos elementos son:
rectángulo superior e inferior = new Rectangle(ancho de pantalla * 3 / 10 - ancho / 2, alto de pantalla / 2
± distancia vertical - alto / 2 + posición vertical del centro, ancho, alto);
rectángulo derecho e izquierdo = new Rectangle(ancho de pantalla * 3 / 10 ± distancia horizontal - ancho
/ 2, alto de pantalla / 2 - alto / 2 + posición vertical del centro, ancho, alto);
100
REFERENCIAS
Abhijit, J., 2012, "Kinect for Windows SDK Programming Guide: Build motion-
sensing applications with Microsoft's Kinect for Windows SDK quickly and easily".
Altanis, G., Boloudakis, M., Retalis, S., Nikou, N., 2013, Children with Motor
Impairments Play a Kinect Learning Game: First Findings from a Pilot Case in an
Authentic Classroom Environment. Interaction Design and Architecture(s) Journal
- IxD&A, N.19, 2013, pp. 91-104.
Ballarini, F., 2015, REC, Editorial Sudamericana, ISBN: 978-9500753555.
Barlet, M. C., Spohn, S. D., Includification, 2012, The Able Gamers Foundation - IRS
501(c)(3) Public Charity.
Chang, C. Y. , Lange B., Zhang, M., 2012, Towards pervasive physical rehabilitation
using Microsoft Kinect, 6th International Conference on Pervasive Computing
Technologies for Healthcare.
Cook, A. M., Polgar, J. M., 2015, Assistive Technologies: Principles & Practices, 4th
edition, ISBN 978-0323096317.
Fanucci, L., Iacopetti, F., Roncella, R., 2011, A Console Interface for Game
Accessibility to People with Motor Impairments, IEEE International Conference on
Consumer Electronics - Berlin (ICCE-Berlin).
Grammenos, D., Savidis, A., Stephanidis, C.,2007, Unified Design of Universally
Accessible Games, Universal Access in Human-Computer Interaction. Applications
and Services, Lecture Notes in Computer Science, Volume 4556, 607-616.
González Sánchez, J. L., Cabrera, M., Gutiérrez, F. L, 2007, Using Videogames in
Special Education. XII International Conference on Computer Aided Systems
Theory, Las Palmas de Gran Canaria, Spain.
101
Gardner H., 1983, Frames of Mind: The Theory of Multiple Intelligences, ISBN 978-
0465025107.
Hourcade, J. P., 2015, Child Computer Interaction First Edition.
Jacko, J. A., 2012, Human Computer Interaction Handbook: Fundamentals, Evolving
Technologies, and Emerging Applications, Third Edition.
Jiang, H., Li, Z., Drew, M. S., 2005, Human posture recognition with convex
programming, in Proceedings of the IEEE International Conference on Multimedia
and Expo, Amsterdam, Netherlands, pp. 574-577.
Kiil, K.i, Ketamo, H., Kickmeier-Rust, M., 2014, Eye Tracking in Game-based
Learning Research and Game Design, International Journal of Serious Games,
Volume 1, Issue 2.
Le, T., Nguyen, M., Nguyen, T., 2013, Human posture recognition using human
skeleton provided by Kinect, Proceedings of International Conference on
Computing, Management and Telecommunications (ComManTel), pp. 340–345
Le Boulch, J., 1995, El desarrollo psicomotor desde el nacimiento hasta los 6 años:
consecuencias educativas, Editorial Paidós, ISBN: 978-8449300967.
Leyvand, T., 2011, Kinect Identity: Technology and Experience, Computer, vol.44,
no. 4, pp. 94-96.
Mori, G., Ren, X., Efros, A., Malik, J., 2004, Recovering Human Body Configurations:
Combining Segmentation and Recognition, Proc. IEEE CS Conf. Computer Vision
and Pattern Recognition, vol. 2, pp. 326-333.
Organización mundial de la salud (OMS), 2011, Reporte mundial de discapacidad,
Informe de la OMS.
Organización mundial de la salud (OMS), 2011, Clasificación Internacional del
Funcionamiento, la Discapacidad y la Salud (CIF).
Palacios J., Sagüés C., Montijano E., Llorente. "Human-Computer Interaction Based
on Hand Gestures Using RGB-D Sensors". Sensors (Basel) . (2013).
102
Piccolo, M., Fabián, M., 2014, Propuesta de trabajo final: Implementación de
videojuegos como herramienta para el desarrollo motor y cognitivo de
niños.
Ramey A., Gonzalez-Pacheco V., Salichs M.A. "Integration of a Low-Cost rgb-d
Sensor in a Social Robot for Gesture Recognition". Proceedings of the 6th
ACM/IEEE International Conference on Human-Robot Interaction (HRI). (2011).
Russell, J., Cohn, R., 2012, Model-View-Controller, ISBN 9785513484684.
Sehaba, K., Estraillier, P., Didier Lambert, D., 2005, Interactive Educational Games
for Autistic Children with Agent-Based System, Springer Berlin/ Heidelberg.
Spence, I., Feng, J.,2010, Video Games and Spatial Cognition, Review of General
Psychology, Vol. 14, No. 2, 92–104.
UNESCO, 2009, Empowering Persons with Disabilities through ICTs, ITU Telecom
World, Geneva, Switzerland.
UNESCO’s Communication and Information Sector, Knowledge Societies Division
and Microsoft Corporation, 2011, Accessible ICTs and Personalized Learning for
Students with Disabilities, Paris, Francia.
Wilson, C., 2013, Brainstorming and Beyond: A User-Centered Design Method
Wright, R. A., 2004, Short History of Progress, Anansy Pub, Toronto, ON, Canada.
Yuan, B., Folmer, E., Harris, F. C., 2011, Game Accessibility: a Survey.
Zafrula Z., Brashear H., Starner T., Hamilton H., Presti P., 2011, "American sign
language recognition with the kinect". Proceedings of the 13th International
Conference on Multimodal Interfaces. (2011).
Zhang S., He W., Yu Q., Zheng X. "Low-Cost Interactive Whiteboard Using the
Kinect". Proceedings of the International Conference on Image Analysis and Signal
Processing (IASP). (2012).
103
AGRADECIMIENTOS
A mi mamá, por ser mi mayor orgullo y mi modelo a seguir como persona,
profesional, estudiante y madre.
A mi papá y a mi hermano, por los sacrificios que hicieron para poder
acompañarme en este camino, por todo su amor y comprensión.
A Luis Murillo, mi compañero de vida, por su amor y apoyo incondicionales, por
cuidarme y sacarme una sonrisa cuando mi ánimo no es el mejor.
A mi familia política, Mabel Coppola y Armando Murillo, por tratarme como una
hija y apoyarme durante la carrera.
A mi codirectora Carolina Valdez Gándara, mi compañera y guía en el trayecto final
de la carrera, por su exigencia, apoyo y paciencia durante la escritura de la tesis.
A mi director Cristian García Bauza, por la darme la oportunidad e inspirarme a
usar mis conocimientos para ayudar a otras personas y guiarme en mi formación
profesional.
A mis amigos, Judit Montoya, Patricio Albizu, Agustin Vizcay, Leandro Tapia, Mauro
Torres, Ezequiel Geringer, Cristian Costa, Emilio Quattrocchio, Casandra Morales,
Luis Negrete y Santiago Tolley, por compartir este sueño conmigo y dejarme ser
parte de sus vidas.
A mis colegas más cercanos, Alejandro Perez, Sebastian Serritella, Virginia
Cifuentes, Pablo Rinaldi, Gustavo Boroni, Sergio Gomez, Leonardo Dominguez,
Javier Dottori, Javier Romero, Marcos Lazo y Lucas Lo Vercio por las charlas, los
consejos y las risas compartidas.
A todos los integrantes del instituto PLADEMA por dejarme formar parte de este
grupo de trabajo tan especial.
104
A mi familia más cercana, abuelos, tíos, primos y mi madrina por su apoyo y
confianza.
A los profesionales y alumnos de ATAD por recibirme en la institución con calidez
y entusiasmo.