sergio andres osma aponte uni
Transcripción
sergio andres osma aponte uni
ANÁLISIS, DISEÑO Y DESARROLLO DEL PRODUCTO MÍNIMO VIABLE PARA EL VIDEOJUEGO “MAGIC CAVE” SERGIO ANDRES OSMA APONTE UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTÁ 2015 1 ANÁLISIS, DISEÑO Y DESARROLLO DEL PRODUCTO MÍNIMO VIABLE PARA EL VIDEOJUEGO “MAGIC CAVE” SERGIO ANDRES OSMA APONTE CÓDIGO: 20072020058 MODALIDAD PASANTIA PROYECTO JOHN FREDY PARRA DIRECTOR INTERNO HUGO ORLANDO URUEÑA NARANJO DIRECTOR EXTERNO UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS BOGOTÁ 2015 2 CONTENIDO 1. Introducción .................................................................................................................................8 2 Planteamiento del problema .................................................................................................... 10 2.1 Descripción del problema .................................................................................................. 10 2.2 Formulación del problema ................................................................................................. 10 3 Justificación ............................................................................................................................... 11 4 Objetivos ................................................................................................................................... 12 5 4.1 Objetivo general................................................................................................................. 12 4.2 Objetivos específicos ......................................................................................................... 12 Delimitación .............................................................................................................................. 13 5.1 Alcances ............................................................................................................................. 13 5.2 Limitaciones ....................................................................................................................... 13 6 Factores diferenciantes o de valor agregado............................................................................ 15 7 Antecedentes o Estado del arte ................................................................................................ 16 8 7.1.1 Milky y Mr.Spots ....................................................................................................... 16 7.1.2 IGDA .......................................................................................................................... 17 7.1.3 Colombia Games ....................................................................................................... 17 7.1.4 Efecto Studio ............................................................................................................. 18 7.1.5 Rovio ......................................................................................................................... 18 Marco teórico............................................................................................................................ 20 8.1 Producto Mínimo Viable (PMV) ......................................................................................... 20 8.2 Videojuego ......................................................................................................................... 20 8.3 Metodología SCRUM .......................................................................................................... 21 3 8.4 Sprint .................................................................................................................................. 22 8.5 Roles SCRUM ...................................................................................................................... 22 8.5.1 Roles Principales ....................................................................................................... 22 8.5.2 Roles Auxiliares ......................................................................................................... 23 8.6 9 Documentos ....................................................................................................................... 23 8.6.1 Product backlog ........................................................................................................ 23 8.6.2 Sprint backlog............................................................................................................ 23 8.6.3 Burn down chart ....................................................................................................... 24 8.7 Historias de Usuario ........................................................................................................... 24 8.8 Motor de videojuego (GameEngine).................................................................................. 24 8.9 Unity 3D ............................................................................................................................. 25 8.10 Programación Orientada a Objetos ................................................................................... 25 8.11 Programación Orientada a Componentes ......................................................................... 25 8.12 Lenguaje de programación C# ........................................................................................... 26 8.13 Lenguaje de programación JavaScript (JS) ......................................................................... 26 8.14 XML .................................................................................................................................... 27 Metodología de desarrollo del proyecto .................................................................................. 28 9.1 Tipo de estudio .................................................................................................................. 28 9.2 Metodología del proyecto ................................................................................................. 28 9.3 Descripción de la metodología en contexto ...................................................................... 28 9.3.1 Datos técnicos ........................................................................................................... 29 4 9.3.2 Medios de apoyo para SCRUM: ................................................................................ 29 9.4 Participantes ...................................................................................................................... 31 9.5 Instrumentos y equipo ....................................................................................................... 32 9.6 Herramientas utilizadas ..................................................................................................... 32 9.6.1 Software .................................................................................................................... 32 9.6.2 Hardware................................................................................................................... 33 9.6.3 Talento humano: ....................................................................................................... 33 10 Resultados obtenidos............................................................................................................ 34 11 Cronograma .......................................................................................................................... 35 12 Presupuesto .......................................................................................................................... 38 13 Análisis del sistema ............................................................................................................... 40 13.1 Ficha Técnica del videojuego ............................................................................................. 40 13.2 Requerimientos .................................................................................................................. 40 Computador .............................................................................................................................. 40 iOS ............................................................................................................................................. 40 Android ..................................................................................................................................... 41 13.3 Diagramas UML .................................................................................................................. 41 13.3.1 Diagrama de casos de uso ......................................................................................... 41 13.3.2 Diagrama de componentes ....................................................................................... 50 13.3.3 Diagrama de actividades ........................................................................................... 53 13.4 Principales módulos del software ...................................................................................... 56 13.4.1 Diseño de IA .............................................................................................................. 56 13.4.2 Algoritmo de búsqueda............................................................................................. 59 13.4.3 Sistema patrulla ........................................................................................................ 60 13.4.4 Indicadores de estado ............................................................................................... 61 5 13.4.5 13.5 Sistema de carga y guardado de niveles ................................................................... 61 Interfaz de juego ................................................................................................................ 62 13.5.1 Diagrama de flujo de Interfaz ................................................................................... 62 13.5.2 Interfaz del juego ...................................................................................................... 63 13.5.3 Menú principal .......................................................................................................... 65 13.5.4 Menú de opciones..................................................................................................... 65 13.5.5 Menú de selección de niveles ................................................................................... 66 13.5.6 Menú de creación de niveles .................................................................................... 66 14 Bibliografía ............................................................................................................................ 67 15 Cibergrafía ............................................................................................................................. 69 16 Anexos ................................................................................................................................... 70 Anexo A .......................................................................................................................................... 70 Historias de usuario .................................................................................................................. 70 Anexo B .......................................................................................................................................... 70 Sprint Backlog ........................................................................................................................... 70 16.1.1 Sprint 1 ...................................................................................................................... 70 16.1.2 Sprint 2 ...................................................................................................................... 71 16.1.3 Sprint 3 ...................................................................................................................... 71 16.1.4 Sprint 4 ...................................................................................................................... 71 16.1.5 Sprint 5 ...................................................................................................................... 72 16.1.6 Sprint 6 ...................................................................................................................... 72 16.1.7 Sprint 7 ...................................................................................................................... 73 16.1.8 Sprint 8 ...................................................................................................................... 73 16.1.9 Sprint 9 ...................................................................................................................... 73 16.1.10 Sprint 10 ................................................................................................................ 74 16.1.11 Sprint 11 ................................................................................................................ 74 16.1.12 Sprint 12 ................................................................................................................ 75 6 Anexo C .......................................................................................................................................... 76 Diseño de niveles ...................................................................................................................... 76 7 1. INTRODUCCIÓN Los videojuegos hoy en día tienen una gran importancia en la cultura del ocio y el entretenimiento, esto los ha convertido en una industria de gran crecimiento y de difusión masiva, logrando obtener ingresos similares y en algunos casos superiores a la industria del cine y la música. Se han convertido en uno de los productos más demandados por la sociedad actual, convirtiéndose en la base del ocio digital, ya que poseen características que los sitúan como herramientas con un gran potencial comunicador y un medio idóneo para expresar ideas, contar historias, generar emociones y sentimientos en los usuarios, convirtiéndose así en una forma de arte. Los grandes avances tecnológicos han permitido mayor calidad a precios mucho menores, y la gran oferta de dispositivos electrónicos constituyen una plataforma ideal para un crecimiento acelerado y un alcance masivo de los productos de entretenimiento. Es por esto, que el gobierno de Colombia, representado por el Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC) ha creado estrategias para fomentar el desarrollo y distribución de contenidos digitales, y en especial de videojuegos, creando nuevas oportunidades para las empresas Colombianas e impulsando el desarrollo de este sector cada vez más. En 2012 el Ministerio TIC y el ministerio de cultura firman una alianza para incentivar la producción de videojuegos, denominada "Crea Digital", la cual brinda incentivos económicos a empresas que sean capaces de mostrar calidad e innovación en este sector. Por lo anterior, Atomic Studio SAS desea crear contenido de una mayor calidad y de más alcance, surgiendo así "Magic Cave" un videojuego de aventura y estrategia en tiempo real, pensado para mostrar las capacidades de la empresa y convertirse en el proyecto insignia de la misma, logrando con él una muestra de calidad, profesionalismo y competitividad de la empresa en el sector y con él, abrir nuevas 8 oportunidades de negocio y crecimiento, además de convertirse en patrimonio de investigación y experiencia vivencial para nuevos proyectos. 9 2 PLANTEAMIENTO DEL PROBLEMA 2.1 DESCRIPCIÓN DEL PROBLEMA Cada año, el negocio de los videojuegos mueve unos 700 billones de dólares, de los cuales 15 billones corresponden a aplicativos para dispositivos móviles como smartphones o tablets. 1 Estos datos reflejan la gran importancia que tienen los videojuegos como producto y las grandes posibilidades que el mercado globalizado ofrece. Actualmente Atomic Studio SAS no cuenta con un producto propio de difusión masiva que le permita incursionar de manera directa al mercado internacional y quiere aprender cómo se puede lograr. Para este fin es necesario el desarrollo de un videojuego propio, capaz de demostrar las habilidades, fortalezas y experiencia de la empresa, además de convertirse en la base de conocimientos y recursos para proyectos posteriores que proporcionen la experiencia necesaria para acortar los tiempos de elaboración. Se requiere que el producto cumpla con las características de un producto mínimo viable2, el cual está en capacidad de ser mostrado y usado como un producto final y que cumple con las características funcionales para ser ampliado o modificado en un producto nuevo. 2.2 FORMULACIÓN DEL PROBLEMA ¿Cómo se puede desarrollar un videojuego para dispositivos móviles que integre los estándares de calidad internacional para competir con el mercado global? 1 Datos tomados de la revista Forbes (Forbes, 10 de Agosto de 2013). El producto estará terminado por completo en los aspectos de diseño, ilustración, modelado 3D y programación. Al finalizar esta etapa se evaluará la mejor fecha para su publicación. 2 10 3 JUSTIFICACIÓN Dado el constante crecimiento de la industria tecnológica y de la importancia que ha adquirido el campo del ocio y el entretenimiento digital, Atomic Studio SAS valiéndose de su amplia experiencia local se propone incursionar de una manera más directa en el mercado y la industria global. "Magic Cave" surgirá como un producto ágil, efectivo y eficaz, tomando como base la experiencia adquirida con productos anteriores, permitiendo entrar con mayor fuerza a la industria y preparar a la empresa para alcanzar nuevos horizontes. Así pues el desarrollo de “Magic cave” resulta ser una oportunidad para adquirir nuevos conocimientos y experiencias, además que permite evaluar el comportamiento y tendencias del nuevo mercado. Por tanto este producto será más completo y complejo, logrando una mayor rentabilidad a través de la optimización en el proceso de producción sin perder el gran nivel de calidad que caracteriza a la empresa. 11 4 OBJETIVOS 4.1 OBJETIVO GENERAL Desarrollar un videojuego que cumpla con las características de un producto mínimo viable y que esté preparado para competir en el mercado internacional. 4.2 OBJETIVOS ESPECÍFICOS Desarrollar el sistema básico de juego, que permita mostrar las acciones y comportamientos del personaje. Programar la inteligencia artificial del juego para que supla las necesidades del proyecto, y que además pueda ser reutilizado en futuros desarrollos. Desarrollar un editor de niveles que pueda ser usado por el jugador. Definir los escenarios de pruebas que permitan validar la correspondencia de las funcionalidades con las del diseño de la aplicación. Generar la documentación del software siguiendo los lineamientos de la metodología SCRUM y de la empresa. 12 5 DELIMITACIÓN 5.1 ALCANCES El videojuego constituye un producto mínimo viable que tendrá un editor de niveles, una secuencia de introducción, una pantalla inicial con menú de configuraciones y de juego. Se implementaran las mecánicas de juego, los movimientos del personaje (jugador), sus habilidades y los diversos cambios que este sufre a través de la historia, además de los movimientos de los enemigos, sus habilidades y comportamiento. Se programará desde cero un sistema de inteligencia artificial (IA) basado en el algoritmo A* que incluirá: rutinas de búsqueda (algoritmos de optimización, búsqueda y rutas cortas), reconocimiento del entorno, rutinas de patrulla y diversos comportamientos de interacción con el jugador (atacar, huir, evadir, etc.). EL proyecto será desarrollado usando el motor de videojuego Unity3D, y su IDE Mono Develop usando los lenguajes de programación C# y JavaScript. El proyecto se realizará para las plataformas iOS y Android. La aplicación funcionará de forma local y no tendrá ningún modo de juego cooperativo ni multijugador. El producto será desarrollado usando la metodología SCRUM de acuerdo a las normas de la empresa. 5.2 LIMITACIONES La implementación se limitará a la codificación del videojuego y los plugins necesarios para que funcione en las plataformas mencionadas, además del uso e 13 integración de los recursos proporcionados por el resto del equipo (Ilustraciones, modelos 3D, iconos, audio, etc.). No podrá ser usada por más de un usuario a la vez en cada dispositivo. El tiempo límite para el desarrollo es de seis (6) meses. El juego no estará publicado en las tiendas de aplicaciones en esta etapa. La versión mínima de Android que será compatible con el producto es Gingerbread3 (Android 2.3.6). La mínima versión del sistema operativo de iPhone e iPad compatible será iOS 6. Dado el limitado hardware que poseen la mayoría de tabletas, los modelos utilizados no superaran los 5000 polígonos4 y las texturas estarán comprimidas. 3 GingerBread es la versión 2.3 de Android, lanzada en 2010 fue la versión que logro masificar este sistema operativo y la primera que soporta Unity3D. 4 En computación gráfica, un polígono se define como una serie de vértices que conforman un plano en el espacio 3D. Un polígono puede formarse hasta por uno o más triángulos. 14 6 FACTORES DIFERENCIANTES O DE VALOR AGREGADO El diseño e implementación de "Magic Cave" tendrá un enfoque modular y diseñado para ser reutilizable por otras aplicaciones, acogiéndose desde el inicio a los principios de la programación orientada a componentes, lo que permitirá que los desarrollos futuros sean más simples. Se creará un sistema de Inteligencia Artificial modularizado que incluya rutinas y comportamientos básicos para el personaje y enemigos, que se convertirá en una librería reutilizable y fácilmente extensible para ser reutilizado en futuros desarrollos. 15 7 ANTECEDENTES O ESTADO DEL ARTE En diciembre de 2009 sale al Mercado el videojuego “Angry Birds” que posee más de mil millones5 de descargas y que logro captar la atención del público en general abriendo el camino al uso masificado de este tipo de aplicaciones a nivel global. Cabe mencionar que este juego fue desarrollado por Rovio, empresa que dedico mucho tiempo a evaluar el comportamiento y gustos de los usuarios a través de sus anteriores aplicaciones, y con estos datos logró sacar al mercado un producto que gustó a más del 80% de los usuarios de Smartphone de la época. Actualmente la industria de los videojuegos supera en ingresos a la industria del cine, y dada la masificación de dispositivos móviles como Smart Phones y Tablets el número de posibles usuarios aumenta de forma rápida. Igualmente, la industria de los videojuegos en Colombia ha tenido un constante crecimiento, en los últimos años muchas compañías han surgido, fortaleciendo el mercado, promoviendo el desarrollo tecnológico y la inversión del sector público y privado, impulsando así la industria local, demostrando altos niveles de calidad y competitividad. Atomic Studio SAS es una empresa que se dedica al desarrollo de aplicaciones interactivas, y en especial de videojuegos, su principal campo de acción es el desarrollo de videojuegos con un enfoque educativo, trabajando con empresas como Mi Señal TV (Señal Colombia) y el Ministerio de Cultura realizando proyectos a la medida de sus necesidades. 7.1.1 Milky y Mr.Spots "Milky" o en español “Leches” es un cuento interactivo acerca de un cachorro y su mejor amigo. El cuento incluye cinco videojuegos diseñados para niños. El libro fue lanzado el año 2012 permitiendo a la empresa incursionar a las tiendas de Android y Apple dando un rápido vistazo del comportamiento y requerimientos de la industria. 5 Datos tomados de la tienda de aplicaciones de Google para https://play.google.com/store/apps/details?id=com.rovio.angrybirds&hl=es_419 Android (GooglePlay). 16 En 2013 se lanzó su secuela titulada "Mr. Spots", la cual fue nominada y ganadora de varios premios certificando el gran nivel de calidad de la aplicación a nivel nacional. Actualmente Milky y Mr.Spots juntas cuentan con más de 50.000 descargas en los 2 años que llevan en el mercado. Ilustración 1. Libro interactivo Milky 7.1.2 IGDA El IGDA (International Game Developers Association) es una organización internacional que se encarga de la promoción e integración de las empresas en el sector de videojuegos. En el año 2011 se creó IGDA Colombia cuyo principal objetivo ha sido propiciar un ecosistema para el desarrollo y fortalecimiento de la industria local6. Hoy en día existen 47 empresas del sector videojuegos registradas al IGDA en nuestro país.7 7.1.3 Colombia Games En 2005 Colombia Games se lanzó al mercado de Latinoamérica, con la aplicación “ToGetHere” que tuvo un éxito comercial limitado, pero que fue elogiada por su contribución al cuidado del medio ambiente. Este producto logró demostrar la calidad y el nivel de competitividad que podía alcanzar una empresa colombiana, impulsando así el surgimiento de nuevas 6 Información basada en la misión del IGDA Colombia http://igdacolombia.co/about/ Datos tomados del IGDA Colombia (Asociación de Desarrolladores http://igdacolombia.co/desarrolladores/ 7 de Videojuegos) 17 empresas y de políticas que favorecen las posibilidades para la industria local en este campo. 7.1.4 Efecto Studio Efecto Studio, conformado por varios de los pioneros en el desarrollo de videojuegos en el país y con un amplio nivel de experiencia en empresas internacionales decide dejar de producir juegos para consolas y enfocarse en los dispositivos móviles evidenciando el enorme mercado y la gran ventaja competitiva de este sector. Su último juego “Grabbity” logro una gran acogida a nivel internacional con más 500.000 descargas solo en la tienda de Apple. Ilustración 2. Videojuego Grabbity 7.1.5 Rovio Rovio es una empresa finlandesa, fundada en 2003 por 3 estudiantes y que en 2009 luego de hacer varios juegos con un éxito mediano, lanzaron al mercado “Angry Birds”, un juego que se convirtió en un hito en la industria, logrando ser el primero en alcanzar una difusión global, convirtiéndose en el juego más descargado del año en 2010. Hoy cuenta con más de mil millones de descargas de las cuales el 25% han sido de pago, generando ingresos por más de 20 millones de dólares anuales 8. 8 Datos tomados del El Tiempo, 28 de abril de 2014. http://www.eltiempo.com/archivo/documento/CMS13897556 18 Ilustración 3. Videojuego AgryBirds de Rovio 19 8 MARCO TEÓRICO El desarrollo de videojuegos es un proceso ingenieril que une artes, procesos y conocimientos de diversas áreas en un único sistema que debe funcionar de manera sinérgica y transparente al usuario9. El objetivo principal es el de entretener a través de experiencias vivenciales. 8.1 PRODUCTO MÍNIMO VIABLE (PMV) Este término fue popularizado por Eric Ries en su libro “The Lean Startup” y hace referencia a la versión de un nuevo producto que permite al equipo recolectar, usando el menor esfuerzo posible10, la mayor cantidad de conocimiento validado sobre sus potenciales clientes. Un producto mínimo viable, se caracteriza por tener aquellas funcionalidades que permiten que el producto sea lanzado. El producto puede ser lanzado a un segmento de todos los posibles clientes o a todo el mercado para que sea probado y evaluado por el consumidor final. Normalmente, el producto es lanzado a un pequeño segmento, conocido como los “early adopters”, que son el grupo del mercado que conoce este tipo de productos y que está dispuesto a pasar por alto los pequeños errores o funcionalidades incompletas y a su vez, que están dispuestos a evaluar y proveer opiniones acerca del producto. 8.2 VIDEOJUEGO Los videojuegos son juegos electrónicos, productos de software que permiten la interacción del usuario con un dispositivo electrónico y que brinda una respuesta visual a sus acciones. Este dispositivo electrónico puede ser una computadora, un teléfono o un aparato diseñado con el único fin de jugar. Orlando, Greg; Console Portraits: A 40-Years Pictorial History of Gaming. Wired News. 2007. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Publishing. 2011. p. 25. 9 10 20 8.3 METODOLOGÍA SCRUM Es un modelo de referencia, define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante el proyecto. SCRUM se basa en la experiencia colectiva y el conocimiento empírico para detectar los puntos fuertes y débiles del proceso de producción y ayudar al equipo a crear estrategias para mejorar su desempeño y productividad, todo esto mediante tres pilares: transparencia, inspección, adaptación.11 Aunque SCRUM nace como un modelo para el desarrollo de productos tecnológicos, también fue diseñado para trabajar en entornos con requisitos inestables y que requieren rapidez y flexibilidad. En 1993 Jeff Sutherland aplico el modelo en Easel Corporation, y luego de dos años de pruebas, junto con Ken Schwaber presento el SCRUM como un modelo formal para el desarrollo de software. Para que la metodología de frutos, es necesario hacer tres tipos de reuniones por parte del equipo de trabajo: Planificación del Sprint Es la reunión inicial, en la que se plantean los requerimientos para este Sprint, y se dan las pautas a seguir durante el siguiente mes de trabajo. Revisión diaria Es la base del SCRUM, en ella se revisan los objetivos del día anterior y se plantean nuevos objetivos para el día que comienza, y adicionalmente se presentan las dificultades y obstáculos que se presentaron. Tiene una duración fija de 15 minutos, es de carácter informal, y se debe realizar en el mismo lugar y hora cada día al comenzar la jornada laboral.12 11 12 Ken Schwaber; Agile Project Management with Scrum. Microsoft Press, January 2004, 150p-158p Ken Schwaber; Agile Project Management with Scrum. Microsoft Press, January 2004, 160p-165p 21 Revisión del Sprint Al final de cada Sprint se hace una revisión del proyecto, esto sirve como base para la planeación del siguiente Sprint. Su propósito es garantizar una mejora continua del proceso, tiene una duración de 4 horas.13 8.4 SPRINT Es el corazón de SCRUM14, con una duración de 1 mes o menos, en el cual se crea un producto potencialmente viable. Un sprint comienza inmediatamente después de terminar el anterior y debe cumplir los siguientes objetivos: No se deben hacer cambios que pongan en riesgo el objetivo del sprint. Las metas de calidad siempre deben aumentar. Los objetivos deben ser renegociados entre el Product Owner y el equipo de trabajo como resultado de las experiencias adquiridas durante el sprint. 8.5 ROLES SCRUM 8.5.1 Roles Principales 8.5.1.1 Product Owner Representa al cliente, se encarga de velar por que se cumplan los requisitos y necesidades del mismo. Se asegura de que el equipo de SCRUM trabaje de forma adecuada desde la perspectiva del negocio. Es el encargado de escribir las historias de usuario. 8.5.1.2 ScrumMaster (facilitador) El SCRUM es facilitado por un ScrumMaster, cuyo trabajo principal es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo, sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. Es el encargado de velar porque los pasos y procesos del SCRUM se cumplan de manera correcta. 13 Official guide of SCRUM. https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/ScrumGuide.pdf#zoom=100. p11. 14 Ibíd. p7. 22 8.5.1.3 Equipo de desarrollo El equipo tiene la responsabilidad de entregar el producto. Debe ser un equipo pequeño (de entre 3 a 9 personas) con habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc.). 8.5.2 Roles Auxiliares 8.5.2.1 Stakeholders Son las personas que hacen posible el proyecto (clientes, proveedores, vendedores, etc.) y para los que el proyecto producirá beneficio, justificando así su producción. Solo participan de manera directa durante las revisiones del Sprint.15 8.5.2.2 Administradores Son los encargados de establecer el ambiente de desarrollo del producto. 8.6 DOCUMENTOS 8.6.1 Product backlog El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requisitos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión. Es abierto y solo puede ser modificado por el product owner16. Contiene estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. 8.6.2 Sprint backlog El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser dividida en otras menores. Las tareas en el sprint backlog 15 Official guide of SCRUM. https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/ScrumGuide.pdf#zoom=100. 16 Ibíd. p12. 23 nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno. 8.6.3 Burn down chart La burn down chart es una gráfica que se muestra públicamente y que mide la cantidad de requisitos en el Backlog del proyecto que se encuentran pendientes al comienzo de cada Sprint. Si se dibuja una línea que conecte los puntos de todos los Sprints completados, se puede evidenciar el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos. 8.7 HISTORIAS DE USUARIO Son las técnicas utilizadas para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no. El tratamiento de las historias de usuario es muy dinámico y flexible. Cada historia de usuario es los suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas pocas semanas. Las historias de usuario son descompuestas en tareas de programación y asignadas a los programadores para ser implementadas durante una iteración de la metodología de trabajo. 8.8 MOTOR DE VIDEOJUEGO (GAMEENGINE) Es un software que incorpora rutinas de programación que permiten el diseño, la creación y la presentación de un videojuego. La funcionalidad básica de un motor es proveer al videojuego de un motor de renderizado para los gráficos 2D y 3D, un motor de físicas que además incluya un detector de colisiones, un sistema integrado para el uso de sonidos, scripting, animación, administración de memoria y un escenario gráfico. Su utilidad reside en la capacidad que tienen para mejorar la 24 organización de un proyecto de este tipo17, además de eliminar la necesidad de programar todo desde el comienzo y eliminar en gran parte la programación a bajo nivel.18 8.9 UNITY 3D Unity 3D es un motor de videojuegos multiplataforma con un IDE integrado. Actualmente es el líder del mercado y está disponible para las plataformas: PC, Mac, Linux, Web, Android, iOS, Blackberry 10, Windows Phone, Wii, Wii U, Xbox 360, Xbox One, y Play Station 4. Al tener su propio IDE, permite la programación en diversos lenguajes, los cuales luego transcribe como código C y C++ optimizando su ejecución y permitiendo una mayor compatibilidad con las diferentes plataformas. 8.10 PROGRAMACIÓN ORIENTADA A OBJETOS La programación orientada a objetos (POO) es un paradigma que usa el símil de los objetos en sus interacciones, para diseñar aplicaciones y programas informáticos. Los objetos son entidades que tienen un determinado estado, identidad y comportamientos asociados. Son abstracciones de algún hecho o ente del mundo real, con atributos que representan sus características o propiedades y métodos que emulan su comportamiento o actividad. La programación orientada a objetos difiere de la programación estructural tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento lineal de datos, para convertir entradas en salidas. 8.11 PROGRAMACIÓN ORIENTADA A COMPONENTES Es un paradigma de programación con énfasis en la descomposición de sistemas ya conformados en componentes funcionales o lógicos con interfaces bien definidas Wolf, Mark; Perron, Bernard (Agosto 19, 2003). The Video Game Theory Reader. Routledge. Pág. 10 18 Ward, Jeff; What is a game engine (Abril 29, 2008). http://www.gamecareerguide.com/features/529/what_is_a_game_.php. 17 25 usadas para la comunicación entre componentes. Se considera que posee un nivel de abstracción más alta que el de la programación orientada a objetos, introduciendo la comunicación entre estos por medio de mensajes que contienen datos. Un componente es un elemento de un sistema que ofrece un servicio predefinido, y es capaz de comunicarse con otros componentes a través del intercambio de mensajes. Su principal característica es la capacidad de ser fácilmente reutilizable, por lo que debe estar completamente documentado y ser muy robusto, reduciendo el acoplamiento al mínimo, teniendo una gran capacidad de soportar errores. 8.12 LENGUAJE DE PROGRAMACIÓN C# C# es un lenguaje de programación orientado a objetos que permite el desarrollo de aplicaciones para internet, para móviles y aplicaciones de propósito general. Inicialmente se desarrolló para programar en la plataforma .net, pero dadas las características de esta y la estandarización que se ha hecho de su estructura por parte de las principales entidades de estándares internacionales, se han desarrollado otras plataformas que cumplen con dicha estructura y por lo tanto C# puede ser utilizado como lenguaje de programación entre ellas.19 El lenguaje C# es orientado a objetos y se ha creado basándose en la estructura de C y C++, especialmente su sintaxis y potencia, y adoptando el estilo y metodología de la programación de Visual Basic. Cabe destacar que C# no es el resultado de la evolución directa de ninguno de estos lenguajes, sino que ha sido creado desde cero, para programar sobre la plataforma .net. Es un lenguaje que fue concebido con el objetivo de programar esta plataforma y por lo tanto se puede decir que es el lenguaje natural de .net.20 8.13 LENGUAJE DE PROGRAMACIÓN JAVASCRIPT (JS) JavaScript es un lenguaje de programación que se diseñó para construir sitios Web y para hacerlos más interactivos, aunque es raro su uso como lenguaje de programación no enfocada a web, Unity es capaz de interpretarlo y aprovecharlo ya 19 20 FERNÁNDEZ, Carmen. C# Básico. España: StarBook Editorial, 2009. 178p. Kovacs, James (Septiembre 7, 2007). C#/.NET History Lesson. 26 que es un lenguaje de programación interpretado y orientado a objetos el cual basa su estructura en C.21 Aunque comparte muchas de las características y de las estructuras del lenguaje Java, fue desarrollado independientemente y cumple con un propósito distinto. Es un lenguaje de programación débilmente tipado y dinámico. El lenguaje JavaScript puede interactuar con el código HTML, permitiendo a los programadores web utilizar contenido dinámico. El lenguaje JavaScript es de código abierto (opensource), que cualquier persona puede utilizar sin comprar una licencia. 8.14 XML XML es un Lenguaje de Etiquetado Extensible muy simple, pero estricto que juega un papel fundamental en el intercambio de una gran variedad de datos. Es un lenguaje muy similar a HTML pero su función principal es describir datos y no mostrarlos como es el caso de HTML. XML es un formato que permite la lectura de datos a través de diferentes aplicaciones. Las tecnologías XML son un conjunto de módulos que ofrecen servicios útiles a las demandas más frecuentes por parte de los usuarios. XML sirve para estructurar, almacenar e intercambiar información22. 21 BLACKMAN, Sue. Beginning 3D Game Development with Unity: All-in-One, multiplatform Game Development. Estados Unidos: Apress, 2013. 28p. 22 Sitio oficial de la W3C en español. http://www.w3c.es/Divulgacion/GuiasBreves/TecnologiasXML 27 9 METODOLOGÍA DE DESARROLLO DEL PROYECTO 9.1 TIPO DE ESTUDIO Dado que el proyecto consiste en crear una solución de software totalmente nueva y adaptable a futuros requerimientos, basándose en el conocimiento del mercado y de las necesidades del mismo, además del uso del conocimiento teórico y práctico obtenido en proyectos académicos realizados en aulas de clase, se puede concluir que este es un estudio y desarrollo ingenieril enfocado al desarrollo tecnológico. 9.2 METODOLOGÍA DEL PROYECTO El proyecto se realizó basado en los datos y experiencias documentadas de la compañía en esta área, haciendo uso del conocimiento que surge de la práctica y del análisis de los resultados obtenidos con proyectos anteriores. Se usó la metodología de desarrollo ágil SCRUM para coordinar cada aspecto del desarrollo, ya que era necesario poseer prototipos tempranos que permitieron evaluar aspectos de calidad y entretenimiento, para así detectar posibles cambios a la historia, Gameplay, diseño visual, o cualquier otro aspecto que no funciono como se esperaba. Partiendo de la historia y el diseño del videojuego (mecánicas, niveles, personajes, etc.), la empresa dividió el equipo de trabajo en dos grupos, el primero conformado por el pasante estuvo encargado de la programación, y el segundo de la parte visual (gráficos, modelado de personajes, ilustración, etc.). 9.3 DESCRIPCIÓN DE LA METODOLOGÍA EN CONTEXTO El desarrollo se realizó de forma incremental, desarrollando pequeñas versiones que se probaron y se integraron con las anteriores, añadiendo con cada iteración más funcionalidades y valor al producto, cada ciclo cumplió con 4 etapas: análisis, diseño, implementación y pruebas. 28 Para comenzar, se hiso un diseño base según la mecánica de juego, y se verificaron los resultados obtenidos, para así evaluar los objetivos alcanzados y los atrasados, además de las dificultades que se produjeron a lo largo de la iteración anterior, para generar una nueva estrategia a fin de mejorar el proceso, asignar nuevas metas y objetivos, así como estrategias para alcanzarlos. El código se documentó de forma inmediata y se escribió de forma semántica para reducir al mínimo la necesidad de manuales y de documentos de soporte aprovechando el tiempo para verificar la compatibilidad con los módulos anteriores y el perfecto acople de la aplicación tras el desarrollo de cada módulo. Al final de cada iteración se realizaron pruebas locales del software para verificar cuales de los objetivos fueron cumplidos o en qué porcentaje se alcanzaron, al igual de los obstáculos que se encontraron en el proceso, para así poder utilizar esta información como base para la siguiente iteración y alimentar el Burn down chart. 9.3.1 Datos técnicos El proyecto se dividió en 12 Sprints cada uno de 15 días de duración, con sus respectivas reuniones de Daily SCRUM realizadas a las 10:00 AM con todo el equipo involucrado al proyecto. Al final de cada sprint se tuvo un demo con las nuevas funcionalidades a probar (véase anexo B) y se realizó una reunión mensual para verificar el avance global del desarrollo. 9.3.2 Medios de apoyo para SCRUM: 9.3.2.1 Semáforo de proyectos Se muestra un listado de los proyectos y de las áreas de la empresa en una matriz, donde con 4 colores se indica el nivel de compromiso de cada área con el desarrollo de cada uno de los proyectos. El tablero de proyectos cuenta con 4 estados para clasificar un proyecto y el nivel de compromiso de cada área. Los colores son: Rojo: El proyecto tiene la prioridad número 1, es el más importante y se le debe dedicar el mayor tiempo posible. Verde: En proceso. 29 Amarillo: Se encuentra en espera, ya sea del trabajo de un área, una autorización del cliente, etc. Azul: El proyecto se encuentra congelado y no se trabajara más en él. 9.3.2.2 Tablero de proyectos Tanto las historias de usuario, los criterios de aceptación como las tareas, son escritas en posits y pegadas en un tablero Scrum; se recomienda que las historias de usuario se escriban en posits del mismo color, de un tamaño grande; luego los criterios de aceptación en posits de distinto color al de las historias de usuario, de un tamaño mediano y por último las tareas de un color distinto al de los anteriores 2 y de un tamaño pequeño. El tablero consta de 5 columnas y X número de filas, donde X representa el número de historias de usuario que se van a ejecutar durante el sprint: 1. To Do: Allí se pegan las historias de usuario con sus criterios de aceptación, además de las tareas que son necesarias para cumplir los criterios de aceptación. 2. Doing: Son las tareas que se están ejecutando actualmente. 3. Review: Son las tareas que ya han sido acabadas, sin embargo están en revisión por los miembros del equipo encargados de Q.A. 4. Done: Son las tareas que ya han sido acabadas y verificadas, por tanto están completas. 30 Ilustración 4. Tablero SCRUM 9.4 PARTICIPANTES Se involucró todo el equipo de desarrollo de la empresa, conformado por un grupo interdisciplinar de profesionales en diversas áreas del proceso productivo, del cual el pasante ocupó el cargo de desarrollador cumpliendo las labores de programación necesarias para lograr los objetivos del proyecto, además estuvo involucrada el área administrativa de la empresa cuyo rol principal fue asignar los recursos, coordinar el proyecto y el trabajo de cada una de las partes involucradas. Se realizaron pruebas por parte de personas ajenas a la compañía, quienes estaban conformados tanto por profesionales en el área de testeo como por pequeñas muestras del público objetivo (usuarios finales de la aplicación). La distribución del equipo para las tareas de SCRUM fue: SCRUM Master: Jeidy Martinez Product Owner: Hugo Urueña Development team member: 31 Sergio Osma (Programación) Julián Cagua (Diseño de interfaz) Wilson Ortiz (Modelado y Animación 3D) Edgar Murcia (Modelado y Animación 3D) Javier Marciales (Arte y Texturizado) Diego Sánchez (Coordinación de arte) 9.5 INSTRUMENTOS Y EQUIPO Además de los equipos utilizados para desarrollar el videojuego (computadores de escritorio, tablas de dibujo digital) se utilizaron tabletas y celulares tanto Android como iOS en entornos simulados de prueba, para obtener datos de rendimiento y de comportamiento de la aplicación bajo los estándares de calidad de la empresa. Al completar la mecánica base del juego se realizaron pruebas de usuario, primero de forma interna por parte del equipo de desarrollo y luego con personas externas a la empresa, que probaron la mecánica de juego y la viabilidad del control que se ajustó según los resultado obtenidos y posteriormente se probó de forma similar obteniendo un mayor nivel de aceptación. 9.6 HERRAMIENTAS UTILIZADAS 9.6.1 Software El software utilizado para programar y compilar el proyecto fue Unity 3D, que además de ser la plataforma encargada de unir todos los recursos que los demás miembros del equipo desarrollaron posee un entorno de depuración y compilación para C# y JavaScript. Unity 3D también proveyó un sistema de pruebas en tiempo real que junto con el hardware (tabletas y celulares) dedicado a tal fin asegura la mejor calidad posible en el producto final. Se utilizaron además otras herramientas por parte del equipo de desarrollo: Photoshop: software utilizado para la edición de imágenes, dibujo de texturas e interfaces, además de las ilustraciones del juego. 32 Blender 3D: software libre, utilizado para el modelado y animación de los objetos, escenarios y personajes del juego. Office 2013: Se utilizaran herramientas como Outlook, Word y Excel, para la documentación, diseño y control del proceso de desarrollo. 9.6.2 Hardware 2 Tabletas digitalizadora Wacom 2 Equipos iMac con OSX, 8GB RAM, 1TB disco duro, procesador Intel Core i5 2 Equipos Pc con Windows 7, 8GB RAM, 512GB disco duro, procesador Intel Xeon E5 2 Equipos Pc con Windows 8, 4GB RAM, 1TB disco duro, procesador Intel Core i 7 9.6.3 Talento humano: Director del proyecto: Es aquel que coordina todas las áreas del proyecto a fin de garantizar su correcto funcionamiento. Arquitecto de software: Cargo ocupado por el pasante, que se encargó del diseño estructural del software. Gerente de proyectos: Se encarga de controlar los procesos y medir las tareas de los demás roles, además ejercerá el papel de SCRUM master. Diseñador del juego: Es el encargado de crear las mecánicas del juego, definir las reglas y la interacción con el usuario. Desarrollador: Rol principal del pasante, que se encargó de la codificación del videojuego, además de la posterior compilación y pruebas de la aplicación. Diseñadores (2): Encargados de crear los bocetos, ilustraciones, interfaz gráfica, y diagramación del juego. Modeladores 3D (2): Se encargaron de crear los objetos 3D del juego, incluyendo los personajes, escenarios y utilería del mismo. Documentador: El pasante se encargó de mantener actualizados los documentos de diseño de juego y de desarrollo de software del proyecto. 33 10 RESULTADOS OBTENIDOS Al concluir este proceso, se obtuvo el producto mínimo viable del videojuego "Magic Cave” que está en la capacidad de ser probado y evaluado por usuarios y posibles clientes, para así pasar a ser comercializado o ampliado según lo decidan los revisores internos de la empresa. "Magic Cave" se caracteriza por: Los scripts de inteligencia artificial para los personajes y su documentación se realizaron teniendo en cuenta que quedaran a disposición de proyectos futuros lo cual ahorrará tiempo y costos al proceso de producción. Poseer un editor de niveles, que permite ampliar de forma simple el videojuego. Tener una interfaz del usuario completa, amigable y funcional. Guardar y recuperar información de ficheros XML de forma confiable. Ser un producto que cumple con los requisitos básicos para ser considerado un producto comercial (requisitos funcionales y no funcionales), y a su vez, ser fácilmente extensible para ser ampliado en una etapa posterior de ser considerado necesario. Tener un alto nivel de optimización, garantizando su funcionamiento con un uso mínimo de hardware. Estar probado en las plataformas líderes del mercado (Android e iOS) y en una gran variedad de dispositivos y ambientes, lo que garantiza un producto robusto. 34 11 CRONOGRAMA ACTIVIDAD TAREA Mes 6 Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 Análisis y comprensión de los requerimientos Definición de los alcances y Iniciar el límites del proyecto proyecto Identificación y asignación de roles Identificación de riesgos Determinación de requerimientos Funcionales y Administrar no funcionales Requerimientos Creación y Documentación de los diagramas de Casos de uso Creación de los casos de prueba Reunión inicial SCRUM, Administrar la definición de tiempos y fechas iteración para las reuniones y ciclos necesarios. Identificar escenarios Definir Identificar patrones de negocios Arquitectura Identificar elementos de diseño relevantes Diseñar Pruebas de la Desarrollar la implementación solución 35 S4 ACTIVIDAD TAREA Mes 6 Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 Diseñar de Game Play Crear Guion literario del juego (Textos) Diseñar de Personajes Modelar de Personajes Texturizar de los personajes Animación de los personajes Crear Árbol de Navegación Codificación del juego Modelar escenarios Diseñar y Crear sistema de guardado de datos Diseñar de interfaz de usuario Modelar utilería Implementación de controles Realización de pruebas del desarrollador Documentación del desarrollo Identificar y documentar requerimientos adicionales Corrección con base en las pruebas Crear y documentar de los diagramas de Casos de uso Crear casos de prueba Crear documento de cambios y control de versiones 36 S4 ACTIVIDAD TAREA Iniciar la documentación y manuales de juego Iniciar manual de usuario Desarrollar incremento de la solución Probar la versión Preparar la publicación del juego Finalización del producto, documentación Mes 6 Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 Iniciar Libro de diseño de juego. Codificación final de los menús e interfaz de usuario. Realización de pruebas del desarrollador Corrección de los errores (“bugs” y “glitchs”) encontrados. Creación del compilado Realizar pruebas con los jugadores Corrección con base en las pruebas Validar las condiciones necesarias para la finalización del producto. Terminar manual de usuario. Terminar libro de diseño de Juego. Tabla I. Cronograma del proyecto teniendo en cuenta la metodología SCRUM 37 S4 12 PRESUPUESTO Talento Humano Gasto Tiempo (meses) Valor (COP) Total (COP) Arquitecto de software $ 4.000.000 5 $ 20.000.000 Gerente de proyectos (SCRUM Master) $ 3.000.000 5 $ 15.000.000 Diseñador de mecánicas de juego (Game designer) $ 3.000.000 3 $ 9.000.000 Desarrollador $ 1.200.000 6 $ 7.200.000 Audio $ 800.000 1 $ 800.000 Ilustrador $ 1.100.000 2 $ 2.200.000 Diagramador $ 1.100.000 3 $ 3.300.000 Modeladores 3D (2) $ 2.800.000 4 $ 11.200.000 Equipo de pruebas de software $ 1.000.000 2 $ 2.000.000 Documentador $ 1.000.000 4 $ 4.000.000 Total Talento Humano - - $ 74.700.000 Recursos de Software Gasto Tiempo (meses) Valor (COP) Total (COP) Unity 3D $ 140.000* 5 $ 700.000 Photoshop $ 60.000 6 $ 360.000 Blender 3D $ 100.000** - $ 100.000 Office 365 $ 15.000* 6 $ 90.000 Enterprise Architect $ 375.000* - $ 375.000 Sistema operativo Windows 8 (4 unidades) $ 374.000* - $ 1’496.000 Total Software - - $ 1.625.000 Recursos de Hardware Gasto Valor (COP) Cantidad Total (COP) Tableta digitalizadora $ 250.000* 3 $ 750.000 Computadores Mac $ 950.000* 4 $ 3.396.000 Computadores Windows $ 849.000* 4 $ 3.396.000 Total Hardware - - $ 7.542.000 Otros Gasto Material Bibliográfico Tiempo (meses) Valor (COP) $ 200.000 - Total (COP) $ 200.000 38 Papelería - - $ 450.000 Servicios públicos (agua, luz, telefonía e internet) $ 180.000 6 $ 1.080.000 Total otros gastos - - $ 1.730.000 Total gastos $ 85.696.000 Tabla 2. Presupuesto estimado del proyecto. * La empresa ya posee la licencia de este software, el valor corresponde al valor estimado para el proyecto. ** Corresponde a costos de instalación, configuración y mantenimiento. 39 13 ANÁLISIS DEL SISTEMA 13.1 FICHA TÉCNICA DEL VIDEOJUEGO Fecha: 12-12-2014 Versión: 2.0 Software: UNITY3D Ficha entregable: 1. A qué categoría pertenece: Entretenimiento 2. Descripción cognitivo del juego: No Aplica 3. Rango de edad: 13+ Objetivo: 1. Llevar a nuestro personaje hasta la puerta mágica que nos trasladara al siguiente reto Tabla 3. Ficha técnica del videojuego. 13.2 REQUERIMIENTOS El juego tiene distintos niveles de calidad visual ajustándose automáticamente a las capacidades del dispositivo en el que se ejecute, sin embargo los requerimientos mínimos para funcionar son: Computador: Sistema operativo: Windows XP, Mac OS X 10.7, Ubuntu 10.10, SteamOS o superiores. Tarjeta de vídeo: Capacidades DX9 (shader modelo 2.0). CPU: Compatible con el conjunto de instrucciones SSE2. iOS: Sistema operativo iOS 6.0 o versiones posteriores. 40 Android: Sistema operativo 2.3.1 o posterior Procesador ARMv7 (Cortex) CPU o Atom CPU Procesador gráfico con OpenGL ES 2.0 o posterior. 13.3 DIAGRAMAS UML 13.3.1 Diagrama de casos de uso 13.3.1.1 Diagrama Ilustración 5. Diagrama de casos de uso. 13.3.1.2 Actores Jugador: Es el usuario final de la aplicación, quien hará uso de las funciones de juego. Diseñador de juego: Tendrá acceso a funciones especiales de la aplicación, puede crear niveles y probarlos para habilitarlos en la versión final de la aplicación. 41 13.3.1.3 Definición de los casos de uso Nombre del Caso Jugar de Uso Resumen El Jugador podrá usar esta opción para ingresar al juego. Jugador Sistema Curso básico de 1. El Jugador selecciona la eventos opción jugar. 2. El sistema muestra la secuencia de introducción al juego. 3. El sistema crea la partida. 4. El sistema guarda los datos iniciales. 5. El sistema muestra el tutorial inicial del juego. 7. El Jugador interactúa con el juego de acuerdo a las instrucciones presentadas y teniendo en cuenta la mecánica de juego. Caminos alternativos Caminos excepción 6. El sistema habilita los controles del juego. N/A (No Aplica) de 1. De acuerdo a la mecánica de juego, es necesario encontrar una solución al nivel actual para avanzar. Suposiciones El juego debe estar instalado en un computador o dispositivo móvil que cumpla con las características requeridas. Pre Condiciones Se ha podido cargar el nivel del archivo XML. Post Condiciones Se inicia una partida de juego. 42 Autor Sergio Osma Fecha 30 de Octubre de 2014 Nombre del Caso Pausar partida de Uso Resumen El Jugador podrá acceder a esta opción desde el juego a través del botón “menú” o con la tecla “escape”. Jugador Curso básico de 1. El jugador accede al menú eventos de pausa al pulsar el botón “menú” o al presionar la tecla “escape”. Sistema 2. El sistema envía la orden a sus componentes para que detengan su ejecución (pausa el juego). 3. El sistema muestra un submenú. Caminos alternativos Caminos excepción N/A (No Aplica) de N/A (No Aplica) Suposiciones El juego no se encuentra pausado. El jugador se encuentra en la pantalla de juego. Pre Condiciones El jugador se encuentra en una partida activa. El juego no está cargando o durante una cinemática. Post Condiciones El juego entra al estado de pausa. Se muestra una nueva interfaz con más opciones. Autor Sergio Osma Fecha 30 de Octubre de 2014 43 Nombre del Caso Volver al menú principal de Uso Resumen El Jugador podrá acceder a esta opción para ir al menú del juego a través del submenú de pausa. Jugador Sistema Curso básico de 1. El Jugador selecciona la eventos opción “Regresar al menú 2. El sistema confirma si el principal”. jugador quiere ir al menú principal del juego. 3. El Jugador confirma la opción de ir al menú principal. Caminos alternativos Caminos excepción 4. El sistema cierra la partida y se dirige al menú principal del juego. N/A (No Aplica) de N/A (No Aplica) Suposiciones N/A (No Aplica) Pre Condiciones El jugador se encuentra en el submenú de pausa. Post Condiciones EL juego regresa al menú principal. Autor Sergio Osma Fecha 30 de Octubre de 2014 Nombre del Caso Reiniciar partida de Uso Resumen El Jugador podrá acceder a esta opción para reiniciar el nivel actual del juego. Jugador Sistema Curso básico de 1. El Jugador selecciona la eventos opción “Reiniciar partida”. 44 2. El sistema confirma si el jugador quiere ir reiniciar el 3. El Jugador confirma la nivel actual del juego. opción de reiniciar. 4. El sistema cierra la partida. 5. El sistema carga nuevamente el nivel actual. Caminos alternativos Caminos excepción Perder la partida. de N/A (No Aplica) Suposiciones N/A (No Aplica) Pre Condiciones El jugador se encuentra en el submenú de pausa. Post Condiciones El jugador encuentra el nivel en su estado inicial y pierde todo su avance en este. Autor Sergio Osma Fecha 30 de Octubre de 2014 Nombre del Caso Cargar partida de Uso Resumen El Jugador podrá acceder a esta opción para ingresar al juego y continuarlo desde el último punto de guardado (Checkpoint). Jugador Curso básico de 1. El Jugador inicia el juego y eventos selecciona la opción cargar partida. Sistema 2. El sistema carga la última partida guardada. 45 3. El sistema configura la partida con los parámetros guardados. 5. El Jugador interactúa con el 4. El sistema habilita el juego de acuerdo a las control del personaje. instrucciones presentadas y teniendo en cuenta la mecánica de juego. Caminos alternativos Caminos excepción N/A (No Aplica) de N/A (No Aplica) Suposiciones El juego debe estar instalado en un computador o tableta que cumpla con las características requeridas. Pre Condiciones Se ha podido cargar el nivel del archivo XML. Post Condiciones Se inicia una partida de juego en el nivel y con las características guardadas. Autor Sergio Osma Fecha 7 de Noviembre de 2014 Nombre del Caso Configurar opciones de Uso Resumen El Jugador podrá acceder a esta opción para configurar las opciones visuales y de sonido. Jugador Curso básico de 1. El Jugador inicia eventos aplicación y selecciona opción “Configuración”. Sistema la la 2. El sistema muestra la pantalla de configuración del 3. El Jugador selecciona la juego. opción de configuración que desea y ajusta los parámetros. 46 4. El sistema aplica los parámetros de configuración. Caminos alternativos Caminos excepción El jugador activa el menú desde el juego y oprime el botón “Opciones” de N/A (No Aplica) Suposiciones El jugador quiere cambiar o ajustar los parámetros del juego. Pre Condiciones N/A (No Aplica) Post Condiciones El sistema aplica los parámetros de configuración seleccionados para que los jugadores puedan disfrutar el juego de acuerdo a sus necesidades y gustos. Autor Sergio Osma Fecha 7 de Noviembre de 2014 Nombre del Caso Salir de Uso Resumen El Jugador podrá acceder a esta opción para cerrar la aplicación y detener su ejecución. Jugador Curso básico de 1. El Jugador inicia eventos aplicación y selecciona opción “Salir”. Sistema la la 2. El sistema muestra un mensaje de confirmación. 3. El Jugador confirma que 4. El sistema desea salir. aplicación. Caminos alternativos Caminos excepción Suposiciones cierra la En el sistema operativo Android oprimir la tecla “escape” desde el menú principal. de N/A (No Aplica) El jugador quiere salir de la aplicación. 47 Pre Condiciones N/A (No Aplica) Post Condiciones El sistema se cierra y termina cualquier subproceso que haya iniciado. Autor Sergio Osma Fecha 30 de Octubre de 2014 Nombre del Caso Crear nivel de Uso Resumen El diseñador de juego podrá acceder a esta opción para crear un nuevo nivel. Diseñador de juego Sistema Curso básico de 1. El diseñador de juego inicia eventos la aplicación y selecciona la opción “Configuración”. 2. El sistema muestra la pantalla de creación de 3. El diseñador de juego crea niveles. el nivel utilizando los elementos disponibles en la interfaz. 3. El diseñador de elige como guardar el nivel. Caminos alternativos Caminos excepción 5. El sistema guarda el nivel de pruebas. N/A (No Aplica) de N/A (No Aplica) Suposiciones El diseñador de juego quiere crear o ajustar un nivel del juego. Pre Condiciones N/A (No Aplica) Post Condiciones El sistema guarda un nuevo nivel que podrá ser probado por el diseñador de juego. 48 Autor Sergio Osma Fecha 23 de Febrero de 2015 Nombre del Caso Probar nivel de Uso Resumen El diseñador de juego podrá acceder a esta opción para probar un nivel guardado. Diseñador de juego Curso básico de 1. El diseñador de juego eventos selecciona la opción “Probar”. Sistema 2. El sistema carga el listado de niveles guardados. 3. El sistema muestra la pantalla de selección de niveles. 4. El diseñador de juego elige el nivel que desea probar. 5. El sistema carga el nivel guardado. 6. El sistema habilita los 7. El Jugador interactúa con el controles del juego. juego de acuerdo a las instrucciones presentadas y teniendo en cuenta la mecánica de juego. Caminos alternativos Caminos excepción N/A (No Aplica) de N/A (No Aplica) Suposiciones El diseñador de juego quiere crear o ajustar un nivel del juego. Pre Condiciones N/A (No Aplica) 49 Post Condiciones El sistema guarda un nuevo nivel que podrá ser probado por el diseñador de juego. Autor Sergio Osma Fecha 23 de Febrero de 2015 13.3.2 Diagrama de componentes 13.3.2.1 Componentes 1. LeerXML: Lee los archivos XML según el formato establecido y los carga en una biblioteca pública que envía como mensaje a quien lo requiera. 2. GuardarXML: Guarda el contenido de un arreglo en un fichero XML. 3. Logica_gui: Controla la GUI de movimiento, ataques e indicador de magia del personaje. Se comunica con rag_movement (ActivarCaminar) para darle la orden al personaje de caminar, con selección_destino (Desactivar, Activar) para controlar en que momentos es posible elegir un destino y con el control de la cámara “camaraPerseguidora” (Cambiar) para cambiar el ángulo y posición actual de la cámara. 4. Rag_Movement: Mueve el personaje y permite el uso de sus habilidades. Se comunica con Baul (Activar), con selección_destino (finalizarRecorrido, empezarRecorrido) para informar que acabo el recorrido y que es posible seleccionar un nuevo destino y con lógica_gui (finalizarRecorrido) para habilitar el botón de caminar al llegar al destino. 5. Selección_destino: Permite seleccionar el cuadro deseado, almacena los 3 puntos de la ruta y muestra la interfaz del recorrido. Se comunica con Rag_Movement para asignarle la ruta que debe tomar el personaje. 6. CamaraPerseguidora: Controla la posición de la cámara y guarda su configuración. 7. Baúl: Controla el baúl que contiene los diferentes poderes que adquiere el personaje. Se comunica con Rag_Movement (GanarPoder), lógica_gui (MostrarInfo) 8. Historia: Muestra la historia del juego. 9. movEnemigo: Mueve al enemigo. 10. IAEnemigo: Gestiona el comportamiento del enemigo y sus acciones. Se comunica con movEnemigo (Destino, Detener) enviándole la ruta que debe tomar y la orden de detenerse cuando sea necesario. 11. puertaMagica: Es el final de un nivel, desencadena la celebracion del personaje y el cargue del siguiente nivel. 12. ragParpadear: Componente que agrega el parpadeo a los ojos del personaje. 50 13. texturaAleatoria: Componente que permite asignar varias texturas a personajes y props de forma aleatoria. 14. tutorial: controla el nivel de tutorial, se comunica con los componentes de interfaz y control del personaje para poder guiar al usuario en el uso de controles e interfaz. 15. logosMenu: carga los logos del juego y posteriormente muestra el menú principal. 16. MainMenu 17. skipVideo: permite omitir los videos y secuencias animadas del juego. 18. pasarDeNivel: cargar el siguiente nivel de forma inteligente, cargando solo los modelos y texturas que se utilizaran. 19. cargarNivel: cargar el siguiente nivel de forma inteligente, cargando solo los modelos y texturas que se utilizaran. 20. cargarPartida: carga la última partida guardada. 21. guardarPartida: guarda los puntajes y el avance actual del juego. 22. configuracionVisual: guarda y aplica los cambios a la calidad gráfica del juego. 23. controlDeAudio: guarda y aplica los cambios a la intensidad del volumen del sonido del juego. 13.3.2.2 Diagramas de componentes Componentes de la aplicación Ilustración 6. Diagrama general de componentes. 51 Configuración Ilustración 7. Diagrama de componentes de configuración. Juego Ilustración 8. Diagrama de componentes de juego 52 Editor de niveles Ilustración 9. Diagrama de componentes del editor de niveles. 13.3.3 Diagrama de actividades 13.3.3.1 Diagramas del personaje 13.3.3.1.1 Ataque Enciende lámparas que ahuyenta los murciélagos e ilumina el camino Si Ataque de fuego Se crean llamas en la malla seleccionada Jugador activa comando Espera Es una lámpara No Ataque Ataque con plantas Incinera los enemigos y los deja fuera de combate Es creada una enredadera que encierra al enemigo Encierra a los enemigos 53 13.3.3.1.2 Defensa No Poder del fuego Es creado un muro de fuego en la malla Vacío Jugador activa comando Espera Si Defensa No Es creado un muro de plantas temporal en la malla Crea un muro de fuego (temporalmente) que detiene a los enemigos y hace huir a los zombis y a Frankye Seca el agua en los cuadros con agua y deja libre el camino Crea un muro de plantas que detiene a los enemigos temporalmente (lo golpean) Vacío Poder de las plantas. Si Crea cuadros sobre los que se puede caminar pero tienen un tiempo de duración.(Temporalmente, el cuadro debe tener plantas) 54 13.3.3.1.3 Evade Se transforma en un zorro que mueve la cola y las orejas Capa del zorro No Jugador activa comando Esper a Se convierte en un zorro el cual no es atacado por ningún enemigo pero no se puede mover o hacer magia. No consume energía. Poder roca. Evasión de la Crea caminos permanentes en los vacíos de la caverna Destruye el cuadro y recupera energía mágica pero muy poca. Vacío Si Poder de las Crea caminos permanentes en los vacíos de la plantas. caverna Crea cuadros permanentes de camino. Mueve las rocas del camino 55 13.3.3.2 Diagrama de comportamiento de Enemigos Patrulla Movimiento del punto A al B Detecta jugador al Jugador Ataca Inhabilita al fantasma Persigue jugador Jugador se esconde antes de ser encontrado al Animació n fantasma Encuentra al jugador Golpea jugador al Fin del juego 13.4 PRINCIPALES MÓDULOS DEL SOFTWARE 13.4.1 Diseño de IA 13.4.1.1 Estados Dormido: El enemigo está dormido e inmóvil, cuando el jugador pasa muy cerca, este se despierta y se pasa al estado alerta. Alerta: En este estado el enemigo sabe que el jugador está cerca y percibe más fácilmente cualquier movimiento o acción poco prudente. Confundido: Al perder de vista al jugador el enemigo entra a este estado, cuyo comportamiento es similar a alerta, pero tiene una duración diferente. Patrulla: El enemigo sigue un circuito preestablecido hasta que algo lo impida o hasta cuando detecte al jugador. Cacería: Cuando se ha detectado al jugador y éste está lo suficientemente cerca, el enemigo lo persigue intentando atraparlo. 56 Atacando: Cuando se alcanza al jugador el enemigo lanza un ataque, que de alcanzar al jugador da por terminada la partida y se ejecuta la animación de celebración. Vagando: El enemigo camina sin un rumbo determinado, y puede cambiar de dirección de forma aleatoria. Reposo: Cuando algo impide el movimiento del enemigo o éste está vagando, puede detenerse y quedarse en el mismo lugar por cierto tiempo. 57 13.4.1.2 Diagrama de estados (comportamiento de enemigos) Ilustración 10. Diagrama de estados de Inteligencia Artificial. 58 13.4.2 Algoritmo de búsqueda Se programó un sistema de detección del entorno que detecta las zonas por las que el personaje puede transitar. Ilustración 11. La zona azul muestra los posibles lugares donde el personaje puede caminar. Luego se guardó esta información en una matriz y se calculó la mejor ruta posible entre dos puntos usando el algoritmo A*. Ilustración 12. Mejor ruta hacia el objetivo. El sistema de detección de la zona caminable se amplió para reconocer espacios vacíos, y se agregó una excepción al sistema para que no los tuviera en cuenta en el cálculo de la ruta. 59 Ilustración 13. La zona azul gris muestra los lugares vacíos 13.4.3 Sistema patrulla El sistema de patrulla usa puntos de referencia que el personaje busca de forma cíclica, haciendo uso del algoritmo de búsqueda para encontrar la mejor ruta, esquivando obstáculos y peligros. Ilustración 14. Recorrido de patrulla. 60 13.4.4 Indicadores de estado Los enemigos cuentan con unos indicadores visuales que muestran el estado actual de la IA que permiten al jugador replantear su estrategia dependiendo del nivel de alerta en que estos se encuentran. 13.4.5 Sistema de carga y guardado de niveles El producto mínimo viable cuenta con 12 niveles, que hacen parte de la primera sección del juego, las secciones restantes se añadirán en desarrollos futuros. Los archivos se encuentran dentro de la carpeta “resources” del juego, y pueden ser agregados y modificados manualmente o desde la aplicación. 13.4.5.1 Estructura de archivos XML Los archivos XML contienen el nombre del nivel guardado, las filas y columnas del mismo. El nodo principal es nivel, que contiene las filas y dentro de estas están las columnas que contienen la información de la casilla representada por un número entero. Ilustración 15. Archivo XML para un nivel de 4 filas con 3 columnas (generado desde la aplicación) 61 13.5 INTERFAZ DE JUEGO 13.5.1 Diagrama de flujo de Interfaz Cargue imagen de Ananja Cargue ventana de inicio Magic Cave Opciones Inicio juego No Omitir historia Si Salir Configurar Opciones Créditos Historia juego Videojuego Si Termina No 62 13.5.2 Interfaz del juego Diseño guía que contiene los botones necesarios y una posible distribución en el espacio de la pantalla. Botón de Cámara Botón de menú Barra de energía mágica Barra de poderes Poder 1 Poder 2 Poder 3 Poder 4 Botón de Caminar/Correr Diseño final aplicando la guía de estilo del juego. Ilustración 16. Interfaz gráfica del juego 63 La interfaz fue programada de forma que su diseño se ajusta a la forma y tamaño de pantalla del dispositivo que lo ejecuta. Ilustración 17.Interfaz en pantalla cuadrada. Ilustración 18. Interfaz en pantalla ancha (wide screen) 64 13.5.3 Menú principal Botón salir Botón desarrollo Botón Jugar Botón opciones 13.5.4 Menú de opciones Barra configuración volumen Barra configuración calidad grafica Botón regresar 65 13.5.5 Menú de selección de niveles Selección de nivel Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5 Nivel 6 Nivel 7 Nivel 8 Nivel 9 Nivel 10 Nivel 11 Nivel 12 Nivel de pruebas Botón regresar 13.5.6 Menú de creación de niveles Tipo cubo 0 1 r r 2 3 e e rg rg 4 5 e e r r rg rg 6ee 7ee rs rs rg rg e a a er ere s s ger ger rsa Botón rsa r r ea regresar ea sr sr a a r r Botón Probar Botón Guardar 66 14 BIBLIOGRAFÍA FERNÁNDEZ, Carmen. C# Básico. España: StarBook Editorial, 2009. 178p. ISBN 9788493689674. MICROSOFT. Microsoft official course 2124c programming with C#. 1ed. Estados Unidos: Microsoft, 2002.ISBN 9780758061201. MENARD, Michelle. Game Development whit Unity. 1ed. Estados Unidos: Course Technology, 2011. 352p. ISBN 978-1435456587. SMITH, Matt. Unity 4.x Cookbook. Estados Unidos: Packt Publishing, 2013. 386p. ISBN-13: 978-1849690423. BLACKMAN, Sue. Beginning 3D Game Development with Unity: All-in-One, multiplatform Game Development. Estados Unidos: Apress, 2013. 808p. ISBN-13: 978-1430248996. GOLDSTONE, Will. Unity 3x Game Development Essentials. 2ed. Estados Unidos: Packt Publishing, 2011. 488p. ISBN-13: 978-1849691444. LENGYEL, Eric. Mathematics for 3D Game Programming and Computer Graphics. Estados Unidos: Cengage Learning, 2011. 563p. ISBN-13: 978-1-4354-5886-4. BUCKLAND, Mat. Programming Game AI by Example. 1ed. Estados Unidos: Jones & Barlett Learning, 2004. 495p. ISBN-13: 978-1556220784. BOURG, David M. AI for game developers: Creating Intelligent Behavior in Games. 1ed. Estados Unidos: O’Reilly Media, 2004. 392p. ISBN-13: 978-0596005559. SKEET, Jon. C# in Depth. 3ed. Estados Unidos: Manning Publications, 2013. 616p. ISBN-13: 978-1617291340. NORTON, Terry. Learning C# by Developing Games with Unity 3D Beginner’s Guide. Estados Unidos: Packt Publishing, 2013. 292p. ISBN-13: 978-1849696586 LAMMERS, Kenny. Unity shaders and effects cookbook. Estados Unidos: Packt Publishing, 2013. 268p. ISBN-13: 978-1849695084. FUNGE, John. Artificial Intelligence for Games. 2ed. Estados Unidos: CRC Press, 2009. 896p. ISBN-13: 978-0123747310. 67 TAHA, Hamdy A. Investigación de Operaciones. España: Alfaomega Grupo Editor, 1996. ISBN-13: 978-9701501153. 68 15 CIBERGRAFÍA Ken Schwaber y Jeff Sutherland. Scrum.org. The Scrum Guide, [en línea]. Disponible en internet: <https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/ScrumGuide.pdf#zoom=100 > [citado en 30 de abril de 2014]. Unity Technologies. Unity3d.com. Learn with Unity [en línea] Disponible en internet<https://unity3d.com/learn> [citado en 30 de abril de 2014]. Unity Technologies. Unity3d.com. Keep your focus, work fast, have fun—finish it [en linea] Disponible en internet: <https://unity3d.com/unity/workflow> [citado en 30 de abril de 2014]. Microsoft. Microsoft Developer Network. Introduction to Unity, [en línea]. Disponible en internet: <http://msdn.microsoft.com/en-us/library/ff649614.aspx> [citado en 25 de abril de 2014]. Google Inc. Android.com. Develop in Android, [en línea] Disponible en internet: <http://developer.android.com/index.html> [citado en 20 de abril de 2014]. Wikipedia comunity. wiki.unity3d.com. UnityScript versus JavaScript, [en línea] Disponible en internet: <http://wiki.unity3d.com/index.php/UnityScript_versus_JavaScript> [citado en 30 de abril de 2014]. Paul Miller. Gamasutra.com, Top 10 Pitfalls Using Scrum Methodology for Video Game Development, [en línea] Disponible en internet: <http://www.gamasutra.com/view/feature/132121/top_10_pitfalls_using_scrum_.ph p?print=1> [citado en 25 de abril de 2014]. 69 16 ANEXOS ANEXO A Historias de usuario # BACKLOG ITEM (USER STORY) 1 2 3 4 5 6 7 8 9 STORY POINT Como usuario yo quiero poder entrar al juego 2 e iniciar una partida. Como jugador yo quiero poder controlar el 4 personaje Como jugador yo quiero poder usar los 4 3 poderes del personaje. Como diseñador de juego yo quiero crear 2 tableros nuevos y probarlos de forma fácil y sin necesidad de programación extra. Como usuario yo quiero poder ajustar las 1 opciones básicas, como el volumen del audio. Como diseñador de juego yo quiero poder 2 guardar los niveles creados para probarlos posteriormente. Como usuario yo quiero poder atacar a los 3 enemigos del juego. Como diseñador de juego yo quiero que exista 2 una continuidad en el juego, que no haya pantallas de carga sino una animación del personaje caminando de un nivel a otro. Como jugador yo quiero ver la historia del 3 juego. ITERACION Sprint 1 Sprint 3 Sprint 6 Sprint 2 Sprint 1 Sprint 4 Sprint 8 Sprint 2 Sprint 1 ANEXO B Sprint Backlog 16.1.1 Sprint 1 16.1.1.1 Criterios de aceptación: Crear el sistema básico de navegación del juego. Crear el sistema generación de niveles. 16.1.1.2 Tareas 1. Crear el archivo fuente del juego 70 2. 3. 4. 5. 6. Crear el menú principal de juego Crear la ventana de opciones Crear la pantalla de cargue y logos Crear las opciones ocultas de desarrollo Crear una grilla (rejilla) para los niveles de forma dinámica usando matrices. 16.1.2 Sprint 2 16.1.2.1 Criterios de aceptación: Importar los modelos de personajes y escenario. Crear un sistema lector de XML. 16.1.2.2 Tareas 1. Importar los modelos 3D 2. Importar las texturas. 3. Crear los materiales de cada modelo y asignar las texturas. 4. Definir la estructura del archivo XML a utilizar. 5. Crear un lector de archivos XML. 6. Cargar los datos del archivo XML en la matriz que crea los niveles. 16.1.3 Sprint 3 16.1.3.1 Criterios de aceptación: Crear los materiales. Agregar las animaciones del personaje principal Crear el sistema de control de personaje. 16.1.3.2 Tareas 1. Crear los materiales de cada modelo, asignándole sus respectivas texturas y mapas (normales, difusos y specular) 2. Importar las animaciones. 3. Configurar los loops en las animaciones. 4. Crear un sistema para selección del destino en la rejilla. 5. Crear un indicador visual del punto seleccionado. 6. Agregar una interfaz que muestre el camino que seguirá el personaje. 7. Hacer que el personaje rote y se desplace hasta el punto seleccionado. 16.1.4 Sprint 4 16.1.4.1 Criterios de aceptación: Crear un sistema de guardado de archivos XML. Convertir los diferentes bloques del nivel en prefabs. 71 Crear un editor de niveles. Agregar las animaciones al personaje y la opción de correr. 16.1.4.2 Tareas 1. Crear el archivo XML que contendrá los datos. 2. Crear un estándar de nombres de archivo para los diferentes niveles. 3. Crear o sobrescribir el archivo XML que contiene la información de los niveles. 4. Organizar y agrupar los bloques, para crear la cantidad necesaria de prefabs. 5. Crear la interfaz de creación de niveles. 6. Cargar los prefabs de los bloques. 7. Convertir el personaje en un prefab. 8. Añadir el sistema de lectura, carga y posterior guardado de los niveles. 9. Crear en árbol de estado de animaciones del personaje y las variables para el control de estas. 10. Añadir un botón de correr. 11. Crear un estado de “correr” para el personaje y modificar su animación y velocidad. 16.1.5 Sprint 5 16.1.5.1 Criterios de aceptación: Importar los modelos de personajes (enemigos) y escenario (escenografía y props). Configurar los enemigos y props asignándoles materiales y animaciones. 16.1.5.2 Tareas 1. Importar los modelos manteniendo la jerarquía de archivos. 2. Crear sus respectivos materiales y asignarles las texturas indicadas. 3. Asignarles animaciones a los modelos que las necesiten. 16.1.6 Sprint 6 16.1.6.1 Criterios de aceptación: Modificar la pantalla de menú inicial para que muestre el primer nivel. Agregar los dos primeros poderes a RAG (capa del zorro y flauta de los elementos) 16.1.6.2 Tareas 1. Agregar el poder del zorro. 2. Hacer que los enemigos no vean ni ataquen al personaje si tiene el poder activo. 3. Hacer que el personaje se convierta en zorro al activar el poder. 4. Agregar el poder de la flauta. 72 5. Hacer que se creen muros de planta. 6. Hacer que se creen caminos de enredaderas al usar la flauta. 7. Agregar la flauta y la animación de tocarla al personaje. 16.1.7 Sprint 7 16.1.7.1 Criterios de aceptación: Crear los 6 primeros niveles e incluirles la progresión del juego. 16.1.7.2 Tareas 1. Crear los 6 primeros tableros en el editor de niveles. 2. Editar los niveles para asignarles su respectivo fondo y escenografía. 3. Crear un sistema de continuidad al pasar de un nivel a otro. 4. Modificar la posición de la cámara al pasar de niveles. 16.1.8 Sprint 8 16.1.8.1 Criterios de aceptación: Añadir los 2 poderes restantes a RAG (Medallón de fuego y Báculo de roca). Crear la inteligencia artificial de los enemigos. Crear los 2 primeros enemigos. 16.1.8.2 Tareas 1. Crear una máquina de estados para los enemigos. 2. Implementar el algoritmo A* para búsqueda de rutas. 3. Implementar y probar el comportamiento de los 2 primeros enemigos. 4. Agregar el poder de fuego y roca a la interfaz. 5. Crear muros de fuego. 6. Crear muros de roca. 7. Destruir baldosas con el poder de roca. 8. Destruir muros y baldosas de planta con el poder de fuego. 9. Encender luces y candelabros con el poder de fuego. 10. Agregar el medallón y el báculo al personaje. 11. Agregar las animaciones al usar los poderes. 16.1.9 Sprint 9 16.1.9.1 Criterios de aceptación: Agregar detalles de iluminación y niebla a los escenarios. Ampliar la IA de enemigos para incluir enemigos dormidos y voladores. 73 16.1.9.2 Tareas 1. Crear un sistema de niebla en las partes más lejanas del nivel. 2. Crear niebla en el fondo de la caverna con una animación de movimiento. 3. Implementar los modos gráficos para demostrar el estado de los enemigos. 4. Modificar el sistema de movimiento y de detección de obstáculos para incluir los enemigos que vuelan. 16.1.10 Sprint 10 16.1.10.1 Criterios de aceptación: Crear mensajes y animaciones al recoger poderes o avanzar en el juego. Crear interfaz gráfica (HUD) con barra de mana del personaje. Actualizar la interfaz del juego para que se adapte al diseño del área gráfica. 16.1.10.2 Tareas 1. Cambiar las imágenes y ubicación de la interfaz. 2. Crear la barra de mana. 3. Agrupar los poderes en una barra y hacer que esta se oculte con un botón. 4. Pausar el personaje y enemigos al momento de una interacción con un cofre. 5. Animar al personaje y mostrar un mensaje cuando se obtiene un poder. 16.1.11 Sprint 11 16.1.11.1 Criterios de aceptación: Actualizar el juego modificando el movimiento del personaje para incluir 3 puntos de destino. (Rag) Personaje principal: corra, camine y que se mueva en la dirección que se necesita. 1 Enemigo que funcione con todos los moods. La implementación de los 12 niveles de juego. Interfaz gráfica finalizada. 16.1.11.2 Tareas 1. Cambiar el sistema de control de personaje. 2. Agregar botón de reinicio de selección de puntos. 3. Cambiar los modelos y animaciones a la versión más actual. 4. Agregar los moods al primer enemigo. 5. Completar la navegación por la aplicación. 74 16.1.12 Sprint 12 Los tableros deben tener un punto de guardado. Los enemigos deben estar texturizados. GUI en su versión final. Agregar animaciones a los puntos de guardado. Versión final del Producto Mínimo Viable compilada. 16.1.12.1 Tareas 1. Activar los checkpoints. 2. Agregar partículas y animación visual al checkpoint. 3. Actualizar las imágenes de la GUI. 4. Organizar la GUI de acuerdo al diseño. 5. Optimizar el juego. 6. Compilar versión para Android. 7. Compilar versión para PC. 75 ANEXO C Diseño de niveles Nivel 0. Tutorial de movimiento. Nivel 0.1 Dificultad: Básica Poderes habilitados al jugador: N/A Total de enemigos: 0 10 9 8 7 6 5 4 3 2 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 76 Nivel 0.2 Dificultad: Básica Poderes habilitados al jugador: N/A Total de enemigos: 0 10 9 8 7 6 5 4 3 2 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Nivel 0.3 Dificultad: Básica Poderes habilitados al jugador: N/A Total de enemigos: 0 77 10 9 8 7 6 5 4 3 2 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 78 Nivel 0.4 Dificultad: Básica Poderes habilitados al jugador: N/A Total de enemigos: 0 10 9 8 7 6 5 4 3 2 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 79 Árbol de clan. Nivel 1. Dificultad: Básica Poderes habilitados al jugador: Capa del zorro Total de enemigos: 1 Diseño del nivel: Nivel 2. Dificultad: Básica Poderes habilitados al jugador: Capa del zorro Total de enemigos: 2 Diseño del nivel: 80 81 Nivel 3. Dificultad: Básica Poderes habilitados al jugador: Capa del zorro Total de enemigos: 2 Diseño del nivel: Nivel 4. Dificultad: Media Poderes habilitados al jugador: Capa del zorro, flauta de los elementos Total de enemigos: 3 Diseño del nivel: 82 83 Nivel 5. Dificultad: Difícil Poderes habilitados al jugador: Capa del zorro, flauta de los elementos Total de enemigos: 2 Diseño del nivel: Nivel 6. Dificultad: Difícil Poderes habilitados al jugador: Capa del zorro, flauta de los elementos Total de enemigos: 2 Diseño del nivel: 84 85