1

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

2

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

3

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

4.1 Objetivo general ................................................................................................................. 12

4.2 Objetivos específicos ......................................................................................................... 12

5 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

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

8 Marco teórico ............................................................................................................................ 20

8.1 Producto Mínimo Viable (PMV) ......................................................................................... 20

8.2 Videojuego ......................................................................................................................... 20

8.3 Metodología SCRUM .......................................................................................................... 21

4

8.4 Sprint .................................................................................................................................. 22

8.5 Roles SCRUM ...................................................................................................................... 22

8.5.1 Roles Principales ....................................................................................................... 22

8.5.2 Roles Auxiliares ......................................................................................................... 23

8.6 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

9 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

5

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

6

13.4.5 Sistema de carga y guardado de niveles ................................................................... 61

13.5 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

7

Anexo C .......................................................................................................................................... 76

Diseño de niveles ...................................................................................................................... 76

8

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

9

oportunidades de negocio y crecimiento, además de convertirse en patrimonio de

investigación y experiencia vivencial para nuevos proyectos.

10

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). 2 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.

11

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.

12

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.

13

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

14

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.

15

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.

16

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 Android (GooglePlay). https://play.google.com/store/apps/details?id=com.rovio.angrybirds&hl=es_419

17

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/ 7 Datos tomados del IGDA Colombia (Asociación de Desarrolladores de Videojuegos) http://igdacolombia.co/desarrolladores/

18

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 anuales8.

8 Datos tomados del El Tiempo, 28 de abril de 2014. http://www.eltiempo.com/archivo/documento/CMS-13897556

19

Ilustración 3. Videojuego AgryBirds de Rovio

20

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.

9 Orlando, Greg; Console Portraits: A 40-Years Pictorial History of Gaming. Wired News. 2007. 10 The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically

Successful Businesses. Crown Publishing. 2011. p. 25.

21

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 Ken Schwaber; Agile Project Management with Scrum. Microsoft Press, January 2004, 150p-158p 12 Ken Schwaber; Agile Project Management with Scrum. Microsoft Press, January 2004, 160p-165p

22

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/Scrum-Guide.pdf#zoom=100. p11. 14 Ibíd. p7.

23

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/Scrum-Guide.pdf#zoom=100. 16 Ibíd. p12.

24

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

25

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

17 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.

26

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 FERNÁNDEZ, Carmen. C# Básico. España: StarBook Editorial, 2009. 178p. 20 Kovacs, James (Septiembre 7, 2007). C#/.NET History Lesson.

27

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

28

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.

29

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.

30

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.

31

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:

32

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.

33

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.

34

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.

35

11 CRONOGRAMA

ACTIVIDAD TAREA Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6

S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4

Iniciar el

proyecto

Análisis y comprensión de los

requerimientos

Definición de los alcances y

límites del proyecto

Identificación y asignación de

roles

Identificación de riesgos

Administrar

Requerimientos

Determinación de

requerimientos Funcionales y

no funcionales

Creación y Documentación de

los diagramas de Casos de uso

Administrar la

iteración

Creación de los casos de prueba

Reunión inicial SCRUM,

definición de tiempos y fechas

para las reuniones y ciclos

necesarios.

Definir

Arquitectura

Identificar escenarios

Identificar patrones de negocios

Identificar elementos de diseño

relevantes

Desarrollar la

solución

Diseñar Pruebas de la

implementación

36

ACTIVIDAD TAREA Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6

S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4

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

Identificar y documentar

requerimientos adicionales

Corrección con base en las

pruebas

Documentación

del desarrollo

Crear y documentar de los

diagramas de Casos de uso

Crear casos de prueba

Crear documento de cambios y

control de versiones

37

ACTIVIDAD TAREA Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6

S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4

Iniciar la

documentación

y manuales de

juego

Iniciar manual de usuario

Iniciar Libro de diseño de

juego.

Desarrollar

