PDF de programación - Azimuth: diseño y desarrollo de un videojuego no euclídeo

Universidad Complutense de Madrid

Falcutad de Informática

Azimuth: diseño y desarrollo de un

videojuego no euclídeo

Trabajo de fin de grado
Doble Grado en Ingeniería Informática
y Matemáticas

Autor:
Jose Pablo Cabeza García

Director:
Dr. Marco Antonio Gómez Martín

Septiembre 2015

This work is licensed under the Creative Commons Attribution-
NonCommercial-ShareAlike 4.0 International License. To view a copy of this
license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/.

Azimuth: Diseño y desarrollo de un videojuego no euclídeo

Jose Pablo Cabeza García

Resumen

El desarrollo de un videojuego no euclídeo necesita de unos fundamentos mate-
máticos sólidos con los que diseñar e implementar la arquitectura de un motor de
juego. En esta memoria se describe la arquitectura e implementación de un motor
no euclídeo sobre Unity, sin entrar en detalles del modelo matemático subyacente.

Palabras clave: geometría diferencial, geometría no euclídea, desarrollo de video-
juegos, Unity, informática gráfica

Azimuth: Design and Development of a Non-Euclidean Videogame

Jose Pablo Cabeza García

Abstract

Developing a non-Euclidean videogame needs solid mathematical foundations
to build and design a game engine. This report describes the architecture and
implementation of a non-Euclidean game engine in Unity, without getting into
details of the mathematical model.

Keywords: differential geometry, non-Euclidean geometry, videogame develop-
ment, Unity, computer graphics

Índice general

1. Introducción

2. Nociones preliminares

2.1.1. Antichamber
2.1.2. Gateways
2.1.3. Portal

1

2.1. Videojuegos de referencia . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Conceptos fundamentales . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Línea de visión . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2. Fundamentos matemáticos . . . . . . . . . . . . . . . . . . .
2.3. Unity y sus herramientas . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1. Scenes, GameObjects y components . . . . . . . . . . . . . .
2.3.2. Cámara . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3. Recursos y assets . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4. MonoBehavior y API . . . . . . . . . . . . . . . . . . . . . .
2.3.5. Materiales y shaders

3
3
3
4
5
5
6
6
7
8
8
9
9
. . . . . . . . . . . . . . . . . . . . . . 10

3. Trabajo previo

11
. . . . . . . . . . . . . . . . . . . . . 11
3.1. Primeros diseños no euclídeos
3.2. Primera implementación . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Unity y Shaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4. Visión general de la arquitectura

15

i

ÍNDICE GENERAL

ii

4.1. Partes de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. AzimuthWorld . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. UnityWorld . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3. AzimuthManager . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.4. Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5. Modelo del mundo
5.1. Grafo de parches

19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.1. Parche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.2. Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.3. Objetos
5.2. Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3. Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.
Interacción física . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6. Controladores y módulos globales

25
6.1. AzimuthManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Carga de mapas . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Motor geométrico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3. Motor físico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.1. Shape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.2. Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7. Representación del mundo en Unity

29
7.1. UMeshModel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2. Árbol de visibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2.1. Cambio de parche . . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8. Implementación en Unity

33
8.1. Matrices y vectores . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.2. Organización de los archivos . . . . . . . . . . . . . . . . . . . . . . 34

ÍNDICE GENERAL

iii

8.3. Creación de escenas . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.3.1. Posición de la cámara . . . . . . . . . . . . . . . . . . . . . . 35

9. Conclusión y trabajo futuro

Bibliografía

37

39

ÍNDICE GENERAL

iv

Capítulo 1

Introducción

Existen muchos juegos que dicen no ser euclideos y romper las reglas del espacio,
pero al final siempre se basan en motores convencionales que se comportan y
mueven como lo esperaríamos. Estos juego estan basados en coser el espacio con
bucles y eventos que no existen en el mundo real, pero que en última instancia no
rompen las reglas del espacio.

Frente a esto, mis compañeros, Alejandro Aguirre Galindo, Paco Criado Gallart, y
yo nos embarcamos en el proyecto de crear un juego que fuese genuinamente no
eucídeo. Este proyecto comenzó hace casi dos años como un embrión de idea que
podría explotarse hasta llegar al día de hoy, en el que ya hay resultados visibles.

