SweetRunner : juego de plataforma estilo runner para Android

0 Trabajo de Final de Título en Ingeniería Informática “SweetRunner”: juego de plataforma estilo runner para Android. Autor: Cynthia Paola Ramos Martínez. Tutor: Cayetano Guerra Artal. Tutor: José Miguel Santos Espino. Grado en Ingeniería Informática Curso 2014-2015 Convocatoria Extraordinaria Universidad de Las Palmas de Gran Canaria 1 AGRADECIMIENTOS Al redactar esta sección es inevitable no ponernos nostálgicos, empezamos a recordar todo lo que hemos pasado para llegar hasta este punto e incontables imágenes invaden nuestra cabeza: tantas noches de estudio con compañeros o acompañados simplemente de un buen café, risas y momentos llenos de alegría, los rostros profesores que en muchas ocasiones fueron verdaderos mentores, y por supuesto, los cálidos rostros de nuestros familiares incitándonos a seguir. A esas dos personas, que con paciencia y comprensión me supieron guiar, aconsejar y apoyar en la realización del presente trabajo de final de título. Mis dos estimados tutores, Cayetano Guerra Artal y José Miguel Santos Espino, sin ustedes nada de esto habría sido posible. Amigos y compañeros entrañables, con los que compartimos diversos momentos de estrés por exámenes, agobio para llegar a tiempo para entregar prácticas, alegrías al aprobar, diversión, entre otros. Chinito, eres uno de los pilares fundamentales de mi vida, fuiste mi soporte cuando lo necesité, me brindaste tu cariño y amistad, por todo esto y más te doy las gracias. A Mi querida familia, que son el pilar más importante de mi existencia, a ustedes que me enseñaron todo lo que se, que me mantuvieron a flote en los momentos duros, que me han dado su apoyo de forma incondicional y a quienes tanto quiero. Mami, Moché, Abi Javi, Cris y Fridel, sencillamente, gracias por ser ustedes. A esa persona, que casi desde el momento en que nos conocimos ha estado alentándome a seguir, me ha otorgado su afecto y amistad. Sin ti no lo hubiese logrado. A todos, muchas gracias. 2 RESUMEN El primordial objetivo del presente Trabajo de Final de Título (TFT) es realizar un juego de plataforma estilo runner para dispositivos móviles con sistema Android, y por medio de este, realizar un análisis de las diferentes herramientas que se pueden emplear para el desarrollo juegos para móvil estilo runner. El resultado que se obtuvo fue SweetRuner, una aplicación móvil que permite jugar en dispositivos móviles que posean sistema Android en una versión igual o superior a Honeycomb. Las características que posee SweetRunner son: creación aleatoria de los elementos del juego; obstáculos y bonificaciones; aumento de dificultad conforme aumenta la puntuación; cálculo de puntuación y puntuación máxima; finalmente, comunicación con la red social Facebook. El desarrollo de SweetRunner se realizó en el motor de videojuegos Unity3D, ya que es considerado la mejor opción para este tipo de juegos, por las facilidades que brinda y por su sencillez y amigabilidad. La mayoría de las herramientas empleadas en el desarrollo de la app son de software libre, pero también se ha trabajado con software privativo. Es por esta razón que el presente trabajo se distribuye bajo la licencia GNU LGPL versión3, ya que con esta licencia se pueden enlazar a un programa no GPL, que puede ser software libre o no. El presente trabajo tiene el potencial necesario para convertirse en una guía para desarrollar juegos para móviles estilo runner. Esta guía facilitará el proceso de desarrollo y optimización, además de ayudar a entender el funcionamiento y la potencialidad de las diferentes herramientas y componentes que se usaron. 3 ABSTRACT The primary objective of this Final Working Title (TFT) is making a runner style platform game for mobile devices with Android system, and through this, an analysis of the different tools that can be used for developing games mobile, runner style. The result obtained was SweetRuner, a mobile application that is optimized for play on mobile devices that have a version equal to or greater than Honeycomb Android system. SweetRunner possessing characteristics are: random creation of game elements; obstacles and bonuses; Difficulty increases with increasing score; calculation of score and maximum score; finally, communication with the social network Facebook. The development of SweetRunner was performed in professional Unity3D game engine, as it is considered the best choice for this type of game, for the facilities provided, for its simplicity and friendliness. Most of the tools used in the development of the app is free software, but has also worked with proprietary software. It is for this reason that the present work is distributed under the GNU LGPL Version3, because with this license can be linked to a nonGPL program, which can be free or not software. The present work has the potential to become a guide for developing mobile games runner style. This guide will facilitate the process of development and optimization, and help to understand the functioning and potential of the different tools and components that are used. 4 TABLA DE CONTENIDOS AGRADECIMIENTOS ............................................................................. 1 RESUMEN. ........................................................................................... 2 ABSTRACT ............................................................................................ 3 1 INTRODUCCIÓN ................................................................................ 7 1.1 ESTADO ACTUAL ............................................................................................... 9 1.2 OBJETIVOS ......................................................................................................... 9 2 COMPETENCIAS ............................................................................... 11 2.1 CII08…… ............................................................................................................. 11 2.2 CII09……………………………………………………. ..................................................... 11 2.3 CII18……………………………………………………………………………………………………. .11 2.4 ISO2…………………………………………………………………………………………………….. 11 2.5 IS05……………………………………………………………………………………………………… 12 3 PLIEGO DE CONDICIONES ............................................................... 13 3.1 PLIEGO de CONDICIONES GENERALES ........................................................ 13 3.2 PLIEGO DE ESPECIFICACIONES TÉCNICAS ................................................ 13 3.2.1 Especificaciones de materiales y equipos………………………………………..13 3.2.2 Especificaciones de ejecución………………………………………………………..14 3.3 PLIEGO DE CLAÚSULAS ADMINISTRATIVAS .............................................. 15 3.4 LICENCIAS ........................................................................................................ 15 4 APORTACIONES ............................................................................... 17 5 NORMATIVA Y LEGISLACIÓN .......................................................... 19 5.1 LEY ORGÁNICA DE PROTECCIÓN DE DATOS (LOPD) ............................... 19 5.2 LEY DE SERVICIOS DE LA SOCIEDAD DE LA INFORMACIÓN DE COMERCIO ELECTRÓNICO (LSSI) ......................................................................... 19 5 5.3 NORMATIVA DE COOKIES ............................................................................. 20 5.4 LICENCIAS ..........................................................................................................21 5.4.1 Licencia pública General (Gnu Lpg)……………………………………………………21 5.4.2 Licencia Pública General Reducida (GNU LGPL)…………………………………21 5.4.3 Apache 2.0……………………………………………………………………………………...22 5.4.4 Creative Commons (CC)……………………………………………………………………22 6 REQUISITOS .................................................................................... 24 6.1 HARDWARE ....................................................................................................... 24 6.2 SOFTWARE ........................................................................................................ 24 7 METODOLOGÍA Y PLAN DE TRABAJO ............................................. 26 7.1 METODOLOGÍA ............................................................................................... 26 7.2 PLAN DE TRABAJO ......................................................................................... 27 8 CONCEPTOS Y FUNCIONES PROPIAS ............................................. 29 8.1 CONCEPTOS ..................................................................................................... 29 8.1.1 Islas y Sprites……………………………………………………………………………………29 8.1.2 Atlas………………………………………………………………………………………………..29 8.1.3 Sprite Texture…………………………………………………………………………………..29 8.1.4 GameObject……………………………………………………………………………………..29 8.1.5 Partículas…………………………………………………………………………………………30 8.1.6 Cámara…………………………………………………………………………………………….31 8.2 FUNCIONES PROPIAS .................................................................................... 32 8.2.1 Awake……………………………………………………………………………………………..32 8.2.2 Start……………………………………………………………………………………………….32 8.2.3 Update……………………………………………………………………………………………33 8.2.4 FixedUpdate……………………………………………………………………………………33 9 ANÁLISIS DEL PROBLEMA ............................................................. 34 9.1 UNITY3D ........................................................................................................... 34 9.2 C#....................................................................................................................... 37 9.3 MONODEVELOP .............................................................................................. 37 6 9.4 INKSCAPE ........................................................................................................ 38 9.5 GIMP…………………………………………………………………………………………………… 39 9.6 AUDACITY .........................................................................................................41 10 DESARROLLO ................................................................................ 42 10.1 DISEÑO E IMPLEMENTACIÓN .................................................................... 42 10.1.1 Primera Aproximación……………………………………………………………………..42 10.1.2 Obstáculos Y Bonificaciones…………………………………………………………….45 10.1.3 Generación Aleatoria……………………………………………………………………….47 10.1.4 Elementos Gráficos………………………………………………………………………….49 10.1.5 Integración De Puntuación……………………………………………………………….52 10.1.6 GUI………………………………………………………………………………………………..53 10.1.7 Efectos……………………………………………………………………………………………54 10.1.8 Redes Sociales…………………………………………………………………………………56 10.1.9 Limitación De Frames……………………………………………………………………..58 10.1.10 Incorporación de audio………………………………………………………………….58 11 PRUEBAS FINALES Y RESULTADOS .............................................. 59 12 CONCLUSIONES Y TRABAJOS FUTUROS ........................................ 61 12.1 CONCLUSIONES ............................................................................................. 61 12.2 TRABAJOS FUTUROS .................................................................................... 62 13 FUENTES DE INFORMACIÓN ......................................................... 63 7 1 INTRODUCCIÓN La historia de los videojuegos tiene su origen en los finales de la década de los 40, concretamente tras la segunda guerra mundial. Las potencias vencedoras iniciaron carreras tecnológicas para construir las primeras supercomputadoras programables como ENIAC, una computadora enorme que ocupaba una superficie total de 167 m² y alcanzaba un peso de 27 toneladas. Los primeros videojuegos estaban concebidos mayormente como experimentos y pruebas académicas por parte de científicos y físicos, no fue hasta la década de los 70 que los videojuegos empezaron a adquirir un carácter más comercial, marcando así el inicio de una nueva era. Una era en la que los videojuegos se acabarían convirtiendo en un fenómeno culturar de masas, llegando incluso a lograr el estatus de medio artístico en ciertos países. El inicio se suscitó en el año de 1994, con el juego del teléfono pionero en la instalación de juegos, se trató de una versión de Tetris en la Hagenuk MT-2000. Sin embargo, no fue sino hasta tres años después de que los teléfonos móviles tuvieron su primer verdadero éxito. Podría haber sido muy básico, pero la aparición de la serpiente (Snake) en el Nokia 6610 fue un momento decisivo para la industria, fue el momento en el que una nueva era vio la luz. Algunas actualizaciones más adelante, 400 millones de juegos instalados y la sencillez de este juego, clave fundamental para atraer una gran audiencia de jugadores, fueron los elementos que cambiaron el la concepción que se tenía de los teléfonos móviles. De repente, la gente empezó a usar de forma regular sus teléfonos para algo más que para hacer llamadas. Al igual que la industria del cine, los primeros años de juegos móviles eran exclusivamente en blanco y negro. No fue hasta cuatro años más tarde, cuando Nokia introdujo pantallas a color, generando con esto que lo juegos móviles dieran su próximo gran salto tecnológico La llegada de tecnología del Protocolo de Aplicaciones Inalámbricas (WAP) permite a los dispositivos móviles conectarse a Internet, causando otro importante adelanto para los juegos. Otro hecho clave fue la propagación del entorno de 8 programación Java, con teléfonos como el popular Nokia 3410 que apoyan juegos Java. La aparición de la pantalla táctil ofrece nuevas y accesibles formas de jugar. Sin embargo, no fue hasta el lanzamiento de la App Store el año siguiente que se dio un nuevo gran salto en el mundo de los juegos móviles. Los usuarios ahora podían comprar y descargar juegos produciéndose así una revolución en las ventas de juegos. Pero no sólo fue una revolución en ventas, sino que pequeños desarrolladores de pronto encontraron una plataforma para llegar a un público amplio. En la siguiente imagen se pude apreciar algunos de los juegos más relevantes de la historia de los juegos para móviles: Imagen 1: Juegos móviles más relevantes a través de la historia. 15  Desarrollo de un prototipo inicial capaz de mostrar un terreno y mover la cámara.  Mejora del prototipo con la incorporación de un objeto capaz avanzar de forma autónoma por el terreno y de saltar a voluntad del usuario.  Mejora del prototipo agregando enemigos y bonificaciones.  Mejora del prototipo consistente en creación automatizada y aleatoria de entorno, terreno, enemigos y bonificaciones.  Mejora del prototipo, añadiendo los elementos gráficos Background, GUI y efectos (partículas).  Mejora del prototipo en base a la funcionalidad de comunicación con redes sociales y generación de puntuación (score). 3.3 PLIEGO DE CLAÚSULAS ADMINISTRATIVAS El presupuesto necesario para desarrollo de SweetRuner es de euros. A continuación veremos con mayor detalle cómo se obtuvo esta cifra: Recurso Costo Programador (230 hora) 40 euros / hora Diseñador (15 horas) 30 euros/hora Ordenador Portátil Lenovo B590 346 euros SmartPhone Primux TECH alpha 3x 89 euros Tablet Samsung GT-P5110 124, 99 euros Licencia Unity3D Pro (3 meses) 75 euros / mes Total 10434,99 euros (IGIC incl.) Tabla 1: Relación de costes del proyecto. 3.4 LICENCIAS El presente trabajo se distribuye bajo la Licencia Pública General Reducida (GNU LGPL) versión 3, que en realidad es un conjunto de permisos añadidos a la GNU GPL (Licencia Pública General Reducida). Dado que Unity3d no es software 16 libre con esta licencia se pueden enlazar a un programa no-GPL, que puede ser software libre o no. Al igual que otras licencias de este tipo, garantiza la libertad de compartir y modificar el software que está bajo ella, asegurando que el software es libre para todos sus usuarios. 17 4 APORTACIONES Desde que salieron los juegos para Android, hace aproximadamente seis años, hasta nuestros días, su incremento ha sido de forma exponencial. Este crecimiento nos insta a pensar, que existen numerosas técnicas y herramientas usadas por desarrolladores que nos proporcionan un sin fin de métodos para el desarrollo de los citados juegos. Sin embargo, muchas de las metodologías empleadas no han logrado llegar a un nivel óptimo de funcionalidad, y en muchos casos ni a niveles aceptables. Esto es debido a que al no mantenerse un estándar que pueda homologar, de cierta forma, estos métodos, se generan diversos tropiezos e inconvenientes sobre los equipos donde son armados. Es evidente que la mayor parte de dificultades se suscita en personas que empiezan o tienen poca experiencia. Es por eso que a la hora de plantearnos el presente TFT, ha sido pensando en generar un análisis de las herramientas de desarrollo, realizando comparativas entre ellas, estableciendo las metodologías de trabajo más útiles. Todo esto se basará la experiencia propia, en este caso en particular, del desarrollo de un juego plataforma estilo runner. A continuación, se listarán las diferentes aportaciones que ofrece SweetRunner:  Razones por las que se ha escogido Unity3D como principal herramienta de desarrollo.  Análisis de facilidades y dificultades que presenta Unity3D a la hora de desarrollar.  Estudio de compatibilidad que tiene Unity3D con diferentes entornos de programación, lenguajes de programación y herramientas de creación gráfica.  Determinación de la mejor manera de desarrollo, tomando en cuenta factores gráficos, limitaciones de arquitectura de los dispositivos, y 18 codificación, para finalmente poder optimizar el rendimiento de la aplicación. Como hemos podido observar, las aportaciones que ofrece el presente trabajo consisten en una serie de estudios y análisis basados en la experiencia, con el fin de facilitar la vida a quienes deseen desarrollar un juego de este tipo. 19 5 NORMATIVA Y LEGISLACIÓN Este capítulo trata de la legislación vigente que afecta al presente trabajo de final de título. 5.1 LEY ORGÁNICA DE PROTECCIÓN DE DATOS (LOPD) La ley Orgánica de Protección de Datos estipula en el artículo 1 “La presente Ley Orgánica tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente de su honor e intimidad personal y familiar”. Así mismo, el artículo 6 “Consentimiento del afectado” sección 1 dice: “El tratamiento de los datos de carácter personal requerirá el consentimiento inequívoco del afectado, salvo que la ley disponga otra cosa”. Finalmente, en el artículo 11 “Comunicación de Datos” sección 4 se establece: El consentimiento para la comunicación de los datos de carácter personal tiene también un carácter de revocable. En nuestro caso, SweetRunner no recogerá datos de ningún tipo, sin embargo va a permitir la compartición de información a través de las redes sociales, previo consentimiento del usuario. No obstante, en mejoras futuras cabe la posibilidad de pedir al usuario algunos daros, obviamente contando con su consentimiento. 5.2 LEY DE SERVICIOS DE LA SOCIEDAD DE LA INFORMACIÓN DE COMERCIO ELECTRÓNICO (LSSI) El artículo 1 de la Ley de Servicios de la Sociedad de la Información de Comercio Electrónico estipula: “Es objeto de la presente Ley la regulación del régimen jurídico de los servicios de la sociedad de la información y de la contratación por vía electrónica, en lo referente a las obligaciones de los prestadores de servicios incluidos los que actúan como intermediarios en la transmisión de contenidos por las 20 redes de telecomunicaciones, las comunicaciones comerciales por vía electrónica, la información previa y posterior a la celebración de contratos electrónicos, las condiciones relativas a su validez y eficacia y el régimen sancionador aplicable a los prestadores de servicios de la sociedad de la información.” El artículo 22 “Derechos de los destinatarios de servicio” sección 2 señala: “Los prestadores de servicios podrán utilizar dispositivos de almacenamiento y recuperación de datos en equipos terminales de los destinatarios, a condición de que los mismos hayan dado su consentimiento después de que se les haya facilitado información clara y completa sobre su utilización, en particular, sobre los fines del tratamiento de los datos, con arreglo a lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal. Cuando sea técnicamente posible y eficaz, el consentimiento del destinatario para aceptar el tratamiento de los datos podrá facilitarse mediante el uso de los parámetros adecuados del navegador o de otras aplicaciones. Lo anterior no impedirá el posible almacenamiento o acceso de índole técnica al solo fin de efectuar la transmisión de una comunicación por una red de comunicaciones electrónicas o, en la medida que resulte estrictamente necesario, para la prestación de un servicio de la sociedad de la información expresamente solicitado por el destinatario. ” 5.3 NORMATIVA DE COOKIES La Agencia Española de Protección de datos publica la Normativa de Cookies con la finalidad hacer cumplir el artículo 22 sección 2 de la LSSI. Así, la información debe facilitarse según lo establecido en el artículo 22.2. La información sobre cookies facilitada en el momento de solicitar el consentimiento del usuario, debe ser lo suficientemente completa para permitir que el usuario pueda entender la finalidad para las que se instalaron y conocer los usos que se les darán. 21 En caso de que el usuario preste su consentimiento para el uso de cookies, la información sobre cómo revocar este consentimiento y la posibilidad de eliminar las cookies deberá estar a su disposición de forma accesible y permanente. SweetRunner no usará cookies propias pero si de terceros, Al subir la aplicación a la Google Play Store se debe asumir el uso de cookies de terceros. 5.4 LICENCIAS En este apartado se va a detallar las licencias que están implicadas en el desarrollo del proyecto. 5.4.1 LICENCIA PÚBLICA GENERAL (GNU LPG) La licencia Pública General de GNU o General Public License (GNU GPL en inglés) fue creada por Richard Stallman, fundador de la Software Foundation (FSF) para el proyecto GNU. Se encarga de garantizar a los usuarios finales (personas, organizaciones, compañías) la libertad de usar, estudiar, compartir (copiar) y modificar el software. Con el objetivo declarar que el software que esté bajo esta licencia es software libre y protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios. Están bajo esta licencia GIMP, Inkscape, Audacity y Android. 5.4.2 LICENCIA PÚBLICA GENERAL REDUCIDA (GNU LGPL) Al igual que la GNU GPL, la Licencia Pública General Reducida de GNU o Lesser General Public License (en inglés), fue creada por la Free Software Foundation. Esta licencia pretende garantizar la libertad de compartir y modificar el software que está bajo ella, asegurando que el software es libre para todos sus usuarios. Ahora bien, la principal diferencia con la GPL es que la LGPL puede enlazarse a (en el caso de una biblioteca, 'ser utilizada por') un programa no-GPL, que puede ser software libre o software no libre. Así pues la GNU LGPL versión 3 se presenta como un conjunto de permisos añadidos a la GNU GPL. 22 Bajo esta licencia se encuentran el anteriormente citado Inkscape y el presente trabajo de final de título. 5.4.3 APACHE 2.0 La licencia Apache (en inglés, Apache License o Apache Software License para versiones anteriores a 2.0) es una licencia de software libre creada por la Apache Software Foundation (ASF). Esta licencia requiere la conservación del aviso de copyright y el disclaimer, pero no es una licencia copyleft, ya que no requiere la redistribución del código fuente cuando se distribuyen versiones modificadas. Apache concede al usuario del software la libertad de usarlo para cualquier propósito, distribuirlo, modificarlo, y distribuir versiones modificadas de ese software. A diferencia de las licencias anteriores, Apache no exige que las obras derivadas del software se distribuyan usando la misma licencia, ni siquiera que se tengan que distribuir como software libre. Así Apache sólo exige que se mantenga una noticia que informe a los receptores que en la distribución se ha usado código con la Licencia Apache. El software que se encuentra bajo esta licencia es Android. 5.4.4 CREATIVE COMMONS (CC) Creative Commons es una organización sin ánimos de lucro que permite usar y compartir tanto la creatividad como el conocimiento por medio de varios instrumentos jurídicos que son de carácter gratuito. CC, se encuentra al frente del movimiento copyleft, que pretende construir una alternativa al copyright “todos los derechos reservados”. Los citados instrumentos jurídicos no son más que un conjunto de licencias de derechos de autor, licencias Creative Commons, que permiten al autor de una obra otorgar permiso al público en general de compartir y usar su trabajo creativo bajo los términos y condiciones que él escoja. Los términos de cada licencia dependen de cuatro condiciones: atribución; no comercial; no derivadas; compartir igual. Con estas cuatro condiciones se obtienen 23 las siguientes licencias: Atribución; Atribución-CompartirIgual; AtribuciónNoDerivadas; Atribución-NoComercial; Atribución-NoComercial-CompartirIgual; Atribución-NoComercial-NoDerivadas. Bajo esta licencia se encuentran los sonidos que se descargaron para la incorporación en SweetRunner. 24 6 REQUISITOS Los requisitos empleados para el desarrollo de SweetRuner, se describirán detalladamente en los apartados Hardware y Software respectivamente: 6.1 HARDWARE  Ordenador portátil personal. Como se mencionó en el capítulo Pliego de Condiciones, se ha empleado un Lenovo B590 y no es necesario que el equipo tenga características especiales, basta que posea la capacidad de ejecutar Inkscape y Unity3D.  Dispositivo móvil Smartphone para testear la aplicación. Se requiere que posea sistema Android a partir de la versión 3.0 (Honeycomb). El Smartphone que se ha utilizado es un Primux Tech alpha 3x.  Dispositivo móvil Tablet para testeo de la aplicación. Es necesario que esté basado en sistema Android igual o superior a la versión Honeycomb. El Tablet empleado en este TFT fue un Samsung GTP5110. 6.2 SOFTWARE  Unity3D Pro. Versión 4.5.1.  Monodevelop. Se trata de un entorno de programación propio de Unity3D que soporta varios lenguajes de programación: C#, JavaScript y Boo.  Eclipse.  SDK de Facebook para Android.  Inkscape. Como se ha mencionado antes, se ha empleado en la creación de elementos gráficos vectoriales, la versión empleada fue la 0.48.5 que es una versión estable.  GIMP. También ha sido empleado en la realización los elementos gráficos, la versión que se usó es la 2.8.14. 31 8.1.6 CÁMARA La cámara es la encargada de renderizar el resultado de la escena de juego en la pantalla. Al crear una nueva escena, Unity siempre incorpora una cámara en ella por defecto. Cabe añadir que se pueden añadir varias cámaras a una escena. Además, las cámaras no sólo sirven para el renderizado de la escena, pueden usarse para simular cámaras de videovigilancia, para simular retrovisores, para crear juegos para varios jugadores (pantalla partida), entre otros. La cámara, es un componente más que se agrega a los GameObjects. Sin embargo, puede contener una colección diferente de componentes, otorgando funciones adicionales a los GameObjects. En la imagen 4 se pueden apreciar los elementos de la cámara principal (main camera). Imagen 4: Elementos de la Cámara. 32 8.2 FUNCIONES PROPIAS Unity posee algunas funciones propias que son sobreescribibles, es decir permiten que el usuario defina su contenido. Respecto a estas funciones, Unity tiene un orden de ejecución, se puede decir que es el cuándo y nosotros desarrollaremos el qué y el cómo. Para entender mejor lo mencionado anteriormente, se hablará del orden en el que Unity inicializa los distintos elementos que lo componen cada vez que se carga una escena del juego. De este modo, lo primero que se carga son los Game Object y componentes, seguidamente se cargan los scripts que van vinculados a estos Game Object, y finalmente se llaman una serie de funciones en un orden específico (Awake, Satart, Update / FixedUpdate y LateUpdate). A continuación se dará una breve descripción de las funciones que se han empleado en el TFT. 8.2.1 AWAKE Al cargarse la escena cuando se inicia el script, la función Awake es llamada. Esta función es útil para iniciar variables o estados del juego antes de que éste empiece. Hay que tener en cuenta que Awake será llamada aunque en el inspector la instancia del script esté deshabilitada. Además, no puede formar parte de una corrutina. 8.2.2 START Start es llamada justo después de Awake, se diferencia de esta última en que es llamada si la instancia del script está habilitada en el inspector. 33 8.2.3 UPDATE Esta función es llamada cada frame, al igual que Start siempre y cuando la instancia del script esté activa. Es la función más usada en los scripts pese a que cada ordenador puede tener un framerate distinto. 8.2.4 FIXEDUPDATE FixedUpdate, a diferencia de Update, se ejecuta cada cierto número fijo de frames. Es recomendable utilizarla cuando se hagan implicaciones de físicas y cuando se utilice un Rigibody. 34 9 ANÁLISIS DEL PROBLEMA Como se mencionó anteriormente, en el capítulo de aportaciones, el planteamiento del proyecto fue pensando en generar un análisis de las distintas herramientas que se usan para el desarrollo de un juego de plataforma estilo runner. Así pues, hablaremos del motivo por el cual se ha escogido cada una de ellas, sus ventajas, desventajas y los beneficios que ha aportado al proyecto. A la hora de plantearnos el desarrollo de un juego de este tipo surgen muchas incógnitas como, que motor de videojuego usar, que herramientas emplear para crear los gráficos y el sonido, que lenguaje de programación es el más adecuado, entre muchas otras. A continuación daremos respuesta a estas cuestiones. 9.1 UNITY3D Unity3D es un motor de videojuegos multiplataforma muy versátil, permite publicar o buildear para PC, en los sistemas operativos: Windows, Linux e IOS; para dispositivos móviles: Android, iPad, iPhone y Windows Phone; y para consolas de juegos: Xbox 360, PlayStation 3, PlayStation Vita, Wii, Wii U, entre otras. Además permite el buildeo en Web, haciendo uso de un complemento llamado Unity Web Player que es gratuito. Esta herramienta creada por Unity Technologies cuenta con dos tipos de licencia, una es gratuita aunque posee ciertas limitaciones y otra llamada Unity-Pro que es pagada. En la actualidad se encuentra disponible para el desarrollo en los sistemas operativos Windows, Mac IOS. Es importante recalcar que Unity posee un editor propio, Monodevelop, que soporta los lenguajes JavaScript, C# y Boo. Además posee un editor visual muy intuitivo lo que facilita el trabajo con los elementos visuales y en donde se puede observar la ejecución del programa. La creación de los ejecutables para cada una de las distribuciones es bastante sencilla, basta con elegir el sistema operativo y la arquitectura. 35 Finalmente, Unity cuenta con una interfaz que puede ser modificada de acuerdo a las necesidades del usuario, esta interfaz posee 5 elementos o vistas como se puede observar en la Imagen 5: La vista de Escena (color azul) permite construir la parte visual de la aplicación, se pueden posicionar objetos importados, rotarlos, escalarlos y moverlos. La vista de Juego (color rosa) posibilita previsualizar lo creado en la vista de Escena, permitiendo ejecutar la aplicación que está desarrollándose para probar su funcionamiento. En la vista de Proyecto (color marrón) se encuentran todos los assets del proyecto, normalmente ordenados en carpetas. Es precisamente aquí donde se importan o crean los elementas de la escena, tales como objetos, texturas, scripts, Imagen 5: Interfaz de Unity3D. 36 entre otros. El manejo de estos elementos es muy sencillo, basta con arrastrarlos en la escena. La vista de Jerarquía (color verde) contiene los objetos que se encuentran en un momento dado en la escena. Gracias a esta vista resulta sencillo encontrar todos los elementos de la escena, sin la necesidad de moverse por ella. Por último el elemento Inspector (color olivo), en él se encontrará toda la información detallada de los assets de la escena. En resumen, las principales características que posee Unity3D son las siguientes:  Software gratuito en su versión básica.  Disponible para Windows y Mac OS.  Espacio de trabajo intuitivo y muy sencillo, de fácil manejo y con opciones para ejecutar, editar y probar la aplicación que se está desarrollando.  Alta calidad visual y de sonido, permite mezclar en tiempo real gráficos, tanto 2D como 3D, y audio.  Poderoso sistema de animación que permite fluidez en las escenas.  Multiplataforma, permite publicar o buildear en varios sistemas de manera sencilla.  Soporta assets que pueden exportarse desde múltiples herramientas de modelado y se importan automáticamente.  Manejo de un solo editor en tiempo real.  Sistema de partículas en tiempo real.  Manejo de inteligencia artificial.  Iluminación dinámica en alta velocidad.  Procesador de alta velocidad.  Se puede encontrar gran cantidad de documentación.  Cuenta con una amplia comunidad que brinda soporte. 37 En síntesis, Se ha optado por usar Unity3D por todo lo descrito anteriormente pese a que en el mercado se encuentran diversos motores de videojuegos igual de válidos. Sin embargo, Unity sigue siento el mejor a la hora de generar juegos en 2D y 3D para móviles. Otra de las razones definitivas fue su interfaz que es mucho más amigable e intuitiva, bajo mi punto de vista basado en la experiencia, que la de otros. 9.2 C# Al hablar del lenguaje de programación escogido es necesario tomar en cuenta que Unity soporta, como ha mencionado en capítulos pasados, JavaScript, C# y Boo. C#, es un lenguaje de programación orientado a objetos un poco menos flexible que JavaScript pero nos permite manipular mayor cantidad de datos. Se trata de un lenguaje un poco más estricto que JavaScript, al ser más preciso es necesario escribir todos los tipos de variables y funciones dejando poco margen de error. Finalmente, cabe añadir que nos da mayor acceso al System tolos, nos permite comunicarnos con cosas externas a Unity. Estas son las razones por las que se ha optado por este lenguaje. 9.3 MONODEVELOP MonoDevelop es un entorno de desarrollo gratuito y libre, se encuentra bajo la licencia GNU GPL. Está diseñado para soportar principalmente los lenguajes C#, JavaScript y Boo. En la actualidad esta herramienta es multiplataforma, puede ser usada en GNU/Linux, Windows y Mac. Además, es el entorno de desarrollo propio de Unity3D con lo cual se pude comprobar inmediatamente lo que vamos realizando. Al escribir un script, basta con asignarle a un Game Object para ejecutarlo desde la Vista de Juego de Unity y 38 observar todo lo que se va realizando. Se puede abrir Monodevelop desde la Vista de Proyecto de Unity, basta con dar doble clic sobre el script que se desea abrir. A continuación, en la imagen 6 se puede observar el entorno de desarrollo Monodevelop. 9.4 INKSCAPE Inkscape es un editor de gráficos vectoriales de código abierto, se distribuye bajo la licencia GNU. Además, es un software gratuito. Algo que vuelve a Inkscape único es que el formato nativo que usa es el Scalable Vector Graphics (SVG), que es un estándar abierto de W3C basado en XML. Pese a que este software se encuentra desarrollado principalmente para el sistema GNU/Linux, es una herramienta multiplataforma que puede ser empleada en Windows, Mac OS X y otros sistemas derivados de Unix. Imagen 6: Entorno de Desarrollo Monodevelop. 39 En cuanto a sus características, Inkscape es una herramienta de dibujo bastante potente y muy sencilla de usar, es totalmente compatible con los estándares XML, SVG y CSS. Además, posee una comunidad bastante amplia. Por todo lo mencionado anteriormente es que se decidió escoger Inckscape. 9.5 GIMP GIMP (GNU Image Manipulation Program), es un programa de edición de imágenes digitales, tanto dibujos como fotografías, en forma de mapa de bits. Es un software gratuito y libre, es parte del proyecto GNU y se encuentra bajo las licencias GPL y LGPL. Imagen 7: Interfaz de Inkscape. 40 GIMP permite el tratado de imágenes por capas, esto permite que cada objeto de la imagen pueda ser tratado de forma totalmente independiente. Soporta los formatos JPG, GIF, PNG, PCX, TIFF, la mayoría de psd y además posee su propio formato abierto, XCF. Es preciso añadir que permite importar imágenes vectoriales en formato SVG. La interfaz de esta herramienta está disponible en varios idiomas. Además, es multiplataforma está disponible para los sistemas operativos Unix, GNU/Linux, FreeBSD, Solaris, Windows, Mac OS X, entre otros. La razón principal por la que se decide usar GIMP para el desarrollo del TFT es por la gran compatibilidad que presenta con el resto de herramientas con las que se trabaja. Como se mencionó anteriormente, permite importar imágenes en formato SVG, que pueden ser creadas por Inkscape. Así mismo, recordemos que permite generar extensión PSD, que es compatible con Unity3D. Esta compatibilidad facilita mucho el trabajo puesto que se pueden realizar cambios desde GIMP que se cargarán automáticamente en el entorno gráfico de Unity. En la siguiente imagen se muestra el entorno de GIMP. Imagen 8: Interfaz de GIMP 47 10.1.3 GENERACIÓN ALEATORIA Un juego de este estilo debe tener gran cantidad de niveles y muy extensos para que no se vuelva monótono, en vez de ello se optó por crear de forma aleatoria e infinita el entorno, el terreno, los objetos y las bonificaciones. Con esto se satisfizo la siguiente historia de usuario:  Como usuario de la aplicación quiero un juego que no sea monótono para que no se convierta en algo aburrido. Para lograr esta mejora hizo falta desarrollar un sistema de reutilización de elementos. Para ello, se crean una cantidad predefinida de elementos en pantalla con los componentes de terreno y vacíos, estos elementos se crearán y destruirán sin sobrepasar ni ser inferiores al número que se definió con antelación. Este proceso se repetirá tantas veces sea necesario mientras el juego esté en funcionamiento. El desarrollo de la generación aleatoria de elementos se realizó en el script levelCreator. 10.1.3.1 Nivel extenso Vs Aleatoriedad infinita A continuación, se explicarán las razones por la que se escogió el sistema descrito anteriormente para satisfacer la historia de usuario correspondiente a esta mejora. Imagen 12: Ejecución del juego con obstáculos y bonificaciones. 48 10.1.3.1.1 Siempre nuevo Al crear un nivel muy extenso puede que las primeras veces no se monótono. Pero sin duda, tras jugar muchas veces llegará un punto en el que ya sabremos exactamente dónde van los obstáculos, cuando aparecen las bonificaciones y como es el terreno o las plataformas, convirtiéndolo inevitablemente, tarde o temprano, en un juego aburrido. Al desarrollar un juego aleatorio e infinito se rompe con las problemáticas citadas anteriormente, se tendrá al jugador en expectativa para sortear los obstáculos, coger las bonificaciones y moverse por las diferentes plataformas o terrenos que se van creando. 10.1.3.1.2 Rendimiento y Ralentización Es inevitable hablar de rendimiento y ralentización a la hora de debatir entre nivel extenso y aleatoriedad infinita. Desarrollar un juego con niveles extensos implica que las plataformas o terrenos, enemigos, bonus y entorno deben ser creados en su totalidad y almacenados para poder jugar. Al realizar la tarea de este modo, todo se almacena en memoria y deberá ser llamado en su totalidad. Así por ejemplo, si tenemos un nivel con unas 70 plataformas de diferentes tamaños, 120 obstáculos, 20 bonusBox, 200 pastelitos de diferentes tamaños y el cielo. Todos estos elementos se almacenan en memoria y se realizan 411 llamadas para lograr recrear las imágenes. En nuestro caso en particular, se creó un nivel no tan extenso como el descrito anteriormente, y al realizar las pruebas en los dispositivos móviles nos encontramos con que había ralentización en la creación de las imágenes y el objeto móvil principal tenía lag. Si bien este tipo de juegos presenta los problemas que se describieron antes, también hay algunas maneras de solucionarlos. En este caso en particular, y dado que se debe tener en cuenta la jugabilidad requerida por el usuario, se optó por la solución de la Aleatoriedad. 49 Al escoger esta opción, los problemas de rendimiento que se presentaban anteriormente se solventan. Al generar un número predefinido de elementos en pantalla, que son construidos y destruidos tantas veces sea necesario, lo único que se llamará serán esos elementos. 10.1.3.2 Pruebas y Problemas Solventados Para satisfacer la historia de usuario concerniente a esta mejora, se comprobó el correcto funcionamiento de lo descrito anteriormente en los dispositivos móviles. Como se mencionó en el apartado anterior, al realizar las primeras pruebas se encontró algunos problemas que se solventaron haciendo un mejor uso de los recursos. En la imagen 13 se puede apreciar la mejora implementada: . 10.1.4 ELEMENTOS GRÁFICOS En esta mejora se incorporan los elementos gráficos que serán parte de SweetRunner. En la Imagen 14 se muestran los elementos gráficos que fueron introducidos: Imagen 13: Generación aleatoria de elementos. 50 Lo primero que se realizó fue ir cargando uno a uno los gráficos y se les dio el valor de Sprite Texture, tal y como se realizó la primera vez al desarrollar el prototipo inicial. 10.1.4.1 Rendimiento Al realizar la integración de imágenes como se describe anteriormente, se pudo notar que el rendimiento de la CPU resultó seriamente penalizado. Este fenómeno se produce porque se llaman una a una cada isla o sprite. La GPU no presentó perdidas en rendimiento. Para evitar la penalización en rendimiento, se optó por juntar todas las imágenes en 2 atlas:  Atlas 1: Terreno o plataforma, background y personaje.  Atlas 2: bonusBox y obstáculos Se emplearon dos atlas atendiendo a las propiedades de sus islas, la bonusBox y los obstáculos poseerán efectos posteriormente. Una vez conformados los atlas, se notó que el rendimiento de la CPU mejoró notablemente, el rendimiento fue superior al que tenía cuando se trabajaba con las imágenes del prototipo inicial. Imagen 14: Gráficas del Juego. 51 Esta mejora tan significativa se debe a que al tener solo dos atlas, se aligeró el coste de trabajo producido por la CPU ya que ahora tan solo deberá realizar dos llamadas. 10.1.4.2 Luces Es imprescindible la incorporación de luces en el escenario dado que éstas también generan efectos como sombras, y contorneados. En este caso se utilizó una luz para iluminar, y con ello hacer visible, el plano posterior azul. 10.1.4.3 Pruebas Al realizar pruebas en los dispositivos móviles se notó que había ralentización del proceso de llamadas gráficas. El problema se solventó como se describe en el apartado anterior, rendimiento. Las pruebas finales se realizaron en los dispositivos móviles y esta vez se realizó un número elevado de pruebas, con el fin de detectar cualquier problema de elementos no eliminados. Una vez más las pruebas se superaron satisfactoriamente. 10.1.4.4 Programación Vs Facilidades de Unity Empezaremos hablando de algunas de las facilidades que nos proporciona Unity. Con el fin de ahorrar tiempo Unity brinda algunas facilidades, con sus diversos componentes. Como por ejemplo, los componentes de físicas, que aparte de emular bastante bien la realidad son totalmente manipulables y realmente flexibles. También permite integrar colisiones con los componentes de colisiones, al igual que las físicas también se pueden manipular. Además de esas facilidades, Unity también permite la programación de estos componentes. Es decir, permite que un desarrollador que programe sus propias físicas, colisiones, luces, entre otros. En algunos casos es mejor programar diversos elementos y en otros emplear los componentes proporcionados, no hay un estándar que especifique nada de esto, 52 todo va depender del proyecto que se esté desarrollando, su tamaño, las necesidades que se presenten, entre otros. En el caso del presente TFT se emplearon unos pocos componentes de los que ofrece Unity. Se empleó la luz, los componentes de sonido, y el sistema de partículas y colisionadores. Sin embargo se desarrollaron otros componentes como físicas, movilidad del personaje, avance de cámara, entre otros. 10.1.5 INTEGRACIÓN DE PUNTUACIÓN Esta mejora tiene el fin de satisfacer las siguientes historias de usuario:  Como jugador de SweetRunner quiero saber mis logros para así saber mi evolución en el juego.  Como jugador de SweetRunner quiero saber cuáles han sido mis mayores logros saber mi record. Para solventar estás historias de usuario se creó un sistema de puntuación que se incrementa a medida que avanzamos en el juego. El sistema de puntuación se desarrolló en el fichero “scoreHandler” además recibe información de “levelCrator” y bonusBox. El score o puntuación ha sido cifrado con MD5 para asegurarnos que no es susceptible de ser modificado manualmente. En pantalla se muestran dos puntuaciones, en el lado Izquierdo superior, la puntuación que vamos acumulando a medida que avanza el juego, y en la parte superior derecha la puntuación más alta o High Score. 10.1.5.1 Puntuación BonusBox Una mejora añadida, o cambio realizado, fue en la bonusBox. Se decidió cambiar la bonificación recibida al tomar el color verde, ahora en lugar de aumentar la velocidad incrementará la puntuación en 10 puntos. Esta mejora se realizó con el fin de volver más tentadora la idea de coger la bonusBox, ya que al juagar SweetRunner nos percatamos que muchas veces se 53 dejaban de lado las bonificaciones pues no había un incentivo lo suficientemente fuerte como para asumir el riesgo de cogerlas. En la imagen 15 se observa la mejora incorporada. 10.1.6 GUI Esta mejora se corresponde con la Interfaz Gráfica de Usuario. Se ha desarrollado una interfaz gráfica que nos permite mostrar de manera más vistosa la puntuación máxima que el usuario ha acumulado. Al realizar las pruebas se presentó una problemática. Al ejecutarse en el dispositivo móvil tablet no hubo ningún problema. Sin embargo, al probarlo en un Smartphone el texto e imágenes de la GUI perdieron la posición en la que debían estar. El trabajo con las GUI por lo general representa un reto y es que el diseño se debe adaptar a diferentes resoluciones. Es decir, se debe lograr que la GUI sea responsive o adaptativa. Para conseguir la adaptabilidad se debe hacer uso de valores dinámicos, se trabaja en base al tamaño de la pantalla en la que se esté ejecutando el juego: Imagen 15: Incorporación de la Puntuación. 54 En la siguiente imagen se podrá apreciar las mejoras Integración de GUI de puntuación máxima. 10.1.7 EFECTOS Esta mejora se trata de introducir ciertos efectos gráficos en el juego para volverlo más vistoso. La mayor parte de juegos emplean estos efectos para otorgarle un realce gráfico pues realmente se gana mucho, se puede trabajar en base a detalles y la mejor forma es con sistemas de partículas. 10.1.7.1 Sistemas de Partículas Los efectos se crean, como se mencionó anteriormente, con sistemas de partículas. Unity ofrece dos sistemas de partículas, Legacy y Shuriken, con los que se puede crear una gran variedad de efectos. Imagen 16: GUI de Puntuación. 55 Estos sistemas vienen predefinidos en cuanto a la cantidad de variaciones que se pueden realizar, lo que quiere decir que no se puede realizar cualquier tipo de efecto. Posee limitaciones. En el caso del presente proyecto, se decidió incorporar el sistema de partículas Shuriken para los obstáculos empleados, concretamente para hacer las flamas de las velas, que son los obstáculos del juego. 10.1.7.2 Rendimiento y Ralentización Tras realizar pruebas sobre los nuevos componentes agregados, se apreció un nuevo cambio significativo en cuanto a rendimiento. Las aparición de imágenes se ralentizó y los movimientos dejaron de ser fluidos.. Al empezar a trabajar con partículas, se hizo uso de gran cantidad de efectos sin tomar en cuenta la penalización que estos podrían generar. En realidad, nunca se midió el desgaste de memoria que se estaba generando. Con el fin de solventar el problema de rendimiento descrito, se tuvo que llegar a un consenso entre rendimiento y funcionalidad. De esta forma, se manipulo la herramienta de partículas tomando en cuenta que cada partícula emitida se puede considerar un sprite. Se ajustó el número de partículas que se deben emitir y se habilitaron funciones que ayudaron al efecto como cambios de colores de las flamas por tiempo de vida, con esta función se evitó el uso de 2 sistemas de partículas (uno de color rojo para la parte baja de la flama y uno de color amarillo para la parte alta). El efecto se replicó para las otras dos velas, empleándose color amarillo y verde para la vela amarilla, rojo y amarillo para la vela rosa, y azul y amarillo para le vela azul. Como se puede observar en la imagen 17. 56 Gracias a lo descrito anteriormente, se pasó de tener una emisión de 1000 partículas a tener una emisión de 10. Se les agregó un ciclo de vida, con el propósito de poder lograr que desaparezcan, con el fin de evitar que las partículas estén siempre cargadas en memoria. Por último, se empleó la creación elementos prefabricados de este estilo. 10.1.8 REDES SOCIALES La incorporación de redes sociales a SweetRuner se hizo para satisfacer las historias de usuario siguientes:  Como jugador de SweetRunner, quiero poder mostrar a mis amigos la puntuación máxima que he obtenido para que vean mis logros.  Como jugador de SweetRunner, quiero poder mostrar la puntuación que obtengo en Facebook para poder etiquetar y realizar comentarios con la gente. Imagen 17: Sistema de Partículas Shuriken con sus valores en tiempo real. 63 13 FUENTES DE INFORMACIÓN [1] Juegos plataforma. http://es.wikipedia.org/wiki/Videojuego_de_plataformas [2] Historia de los videojuegos para móviles. http://en.wikipedia.org/wiki/Mobile_game [3] Página oficial de Android. http://www.android.com/ [4] Historia y versiones de Android. http://androidos.readthedocs.org/en/latest/ [5] Página de desarrolladores de Andorid. http://android-developers.blogspot.in/ [6] Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal. http://www.boe.es/buscar/doc.php?id=BOE-A-1999-23750 [7] Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico. https://www.boe.es/buscar/act.php?id=BOE-A-200213758&b=34&tn=1&p=20140510#a22 [8] Normativa de Cookies. https://www.agpd.es/portalwebAGPD/canaldocumentacion/publicaciones/c ommon/Guias/Guia_Cookies.pdf [9] Licencia Pública General (GNU LPG). http://www.gnu.org/copyleft/gpl.html [10] Licencia Pública General Reducida (GNU LGPL). 64 https://www.gnu.org/licenses/lgpl.html [11] Licencia Apache 2.0. http://es.wikipedia.org/wiki/Apache_License [12] Condiciones del servicio de Google Play. https://play.google.com/intl/es-419_us/about/play-terms.html [13] Proceso Unificado. http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational [14] Manifiesto ágil. http://agilemanifesto.org/iso/es/ [15] Metodología de desarrollo ágil Scrum. https://www.scrum.org/ [16] Manual oficial de Unity. http://docs.unity3d.com/Manual/index.html [17] Página oficial de Unity. https://unity3d.com/ [18] Guía de programación de C#. http://msdn.microsoft.com/es-es/library/67ef8sbd.aspx [19] Página oficial de Monodevelop. http://www.monodevelop.com/ [20] Página oficial de Inkscape. https://inkscape.org/es/ [21] Página oficial de GIMP. http://www.gimp.org/ 65 [22] Página oficial de Audacity. http://audacity.sourceforge.net/?lang=en [23] Página de Descarga de Sonido Gratuito. https://www.freesound.org// [24] API Facebook. https://developers.facebook.com/docs/android?locale=es_ES [25] Página oficial de Eclipse. https://eclipse.org/