incremento de

la solución

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

Probar la

versión

Realizar pruebas con los

jugadores

Corrección con base en las

pruebas

Preparar la

publicación del

juego

Validar las condiciones

necesarias para la finalización

del producto.

Finalización del

producto,

documentación

Terminar manual de usuario.

Terminar libro de diseño de

Juego.

Tabla I. Cronograma del proyecto teniendo en cuenta la metodología SCRUM

38

12 PRESUPUESTO

Talento Humano

Gasto Valor (COP) Tiempo (meses)

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 Valor (COP) Tiempo (meses)

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 Valor (COP) Tiempo (meses)

Total (COP)

Material Bibliográfico $ 200.000 - $ 200.000

39

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.

40

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.

41

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.

42

13.3.1.3 Definición de los casos de uso

Nombre del Caso

de Uso

Jugar

Resumen El Jugador podrá usar esta opción para ingresar al juego.

Jugador Sistema

Curso básico de

eventos

1. El Jugador selecciona la

opción jugar.

7. El Jugador interactúa con el

juego de acuerdo a las

instrucciones presentadas y

teniendo en cuenta la

mecánica de juego.

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.

6. El sistema habilita los

controles del juego.

Caminos

alternativos

N/A (No Aplica)

Caminos de

excepción

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.

43

Autor Sergio Osma

Fecha 30 de Octubre de 2014

Nombre del Caso

de Uso

Pausar partida

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 Sistema

Curso básico de

eventos

1. El jugador accede al menú

de pausa al pulsar el botón

“menú” o al presionar la tecla

“escape”.

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

N/A (No Aplica)

Caminos de

excepción

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

44

Nombre del Caso

de Uso

Volver al menú principal

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

eventos

1. El Jugador selecciona la

opción “Regresar al menú

principal”.

3. El Jugador confirma la

opción de ir al menú principal.

2. El sistema confirma si el

jugador quiere ir al menú

principal del juego.

4. El sistema cierra la partida

y se dirige al menú principal

del juego.

Caminos

alternativos

N/A (No Aplica)

Caminos de

excepción

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

de Uso

Reiniciar partida

Resumen El Jugador podrá acceder a esta opción para reiniciar el nivel

actual del juego.

Jugador Sistema

Curso básico de

eventos

1. El Jugador selecciona la

opción “Reiniciar partida”.

45

3. El Jugador confirma la

opción de reiniciar.

2. El sistema confirma si el

jugador quiere ir reiniciar el

nivel actual del juego.

4. El sistema cierra la partida.

5. El sistema carga

nuevamente el nivel actual.

Caminos

alternativos

Perder la partida.

Caminos de

excepción

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

de Uso

Cargar partida

Resumen El Jugador podrá acceder a esta opción para ingresar al juego

y continuarlo desde el último punto de guardado (Checkpoint).

Jugador Sistema

Curso básico de

eventos

1. El Jugador inicia el juego y

selecciona la opción cargar

partida.

2. El sistema carga la última

partida guardada.

46

5. El Jugador interactúa con el

juego de acuerdo a las

instrucciones presentadas y

teniendo en cuenta la

mecánica de juego.

3. El sistema configura la

partida con los parámetros

guardados.

4. El sistema habilita el

control del personaje.

Caminos

alternativos

N/A (No Aplica)

Caminos de

excepción

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

de Uso

Configurar opciones

Resumen El Jugador podrá acceder a esta opción para configurar las

opciones visuales y de sonido.

Jugador Sistema

Curso básico de

eventos

1. El Jugador inicia la

aplicación y selecciona la

opción “Configuración”.

3. El Jugador selecciona la

opción de configuración que

desea y ajusta los parámetros.

2. El sistema muestra la

pantalla de configuración del

juego.

47

4. El sistema aplica los

parámetros de configuración.

Caminos

alternativos

El jugador activa el menú desde el juego y oprime el botón

“Opciones”

