Desarrollo De Un Prototipo De Videojuego
UNIVERSIDAD DE EXTREMADURA
Escuela Politécnica
Máster en Ingeniería Informática
Trabajo de Fin de Máster Desarrollo de un Prototipo de Videojuego
Ricardo Franco Martín
Noviembre, 2016
UNIVERSIDAD DE EXTREMADURA Escuela Politécnica Máster en Ingeniería Informática
Trabajo de Fin de Máster Desarrollo de un Prototipo de Videojuego
Autor: Ricardo Franco Martín Fdo: Directores: Pablo García Rodriguez y Rober Morales Chaparro Fdo:
Tribunal Cali cador Presidente: Fdo: Secretario: Fdo: Vocal: Fdo:
Dedicado a mi familia
i ii Agradecimientos
Quisiera agradecer a varias personas el apoyo y ayuda que me han prestado en la realización de este Trabajo de Fin de Máster.
En primer lugar, agradecer a mi director Pablo García Rodríguez por per- mitirme realizar este proyecto y recibirme con los brazos abiertos cada vez que he necesitado su ayuda.
También quiero agradecer a mi codirector Rober Morales Chaparro por con ar en mí y proporcionarme una de las fases profesional y educativa más importantes de mi vida.
Por último, agradecer a mi familia y amigos, que sin su apoyo, no habría llegado tan lejos. En especial, darle las gracias a mi hermano José Carlos Franco Martín que ha realizado y proporcionado algunos recursos artísticos para el proyecto.
½Muchas gracias a todos!
iii iv Resumen
Este Trabajo de Fin de Máster (en adelante TFM) trata sobre todo el proceso de investigación, con guración de un entorno de trabajo y desarrollo de un prototipo de videojuego.
Analizaremos la tecnología actual y repasaremos algunas de las herramien- tas más relevantes utilizadas en el proceso de desarrollo de un videojuego.
Seguidamente, trataremos de desarrollar un videojuego. Para ello, a partir de una idea de juego, diseñaremos las mecánicas y construiremos un prototipo funcional que pueda ser jugado y que re eje las principales características planteadas en la idea inicial, con el objetivo de comprobar si el juego es viable, si es divertido y si interesa desarrollar el juego completo.
Por último, analizaremos y valoraremos los resultados obtenidos.
Palabras clave: investigación, aprendizaje, videojuego, prototipado, ar- quitectura software.
v vi Abstract
This Master's Thesis deals with the entire process of research, setting up of a working environment and development of a video game prototype.
We will analyze the current technology and review some of the most relevant tools used in the video game development process.
Next, we will try to develop a video game. For that, from a game concept idea, mechanics are designed and a functional prototype is built to get an initial playable version of the sofware product that represent the main characteristics of the prime game concept. The goal is to check if the game is viable, fun and if the full game is interesting to be developed.
Finally, we will analyze and evaluate the obtained results.
Keywords: research, learning, videogame, prototyped, software architec- ture.
vii viii Índice general
Agradecimientos iii
Resumen v
Abstract vii
Índice de Tablas xiii
Índice de Figuras xv
1. Introducción1
2. Introduction3
3. Motivación5 3.1. Sociedad del Entretenimiento...... 5 3.2. Los Videojuegos...... 6 3.3. Propuesta...... 6
4. Motivation9 4.1. Society of Entertainment...... 9 4.2. Video Games...... 10 4.3. Proposal...... 10
5. Estado del Arte 13 5.1. Plataformas de Juego...... 13
ix 5.1.1. PC...... 14 5.1.2. Videoconsolas...... 16 5.1.3. Dispositivos Móviles...... 18 5.1.4. Realidad Virtual...... 18 5.2. Herramientas de Desarrollo de Videojuegos...... 20 5.2.1. Unity...... 21 5.2.2. Unreal Engine...... 22 5.2.3. CryEngine...... 23 5.2.4. Otros Motores...... 24 5.2.5. Otras Herramientas...... 25 5.3. Videojuegos Similares...... 25 5.4. Consideraciones sobre el Proyecto...... 26
6. State of art 27 6.1. Gaming Platforms...... 27 6.1.1. PC...... 28 6.1.2. Video Game Consoles...... 30 6.1.3. Mobile Devices...... 31 6.1.4. Virtual Reality...... 31 6.2. Video Game Development Tools...... 32 6.2.1. Unity...... 32 6.2.2. Unreal Engine...... 33 6.2.3. CryEngine...... 34 6.2.4. Other Video Game Engines...... 34 6.2.5. Other Tools...... 35 6.3. Similar Video Games...... 35 6.4. Conclusion...... 36
7. Desarrollo del Videojuego 37 7.1. Concepto de Juego...... 37 7.1.1. Per l...... 37
x 7.1.2. Descripción...... 38 7.1.3. Ambientación...... 38 7.1.4. Mecánicas...... 38 7.1.5. Referencias...... 39 7.1.6. Riesgos...... 39 7.2. Ampliación del Concepto de Juego...... 40 7.2.1. Jugabilidad...... 40 7.2.2. Editor de Niveles...... 42 7.3. Entorno de Desarrollo...... 43 7.4. Prototipado...... 43 7.4.1. Primera Versión...... 44 7.4.2. Segunda Versión...... 44 7.5. Arquitectura e Implementación del Juego...... 55 7.5.1. Editor de Niveles...... 55 7.5.2. Juego/Jugabilidad...... 62 7.5.3. Interfaz de Usuario...... 65 7.5.4. Servidor...... 66
8. Resultados y Discusión 69
9. Conclusiones 79
10.Conclusion 81
11.Trabajos Futuros 83
12.Referencias 85
A. Unity y la Arquitectura Orientada a Componentes 89
B. Modelado del Personaje en Blender 95
xi xii Índice de cuadros
7.1. Per l del juego...... 37 7.2. Entorno de desarrollo...... 43 7.3. Peticiones POST del servicio REST...... 68 7.4. Peticiones GET del servicio REST...... 68
xiii xiv Índice de guras
5.1. PlayStation 4...... 17 5.2. Xbox One...... 17 5.3. Nintendo 3DS...... 17 5.4. Wii U...... 18 5.5. Oculus Rift...... 19 5.6. HTC Vive...... 19 5.7. PlayStation VR...... 19 5.8. Samsung Gear VR...... 20 5.9. Ejemplo del editor de Unity...... 22 5.10. Ejemplo del editor de Unreal Engine...... 23 5.11. Ejemplo del editor de CryEngine...... 24
7.1. Primera versión del prototipo...... 44 7.2. Inicio del nivel...... 45 7.3. Mecánica de agacharse...... 46 7.4. Mecánica de salto y plataformas móviles...... 46 7.5. Mecánica de saltar sobre las paredes...... 47 7.6. Mecánica de agarrar, arrastrar y empujar objetos...... 47 7.7. Mecánicas con cuerdas...... 48 7.8. Ejemplo de prueba con un vehículo...... 48 7.9. Primer ejemplo de puzle (1 de 2)...... 49 7.10. Primer ejemplo de puzle (2 de 2)...... 49 7.11. Prueba con plataformas móviles que pueden aplastar al avatar. 50
xv 7.12. Ejemplo de prueba con arma, palanca y láser...... 51 7.13. Segundo ejemplo de puzle (1 de 3)...... 52 7.14. Segundo ejemplo de puzle (2 de 3)...... 52 7.15. Segundo ejemplo de puzle (3 de 3)...... 53 7.16. Mecánicas con trampolines o camas elásticas...... 53 7.17. Ejemplo de prueba con vehículo aéreo y obstáculos (1 de 2)... 54 7.18. Ejemplo de prueba con vehículo aéreo y obstáculos (2 de 2)... 54 7.19. Representación de los modos de edición del editor de niveles.. 57 7.20. Representación de los componentes de edición que pueden tener los objetos editables...... 59 7.21. Representación aproximada de la máquina de estados imple- mentada para el avatar...... 63 7.22. Representación del modelo de datos utilizado en el servidor... 67
8.1. Captura del menú principal...... 71 8.2. Captura del menú de opciones grá cas...... 72 8.3. Captura del menú de opciones de sonido...... 72 8.4. Captura del menú de opciones de los controles del juego..... 73 8.5. Captura del menú de personalización del avatar...... 73 8.6. Captura del menú de gestión de niveles editables del jugador.. 74 8.7. Captura del editor con varios objetos editables...... 74 8.8. Captura de la paleta de objetos del editor de nivel...... 75 8.9. Captura del menú de publicación de un nivel...... 75 8.10. Captura del menú de búsqueda y selección de niveles...... 76 8.11. Captura del menú de n del nivel con una lista de puntuaciones máximas...... 76
A.1. Flujo de ejecución de la clase MonoBehaviour dentro del motor Unity...... 91 A.2. Ejemplo de atributos de un componente en la ventana Inspector de Unity...... 93
xvi B.1. Captura de Blender con las plantillas 2D del personaje..... 96 B.2. Captura de Blender el módelo 3D completado...... 97 B.3. Captura de Blender con los huesos del personaje...... 97
xvii xviii Capítulo 1
Introducción
El sector del videjuego se ha convertido en una de las industrias más pode- rosas en el ámbito del entretenimiento. Los videojuegos ofrecen experiencias a los jugadores que no son posibles en otros sectores como el cine o la música.
El desarrollo y producción de videojuegos es muy complicado, requiere de grandes conocimientos, disciplina y trabajo en equipo. Las empresas suelen pedir un catálogo de juegos terminados en las entrevistas de trabajo, de forma que es un sector con grandes barreras de entrada.
Sin embargo, actualmente existen muchas herramientas y facilidades para desarrollar videojuegos y publicarlos al mercado:
Entornos de desarrollo y motores de videojuego que incluyen la posibi- lidad de exportar el juego a múltiples plataformas, realizando la menor cantidad de modi caciones posibles sobre el código.
Herramientas para la publicación y monetización de videojuegos, algunas incluidas incluso en los propios motores de desarrollo.
Plataformas y servicios de publicación y venta de videojuegos (Steam, Google Play, App Store, etc).
1 En videoconsolas es más complicado desarrollar y publicar un videojuego, pues se requieren kits de desarrollo especiales. No obstante, últimamente se está apostando por los estudios independientes1 y algunas empresas como Sony proporcionan kits gratuitos.
La estructura del TFM será la siguiente:
En el capítulo3 (español) y4 (inglés) se describirá la importancia del videojuego en la sociedad y los objetivos de este TFM.
En el capítulo5 (español) y6 (inglés) repasaremos algunos de los aspectos más importantes del sector del videojuego, tanto desde el punto de vista del jugador o usuario como desde la perspectiva del desarrollador de videojuegos. De esta forma, repasaremos y analizaremos las plataformas de juego, herramientas de desarrollo más relevantes en la industria actual y para este TFM y algunos videojuegos similares al que se pretende desarrollar.
El capítulo7 tratará sobre la elección de los entornos y herramientas para desarrollar el videojuego y el proceso seguido para la construcción del mismo.
El capítulo8 se presentarán y discutirán los resultados obtenidos.
El capítulo9 (español) y 10 (inglés) se expondrán las conclusiones nales sobre el TFM.
En el capitulo 11 se propondrá una serie de posibles trabajos futuros.
En el capítulo 12 se indicarán las referencias a las fuentes de información utilizadas.
1No es un término muy bien de nido, pero suele refererise a estudios pequeños sin apoyo por parte de una distribuidora de videojuegos
2 Chapter 2
Introduction
The video game industry has become one of the most powerful industries in the entertainment sector. Videogames oer experiences to players that are not possible in other sectors such as cinema or music.
The video game development and production is very complicated, it requires great knowledge, discipline and teamwork. Companies often request a catalog of nished games in job interviews, so that, it is a sector with high barriers to entry.
However, nowadays, there are many tools and facilities to develop video games and publish them on the market:
Development environments and video game engines that include the pos- sibility of exporting the game to multiple platforms, making the least possible modi cations to the code.
Tools for publishing and monetizing video games, some of them included in the development engines themselves.
Platforms and services of publishing and sale of video games (Steam, Google Play, App Store, etc).
3 On videogame consoles it is more complicated to develop and publish a video game, as special development kits are required. However, lately, independent developers1 have recently become very important and some companies like Sony provide free kits.
The TFM structure will be as follows:
The chapters3 (spanish) and4 (english) describe the importance of video game in the society and the objectives of this TFM.
The chapters5 (spanish) and6 (english) review some of the most im- portant aspects of the video game sector, both from the point of view of the player and from the perspective of the videogame developer. In this way, we will review and analyze the most relevant gaming platforms and game development tools for the current industry and for this TFM. Furthermore, we will talk about some similar video games to the one that is intended to develop.
The chapter7 describes the choice of the environment and tools to de- velop a video game and the process followed for its construction.
The chapter8 presents and discusses the results.
The chapters9 (spanish) and 10 (english) present the nal conclusions about the TFM.
The chapter 11 proposes a possible future works.
The chapter 12 indicates the references to the sources of information used.
1It is not a very well de ned term, but usually refers to small studies without support from a videogames distributor
4 Capítulo 3
Motivación
En este capítulo se explicará la importancia de los videojuegos en la sociedad y se justi cará la elección de la temática de este TFM.
3.1. Sociedad del Entretenimiento
El entretenimiento juega un papel muy importante en el transcurso de la vida de los seres humanos. Las personas suelen dedicar su tiempo de ocio en realizar actividades que les divierten y alejan de las preocupaciones del día a día. De hecho, entre las muchas de niciones que se han hecho de la sociedad actual, una es Sociedad del Entretenimiento.
El entretenimiento se ha industrializado, de forma que existen numerosas empresas cuya principal actividad económica es la producción de cultura y entretenimiento con nes lucrativos. La televisión, la radio, la música, las re- vistas, el deporte, la lituratura y los videojuegos son algunos ejemplos.
5 3.2. Los Videojuegos
Un videojuego es un juego electrónico. El usuario interactúa con el jue- go mediante dispositivos de entrada o controladores (mando, teclado, ratón, cámara, etc) y éste ofrece una respuesta en dispositivos de salida (monitor, altavoces, etc). Existen otros puntos de vista o de niciones del término (me- dio de entretenimiento, producto o servicio software, forma de expresión, arte, medio educativo, etc).
El videojuego se ha convertido en uno de los sectores más importantes de la industria del entretenimiento. Se estima que en 2015, la industria del video- juego movió unos 90.000 millones de dólares, siendo, en términos generales, la industria del sector de entretenimiento más rentable de todo el mundo.
Las principales razones para desarrollar un videjuego como propuesta de este TFM son las siguientes:
A anzar los conocimientos adquiridos durante el transcurso del Grado y Máster.
Finalizar los estudios con una propuesta entretenida y desa ante.
Ampliar el per l profesional hacia la industria del videojuego como un posible futuro laboral.
Aprender sobre el Desarrollo de Videojuegos.
3.3. Propuesta
En este TFM se proponen los siguientes objetivos:
Investigar el proceso de creación de un videojuego, especialmente desde el per l de programación.
Desarrollar un prototipo de videojuego.
6 Construir una versión estable y funcional que re eje las características y mecánicas de la idea de juego planteada.
Documentar el proceso realizado para la construcción del videojuego.
7 8 Chapter 4
Motivation
This chapter discusses the importance of video games in society and justi es the choice of the topic of this TFM.
4.1. Society of Entertainment
Entertainment has a very important role in the human lifetime. People often expend their leisure time on activities that amuse and get them away from the worries of the day to day. In fact, among the many de nitions that have been made of today's society, one is the Society of Entertainment.
Entertainment has become industrialized, so there are a lot of companies whose main economic activity is the production of culture and entertainment with pro t. Some examples are Television, radio, music, magazines, sports, literature and video games.
9 4.2. Video Games
A video game is an electronic game. Users interacts with the game via input devices or controllers (command, keyboard, mouse, camera, etc.) and the game oers a response on output devices (monitor, speakers, etc.). However, there are other points of view of the term (entertainment medium, software product or service, form of expression, art, educational medium, etc).
Video game has become one of the most important sectors of the entertain- ment industry. It is estimated that in 2015 the video game industry moved about 90 billion dollars, being, in general, the most pro table entertainment industry in the world.
The main reasons for developing a video game as a proposal of this TFM are the following:
Strengthen the knowledge acquired during the course of the Master's Degree.
Finish the universitary studies with an entertaining and challenging pro- posal.
Expand profesional pro le towards the video game industry as a possible future job.
Learning about Video Game Development.
4.3. Proposal
This TFM proposes the following objectives:
Investigate the video game developing process, especially from the pro- gramming pro le.
Develop a video game prototype.
10 Build a stable and functional version that re ects the characteristics and mechanics of the game idea raised.
Document the whole process performed for the construction of the video game.
11 12 Capítulo 5
Estado del Arte
En este capítulo repasaremos brevemente la historia de los videojuegos y estudiaremos las principales plataformas de juego y herramientas de creación de videojuegos. Estudiaremos estos apartados para obtener una visión general del contexto, desarrollo y mercado actual del videojuego.
5.1. Plataformas de Juego
Aunque la tendencia de las compañías de desarrollo de videojuegos es pro- ducir juegos para la mayor cantidad de dispositivos posibles y llegar a más usuarios, no siempre ocurre así. De esta forma, podemos distinguir los siguien- tes tipos de videojuego:
Juegos exclusivos. Son títulos que salen al mercado para una plata- forma especí ca. La razón principal suele ser la de atraer usuarios a la plataforma (contratos de exclusividad), falta de recursos, decisiones de negocio o por ser inadecuados para las demás. Algunos ejemplos de jue- gos exclusivos son World of Warcraft (PC), Forza(Xbox), BloodBorne (Play Station) y Splatoon (Wii U).
13 Juegos multiplataforma. Videojuegos que se publican para más de una plataforma. Algunos ejemplos son Grand Theft Auto, Call of Duty o videojuegos deportivos como Fifa y Pro Evolution Soccer.
Por otra parte, según el formato de venta del juego podemos diferenciar:
Mercado físico. Es el formato tradicional de venta, los juegos se suelen comercializar en DVDs, cartuchos o tarjetas de memoria, dependiendo de la plataforma de juego. En este ámbito suelen cobrar principal impor- tancia las ediciones especiales o coleccionistas, donde además del propio juego, se presentan libros del arte, maquetas u otros objetos.
Mercado digital. Este formato se está imponiendo al mercado físico. Generalmente, los usuarios poseen una cuenta y los videojuegos o pro- ductos adquiridos quedan asociados a su biblioteca virtual.
Son muchos los dispositivos disponibles para jugar a videojuegos. Por este motivo, repasaremos las plataformas actuales y relevantes en la industria.
5.1.1. PC
Los computadores, aunque son de propósito general, constituyen la plata- forma líder del mundo de los videojuegos.
Ventajas:
Salvo excepciones, el usuario puede jugar a cualquier juego antiguo sin problemas de compatibilidad.
Los juegos suelen ser más baratos.
El teclado y el ratón suelen proporcionar un control más preciso.
Proporciona una gran exibilidad en los controladores de juego: teclado y ratón, joystick, gamepad, etc.
14 Pueden ofrecer juegos tecnológicamente mejores que en consolas. El PC tiene menor limitación de recursos.
Es más fácil y existen menos restricciones a la hora de desarrollar pro- ductos para PC que para las demás plataformas.
Desventajas:
Los usuarios deben preocuparse de los requisitos de los juegos y del man- tenimiento y mejora del computador para poder jugar a títulos actuales.
No ofrece la comodidad de las consolas de jugar en el sofá del salón.
Es bastante común que ocurran fallos en algunos computadores con de- terminados juegos, de forma que hay que consultar en foros de ayuda para solucionar los problemas.
En PC, existen varias plataformas o servicios para comprar juegos. Entre las formas de distribución más relevantes podemos enumerar las siguientes:
Steam. Creada por Valve, es la plataforma de distribución digital y red social líder del mercado. Cuenta con el servicio Steam Greenlight, donde los estudios independientes pueden publicar sus juegos y si cuentan con el apoyo su ciente por parte de los usuarios, el juego podrá ser publicado en la tienda principal.
Origin, Uplay. Son las plataformas de distribución digital de videojue- gos de Electronic Arts y Ubisoft, respectivamente.
Windows Store. Es la tienda o cial de Windows 8 y 10. No es muy popular, pero Microsoft ya ha empezado a publicar sus juegos AAA1, como Forza Horizon 3 y Gears of War 4.
GOG. Es el servicio de distribución digital de juegos de la empresa CD Project. Las diferencias con las plataformas anteriores son la distribu-
1Este término se utiliza para referirse a las superproducciones de videojuegos
15 ción de videojuegos sin gestión digital de derechos (DRM, Digital Rights Management) y la distribución de juegos antiguos, asegurando su com- patibilidad con las actuales versiones de Windows.
Humble Bundle. Este servicio cuenta con una tienda virtual, pero des- taca por la creación de paquetes de juegos donde el usuario paga la cantidad que considere oportuna, además, eligiendo el destinatario del dinero (desarrolladores, distribuidores y caridad).
G2A, Kinguin, Green Man Gaming, etc. Son tiendas de distribu- ción de claves de juegos. Los productos suelen ser más baratos que en los anteriores servicios y la clave sirve para activar y asociar el juego a la cuenta de usuario en las principales tiendas virtuales.
5.1.2. Videoconsolas
Las videoconsolas suelen ser consideradas las plataformas de juego por ex- celencia, donde el usuario solo tiene que de introducir el juego y jugar, sin preocuparse de otros aspectos.
Las videoconsolas han evolucionado hacia dispositivos multimedia, con la posibilidad de reproducir videos, música, navegar por internet, etc. Ahora los videojuegos requieren de instalación parcial o total en el disco duro y actuali- zaciones mediante parches, incluso en el primer día de lanzamiento del juego. De esta forma, las facilidades y comodidades que ofrecían las videoconsolas anteriores han sido rebajadas.
Las principales marcas de videoconsolas también cuentan con un servicio de venta y distribución online de juegos y ofrecen oportunidades y facilidades a desarrolladores y estudios independientes.
Actualmente, las videoconsolas que lideran el mercado son:
PlayStation 4 (PlayStation Network).
16 Figura 5.1: PlayStation 4
Xbox One (Xbox Live).
Figura 5.2: Xbox One
Nintendo 3DS (Nintendo eShop).
Figura 5.3: Nintendo 3DS
Wii U (Nintendo eShop).
17 Figura 5.4: Wii U
5.1.3. Dispositivos Móviles
La evolución de la tecnología en los teléfonos móviles y la aparición de servicios de distribución de aplicaciones han impulsado que las empresas del sector del videojuego y muchos desarrolladores independientes desarrollen jue- gos para dicha plataforma. Sin embargo, es un mercado complicado, donde es difícil destacar y donde la mayor parte de los bene cios lo consiguen juegos que ocupan los primeros puestos del ranking de descargas.
Las principales plataformas para móviles son:
iPhone / iPad (AppStore).
Android (PlayStore).
Windows Phone (Microsoft Store).
5.1.4. Realidad Virtual
Aunque la realidad virtual no es una tecnología nueva, es ahora cuando se está apostando fuerte por estos dispositivos. De esta forma, surge un nuevo mercado lleno de oportunidades.
Existen varios dispositivos de realidad virtual, los más importantes son:
18 Oculus Rift.
Figura 5.5: Oculus Rift
HTC Vive.
Figura 5.6: HTC Vive
PlayStation VR.
Figura 5.7: PlayStation VR
Samsung Gear VR.
19 Figura 5.8: Samsung Gear VR
5.2. Herramientas de Desarrollo de Videojuegos
Antiguamente, los videojuegos se desarrollaban desde cero, es decir, sin la utilización de software intermediario ni herramientas especializadas. Con el avance tecnológico, las posibilidades crecían y la complejidad aumentaba, de forma que se precisaban nuevos enfoques para optimizar el ciclo de desarrollo. Fueron los juegos de disparo en primera persona los primeros en fomentar el desarrollo y utilización de dichas herramientas, que denominamos motores de juego (game engines).
Los primeros motores se centraban principalmente en la tarea de rende- rización de grá cos, aunque fueron incorporando más características con el paso del tiempo. FreeScape fue uno de los primeros motores 3D utilizados pa- ra crear videojuegos. Posteriormente surgieron herramientas como id Tech 1, Build Engine, Quake Engine, Unreal Engine, Source Engine, etc.
Actualmente, los motores de juego suelen estar formado por un conjunto de herramientas y soluciones software (lenguaje de programación, librerías, edito- res, documentación, tutoriales, servicio de soporte, etc) para gestionar, dirigir y facilitar la mayoría de las fases del proceso de desarrollo de videojuegos.
20 5.2.1. Unity
Es el motor de videojuegos creado por Unity Technologies. Algunas de sus características son las siguientes:
Tiene versión o cial para Windows y Mac, aunque también se puede ejecutar en Linux.
Ofrece una licencia personal gratuita y una licencia profesional de pago. La licencia personal suele ser su ciente para cualquier proyecto.
No hay que pagar regalías por vender productos creados con Unity, hasta recaudar cien mil dólares por ejercicio scal.
Incluye una tienda con todo tipo de recursos, tanto gratuitos como de pago, creados por la comunidad.
Incluye una documentación muy completa.
Cuenta con una gran comunidad.
Permite desarrollar juegos y aplicaciones para distintas plataformas (dis- positivos móviles, computadores, videoconsolas, web y realidad virtual).
Ofrece un potente editor, altamente personalizable y extensible, que fa- cilita y acelera el ujo de trabajo.
Ofrece integración nativa con los entornos de programación MonoDevelop y Visual Studio.
Permite el desarrollo de código en UnityScript (basado en javascript), C# y Boo (inspirado en Python).
Presenta una Arquitectura Orientada a Componentes (AOC). Sin embar- go, no es la misma arquitectura que conocemos de Ingeniería del Software (anexoA).
21 Proporciona gestión de grá cos, animaciones, iluminación, shaders, au- dio, físicas 2D y 3D, importación de recursos, etc.
Constituye una herramienta para desarrollar prototipos con cierta faci- lidad y rapidez.
Figura 5.9: Ejemplo del editor de Unity
5.2.2. Unreal Engine
Creado por Epic Games, es el motor de videojuegos más popular, especial- mente para juegos AAA. Su último producto es Unreal Engine 4, que con una visión distinta de negocio a sus anteriores versiones, ofrece un potente y com- pleto conjunto de herramientas para el desarrollo de videojuegos. Algunas de sus características son:
Motor de código abierto. Se puede acceder al código en Github y formar parte del desarrollo.
Permite su uso de forma gratuita, pero cuenta con una regalía del 5 % de los bene cios a partir de los primeros 3000 $ conseguidos con el producto.
Disponible de forma o cial para Windows, Mac y Linux.
Utiliza C++ como lenguaje de programación.
22 Utiliza BluePrint como lenguaje de programación visual.
Incluye una buena documentación.
Cuenta con uno de los motores grá cos más potentes del mercado.
Incluye una tienda de recursos para los proyectos.
Figura 5.10: Ejemplo del editor de Unreal Engine
5.2.3. CryEngine
Creado por Crytek, es uno de los motores de videojuegos actuales más potentes. Actualmente se encuentra en la versión 3 y está especializado en la gestión de enormes entornos, donde la gestión de carga y descarga de elementos del juego es muy importante. Además, está libre de regalías y de derechos de licencia.
23 Figura 5.11: Ejemplo del editor de CryEngine
5.2.4. Otros Motores
Existe una extensa lista de motores de videjuegos 3D y 2D. Entre los más importantes podemos enumerar los siguientes:
Source2.
Amazon Lumberyard.
Ogre3d.
Torque3D.
Cocos2d.
Construct 2.
Game Maker.
Libgdx.
24 5.2.5. Otras Herramientas
Aparte de los motores de juego, existen otro tipo de herramientas impor- tantes para la creación de videojuegos que no suelen estar integradas junto con el motor. Entre ellas, podemos enumerar las siguientes:
Herramientas grá cas. Adobe Photoshop, GIMP, Krita, Graphics Ga- le, Adobe Illustrator, InkScape, etc.
Modelado 3d. Adobe 3ds Max, Adobe Maya, Blender, ZBrush, OpenS- CAD, etc.
Audio. Adobe Audition, Audacity, Sound Forge, SunVox, OpenMTP, etc.
Control de versiones. Git, Subversion, etc.
Otras. Graphviz, XMind, Microsoft O ce, OpenO ce, etc.
5.3. Videojuegos Similares
Hay muchos videojuegos que incluyen un editor de niveles, pero suele ser una herramienta extra. Sin embargo, si hay ciertos productos que basan su losofía en la creación de niveles por partes de los usuarios. Algunos son:
Little Big Planet (2008). Este juego es la principal referencia que se ha tomado para la realización del TFM. Ha sido creado por Media Molecule para las principales plataformas de Sony.
Se puede decir que es un juego de plataformas, basado en físicas, en dos dimensiones, pero tiene varios niveles discretos de profundidad, por lo que en realidad hay tres dimensiones. Es decir, el jugador controla un muñeco de trapo (Sackboy) con las típicas mecánicas de un plataformas 2D, pero puede situarse en uno de los tres niveles de profundidad del
25 nivel.
Presenta un potente editor de niveles donde los usuarios han conseguido incluso representar versiones simpli cadas de otros juegos de distinto género.
Happy Wheels (2010). Es un juego de navegador web desarrollado por Fancy Force.
Presenta mecánicas de plataformas en dos dimensiones, donde los perso- najes están basados en física de ragdolls2, de forma que el atractivo del juego es la di cultad de controlar a los personajes para avanzar por el nivel.
Super Mario Maker (2015). Desarrollado por Nintendo, es una en- trega de la serie Mario Bros que cuenta con un potente editor donde los usuarios son los creadores de los niveles.
5.4. Consideraciones sobre el Proyecto
Hemos repasado los dispositivos de juego actuales más relevantes para en- focarnos en uno o varios de esos dispositivos y hemos enumerado y estudiado una serie de herramientas que existen para la creación de videojuegos.
Por otra parte, se han enumerado y descrito algunos juegos con mecánicas similares para tener una referencia y comenzar con el desarrollo del videojuego.
De esta forma, partimos de una buena base para desarrollar el proyecto planteado.
2Es un típo de física utilizado principalmente para simular animaciones de muerte de personajes
26 Chapter 6
State of art
In this chapter, we will brie y review the history of video games and study the main gaming platforms and tools to create video games. We will study these topics to get an overview of the context, development and current market of the video game.
6.1. Gaming Platforms
Although producing games for as many devices as possible and getting more users is the trend of video game development companies, it is not always the case. In this way, we can distinguish the following types of video game:
Exclusive games. Products are released for a speci c platform. The main reason is usually to attract users to the platform (exclusivity con- tracts), lack of resources, business decisions or to be inadequate for ot- hers. Some examples of exclusive games are World of Warcraft (PC), Forza (Xbox), BloodBorne (Play Station) and Splatoon (Wii U).
Multiplatform games. Video games are published for more than one platform. Some examples are Grand Theft Auto, Call of Duty or sports
27 video games like Fifa and Pro Evolution Soccer.
On the other hand, there are several types of videogames depending on the sale format:
Physical video games. It is the traditional sale format. Games are usually sold on DVDs, cartridges or memory cards, depending on the gaming platform. Special or collectors edittions usually have special importance in this area; where in addition to the game itself, art books, models or other objects are included in the edition.
Digital video games. This format is getting over the physical market. Generally, the users own an account and the videogames or products acquired are associated with their virtual libraries.
There are a lot of hardware devices to play videogames. For this reason, we will review current and relevant gaming platforms in the industry.
6.1.1. PC
Computers are general purpose machines but they are the leading platform in the world of video games.
Advantages:
With few exceptions, the user can play any old game without any com- patibility problems.
Video games are usually cheaper.
The keyboard and mouse usually provide more precise control.
It provides a great versatility in the game controllers: keyboard and mou- se, joystick, gamepad, etc.
They can technologically oer better games than on consoles. The PC
28 has less resource limitation.
It is easier and there are fewer restrictions when developing computer products than for other platforms.
Disadvantages:
Users should be concerned about system requirements of games and about maintenance and upgrading of the computer in order to play cu- rrent high tech video games.
It can not oer the comfort of consoles to play on the living room sofa.
Sometimes failures occur with some games running on certain computers, so you have to consult in help forums to solve the problems.
On PC, there are several platforms or services to buy games. We can enumeate the following platforms among the most relevant of market:
Steam. Created by Valve, it is the market's leading digital distribution and social network platform. It has the Steam Greenlight service, where independent developers can publish their games and if the game has enough support from the users, it can be published in the main store.
Origin, Uplay. They are the digital video game distribution platforms of Electronic Arts and Ubisoft, respectively.
Windows Store. It is the o cial store of Windows 8 and Windows 10. It is not very popular, but Microsoft has already started to publish its AAA games, such as Forza Horizon 3 and Gears of War 4.
GOG. It is the digital game distribution service of CD Project. The dierences with previous services are the distribution of video games without Digital Rights Management (DRM) and the distribution of old games, ensuring compatibility with current versions of Windows.
Humble Bundle. This service has a virtual store, but stands out for
29 the creation of game packages. The users can pay the amount he consi- der appropriate, in addition, they can choose the receiver of the money (developers, distributors and charity).
G2A, Kinguin, Green Man Gaming, etc. They are distribution sto- res of game keys. The products are usually cheaper than in the previous services and the key is used to activate and associate the game with the user account in a major virtual stores, usually Steam, Origin, Uplay and GOG.
6.1.2. Video Game Consoles
Consoles are usually considered the gaming platform par excellence, the user only has to introduce the game disk and play, without worrying about other aspects.
However, consoles have evolved into multimedia devices, with the possibility of playing videos, music, sur ng the World Wide Web, etc. Now video games require partial or complete installation on the hard drive and patch upgrades, even on the rst day of game launch. In this way, the facilities and comforts oered by previous consoles have been lowered.
The main video game consoles also have an online game sale service and oer opportunities and facilities to independent developers and studios.
Nowadays, the leading consoles of the market are:
PlayStation 4 (PlayStation Network).
Xbox One (Xbox Live).
Nintendo 3DS (Nintendo eShop).
Wii U (Nintendo eShop).
30 6.1.3. Mobile Devices
The evolution of technology in mobile phones and the emergence of applica- tion distribution services have led companies in the video game industry and many independent developers to develop games for mobile. However, it is a complicated market, where it is di cult to stand out and most of the pro ts are obtained by games placed in the top of the download ranking.
The main mobile platforms are:
iPhone / iPad (AppStore).
Android (PlayStore).
Windows Phone (Microsoft Store).
6.1.4. Virtual Reality
Although virtual reality is not a new technology, it is now when many com- panies are doing many tests with these devices. In this way, a new unexplored market emerges with great opportunities to stand out.
There are several virtual reality devices, the most important are:
Oculus Rift.
HTC Vive.
PlayStation VR.
Samsung Gear VR.
31 6.2. Video Game Development Tools
In the past, video games were developed from scratch, without the use of intermediary software or specialized tools. With the technological advance, the possibilities grew and the complexity increased, so new approaches were needed to optimize the development cycle. First Person Shooter games (FPS) were the rst to encourage the development and use of these tools, which we usually call game engines.
The rst engines mainly focused on the task of rendering graphics, although they were incorporating more features with the passage of time. FreeScape was one of the rst 3D engines used to create video games. Later, tools like id Tech 1, Build Engine, Quake Engine, Unreal Engine or Source Engine appeared.
Currently, game engines are usually made up of a set of tools and software solutions (programming language, libraries, editors, documentation, tutorials, support service, etc.) to manage, lead and facilitate most phases of the video games development.
6.2.1. Unity
It is the video game engine created by Unity Technologies. Some of its characteristics are the following:
It has o cial versions for Windows and Mac, although it can also run on Linux.
It oers a free personal license and a professional payment license. Per- sonal license is usually enough for any project.
There are not royalties to pay for selling products created with Unity, until you raise one hundred thousand dollars per scal year.
32 It has a store with all kinds of resources, free and paid, created by the community.
It has a very complete documentation.
It has a large comunity.
It allows to develop games and applications for dierent platforms (mobi- le devices, computers, video consoles, web browsers and virtual reality).
It oers a powerful, highly customizable and extensible editor that faci- litates and accelerates the work ow.
It provides native integration with the MonoDevelop and Visual Studio programming environments.
It allows the development of code in UnityScript (javascript-based), C # and Boo (inspired by Python).
It presents a Component Oriented Architecture. However, it is not the same architecture we know about Software Engineering (annexA).
It provides management of graphics, animations, lighting, shaders, audio, 2D and 3D physics, importing resources, etc.
It is a useful tool to develop prototypes with certain ease and speed.
6.2.2. Unreal Engine
Created by Epic Games, it is the most popular video game engine, especially for AAA games. Its latest product is Unreal Engine 4, which with a dierent business vision to its previous versions, it oers a powerful and complete set of tools for the development of video games. Some of its characteristics are:
Open source engine. You can access the code in Github and be part of the development.
33 It allows its use for free, but it has a royalty of 5 % of pro ts from the rst 3000 $ obtained with the product.
O cially available for Windows, Mac and Linux.
It uses C++ as programming language.
It uses BluePrint as visual programming language.
It has a good documentation.
It is one of the most powerful graphics engines on the market.
It has a resource store for projects.
6.2.3. CryEngine
Created by Crytek, it is one of the most powerful current video game en- gines. It is currently in version 3 and specializes in huge environments mana- gement, where loading and unloading of game elements is very important. In addition, it is free of royalties and license fees.
6.2.4. Other Video Game Engines
There is an extensive list of 3D and 2D video game engines. Among the most important, we can list the following:
Source2.
Amazon Lumberyard.
Ogre3d.
Torque3D.
Cocos2d.
Construct 2.
34 Game Maker.
Libgdx.
6.2.5. Other Tools
There are other important tools for creating video games that are not usually integrated with the game engine. Among them, we can list the fo- llowing:
Graphic tools. Adobe Photoshop, GIMP, Krita, Graphics Gale, Adobe Illustrator, InkScape, etc.
3D modelling. Adobe 3ds Max, Adobe Maya, Blender, ZBrush, OpenS- CAD, etc.
Audio. Adobe Audition, Audacity, Sound Forge, SunVox, OpenMTP, etc.
Version control. Git, Subversion, etc.
Other. Graphviz, XMind, Microsoft O ce, OpenO ce, etc.
6.3. Similar Video Games
There are many video games that include a level editor, but it is usually an extra tool. However, there are certain products in which the main base is the level creation by the users. There are some examples:
Little Big Planet (2008). This is the main reference used for the development of the game of this TFM.
It has been created by Media Molecule for the major platforms of Sony.
35 It is a platform game, physics-based, in two dimensions, but has several discrete depth levels, so there are actually three dimensions. That is, the player controls a rag doll (Sackboy) with the typical mechanics of a 2D platform, but can be placed in one of the three depth levels.
It has a powerful level editor where users have even got to represent simpli ed versions of other games of dierent genres.
Happy Wheels (2010). It is a web browser game developed by Fancy Force.
It is a 2D platform game, where the characters are based on rag dolls physics1, so the attraction of the game is the di culty of controlling the characters to advance through the level.
Super Mario Maker (2015). Developed by Nintendo, is a delivery of the Mario Bros series that has a powerful editor where the users are the levels creators.
6.4. Conclusion
We have reviewed the most relevant current game devices to focus on one or more of these devices and we have listed and studied some tools exist for the creation of video games.
On the other hand, we have described some games with similar mechanics to have a reference and begin with the video game development process.
In this way, we start from a solid base to develop the proposed project.
1It is a kind of physics mainly used to simulate animations of character deaths
36 Capítulo 7
Desarrollo del Videojuego
En este capítulo analizaremos todo el proceso seguido para desarrollar el videojuego, desde el desarrollo de la idea hasta conseguir el producto nal.
7.1. Concepto de Juego
El Concepto de Juego es un documento que sirve para explicar, de forma muy resumida, en qué consiste el juego.
7.1.1. Per l
Título Toy Box Género Plataformas, Puzles, Creatividad Plataformas PC, PlayStation4, Xbox One Modos de juego Un jugador Audiencia +7
Cuadro 7.1: Per l del juego
37 7.1.2. Descripción
Toy Box es un juego de plataformas en dos dimensiones. El jugador puede crear niveles con las herramientas y mecánicas del juego, compartirlos con la comunidad y jugar a los niveles publicados por otros usuarios.
7.1.3. Ambientación
El juego será completamente en dos dimensiones, excepto el avatar1, que estará modelado en 3d (anexoB). Se utilizará una estética cel shading para el personaje, es decir, se dibujará el contorno del personaje para darle un toque de dibujo animado.
7.1.4. Mecánicas
El avatar es un robot. Su misión es superar todas las pruebas que se le planteen.
El avatar puede:
• Avanzar (caminando, corriendo o agachado) de izquierda a derecha y viceversa hasta los límites del nivel.
• Caminar, correr, agacharse y saltar.
• Deslizarse por el suelo si previamente está corriendo.
• Saltar impulsándose sobre una pared.
• Agarrar un objeto, empujarlo y arrastrarlo.
• Agarrar una cuerda, subir, bajar y balancearse para saltar.
1El avatar es la representación del jugador en el juego
38 El jugador puede crear niveles en un editor utilizando los bloques, dis- positivos y mecánicas del juego.
El juego consta de un conjunto de bloques con varias formas que cons- truyen el escenario o nivel de juego, la disposición de los mismos in uyen en la di cultad.
El juego incluye una variedad de sensores, controladores y actuadores que añaden dinamismo al nivel.
Ejemplo 1. Un botón, al pulsarlo, mueve un obstáculo, permitiendo al avatar seguir avanzando.
Ejemplo 2. Un dispositivo, que emite una señal cada cierto tiempo, activa un dispositivo que dispara una proyectil que al impactar con el avatar le hace daño.
7.1.5. Referencias
Little Big Planet (PlayStation 3, PSP, PSP Vita).
Super Mario Maker (Wii U, Nintendo 3DS).
Happy Wheels (Web, Android, iOS)
7.1.6. Riesgos
Es un juego muy complejo. Es posible que surjan muchas di cultades durante el desarrollo y no dé tiempo a terminarlo.
Hay muchas mecánicas. Puede ser complicado conseguir un buen funcio- namiento que construyan una buena experiencia de juego.
La experiencia de usuario del editor debe ser muy buena para que el jugador no se frustre en la creación de niveles.
39 Se necesita un servidor para gestionar los niveles.
7.2. Ampliación del Concepto de Juego
En esta sección se desarrollará con más detalle el concepto de juego, con el objetivo de tener una idea aproximada de los elementos necesarios y del tamaño del mismo.
Se pueden distinguir claramente dos partes:
Juego/Jugabilidad. Entorno donde juegan los jugadores y conjunto de mecánicas del juego.
Editor de niveles. Entorno en el cual los jugadores crean los niveles.
7.2.1. Jugabilidad
El juego está compuesto por una serie de mecánicas que podemos clasi car en:
Mécanicas del avatar. Son las capacidades y habilidades del avatar del jugador:
• Movimiento lateral. El avatar puede avanzar hacia la izquierda y hacia la derecha, siempre y cuando no haya un obstáculo que se lo impida o llegue a los límites del nivel. Hay tres valores de velocidad, dependiendo de si anda, camina agachado o corre.
• Saltar. El avatar puede saltar si está pisando un objeto sólido, si está en el aire pero apoyado sobre una pared o si está agarrando una cuerda.
• Agachar. El avatar puede agacharse. No podrá levantarse si tiene un bloque sobre él.
40 • Deslizar. Si el avatar está corriendo, puede realizar un deslizamien- to por el suelo, de forma que puede esquivar ciertos obstáculos sin tener que pararse.
• Agarrar. El avatar puede agarrar objetos móviles para empujarlos o tirar de ellos. También puede utilizar cuerdas y otros objetos para interactuar con ellos.
• Escalar. Si el avatar está agarrado a una cuerda, puede subir y bajar la cuerda hasta sus extremos, si no hay obstáculos que se lo impidan.
• Balancear. Si el avatar está agarrado a una cuerda, puede balan- cearse hacia la derecha o hacia la izquierda.
Mecánicas físicas. Son las características físicas de un nivel. Es decir, todos aquellos elementos visibles por el jugador y que el avatar puede interactuar con ellos físicamente.
• Bloques/Figuras. Son guras básicas (rectángulo, triángulo, círcu- lo, etc) que constituyen el terreno o forman parte de dispositivos (coches, naves, puertas, trampas, etc).
• Botones. Son dispositivos que pueden ser utilizados por el avatar para activar otros mecanismos.
• Proyectiles. Objetos del juego que dañan al avatar.
• Portales. Dispositivos que puede utilizar el jugador para teletrans- portarse de un lugar a otro.
• Puntos de control. Elementos del nivel que cambian el punto de aparición del avatar en caso de muerte.
• Tuercas y tornillos. Son objetos de puntuación.
• Meta. Objeto que indica el nal del nivel.
41 Mecánicas lógicas. Compuesto por todos los elementos lógicos del ni- vel:
• Sensores (botones, palancas y sensores de area). Son elemen- tos que pueden activar otros dispositivos cuando el avatar u otros objetos del nivel interactuan con ellos.
• Controladores (temporizadores, bucles, contadores, retar- dadores de señal, etc). Son elementos que pueden procesar una señal de entrada y/o activar otros dispositivos.
• Actuadores (armas, trayectorias, instanciadores de objetos, textos, etc). Son elementos que realizan acciones, normalmente cuando son activados.
7.2.2. Editor de Niveles
Una de las partes fundamentales del juego es el editor de niveles. Ya que son los usuarios los creadores, hay que proporcionarles una buena herramienta que permita realizar niveles complejos de forma sencilla.
Hay que tener en cuenta que la creación de un nivel está asociado y limitado a las mecánicas del juego. Es decir, un usuario no puede realizar cualquier cosa que se le ocurra, ya que no es una herramienta para crear juegos, sino un entorno que permite crear niveles relacionados con las mecánicas del juego.
En resumen, el editor de niveles permitirá la creación y personalización de los elementos descritos en la sección 7.2.1, dando como resultado un nivel que podrá ser publicado y jugado por cualquier usuario.
42 7.3. Entorno de Desarrollo
El entorno de trabajo que se ha establecido para el TFM está formado por las herramientas de la tabla 7.2.
Sistema Operativo Windows 10 (Juego), Ubuntu 16.04 (Servidor) Motor de juego Unity 5 Servidor Sinatra, Heroku Base de datos PostgreSQL Lenguaje de programación C# (Juego), Ruby (Servidor) IDE/Editor de código Sublime Text 3 Modelado 3d Blender, www.mixamo.com (animaciones) Edición 2d GIMP, Krita Edición de audio Audacity Control de versiones Git, git- ow, Bitbucket Documentación/Memoria MiKTeX, TeXstudio, Dia (diagramas)
Cuadro 7.2: Entorno de desarrollo
7.4. Prototipado
El primer paso a la hora de comenzar con la implementación del video- juego es realizar un prototipo. Construimos una versión en poco tiempo sin preocuparnos en obtener un buen código, sólo que los principales elementos funcionen.
En este sentido, se realizará un prototipo de los elementos jugables. Pro- totipar el editor de niveles en la misma escala que los elementos jugables es una tarea más complicada, presenta demasiados elementos y una complejidad elevada, de forma que se ha decidido aplazar para fases posteriores y diseñar previamente una arquitectura software en lugar de realizar una versión rápida del mismo.
43 7.4.1. Primera Versión
La primera vesión del prototipo es muy básica, consiste en la construcción de algunas mecánicas del juego con guras básicas como cubos y esferas. Se desarrolla un entorno donde el jugador controla un cubo para moverse por un nivel con diferentes elementos. En la gura 7.1 se puede observar un ejemplo de la primera versión del prototipo.
Figura 7.1: Primera versión del prototipo
En esta versión se implementaron las siguientes mecánicas:
Movimiento del avatar (rectángulo rojo) y salto.
Empuje de objetos ( guras de color naranja).
Plataformas móviles (rectángulo blanco).
Salto sobre pared.
7.4.2. Segunda Versión
En la segunda versión del prototipo construimos un posible nivel completo donde se representa el uso de las mecánicas del juego para presentar retos y puzles que el jugador debe superar controlando al avatar. Esta versión debe
44 presentar elementos jugables que el usuario debería poder crear y personalizar en el futuro editor de niveles.
En la gura 7.2 se muestra el inicio del nivel, donde se muestra el primer punto de control (si el avatar muere aparece en el último punto de control), el personaje y unos mensajes en pantalla explicando las mecánicas del nivel.
Figura 7.2: Inicio del nivel
En la gura 7.3 se muestra un obstáculo que el avatar debe superar cami- nando agachado.
45 Figura 7.3: Mecánica de agacharse
En la gura 7.4 el avatar tiene que saltar a la plataforma que se está mo- viendo de izquierda a derecha para llegar al otro lado.
Figura 7.4: Mecánica de salto y plataformas móviles
En la gura 7.5 el avatar debe ir saltando de pared en pared para ascender a la parte superior.
46 Figura 7.5: Mecánica de saltar sobre las paredes
En la gura 7.6 se muestra la mecánica de agarrar, arrastrar y empujar objetos. En este caso, el avatar tiene que arrastrar el objeto hacia la parte izquierda para poder pasar.
Figura 7.6: Mecánica de agarrar, arrastrar y empujar objetos
En la gura 7.7 el avatar tiene que saltar, agarrarse a las cuerdas y balan-
47 cearse para llegar al otro lado.
Figura 7.7: Mecánicas con cuerdas
En la gura 7.8 el avatar tiene que subirse al vehículo. Al pulsar los botones el vehículo se mueve a la izquierda o a la derecha, dependiendo del botón. El avatar debe avanzar sin chocar con los bloques que se están moviendo arriba y abajo.
Figura 7.8: Ejemplo de prueba con un vehículo
48 En la gura 7.9 se muestra un pequeño puzle. El botón izquierdo mueve el bloque gris de la derecha que bloquea el paso y el botón que está debajo de la caja activa el láser. El avatar tiene que arrastrar la caja de un botón a otro para subir la plataforma y desactivar el láser ( gura 7.10).
Figura 7.9: Primer ejemplo de puzle (1 de 2)
Figura 7.10: Primer ejemplo de puzle (2 de 2)
49 La imágen 7.11 muestra una serie de plataformas que se están moviendo de arriba hacia abajo y viceversa. El avatar tiene que coordinar los tiempos y avanzar evitándo ser aplastado.
Figura 7.11: Prueba con plataformas móviles que pueden aplastar al avatar
En la gura 7.12 el avatar tiene que interactuar con la palanca para desac- tivar el láser sin ser impactado por el proyectil que dispara el arma situado a la izquierda.
50 Figura 7.12: Ejemplo de prueba con arma, palanca y láser
En la gura 7.13 se muestra otro puzle. En este caso, el avatar tiene que activar la palanca para que la plataforma móvil baje. Seguidamente, debe lan- zarse al portal violeta que tiene a la derecha, que le tele-transporta al portal superior, cayendo en la plataforma ( gura 7.14). La palanca vuelve a su posi- ción original cuando el avatar no interactúa con ella, subiendo la plataforma y permitiendo al personaje alcanzar el botón. El botón activa el portal azul, creando una caja que cae sobre el botón y desactiva el láser. Finalmente, el avatar puede seguir avanzando por el nivel ( gura 7.15).
51 Figura 7.13: Segundo ejemplo de puzle (1 de 3)
Figura 7.14: Segundo ejemplo de puzle (2 de 3)
52 Figura 7.15: Segundo ejemplo de puzle (3 de 3)
En la gura 7.16 aparece un trampolín o cama elástica que impulsa al avatar hacia arriba cuando salta sobre él, permitiéndole llegar a la cuerda.
Figura 7.16: Mecánicas con trampolines o camas elásticas
En la gura 7.17 el avatar interactúa con la palanca para activar el portal azul, que crea un vehículo volador que se muestra debajo del portal. El avatar
53 puede subirse en él, de forma que al presionar el botón, activa los propulsores, impulsando el vehículo hacia arriba. El avatar puede aprovechar su peso para inclinar el vehículo y moverlo horizontalmente para superar los obstáculos de la parte superior ( gura 7.18).
Figura 7.17: Ejemplo de prueba con vehículo aéreo y obstáculos (1 de 2)
Figura 7.18: Ejemplo de prueba con vehículo aéreo y obstáculos (2 de 2)
54 7.5. Arquitectura e Implementación del Juego
En esta sección se abordarán cuestiones relativas al diseño e implementación del juego.
La aquitectura del juego se ha diseñado teniendo en cuenta Unity como motor de juego (anexoA). Para simpli car el análisis, se dividirá en varios apartados:
Editor de niveles.
Juego/Jugabilidad.
Interfaz de usuario.
Servidor.
7.5.1. Editor de Niveles
EL videojuego propuesto se centra en aprovechar las mecánicas del mismo para que los usuarios puedan crear niveles y puedan ser jugados por el resto de usuarios. Por lo tanto, hay que desarrollar un editor de niveles. Consiste en un entorno, incluido en el propio juego, que permite a los usuarios crear niveles utilizando los objetos y mecánicas del juego.
Se ha decidido utilizar una aproximación de los Sistemas Basados en En- tidades. Representamos los modos de edición del editor como sistemas y los objetos editables como entidades. De esta forma, un objeto editable estará compuesto por una serie de componentes que establecen los tipos de edición que se pueden aplicar al objeto.
De forma general, para que un objeto sea editable por un modo, deberá contener un componente que identi ca al objeto como editable por ese modo y otro componente con los datos a editar. Por ejemplo, un objeto será Escalable
55 por el modo de edición Escalar si contiene los componentes Scalable, que indica que se puede escalar, y Scale, que almacena los datos de escalado.
Modos de Edición
En la mayoría de los casos, todos los tipos de tareas que realiza el usuario están implementadas mediante un modo/sistema.
En un instante determinado, puede haber uno o varios modos activos. Un modo puede no realizar acciones sobre un objeto editable. Por ejemplo, se puede desarrollar un modo para elegir una opción sobre un menú o paleta.
Se ha utilizado una implementación del patrón Publish/Subscribe para rea- lizar la comunicación. Por ejemplo, para crear un objeto en el nivel, se utiliza una paleta de objetos. En esta operación intervienen dos modos, el modo que crea el objeto (CM ) y el modo que permite seleccionar el objeto de la paleta (PM ). De esta forma, CM se subscribe al evento de seleccionar un objeto de la paleta y cuando PM lanza el evento, CM lo recibe y crea el objeto.
A modo de resumen, los elementos principales del editor son:
Editor de nivel. Gestor principal de la edición del nivel.
Nivel. Se re ere al nivel que crea un jugador. Está formado por un conjunto de objetos editables.
Modo/Sistema. Sistema encargado de gestionar una tarea en el editor.
Entidad de editor/Objeto editable. Objeto que forma parte del nivel en edición. Todos los tipos de objeto editable que el usuario puede crear serán Prefabs2 de Unity.
Componente de modo. Componente que indica que un objeto es edi- table por un modo.
2Los Prefabs son objetos prefabricados con una determinada con guración de componen- tes
56 Componente de datos. Componente que almacena datos sobre un contexto especí co del objeto editable.
Por otra parte, se ha reutilizado código utilizando herencia de clases en la implementación de los modos del editor.
Como podemos apreciar en la gura 7.19, el editor (LevelEditor) puede tener varios modos activos. EditorMode es la implementación base con las fun- cionalidades principales que tiene un modo. De esta forma, todos los modos del editor herendan de la clase base sobreescribiendo y añadiendo las caracte- rísticas correspondientes.
Figura 7.19: Representación de los modos de edición del editor de niveles
A continuación, se describe brevemente el funcionamiento de cada modo:
TransformMode. Realiza una acción de transformación sobre un objeto editable. Se ha desarrollado para describir las funcionalidades comunes de las acciones de mover, escalar y rotar.
MoveMode. Permite mover un objeto editable seleccionado por el nivel.
57 ScaleMode. Permite escalar un objeto editable seleccionado.
RotateMode. Permite rotar un objeto editable seleccionado.
CreateMode. Crea un objeto editable temporal. El objeto puede ser colocado en el nivel o destruido cancelando la acción.
PathMode. Permite crear una ruta sobre un objeto editable, de forma que el objeto en el nivel jugable seguirá el recorrido de nido por la ruta.
SelectEntityMode. Este modo permite seleccionar un objeto. Cuando un objeto es seleccionado, lanza un evento informando de la selección.
GroupMode. Permite agrupar varios objetos como descendientes de un objeto de grupo.
LinkMode. Permite conectar nodos (puntos de enlace de dispositivos lógicos) de dos objetos. Por ejemplo, se puede conectar un botón con un arma para que ésta dispare al pulsarlo.
JointMode. Permite realizar enlaces entre bloques utilizando propie- dades físicas. Por ejemplo, podemos unir un rectángulo con un círculo mediante un eje con motor, a modo de rueda.
ChangePropertiesMode. Permite cambiar propiedades de nidas sobre un objeto mediante un menú interactivo. Por ejemplo, el usuario puede cambiar el intervalo de tiempo de un temporizador.
DeleteMode. Permite destruir objetos del nivel.
PalleteMode. Muestra un menú con una paleta de objetos, permitiendo seleccionar uno.
TestLevelMode. Se encarga de gestionar las operaciones relacionadas con la conversión de los objetos del editor a objetos del nivel de juego y de otras funciones, permitiendo al usuario probar el nivel y volver a la edición en cualquier momento.
58 PublishMode. Muestra un menú iteractivo, permitiendo cambiar los detalles del nivel y publicar en el servidor para que los demás usuarios puedan jugar.
ScreenShotMode. Permite realizar una captura o foto de una región con gurable del nivel.
Componentes de Edición
Como se ha comentado anteriormente, se han desarrollado componentes para almacenar datos y componentes para permitir a los modos interactuar con los objetos del nivel.
Figura 7.20: Representación de los componentes de edición que pueden tener los objetos editables
En la gura 7.20 aparece re ejada la estructura de implementación utilizada para de nir los componentes. Podemos destacar lo siguiente:
ExtendedComponent extiende los componentes que proporciona Unity. Añade información relevante para el juego.
EditorComponent identi ca los componentes de edición.
59 FeatureComponent y sus descendientes son los componentes que permi- ten a los modos del editor manipular los objetos.
DataComponent es un componente que almacena datos relevantes del objeto editable. Entre sus descendientes tenemos lo siguiente:
• Position, Scale y Rotation almacenan la posición, escala y rotación del objeto, respectivamente.
• Color almacena el color del objeto.
• Property almacena datos que pueden ser modi cados por el usuario en la edición del nivel mediante un menú. Por ejemplo, el intervalo de tiempo de un temporizador es personalizable por el usuario. Po- demos apreciar que hay propiedades para los tipos de datos básicos. EntityProperty almacena la referencia a un objeto del nivel.
Almacenamiento y Carga de Datos
Uno de los aspectos importantes del editor de niveles es el almacenamiento de los datos del nivel.
La serialización de un nivel se realiza en formato JSON y se almacenan todas las entidades del nivel y la información de los componentes de datos. Las modi caciones que el jugador realice sobre el nivel se guardan en un archivo hasta su publicación en el servidor. El usuario puede salir del nivel y continuar con su edición en cualquier momento.
La tarea de serialización se ha diseñado de la siguiente forma:
Todo objeto editable que va a formar parte del nivel jugable tiene el componente EditableEntity.
Todo componente que tenga datos relevantes para el objeto o nivel, he- reda de DataComponent e implementa los métodos Save y Load para
60 almacenar y cargar los datos.
El sistema encargado del almacenamiento de datos, recorre todo el con- junto de objetos editables y sus componentes de datos, construyendo el archivo.
Por otra parte, el sistema encargado de la carga de datos, recorre el ar- chivo en dos fases. En el primer paso, crea todos los objetos editables a partir de los Prefabs correspondientes, de forma que ya tienen los com- ponentes propios de ese objeto. En la segunda fase, asigna los datos de los componentes del archivo a cada componente del nivel.
Prueba del Nivel
Durante la edición del nivel, el usuario puede cambiar a la fase de prueba del nivel. En esta operación, todas las entidades de editor son transformadas en las entidades de juego correspondientes y los componentes son procesados, construyendo el nivel jugable.
La conversión del nivel es algo más complicada que el almacenamiento y carga de datos. Componentes como la posición, escala y rotación son fáciles de tratar, pero otros componentes como las conexiones entre dispositivos, las uniones de física y las propiedades no son triviales.
La decisión que se ha tomado es crear un mapa encargado de procesar un componente de un objeto editable para obtener un componente de una entidad de juego u otros resultados, dependiendo de las características del componente y del proceso de conversión. Por ejemplo:
Los datos del componente Position de un objeto editable son asignados al componente Transform (es un componente de Unity) del objeto en el nivel jugable.
Los datos del componente Connection, que representa una conexión entre
61 los nodos de dos objetos editables, es procesado para unir los componen- tes Transmiter y Receiver de los objetos jugables involucrados.
Una vez realizado el proceso de conversión, las entidades del editor son destruidas y el usuario puede jugar y probar su nivel.
De la misma forma, el usuario puede volver a la fase de edición, las entidades de juego son destruidas y los objetos editables del nivel son cargados a partir de la última versión del archivo de guardado.
Publicación del Nivel
Una vez el usuario esté conforme con su nivel puede publicarlo con un nombre, una descripción y una captura de la región del nivel que considere oportuna.
En este caso, son las entidades de juego las almacenadas en un archivo, ya que los demás jugadores juegan al nivel y no participan en la edición. De esta forma, se genera el archivo JSON y se sube al servidor.
7.5.2. Juego/Jugabilidad
Podemos distinguir dos partes en el desarrollo de la jugabilidad:
Avatar del jugador.
Resto de objetos de un nivel.
Avatar/Personaje
El avatar del jugador se ha diseñado utilizando varios componentes:
Controlador (PlayerController). Engloba todo el comportamiento del avatar utilizando una máquina de estados. Se encarga de:
62 • Gestionar todos los movimientos del avatar.
• Gestionar la máquina de estados.
• Reproducir las animaciones correspondientes.
Entrada de usuario (UserInput). Se encarga de gestionar las acciones del jugador a través de los dispositivos de entrada para comunicárselas al controlador del avatar. Se ha decidido utilizar la inyección de dependencia y ejecutar directamente los métodos de PlayerController en vez de usar otras técnicas de comunicación, para simpli car su implementación.
Componentes de Unity. Se han utilizado los componentes BoxColli- der2D y Rigidbody2D, para que Unity gestione las físicas del avatar, y Animator para poder reproducir las animaciones del personaje.
Para gestionar el control del personaje, se ha utilizado una máquina de estados para saber en todo momento el estado del avatar y sus posibles movi- mientos.
Figura 7.21: Representación aproximada de la máquina de estados implemen- tada para el avatar
En la gura 7.21 observamos la máquina de estados desarrollada. Es una representación simpli cada, donde se representa lo siguiente:
63 ON_GROUND y ON_AIR no son estados realmente, simplemente es una división para mejorar la comprensión del diagrama.
IDLE es el estado por defecto y representa al avatar parado, cuando el usuario no está pulsando ningún botón de acción.
Se representan dos tipos de transiciones. La echa indica que se puede pasar del estado origen al destino. La linea indica que se puede ir de un estado a otro y viceversa.
Una echa con origen o destino en ON_GROUND y ON_AIR represen- ta que la mayoría de los nodos origen o destino del interior que pueden participar en la transición. Por ejemplo, se puede pasar al estado JUM- PING desde IDLE, WALKING y RUNNING.
El estado GRABING_OBJECT es un estado aditivo, es decir, el avatar puede agarrar un objeto mientras está en los estados WALKING y RUNNING.
Objetos de Juego
Para el resto de elementos se ha utilizado la AOC. De esta forma, se han desarrollado:
Componentes genéricos. Aquellos que pueden utilizarse en cualquier objeto. Algunos ejemplos son:
• DestroyOnLevelOut. Destruye el objeto si sale de los límites del nivel.
• Receiver y Transmitter. La comunicación entre dispositivos de un circuito en el nivel jugable se realiza con estos dos componentes. Un dispositivo puede enviar una señal a otro si tiene una conexión entre su transmisor y el receptor del otro. Se utilizan los delegados/- footnoteEn C#, un delegado es un puntero a una función o método
64 y eventos de C#, de forma que el receptor se mantendrá a la espera del evento en el transmisor y al recibir la señal, la procesa y reali- za las acciones correspondientes. Por ejemplo, un botón conectado a un arma, utilizará el componente Transmitter para comunicarse con el componente Receiver del arma y activarla.
Componentes especí cos. Son aquellos que solo tienen sentido en cier- tos objetos. De forma general, cada tipo de objeto del nivel jugable tiene un componente especí co, que le distingue del resto. Por ejemplo, un sensor de área tendrá un componente para detectar si un objeto entra o sale del área..
7.5.3. Interfaz de Usuario
La Interfaz de usuario está compuesta por aquellos elementos que permiten al usuario interactuar con el juego. De esta forma, podemos distinguir varios tipos de interfaz:
Menú de juego. Son todos los menús que aparecen al ejecutar el juego. Se han construido con las herramientas de interfaz de Unity, en una escena única, con varios componentes para gestionar la con guración y navegación del juego. Se utilizan elementos de Unity como:
• Panel. Permite agrupar elementos.
• Button.
• Slider. Barras de desplazamiento para ajustar aspectos como el volumen.
• Text. Se utilizan como etiquetas y títulos.
• Canvas Group. Permite ocultar y mostrar grupos de elementos.
• Vertical Layout, Horizontal Layout, Grid Layout. Modi can
65 la posición y el tamaño de los descendientes del objeto que tiene el componente.
Menú del editor. El editor de niveles contará con un menú grá co, incluyendo atajos de teclado para ciertas acciones. La invocación de las acciones y la gestión de los elementos del menú se realizará de forma independiente utilizando la comunicación basada en Publish/Subscribe y la gestión de eventos de Unity. Por ejemplo, el gestor principal del editor se subscribe al evento de cambio de modo, de forma que el sistema de GUI y de gestión de teclado lanzarán el evento de cambiar a otro modo para que el gestor se entere.
Teclado, ratón y mando. Se realiza una gestión de entrada, con con- troles personalizables por el usuario, para poder jugar a los niveles tanto con teclado como con mando (Gamepad). La edición de niveles se rea- lizará con teclado y ratón. Para ello, se utilizará la gestión de eventos de Unity y la librería cInput2, disponible en la tienda (Asset Store) de Unity.
7.5.4. Servidor
Se requiere de una aplicación alojada en un servidor para realizar la gestión de usuarios y niveles del juego.
Para ello, se implementará un pequeño servicio REST utilizando Ruby co- mo lenguaje de programación, Sinatra para la construcción de la aplicación y PostgreSQL para la base de datos. Además, se desarrollará un pequeño gestor de cheros para gestionar los niveles de los usuarios.
66 Modelo de Datos
El modelo de datos utilizado se representa en la gura 7.22, donde podemos deducir lo siguiente:
El modelo está formado por usuarios (USER), niveles (LEVEL), valora- ciones de los niveles (RATE) e informaciones de las partidas (PLAY ).
Un nivel está publicado por un usuario. Un usuario puede publicar los niveles que desee.
Un nivel puede ser jugado por varios usuarios y un usuario puede jugar a un nivel varias veces. Hay un registro de cada partida.
Un usuario puede realizar valoraciones de los niveles, pero solo una por cada nivel.
Figura 7.22: Representación del modelo de datos utilizado en el servidor
Servicio REST
El juego utiliza el servidor para recibir y enviar información de niveles y usuarios. Como no es un requisito muy complejo, se ha decidido realizar una implementación de un servicio REST. Las peticiones que proporciona el servicio se describen en las tablas 7.3y 7.4.
67 Petición Parámetros Descripción /register name, password Creación de un nuevo usuario /login name, password Identi cación de usuario /levels/search keyword, updloaded, Búsqueda de niveles sort_by /play user_id, level_id Registro de una nueva partida /score play_id, value Registro de la puntuación de un partida /rate user_id, level_id, va- Valoración de un nivel lue /level user_id, title, descrip- Publicación de un nivel tion, image, content
Cuadro 7.3: Peticiones POST del servicio REST
Petición Descripción /levels/:level_id/content Descarga del contenido de un ni- vel jugable /levels/:level_id/image Descarga de la imagen de un nivel /levels/:level_id/scores/:user_id Petición de las puntuaciones de un nivel relativas a un jugador
/levels/:level_id/max_score/:user_id Petición de la puntuación máxi- ma de un jugador en un nivel /levels/:level_id/max_scores Petición de las puntuaciones má- ximas de de un nivel (de todos los jugadores)
Cuadro 7.4: Peticiones GET del servicio REST
68 Capítulo 8
Resultados y Discusión
En este capítulo se mostrará el videojuego desarrollado, al que se ha nom- brado como Toy Box, mostrando capturas de pantalla de los principales ele- mentos del mismo.
En primer lugar, repasaremos el menú principal. La gura 8.1 representa un menú de navegación a los distintos entornos del juego:
Play. Muestra el buscador de niveles publicados en el servidor ( gura 8.10). Presenta opciones y un buscador por palabras clave para ltrar la búsqueda.
Build. Muestra el gestor de niveles ( gura 8.6) del jugador actual. El gestor muestra los niveles creados por el jugador, permitiéndo su edición, borrado y creación de otros niveles.
Customize. Muestra un menú ( gura 8.5) para cambiar los colores del avatar.
Options. Muestra el menú de con guración del juego. Está dividido en tres partes.
• Con guración de grá cos ( gura 8.2).
69 • Con guración de sonido ( gura 8.3).
• Con guración de controles ( gura 8.4). Se puede asignar dos bo- tones a cada acción o evento. Se permite controlar al avatar con teclado o mando.
Exit. Cierra la aplicación.
Music. El botón situado en la esquina inferior derecha del panel sirve para cambiar entre las distintas pistas de música.
Una vez el jugador se encuentra en el entorno de edición de un nivel, en- contrará una escena como la que se presenta en la gura 8.7. El usuario puede mover la cámara por el nivel hasta los límites del mismo y puede utilizar los botones del menú para crear objetos y realizar otras acciones. El usuario puede:
1. Cambiar entre el modo de prueba de nivel y la edición del mismo.
2. Cambiar el fondo del nivel.
3. Cambiar el color. Al crear las guras básicas, éstas aparecen con el color seleccionado.
4. Mover, escalar y rotar objetos.
5. Borrar objetos.
6. Abrir la paleta de objetos. Muestra un menú ( gura 8.8) con todos los objetos del juego. Al pulsar sobre un elemento de la paleta, se crea el objeto y el usuario puede colocarlo en el nivel.
7. Acceder y cambiar las propiedades de ciertos objetos.
8. Conectar dispositivos lógicos.
9. Agrupar objetos. El usuario puede seleccionar varios objetos y enlazarlos a un objeto raíz.
10. Crear una ruta para un bloque.
70 11. Conectar dos bloques con una unión rígida. En el nivel jugable no se representa la unión, pero el resultado es como si existiera una barra con cada objeto en un extremo.
12. Conectar dos guras con un eje. Es similar a la unión rígida, pero la gura de uno de los extremos puede girar.
El usuario puede salirse en cualquier momento de la edición del nivel, sin perder el progreso. Una vez el usuario está satisfecho con el resultado, puede acceder al menú de publicación del nivel ( gura 8.9), ajustar el nombre y la descripción y tomar una captura de la región del nivel que desee.
Por otra parte, cuando un jugador termina el nivel, se presenta un menú ( - gura 8.11) con su puntuación actual y máxima y una lista con las puntuaciones máximas de los jugadores que han jugado al nivel.
Figura 8.1: Captura del menú principal
71 Figura 8.2: Captura del menú de opciones grá cas
Figura 8.3: Captura del menú de opciones de sonido
72 Figura 8.4: Captura del menú de opciones de los controles del juego
Figura 8.5: Captura del menú de personalización del avatar
73 Figura 8.6: Captura del menú de gestión de niveles editables del jugador
Figura 8.7: Captura del editor con varios objetos editables
74 Figura 8.8: Captura de la paleta de objetos del editor de nivel
Figura 8.9: Captura del menú de publicación de un nivel
75 Figura 8.10: Captura del menú de búsqueda y selección de niveles
Figura 8.11: Captura del menú de n del nivel con una lista de puntuaciones máximas
Los elementos presentados anteriormente construyen la base del juego. Es una base mínima que permite cierta exibilidad a la hora de crear niveles, pero no proporciona demasiados elementos jugables. Sería necesario añadir más opciones y re nar las presentes para que este juego fuera un buen producto y pudiera ser publicado en el mercado.
Por otra parte, hay muchos aspectos mejorables:
76 No se controla ciertos aspectos de seguridad relacionados con el servidor y los usuarios.
El apartado grá co es un aspecto al que se le ha prestado poca atención.
Las interfaces de usuario son muy mejorables.
Hay que realizar una tarea de búsqueda y resolución de posibles errores que pueden ocurrir en la aplicación.
No obstante, debemos recordar que la aplicación se encuentra en una versión temprana del desarrollo, donde se está estudiando, planteando y construyendo las mecánicas principales del juego. Todos los elementos, relacionados con el juego, explicados en este documento pueden cambiar si se decidiera continuar y desarrollar una versión más avanzada del mismo.
77 78 Capítulo 9
Conclusiones
La propuesta inicial era desarrollar un prototipo de videojuego, ya que desarrollar el juego completo superaría el alcance del TFM. Sin embargo, al- gunos aspectos como el editor de niveles no son triviales de prototipar. Por este motivo, se ha decidido dar un paso más y desarrollar algunas funciona- lidades pensando en la arquitectura y no tanto en conseguir una versión lo antes posible. Otras razones son aprender más sobre Unity y el desarrollo de videojuegos.
La decisión anterior ha repercutido en el alcance del proyecto y se ha dedica- do más esfuerzo que el estimado (300-350 horas). No obstante, las di cultades que han surgido se han conseguido solventar de forma satisfactoria en la ma- yoría de los casos y se han adquirido valiosos conocimientos, cumpliendo con uno de los objetivos más importantes del TFM.
Utilizar Unity como motor del juego ha facilitado en gran medida muchos de los aspectos del desarrollo del proyecto, pero en algunos casos se ha tenido que desarrollar implementaciones para ampliar o incluir funcionalidades que Unity no puede aportar para construir algunas características del juego.
Respecto a la arquitectura del servidor, posiblemente no sea la implemen-
79 tación más adecuada para un videjuego, pero se ha realizado así para agilizar el desarrollo y conseguir rápidamente una versión funcional que gestione los usuarios y niveles del juego.
Por otra parte, el apartado artístico es muy mejorable, es el aspecto más ojo del videojuego, pero en un prototipo no importan tanto los grá cos y no entraba en los objetivos del TFM.
Como conclusión nal, aunque quedan algunos aspectos que añadir y me- jorar, se ha conseguido construir una versión estable y que representa las me- cánicas y planteamientos descritos en el documento de concepto. También se han adquirido conocimientos sobre el proceso de prototipado y desarrollo de videojuegos, arquitectura software de videojuegos y modelado 3D.
80 Chapter 10
Conclusion
The initial proposal was to develop a video game prototype, since developing the complete game would be beyond the scope of this TFM. However, some aspects, like the level editor, are not trivial to be prototyped. For this reason, it has been decided to take a step further and develop some functionalities thinking about the software architecture and not so much about getting a simple version as soon as possible. An additional reason is learning more about Unity and the development of video games.
The previous decision has impacted the scope of the project and has devoted more eort than estimated (300-350 hours). However, the di culties that have arisen have been sucesfully solved in most cases and valuable knowledgement has been achieved, ful lling one of the most important objectives of the TFM.
Using Unity as the main engine of the game has greatly facilitated many aspects of project development, but in some cases it has been necessary to developed implementations to extend or include features that Unity cannot contribute to build some features of the game easily.
Regarding the architecture of the server, it may not be the most suitable implementation for a videogame, but it has been done in this way in order to
81 speed up the development and quickly obtain a functional version to manage the users and levels of the game.
On the other hand, the art section is very improvable, it is the loosest aspect of the video game, but in a prototype this does not matter so much and it is not t into the objectives of the TFM.
In conclusion, although there are some aspects to add and improve, it has managed to build a stable version that represents the mechanics and approa- ches described in the concept document. Knowledge about the process of pro- totyping and video game development, video game software architecture and 3D modeling has also been acquired.
82 Capítulo 11
Trabajos Futuros
En este capítulo se presentarán los posibles trabajos futuros:
Mejorar las mecánicas del juego.
Añadir más elementos para la creación de niveles.
Crear una edición de objetos mediante la generación de mallas.
Mejorar la interfaz del editor.
Mejorar el apartado artístico.
Añadir multijugador local y en línea.
83 84 Capítulo 12
Referencias
Videojuego. Wikipedia. 12 agosto 2016, 10:20 [consulta: 16 agosto 2016]. Dispoible en:
https://es.wikipedia.org/wiki/Videojuego
Unity Game Engine. c 2016 [consulta: 2 mayo a 12 noviembre 2016]. Disponible en:
https://unity3d.com/
Unreal Engine Technology. c 2014-2016 [consulta: 18 mayo 2016]. Dis- ponible en:
https://www.unrealengine.com/
CryEngine. The complete solution for next generation game development
by Crytek. c 2016 [consulta: 18 mayo 2016]. Disponible en:
https://www.cryengine.com/
Blender.org. Home of the Blender Project. Free and Open 3D Creation Software. [consulta: 6 junio a 11 julio 2016]. Disponible en:
https://www.blender.org/
85 3ds Max. Software de modelado y renderización en 3D. c 2016 [consulta: 4 junio 2016]. Disponible en: http://www.autodesk.es/products/3ds-max/overview
Schell, J. The Art of Game Design. A Book of Lenses. Morgan Kaufmann, 2008.
Software Architecture and Design Component-Based Architecture. [con- sulta: 10 mayo 2016]. Disponible en: https://www.tutorialspoint.com/software_architecture_design/ compo- nent_based_architecture.htm
Implementation of a component-based entity system in modern C++. Vittorio Romeo, 2015. Disponible en: https://www.youtube.com/watch?v=NTWSeQtHZ9M
Entity system architecture with Unity. Maxim Zaks & Simon Schmid, 2015. Disponible en: https://www.youtube.com/watch?v=1wvMXur19M4
Referencia de C#. c 2016 [consulta: 2 mayo a 12 noviembre 2016]. Dis- ponible en: https://msdn.microsoft.com/es-es/library/618ayhy6.aspx
Unity. Manual de Unity c 2016 [consulta: 2 mayo a 12 noviembre 2016]. Disponible en: https://docs.unity3d.com/es/current/Manual/index.html
Unity. Scripting API. c 2016 [consulta: 2 mayo a 12 noviembre 2016]. Disponible en: https://docs.unity3d.com/ScriptReference/
86 Introduction to Unity UI Part 1. c 2016 [consulta: 14 junio 2016]. Dis- ponible en: https://www.raywenderlich.com/114700/introduction-unity-ui-part-1
Ruby-Doc.org. Documenting the Ruby Language. [consulta: 20 septiem- bre a 1 noviembre 2016]. Disponible en: http://ruby-doc.org/
Rubular. A Ruby regular expression editor and tester. [consulta: 25 junio 2016]. Disponible en: http://rubular.com/
Sinatra Documentation. [consulta: 20 septiembre a 1 noviembre 2016]. Disponible en: http://www.sinatrarb.com/documentation.html
87 88 Apéndice A
Unity y la Arquitectura Orientada a Componentes
Como se ha comentado anteriormente, se utilizará Unity como motor de jue- go. Por este motivo, hay que considerar ciertos aspectos importantes. Uno de ellos es que el motor está basado en la Arquitectura Orientada a Compo- nentes (AOC), que es una variante de la Programación Orientada a Objetos (POO) y se centra en la descomposición del diseño en componentes en lugar de objetos.
Un componente se puede de nir como una unidad de composisión con in- terfaces especi cadas contractualmente y dependencias de contexto explícitas. Un componente de software se puede implementar de forma independiente y está sujeta por la composición por parte de terceros.
Un componente debe ser:
Reusable. Puede ser utilizado en diferentes contextos y aplicaciones, aunque puede haber componentes diseñados para una tarea especí ca.
Sustituible. Puede ser sustituido por otro componente similar.
Extensible. Puede ser utilizado por otro componente para extender su
89 funcionalidad o añadir un nuevo comportamiento.
Encapsulado. Se describe mediante la interfaz, sin exponer detalles in- ternos del mismo.
Independiente. Tiene las mínimas dependencias posibles con otros com- ponentes (bajo acoplamiento).
Por otra parte, Unity utiliza en su motor una visión particular de la AOC, el Sistema Basado en Entidades (SBE), donde los objetos se denominan entidades, los componentes son solo contenedores de datos y el comporta- miento está a cargo de los sistemas. Por ejemplo, Unity tiene un sistema de físicas, las entidades que requieran de comportamientos físicos deben incluir los componentes Collider y Rigidbody, que contienen datos sobre la forma del objeto (colisiones) y sobre las propiedades físicas. El Sistema de físicas, en cada iteración, inspecciona todas las entidades que cuenten con esos componentes y los utiliza para realizar los cálculos correspondientes y modi car los datos de la entidad.
Algunas características y herramientas que proporciona Unity son las si- guientes:
Está implementado en C++, pero utiliza C# y javascript como lenguaje de programación.
Utiliza el GameObject como entidad base, que es un contentedor para otras entidades llamadas componentes, que de nen al GameObject.
Los componentes suelen heredar de la clase MonoBehaviour, que pro- porciona métodos que pueden ser implementados por las clases hijas y son ejecutados en el orden que ha establecido Unity.
90 Figura A.1: Flujo de ejecución de la clase MonoBehaviour dentro del motor Unity
91 Utiliza el paso de mensajes para realizar la comunicación entre compo- nentes. Hay que tener en cuenta que está técnica es muy costosa, ya que se consigue mediante re exión, es decir, examinando y ejecutando, en tiempo de ejecución, los métodos del componente. Puede ser inadecuada para ciertos juegos y plataformas.
Los GameObjects se organizan en la escena, en forma de jerarquía.
Permite la búsqueda de objetos en la jerarquía y componentes en los objetos. Se puede utilizar para comunicar componentes de forma más rápida, pero repercute negativamente en el acoplamiento.
Los campos1 públicos o marcados con el atributo2 [SerializeField] de un componente aparecerán en la ventana Inspector del editor de Unity, de forma que podemos ajustar los valores de dicho atributo sin pasar por el código.
1Equivalen a los atributos en Java 2Equivalen a las etiquetas en Java
92 Figura A.2: Ejemplo de atributos de un componente en la ventana Inspector de Unity
Utiliza los Prefabs (objetos prefabricados) para la construcción de obje- tos con valores especí cos de con guración. Por ejemplo, se puede crear un Prefab que representa a un enemigo con los componentes de inteli- gencia arti cial, vida y muerte, de forma que podrá ser utilizado para instanciar un enemigo en cualquier escena.
93 94 Apéndice B
Modelado del Personaje en Blender
El personaje que aparece en este videojuego se ha modelado utilizando Blender. Para ello, se han realizado las siguientes fases:
1. Modelado. Se ha intentado utiliar la técnica conocida como Low Poly, es decir, utilizando la menor cantidad de polígonos para construir el personaje. De esta forma:
a) Se ha con gurado blender para que presente un boceto a modo de plantilla en las cámaras correspondientes, como se puede apreciar en la gura B.1.
b) Se ha creado un cubo 3D, realizando extrucciones de las caras de la malla 3D resultante del cubo.
c) Según se van realizando extrucciones, se posicionan los vértices y se escalan y rotan las aristas y caras del modelo para dar forma al personaje.
d) El personaje se ha modelado construyendo las partes principales del cuerpo de forma independiente. Aunque el modelo forma solo una
95 malla, los vértices de las diferentes secciones no están unidos.
2. Se ha asignado a las distintas partes del cuerpo un material, de forma que podrá ser personalizado en Unity y en el juego.
3. Se ha realizado la fase de rigging, que consiste en crear los huesos y asignar los vértices que mueve cada uno. Debido a que el personaje se ha creado con las partes separadas, ha resultado sencillo dicha asignación.
A continuación se presentarán algunas capturas del progreso:
Figura B.1: Captura de Blender con las plantillas 2D del personaje
96 Figura B.2: Captura de Blender el módelo 3D completado
Figura B.3: Captura de Blender con los huesos del personaje
97 98