desarrollo de un videojuegotauja.ujaen.es/bitstream/10953.1/4005/1/tfg_ruiz_ibáñez...mis amigos...

Esc

uela

Pol

itécn

ica

Sup

erio

r de

Jaé

n

UNIVERSIDAD DE JAÉN ESCUELA POLITÉCNICA SUPERIOR (JAÉN)

Trabajo Fin de Grado

DESARROLLO DE UN

VIDEOJUEGO

Alumno: Miguel Tomás Ruiz Ibáñez Tutor: Juan Roberto Jiménez Perez Dpto: Informática

Junio, 2016

DESARROLLO DE UN VIDEOJUEGO MIGUEL TOMÁS RUIZ IBÁÑEZ

ESCUELA POLITÉCNICA SUPERIOR DE JAÉN 2



Agradecimientos Quiero dedicar esta parte del documento a expresar mi más sincero agradecimiento a aquellas personas que han supuesto un apoyo durante el desarrollo de este proyecto: Mis padres, Miguel y Purificación, gracias a ellos estoy hoy aquí. Gracias por apoyarme y creer en que sería capaz de llegar hasta donde estoy a día de hoy. Mis amigos Miguel Peinado y Amador Mesías, por aguantarme cada vez que iba detrás de ellos pidiéndoles diseños, ayuda y consejo sobre el videojuego. A mi tutor, Juan Roberto Jiménez, por soportarme como alumno del TFG y tener toda la paciencia del mundo conmigo. A todos los amigos que me han aportado cualquier tipo de idea, aconsejado con cualquier diseño o simplemente mostrar su apoyo hacia mí durante el desarrollo del mismo. Y no menos importante a grupos musicales como Extremoduro o Trivium, gracias por hacer tan buenas canciones y amenizarme los momentos de desarrollo del proyecto, sin vuestras canciones esto tampoco habría sido posible. ¡MUCHAS GRACIAS!



Indice Capítulo 1 Introducción 7

1.1 Introducción al proyecto ................................................................................................................ 8

1.2 Propósito del proyecto ................................................................................................................. 11

1.3 Metodología ................................................................................................................................. 11

1.4 Objetivos ...................................................................................................................................... 11

1.5 Herramientas utilizadas ................................................................................................................ 12

1.6 Estructura del proyecto ................................................................................................................ 13

Capítulo 2 Estado del Arte 15

2.1 ¿Qué es Steam? ............................................................................................................................ 16

2.2 Secciones de Steam ...................................................................................................................... 17

2.3 Futuro de Steam ........................................................................................................................... 18

2.3.1 Steam OS 18

2.3.2 Steam Machines 18

2.4 Plataformas alternativas ............................................................................................................... 19

2.4.1 Diferencias entre Steam y el resto de plataformas 20

2.5 Juegos del genero ......................................................................................................................... 20

Capítulo 3 Introducción a Unity 25

3.1 ¿Por qué Unity? ............................................................................................................................ 26

3.2 Características de Unity ................................................................................................................ 27

Capítulo 4 Planificación y presupuesto 34

4.1 Metodología Scrum ...................................................................................................................... 35

4.1.1 ¿Qué es Scrum? 35

4.1.2 El proceso de Scrum 36

4.1.3 Beneficios de Scrum 37

4.1.4 Aplicación de Scrum sobre el proyecto 38

4.2 Planificación temporal .................................................................................................................. 39

4.3 Planificación de costos ................................................................................................................. 42

Capítulo 5 Análisis 47

5.1 Identificación de actores .............................................................................................................. 50

5.2 Objetivos ...................................................................................................................................... 50

5.3 Especificación de Requisitos ......................................................................................................... 53

5.4 Casos de Uso ................................................................................................................................ 63

5.5 Especificación de Casos de Uso ..................................................................................................... 64



Capítulo 6 Diseño 71

6.1 Arquitectura Lógica ...................................................................................................................... 72

6.2 Diagramas de clases de diseño ..................................................................................................... 72

6.3 Diagramas de estado .................................................................................................................... 79

6.4 Diagramas de secuencia ............................................................................................................... 82

6.5 Historia ........................................................................................................................................ 85

6.6 Estética del juego ......................................................................................................................... 85

Capítulo 7 Implementación 91

7.1 Organización del proyecto ............................................................................................................ 92

7.2 Controlador de juego.................................................................................................................... 94

7.3 Cartas ........................................................................................................................................... 96

7.4 Jugador ........................................................................................................................................ 98

7.5 Enemigo ....................................................................................................................................... 98

7.6 Menú de configuración................................................................................................................. 99

Capítulo 8 Pruebas 101

8.1 Pruebas generales ...................................................................................................................... 102

8.2 Pruebas realizadas en las iteraciones .......................................................................................... 103

Capítulo 9 Manual de instalación 106

Capítulo 10 Conclusiones 112

10.1 Futuras mejoras ......................................................................................................................... 114

Capítulo 11 Manual de usuario 116

Capítulo 12 Bibliografía 125



Capítulo 1 Introducción



1.1 Introducción al proyecto

Los videojuegos es una industria en constante auge desde su aparición, tras la segunda guerra

mundial, cuando comenzaron a surgir las primeras supercomputadoras programables, como ENIAC en 1946. La facturación del sector de los videojuegos supera actualmente a la facturación de la música y el cine juntos, estos datos nos muestran el increíble impacto e importancia de esta industria en nuestras vidas. A nivel nacional, la industria Española del videojuego, facturo 412, 4 millones de euros en 2014, lo que supone un incremento del 31% más que lo que se facturó en el año 2013. Estas cifras sitúan a la industria del videojuego entre las principales a nivel nacional en cuanto a contenido digital. Además de crecer en ingresos, el sector aumenta el número de empleos generados, esto se traduce en un mayor número de estudios, ya que en el año 2014 se han registrado un total de 70 nuevas empresas, lo que hace que se alcance la cifra de 400, lo que coloca a España como líder Europeo en cuanto a cantidad de estudios operativos dedicados al sector. [1] En cuanto a previsiones futuras respecto a facturación, se prevé una consolidación hasta el año 2018, crecerá a una tasa anual compuesta del 24,7%. Esto supone alcanzar en 2018 los más de mil millones de euros de facturación, triplicando los datos de 2013.

Figura 1.1.1: Estimación de crecimiento en millones de euros

La industria española está financiada principalmente por capital nacional (93%), se caracteriza por su gran capacidad de exportación, ya que, un 56% de sus ventas se producen en mercados internacionales.



Figura 1.1.2: Distribución de facturación (global)

Las principales empresas del sector del videojuego son PYMES, de hecho, el 96% de empresas de esta industria tienen menos de 50 empleados y la mitad de las empresas declaran tener menos de 5 empleados. En cuanto a volumen de negocio de la industria a nivel de CC.AA., la mitad de las empresas se sitúan en Comunidad de Madrid (25%) y Cataluña (24%). Destacar también comunidades como Comunidad Valenciana con un 14% de las empresas de videojuegos, seguida por Andalucía y País Vasco.

Figura 1.1.3: Distribución global empresas de videojuegos (España)



Podemos asumir con los datos nacionales que la industria está en un gran momento y que aún le queda mucho por evolucionar y mejorar en España.

Pasando del panorama español al panorama internacional, se prevé que el mercado de Asia-Pacifico (zona de países emergentes) genere alrededor de 30.300 millones de dólares, superando la cifra de los principales mercados occidentales. También ganarán peso, mercados como el sudafricano, que ya empieza a generar cifras similares a las de algunos países europeos, o el chino, el cual 2011 experimento un incremento del consumo del 34%, algo que se entiende por el desarrollo de Smartphone y la mejora de la conectividad. Los principales estudios de mercado la sitúan como la industria tecnológica con mayor proyección de crecimiento, las ventas por plataformas online (Steam, Origin, etc) o páginas dedicadas a comerciar con códigos de videojuegos (ingresar el código y descargar el juego en cuestión), hacen de esta industria unas de las más influyentes a nivel mundial. Debido a todo esto, en la realización de este TFG he intentado sumarme a una tendencia cada vez más en auge de uno de los sectores con mejores previsiones para los próximos años: el desarrollo de un videojuego en sus primeras fases y un estudio de su posible monetización en distintas plataformas, más concretamente, Steam. Centrándonos y para terminar esta introducción, y enfocándonos en la temática/genero del videojuego a desarrollar, Card Game War, es un videojuego desarrollando en corto plazo como single player, planificado de forma futura como multiplayer. Es un videojuego del género de estrategia por turnos/colección de cartas. Con una temática medieval/fantástica, representaremos el papel de un caballero, llamado Gedo que a través de las batallas de cartas, tendrá el desafío de pelear con diferentes adversarios. La estrategia será encontrar el método de derrotar a nuestro rival por medio de las cartas que tengamos en nuestro mazo creando múltiples posibilidades de pelea y opciones. Dentro de nuestro juego tendremos:

• Diferentes niveles de dificultad

• Múltiples enemigos

• Cartas con varios atributos

• Sonidos y múltiples efectos Para realizar todo esto, el proyecto se ha estructurado en distintos niveles que permitieran un mejor seguimiento en primer lugar de la idea original, de las tendencias que se llevan a cabo dentro del sector y la temática del videojuego y la temática del videojuego y para terminar, de la forma en que los estudios de desarrollo monetizan sus creaciones. En los próximos capítulos se desgranará en mayor profundidad todo lo mencionado en esta introducción, junto con la historia, reglas y mecánica de Card War Game.



Figura 1.1.4: Logo videojuego

1.2 Propósito del proyecto

Diseño y desarrollo de un videojuego online de duelo de cartas por turnos. Peleas contra una IA con un sistema de juego desarrollado desde 0 y diseñado 100% “customizable”.

1.3 Metodología

1. Búsqueda y revisión bibliográfica.

2. Estudiar el funcionamiento y desarrollo de scripts en Unity3D, utilizando C# como lenguaje de programación para el desarrollo del mismo.

3. Estudio, preparación e implementación de los elementos visuales y gráficos del

videojuego.

4. Implementación del código de cada uno de los elementos del juego, fase de pruebas y optimización del mismo.

5. Redacción de la memoria.

1.4 Objetivos

El principal objetivo de este TFG, es el desarrollo de una “demo” funcional de un videojuego 2D con Unity3D, comenzando desde la fase de ingeniería del software, siguiendo una estructura lógica y construyendo diferentes características sobre él. Esto hace que se divida en los siguiente sub-objetivos:



• Diseño del videojuego: Diseño de una sólida estructura de ingeniería del software.

• Estética del videojuego: Diseño de la estética visual que contendrá el videojuego, incluyendo el escenario de juego.

• Creación de una interfaz gráfica: Estadísticas, menús, sencilla e intuitiva.

• Creación del sonido del juego.

• Programación de las distintas funcionalidades del videojuego.

• Creación de una Inteligencia Artificial: Gestionada con diferentes niveles de dificultad.

Para la realización de este proyecto se ha utilizado, por familiarización y especificaciones del videojuego, Unity3D. También será necesario adquirir conocimientos de diseño gráfico (para el diseño de algunos objetos o procesar imágenes que puedan ser interpretadas por el motor gráfico), así como tener claros conocimientos sobre el desarrollo de software, comprendiendo todos los pasos y procedimientos necesarios para ello. Dentro de estos objetivos, tenemos otros objetivos a largo plazo:

• Agregar la posibilidad de partidas en red.

• Mejora visual del videojuego

• Más cartas con diferentes habilidades.

1.5 Herramientas utilizadas

Para el desarrollo de este proyecto se han utilizado las siguientes herramientas:

• Unity 3D: Esta herramienta nos proporcionara el motor gráfico. Unity es una plataforma de desarrollo flexible y sencillo para el desarrollo de juegos sencillos, interactivos y de cualquier género que se quiera crear, tanto en 2D como en 3D. Unity nos proporciona una gran documentación en varios idiomas además de un soporte a nivel de comunidad que responde dudas y aporta soluciones y diferentes buenas prácticas para un correcto desarrollo, además de múltiples tutoriales.

• MonoDevelop: IDE que se utilizara para desarrollar los diferentes scripts implicados en el proyecto.

• C#: Este lenguaje será el que se utilizara para el desarrollo de scripts. Se ha escogido este lenguaje por un uso más amplio frente a JavaScript. Además, que ya se cuenta con experiencia previa en este lenguaje frente al uso de JavaScript en esta plataforma.

• Gimp: Software para obtener las imágenes en formato correcto y procesarlas de forma que podamos trabajar de forma eficiente con ellas.

• Google Drive: Plataforma gratuita donde almacenaremos todos los cambios y mantendremos una constante copia de seguridad frente algún inconveniente.



1.6 Estructura del proyecto

Tras la breve introducción al proyecto en este capítulo, se expondrá brevemente el contenido de

los siguientes de forma breve para tener una idea de que se detallara en cada uno de ellos.

Dentro del capítulo 2 abordaremos una visión de los distintos elementos del videojuego y de los

videojuegos en general repasando su estructura básica de un videojuego y de cómo afectan a su

sistema de juego. También analizaremos la famosa plataforma Steam, objetivo donde se publicitara

el juego tras la demo y que tanto ha aportado a esta industria revolucionando el mercado.

En el capítulo 3 repasaremos el motor gráfico usado para el desarrollo del proyecto; se listara los

diferentes elementos que componen Unity3D así como sus características internas. Ventajas de

Unity frente a otros programas de desarrollo de videojuegos como es Unreal Engine o

jMonkeyEngine en java para desarrollar juegos, veremos cuál es el más usado. Se analizara el

creciente auge de los videojuegos para dispositivos móviles, el mercado que se está abriendo y el

fácil acceso a los mismos en la actualidad.

En el capítulo 4 incluiremos la parte de planificación y costes. Vendrán reflejadas las diferentes

iteraciones producidas durante el desarrollo.

El capítulo 5 será nuestro apartado principal del proyecto, en él se repasaran las distintas técnicas

la ingeniería del software, está planeado que este sea el apartado más amplio del proyecto. Como

un proyecto de desarrollo de software, se hará un análisis exhaustivo estudio de las diferentes

etapas de la ingeniería del software, acto seguido estas técnicas serán aplicadas en el desarrollo de

nuestro videojuego. De esta forma, definiremos de forma eficiente nuestro videojuego, incluyendo

distintos modelos de caso de uso, perfiles de usuarios, escenarios, etc. En el siguiente paso

tendremos que realizar la fase de diseño, comprende la creación del diagrama de clases, diseño de

datos, hasta el diseño de cada uno de los elementos de la mesa de juego. Por último, debemos de

repasar todo el proceso de creación verificando las pruebas para el cumplimiento de los requisitos

funcionales del videojuego.

En el capítulo 7 entraremos en la parte de implementación, se explicara la parte de desarrollo del

proyecto en la fase de implementación, así como también la diferente organización del videojuego,

pantallas, menús, etc.

El capítulo 8 abarca la parte de las pruebas relacionadas durante el desarrollo del proyecto, se da

una visión general en cuanto al rendimiento que se ha obtenido tras el desarrollo del mismo en

cuanto a calidad de imagen y procesamiento de eventos dentro del sistema, dentro de unos

tiempos aceptables.

El capítulo 9, se expondrá un manual de instalación del juego, se detallaran los pasos a seguir para



poder probarlo tanto para Windows como para Mac y otras alternativas.

El capítulo 10 englobara la parte de conclusiones que se han obtenido tras la realización del

proyecto, al igual también se agregara una sección de futuras mejoras que se realizaran sobre el

videojuego.

En el capítulo 11, contiene un breve manual de usuario con un resumen sobre las acciones y

posibilidades que tendrá el jugador dentro del juego así como unas instrucciones para saber cómo

comenzar a interaccionar con el juego.

Capítulo 12, bibliografía de esta memoria, donde se indicara de donde se han ido obteniendo los

diferentes datos indicados en este documento.



Capítulo 2 Estado del Arte



En este capítulo se analiza el entorno en el que se desenvuelve el TFG, comparándolo con juegos

de la actualidad y las ventajas de un desarrollo multiplataforma en la actualidad.

La industria del videojuego tiene un amplio abanico de plataformas donde los consumidores, según

el hardware (Pc, consola, móvil, etc), adquieren diferentes tipos de juegos según las necesidades,

por ejemplo, la industria de los videojuegos móviles, un tipo de juegos mucho más “casual” ha

crecido en los últimos años gracias al precio y facilidad de adquirirlos, mientras que los usuarios de

PC y consola son usuarios más exigentes y adquieren juegos con unas prestaciones superiores que

por ejemplo los de plataforma móvil.

Existen plataformas para móviles, como google play. Para ordenadores, independientemente del

sistema operativo, tenemos Steam, Battlenet, Origin entre otras muchas. Los otras plataformas son

Xbox live y PlayStation Network, respectivas para las consolas xBox y PlayStation.

En este TFG nos centraremos en Steam puesto que nuestro objetivo es publicar nuestro videojuego

en esta plataforma disponible para PC, Mac y Linux.

2.1 ¿Qué es Steam?

Steam es una plataforma de distribución de contenidos, gestión digital de derechos,

comunicaciones y servicios multijugador de Valve Corporation, lanzada en el año 2003. La

