Uso del movimiento de los Joy-Con de Nintendo Switch en el motor Unity
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Uso del movimiento de los Joy-Con de
Nintendo Switch en el motor Unity
Movement detection using Nintendo Switch
Joy-Con in Unity engine
PROYECTO DE FIN DE GRADO
Curso 2020–2021
Autores
Daniel Pérez Luque
Héctor Valverde Bourgon
Directores
Pedro Antonio González Calero
Pedro Pablo Gómez Martín
Institución
Facultad de Informática
Universidad Complutense de Madrid
Uso del movimiento de los Joy-Con
de Nintendo Switch en el motor
Unity
Memoria presentada para optar al título de Graduado en Desarrollo
de Videojuegos por Daniel Pérez Luque y al título de Graduado en
Ingeniería Informática por Héctor Valverde Bourgon
Dirigida por los Doctores Pedro Antonio González Calero y Pedro
Pablo Gómez Martín
Facultad de Informática
Universidad Complutense de Madrid
Septiembre 2021
Copyright © Daniel Pérez Luque y Héctor Valverde Bourgon
A aquellos que escuchan,
sienten y padecen
mi pequeña carga titánica.
Agradecimientos
Yo, Daniel, quiero agradecer sobre todo a aquellas personas cercanas que
con sus ánimos han conseguido que este proyecto saliese adelante. Tanto a
amigos como a familiares, aquellos que día tras día han sufrido mis comenta-
rios desalentadores en los peores momentos. Que me han seguido animando
a seguir cuando me quejaba de que no conseguíamos que nada saliese como
esperábamos. Muchos incluso buscaban alguna forma de ayudarme aun sin
tener conocimientos de programación. Gracias a todos ellos por conseguir
que no me sintiese solo ante el peligro. Y también agradecer a aquellos com-
pañeros que me han ayudado con todo lo referente al formato y estructura
de la memoria, cediéndome como ejemplo lo que habían hecho ellos.
Y yo, Héctor, quiero agradecer a mis amigos que, pese a todas las dificul-
tades que he tenido a lo largo de todos estos años, han sabido darme ánimos
para que pueda seguir adelante y poder estar aquí. En especial a mi amigo
Alejandro Borreguero, quien ha sabido enseñarme lo bonito de este mundo
y lo divertido que puede ser el desarrollo de un videojuego. Y, por último, a
mi compañero Dani, el cual ha sido muy paciente conmigo pese a no saber
mucho de programar juegos. Muchísimas gracias a todos de todo corazón, ya
falta muy poco.
vi
Resumen
Los videojuegos podrían ser definidos como el arte que aúna muchos de
los demás e incluye la interacción directa del usuario. En mayor o menor
medida hacen partícipe al jugador de lo que quieren transmitir. Además,
permiten ponerse en la piel de otros personajes, sintiendo lo que sienten. Es
por ello que empresas como Nintendo quisieron apostar por un enfoque más
directo: el control por movimiento.
Y es que posiblemente no haya nada más inmersivo a día de hoy que poder
tomar las riendas de las acciones directas del personaje que controlamos. Eso
llevó a plantear por qué un sistema tan potente como es el ordenador no
contaba con juegos que hiciesen uso de la lectura de movimiento. Cierto es
que el auge de las realidades virtuales y cámaras como Kinect ya lo permiten,
pero no todos los usuarios disponen del dinero o el espacio para utilizar esta
tecnología.
Con todo esto en mente se elaboró un proyecto en el que un usuario con
un ordenador pueda disfrutar también de videojuegos que hagan uso de la lec-
tura de movimientos. Se decidió utilizar los Joy-Con de la Nintendo Switch,
con los que se quiso investigar la precisión que se puede conseguir al realizar
movimientos con ellos. Para conseguir esto primero hubo que conectarlos a
Unity, uno de los motores más utilizados para realizar videojuegos. Además,
se tenia que plantear el hecho de crear también un modelo de red neuronal
que pudiese identificar los movimientos del jugador y que así pudiese ser
utilizado posteriormente en otros proyectos.
Todo el proyecto y sus avances quedarán recogidos en el repositorio de
GitHub: https://github.com/PsycoInformaticos/TFG
Palabras clave
Desarrollo de Videojuegos, Unity, Captura de Movimiento, Nintendo Switch,
Joy-Con, Red Neuronal Atificial, Keras
vii
Índice
Agradecimientos vi
Resumen vii
1. Introducción 1
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . 3
2. Estado de la cuestión 5
2.1. Detección de movimiento (como método de entrada) en los
videojuegos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Consola Nintendo Switch y sus Joy-Con . . . . . . . . . . . . 13
2.3. Unity como entorno de desarrollo . . . . . . . . . . . . . . . . 16
2.3.1. Motor gráfico para renderizado 2D y 3D . . . . . . . . 17
2.3.2. Motor físico . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3. Sonidos . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.4. Asset Store . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4. JoyconLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5. Aprendizaje automático y redes neuronales . . . . . . . . . . 22
3. Planteamiento 26
3.1. Toma de decisiones . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1. Sensor de movimiento . . . . . . . . . . . . . . . . . . 26
viii
3.1.2. Sistema de aprendizaje automático . . . . . . . . . . . 28
3.2. Diseño de los minijuegos . . . . . . . . . . . . . . . . . . . . . 28
3.2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2. Videojuegos de referencia . . . . . . . . . . . . . . . . 29
3.2.3. Runner . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.4. Slasher . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4. Desarrollo del proyecto 40
4.1. Primeros Pasos . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. Serialización de datos . . . . . . . . . . . . . . . . . . . . . . . 40
4.3. Red neuronal . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4. Lectura de movimiento . . . . . . . . . . . . . . . . . . . . . . 44
4.5. Minijuego Runner . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6. Minijuego Slasher . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.7. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5. Conclusiones 51
5.1. Conclusiones finales . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A. Aportaciones individuales de los autores 54
A.1. Daniel Pérez Luque . . . . . . . . . . . . . . . . . . . . . . . . 54
A.2. Héctor Valverde Bourgon . . . . . . . . . . . . . . . . . . . . 56
B. Title, Abstract and Keywords 58
B.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
B.2. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
B.3. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C. Introduction 60
C.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
C.2. Objectivs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
C.3. Workplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
C.4. Report’s structure . . . . . . . . . . . . . . . . . . . . . . . . 62 D. Conclusions 63 D.1. Last Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 63 D.2. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Bibliografía 66
Índice de figuras
2.1. Joyboard y Mogul Maniac . . . . . . . . . . . . . . . . . . . . 6
2.2. Foot Craz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Power Pad y Dance Aerobics . . . . . . . . . . . . . . . . . . 7
2.4. Sega activator . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Eye Toy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. Eye Toy Groove y Kinetic . . . . . . . . . . . . . . . . . . . . 8
2.7. Wii Remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.8. Nunchuck y Wii Motion Plus . . . . . . . . . . . . . . . . . . 9
2.9. Wii Sports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.10. Wii Balance Board . . . . . . . . . . . . . . . . . . . . . . . . 10
2.11. PlayStation Move . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.12. 6-DoF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.13. Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.14. Nintendo Switch . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.15. Modos de juego Nintendo Switch . . . . . . . . . . . . . . . . 14
2.16. Joy-Cons frontal . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.17. Joy-Cons trasera . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.18. Joy-Cons lateral . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.19. Unity partes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.20. Renderizado 3D Unity . . . . . . . . . . . . . . . . . . . . . . 18
2.21. Animacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.22. Fisica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.23. Asset Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.24. Esquema machine learning . . . . . . . . . . . . . . . . . . . . 23
xi2.25. Esquema red neuronal . . . . . . . . . . . . . . . . . . . . . . 25 2.26. Esquema interno neurona . . . . . . . . . . . . . . . . . . . . 25 3.1. Captura Ring Fit Adventure . . . . . . . . . . . . . . . . . . . 29 3.2. Captura The Legend of Zelda: Skyward Sword HD . . . . . . 30 3.3. Captura Fruit Ninja . . . . . . . . . . . . . . . . . . . . . . . 31 3.4. Roca Runner . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5. Tronco Runner . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.6. Pocion Runner . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.7. Entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.8. Minijuego Slasher . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1. Esquema serialización . . . . . . . . . . . . . . . . . . . . . . 42 4.2. Esquema dataset para modelo de red neuronal . . . . . . . . . 43 4.3. Esquema proceso de pruebas . . . . . . . . . . . . . . . . . . . 48
Capítulo 1
Introducción
1.1. Introducción
Todo buen diseño, en general, ha de cumplir ciertos factores: ser me-
dianamente innovador y proponer algo nuevo, ser funcional y útil, incluso
duradero. Según ciertos criterios y la finalidad del producto, también se es-
pera que sea estético, sencillo y fácil de utilizar. Y es quizá esto último uno
de los factores más importantes, los mejores diseños son intuitivos, hacen
que el usuario utilice el producto sin pararse a pensar cómo debe hacerlo.
La industria del videojuego, entendida como medio que genera productos
por y para el consumidor, también ha luchado por generar videojuegos y sis-
temas que cumpliesen con la mayoría de estos factores a la hora de diseñarlos.
Con el fin de que la experiencia de juego fuese mucho más intuitiva para los
jugadores, muchas compañías buscaron nuevas mecánicas y formas de jugar.
No es extraño que llegasen a la conclusión de que una de las mejores formas
de hacer que jugar fuese intuitivo fuera a través de sensores de movimiento.
Dado que muchos videojuegos simulan diferentes aspectos de la realidad,
cabe esperar que realizar ciertas acciones se entienda antes si se asemejan
a como se hacen en la vida real. Los que mejor demuestran esto son los
videojuegos deportivos y de baile, justo los que mejor han hecho uso de los
sensores de movimiento. Ejemplos de ello son videojuegos con gestos como
mover una raqueta para golpear la pelota, tensar un arco para disparar una
flecha, hacer el mejor swing para conseguir que la bola entre en hoyo, etc.
Incluso juegos que representan algo tan cotidiano como cortar verduras y
remover lo que se cuece en la olla; o todo lo contrario, juegos que hacen que
realmente seas el héroe de la historia, controlando cada corte de la espada.
El jugador ha indicado su intención de realizar todas estas acciones a través
de la pulsación de uno o más botones, lo que requería un aprendizaje previo.
11.2. Objetivos 2
Pero por medio de los sensores de movimiento estas acciones se convirtieron
en algo sencillo, totalmente interiorizado.
1.2. Objetivos
Este proyecto consta de dos objetivos principales:
Crear una librería para el desarrollo de videojuegos para ordenador que
hagan uso de dispositivos de entrada que detecten el movimiento del
jugador.
Para lograrlo se divide en estos subojetivos:
• Seleccionar un sensor de movimiento que debe cumplir:
◦ Ser preciso.
◦ Tener una fácil conexión a un ordenador.
◦ Ser cómodo y fácil de usar.
◦ Ser accesible para el usuario.
◦ Que se pueda acceder a su información y programar con ella.
• Elegir un motor de desarrollo y adaptar el dispositivo elegido a
dicho motor.
• Determinar cómo identificar distintos movimientos mediante un
modelo de red neuronal.
• Integrar el modelo de red neuronal conseguido en el motor esco-
gido.
Desarrollar uno o varios minijuegos que demuestren la eficacia y pre-
cisión de los sensores de movimiento.
1.3. Plan de trabajo
La idea original planteada para este proyecto es conseguir leer gestos
sencillos de un sensor de movimiento determinado, para luego ser aplicados
en minijuegos para pc que servirán de ejemplo. Y para ello se seguirá el
siguiente plan de trabajo.
Primero habrá que seleccionar el sensor de movimiento y el motor que
mejor se adapte a las necesidades planteadas para el proyecto. Se esperará
que el sensor aporte suficiente información útil para poder ser procesada en
forma de gestos que el usuario pueda realizar y que cobren sentido en cuanto
a mecánicas de juego. El motor deberá ser sencillo de utilizar y accesible,1.4. Estructura de la memoria 3
permitiendo la posibilidad de detectar y utilizar la información que aporte
el sensor de movimiento. En el caso de que el motor no disponga de una
librería propia que procese la información del sensor de movimiento escogido,
también será necesario encontrar una externa y aplicarla al proyecto.
Dado que la información aportada por cualquier sensor de movimiento se
dará en crudo y sin procesar como gestos, será necesario guardarla primero
como dataset y crear después un modelo de red neuronal que lo utilice como
entrada. Con ello se espera que aprenda a predecir, al menos, cuatro gestos
sencillos con los brazos: hacia arriba, hacia abajo, hacia la derecha y hacia
la izquierda.
Una vez que el modelo de red neuronal fuese capaz de identificar los
gestos planteados, lo siguiente será desarrollar minijuegos sencillos que sirvan
de ejemplo del funcionamiento de la lectura de movimiento.
Finalmente, se probará si los minijuegos dan buenos resultados con varias
pruebas. De esta forma se verá cómo de preciso es el modelo según el tipo de
dataset que se utilice para entrenarlo. Esto ayudará a concretar si el proyecto
cumple con lo esperado y facilitará el camino a seguir en futuros proyectos
que utilicen este como base.
1.4. Estructura de la memoria
Incluyendo este capítulo introductorio, la memoria consta de cinco capí-
tulos diferenciados:
El capítulo 2 describe el uso que los sensores de movimiento que han
tenido a lo largo de la historia en el mundo de los videojuegos, pres-
tando especial atención a la Nintendo Switch. Explica, además, todo
lo que puede hacer el motor de Unity y la librería que permite la co-
nexión entre este motor y los mandos de Switch. Finalmente introduce
el concepto de aprendizaje automático y concretamente el de redes
neuronales.
El tercer capítulo muestra todo el planteamiento y diseño que elabo-
ramos. Comenta cómo fueron saliendo las ideas y las decisiones que se
tuvieron que ir tomando. También incluye el diseño principal de ca-
da uno de los minijuegos planteados para demostrar la precisión de la
lectura de movimientos.
El capítulo 4 explica el contenido final del proyecto, indicando más
detalladamente como funciona todo lo que se ha hecho.1.4. Estructura de la memoria 4
Finalmente, en el capítulo 5 se valora si se han conseguido los objetivos
plateados y hasta qué punto. Además, termina indicando ideas que se
podrían seguir en el futuro para perfeccionar todo lo ya realizado.Capítulo 2
Estado de la cuestión
2.1. Detección de movimiento (como método de en-
trada) en los videojuegos
Como se comenta en The Rhetoric of Exergaming (Bogost, 2005), histó-
ricamente en los videojuegos se utilizaban dispositivos de entrada estándar
(teclados) o específicos (joysticks, pads), que no imitan el movimiento real
que tendría que hacer el jugador para realizar una acción, lo cual dejaba
al hecho de jugar videojuegos como una actividad sedentaria. Para incen-
tivar que los usuarios hiciesen algo de ejercicio mientras jugaban apareció
una nueva categoría de juegos que más adelante pasaría a conocerse como
exergames, una combinación entre las palabras inglesas exercise y game. To-
dos ellos recogen un input que obliga al jugador a realizar con su cuerpo los
gestos o movimientos que se piden en el juego, ya sea mediante sensores de
movimiento reales o mediante el mapeado de los botones de un controlador
normal a otro dispositivo. Estos últimos tendían a tener forma de plataforma
o alfombrilla y la intención era que se pulsasen los botones con los pies.
En la década de los 80 empezaron a aparecer dispositivos que cambia-
ban el formato y requerían algún tipo de ejercicio físico. La pionera fue la
Joyboard de Amiga Corporation en 1983 con un periférico para Atari 2600.
Detectaba la inclinación del jugador en cada una de las cuatro direcciones al
subirse encima. Contaba con cuatro teclas direccionales internas que mapea-
ban la inclinación del jugador como si se utilizase un joystick corriente. Salió
con un único juego de esquí, llamado Mogul Maniac. Tanto el dispositivo
como el videojuego se puede observar en la figura 2.1.
A este periférico le siguió otro para la misma consola: Foot Craz (Figu-
ra 2.2), que continuaba con la idea anterior. En este caso el “joystick” había
tomado forma de “pad” o alfombrilla, extendida más adelante para juegos de
52.1. Detección de movimiento (como método de entrada) en los videojuegos6
Figura 2.1: Periférico Joyboard (izquierda) y Mogul Maniac (derecha).
Figura 2.2: Foot Craz (Exus, 1987)
baile, ya que la intención era que los botones se pulsasen con los pies. Tenía
cuatro botones de distintos colores, alineados en horizontal y que respondían
al ser pulsados, mapeados como si fueran las cuatros direcciones del joystick
original. Se añadía, además, un quinto botón que se mapeaba con el de ac-
ción del joystick de la consola (Loguidice y Barton, 2009). Un año después
fue Nintendo la que produjo su propio pad: Power Pad o Family Fun Fitness,
como se le nombró en Europa (Figura 2.3). Contaba con mayor cantidad de
botones, permitiendo así más modos de juego. Además, la misma alfombrilla
disponía de dos caras con distintos diseños, aunque usaban los mismos doce
botones bajo la cubierta. La cara más utilizada tenía doce círculos nume-
rados, la mitad azules y la otra mitad rojos, de forma que permitía jugar
a dos personas simultáneamente con cada mitad. Todas estas posibilidades
llevaron a que otras compañías diferentes de la propia Nintendo se animasen
a hacer sus propios juegos para este periférico. Un ejemplo es el Dance Aero-
bics que, como se muestra en la figura 2.3, reflejaba directamente en pantalla
una muestra del pad y donde se debía pulsar en cada momento.
En 1993 Sega sacó al mercado el periférico Sega Activator o Activator
Ring (Figura 2.4) para la Sega Mega Drive (Loguidice y Barton, 2009). Con-
sistía en un conjunto de piezas que se unían formando un octógono y cada
una de ellas proyectaba una luz infrarroja hacia el techo. Esto dotaba de
ocho direcciones en las que el jugador, dentro del octágono, podía realizar2.1. Detección de movimiento (como método de entrada) en los videojuegos7
Figura 2.3: Power Pad (Nintendo, 1988) y Dance Aerobics (Bandai, 1988)
Figura 2.4: Sega Activator (Sega, 1993)
movimientos que se verían reflejados en pantalla. Realmente no dejaba de
ser un mapeado de un controlador normal, como ha venido sucediendo hasta
ahora, solo que sustituía los botones por haces de luz infrarroja que envia-
ban el input cuando detectaban que algo los atravesaba. Sin embargo, esta
tecnología quedaba distorsionada con elementos y luces de la estancia, im-
pidiendo jugar correctamente. Debido a esto tuvo poco éxito y solo se lanzó
en Estados Unidos.
Volviendo al formato de pulsadores para los pies, apareció el videojue-
go Dance Dance Revolution (Konami, 1998), que se originó como máquina
arcade con una base de placas de presión metálicas con las flechas de las di-
recciones. Fue recreada en múltiples consolas en formato de alfombrilla para
jugar en los hogares. Incluso se vendía el juego sin la alfombrilla ya que se
podía utilizar un controlador normal para jugar. Seguía la dinámica principal
de indicar al jugador por pantalla la siguiente flecha que debía pulsar en el
momento justo. De esta forma se conseguía que los jugadores sintiesen que
estaban bailando una coreografía de verdad.
En 2003, Sony revolucionó el uso de movimiento como entrada en vi-
deojuegos a través del dispositivo EyeToy (Figura 2.5) para PlayStation 2.
Consistía en una cámara con la que se recogía la imagen del jugador y se in-
tegraba en el propio juego, de forma que reconocía en tiempo real los gestos2.1. Detección de movimiento (como método de entrada) en los videojuegos8
Figura 2.5: Eye Toy junto a una captura de Eye Toy: Play (London Studio,
2003)
Figura 2.6: Capturas de Eye Toy: Groove y Eye Toy: Kinetic (London Studio)
que realizaba gracias a un sistema de rastreo de movimientos. Salió origi-
nalmente junto a Eye Toy: Play (Figura 2.5), un conjunto de minijuegos de
diversa índole. Pero la misma compañía fue creando todo tipo de experien-
cias como el baile (e.g. Eye Toy: Groove en 2003) o el entrenamiento o fitness
(e.g. Eye Toy: Kinetic en 2005) como muestran las capturas de la figura 2.6.
En 2006 Nintendo1 cambió la forma de jugar gracias a su consola Wii,
que incorporaba sensores de movimiento en el propio dispositivo. Contaba
con los Wiimotes o Wii Remotes (Figura 2.7), unos mandos dotados de
sensores inerciales de movimiento. Destaca el acelerómetro que detectaba la
aceleración, la vibración, la velocidad y la inclinación que se ejercía sobre el
mando (Farkas, 2007). Reconocía la aceleración en tres ejes y, midiendo la
dirección de la gravedad, conseguían los ángulos pitch y roll, que eran la base
del reconocimiento de gestos de muchos juegos. Por sí solo, el acelerómetro
no es capaz de rastrear la posición relativa y la orientación del mando en
el espacio. Por ello, los wiimotes cuentan también de un sensor óptico, que
junto a la barra de infrarrojos que incorporaba la consola, permitía detectar
a donde se estaba apuntando el mando y la dirección en la que se estaba
moviendo. El sensor óptico detectaba los diez LEDs de la barra de infra-
rrojos, de forma que estando frente a ella podía determinar la distancia y
su posición en el espacio según como incidiesen las luces infrarrojas. Cuanto
más lejos estuviese, detectaba más juntas las luces, formando un solo punto;
1
Datos técnicos e imágenes obtenidas de la página oficial: https://www.nintendo.es/2.1. Detección de movimiento (como método de entrada) en los videojuegos9
Figura 2.7: Wii Remote con distintos de sus accesorios
Figura 2.8: Accesorio nunchuck y Wii Motion Plus para el Wii Remote
y cuanto más cerca de la barra, detectaba más luces por estar más separadas.
Añadiendo el mando nunchuck (Figura 2.8) se le permitía al jugador mayor
versatilidad a la hora de recrear movimientos, pues también contaba con un
acelerómetro propio. Uno de los ejemplos que representa la eficacia de los
mandos en distintas actividades es el juego que viene incluido con la consola:
Wii Sports (Nintendo, 2006), que permitía jugar al tenis, al baseball o al golf
entre otros deportes, como se observa en la figura 2.9.
Posteriormente se mejoró la tecnología de los wiimotes mediante el acce-
sorio Wii Motion Plus (Figura 2.8), que se conectaba en la base del mando y
permitía detectar movimientos más precisos. Esto era así debido a la inclu-
sión de un giróscopo, que medía la orientación espacial o rotación del mando
en cada uno de los tres ejes. Por sí mismo no detectaba los movimientos li-
neales, pero junto al acelerómetro se conseguía una mejor precisión a la hora
de representar la posición espacial del mando. También se distribuyó direc-
tamente acoplado al mando para evitar tener que estar conectándolo. Juegos
como The Legand of Zelda: Skyward Sword (Nintendo EAD, 2011) solo se
pueden jugar con Wii Motion Plus. En este caso, el juego tiene mecánicas
en las que es necesario realizar un gesto determinado para derrotar a ciertos
enemigos o superar determinados puzzles2 .
2
Esto ha sido adaptado a los mandos de Switch en el remake lanzado para esta consola
a finales de julio de 20212.1. Detección de movimiento (como método de entrada) en los videojuegos
10
Figura 2.9: Wii Sports (Nintendo, 2006)
Figura 2.10: Wii Balance Board (Nintendo, 2008)
Nintendo sacó al mercado Wii Balance Board en 2008 (Figura 2.10).
Era un periférico con forma de tabla sobre la que se subía el jugador para
detectar los cambios de peso ejercido sobre cada una de sus cuatro básculas,
una por cada pata. Estos cambios de peso indicaban un cambio en el centro
de gravedad del jugador, tanto en el eje horizontal como en el vertical. Con
esto se intentaba deducir la postura del jugador sobre la Balance Board,
lo que permitió una mayor precisión a la hora de realizar actividades como
aerobic o yoga.
Tras el éxito de Wii, Sony lanzó en 2006 su PlayStation 3 con un mando
que contaba con giróscopos y acelerómetros. Se le llamó inicialmente Sixaxis
ya que detectaba movimiento en seis ejes. Tres de estos ejes para detectar
movimientos posicionales mediante acelerómetros y otros tres para determi-
nar la rotación mediante giróscopos. Más adelante se revisó el mando y se
le añadió vibración, conociéndosele finalmente como Dualshock 3. Pese a los
acelerómetros con los que contaba, era complicado detectar desplazamien-
tos, por lo que en 2010 lanzaron PlayStation Move. Estaba compuesto por
un controlador principal, o Motion Controller, un mando alargado con una
esfera luminosa en su extremo; el Navigation Controller, que venía a suplir
las características del nunchuck de Wii de forma inalámbrica; y la cámara2.1. Detección de movimiento (como método de entrada) en los videojuegos
11
Figura 2.11: PlayStation Move: Navigation Controller (izquierda), Motion
Controller (centro) y PlayStation Eye (derecha)
Figura 2.12: 6-DoF (6 grados de libertad)
PlayStation Eye (Figura 2.11 (Amos, 2019)). A los nuevos controladores se
les añadieron magnetrónomos y un termómetro para corregir las desviacio-
nes de los acelerómetros y giróscopos. La cámara mejoraba en resolución
respecto a la EyeToy, consiguiendo detectar los movimientos mejor incluso
en entornos con poca luz. Y en este caso, era la esfera lumínica del Motion
Controller la que se reconocía desde la cámara y permitía la colocación en
el espacio, de manera que se conseguía un 6-DoF real (Figura 2.12).
Posteriormente estos periféricos fueron mejorados para su uso en PlaySta-
tion 4. El mando Dualshock 4 añade una luz frontal que hace que la cámara
también lo detecte. Esta última se rediseñó y rebautizó como PlayStation
Camera, que seguía reconociendo el movimiento realizado y además lo hacía
en profundidad gracias a su segunda cámara, tal y como había hecho años
atrás el sistema Kinect de Microsoft.
A la estela del auge de los juegos basados en el movimiento que había co-
menzado Nintendo con su consola Wii, Microsoft puso a la venta en 2010 su
propia alternativa a través del dispositivo Kinect (Figura 2.13), para XBox
360 (Loguidice y Loguidice, 2012). Sigue la aproximación de EyeToy, pero2.2. Consola Nintendo Switch y sus Joy-Con 12
Figura 2.13: Kinect(Microsoft, 2010)
disponía de una doble cámara que detectaba la imagen en color de lo que
hacía el jugador y la posición en tres dimensiones de este respecto a la sala
en la que se encontraba, recogiendo así movimientos mucho más precisos.
Además, gracias a su pivote motorizado era capaz de seguir al jugador hacia
arriba y hacia abajo. Detectaba el cuerpo completo, pudiendo diferenciar
hasta seis personas distintas a la vez en la imagen, pero solo cuatro de ellas
las tomaba como parte de los jugadores actuales. Esto, sin embargo, añadía
latencia pues se necesitaba más potencia de cálculo, lo que retrasaba la de-
tección y perjudicaba la experiencia. Aún así se adaptó para funcionar en
las siguientes consolas de la compañía y en sistemas Windows.
Actualmente, está en auge la tecnología de realidad virtual. La usada
en los visores con pantallas propias incluye acelerómetros y giróscopos que
detectan los giros y movimientos de la cabeza. De esta forma se consigue
rotar la cámara siguiendo el movimiento que haga el jugador. Y muchos de
estos sistemas se lanzan al mercado con sus propios mandos, que incorporan
también acelerómetros y giróscopos para reconocer los movimientos del ju-
gador y representarlos, por ejemplo, en las manos del personaje dentro del
juego. Las PlayStation VR utilizan PlayStation Move al completo, de forma
que disponen de la cámara para ayudar a detectar la profundidad y posición
espacial del Motion Controller. De nuevo, esto permite leer movimientos en
6-DoF para ser más preciso en los movimientos, lo que además aumenta la
sensación de inmersión.
En la sección siguiente se realiza un análisis exhaustivo de la consola
Nintendo Switch y sus mecanismos de detección de movimiento, por ser la
que se ha utilizado en el proyecto.2.2. Consola Nintendo Switch y sus Joy-Con 13
Figura 2.14: Nintendo Switch original
2.2. Consola Nintendo Switch y sus Joy-Con
En marzo de 2017 Nintendo sacó su Nintendo Switch (Figura 2.14 (Amos,
2019))3 . La idea de consola híbrida le permite ser disfrutada con un televisor
o en formato portátil. La propia consola con el hardware principal consta
de una pequeña pantalla LCD multitáctil, pero se puede conectar mediante
un soporte a un televisor. En la versión original, los mandos o Joy-Con se
conectan a cada lado de la consola. Esto permite que el usuario disponga de
distintas modalidades de juego según la situación. Los Joy-Con pueden estar
encajados en la propia consola actuando como consola portátil (Figura 2.15
en la parte derecha), o retirados del hardware principal para ser utilizados
de estas formas:
Modo televisor: La consola está conectada al televisor y los Joy-Con
están unidos a un soporte con forma de mando convencional. También
es posible jugar teniendo cada Joy-Con en una mano, de esta forma se
podrá realizar con ellos movimientos más complejos (Figura 2.15 en la
parte izquierda).
Modo sobremesa: Se utiliza la pantalla propia de la consola y cada
Joy-Con en horizontal, separado de forma individual permitiendo a dos
jugadores jugar a la vez, uno con el Joy-Con izquierdo y otro con el
derecho (Figura 2.15 en la parte central).
Cada Joy-Con está pensando para que, por separado, ocupe poco en la
mano y sea fácil de manejar. Dispone de cuatro botones de acción delanteros,
marcados como A, B, X, Y en el derecho y las flechas de dirección en el
izquierdo, un joystick analógico que se puede pulsar, los botones más(+) y
menos(-), dos gatillos y dos botones laterales que sobre todo tienen su uso
al manejar cada Joy-Con en horizontal de forma individual. Ambos cuentan
3
Las demás imágenes e información técnica se ha sacado de la página
oficial de la consola: https://www.nintendo.es/Familia-Nintendo-Switch/
Familia-Nintendo-Switch-1618251.html2.2. Consola Nintendo Switch y sus Joy-Con 14
Figura 2.15: Modos de jugar con Nintendo Switch
Figura 2.16: Joy-Con parte frontal
con tecnología de giroscopio y acelerómetro, además de una función llamada
vibración HD que permite una respuesta táctil al jugador de lo que pasa en
pantalla.
El Joy-Con derecho, además, cuenta con sensor NFC que permite la
lectura de los productos de la familia amiibo, una serie de figuras con formas
de los personajes de distintos juegos que aportan algún tipo de material o
funciones dentro del propio juego cuando se conectan. También dispone de
un sensor de infrarrojos que permite detectar movimientos, la distancia del
mando a un objeto y distintas formas. Como ejemplo el juego Brain Training
lo utiliza para detectar la mano del jugador y probar su habilidad mental en
el juego “Piedra, papel o tijera”.
Cuando los Joy-Con no están conectados a la propia consola, esta los
detecta por conexión Bluetooth, lo que permite que los mandos también se
puedan conectar a otros dispositivos que utilicen esta tecnología, como los
ordenadores. Y, para evitar que los mandos se le caigan o escurran de la
mano al jugador, estos vienen con una correa que se adapta a la muñeca.2.2. Consola Nintendo Switch y sus Joy-Con 15
Figura 2.17: Joy-Con parte trasera
Figura 2.18: Joy-Con parte lateral
Esta se conecta a los Joy-Con a través de otro raíl como ocurre en la consola.
Suplen, además, los botones laterales que ocultan al colocarse, dándoles más
volumen y mejorando su pulsado.
Se ha centrado este apartado en las características de la consola origi-
nal y en sus Joy-Con, pero coexiste con otra versión, la Nintendo Switch
Lite4 . Esta variante está diseñada para ser operativa solo en formato por-
tátil, no pudiéndose conectar a la televisión ni separar los Joy-Con de esta,
pues vienen integrados en la propia consola como controlador principal. Aun
así se puede jugar con ella a todos los juegos que sean compatibles con el
4
En el momento que se redactó esta memoria fue anunciada una nueva versión: Nin-
tendo Switch Oled, que mejoraba la pantalla y añadía pequeñas características nuevas. No
se ha querido tener demasiado en cuenta ya que no cambia la tecnología de los mandos y
los sensores de movimiento.2.3. Unity como entorno de desarrollo 16
modo portátil y, para los que no son compatibles con este modo, se pueden
incorporar Joy-Con por separado.
2.3. Unity como entorno de desarrollo
Unity es uno de los entornos de desarrollo mas utilizados mundialmente
en el ámbito de desarrollo de videojuegos para diversas plataformas. Permi-
te crear tanto juegos retro en dos dimensiones hechos para teléfonos móviles
hasta juegos de mundo abierto con decenas de jugadores en cualquier orde-
nador. Unity consiste en un editor para la creación de juegos con un motor
en ejecución. Está basado en componentes programables en C# y posee he-
rramientas útiles para el desarrollo de videojuegos, puesto que nos facilitará
el desempeño de labores como la creación de física o animaciones de los
elementos de la escena.
A día de hoy Unity es de los motores de videojuegos más utilizados,
debido a la gran variedad de herramientas que lleva incorporado permitiendo
muchas facilidades a sus programadores 5 .
Los beneficios mas importantes que aporta Unity son su acelerado de-
sarrollo (dados los elementos que vienen incorporados en Unity y que se
explicarán mas adelante, su entorno de desarrollo integrado dentro del soft-
ware, la interfaz gráfica del usuario muy clara y fácil de usar y, por último,
implementación multiplataforma, dado que permite recrear entornos con sin
dificultad (como Android o iOS) (Felicia, 2015)
Unity fue un gran impulso de cara a la creación de videojuegos, puesto
que anteriormente los programas para desarrollarlos seguían un proceso muy
desalentador, especialmente los gratuitos debido a la pobre ejecución que
tenían y la escasa documentación. Gracias a la revolución que fue Unity,
actualmente personas con poco conocimiento pueden ser capaces de hacer
juegos (Menard y Wagstaff, 2015).
La interfaz (Figura 2.19) del programa se divide en 6 partes:
Vista de escena: permite navegar por el escenario y editar visual-
mente la escena del proyecto. La vista puede ser tanto en 2D como
en 3D y posee herramientas para poder visualizar los elementos de la
escena y editarlos.
Juego: Es la pantalla donde se prueba el juego que se está desarro-
llando. Permite ajustar la escala y la resolución del propio juego, así
como aportar información sobre el audio y los gráficos.
5
Valores que promueve la compañía y sus cifras, indicando la cantidad de usuarios
utilizando Unity https://unity.com/our-company2.3. Unity como entorno de desarrollo 17
Figura 2.19: Vista general de la interfaz de Unity
Jerarquía (Hierarchy): Consiste en una representación jerárquica de
todos los elementos de la escena en forma de texto. También se puede
observar como están relacionados los elementos de la escena.
Inspector: Muestra las propiedades del objeto que está seleccionado
en la vista de la escena o de la jerarquía. Al ser un motor basado en
componentes, el inspector muestra, para cada uno de ellos, las propie-
dades que incorporan por separado, permitiendo modificarlas.
Ventana del proyecto: Esta ventana muestra los recursos de los
que dispone el proyecto. Dichos recursos son elementos que pueden
provenir de archivos fuera de Uniy, como puede ser un modelo 3D
o un archivo de Audio, pero pueden ser también creados por Unity
(como una textura). Se puede organizar mediante carpetas, por lo que
es habitual estructurar los recursos separándolos por tipos (imágenes,
sonidos, materiales, etc).
Barra de herramientas: Esta parte da acceso a las herramientas mas
esenciales a la hora de trabajar con Unity. Posee, entre otras cosas,
herramientas para poder manipular tanto la escena como los objetos
que se encuentran en ella y los controles para iniciar y parar el proyecto.
Las herramientas que proporciona Unity para poder facilitar el desarrollo
de videojuegos se detallarán en los siguientes apartados.
2.3.1. Motor gráfico para renderizado 2D y 3D
Unity cuenta con un motor gráfico que permite el renderizado tanto en
2D como en 3D (Figura 2.20).
El renderizado 3D consiste en un proceso encargado de producir una
imagen a través de datos tridimensionales. Al renderizar, los gráficos del or-
denador convierten modelos 3D en imágenes 2D con efectos 3D fotorrealistas,
o lo más cercano a la realidad posible.2.3. Unity como entorno de desarrollo 18
Figura 2.20: Ejemplo del alcance del renderizado de Unity
Se pueden renderizar imágenes en tiempo real, que es lo mas común en
los videojuegos. Esto se realiza a velocidades muy altas, que hace ver que
las escenas, compuestas de muchas imágenes en poco tiempo, se producen
muy rápido, reflejando al momento toda interacción del jugador. Es por esta
razón que el renderizado es una base fundamental de los videojuegos.
El renderizado en Unity utiliza 3 elementos para llevarse a cabo:
Materiales: indica cómo debe renderizarse una superficie e incluye
referencias a las texturas que utiliza. Las opciones disponibles para un
Material dependen del shader que el material esté usando.
Shaders: scripts que calculan el color de cada píxel procesado, en
función de la iluminación y la configuración del material.
Texturas: un material puede contener referencias a las texturas, de
modo que el shader del material pueda usar las texturas al calcular
el color de la superficie de un GameObject.
Una forma de darle realismo a los objetos que existen en un juego es
mediante las animaciones, lo que permite crear un ambiente mas dinámico
(Figura 2.21).
Todos los elementos de la escena son objetos (en Unity GameObject) y
constituyen el componente básico del software. Todos estos GameObjects
poseen un parámetro llamado Transform, usado para almacenar la posición,
rotación, escalado y estado y que todos los GameObject poseen.
Las animaciones consisten en modificar alguno de los parámetros que
conforma el transform de cada objeto, por lo que podemos modificar su
escala, posición o rotación. Dichas modificaciones se realizarán a lo largo de
un tiempo y es lo que conformará la animación.2.3. Unity como entorno de desarrollo 19
Figura 2.21: Jugador de uno de nuestros minijuegos, tiene la animación de
correr y saltar
2.3.2. Motor físico
El motor físico que tiene Unity esta orientado a entornos 2D y 3D, siendo
muy similar en ambos casos, utilizando componentes muy similares como lo
son los rigidbodies, colliders o joints pero añadiendo diferencias en función
del tipo de proyecto que tenemos (Figura 2.22).
Rigidbody: Es uno de los componentes cruciales dentro de Unity,
puesto que al asignar este a algun gameobjects hace que sea capaz de
detectar colisiones, pudiendo modificar su velocidad, aplicarle fuerzas
o sentirse afectado por la gravedad, entre otras cosas. Es gracias a
esto que se puede otorgar a un objeto un comportamiento de masa y
gravedad, muy similar al de la vida real.
Collider: Los collider, junto a los rigidbody, son la base de la física
de Unity. En concreto los collider tienen una estructura geométrica
que permite delimitar una zona de contacto, por lo que se puede ver si
algo entra en la zona de contacto, esta todavía dentro o deja de estar
en contacto con nuestro objeto.
La práctica de utilizar formas geométricas primitivas facilita el cálculo
de colisiones pero si se necesita una detección totalmente precisa se
puede utilizar los llamados Mesh Collider, que genera una versión2.3. Unity como entorno de desarrollo 20
Figura 2.22: Elementos con fisica en Unity, los arboles y las piedras tienen
masa y se puede chocar con ellos
simplificada de la malla para acercarse lo máximo posible a la detección
de colisiones.
Los colliders no permiten detectar por si solos las colisiones sino
que se puede hacer cuando se detecta un objeto solido gracias a un
Trigger. Cuando se le añade un collider a un gameObject, en el
editor se puede activar un parámetro para hacer que, cuando entre en
contacto con otro gameobject con el parámetro de trigger activado,
pueda detectar esa colisión mediante una función de C# para que se
pueda añadir el comportamiento deseado.
Joint: Estos componentes permiten crear estructuras complejas, como
muelles, cuerdas o bisagras entro otros.
2.3.3. Sonidos
El audio es uno de los elementos mas importantes de cara a conseguir
una buena ambientación dentro de un videojuego y ayuda a mejorar la ex-
periencia del jugador. Unity permite añadir música ambiental y efectos de
sonido que se reproducen ante eventos del juego
La gestión de los sonidos se hace a través de un audio source. Este
componente permite reproducir cualquier tipo de clip de sonido y puede
configurarse para que se produzca tanto en 2D o en 3D. También permite
configurar tanto la distancia como el volumen o difuminación del sonido.
El motor de audio posee mas componentes de sonido para funciones es-
pecíficas, pudiendo añadir al clip de audio efector de eco, reverberación,
distorsión y coros entre otras opciones. Cada componente tiene parámetros
específicos que difieren de los otros tipos de componentes (en el coro se puede
personalizar el volumen de cada sonido del coro mientras que en la distorsión
de puede ajustar el nivel de potencia de la misma)2.4. JoyconLib 21
Figura 2.23: Barco creado por el usuario ozgur para poder descargar de esta
biblioteca
2.3.4. Asset Store
Unity posee también una sección llamada Asset Store, que consiste en
una enorme biblioteca de contenido a disposición de los usuarios que esta en
continua expansión. Tanto Unity Technologies como los propios miembros
de la comunidad son los encargados de crear los elementos y publicarlos en
esta biblioteca (Figura 2.23). Se puede encontrar cualquier tipo de recurso
gracias a su buscador, permitiendo escoger animaciones, materiales, sonidos
o componentes enteros ya creados que combinen varios recursos (como el
Jugador de nuestro Runner, que combina animación y material).
El valor que tiene esta herramienta es incalculable y debido a la gran
cantidad de contenido que posee, cualquier desarrollador debe aprender a
utilizarla para sacarle partido (Blackman, 2014).
2.4. JoyconLib
Como se ha comentado previamente, la elección de utilizar los mandos de
Nintendo Switch se tomó porque cumplían la gran mayoría de características
esperadas de un sensor de movimiento6 . En particular los Joy-Con son fáciles
de conectar vía Bluetooth a un ordenador con Windows 10 como sistema
operativo. Sin embargo, Unity no permite comunicarse a través de Bluetooth
con otros dispositivos ya que no tiene una API para ello. En GitHub existe
una librería “nativa” (en C) que proporciona un API para poder comunicarse
por USB/Bluetooth en Windows, Linux y Mac. Se llama HIDAPI7 .
6
La elección de estos dispositivos se explicará en profundidad en el capítulo de plante-
amiento del proyecto.
7
https://github.com/signal11/hidapi2.5. Aprendizaje automático y redes neuronales 22
Para poder usar esa librería en Unity, hay que incorporarla como “plu-
gin nativo” y luego hacer un envoltorio en C# al API que proporciona. Los
desarrolladores de Looking-Glass permiten el uso libre de su librería desde
su GitHubfootnotehttps://github.com/Looking-Glass/JoyconLib/. Esta
recoge el “envoltorio”(HIDapi.cs) de Flafla2 usado en Unity-Wiimote, utili-
zándolo para que Unity se pueda comunicar con los Joy-Con. De esta forma,
generaron código en C# que traduce la información que transmiten los man-
dos de forma que los programadores la puedan utilizar fácilmente.
El código que distribuye JoyconLib consta de tres scripts principales:
HIDapi.cs: centrado en las funcionalidades propias de la interfaz pa-
ra conectar el motor Unity con los Joy-Con de Nintendo Switch por
Bluetooh.
Joycon.cs: un script diseñado para pedir el estado de los Joy-Con y
entender el formato en el que estos lo proporcionan. Aloja toda la in-
formación de cada Joy-Con individual, diferenciando incluso si es un
Joy-Con izquierdo o derecho. Define todos sus estados y la informa-
ción de los botones que pueden ser pulsados. Entre estos datos, los
más relevantes para el proyecto son los que recogen información del
giroscopio y el acelerómetro. Incluso incluye código para producir la
llamada vibración HD de la que es capaz cada Joy-Con, permitiendo
que se produzca en diferente intensidad o localización del mando.
JoyconManager.cs: este script es llamado manager debido a que es el
que controla el conjunto de Joy-Con que están conectados al ordenador.
Los almacena en una lista para poder ir accediendo a los datos de
cada uno según se requiera. Va llamando constantemente a cada uno
de los mandos para que se actualice su información, de forma que
quede reflejado todo input sobre los Joy-Con, ya sean movimientos o
el pulsado de botones.
2.5. Aprendizaje automático y redes neuronales
Desde hace tiempo se busca conseguir máquinas que simulen, o incluso
mejoren, la capacidad cognitiva de los humanos. Sin embargo, no dejan de
ser programas diseñados y escritos por el hombre. Las máquinas hacen todo
aquello que ha quedado reflejado en su código y si fallan es seguro que el
error haya sido producido por aquél que lo programó.
Las aplicaciones que hacen uso de inteligencia artificial no son realmen-
te “inteligentes”, sino que demuestran un comportamiento simulado cercano
al de los humanos en esas situaciones. La evolución llega entonces cuando
demuestran serlo realmente: aprenden y mejoran su comportamiento. Así2.5. Aprendizaje automático y redes neuronales 23
Figura 2.24: Esquema de como los datos y el ouput generan el programa(Lee,
2019)
pues, el aprendizaje automático o “machine learning” en inglés, es definido
como “una colección de técnicas y algoritmos usadas para diseñar sistemas
que aprenden desde unos datos. Y dichos sistemas podrán con ello predecir
patrones a partir de los datos administrados”(Lee, 2019). No es otro que
el campo de la computación que desarrolla técnicas para que las máquinas
aprendan. Como vemos en la figura 2.24, los programadores dejan de generar
un programa al que se le pasan unos datos para obtener una salida determi-
nada, y empiezan a introducir los datos junto a las salidas esperadas para
que se forme el programa que prediga esas salidas. Con ello se ha conseguido
que se puedan desarrollar programas de índoles diversas, tales como moto-
res de búsqueda y reconocimiento mediante imágenes, palabras o sonidos. Y
esto está suponiendo una gran revolución en la investigación y la medicina
o incluso en sistemas de seguridad.
Hay muchísimas formas de hacer que una computadora aprenda, con ma-
yor o menor eficacia según para qué se apliquen, pudiendo necesitar ejemplos
previos, aprendizaje máquina supervisado; o trabajar sin ellos, aprendizaje
no supervisado. Luego se ha de determinar la tarea que se quiere que consi-
gan y, finalmente, medir la eficacia de realizar esa tarea, de manera que se
pueda dirigir a la máquina hacia resultados mejores.
Los algoritmos de aprendizaje automático se clasifican dentro de tres
categorías: aprendizaje supervisado, no supervisado y por refuerzo. Los su-
pervisados requieren entrenamiento en el que el sistema es alimentado con
casos de ejemplo, donde para cada conjunto de entrada se le indica la salida
que esperamos que dé. El sistema lo analiza, busca las “reglas” (en función de
qué algoritmo sea) y construye un modelo para ser capaz de, tras el entrena-
miento, dar las salidas esperadas a partir de las entradas correspondientes.
Según si la salida es un valor continuo o discreto, se llamará clasificación o
regresión.
Los no supervisados llevan a cabo procesos en los que solo se introducen
ejemplos no clasificados, por lo que el sistema desconoce la categoría de
las entradas. Así que dicho sistema deberá disponer de capacidades para2.5. Aprendizaje automático y redes neuronales 24
reconocer patrones y poder, por tanto, etiquetar por sí solo los ejemplos
entrantes.
El aprendizaje por refuerzo es aquel en el que el algoritmo en cuestión
aprende mediante interacciones con el mundo que le rodea. Recibe retroali-
mentación del exterior en base a sus acciones, lo que viene a ser un aprendi-
zaje que se basa en el éxito que vayan teniendo sus predicciones.
Para este proyecto se ha creído conveniente utilizar el primer tipo de
algoritmos, el supervisado, para que la salida esté etiquetada como uno de
los movimientos previamente introducidos. Para ello lo más acertado era
utilizar una red neuronal, decisión que explicaremos más detenidamente en
el capítulo de planificación.
Las redes neuronales artificiales, o “Artificial Neural Networks” (ANNs)
en inglés, se diseñaron siguiendo el formato de cómo funciona el cerebro
humano. Cada red neuronal cuenta con una sucesión de capas que van pro-
cesando las entradas que les llegan y la van transmitiendo a las siguientes
capas, hasta llegar a una solución. En este caso, cada unidad de procesa-
do es llamada neurona para seguir con la semejanza del cerebro humano.
“Cuando vemos una imagen asociamos una etiqueta o referencia mental a
ella. Entrenamos el cerebro y nuestros sentidos para reconocer una imagen
si la volvemos a ver al etiquetarla de la misma forma” (Verdhan, 2021).
En toda red neuronal hay tres tipos de capas:
Entrada: primera capa de una red neuronal. Se encarga de recibir los
distintos datos que se vayan a usar como ejemplo de entrenamiento o
de prueba.
Ocultas: conjunto de capas intermedias y el punto principal de la red
neuronal. En ellas se sucede todo el aprendizaje, recogen la información
de los datos introducidos en las entradas y los desglosan para poder
trabajar con ellos. Al final le pasan la información que han aprendido
a la capa de salidas.
Salida: capa final de la red neuronal. Reciben la información de las
capas ocultas y con ella deciden cómo clasificar cada entrada.
Cada neurona de la red neuronal recibe entradas con la información de
salida de las neuronas de la capa anterior. Tras procesar la información trans-
mite su salida a la capa de neuronas siguiente. Internamente lo que hace es
combinar la información recibida con su propia información y utilizar el con-
junto en una función de activación. Y es el resultado de esta función lo que
se transmitirá como salida.
Cada entrada constará de una suma de pesos a la que se le añade una
constante o “bias” que permite adecuar el resultado a lo esperado. Esto es2.5. Aprendizaje automático y redes neuronales 25
Figura 2.25: Esquema de una red neuronal típica (Verdhan, 2021)
Figura 2.26: Esquema del proceso interno de cada neurona (Verdhan, 2021)
llamado función de propagación y lo podemos ver de forma esquemática en
la figura 2.26
Con un entrenamiento supervisado se le dan los datos de entrada del
dataset a la red junto a la etiqueta que determina de qué tipo es ese dato.
Tras procesar la información da la salida, y se observa si se han producido
errores. Esto indican cómo de cerca o de lejos está el resultado de la salida
esperada. Según el resultado, hay que ajustar los pesos de las conexiones de
la red y para eso se utiliza el “backpropagation”.
Una vez se han minimizado los errores se vuelve a propagar la información
hacia las capas de salida y se decide definitivamente el resultado, ya que se
tiene una mayor precisión de acertar con un resulta más cercano al esperado.Capítulo 3
Planteamiento
3.1. Toma de decisiones
Los objetivos principales del proyecto eran crear una librería que per-
mitiese el uso de dispositivos que detecten el movimiento y desarrollar mi-
nijuegos que demostrasen su precisión. Para ello se necesitaba escoger el
dispositivo que mejor cumpliese con las necesidades del proyecto y un motor
en el que poder desarrollar los minijuegos. Se tenía que generar un mode-
lo de red neuronal con el que identificar distintos gestos e integrarlo en el
motor escogido. Y así poder realizar minijuegos sencillos que tuviesen como
mecánicas principales acciones que requiriesen movimientos.
Apuntar previamente que se decidió trabajar en ordenadores con el sis-
tema operativo de Windows1 ya que era el sistema operativo más utilizado
por los usuarios de ordenador2 . Y desde el principio se decidió utilizar el
motor Unity debido a su sencillez y capacidades. Permitía desarrollar mini-
juegos sencillos sin requerir demasiado tiempo de aprendizaje, permitiendo
centrarse en el desarrollo de la librería.
3.1.1. Sensor de movimiento
Para hablar del sensor de movimiento elegido y cómo se llegó a esa conclu-
sión, primero hay que nombrar lo que se esperaba que dicho sensor ofreciese:
Precisión: se buscaba un sensor que aportase información precisa so-
bre los movimientos que recoge. Era importante que los movimientos
del jugador se viesen bien reflejados en los juegos. Por ello se necesitaba
un sensor que consiguiese detectar movimientos lineales y rotaciones
1
Con la versión de Windows 10 más concretamente
2
https://news.microsoft.com/bythenumbers/en/windowsdevices
26También puede leer