Caminos de

excepción

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

de Uso

Salir

Resumen El Jugador podrá acceder a esta opción para cerrar la

aplicación y detener su ejecución.

Jugador Sistema

Curso básico de

eventos

1. El Jugador inicia la

aplicación y selecciona la

opción “Salir”.

3. El Jugador confirma que

desea salir.

2. El sistema muestra un

mensaje de confirmación.

4. El sistema cierra la

aplicación.

Caminos

alternativos

En el sistema operativo Android oprimir la tecla “escape”

desde el menú principal.

Caminos de

excepción

N/A (No Aplica)

Suposiciones El jugador quiere salir de la aplicación.

48

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

de Uso

Crear nivel

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

eventos

1. El diseñador de juego inicia

la aplicación y selecciona la

opción “Configuración”.

3. El diseñador de juego crea

el nivel utilizando los

elementos disponibles en la

interfaz.

3. El diseñador de elige como

guardar el nivel.

2. El sistema muestra la

pantalla de creación de

niveles.

5. El sistema guarda el nivel

de pruebas.

Caminos

alternativos

N/A (No Aplica)

Caminos de

excepción

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.

49

Autor Sergio Osma

Fecha 23 de Febrero de 2015

Nombre del Caso

de Uso

Probar nivel

Resumen El diseñador de juego podrá acceder a esta opción para

probar un nivel guardado.

Diseñador de juego Sistema

Curso básico de

eventos

1. El diseñador de juego

selecciona la opción “Probar”.

4. El diseñador de juego elige

el nivel que desea probar.

7. El Jugador interactúa con el

juego de acuerdo a las

instrucciones presentadas y

teniendo en cuenta la

mecánica de juego.

2. El sistema carga el listado

de niveles guardados.

3. El sistema muestra la

pantalla de selección de

niveles.

5. El sistema carga el nivel

guardado.

6. El sistema habilita los

controles del juego.

Caminos

alternativos

N/A (No Aplica)

Caminos de

excepción

N/A (No Aplica)

Suposiciones El diseñador de juego quiere crear o ajustar un nivel del juego.

Pre Condiciones N/A (No Aplica)

50

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.

51

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.

52

Configuración

Ilustración 7. Diagrama de componentes de configuración.

Juego

Ilustración 8. Diagrama de componentes de juego

53

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

Espera

Se crean

llamas en la

malla

seleccionada

Ataque con plantas

Ataque

Ataque de fuego

Es creada una enredadera que encierra al enemigo

Jugador

activa

comando

Enciende lámparas que ahuyenta los

murciélagos e ilumina el camino

Incinera los enemigos y los deja fuera de

combate

Encierra a los enemigos

Es una

lámpara

Si

No

54

13.3.3.1.2 Defensa

Espera

Es creado un

muro de

fuego en la

malla

Poder de las plantas.

Defensa

Poder del fuego

Es creado un

muro de plantas

temporal en la

malla

Jugador

activa

comando

Crea un muro de fuego

(temporalmente) que

detiene a los enemigos y

hace huir a los zombis y a

Frankye Vacío

Seca el agua en los

cuadros con agua y

deja libre el camino Si

No

Si

No

Crea un muro de plantas que

detiene a los enemigos

temporalmente (lo golpean) Vacío

Crea cuadros sobre los que

se puede caminar pero

tienen un tiempo de

duración.(Temporalmente,

el cuadro debe tener

plantas)

55

13.3.3.1.3 Evade

Esper

a

Se transforma en

un zorro que

mueve la cola y

las orejas

Poder de la

roca.

Evasión

Capa del zorro

Crea caminos

permanentes en

los vacíos de la

caverna

Jugador

activa

comando

Si

No

Destruye el cuadro y

recupera energía mágica

pero muy poca.

Vacío

Crea cuadros

permanentes de

camino.

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.

Mueve las rocas del

camino

