sergio andres osma aponte uni

Transcripción

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
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
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
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
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
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
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
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
control del personaje.
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
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
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”.
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.
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.
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
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
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
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
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
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
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
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
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
 N/A
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
 N/A
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
 N/A
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
Diseño del nivel:
Nivel 2.
Dificultad: Básica
Diseño del nivel:
80
81
Nivel 3.
Dificultad: Básica
Diseño del nivel:
Nivel 4.
Dificultad: Media
Poderes habilitados al jugador: Capa del zorro, flauta de los elementos
Diseño del nivel:
82
83
Nivel 5.
Dificultad: Difícil
Diseño del nivel:
Nivel 6.
Dificultad: Difícil
Diseño del nivel:
84
85

sergio andres osma aponte uni

Transcripción

Documentos relacionados

Guía SBOK - Scrum, Agile Training