plataforma está disponible tanto para grandes empresas como para desarrolladores

independientes de videojuegos. Los sistemas operativos que soportan Steam, son los siguientes:

Linux, Microsoft, Windows, Mac, X2, PlayStation 3, iOS y Android, los 3 últimos están de manera

parcial.

En cuestión de gestión digital de derechos (DRM), el jugador puede instalar los juegos adquiridos en

varios dispositivos a través de la plataforma. Es necesario estar conectado a internet para

autenticarse o activar el modo offline, siempre que se haya descargado previamente el contenido

para el que se va a ejecutar y Steam tengas las credenciales en memoria local. Este sistema está

disponible a través de Steamworks a los desarrolladores, además de poder incluir el propio DRM de

la propia empresa.

Otro de los servicios que posee es Steam Cloud, es un sistema para guardar archivos en la nube

tales como partidas, pantallazos dentro del juego u otro archivo vinculado a la cuenta. Esto permite

que desde varios dispositivos se posean las partidas y datos guardados en cualquier juego,

estadísticas, logros u otros detalles de los que se quiera tener siempre en el almacenamiento de la

cuenta. El servicio es voluntario y se puede activar o desactivar cuando se desee.



Steam posee otra medida antirrobo de cuenta, Steam Guard, este sistema permite asociar una

cuenta a un equipo concreto. Si esa cuenta se quiere usar en otro equipo ha de autorizarse su uso

por parte del dueño, mediante correo electrónico, o código enviado al móvil para validar la

autorización.

Para obtener todos estos servicios, un usuario deberá registrarse, en la plataforma y todo producto

adquirido se vinculara al mismo. [3]

2.2 Secciones de Steam En este apartado hablaremos de las distintas secciones que posé la plataforma de Steam y las funcionalidades que tiene.

• La tienda, la que se accede por defecto al iniciar la aplicación. En ella aparecen los juegos

más recientes, ofertas diarias y promociones especiales (muy comunes dentro de la

plataforma), los juegos comprados dentro de esta tienda son únicamente en versión digital.

Los pagos se pueden realizar a través de tarjeta, mediante SteamWallet (cartera virtual de

Steam) o por tarjetas prepago de Steam que se pueden adquirir en algunas tiendas

especialidades o grandes almacenes. Dentro de la tienda también se pueden adquirir juegos

totalmente gratuitos o juegos de pago durante un breve periodo de tiempo establecido por

Steam.

• Biblioteca. En esta sección podemos observar todos los juegos que tenemos dentro de

nuestra cuenta , ya sean adquiridos mediante compra en la tienda de Steam , tanto

introducidos por código del juego físico o un juego externo para acceder a él como si fuese

un acceso directo , sin embargo, para este último caso no contamos con los servicios

ofrecidos por Steam.

• Comunidad. Esta es la parte más interesante de cara a este TFG. Dentro de la sección de

comunidad tenemos la parte de inicio, las actualizaciones sobre los juegos que han sido

realizadas o que se va a proceder a realizar y los juegos que han ido subiendo los distintos

usuarios de la plataforma, juego diseñados por ellos mismos.

Entre las distintas partes de la comunidad, hay una sección donde los usuarios pueden subir

sus imágenes y compartirlas para que todos los usuarios vean pantallazos de sus partidas.

Artwork, imágenes creadas por usuarios de personajes de videojuegos, escenarios u otro

similar relacionados con juegos de la comunidad, estas imágenes pueden ser votadas y en

algunas ocasiones pueden ser premiadas con diferentes trofeos, juegos o dinero metálico.

Todas estas secciones de comunidad están incluidas en su inicio, además de en un buscador

para poder localizar cualquier contenido dentro de esta sección o dentro de sus



subsecciones.

Otra sección de comunidad es el foro de discusiones, donde se pueden encontrar guías para

juegos, logros, preguntas sobre herramientas de la comunidad, servidores y aportaciones al

foro por parte de los usuarios.

Workshop, este apartado es donde los usuarios pueden descargar contenido creado por

otros usuarios o subirlo si lo han creado ellos mismos. Es famoso el contenido de esta

sección tales como modificaciones en Skyrim o Team Fortress 2, alterando el entorno y

haciendo el juego muchos más dinámico y divertido por medio de esas modificaciones.

Greenlight, es un sistema el cual la comunidad de usuarios decide que juegos entran en la

tienda de Steam. Los desarrolladores de la comunidad, suben información, capturas de

pantalla y videos de lo que están desarrollando o quiere desarrollar, de esta forma, buscan

un poco el apoyo de la comunidad para que su producto sea elegido para su posterior

distribución. Los desarrolladores también tienen la posibilidad de tener un feedback por

parte de los otros medio de la comunidad, por medios de críticas hacia su producto, el

desarrollador podrá valorar esos comentarios con votos positivos o negativos y además

enfocar su proyecto teniendo en cuenta los feedback recibidos.

2.3 Futuro de Steam En este apartado se explica el futuro de Steam y sus planes para seguir revolucionando el mercado con diferentes actualizaciones tanto a nivel hardware como software.

2.3.1 Steam OS

Steam OS será un sistema operativo gratuito, basado en Linux, diseñado para jugar y ver contenido

multimedia desde las Smart tv. Este sistema operativo tiene 4 características principales:

1. Retransmisión en casa: Para ello, tienes que encender en PC, Mac o Linux tu aplicación

de Steam y se retransmitirá todo automáticamente en la televisión

2. Se tendrá la posibilidad de visualizar series, películas, música a través de la plataforma

3. Ahora se podrá “Jugar en familia”, llamado Family Sharing, esta opción permitirá

compartir juegos dentro de tu televisión con otra gente presente físicamente, por

turnos, y almacenar el proceso y avance de todos en Steam Cloud.

4. Opciones de familia: Se podrán adaptar el contenido que quieras que sea visible a través

de Steam OS por otros usuarios, tanto juegos como contenido multimedia.

2.3.2 Steam Machines



Tras el desarrollo de Steam OS, la compañía plantea el lanzamiento de consolas hardware. El

problema aun para la compañía es el exceso de coste que cuesta ya que es una maquina muy

exigente.

Aún están desarrollando diferentes variaciones en cuestión de componentes y gama de calidad.

Para el primer prototipo, valorado en 999$, se ha probado con una beta cerrada de 300 usuarios.

Aun habrá que esperar para una versión final de estas Steam Machines.

Aun habrá que esperar para una versión final de estas Steam Machines.

2.4 Plataformas alternativas

Steam ha sido escogido para la publicación del videojuego porque esta para prácticamente

cualquier sistema operativo y plataforma. Además, de la posibilidad de subir tú juego y tener la

posibilidad de llegar a monetizarlo, sumándole todo lo anterior mencionado sobre la comunidad ha

sido el motivo por el que se ha detallado y por lo que el objetivo tras finalizar el videojuego seria

subirlo para lograr recuperar el tiempo invertido de forma monetaria.

A continuación, se detallaran alternativas de plataformas de videojuegos con diferentes

características:

• Origin: Plataforma desarrollada por Electronic Arts (EA), similar en cuanto al

almacenamiento de juegos, pero únicamente los de la propia marca de EA (FIFA, Battlefield,

The sims, etc). No tiene una comunidad tan amplia como la de Steam y tampoco permite

subir juegos desarrollados por los propios usuarios, una de las diferencias con Steam es la

revolución respecto a permitir jugar a juegos por cuota mensual, es decir, por 4€ al mes

puedes probar diferentes juegos pero sin tener la propiedad sobre los mismos. [38][39]

• Uplay: Software de administración de videojuegos, similar a Origin puesto que ha

desarrollada por Ubisoft para exclusivamente poder a los juegos de la compañía (Assasin

creed, Silent Hunter, The crew), sobre diferente plataformas (Xbox, PlayStation 4, PC, etc).

Uplay cuenta con una comunidad más reducida que Steam y Origin además de sufrir más

caídas de servicio por errores de seguridad informática. [40]

• Rockstar Games Social Club: Servicio de gestión de videojuegos en línea de la compañía

Rockstar, al igual que las demás alternativas a Steam, se centran únicamente en productos

que desarrollan, juegos como Grand Theft Auto, Midnight Club o Max Payne. Esta

plataforma tiene un enfoque mucho más centrado en red social e intentan que los

jugadores compartan logros e interactúen entre ellos para destacar en el mercado. [41]



2.4.1 Diferencias entre Steam y el resto de plataformas Podemos observar como entre Steam y las plataformas alternativas tienen visiones distintas sobre el mercado con corrientes alternativas de ventas, comunidad, etc. Las corrientes alternativas nos ofrecen productos únicamente desarrollados por la propia marca, sin posibilidad de que otros usuarios puedan subir sus productos o limitar a productos de pago. Estas comunidades alternativas suelen tener un menor número de usuarios y mucho menos activos que en Steam. La corriente de Steam es una corriente mucho más abierta, orientada a la participación del usuario desde el desarrollo hasta la prueba, incluyendo muchos juegos gratuitos de diferentes plataformas.

2.5 Juegos del genero

En los últimos años, el género, estrategia/Juego de cartas coleccionables, ha ganado mucha fuerza y un amplio mercado en cuanto a beneficios conseguidos. El ejemplo más claro es Hearhstone, el más famoso del género, que, con datos de Agosto de 2015, tiene 9 millones de usuarios en plataformas móviles y 8 millones en plataforma PC/Mac. [27]. Este género, actualmente en auge, siendo “casual”, lo que asegura que en poco tiempo puedes conseguir que el jugador disfrute de una gran experiencia sin necesidad de dedicar una cantidad excesiva de horas. Otros juegos de género similar a Card Game War: - La saga Magic Duels of the Planeswalkers: Es una exitosa saga de juegos procedente del famoso mercado de cartas Magic, existente desde hace décadas y muy popular entre varias generaciones.

Figura 2.5.1: Portada Magic The Gathering



Desde 2010 sacaron su primera versión digital en Steam simulando el exitoso juego dentro de plataformas de PC, con versiones posteriores su éxito se fue incrementando e incluyendo mejoras como partidas multijugador, múltiples modos de juego, personalización de mazos y en su última versión de 2015 posibilita su uso en Smartphone. Descarga gratuita desde la play store o http://magic.wizards.com/es/content/magic-duels [42]

- Hearhstone: Tras los éxitos de Blizzard con World of Warcraft (llegando a 10 millones de subscripciones en todo el mundo) y la saga Diablo, el gigante de los videojuegos se atrevió con el mundo de los juegos por turnos basándose en el mundo Warcraft para diseñar las criaturas del juego.

Figura 2.5.2: Imagen promocional Hearhstone

Con una dinámica similar a Magic pero con aspectos y metodologías distintas, este es el juego que actualmente más dinero le hace ganar a Blizzard, un total de 20 Millones de dólares al mes, con la diversión que proporciona un juego algo casual con la característica que es ‘free to play’ lo ha convertido en tan solo 1 año de su lanzamiento y 2 de su beta cerrada en el juego del genero más exitoso del momento. Descarga gratuita en: http://eu.battle.net/es/ [35]

-Card Hunter: Juego de estrategia para navegador, combina colección de cartas con batallas sobre

tablero. Los desarrolladores de este juego de cartas son algunos que participaron también en el

desarrollo de Magic The Gathering.



Figura 2.5.3: Icono de inicio Card Hunter

Primero fue lanzado para navegador con tecnología flash en septiembre de 2013, posteriormente,

en julio de 2015 fue lanzada una versión de escritorio para Windows y OS X. El gameplay de este

juego está basado en un tablero que simula un mapa de una mazmorra, sigue una temática muy

parecida a dragones y mazmorras, donde los personajes son tres con las diferentes clases que

posee el juego. Las cartas sirven para dar habilidades a los personajes, hechizos o posibilidad de

avanzar más posiciones dentro del tablero. Con descarga gratuita en su web oficial:

http:/www.cardhunter.com/ [36]

-HEX TCG: Juego de multijugador masivo online de intercambio y juego de cartas (MMOTCG),

creado por Cryptozoic Entertaiment. Es el primer juego del género que fue creado. Lanzado en

2013 como beta cerrada.

Figura 2.5.4: Imagen promocional Hex: Shards of Fate



Juego muy similar a la versión online de Magic The Gathering, con versiones para PC, iOS y Android.

De descarga gratuita en su web: https://www.hextcg.com [37]

Como se puede apreciar, hoy en día para que un juego triunfe en la red ha de ser gratuito, con

revisiones constantes y adaptado a las necesidades de las jugadores sin perder la esencia que lo

llevaron a ser un éxito, es por este motivo que el principal aliciente de un videojuego de este

género es la diversión y el entretenimiento, diferenciándose de otros competidores en detalles que

hagan del mismo una experiencia única.



Capítulo 3 Introducción a Unity



En este capítulo se introducirá en el motor de juego gráfico Unity 3D, funciones,

características y modos de uso. A la hora del desarrollo de este proyecto se ha aprendido de forma

autónoma, por prácticas de la asignatura de desarrollo de los videojuegos, a través de tutoriales y

en comunidades/foros en internet.

3.1 ¿Por qué Unity?

Se ha decidido hacer uso de la plataforma de desarrollo Unity3D, debido a su gran potencial para la

creación de videojuegos y su capacidad de integración multiplataforma, tanto PC, Mac, además de

para consola (PlayStation, Xbox) como para dispositivos móviles (IOS, Android), permitiendo

desarrollar y exportar juegos a diferentes plataformas de forma fácil y rápida solo cambiando

algunas configuraciones según la plataforma y el tipo de desarrollo elaborado.

Inicialmente se trataba una herramienta para desarrollo de juegos en 3D , por lo que muchos

desarrolladores para juegos 2D utilizaban otras plataformas como Cocos2D, pero Unity3D en su

actualización de la versión 4.6 incorporo la posibilidad de desarrollar videojuegos en 2D,

incorporando físicas, cámaras y otros elementos en 2D.

Otra de las ventajas de Unity es la posibilidad de programar en diferentes lenguajes a la vez,

permitiendo usar C#, Javascript o Boo, lenguajes más simples que C++ (usado por Unreal Engine) y

eficientes para el desarrollo en Unity, permitiendo solo centrarse en funcionalidades propias del

juego y no teniendo que estar pendiente de gestionar la memoria y otros inconvenientes que

puedan surgir, optimizando el ahorro de tiempo. Unity posee un editor gráfico muy simple e

intuitivo.

Figura 3.0: Estructura Unity



Todas estas ventajas hacen de Unity3D uno de los editores más potentes para la creación de

videojuegos.

Entre las desventajas podemos encontrar el precio de su versión pro es bastante caro y que no se

puede retirar el logo de Unity a la hora de cargar el juego dentro del dispositivo donde se quiera

lanzar. [2] [14] [25]

3.2 Características de Unity

La mayoría de los proyectos en Unity en 3D se apoyan en la utilización de Assets (paquetes de

recursos), los cuales contienen GameObjects ya preparados para su uso, materiales, physics,

scripts, etc. Unity dispone de una pestañita a la que se tiene acceso a la Asset Store, una tienda

donde se pueden descargar Assets de pago o gratuitos desarrollados por otros desarrolladores

evitando realizar trabajo ya programado de formas más eficiente para evitar redundancias y ganar

tiempo, se puede acceder a la Asset Store a través de un navegador web al igual que por el propio

motor gráfico teniendo una cuenta en Unity. Otra de las ventajas de este motor gráfico es la

comunidad internacional que proporciona, al ser gratuito y de fácil acceso existen temas con

preguntas que pueden solucionar problemas que aparezcan durante el desarrollo, una muy buena

ayuda si se va a comenzar a utilizar por primera vez este software tan potente.

La interfaz de Unity es bastante intuitiva y sencilla, resulta bastante sencilla familiarizarse en cortos

periodos de tiempo. Ahora, pasaremos a mostrar las diferentes partes de esta interfaz:

1. Project: Dentro de esta sección se muestra la estructura que toma el proyecto conforme se va

desarrollando, dentro de esta parte podemos ver Assets que incluyen recursos a usar en las escenas

del videojuego, GameObjects, etc.

2. Hierarchy: Objetos que están en la escena actual.

3. Inspector: Esta es de las secciones más importantes dentro de un proyecto de Unity 3D, en ella

se muestran las características y atributos del objeto seleccionado, se pueden observar también los

scripts adjuntados al mismo.

4. Scene: Las escenas se utilizan para construir niveles, pantallas, se pueden añadir dentro de forma

individual distintos recursos, objetos y elementos según se desee.



5. Game: Sección en la que se puede preevisualizar el aspecto del juego conforme se esté

desarrollando. Se tendrá especial atención en la resolución de esta pestaña o en el AspectRatio, en

este proyecto utilizaremos distintas resoluciones dependiendo del dispositivo o de las medidas de

la pantalla en donde se ejecute.

6. Console: En esta sección se muestra los mensajes de error, informativos, bug, etc.

7. Game Controller:

Play: Ejecuta/detiene el juego.

Pause: Este botón se utiliza para pausar el juego, permite detener la escena o el

frame en el momento exacto sin necesidad de detener el juego por completo.

Figura 3.1: Interfaz de Unity3D