Crea caminos permanentes en los vacíos de la

caverna

Poder de las plantas.

56

13.3.3.2 Diagrama de comportamiento de Enemigos

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.

Patrulla Detecta al

jugador Inhabilita al fantasma

Encuentra al jugador

Animació

n

fantasma

Golpea al

jugador

Fin del juego

Movimiento del

punto A al B Jugador Ataca

Jugador se esconde antes de

ser encontrado

Persigue al

jugador

57

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.

58

13.4.1.2 Diagrama de estados (comportamiento de enemigos)

Ilustración 10. Diagrama de estados de Inteligencia Artificial.

59

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.

60

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.

61

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)

62

13.5 INTERFAZ DE JUEGO

13.5.1 Diagrama de flujo de Interfaz

Cargue imagen de

Ananja

Cargue ventana

de inicio Magic

Cave

Inicio juego

Créditos

Historia juego

Omitir

historia

Videojuego Termina

Opciones Salir

Si No

Si

No

Configurar

Opciones

63

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.

Diseño final aplicando la guía de estilo del juego.

Ilustración 16. Interfaz gráfica del juego

Botón de

Cámara

Botón de

Caminar/Correr

Botón de

menú

Barra de poderes

Poder 1 Poder 2 Poder 3 Poder 4

Barra de energía

mágica

64

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)

65

13.5.3 Menú principal

13.5.4 Menú de opciones

Botón Jugar Botón opciones Botón

desarrollo

Botón salir

Barra configuración volumen

Botón

regresar

Barra configuración calidad

grafica

66

13.5.5 Menú de selección de niveles

13.5.6 Menú de creación de niveles

Botón

regresar

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 Botón

Guardar

Botón

Probar

2

r

e

g

r

e

s

a

r

3

r

e

g

r

e

s

a

r

4

r

e

g

r

e

s

a

r

5

r

e

g

r

e

s

a

r

6

r

e

g

r

e

s

a

r

7

r

e

g

r

e

s

a

r

Tipo

cubo

0

r

e

g

r

e

s

a

r

1

r

e

g

r

e

s

a

r

67

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.

68

TAHA, Hamdy A. Investigación de Operaciones. España: Alfaomega Grupo Editor, 1996. ISBN-13: 978-9701501153.

69

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/Scrum-

Guide.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].

70

16 ANEXOS

ANEXO A

Historias de usuario

# BACKLOG ITEM (USER STORY) STORY POINT

ITERACION

1 Como usuario yo quiero poder entrar al juego e iniciar una partida.

2 Sprint 1

2 Como jugador yo quiero poder controlar el personaje

4 Sprint 3

3 Como jugador yo quiero poder usar los 4 poderes del personaje.

3 Sprint 6

4 Como diseñador de juego yo quiero crear tableros nuevos y probarlos de forma fácil y sin necesidad de programación extra.

2 Sprint 2

5 Como usuario yo quiero poder ajustar las opciones básicas, como el volumen del audio.

1 Sprint 1

6 Como diseñador de juego yo quiero poder guardar los niveles creados para probarlos posteriormente.

2 Sprint 4

7 Como usuario yo quiero poder atacar a los enemigos del juego.

3 Sprint 8

8 Como diseñador de juego yo quiero que exista una continuidad en el juego, que no haya pantallas de carga sino una animación del personaje caminando de un nivel a otro.

2 Sprint 2

9 Como jugador yo quiero ver la historia del juego.

3 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

71

2. Crear el menú principal de juego

3. Crear la ventana de opciones

4. Crear la pantalla de cargue y logos

5. Crear las opciones ocultas de desarrollo

6. 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.

72

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.

73

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.

74

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.

75

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.

76

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

77

Nivel 0.2

Dificultad: Básica

Poderes habilitados al jugador:

N/A Total de enemigos: 0

Nivel 0.3

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

78

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

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

80

Á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:

81

82

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:

83

84

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:

85