En un primer paso se desarrolló, sobre todo por parte de Paco Criado, un modelo
de cómo funciona la geometría no euclídea y de todas propiedades que tiene.
Esto cristalizó en unas primeras implementaciones que se fueron refinando hasta
conseguir crear una manera de modelar y proyectar el espacio eficiente y elegante.

Con este modelo matemático diseñamos una arquitectura que lo cumpliese y que
además fuese lo suficiente eficiente como para poderse usar en el desarrollo de un
videojuego. Esto nos llevó a enfrentarnos a distintos problemas que normalmente
no se darían en un juego normal y que tuvimos que solventar. Finalmente creamos
e implementamos una arquitectura con la que pudimos diseñar y jugar a algunos
puzles que verdaderamente son no euclídeos.

El desarrollo del motor ha sido realizado sobre todo por Alejandro Aguirre y yo,
encargándose mi compañero de la parte de representar en Unity el modelo que
diseñamos y yo más de deseñar la arquitectura y cómo implementar el modelo
matemático.

1

CAPÍTULO 1. INTRODUCCIÓN

2

Capítulo 2

Nociones preliminares

2.1. Videojuegos de referencia

Previamente a desarrollar y diseñar el motor, se hizo un estudio de los videojuegos
que explotaban el uso del espacio de una manera no estándar para saber lo que ya
se había realizado antes y cómo se había hecho.

El concepto de espacio no euclídeo no se suele usar en los videojuegos, y cuando
se usa es de manera poco rigurosa, pero hay algunos juegos que hacen uso de
estructuras que no son posibles con las reglas normales del espacio, de forma
que pueden considerarse en cierta manera de espacio no euclídeo, aunque el
comportamiento del movimiento y la física sea estándar.

2.1.1. Antichamber

Antichamber es un juego en primera persona creado en 2013 por un desarrollador
independiente sobre el motor Unreal Engine 3. Originalmente el juego en su publi-
cidad afirmaba ser un juego de espacio no euclídeo, haciendo uso de perspectivas
y objetos que normalmente serían imposibles en la vida real. Entre estos puzles
están algunos como pasillos infinitos o pasillos donde tienes que girar más de una
vuelta para volver a donde estabas.

Además de esta manera de definir el mundo que se salta las reglas usuales del
espacio, hace uso de mecánicas y eventos que dependen de la orientación con la que
el jugador mira y se mueve por las salas. El jugador también cuenta con diversas
pistolas que va desbloqueando con las que interactuá con ciertos cubos de colores
para seguir avanzando.

A pesar de que afirma no ser euclídeo, todos los movimientos y física son euclídeos
localmente, es decir, dentro de una sala te mueves de la manera usual, pero es
al unir distintas salas lo que da lugar a estructuras que normalmente no serían
posibles.

3

CAPÍTULO 2. NOCIONES PRELIMINARES

4

Figura 2.1: Captura de antichamber donde se pueden ver estructuras que parecen
imposibles 1

2.1.2. Gateways

Gateways es un juego 2D de plataformas al estilo tradicional, donde las mecánicas
básicas son saltar en enemigos, plataformas y pinchos. Además de esto incluye una
forma de poner portales que tienen distintas propiedad al atravesarlos, por ejemplo,
al poner portales de distinto tamaño el jugador también modifica su tamaño, o
portales que juegan con el tiempo y permiten interactuar con versiones anteriores
del jugador y las acciones que ha realizado.

Lo más importante es que estos portales, y en general todo el juego, hacen uso del
concepto de línea de visión, modificando lo que el jugador ve según donde está y
lo que tiene dentro de su campo de visión.

Figura 2.2: Captura de Gateways donde se ve claramente el concepto de líneas de
visión 2

1Imagen obtenida de: https://en.wikipedia.org/wiki/Antichamber#/media/File:Antichamber_screenshot.jpg
2Imagen obtenida de: http://www.smudgedcat.com/gateways.htm

CAPÍTULO 2. NOCIONES PRELIMINARES

5

2.1.3. Portal

Portal es un juego de puzles en primera persona creado en 2007 por Valve Corpora-
tion, sobre su propio motor Source. El juego fue muy bien recibido, considerándolo
uno de los más originales de 2007, aunque fue criticado por ser demasiado corto.
En 2011 se lanzó una se