El videojuego a desarrollar es un videojuego en 2D, no se requerirán materiales 3D tales como físicas o materiales en tres dimensiones. Para materiales, utilizaremos materiales en 2D, en nuestro Unity utilizaremos Sprites, mapas de bits en 2D que se dibujan en un destino de representación sin usar la canalización de transformaciones, iluminaciones o efectos. A la hora de empaquetar Sprites en spritesheets reduce la memoria utilizada en el proyecto; Unity permite dividir los Sprites de un conjunto. El método para utilizar Sprites es cargar las imágenes y en su Inspector los cargamos como Sprites en la máxima comprensión.



Los videojuegos en Unity se apoya en GameObjects (objetos de juego), estos objetos tienen una característica en común, representados en la figura 3.2.

Figura 3.2: Transformaciones de un GameObject

Transform indica la posición, rotación y escalado del objeto, ambas variables están destinadas en

las 3 dimensiones(X, Y, Z), nosotros en este proyecto solo trabajaremos con X e Y,

A estos GameObjects se le pueden añadir numerosos y distintos Componentes (efectos, físicas,

audios, scripts, materiales, renders, etc...) y estos componentes dan esa gran versatilidad a nuestras

pantallas/niveles a estos objetos de juego.

Unity tiene otro componente muy potente llamado Prefab, son objetos definidos con unos

componentes y características dispuestas para reutilizar tantas veces se quiera con tan solo

arrastrarlos a la escena o al árbol del proyecto. (¡Atención, al modificar un Prefab dentro de la

escena es necesario borrar el predefinido y agregar el modificado a la carpeta o el lugar donde se

estén guardando!).

Aquí indicaremos algunos de los componentes más útiles y básicos de los GameObject:

• Sprite Renderer: Convierte un objeto en un Sprite 2D.

• Animator: Permite a un objeto tener diferentes estados de animación para utilizar en el

juego.

• Physics 2D: Se utiliza para crear colisiones en un juego 2D.

• RigidBody: Característica que se añade a un GameObject para interactuar con los elementos

del juego.

• Camera: Convierte un objeto en una cámara o para añadir a un personaje una camera de

seguimiento sobre el mismo.

• Particle System: Convierte un objeto en un generador de partículas o se le añade uno ya

diseñado a un objeto existente.



• Script: Componente diseñado para añadir código y funcionalidades programadas

(principalmente C# y JavaScript), gracias a los scripts se puede dotar de distintas

funcionalidades a los objetos.

Unity se compone principalmente de objetos de juego o también denominados GameObjects(a

partir de ahora en el documento a los objetos de juego se les denominara de esta forma), que

tienen distintos componentes, pero, ¿Cómo podemos hacer que un objeto tenga vida, ataque, este

animado, etc? Esta es la parte fundamental implementada por los scripts, donde se programan esos

comportamientos y añadir funcionalidades al videojuego. Por ejemplo, mover cartas, campos de

visión, activar distintas funciones según acciones propias, etc. Aquí un ejemplo:

Figura 3.3: Componentes de un GameObject

En cada script se deberá de programar el código en función de las características que adquiera el

objeto en cuestión. Una de las características más comunes de los scripts de Unity es que la

mayoría de ellos han de heredar de la clase MonoBehaviour, esta clase es la principal clase de

Unity, esta clase dispone de las distintas funciones que siguen el ciclo de vida (figura 3.4) como

Start (), que se utiliza cuando comienza la carta del script una única vez o Update () – que se ejecuta

una vez cada frame del juego.



Figura 3.4: Ciclo de vida MonoBehaviour

Unity3D dispone de distinto tipo de funciones, un ejemplo de ellas es Couroutine (corrutina) que

funciona pausando la ejecución del código y continuar con él en el siguiente frame. Aquí vemos un

ejemplo de su declaración:

Funcion () {yield return ;}

IEnumerator funcion () {yield return ;}

La sentencia de retorno yield return se encarga de pausar la ejecución y reanudarla en el siguiente

frame. Para iniciar esta corrutina se debe llamar a la función StartCouroutine (funcion),



normalmente la función devuelve el número de segundos que estará pausado el juego. Este tipo de

funciones se utilizan cuando no se necesita ejecutar funciones o ciertas acciones como sería

necesario hacerlo en el Update (), de esta forma se reduce el número de comprobaciones que se

realizarían si en cada frame se hiciesen comprobaciones, esto posibilita una mayor fluidez dentro

del juego.

Figura 3.5: Arquitectura de Unity3D

La versión 5 de Unity introduce nuevas mejoras como un mejor acceso a la API para realizar tareas de networking de forma más sencilla que versiones antiguas donde tenías que programar a un más bajo nivel para conseguir que funcionase de manera eficiente. Y también se incluyen aspectos de mejoras en la creación de IU con mayor capacidad de personalización. Y una mayor versatilidad sobre dispositivos móviles. Todas estas características hacen de Unity3D una potente herramienta para desarrollar videojuegos, un software usado por grandes empresas y por programadores freelance, haciendo una de las herramientas más importantes del mercado de los videojuegos.



Capítulo 4 Planificación y presupuesto



En este capítulo describiremos la metodología seguida durante el desarrollo de este TFG. Se

ha escogido un método iterativo, los requisitos han sido previamente definidos como vienen

descritos en puntos siguientes. El objetivo de esta metodología es que tras cada iteración, con sus

diferentes fases, aporte un valor añadido al proyecto, de esta forma, podemos decir que es una

metodología ágil iterativa, puesto que se producen diferentes iteraciones y además incremental,

como hemos indicado anteriormente, cada vez que se libera una iteración, se está incrementando

el valor del proyecto con nuevas funcionalidades. En la figura 4.1, podemos ver el ciclo de vida que

se aplicara al proyecto para su desarrollo. [33]

Figura 4.1: Ciclo de vida de un proyecto Scrum

4.1 Metodología Scrum

Dentro de esta sección se pretende explicar qué clase de metodología es Scrum y porque su gran uso actualmente. También nos centraremos en el proceso y fases que utiliza al igual que los beneficios que nos aporta utilizar este tipo de procesos aplicados a proyectos software.

4.1.1 ¿Qué es Scrum?

Scrum es una metodología ágil y flexible para gestionar el desarrollo de software. Dentro de Scrum

se siguen un conjunto de buenas prácticas para trabajar colaborativamente, en equipo y así poder

obtener el mejor resultado posible a la hora de desarrollar un proyecto. Estas prácticas están

basadas en unos estudios en donde se aplican métodos para maximizar la productividad de un

equipo de trabajo.



En Scrum se realizan entregas parciales y regulares del producto final, estas entregas se priorizan

por el beneficio que le supondría al usuario. Por este motivo, Scrum está especializado en entornos

complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o

pocos definidos.

Gracias a los entregables a cliente, Scrum permite al cliente observar el avance del desarrollo del

software, comprobar si se está desarrollando de acuerdo a lo esperado y ver el rumbo que está

tomando el desarrollo del mismo.

4.1.2 El proceso de Scrum

Scrum es una metodología basada en iteraciones, cada iteración dura aproximadamente entre 2

semanas y 1 mes. Cada iteración tiene que proporcionar un resultado completo, un incremento

sobre el producto final, ese incremento ha de ser funcional o implementar alguna función sobre el

último incremento para que el cliente pueda comprobar su avance.

Figura 4.1.1: Ejemplo de iteraciones Scrum

El proceso de desarrollo de cada una de las iteraciones parte de una lista priorizada de objetivos. El

cliente prioriza esos objetivos según sus necesidades, priorizando sobretodo en función del valor

aportado de cada una de las funcionalidades aplicadas, repartiéndose así en diferentes entregas.

Planificación de las tareas

El primer día de cada iteración se realizara una reunión en donde:



• Se realizara con el cliente, esta metodología implica estar en un contacto estrecho con el

cliente. El cliente ha de entregar una hoja de objetivos, ha de priorizar os que más

interesa que sean implementados.

• Se planifica la lista de tareas para esa iteración de manera que el equipo de desarrollo se

compromete al desarrollo de los requisitos establecidos en dicha lista. Se estima un

tiempo para cada una de esas tareas, un esfuerzo y un valor como datos objetivo dados

por el equipo para planificar correctamente la iteración.

Ejecución de la iteración

Cada día de cada iteración, se realiza una reunión para discutir los puntos y tareas que se realizaran

durante ese día, así como los avances realizados. Se analiza también las posibles interrupciones y o

inconvenientes aparecidos. Esta reunión diaria no debe tener una duración superior a 15 minutos.

Inspección y adaptación

El último día de la iteración, se realiza una reunión para analizar los resultados y revisar el trabajo

elaborado.

• Demostración. El equipo ha de presentar al cliente el entregable elaborado durante esa

iteración para que compruebe los requisitos estipulados al inicio de la iteración. El cliente

analiza y estudia si se ha implantado todo como se quería y se comprueba que todo esté

según lo esperado.

• Retrospectiva. El equipo analiza cómo ha sido su manera de trabajar y cuáles son los

problemas que podrían impedirle progresar adecuadamente, para así poder mejorar el

trabajo del equipo

4.1.3 Beneficios de Scrum

• Cumplimiento de las expectativas: El cliente establece el valor para cada historia de

usuario/requisito del proyecto, el equipo establece el tiempo y la prioridad para cada una

de estas historias de usuario.

• Flexibilidad a cambios: El proceso de desarrollo de software ha de ser flexible ante cambios

en alguno de los requisitos generados por la necesidad del cliente o evoluciones del entorno

en el que se desarrolle. Scrum es una metodología diseñada para adaptarse a cambios en

los requerimientos que puede conllevar el desarrollo de un proceso complejo.



• Reducción del Time to Market: El cliente puede comenzar a utilizar el producto antes de ser

lanzado para probar sus diferentes funcionalidades y comprobar si está satisfecho durante

la fase de desarrollo.

• Mayor calidad del software: La metodología de generar un entregable al final de cada

iteración permite que se realicen un mayor número de pruebas sobre cada fase del

producto, incrementando la posibilidad de detección de errores generando un software de

mayor calidad.

• Mayor productividad: Se consigue gracias a mayor autonomía por parte del equipo, y

mayor toma de decisión sobre su propio trabajo, desarrollando de forma más eficiente

gracias a la toma propia de decisiones.

• Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las

prestaciones que aportan mayor valor al producto generando un mayor valor de negocio

priorizando primero por retorno de la inversión.

• Predicciones de tiempos: Mediante la metodología Scrum, se puede conocer la velocidad

media del equipo realizando cada una de las historias de usuario, con lo cual, es muy

fácilmente estimar el tiempo para la realización de alguna tarea.

• Reducción de riesgos: Llevar a cabo los requerimientos más importantes y de más valor

para el cliente, además de conocer los tiempos con los que el equipo desarrolla el proyecto,

permite alejar ciertos riesgos de manera anticipada.

4.1.4 Aplicación de Scrum sobre el proyecto

Para aplicar esta metodología lo primer de todo ha sido abarcar el ámbito y objetivo del

proyecto para comprender y adaptar el enfoque que se le daría. Tras analizar las diferentes

metodologías disponibles que se pudieran adaptar al desarrollo del proyecto, se decidió utilizar

Scrum, ya que, durante el curso se estudió a fondo y además se aplicó su uso en varias asignaturas.

Para ello, primero se establecieron las diferentes iteraciones que el proyecto tendría, así como la

duración de las mismas. La duración de cada una de las tareas se ha basado en la experiencia

personal y en estimación aproximada.

Como variación adicional, se ha dedicado la fase de pruebas de cada una de las iteraciones a

corregir los errores que han aparecido en la misma iteración, en vez de esperar hasta la siguiente

iteración para corregirlas. El tiempo dedicado a la fase de pruebas se ha ajustado teniendo esto en

cuenta los tiempos que llevarían posibles arreglo de cualquier inconveniente encontrado. [34]



4.2 Planificación temporal

Figura 4.2.1: Diagrama de Gantt

Figura 4.2.2: Diagrama de Gantt

En la figura 4.2.1 y 4.2.2 se observa la descomposición de tareas llevadas a cabo en este proyecto; así ́como su planificación temporal a lo largo del periodo establecido. El proyecto se divide en varias iteraciones:



• Iteración 1: o Análisis: En esta primera fase de análisis de la primera iteración se ha procedido a

analizar los requisitos funcionales que tendrá el videojuego, que nivel de gráficos tendrá junto con su ambientación para así decidir el tipo de escenarios donde se realizaran los combates.

o Diseño: En esta fase está pensado un primer familiarización con Unity3D, comprender sus distintos elementos, así como realizar diferentes pruebas para entender las posibilidades del motor gráfico.

o Implementación: Se creara una breve pantalla inicial nada más iniciar el juego, donde se introducirán los datos del jugador.

o Pruebas: Como pruebas iniciales se decidirá redimensionar la pantalla para ver si se descoloca algún elemento y pruebas de visionado en diferentes pantallas.

• Iteración 2: o Análisis: Análisis de los GameObject necesarios para el funcionamiento de una

partida normal. Se decidirá la estructuración del código para que cada uno de los objetos del juego funcione correctamente y de forma simple.

o Diseño: Diseño de los diferentes objetos del juego, estilo de las cartas, como serán los menús, y diferentes estilos que puedan existir.

o Implementación: Implementación de los objetos de juego más todo el código analizado durante la fase de análisis.

o Pruebas: Se ejecutaran una serie de batería de pruebas para intentar encontrar fallas en el código y localizar errores sobre los GameObject ejecutando algunas pruebas de estrés adicionales.

• Iteración 3: o Análisis: Análisis de la interfaz que tendrá el usuario dentro de las partidas, se

tendrán que analizar los componentes de la misma y las funciones que tendrán. o Diseño: Diseño de los componentes de la interfaz, creación, y generación desde

Photoshop. o Implementación: Implementación de la interfaz de usuario dentro del tablero y del

juego en general. Se implementara también las funciones asociadas a los mismos y su codificación.

o Pruebas: Se realizaran comprobaciones sobre los elementos de la interfaz de usuario, animaciones y la secuenciación de actividades relacionadas con los mismos.

• Iteración 4: o Análisis: Analizar historia y objetivos que tendrá que tener el videojuego. o Diseño: Diseño de los elementos del tablero relacionada con la temática que tendrá

el mismo para ser consistente. o Implementación: Se implementan los layer sobre los GameObject que representaran

todos los elementos del juego, tanto el diseño de los botones, como tablero y otros detalles.



o Pruebas: Pruebas sobre el rendimiento y redimensionado una vez implementados todos los elementos añadidos.

• Iteración 5: o Análisis: Analizar los enemigos que aparecerán en el juego, características y definir

su forma de jugar. o Diseño: Se diseñara la imagen de los enemigos y las diferentes versiones de cada

uno. o Implementación: Generación de una inteligencia artificial (IA), con diferentes niveles

de dificultad y variación en cada partida del estilo de juego. o Pruebas: Probar cada una de las acciones de la IA en sus diferentes versiones.

• Iteración 6: o Análisis: Analizar un modelo vista-controlador que gestione los eventos con

acciones, las clases, y la interconexión con los GameObject. Tiene que existir un correcto flujo entre la transacción de actividades generando una consistencia dentro del videojuego.

o Diseño: Diseñar estructura lógica, con diagrama de clases, estados, casos de uso, etc. Tiene que poseer solo las clases necesarias y no tener código innecesario.

o Implementación: Desarrollo y unión de cada una de las partes del código relacionado (eventos, gameObject, fases, etc).

o Pruebas: Probar cada una de las funciones desarrolladas y su correcta ejecución para cada una de las posibilidades existentes.

• Iteración 7: o Análisis: Determinar la estructura final de la documentación que será presentada al

finalizar el desarrollo de este proyecto. o Diseño: Diseño del documento con estilos y composición acordes a las exigencias

adecuadas. o Implementación: Corrección de posibles fallos que han ido apareciendo durante el

desarrollo del videojuego.

En la figura 4.2.3 se muestra el diagrama de actividades con el camino crítico remarcado para entender cuál será el flujo de actividades que se producirán en este proyecto de manera clara y precisa.



Figura 4.2.3: Diagrama de actividades

4.3 Planificación de costos

Dados los conocimientos aprendidos a lo largos del grado hemos decidido aplicar el modelo COCOMO para realizar el análisis de costes derivados por la realización de este proyecto. Este modelo, basado en número de líneas de código, esfuerzo por persona, y otras variables basadas en conocimientos y experiencia del personal encargado para el proyecto, nos dará una aproximación cercana a los costes basándonos en esfuerzo y en tiempo necesario para el desarrollo del mismo. Al final de realizar el proceso, obtendremos el esfuerzo promedio cada mes así como la productividad necesaria para llevarla a cabo. COCOMO se apoya en diversas fórmulas para su realización y serán explicadas a continuación:

• E=(a)(KLDC)b

(EAF)

• D=(c)(E)d

• PR=LCD/E

• P=E/D



Siendo “E” el esfuerzo aplicado en hombre/mes, “D” Siendo “E” el esfuerzo aplicado en hombre mes, “D” el tiempo de desarrollo en meses, PR la productividad, P personal promedio necesario, “KLDC” número de miles de líneas de código estimado para el proyecto, LDC número de líneas de código y EAF el factor de ajuste del esfuerzo que se calcula valorando en la siguiente escala de 15 atributos.

Figura 4.3.1: Tabla atributos de COCOMO



El primer paso que hemos de realizar es definir el tipo de proyecto que estamos realizando para

poder enmarcarlo dentro de las especificaciones de COCOMO, definiendo así como semi-

acoplado dado los siguientes factores que definiremos:

• Este proyecto será realizado por un solo individuo

• Este software será desarrollado con ciertas restricciones

• El desarrollador del proyecto no ha tenido una experiencia anterior a este proyecto

Figura 4.3.2: Tipo de proyecto según COCOMO

Escogemos el modelo semiacoplado por lo tanto, tenemos que utilizar los valores “a, b, c y d”

especificados en la tabla de la figura 4.3.2.

Para calcular el factor de ajuste del esfuerzo escogemos:

• Para los atributos del software un valor alto

• Para los atributos de hardware un valor nominal

• Para los atributos de personal valor nominal

• Para los atributos del proyecto valor alto

Multiplicando los valores obtenidos mediante los valores asignados en la tabla 1.5.1 obtendremos

un valor EAF = 1,09

Aplicando esos valores obtenemos los siguientes resultados:

• E=3*51,09

*1,24 = 21,50 persona/mes



• D=2,5*21,500,35

= 7,32 meses

• P=4000/21,50= 186,05 líneas de código/persona mes

• P=21,50/7,32= 2,94 personas

Conclusiones

Según los resultados obtenidos para el análisis de presupuesto sobre las especificaciones del

proyecto, podemos concluir que, con una duración de cerca de 7 meses y medio, el promedio de

líneas de código estimadas para este proyecto son de 186 líneas de código al mes y teniendo en

cuenta que durante el desarrollo no se tendrán en cuenta las fases de documentación análisis y

pruebas, se le tiene que agregar los meses extra planificados en la documentación para poder

terminar todas las tareas planificadas

Dado que el proyecto se ha estimado con una duración de 15 meses y medio, recaería sobre un desarrollador de videojuegos es de 2.000 €/mes [43], su salario asciende a la suma de 30000 € por los 15 meses trabajados.

Hay que añadir a ese precio la depreciación lineal sobre el ordenador del profesional que va a

desarrollar el videojuego para conseguir el coste total del desarrollo del proyecto.

El ordenador sobre el que se va a desarrollar el proyecto es sobre un MacBook pro 2,3 GHz Intel

Core i7, con una vida útil aproximada de 5 años [29] y un coste de 2300 euros, podemos realizar la

estimación sobre su valor a depreciar con una depreciación lineal en esos 288 días que durara el

proyecto.

Dados estos valores, estipulamos que si cada día de uso son una depreciación de 1,26€/día, la suma

total por esos 288 días son de 362,88€.

Otro material utilizado, y a pesar de ser a coste 0, han sido las siguientes herramientas software.

Visual Paradigm (para la elaboración de los diferentes diagramas realizados), Gimp (Herramienta de

software libre para la elaboración y retoque de los diferentes elementos gráficos que se utilizaran

en el videojuego), Unity 3D licencia estándar (como motor gráfico), Gantt Project (elaboración de

diagrama de Gantt), Camtasia 2, (para la grabación del gameplay).

Con todas estas conclusiones y datos obtenidos aplicando este modelo, estableceremos el

presupuesto final del proyecto en un coste total de 30362,88€.



Capítulo 5 Análisis



En este capítulo especificaremos el comportamiento y las diferentes funcionalidades del sistema, mediante distintos modelos. Para este proyecto y dado lo estudiado durante el curso utilizaremos el modelo UML. UML es actualmente uno de los lenguajes de modelado de sistemas software más conocido y utilizado en la actualidad. Como detalle importante, durante este tema se usaran conceptos del juego que es importante identificar brevemente:

• HandZone: Zona que representara la mano del jugador, se colocaran las cartas que se podrán jugar durante la partida.

• Avatar: Representa el marco del jugador, su aspecto y donde aparece la salud.

• DropZone: Zona donde se arrastran las cartas y en donde se producen los combates entre cartas, solo se puede atacar desde esta zona.

• Barra de mana y cristales de mana: Los cristales de mana son los objetos que permiten pagar el coste de la carta para poder depositarla en la Dropzone, estos cristales se almacenan en una barra por cada jugador.

Los diferentes estados en los que puede estar una carta:

• Deck: Estado cuando la carta no se encuentra creada, se dice por tanto que se encuentra en el deck o mazo del jugador.

• Hand: La carta se encuentra en este estado cuando ha sido creada y está en la mano del jugador.

• Rest: O también estado de reposo, es cuando la carta ha sido puesta sobre la dropZone y aun no puede realizar ningún ataque hasta el siguiente turno. Diseño de ejemplo en figura 5.1

Figura 5.1: Carta en estado de reposo

• Ready: En este estado la carta puede ser lanzada desde la mano hasta la dropZone, la carta se remarca en color verde, representando su disponibilidad, ejemplo en la figura 5.2.



Figura 5.2: Carta en estado ready

• Battle: Estado de batalla, en este estado la carta puede realizar ataques contra otras cartas enemigas o contra el jugador contrario. La carta se remarca de color azul. Ejemplo en la figura 5.3.

Figura 5.3: Carta en estado Battle.

• Dead: La carta llega a este estado cuando es destruida. Diferentes modos que la mesa puede tomar para cada jugador:

• Modo preparación: Modo en el que se pueden lanzar cartas a la zona de combate y donde se recargan todos los cristales de mana.

• Modo de ataque: Modo en el que el jugador puede realizar ataques contra el adversario y sus cartas.

• Modo de finalización: Modo en el que se pueden depositar cartas en la mesa sino se decidió hacer en la fase de preparación y ceder el turno al rival.

Todos estos conceptos serán detallados en más profundidad posteriormente, se indican de esta forma para que el lector tenga una idea de que ha de que viene detallado en cada requisito. Para indicar los diferentes requisitos, actores, objetivos del juego, y otros elementos imprescindibles que se utilizaran unas tablas organizadas por diferentes atributos para diferenciarse entre sí y estructurar la información de forma correcta:



Las tablas contendrán la siguiente información:

• ID: identificador. Se nombra según secuencias numeradas ID [S]-XY donde ID es el nombre del identificador (ACT, RQ, CU), S es el campo opcional (RQF, RQNF, etc...), y un valor ordinal asignado incrementalmente con cada número de tabla de dicho identificador.

• Nombre: Se utiliza para denominar el contenido.

• Versión: Numero de la versión.

• Actor: Usuario que realiza el contenido o realiza la acción indicada en la tabla.

• Disparador: evento que inicia el contenido.

• Dependencias: relaciones con otras tablas.

• Precondiciones: condiciones previas que deben cumplirse para poder utilizarse.

• Prioridad: indica la importancia, se especifica como Baja/Media/Alta/Muy Alta.

• Estado: estado en el que se encuentra el contenido, se especifica como Implementado/No implementado.

• Frecuencia de uso: indica la utilización, se especifica como Baja/Media/Alta/Muy Alta.

• Flujo normal: secuencia de pasos que sigue el usuario al utilizar el contenido, se especifica como Paso (número)/Acción.

• Flujo alternativo: secuencia alternativa de pasos que sigue el usuario al utilizar el con-tenido, se especifica como Paso (número)/Acción.

• Postcondiciones: condiciones que modifica el uso del contenido.

• Excepciones: excepciones que pueden aparecer durante el uso del contenido.

• Descripción: identifica el contenido de forma detallada.

• Otra información: otra información necesaria.

5.1 Identificación de actores En esta sección se identifican los actores a los que ira dirigido el videojuego. Al ser un juego “single player”, un solo jugador, solo existirá un único actor.

ID y Nombre: ACT-01 Jugador

Versión: v1

Descripción: Usuario principal. Jugador de la aplicación.

Otra Información:

Tabla 17. ACT-01 Jugador

5.2 Objetivos En esta sección se identifican los objetivos a conseguir en el proyecto. Para definir los objetivos utilizaremos y definiremos la siguiente tabla:



ID y Nombre: OBJ-XY

Versión: Numero de versión

Descripción: Descripción detallada del contenido

Prioridad: Importancia de implementación

Estado: Implementado/No implementado

Otra Información: Comentarios

Tabla 18. Ejemplo de tabla de objetivos

ID y Nombre: OBJ-01 Diseño del videojuego

Versión: v1

Descripción: Implementación de la estructura básica de un videojuego, permitiendo crear el tablero, la carta y los enemigos como inteligencia artificial

Prioridad: Muy alta

Estado: Implementado

Otra Información:

Tabla 19. OBJ-01 Diseño del videojuego

ID y Nombre: OBJ-02 Creación de la Interfaz de Usuario Gráfica

Versión: v1

Descripción: Implementación de menús para que el jugador pueda interactuar con la interfaz del juego, gestionar la música y sonido del juego, y salir de la aplicación correctamente.

Prioridad: Muy alta


Otra Información:

Tabla 20. OBJ-02 Creación de la GUI

ID y Nombre: OBJ-03 Creación del sonido del juego

Versión: v1

Descripción: Implementación de la música y efectos de sonido del videojuego.

Prioridad: Media


Otra Información: La música es obtenida de contenido free commons

Tabla 21. OBJ-03 Creación del sonido del juego

ID y Nombre: OBJ-04 Programación de las funcionalidades del videojuego

Versión: v1

Descripción: Implementación de la funcionalidad del videojuego, permitiendo al jugador interaccionar entre los distintos turnos, lanzar cartas, atacar y realizar diferentes estrategias.

Prioridad: Muy alta




Otra Información:

Tabla 22. OBJ-04 Programación de las funcionalidades del videojuego

ID y Nombre: OBJ-05 Desarrollo Inteligencia Artificial(IA)

Versión: v1

Descripción: Implementación de diferentes enemigos con diferentes niveles de dificultad y de complejidad a la hora de la implementación.

Prioridad: Alta


Otra Información:

Tabla 23. OBJ-05 Desarrollo Inteligencia Artificial (IA)

ID y Nombre: OBJ-06 Creación del tablero

Versión: v1

Descripción: Implementación y diseño del tablero de juego donde se colocaran las cartas y posicionara el juego

Prioridad: Media.


Otra Información:

Tabla 24. OBJ-06 Creación del tablero

ID y Nombre: OBJ-07 Guardar el proceso

Versión: v1

Descripción: Implementación del guardado/cargado de datos relativos al progreso del juego, permitiendo seguir jugando desde donde se estaba antes de cerrar la aplicación, no perdiendo tu progreso.

Prioridad: Media.

Estado: No implementado

Otra Información:

Tabla 25. OBJ-07 Guardar el proceso

ID y Nombre: OBJ-08 Creación modo historia

Versión: v1

Descripción: Implementar diferentes niveles en función de ir eliminando enemigos de la IA

Prioridad: Alta.


Otra Información:

Tabla 26. OBJ-08 Creación modo historia



5.3 Especificación de Requisitos En esta sección describiremos los requisitos de nuestro videojuego, intentaremos indicar de manera sencilla y simple las funcionalidades de nuestra aplicación y la información necesaria de la misma. Para definir los requisitos se utilizara la siguiente tabla:

ID y Nombre: RQ[S]-XY

Versión: Numero de versión

Descripción: Descripción detallada del contenido

Dependencias: Requisitos necesarios para su funcionamiento

Prioridad: Importancia de implementación

Frecuencia de uso: Uso del contenido

Otra Información: Comentarios

Tabla 27. Ejemplo de tabla de requisitos

REQUISITOS FUNCIONALES

Funcionalidades que ha de tener la aplicación:

ID y Nombre: RQF-01 Introducir datos en menú principal

Versión: v1

Descripción: El jugador deberá introducir el nombre y la clase al entrar en la aplicación

Dependencias:

Prioridad: Muy alta.

Frecuencia de uso: Muy alta.

Otra Información:

Tabla 28. RQF-01 Introducir datos en el menú principal

ID y Nombre: RQF-02 Cargar tablero de juego

Versión: v1

Descripción: El juego deberá cargar la mesa y los distintos elementos para comenzar la partida.

Dependencias: RQF-01

Prioridad: Alta.

Frecuencia de uso: Alta.

Otra Información:

Tabla 29. RQF-02 Cargar tablero de juego



ID y Nombre: RQF-03 Tener vida

Versión: v1

Descripción: El sistema deberá de añadir vida al jugador


Prioridad: Alta.


Otra Información: El jugador comienza con 20 puntos de salud.

Tabla 30. RQF-03 Tener vida

ID y Nombre: RQF-04 Recibir daño

Versión: v1

Descripción: El sistema deberá de añadir la posibilidad de recibir daño al jugador.

Dependencias:

Prioridad: Alta.


Otra Información: El jugador recibirá un daño equivalente al ataque de la carta con la que reciba el daño, directamente sobre sus puntos de vida.

Tabla 31. RQF-04 Recibir daño

ID y Nombre: RQF-05-Cargar datos de las cartas en el objeto de la carta

Versión: v1

Descripción: El sistema deberá de cargar los datos de las cartas en el propio objeto


Prioridad: Alta.


Otra Información:

Tabla 32. RQF-05-Cargar datos de las cartas en el objeto de la carta

ID y Nombre: RQF-06-Generar carta en la HandZone

Versión: v1

Descripción: El sistema posiciona las cartas en la zona de la mano del jugador


Prioridad: Alta.


Otra Información: Las cartas se generan tanto al inicio de la partida tanto como cuando se pasa el turno, es decir, el jugador que recibe el turno también recibe una carta

Tabla 33. RQF-06-Generar carta en la HandZone

ID y Nombre: RQF-07-Lanzar carta a la mesa

Versión: v1



Descripción: El jugador puede tirar cartas en la dropzone

Dependencias:

Prioridad: Alta.


Otra Información: Para que un jugador pueda lanzar cartas ha de estar en posesión del turno y estar en estado de preparación antes de estado de ataque. La carta que lanza a la mesa ha de ser de un coste igual o menor al número de cristales de mana en posesión

Tabla 34. RQF-07-Lanzar carta a la mesa

ID y Nombre: RQF-08-Pasar al turno de ataque

Versión: v1

Descripción: El jugador podrá cambiar al modo de ataque

Dependencias:

Prioridad: Alta.

Frecuencia de uso: Media.

Otra Información: El jugador debe tener la posesión del turno

Tabla 35. RQF-08-Pasar al turno de ataque

ID y Nombre: RQF-09-Cambio de estado de la carta al entrar en la zona de combate

Versión: v1

Descripción: La carta lanzada en la dropzone, cambiara de estado de lista de dentro de la handZone a reposo de la dropZone.

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 36. RQF-09-Cambio de estado de la carta al entrar en la zona de combate

ID y Nombre: RQF-10-Morir

Versión: v1

Descripción: El sistema podrá hacer morir al jugador

Dependencias:

Prioridad: Alta.


Otra Información: Cuando la vida este a 0 o menos se producirá un Game over o fin de juego

Tabla 37. RQF-10-Morir

ID y Nombre: RQF-11-Carta cambia a estado de ataque

Versión: v1



Descripción: La carta tras pasar un turno en la DropZone, pasa de estado en reposo a estado de ataque

Dependencias:

Prioridad: Alta.


Otra Información: Esto quiere decir que en el turno que se lanza no ataca, tiene que esperar hasta el siguiente para poder realizar un ataque.

Tabla 38. RQF-11-Carta cambia a estado de ataque

ID y Nombre: RQF-12-Carta puede atacar a carta enemiga

Versión: v1

Descripción: La carta puede atacar a cartas enemigas que estén en la zona de combate del enemigo

Dependencias:

Prioridad: Alta.


Otra Información: Para que una carta ataque a otra carta, ambas han de estar en DropZone y una de ellas debe de estar en modo ataque para poder ejecutar esta acción.

Tabla 39. RQF-12-Carta puede atacar a carta enemiga

ID y Nombre: RQF-13-Carta quita vida a otra carta

Versión: v1

Descripción: La carta resta la vida de ataque propia a la defensa de la carta del oponente


Prioridad: Alta.


Otra Información:

Tabla 40. RQF-13-Carta quita vida a otra carta

ID y Nombre: RQF-14-Destruir carta

Versión: v1

Descripción: Si una carta recibe más daño que la defensa será destruida y eliminada.


Prioridad: Alta.


Otra Información:

Tabla 41. RQF-14-Destruir carta

ID y Nombre: RQF-15-Atacar salud enemiga

Versión: v1



Descripción: Una carta puede atacar directamente al enemigo y eliminar una vida equivalente al ataque de la carta.

Dependencias:

Prioridad: Alta.


Otra Información: Solo si la carta está en estado de ataque.

Tabla 42. RQF-15-Atacar salud enemiga

ID y Nombre: RQF-16-Gestionar animaciones

Versión: v1

Descripción: Animación al posicionar las cartas dentro de la dropZone y HandZone, simulando el espacio que ocupara y desplazando a las otras hacia los lados.

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 43. RQF-16-Gestionar animaciones

ID y Nombre: RQF-17-Generar vida enemiga

Versión: v1

Descripción: El sistema deberá de añadir una vida a la IA

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 44. RQF-17-Generar vida enemiga

ID y Nombre: RQF-18-Reintentar partida

Versión: v1

Descripción: El sistema deberá poder permitir volver a empezar la partida si la IA elimina al jugador


Prioridad: Alta.


Otra Información:

Tabla 45. RQF-18-Reintentar partida

ID y Nombre: RQF-19-Reproducir música de fondo

Versión: v1



Descripción: El sistema deberá poder reproducir música en el juego

Dependencias:

Prioridad: Media.


Otra Información: Si la música está habilitado.

Tabla 46. RQF-19-Reproducir música de fondo

ID y Nombre: RQF-20-Reproducir efecto de sonido

Versión: v1

Descripción: El sistema deberá poder reproducir efectos de sonido

Dependencias:

Prioridad: Media.


Otra Información: Si el sonido está habilitado.

Tabla 47. RQF-20-Reproducir efecto de sonido

ID y Nombre: RQF-21-Gestionar música

Versión: v1

Descripción: El sistema deberá poder activar/desactivar la música del juego


Prioridad: Media.


Otra Información:

Tabla 48. RQF-21-Gestionar música

ID y Nombre: RQF-22-Gestionar efectos de sonido

Versión: v1

Descripción: El sistema deberá poder activar/desactivar la reproducción de efectos de sonido del juego


Prioridad: Media.


Otra Información:

Tabla 49. RQF-22-Gestionar efectos de sonido

ID y Nombre: RQF-23-Avanzar al siguiente nivel

Versión: v1



Descripción: Cuando se elimina al enemigo rival se avanza al siguiente enemigo

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 50. RQF-23-Avanzar al siguiente nivel

ID y Nombre: RQF-24-Abrir menú

Versión: v1

Descripción: El sistema deberá permitir abrir un menú IU

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 51. RQF-24-Abrir menú

ID y Nombre: RQF-25-Cerrar menú

Versión: v1

Descripción: El sistema deberá permitir cerrar un menú IU


Prioridad: Alta.


Otra Información: Al cerrar el menú se volverá al estado anterior del juego antes de abrirlo

Tabla 52. RQF-25-Cerrar menú

ID y Nombre: RQF-26-Salir del juego

Versión: v1

Descripción: El sistema deberá permitir cerrar correctamente la aplicación

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 53. RQF-26-Salir del juego

ID y Nombre: RQF-27-Generar linerenderer

Versión: v1

Descripción: El sistema deberá generar un line Renderer cuando una carta seleccionar a otra para atacar

Dependencias:

Prioridad: Alta.




Otra Información: Acción que se realiza cuando una carta en estado de ataque desea atacar a otra carta del enemigo, para ello, se genera un linerenderer que simulara la flecha de ataque.

Tabla 54. RQF-27-Generar linerenderer

ID y Nombre: RQF-28-Generar partículas

Versión: v1

Descripción: El sistema deberá generar partículas cuando se seleccionar una carta para atacar

Dependencias:

Prioridad: Baja.


Otra Información:

Tabla 55. RQF-28-Generar partículas

ID y Nombre: RQF-29-Destruir partículas

Versión: v1

Descripción: El sistema deberá destruir las partículas generadas


Prioridad: Baja.


Otra Información:

Tabla 56. RQF-29-Destruir partículas

ID y Nombre: RQF-30-Generar dialogo inicial enemigo

Versión: v1

Descripción: El sistema deberá generar dialogo al empezar una partida

Dependencias:

Prioridad: Baja.


Otra Información:

Tabla 57. RQF-30-Generar dialogo inicial enemigo

REQUISITOS NO FUNCIONALES

ID y Nombre: RQNF-01-Acceso al almacenamiento del dispositivo

Versión: v1



Descripción: El sistema requerirá un mínimo de espacio en el disco duro para poder ejecutarse, como tamaño inicial para esta primera fase, el tamaño se ha establecido en 250Mb

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 58. RQNF-01-Acceso al almacenamiento del dispositivo

REQUISITOS DE RENDIMIENTO

ID y Nombre: RQNFR-01-Respuesta rápida

Versión: v1

Descripción: El sistema deberá ofrecer un buen rendimiento, cargado y respondiendo a las acciones del usuario en un tiempo mínimo y aceptable

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 59. RQNFR-01-Respuesta rápida

REQUISITOS DE ESCALABILIDAD

ID y Nombre: RQNFE-01-Comptibilidad con Pc

Versión: v1

Descripción: El sistema deberá poder instalarse en Windows

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 60. RQNFE-01-Comptibilidad con Pc

ID y Nombre: RQNFE-02-Comptibilidad con Mac

Versión: v1

Descripción: El sistema deberá poder instalarse en Mac

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 61. RQNFE-02-Comptibilidad con Mac



ID y Nombre: RQNFE-03-Comptibilidad con distintas resoluciones

Versión: v1

Descripción: El sistema deberá poder adaptarse a la distinta resolución de los dispositivos en donde el videojuego corra

Dependencias: RQNFE-03 / RQNFE-02

Prioridad: Alta.


Otra Información:

Tabla 62. RQNFE-03-Comptibilidad con distintas resoluciones

REQUISITOS DE HARDWARE

ID y Nombre: RQNFH-01-PC

Versión: v1

Descripción: El usuario deberá disponer de un pc con Windows

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 63. RQNFH-01-PC

ID y Nombre: RQNFH-02-Mac

Versión: v1

Descripción: El usuario deberá disponer de un Mac

Dependencias:

Prioridad: Alta.


Otra Información:

Tabla 64. RQNFH-02-Mac

REQUISITOS DE INTERNACIONALIZACIÓN

ID y Nombre: RQNFI-01-Idioma

Versión: v1

Descripción: El usuario soportara el idioma español

Dependencias:

Prioridad: Media.


Otra Información:

Tabla 65. RQNFI-01-Idioma



5.4 Casos de Uso En esta sección se describe el comportamiento entre el sistema y los actores que harán uso de él, en este caso, se mostrara mediante una secuencia de iteraciones representadas con modelado de casos de uso UML. Puesto que es un videojuego de un jugador para pc/Mac, solo habrá un actor que será el propio jugador.

DIAGRAMA DE CASOS DE USO

Figura 5.4.1: Caso de uso general del videojuego

El diagrama de la figura 5.4.1 refleja los principales objetivos a implementar en el proyecto.



5.5 Especificación de Casos de Uso

ID y Nombre: CU-01 Jugar

Actor: Jugador.

Descripción: Muestra el menú para iniciar la partida

Disparador: El jugador presiona el botón START

Dependencias:

Precondiciones: Se debe de estar en el menú principal del juego

Flujo normal: Paso Acción

1 Presiona el botón Start en el menú inicial del juego

2 El sistema crea la instancia y comienza a cargar la escena donde está contenido el tablero.

Flujo alternativo:

Postcondiciones:

Excepciones:



Otra Información:

Tabla 66. CU-01 Jugar

ID y Nombre: CU-02 Modificar ajustes

Actor: Jugador.

Descripción: Muestra los ajustes de música y sonido del juego

Disparador: El jugador presiona el botón de ajustes

Dependencias:

Precondiciones: Se debe de estar en el menú principal del juego


1 Presionar el botón ajustes en la pantalla inicial del juego

Flujo alternativo: Paso Acción

1 Abrir el menú

2 Presionar el botón ajustes en el menú dentro del juego

Postcondiciones:

Excepciones:

Prioridad: Baja.


Otra Información:

Tabla 67. CU-02 Modificar ajustes

ID y Nombre: CU-03 Salir

Actor: Jugador.



Descripción: Muestra el menú de salir del juego

Disparador: El jugador presiona el menú y pulsa salir

Dependencias:

Precondiciones: Se debe de estar en el menú principal del juego o dentro del juego


1 Abrir el menú

2.1 Confirmar salir del juego

2.2 Cancelar salir del juego

Flujo alternativo:

Postcondiciones: Se cierra la aplicación

Excepciones:



Otra Información:

Tabla 68. CU-03 Salir

ID y Nombre: CU-04 Cargar mesa

Actor: Jugador.

Descripción: Carga la mesa y los elementos

Disparador: El jugador al seleccionar Start genera los elementos de la mesa y da comienzo la partida

Dependencias: CU-01

Precondiciones: Se debe de estar en el menú de iniciar partida y darle a jugar


1 Seleccionar iniciar partida para jugar contra la IA

2 El sistema carga la mesa y todos los elementos visuales de la misma.

3 El sistema elige al jugador que comienza la partida.

Flujo alternativo:

Postcondiciones:

Excepciones:

Prioridad: Alta.


Otra Información:

Tabla 69. CU-04 Cargar mesa

ID y Nombre: CU-05 Cargar carta

Actor: Jugador.

Descripción: Tras cargar la mesa se generan las cartas de la mano

Disparador: El jugador recibe las cartas en la mano

Dependencias: CU-04

Precondiciones: Se debe de haber cargado una partida




1 Estar dentro de una partida

2 La mesa y los diferentes elementos visuales han sido cargados

3 La partida ha cargado y el jugador recibe sus 3 primeras cartas iniciales

Flujo alternativo:

Postcondiciones:

Excepciones: El jugador tiene la mano llena

Prioridad: Alta.


Otra Información:

Tabla 70. CU-05 Cargar carta

ID y Nombre: CU-06 Lanzar carta

Actor: Jugador.

Descripción: El jugador suelta una carta en la carta de combate

Disparador: El jugador arrastra la carta a la zona de combate

Dependencias: CU-04

Precondiciones: Se debe de estar en el turno del jugador


1 Arrastrar la carta a la zona de combate

Flujo alternativo:

Postcondiciones:

Excepciones: No está en el turno del jugador/ Carta con coste demasiado alto

Prioridad: Alta.


Otra Información:

Tabla 71. CU-06 Lanzar carta

ID y Nombre: CU-07 Eliminar carta enemiga

Actor: Jugador.

Descripción: El jugador ataca a una carta enemiga y la elimina

Disparador: El jugador selecciona y elimina a una carta enemiga

Dependencias: CU-04

Precondiciones: Se debe de estar atacando a una carta


1 Atacar a carta enemiga

Flujo alternativo:

Postcondiciones:

Excepciones: No tener el turno/el rival no tiene cartas en la zona de combate que destruir

Prioridad: Alta.




Otra Información:

Tabla 72. CU-07 Eliminar carta enemiga

ID y Nombre: CU-08 Eliminar enemigo

Actor: Jugador.

Descripción: El jugador ataca al enemigo directamente

Disparador: El jugador selecciona y elimina al enemigo

Dependencias: CU-04

Precondiciones: Se debe de estar atacando al marco rival


1 Se selecciona la carta

2 El sistema crea linerenderer entre la carta y el avatar rival

3 El enemigo sufre una pérdida de puntos de vida equivalentes al ataque de la carta.

4 Se termina esa fase o se termina el juego, dependiendo de la fase

Flujo alternativo:

Postcondiciones:

Excepciones: No tener el turno/el rival queda por encima de 1 de vida

Prioridad: Alta.


Otra Información:

Tabla 73. CU-08 Eliminar enemigo

ID y Nombre: CU-09 Abrir menú

Actor: Jugador.

Descripción: El jugador abre el menú

Disparador: El jugador selecciona el botón de abrir el menú

Dependencias: CU-04

Precondiciones: Se debe de estar jugando para abrir este menú


1 Pulsar el botón de abrir el menú

Flujo alternativo:

Postcondiciones:

Excepciones: El jugador ha perdido la partida

Prioridad: Alta.




Otra Información:

Tabla 74. CU-09 Abrir menú

ID y Nombre: CU-10 Volver al menú

Actor: Jugador.

Descripción: El jugador pulsa el botón de volver al menú de inicio

Disparador: El jugador selecciona el botón de volver al menú de inicio

Dependencias: CU-09

Precondiciones: Se debe de estar en el menú de dentro del juego


1 Pulsar el botón de abrir el menú y retornar a al menú inicial

Flujo alternativo:

Postcondiciones:

Excepciones:

Prioridad: Alta.


Otra Información:

Tabla 75. CU-10 Volver al menú

ID y Nombre: CU-11 Continuar

Actor: Jugador.

Descripción: El jugador pulsa el botón de continua

Disparador: El jugador selecciona el botón de continuar el juego

Dependencias: CU-09

Precondiciones: Se debe de estar en el menú de dentro del juego


1 Pulsar el botón de abrir el menú y retornar a dentro del juego para continuar la partida

Flujo alternativo:

Postcondiciones:

Excepciones:



Prioridad: Alta.


Otra Información:

Tabla 75. CU-11 Continuar

ID y Nombre: CU-12 Gestionar música

Actor: Jugador.

Descripción: Activa y desactiva la música del juego

Disparador: El jugador selecciona el botón de música

Dependencias: CU-02

Precondiciones: Se debe de estar en el menú de ajustes


1 Presiona el botón de activar/desactivar música

Flujo alternativo:

Postcondiciones: Activa/desactiva la música

Excepciones: Hay música activada/no hay música activada

Prioridad: Baja.


Otra Información: El botón comparte la funcionalidad de activar/desactivar

Tabla 76. CU-12 Gestionar música

ID y Nombre: CU-13 Gestionar sonido

Actor: Jugador.

Descripción: El jugador activa/desactiva los efectos de sonido

Disparador: El jugador selecciona el botón de música del menú

Dependencias: CU-02

Precondiciones: Se debe de estar en el menú


1 Pulsa el botón de activar/desactivar efectos de sonido

Flujo alternativo:

Postcondiciones:

Excepciones:

Prioridad: Baja.


Otra Información:

Tabla 77. CU-13 Gestionar sonido



Capítulo 6 Diseño



En este capítulo se va a exponer la arquitectura lógica y física del videojuego y la fase de

diseño, esta parte está compuesta por la historia del juego, estética donde explicaremos como se

ha diseñado cada componente del videojuego y que utilidad tienen cada uno. También

detallaremos la parte de la interfaz de usuario.

6.1 Arquitectura Lógica

La arquitectura lógica de la aplicación se divide en diferentes capas:

1. Capa de presentación: Presenta el sistema al usuario, mostrando los componentes de la

IU (pantallas, menús, etc,…) y los componentes de procesos IU que controla el flujo de

operaciones con el usuario y la parte de interacción persona ordenador. Esta capa se

comunica con la capa de negocio.

2. Capa de negocio: Contiene los scripts con las funcionalidades del juego, y las entidades

de negocio, que se encargan del intercambio de datos entre capas. Recibe las solicitudes

de la capa de presentación.

3. Capa de datos: Esta capa se apoya en un XML que contendrá la información de cada una

de las cartas y una serie de clases que se aprovecharan de la estructura del XML para

cargar los diferentes componentes. En el futuro se planteara el uso de una base de datos

más sofisticada.

4. Capa de componentes comunes: Son componentes que pueden ser accedidos a través

de cualquier parte de la aplicación, como por ejemplo, la configuración de sonidos,

efectos, resolución, etc.

6.2 Diagramas de clases de diseño En esta sección se van a describir las clases que conforman el sistema y como se relacionan entre sí. De esta forma se detalla la estructura del sistema para tener un conocimiento sobre la implementación de este.



Figura6.2.1: Diagrama de clases de la estructura de Unity3D

Lo más importante de Unity3D es comprender su estructura interna y sus clases, tras la breve

introducción del capítulo 2, Introducción a Unity3D , sabemos que un proyecto en Unity3D se basa

en Objetos, esos objetos se basan en diferentes Componentes asociados a esos objetos, y para ser

ejecutado en el flujo de ejecución debe de heredar de la clase MonoBehaviour. El diagrama 6.2.1

muestra la estructura básica que sigue Unity3D.

Ahora, pasaremos a explicar las diferentes clases del proyecto. Debido a la complejidad y la

magnitud del mismo se dividirá en diferentes diagramas de clases y se añaden solo los atributos y

funciones principales:

• Controladores: Diagrama que contiene los controladores del juego, los cambios en

los elementos y componentes de la mesa, controladores de interfaz, de sonido, y de

todos los objetos en general que implementa el videojuego.



• Controladores del juego: Contiene las clases encargadas de los controladores del

juego, mesa, cartas, etc.

• Personaje del juego: Contiene las clases relacionadas con las acciones permitidas

por el jugador.

• IA: Clases relacionadas con la inteligencia artificial del juego.

• Objetos del juego: Cartas, mesa, elementos que la constituyen, etc.

Los diagramas del juego son los siguientes:



Figura6.2.2: Controlador y visión global del juego

En la figura 6.2.2, podemos ver una visión global de cómo se desarrolla el videojuego. Todas

heredan de MonoBehaviour y todas prácticamente dependen de la funcionalidad del

GameController.

El Player no es tan solo un script asociado a un objeto vacío, representando la funcionalidad así

como otros datos útiles del jugador, almacena sus datos durante la partida, al igual que los datos de

su zona de tablero.

Las player_actions son las distintas acciones que el usuario puede hacer cuando está en la partida,

se acceden a través del objeto que representa al jugador y dota de distintas funcionalidades como



acceder rápidamente a sus objetos o sus datos sin tener que recorrer la mesa buscando datos

constantemente.

Figura 6.2.3: Visión y funcionamiento de la mesa

En la figura 6.2.3 , se representa la visión desde como funcionara la mesa, aparte de las clases ya

comentadas, nos encontramos también con la “drop zone” las zonas donde las cartas atacan y

defienden, ya que tiene sus propios scripts asociados para los distintos efectos.

Las figuras 6.2.2 y 6.2.3 vienen ampliadas en la carpeta que se entrega justo a este documento,

para facilitar su visualización.

La clase de ButtonControllers, utilizada para la gestión de las diferentes fases durante el desarrollo

de la partida, para pasar de la fase de preparación, de ataque y finalización de turno.

Y como adicional, clickable, se utiliza sobre la carta para saber cuándo se pincha sobre ella y dar

lógica a los diferentes eventos de la partida.



Figura6.2.4: Lógica interfaz de inicio

La figura 6.2.4 representa como actúan las diferentes clases del inicio del juego, desde IUController,

que se utiliza para almacenar los datos que el jugador introduce por la interfaz, esos datos, los

instancia hasta el controlador que da comienzo al juego.

Las clases ComboBox se utilizan solo para la creación del menú desplegable que en esta primera

fase de videojuego no afecta demasiado.



Figura 6.2.5: Interfaz de juego y otras utilidades

En la figura 6.2.5 se muestra la instanciación de elementos, sonido y gestión de los mismos en todo

momento.



6.3 Diagramas de estado

En esta sección se pretende describir los estados que puede tomar el estado en sus

diferentes fases dentro del sistema:

• Jugador:

• Enemigo:

• Mesa:

• Música

• Sonido:

Jugador

• Jugar: En este punto el jugador podrá realizar acciones dentro de la partida.

• isMyTurn: Estado en el que el jugador está dentro de su turno.

• Live: Estado mientras el jugador esta con vidas suficientes para continuar la partida.

Figura 6.2.6: Diagrama de estados del jugador.

Enemigo

• isMyTurn: Turno activo del enemigo



• Live: Si el enemigo sigue con vidas suficientes para continuar la partida.

Figura 6.2.7: Diagrama de estados del enemigo.

Mesa

• Ready: En este estado, en la mesa se podrán poner cartas sobre el tablero, se robara una carta

y se perderán cristales por cada carta lanzada.

• Attack: Las cartas podrán atacar en este turno a otras cartas o al jugador enemigo.

• ChangeTurn: Cambia turnos entre jugadores

Figura 6.2.8: Diagrama de estados de la mesa



Música

• MusicaOn: La música esta activada

• MusicaOff: La música esta desactivada

Figura 6.2.9: Diagrama de estados de la música

Sonido

• SoundOn: Los efectos de sonido están activados.

• SoundOff: Los efectos de sonido esta desactivados.

Figura 6.2.10: Diagrama de estados del sonido



6.4 Diagramas de secuencia En esta sección se van a describir las secuencias de mensajes que intercambian entre si las diferentes clases para realizar sus correspondientes funcionalidades entre sí. Se especificaran las principales secuencia de funcionalidades del videojuego.

Jugar

Figura 5.6.1: Diagrama de secuencia para Jugar

Iniciar partidaIniciar partidaIniciar partidaIniciar partida

Figura 5.6.2: Diagrama de secuencia para iniciar partida



SalirSalirSalirSalir

Figura 5.6.3: Diagrama de secuencia para salir del juego

Lanzar cartaLanzar cartaLanzar cartaLanzar carta

Figura 5.6.4: Diagrama de secuencia para lanzar una carta a la mesa



AtacarAtacarAtacarAtacar

Figura 5.6.5: Diagrama de secuencia para atacar

Eliminar enemigoEliminar enemigoEliminar enemigoEliminar enemigo

Figura 5.6.6: Diagrama de secuencia para eliminar al enemigo



6.5 Historia Reino de Scandred, un reino en donde la justicia se impone a base de peleas de cartas, donde una mala jugada puede suponer lo último que hagas. Tras miles de años en guerra, el reino lleva 120 años de paz, gracias al emperador Buoda y a su padre. Durante esos años de paz, Buoda encontró un libro que hablaba de una famosa leyenda muy antigua que explicaba el origen de guerras pasadas, ese motivo era una carta antigua, una carta legendaria, la cual, daba a su dueño la posibilidad de gobernar todos los reinos del mundo ante un poder tan abrumador. Para tal misión Buoda decidió mandar a su guerrero más prometedor, Gedo, al templo oculto en el pantano de la Penas, el lugar más inhóspito del reino de Scandred. Gedo, al llegar al templo y descubrir que la carta fue el origen de los miles de años de guerra, decidió emprender, con la carta en su poder un viaje hacia el núcleo de lava, para destruir la carta y que nunca más volviese originar ninguna guerra. Buoda, al descubrir el plan de Gedo, decidió mandar a su hijo en su búsqueda, Van Cloff, un famoso caza recompensas que utiliza métodos desconocidos para atrapar a sus presar, hasta el día de hoy, ha atrapado a más de trescientos delincuentes. - ¿Conseguirá Gedo liberar al reino de Scandred de la futura tiranía que quiere implantar Buoda en el reino?

6.6 Estética del juego En este apartado hablaremos sobre el la parte grafica del juego, es un estilo muy sencillo, intentando cuadrar la tonalidad de los colores.

El juego al estar ambientado en un modelo medieval/fantástico, se ven fondos de mesa con

bosques y torres antiguas, intentando así, ambientar un poco más la partida e intentar sumergir

todo lo posible al jugador. El protagonista, así como los enemigos, serán personajes afines a la

época y la historia.



Personajes

Gedo, el protagonista, un joven guerrero desterrado del reino,

armado con su hacha y su baraja de cartas.

El juego War Card Game es un nombre simple, proveniente de una

traducción simple al inglés, y con la filosofía de que en este universo,

se resuelve todo sin violencia, solo con un desafío de cartas.

El diseño encaja perfectamente con el universo del videojuego, donde

lleva ropa de la época e instrumentos identificativos.

En principio se intentó un diseño en 3D con una con efectos asociados

al protagonista, pero por especificaciones y por falta de habilidad para

el modelado 3D y dibujo se decidió adoptar tan solo una versión en

2D.

La imagen del protagonista es la de una persona con confianza y

amigable.

Uno de los antagonistas, Buoda, señor del Reino de Scandred,

desterró hace año a Joda por no cumplir sus órdenes de robar la

famosa carta legendaria oculta en el templo de las profundidades.

Es considerado el mejor maestro de cartas del reino y temido por

todos los ciudadanos porque nunca ha perdido una vez.

Busca a Gedo porque sospecha que consiguió la carta legendaria y

no se la entrego, por ello su destierro y su búsqueda, vivo o

muerto. Su aspecto es el de alguien apático y con poca paciencia.

El último de los personajes y no menos importante es Van Cloff, es el hijo de Buoda y el mayor

caza recompensas del reino, temido entre todos los delincuentes cuando va a buscarlos.

Se dice que nunca ha fracasado a la hora de capturar a alguien y sus métodos, a pesar de ser

desconocidos, se dice que son letales.

Buoda ordeno a Van Cloff la búsqueda de Gedo una vez este fue desterrado, su padre le dijo que

no podía volver a casa sin la carta legendaria.



Botones

Exponemos a continuación el estilo de los botones que se ha utilizado dentro del tablero.

Botón de ataque.

Botón de listo, se utiliza para iniciar la fase de ataque.

Botón de pasar turno.

Mesa de juego

Dentro de este ejemplo de mesa vacía podemos ver:

• Marcos de cada uno de los jugadores

• Corazón, es el indicativo de la vida de cada uno.

• Las “handzone”, representadas en los extremos superiores e inferiores de la pantalla, son las

encargadas de almacenar las cartas de cada uno de los jugadores.

• “Dropzone”, partes centrales del juego, donde las cartas atacaran y defenderán.



• Zona de botones, situada a la derecha del todo, ira intercambiando, según la fase, de listo, ataque y

cambio de turno.

• Otra de las zonas importantes, la zona donde irán alojados los cristales de mana, a la derecha de

cada uno de los jugadores.

Cartas

Ejemplo de cómo está organizada las cartas dentro de este juego:

Coste de la carta

Nombre de la criatura

Foto de la criatura

defensa Ataque

Las cartas son un diseño simple a partir de la construcción de varios GameObject, se pensó otros

diseños con un modelado 3D, tras la fase de la beta se tiene pensado una reforma grafica en lo que

viene siendo la forma de las cartas.

En principio y durante el desarrollo de las funcionalidades de las cartas y la forma que iría

adoptando, se comenzó por un diseño más básico para ir probando distintas posibilidades de cómo

podría ser el diseño:



Otro de los formatos que se iba a adoptar:

Se probó otras versiones con decorado artístico, pero se notaba una

falta de profundidad en la carta, era necesario un grosor en 3D para

intentar dotar de una mayor realidad a las cartas.

Se optó también por clarear la parte de la foto del individuo, para que

las criaturas ocupasen algo más de tamaño dentro de la carta.

En futuros diseños se intentara modelos con algo de profundidad para

intentar dar más realismo a la hora de representar y jugar las cartas.

Para crear una carta dentro del juego se utiliza un mecanismo de creación mediante fichero XML.

Se sigue una plantilla simple diseñada para la generación de las cartas, de esta forma, añadir

nuevas cartas se convierte en una tarea bastante simple, tan solo hay que añadir por separado cada

una como un objeto Monster que es el nombre dado, cada una de las cartas en el XML tendrá un

nombre asignado, vida, ataque, coste y la ruta donde quedara almacenada su imagen para

mostrarla al generarse a partir de la ruta indicada en el atributo PathOfImage. El funcionamiento de

las cartas y su generación se explica en mayor profundidad en el capítulo 7, en el apartado 3.

Otros

Cristal de mana.

Cristal de mana usado.



Capítulo 7 Implementación



En este capítulo procederemos a explicar cómo se ha desarrollado e implementado y el diseño que hemos especificado en los anteriores capítulos. Esta sección está dirigida para entender internamente y a un nivel más técnico.

7.1 Organización del proyecto El proyecto esta subdividido en diferentes carpetas con contenido diferente: CardWarGame: Proyecto Unity 3D

• Assets: Paquetes de recursos. o Editor:

� CrossPlatformInput: Carpeta que contiene el adaptador para adaptar a otras plataformas.

o Fonts: Fuentes usadas dentro del juego. o Images: Imágenes genéricas usadas para representar algunas situaciones en

concreto o Materials: Materiales usados en distintas partes del juego. o Prefabs: Objetos generados por con las propiedades ya establecidas. o Scenes: escenas del juego (pantallas). o Scripts: Código del juego en lenguaje C#. o Sounds: Sonidos del videojuego (música y sonido). o Sprites: Imágenes del juego.

7.2 Mesa de juego Vamos a analizar los diferentes objetos que componen el juego, además de sus agregados y sus utilidades, para entender mejor cómo funcionan y sus diferentes fases.

• InitialTable: GameObject que se utiliza como mesa. En cada nivel, se instancia este objeto de un aspecto similar.

o EventSystem: Evento observador que actúa sobre ciertas acciones, como las de arrastras y detectar actividades que proceden sobre la mesa.

o Botones de cambiado de estado: Estos botones se utilizan para variar de una fase de la partida a otra, entre cambio de turno, estado de ataque y estado de preparación del inicio del turno.

o Players: Esta zona representa a la zona de acción donde cada uno de los jugadores tendrá un control total sobre su zona con las distintas utilidades, los elementos que componen al player, indistintamente de si es un jugador real o la IA son:



� Target: Zona utilizada dentro del marco del jugador para apuntar por el LineRenderer cuando una carta lo marca en el estado de ataque. � AvatarPlayer: Marco del jugador, en el aparece el rostro/figura del enemigo protagonista asignado.

• Box Collider: Se utiliza para saber cuándo se produce una interacción dentro del marco del avatar.

• Script-Clikcable: Este script controla cuando se interacciona con la zona apoyándose en el box-collider indicado en la zona del avatar player. Este script tiene dos métodos esenciales: void OnMouseDown (), controla cada uno de las fases de los objetos que pueden ser marcados (avatares y cartas) se ha de controlar todos los estados para no tener un fallo de memoria al pulsar sobre objetos ya marcados o sobre objetos sin la posibilidad de ser atacados. Bool isPicked (), esta función se utiliza para comprobar si avatar o carta han sido pulsados para atacar o como objetivo de un previo ataque. � NamePlayer: Nombre del jugador

• Text: GameObject canvas donde ira incrustado el texto del nombre del jugador, en el viene cargada previamente la fuente utilizada.

� ManaPlayer: Representa el mana del juego, o también dicho, el coste de la carta a la hora de ponerla en juego.

� PlayerLife: Vida del jugador

• Nlife: Vida del jugador, incrustado con un Text para poder representarla.

� DropZone: Zona donde las cartas atacaran y defenderán contra el oponente.

• Horizontal Layout Group: Propiedad canvas para agrupar varios gameobject en una misma zona, de manera ordenada y espaciada dentro de unos límites pre-establecidos.

• Script-DropZone: script que gestiona la entrada y salida de las cartas dentro de la zona de batalla con las distintas clases que lo componen: Public void OnDrop (PointerEventData eventData): Esta función se activa cuando la carta se deja sobre la dropzone, se cambia el estado de la carta a estado “REST” dejando a la carta parada un turno, posteriormente, se restan los cristales de mana que cueste a los que el jugador tiene en posesión. Public void OnPointerEnter (PointerEventData eventData): Esta función se acciona cuando se está arrastrando la carta y entra en la dropzone el puntero del ratón, creando el efecto del hueco en que la carta se colocara. Public void OnPointerExit (PointerEventData eventData): Función que aparece cuando se esta la carta arrastrando y el puntero sale de la dropzone , en ese momento el objeto vacío que simula la posición que ocuparía la carta se destruye y se devuelve la carta a su antigua



posición, pudiendo recolocarla dentro de la mano (handZone), con efectos similares a la dropzone.

7.2 Controlador de juego

•••• GameManager: No es más que un objeto vacío, hará funciones de observador del juego, controla el flujo de información de la partida y aporta funcionalidades básicas, es posiblemente el GameObject más importante de este proyecto.

o Audio Source: El sonido que ira incrustado en el juego, al igual que la música de fondo, van dentro de este componente.

o Buttons Controller – script: Este script es el encargado de gestionar las diferentes acciones que se ejecutaran dentro del tablero cada vez que se pulsen los botones de cambio de estado dentro de la partida.

� public void PushReady: Función que se activa cuando se pulsa el botón de listo dentro de la partida, en la primera fase del juego, cuando se roba la carta y se puede colocar cartas en la mesa. Esta función deshabilita el botón de listo y se habilita el botón de ataque. Posteriormente, se cambia el modo de cámara a RenderMode.ScreenSpaceCamera, para tener coordenadas de mundo y que se vean ciertos elementos que solo se pueden ver en este tipo de coordenadas (linerenderers). Tras esto, se llama al controlador para preparar a las cartas para el ataque.

1. Public void PrepareTableToAttack: Dentro de esta función, según el turno de un jugador u otro, el que este en posesión del turno, pierde la posibilidad de lanzar más cartas, y las cartas en dropzone se activan para poder atacar (las cartas lanzadas en el mismo turno no atacan hasta el siguiente turno).

� Public void EndAttack: Se activan las funciones de hacer daño con la siguientes secuencias y comprobaciones:

1. Public void DoDamage: Se comprueba que jugador tiene el turno y se recorren todas las cartas que atacan, primero comprueba a que cartas se van a atacar, y se produce el ataque, restando vida a carta atacada y que ataque correspondiente al valor de ataque de la contraria, si el valor de una carta desciende a 0 o menos, se destruye. Posteriormente, se comprueba las cartas que atacan al marco. Si se reduce la vida del jugador a 0 se termina la partida para el player 1 y si se gana a la IA se avanza a la siguiente partida o se termina el juego y se consigue la “victoria”.

Si la partida no se ha terminado en este trato, se continúa la partida. Automáticamente después de los ataques, se limpian los diccionarios donde se almacena cada una de las cartas atacantes y atacadas, al igual que los marcos. Posteriormente, se deshabilita el botón de ataque y se activa el de finalizado de turno, para cederle el turno al otro jugador. Tras el cambio de botones se



activa una función de transición muy importante para el transcurso de la partida:

• Public void PutCardInRest: Esta función gestiona el cambio de estado de la dropzone de “Battle” a un estado de “REST”, para el reposo de las mismas.

Como paso final de este método, se devuelven las coordenadas a un estado inicial, cambiando el render mode de la mesa.

� Public void DisableAllButtons: Función que actúa cuando se finaliza la partida, desactivando todas las funciones para evitar que el jugador realice más acciones tras terminar el juego.

o Enemie_Action – script: Script que controla las actividades del enemigo del juego, esta parte será explicada en la sección del enemigo, donde se detallara más a fondo el funcionamiento de este script.

o Game Controller – script: Script responsable del gobierno y control total del juego, prácticamente todo el flujo y todo control, por temas de seguridad, pasa por este script. Se explicara en detalle las funciones más importantes:

� Private void Awake: La función Awake se activa cuando se comienza la partida, se recibe la instancia creada en la pantalla de inicio y se sitúan todos los elementos, tanto visuales como GameObject sobre los que se poseerá el control como jugador.

� Void Start: Tras el Awake, se ejecuta la función Start, en esta parte del código, se activa el sonido y comienza toda la gestión interna.

� Private void initializeTable: Función que inicializa los elementos de la mesa, se generan los monstruos y se asignan 3 aleatorios por cada jugador.

� Void selectInit: Esta función selecciona quien empieza de los dos jugadores, de forma aleatoria.

� Public void manageGame: Se activa al principio de la partida y cada vez que se pasa de turno, se controla los cristales de mana actuales sino llega a 10, el máximo, se suma 1 al principio de cada turno del jugador.

� Public void pushNext: Cuando se pulsa el botón siguiente del controlador de botones, llama a esta función dentro de esta script, se gestiona el cambio del estado de las cartas, se cambia el turno entre los distintos jugadores y se recargan todos los cristales de mana para el jugador que da comienzo la partida. Posteriormente, se añade una nueva carta a la mano por medio de la función AddNewCard.

� Public void isUsableThisCard: Función que se controla si una carta se puede usar en el turno, se compara el coste de la carta con los cristales de mana del jugador que está en su turno.

� Public void DisabledZaphires: Método que se acciona cuando se lanza una carta a la dropzone. Se compara los cristales que tiene el jugador y los que cuesta la carta, se quitan los que se han usado y se mantienen los que aún se conserva por si se quiere lanzar más cartas.

� Public void DisableHandPostDrop: Tras el lanzamiento de una carta, se activa este método, se revisa la mano del jugador y se comprueba las cartas que aún se pueden seguir lanzando tras desactivar los cristales de mana.



� Public void ChangeStateOfCard: Función que cambia el estado de las cartas de “REST” a “BATTLE”.

� Public void selectTargetToAttack (GameObject target): Función que se acciona tras marcar una carta rival para atacar, el método lo que hace es a partir de una carta origen y un objetivo pasado por parámetro a este método, crea un linerenderer para que se pueda apreciar el ataque entre dos cartas.

� Public void attackToAvatar: Función similar a selectTargetToAvattar, pero el linerenderer se crear a partir de una carta origen y el avatar del enemigo contrario.

� Public void AddNewCard: Función que se activa cuando se cambia de turno, se comprueba la cantidad de cartas del jugador que iniciara la partida, si tiene menos de 5 cartas añade otra nueva, sino no se produce la acción de añadir carta.

Dentro de GameController existen más funciones ya citadas en otros puntos o sencillamente son funciones creadas para cumplir pequeños chequeos o funciones que solo se producen por medio de la IA que se explicara a continuación.

7.3 Cartas El elemento principal del juego, encargado de representar los objetos de acción y por los que se realiza la partida.

•••• CardWithSelector: Este GameObject está formado por otros GameObjectChild, dando la forma final que tendrá la carta. Se explicara cada uno de los elementos asociados a continuación. o Rect Transform: Composición de tamaño y escalado del objeto con respeto a la figura inicial. o Image: En este componente se reservara el espacio donde ira la foto de la carta asociada. o Layout Element: Las cartas, como irán dentro de espacios formados por group layout, necesitan la propiedad layout element para poder, eficientemente irse ordenando conforme se

vayan colocando y adaptando según las necesidades del espacio disponible. o Canvas group: Otro elemento canvas para indicar que formaran parte del grupo de

la zona donde se colocara, en este punto es vital marcar la opción BlocksRaycats, sin esta opción, el ratón no detectara en que zona se quiere dejar la carta y solo detectara el fondo de la carta.

o Box Collider: Para detectar interacciones con la carta. o Draggable – script: Script ya explicado anteriormente, funciona al detectar cuando la

carta se arrastra, sirve para simular el efecto de donde se situara la carta y el espacio que dejara, al igual que el ordenado de los group layout.



o Clikcable – script: Este script funciona únicamente cuando la mesa está en estado de ataque, el jugador en turno, puede marcar las cartas en modo “Battle” :

� Public void OMouseDown: Esta función, explicada anteriormente, se activa cuando se pulsa una carta en modo batalla, pero, realmente explicaremos los puntos sobre los que se apoya cuando se pulsa según que condición.

1. Primero, comprueba que lo que se está pulsando, no sea ni un avatar, que sea una carta en modo “Battle” y que no haya sido “pickeada” o clicada con anterioridad. Si entra en esta condición, se pone esa carta como “pickeada” y se asigna como carta origen de ataque.

2. De no cumplir la primera condición pasaría a esta segunda, en este punto, se comprueba si la carta ya ha sido “pickeada” y además se encuentra almacenada en el diccionario de cartas para atacar, es decir, que ya ha sido seleccionada con anterioridad para efectuar un ataque en este turno, ¿Por qué esta opción? Puesto que si queremos no efectuar un ataque a cierta carta, podeos indicar que no queremos efectuar ese ataque simplemente volviendo a pulsar sobre ella.

3. En el tercer punto, se busca que lo seleccionado no sea un avatar o marco de jugador, que pueda ser un objetivo de un ataque, es decir, carta en la dropzone contraria y no este marcado con anterioridad. Automáticamente se genera un linerenderer porque, de cumplirse esta condición ya se visualizaría un posible ataque entre cartas que no se efectuaría hasta pulsar en el botón de “ATACAR”

4. Esta cuarta opción es para los ataques efectuados sobre los marcos de avatares entre jugadores, se atacara al marco contrario para esta condición se requiere que el marco pueda ser atacado y si efectivamente, es un marco o avatar. En este punto, como en el anterior, se crea un linerenderer simulando una línea de ataque entre ambas partes.

5. Si se quiere eliminar un linerenderer entrara en esta última condición, tras pasar todas las anteriores condiciones se comprobara que existe un vector de ataque entre ambas cartas para posteriormente eliminarlo para corregir el ataque o simplemente no efectuarlo por decisión propia.

o Card – script: Script que gestiona todos los datos de la carta, al igual que los GameObject de los que se compone la carta para, una gestión más eficiente, se almacenan tanto datos lógicos (strings con nombre, valores de la vida y ataque como enteros y path de la ruta de las imágenes). Cabe destacar la función build, que se llama en el momento que se agrega una carta a la mano, almacenando todos los valores relacionados con esa carta dentro de esta clase para lleva un control de todos sus datos.



7.4 Jugador

•••• PlayerGO: El jugador esta implementado de forma que es un objeto vacío, con una serie de acciones prefijadas sobre ese “empty GameObject” dando el gobierno sobre su parte de la mesa y las cartas que se vayan robando de mazo.

o Camera: La cámara asociada a este objeto posiciona la cámara sobre la mesa, con la visión que tendrá el jugador dentro del juego.

o Player-script: Es un script similar al de carta, se almacena tanto la parte de objetos de la mesa asociados al jugador, para que exista la posibilidad de acceder a ellos de una forma más rápida y eficiente. Además de la información de los objetos relacionados, también se almacenan datos como la vida, numero de cristales de mana en el turno en valores enteros, así como si es el turno o no, en valor bool. Con esto se pretende separar la gestión de los objetos y la parte de valores lógicos para que exista un entendimiento más rápido y el propio jugador tenga acceso a sus recursos de una forma más rápida reduciendo el tiempo de ejecución de ciertas acciones.

o Player_Actions – script: Acciones asociadas al jugador que puede activar durante las diferentes fases de la partida, las analizaremos a continuación:

o Void Awake: Se activa en el momento de creación de la clase, lo único que hace por defecto es asignar el turno a falso, puesto que es el controlador quien decidirá quién de los dos jugadores empezara la partida.

o Public Player getPlayer y setPlayer (Player _jug): Ambas clases como su nombre indica funcionan de manera se devuelve el jugador con él se está trabajando y se asigna uno para facilitar el uso del mismo y acceder de manera sencilla a los métodos y atributos que contiene.

o Public void changeTurn: Gestiona al final del turno el cambio de quien podrá jugar en la siguiente ronda, únicamente, el método cambia el valor del atributo isMyTurn este a como este de true a false y viceversa.

o Public void canPlay: Devuelve el valor del turno para saber si el jugador puede jugar o no.

o Public void putCardInRest: Esta función se activa al final del turno del jugador, sencillamente, se recorre la dropzone y las cartas que estén dentro serán cambiadas a un estado “REST”.

o Public void restoreZaphires (GameObject zhapire): En este método restaura los cristales de mana al final del turno, cambia las imágenes de cristales bloqueados por cristales disponibles.

7.5 Enemigo

El enemigo va incrustado dentro del GameObject observador del juego, el script de las acciones esta también dentro del GameManager, vamos a proceder a explicar los distintos métodos asociados a este script:



o Public void checkCards (Player player1): Función que escoge las cartas disponibles que puede lanzarse en el turno del enemigo, escoge aleatoriamente una de la mano de las que pueden usarse.

o Public void putCardOnTable (GameObject card, Player player1): Función llamada desde checkCards, una vez seleccionada la carta se elimina el reverse de la carta enemiga y es colocada en la mesa, al igual que se gestionan los cristales gastados.

o Public void sendToAttack (GameObject card, Player player1): Se selecciona una carta de las disponibles para atacar a un objetivo aleatorio y se pulsa el botón de ejecutar el ataque.

7.6 Menú de configuración El menú de configuración es el elemento de control sobre la música, efectos de sonido y la posibilidad de retornar a la partida o volver a la pantalla de carga.

• Settings_panel: Panel que contendrá todo el control y gobierno sobre sonido y efectos, dentro de él existen diferentes elementos que lo componen citados a continuación

o Volume: Texto de volumen

o Sound: Texto de sonido

o Music_check: Checkbox utilizado para controlar el estado de la música, con el check activado significara que la música de fondo está habilitada. o Sound_check: Checkbox utilizado para controlar el estado de los efectos de sonido, con el check activado significara que los efectos de sonido están habilitados. o Button_exit: Botón de salida, este botón al pulsarlo nos preguntara si estamos seguros de volver a la pantalla de carga. De ser una respuesta afirmativa volveremos a la pantalla de carga, al pulsar no, volveremos al

menú de configuración. o Button_return: Botón de retorno al juego ocultando de nuevo el menú de

configuraciones.



Capítulo 8 Pruebas



En este capítulo se realizaran diversas pruebas y revisar el funcionamiento de la aplicación. Al haber utilizado una metodología incremental, en cada iteración se han hecho pruebas sobre lo existente, por lo tanto en esta sección se realizaran pruebas globales y no sobre lo implementado en cada iteración. Para la realización de este punto se van a utilizar las estadísticas ofrecidas por Unity3D que permiten conocer en tiempo real el comportamiento del dispositivo durante la ejecución del videojuego.

8.1 Pruebas generales

El principal objetivo que un videojuego debe ofrecer es tener un buen tiempo de respuesta

para el jugador o será un motivo de abandono del juego. Los jugadores esperan siempre jugar sin ningún tipo de restricción y sin molestia alguna, por lo tanto este debe de ser un factor muy importante a la hora de evaluar el rendimiento. Esta sección tratara por lo tanto, de evaluar los aspectos más importantes durante la ejecución del videojuego.

Las pruebas han sido realizadas sobre un ordenador Mac Book pro con un procesador Intel

Core i7 2’3GHz 8GB de RAM DDR3 y una tarjeta gráfica NVIDIA GeForce GT 650M 1GB. Se han realizado pruebas sobre Windows 7 a través de una máquina virtual sobre el mismo equipo para comprobar la respuesta sobre este sistema operativo también.

Prueba PR-01-Carga de partida

Prerrequisito

Procedimiento 1. Introducir el nombre del jugador y cargar partida.

Resultado esperado Cargar partida en menos de un segundo.

Resultado obtenido La partida empieza en 0.5 ms

Tabla 78. PR-01-Carga de partida



Tras varias pruebas similares se observa unos valores de respuesta muy similares, realizaremos una

prueba de cuanto tarde en pasar turno, para ver cuánto tiempo tarda en tomar el control la

máquina.

Prueba PR-02-Cambiar turno

Prerrequisito Estar en partida y estar en turno

Procedimiento 1. Pasar de listo a ataque 2. Pasar de ataque a Listo 3. Cambiar el turno

Resultado esperado Pasar el turno a la IA en menos de 1 segundo

Resultado obtenido El turno se ha pasado en 0.8 ms

Tabla 79. PR-02-Carga de partida

Comprobamos claramente que tenemos unos tiempos de respuesta sobre lo esperando, por menos de un segundo de espera, lo que produce un tiempo de respuesta muy bueno permitiendo una jugabilidad excelente. Otro elemento en el que debemos de fijarnos es en los FPS, observamos que están en torno a 200-250 de media al no ser un juego de gráficos exigente y al no consumir demasiados recursos del sistema, indicando así con los buenos tiempos de respuesta y gráficos un buen rendimiento.

8.2 Pruebas realizadas en las iteraciones

La mayoría de las pruebas realizadas durante el desarrollo del videojuego han sido probando errores, poniendo situaciones que podrían hacer “crashear” el juego y ponerlo en situaciones anómalas, probando así, atacarnos a nosotros mismo, atacar a cartas aliada, intentar atacar en turnos que no nos corresponden , etc.

Prueba PR-03-Test sobre el sonido

Prerrequisito

Procedimiento 1. El jugador comprobara si el sonido se activa/desactiva cuando se pulsa sobre el botón que gestiona el sonido.

Resultado esperado El sonido se activa/desactiva de forma correcta durante la partida.



Resultado obtenido El sonido se activa/desactiva correctamente en cualquier instante de la partida

Tabla 80. PR-03-Test sobre el sonido

Prueba PR-04-Test sobre la música de fondo

Prerrequisito

Procedimiento 1. El jugador comprobara si la música de fondo se activa/desactiva cuando se pulsa sobre el botón que gestiona el sonido.

Resultado esperado La música de fondo se activa/desactiva de forma correcta durante la partida.

Resultado obtenido La música se activa/desactiva correctamente en cualquier instante de la partida

Tabla 81. PR-04-Test sobre la música de fondo

Prueba PR-05-Comportamiento de las cartas durante la partida.

Prerrequisito

Procedimiento 1. Se prueba que la carta se comporta correctamente durante cada estado que posee, dependiendo también del estado de la mesa

Resultado esperado La carta se comporta correctamente durante toda la partida.

Resultado obtenido La carta responde correctamente ante cada acción por parte del jugador.

Tabla 82. PR-05-Comportamiento de las cartas durante la partida.

Prueba PR-06-Estado de la mesa

Prerrequisito

Procedimiento Se prueba cada una de las acciones que se puedan realizar en cada estado de la mesa.

Resultado esperado Solo se pueden ejecutar las acciones restringidas par cada estado.

Resultado obtenido Las acciones que se realizan son las correctas sin anomalías.

Tabla 83. PR-06-Estado de la mesa.

Prueba PR-07-Fin de la partida

Prerrequisito

Procedimiento No se puede exploitear ni ningún otro procedimiento que ponga el riesgo el buen funcionamiento del videojuego.

Resultado esperado Solo se pueden ejecutar las acciones restringidas par cada estado.

Resultado obtenido Las acciones que se realizan son las correctas sin anomalías.

Tabla 83. PR-07-Fin de la partida



Capítulo 9 Manual de instalación



Este capítulo estará dedicado como se realiza la instalación del videojuego para poder usarse en cualquier equipo Mac o Windows. Lo primero es copiar el archivo Cardgame.exe a nuestro disco duro local de nuestro equipo que vamos a utilizar. Una vez que se tenga el ejecutable en el espacio local los pasos para la instalación serán los siguientes:

1. Ejecutar el archivo Cardgamewar.exe , un setup para realizar la instalación

2. Aparecerá el típico wizard de instalación para guiarnos durante la instalación.

3. Tras pulsar siguiente y aceptar diferentes opciones el juego quedara instalado en el sistema.



La versión de Mac será directamente ejecutable, es decir, tan solo hay que hacer doble clic sobre el ejecutable entregado para probarlo.

En caso de no disponer de un equipo apropiado, el videojuego se puede ejecutar desde Unity3D, para ello, indicaremos los pasos necesarios para su instalación:

1. Descargar: Unity 3D, la versión 5.3.5 tanto para Windows para Mac.

2. Ejecutar: El ejecutable descargado.

Aceptamos los términos para poder continuar la instalación



Seleccionamos los componentes adicionales que se pueden añadir (tvOS Build Support, WebGL Build Support, etc) y tras ello podemos comenzar la instalación.

Antes de comenzar la instalación podemos elegir en que directorio queremos que sea instalado, por defecto aparece en “Program files”, tras eso, puede dar comienzo la instalación. Dependiendo de la conexión, la duración y el contenido adicional que se haya seleccionado, la instalación puede tener distinta duración



Tras terminar el proceso de instalación, nos aparecerá deberá aparecer siguiente mensaje:

3. Abrir: El proyecto pulsando en el botón que pone “Open”

4. Dar: al botón de play para ejecutar el juego como si fuese un ejecutable.



Capítulo 10 Conclusiones



La realización de este proyecto surgió a partir de la afición durante toda la vida a jugar a

videojuegos y a las ganas de aprender a desarrollar videojuegos, algo que todo el que practica este

hobbie siempre ha tenido curiosidad de cómo se crea algo así. Al existir la asignatura de Desarrollo

de videojuegos en la Universidad de Jaén, tuve la gran oportunidad de poder iniciar el aprendizaje

en este mundo, donde se nos inició en el uso de Unity 3D y en buenas practicas a la hora de

desarrollar videojuegos, al igual que cada uno de los aspecto que ha de tener un videojuego

desarrollado en Unity, por eso nació la idea de desarrollar el Trabajo de Fin de Grado alrededor de

este ámbito. El género del videojuego aparece ante tantos años de afición a juegos de estrategia

como Age of Empires 2, Magic en formato físico o la popularidad actual y la diversión que aporta

Hearhstone.

La realización de este documento ha resultado bastante útil a la hora de entender los pasos de

cómo se desarrolla un proyecto de forma completa, desde la parte de ingeniería del software hasta

la parte e implementación y pruebas, teniendo así la posibilidad de aplicar todos los conocimientos

adquiridos durante los años de carrera en las diferentes asignaturas.

Entre los problemas que han aparecido durante el desarrollo han sido sobre todo con tema de

diseño de gráficos, cámaras, al estar el proyecto desarrollado sobre un panel canvas y tener que

intercambiar en ciertas acciones entre coordenadas de mundo y coordenadas de objeto.

Un apoyo constante para poder desarrollar este proyecto ha sido la documentación oficial de Unity

3D, su foro de apoyo con una gran comunidad siempre aportando respuestas y sobretodo

Stackoverflow donde cualquier problema se indica cómo solucionarlo.

Como ayuda externa se ha pedido ayuda a un diseñador ante el gran desconocimiento en diseño

gráfico. Todo el contenido proviene de creative commons.

El proyecto está en un estado de beta/prototipo, la idea final es crear un modelo de juego

multijugador online que termine en la tienda de Steam, como objetivo final. Por lo tanto, el

desarrollo de este videojuego es un prototipo jugable.



10.1 Futuras mejoras

Tras el desarrollo de este proyecto, han quedado varias cosas pendientes que se han tenido que

quedar fuera por falta de tiempo. Los aspectos pendientes son los siguientes:

• Modo historia: Se ha establecido una historia muy simple, lo ideal será desarrollar una

historia con más trasfondo, diseñando más enemigos con distinto tipo de juego.

• Crear y guardar mazos: Ahora mismo el modo de juego predispone de unas cartas

predeterminadas para el jugador que aparecen de forma aleatoria, en el futuro el jugador

podrá crear mazos con las cartas que quiera, guardándolos y compartiéndolos con otros

jugadores para así, crear diferentes posibilidades e interactuando con la comunidad de

jugadores que se planea tener en este juego.

• Multijugador: En este aspecto se ha investigado bastante pero cuando se comenzó a

desarrollar este videojuego existía un modelo de Networking en Unity totalmente distinto

del actual, se ha investigado en este tema bastante aunque aún falta perfilar varios detalles,

en una futura actualización será la primera mejora a incluir dentro del juego para

enfrentarse con otros jugadores de la red.

• Modo aleatorio: Un modo aleatorio con cartas aleatorias con coste aleatorio, esta idea

surge para salir de la rutina del juego normal y probar algo más “distinto” de lo habitual.

Esto hará que el juego no sea tan monótono y los jugadores se enganchen un poco más con

distintas modalidades de juego.

• Compra de sobres: Los sobres nos proporcionaran distintas cartas con poderes, coste,

ataque y defensa aleatorias, serán packs de tres cartas y esta idea de todo aleatorio surgirá

en parte de la idea de Diablo 3, donde se obtenían objetos con estadísticas aleatorias,

generando mazos diferentes y personalizados para cada jugador. Los sobres se podrán

adquirir por medio de una moneda que se creara dentro del juego o con dinero real, para

este último caso se tendrá que habilitar un sistema seguro de pago por medio de un

protocolo seguro.

• Añadir habilidades sobre cartas: Las cartas tendrán que tener distintas habilidades, de

forma que, creando mayor dinamismo aumente la diversión.

• Añadir más efectos: Efectos nuevos de combate, sonido y efectos sobre cartas al entrar en

el tablero de juego.



• Nuevas clases con diferentes características: Crear diferentes clases, con habilidades y

características distintas y posibilidades diferentes, teniendo fortalezas en algunos aspectos y

debilidades en otros.



Capítulo 11 Manual de usuario



En este capítulo va a mostrarse el funcionamiento que tiene la aplicación, así como una

demostración de sus diferentes funcionalidades.

Al abrir el videojuego se mostrará una pantalla de inicio que durara unos segundos. Esta

pantalla no aparecerá en el caso de que obtengamos la versión pro de Unity3D, por lo tanto, la

pantalla mostrada es por haberse desarrollado con este producto.

Después de esperar los segundos de la pantalla de carga se mostrara la pantalla inicial del

juego:

En esta primera pantalla inicial podemos ver diferentes elementos visuales:

• Nombre del jugador: Ahí podremos introducir el nombre que deseamos que tenga nuestro

jugador.

• Clase del jugador: En esta versión beta no afectara la clase del jugador, en futuras versiones,

será importante elegir la clase según la forma que deseamos que se desarrolle la partida.

• El botón de jugar, que dará comienzo a la partida.

• Abajo, tenemos varios botones que gestionaran algunas opciones dentro del juego, de

izquierda a derecha tenemos:

o Botón de salir, al pulsarlo nos preguntara si deseamos salir, si pulsamos en sí, nos

sacara de la partida, al pulsar no, nos devolverá al menú.

o Botón gestor de sonidos, encargado de activar/desactivar efectos de sonido dentro

del juego.

o Botón gestor de música de fondo, encargado de activar y desactivar la música que

sonara de fondo dentro del juego.



Al querer iniciar partida, uno de los requisitos es introducir el nombre del jugador, sino lo

hacemos, nos aparecerá un mensaje de error pidiendo que se introduzca un nombre.

Al introducir un nombre y comenzar la partida nos debería aparecer nuestro primer enemigo Van

Cloff, el cual será nuestro primer oponente dentro del juego:

Las cartas del enemigo vendrán tapadas, para no partir de una ventaja inicial y no poder

contrarrestar la ofensiva. Durante nuestro turno podemos depositar cartas, atacar, pasar el turno al

oponente, entre otras opciones.

Este botón nos muestra las opciones de gestión de sonido, música, volver a la partida o

salir directamente de la partida.



El menú que se mostrara es el siguiente:

Si deseamos quitar el sonido, tan solo debemos desmarcar el checkBox asociado a cada una de las

opciones.

Al hacerlo, automáticamente la música desaparecerá.

Si pulsamos volver o el botón de configuración, nos devolverá automáticamente a la partida con las

opciones actualizadas tras modificarlas.

Si queremos salir del juego tan solo tenemos que pinchar en la opción de salir, al pulsar, nos

aparecerá un menú para decirnos si estamos seguros de salir o volver al juego para continuar la

partida:



Al comenzar la partida, se nos añadirá un cristal de mana a nuestra barra de cristales, que es lo que

nos permite lanzar las cartas dentro de la zona de combate. Si tenemos suficientes cristales para

pagar la carta y depositarla en juego, nos aparecerá marcada en el color verde, que indica que está

disponible para ser lanzada a la mesa.

Al depositar la carta en el tablero automáticamente se nos descontaran los cristales de mana

equivalentes al coste de la carta lanzada.



A la hora de realizar un ataque tenemos la opción de atacar al jugador marcando su retrato o a sus

cartas para evitar que nos hagan daño a nuestros puntos de salud. Cuando una carta está

preparada para atacar, o como también se denomina en esta memoria, en estado de ataque, como

podemos ver a continuación:

Al realizarse ataques entre cartas, se restara a la vida de cada carta el equivalente al ataque de su

oponente. Si una carta pierde todos los puntos de vida, quedara en estado de dead o destruida,

eliminándola del tablero.

Aquí un ejemplo:

Queremos realizar un ataque del kraken (3 puntos de ataque /1 punto de vida) hacia el Corsario (5

puntos de ataque/ 2 puntos de vida), para ello, marcamos a kraken y luego a corsario, para que se

vea la línea de ataque. Al producirse el ataque, en el intercambio, ambas cartas quedan destruidas.



Como también podemos comprobar se pueden realizar ataques contra la salud del rival, de esta

forma, dejándolo a 0, podemos avanzar hasta posteriores fases.

Si el oponente reduce nuestra salud a 0 tendremos que comenzar de nuevo desde el primer

oponente para derrotar a todos de nuevo.

Si vencemos a Van Cloff, que es nuestro primer oponente tendremos que enfrentarnos

posteriormente al oponente final, Buoda.



Al avanzar de nivel, el fondo y la temática según la historia cambia para intentar ambientar las

partidas, las diferentes estrategias y descubrir cómo actúa la IA quedara a cargo del usuario que

juegue, siendo de esta forma el protagonista del juego.



Capítulo 12 Bibliografía



Este capítulo contiene la bibliografía y webgrafia a la que se ha acudido a la hora de realizar el

proyecto y la documentación:

[1] dev.org.es. La industria española de producción de videojuegos se dispara en tasas de

crecimiento de dos dígitos [en línea]. Disponible en: http://www.dev.org.es/es/noticias-a-

eventos/notas-de-prensa-dev/216-la-industria-espanola-de-produccion-de-videojuegos-se-dispara-

en-tasas-de-crecimiento-de-dos-digitos . Publicado en: 2015

[2] Unity Technologies. Unity Manual [en línea]. Disponible en: http://docs.unity3d.com/Manual/ .

Publicado en: 2015

[3] Blog Historia de la Informática. Steam [en línea]. Disponible en:

http://histinf.blogs.upv.es/2013/12/17/steam/ . Publicado en: 2015

[4] Exit Games. Realtime Intro. Disponible en: https://doc.photonengine.com/en-

us/realtime/current/getting-started/realtime-intro .2016

[5] Exit Games. Turn Matchmaking and lobby [no disponible]

https://doc.photonengine.com/en/turnbased/current/reference/matchmaking-and-lobby .

Publicado en: 2015

[6] Oliver Eberlei. New Photon Unity Networking Tutorial Series [en línea]. Disponible en:

http://forum.unity3d.com/threads/new-photon-unity-networking-tutorial-series.241158/ .

Publicado en: 2011

[7] playMaker. PhotonNetworkConnectionUsingSettings [en línea]. Disponible en:

https://hutonggames.fogbugz.com/default.asp?W902 Publicado en: 2012

[8] PlayMaker. Photon DemoWorker Connection Fsm [en línea]. Disponible en:

https://hutonggames.fogbugz.com/default.asp?W864 Publicado en: 2012

[9] CJR Gaming. Refactoring for MVC [en línea]. Disponible en:

http://cjrgaming.com/drupal/node/60 Publicado en: 2011

[10] NevaK. Random Fixes [en línea]. Disponible en:

http://notamentalparaelfuturo.blogspot.com.es/ Publicado en: 2013



[11] Claywilkinson, Plugins for Unity, https://github.com/playgameservices/play-games-plugin-for-

unity/blob/master/README.md . Último acceso: Diciembre 2015.

[12] Creative Commons España, http://es.creativecommons.org. Ultimo acceso: Mayo 2016.

[13] GC Cookie Inc. Learning Network scripting in Unity 3D [no disponible]

https://cgcookie.com/unity/2011/12/20/introduction-to-networking-in-unity/ .Ultimo acceso en:

Noviembre 2015.

[14] Unity. Unity Answers [en línea]. http://answers.unity3d.com/ . Ultimo acceso: Diciembre 2015.

[15] Pixabay. Hearth Design [no disponible] https://pixabay.com/es/coraz%C3%B3n-el-amor-san-

valent%C3%ADn-rojo-150863/ . Ultimo acceso: Junio 2015.

[16] StackOverflow. Diversas preguntas [en línea], http://stackoverflow.com/ . Ultimo acceso: Mayo

2016.

[17] Pngimg. Png free Images [en línea]. http://www.pngimg.com/ .Ultimo acceso: Diciembre 2015.

[18] Alexander Haider. How to create a lighting strike in Unity2D [en línea].

http://www.bloodirony.com/blog/how-to-create-a-lightning-strike-in-unity2d .Ultimo acceso en:

Junio 2015.

[19] GameDev [en línea]. http://www.gamedev.es/. Ultimo acceso: Diciembre 2015.

[20] Game Development. StackExchange [en línea]. http://gamedev.stackexchange.com/ .Ultimo

acceso: Febrero 2016.

[21] Reddit [en línea]. https://www.reddit.com/r/Unity3D . Ultimo acceso: Diciembre 2015.

[22] Unify Community [en línea]. http://wiki.unity3d.com/ .Ultimo acceso: Junio 2015.

[23] Microsoft. Developer Network [en línea]. https://msdn.microsoft.com .Ultimo acceso: Junio

2015.

[24] Gedesco Blog. El auge de los videojuegos no frena [en línea]. http://www.gedesco.es/blog/el-

auge-de-los-videojuegos-no-frena/ .Ultimo acceso: Febrero 2016.



[25] Expansión. La industria del videojuego, al alza: factura un 30% más en 2014 [en línea]

http://www.expansion.com/empresas/tecnologia/2015/07/13/55a3decb22601df04c8b4595.html

.Ultimo acceso: Febrero 2016.

[26] AEVI (Asociación Española de Videojuegos). El videojuego en el mundo [en línea]. Disponible

en: http://www.aevi.org.es/la-industria-del-videojuego/en-el-mundo/ .Ultimo acceso en: Febrero

2016.

[27] Meristation. Hearhstone es el juego de cartas digital con más éxito [en línea]. Disponible en:

http://www.meristation.com/pc/noticias/20-millones-de-dolares-al-mes-en-ingresos-para-

hearthstone/1850096/2078717 .Ultimo acceso: Febrero 2016.

[28] El país. ¿Te gustan los videojuegos? Puedes vivir de ello [en línea]. Disponible en:

http://economia.elpais.com/economia/2014/09/15/actualidad/1410801712_858986.html . Ultimo


[29] Wikipedia. MacBook pro [en línea]. Disponible en: https://es.wikipedia.org/wiki/MacBook_Pro

Ultimo acceso: Febrero 2016.

[30] PlayHS. Charla con el ilustrador de Hearthstone Ben Thompson [en línea]. Disponible en:

http://www.playhs.es/noticias/actualidad-hearthstone/item/1474-charla-con-el-ilustrador-de-

hearthstone-ben-thompson .Ultimo acceso: Junio 2016.

[31] Quill18creates. Unity Tutorial - Drag & Drop Tutorial #1 [RPGs, Card Games, uGUI] [en línea].

Disponible en: https://www.youtube.com/watch?v=bMuYUOIAdnc . Ultimo acceso: Mayo 2015.

[32] Genmymodel. Class Design in Unity3D [no disponible].

https://repository.genmymodel.com/rajaya/Unity . Ultimo acceso: Diciembre 2015.

[33] Softeng. Metodología Scrum para desarrollo de aplicaciones complejas [en línea]. Ultimo


[34] Proyectos agiles. Que es Scrum [en línea]. Disponible en: https://proyectosagiles.org/que-es-

scrum/ . Ultimo acceso: Marzo 2016.

[35] Anexom. 8 juegos de estilo Hearthstone que también conseguirán engancharte por completo

[en línea]. Disponible en: http://www.anexom.es/servicios-en-la-red/videojuegos/8-juegos-de-

estilo-hearthstone-que-tambien-conseguiran-engancharte-por-completo/ .Ultimo acceso: Febrero

2016.



[36] Wikipedia. Card Hunter [en línea]. Disponible en: https://en.wikipedia.org/wiki/Card_Hunter

.Ultimo acceso: Febrero 2016.

[37] Wikipedia. Hex: Shrads of fate [en línea]. Disponible en:

https://en.wikipedia.org/wiki/Hex:_Shards_of_Fate . Ultimo acceso en: Marzo 2016.

[38] Xataka. EA lleva su modelo de suscripción de videojuegos al PC con 'Origin Access' [en línea].

Disponible en: http://www.xataka.com/videojuegos/ea-lleva-su-modelo-de-suscripcion-de-

videojuegos-al-pc-con-origin-access .Ultimo acceso: Febrero 2016.

[39] Wikipedia. Origin [en línea]. Disponible en: https://es.wikipedia.org/wiki/Origin_(software)

.Ultimo acceso: Abril 2016.

[40] Wikipedia. Uplay [en línea]. Disponible en: https://en.wikipedia.org/wiki/Uplay .Ultimo acceso:

Febrero 2016.

[41] Rockstar Games Social Club [en línea]. Disponible en: http://socialclub.rockstargames.com/ .


[42] Magic. The Game. Disponible en: http://magic.wizards.com/es/articles, ultimo acceso en:

Febrero 2016.

[43] Universia España. Trabajar en videojuegos: ¿una carrera rentable? [En línea]. Disponible en:

http://noticias.universia.es/empleo/noticia/2014/10/09/1112918/trabajar-videojuegos-carrera-

rentable.html# Ultimo acceso: Febrero 2016.

[44] Ben Wootten. Diseños de cartas [en línea]. Disponible en http://benwootten.deviantart.com .


desarrollo de un videojuegotauja.ujaen.es/bitstream/10953.1/4005/1/tfg_ruiz_ibáñez...mis amigos...

Documents