1. No category

REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN SUPERIOR
UNIVERSIDAD RAFAEL URDANETA
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA DE COMPUTACIÓN
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
DESARROLLO DE UN JUEGO DE ESTRATEGIA POR TURNOS CON
CAPACIDAD MULTIJUGADOR UTILIZANDO EL MOTOR GRAFICO UNITY
TRABAJO ESPECIAL DE GRADO PARA OPTAR AL TÍTULO DE
INGENIERO DE COMPUTACIÓN
REALIZADO POR:
BR. LEONARDO JOSÉ FUENMAYOR RINCÓN
C.I V.- 23.737.522
BR. CARLOS DANIEL SOTOLONGO GARCÍA
C.I V.- 20.864.934
TUTOR ACADÉMICO:
ING. RAINIER ARAUJO
MARACAIBO, ABRIL 2015
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
DESARROLLO DE UN JUEGO DE ESTRATEGIA POR TURNOS CON
CAPACIDAD MULTIJUGADOR UTILIZANDO EL MOTOR GRAFICO
UNITY
DESARROLLO DE UN JUEGO DE ESTRATEGIA POR TURNOS CON CAPACIDAD
MULTIJUGADOR UTILIZANDO EL MOTOR GRAFICO UNITY
TESISTAS
_________________________________________
Br. Leonardo José Fuenmayor Rincón
S
O
D
VA
C.I. 23.737.522
Teléfono: 04246083843
O
D
H
C
E
ER
R
SE
E
R
S
Email: [email protected]
_________________________________________
Br. Carlos Daniel Sotolongo García
C.I. 20.864.934
Teléfono: 04146444060
Email: [email protected]
TUTOR ACADÉMICO
_________________________________________
Ing. Rainier Araujo
C.I. 18724011
Teléfono: 04146069190
E-mail: [email protected]
Cargo: Docente Instructor
DEDICATORIA
A mi madre Alcira por todo el apoyo brindado durante mi vida y
especialmente durante mi carrera, a mi padre Leonardo por ser siempre
S
O
D
VA
un ejemplo de dedicación y por enseñarme que para lograr nuestras
ER
S
E
R
cuidado y estar siempre hay para
mí
y finalmente pero no menos
S
O
H por quererme y apoyarme desde que nos
importante, a mi novia
Lisbeth
C
E
conocemos.
DER
metas hay que dar nuestro mayor esfuerzo, a mi abuelo Elí por todo su
amor y apoyo durante mi vida, a mi abuela Cira Luisa, por el amor,
Leonardo Fuenmayor
iii
DEDICATORIA
A mi madre Laury por haberme brindado apoyo por todo el transcurso de
mi vida, a mi abuela María por cuidarme siempre y haber estado
pendiente de mí en todo momento, y a Alcira por sus constantes cuidados
y atenciones en todo el tiempo que estuve en la universidad las cuales
S
O
D
VA
necesité.
O
D
H
C
E
ER
R
SE
E
R
S
Carlos Sotolongo
iv
AGRADECIMIENTO
Resulta muy complicado agradecer a todas las personas que durante los
4 años de carrera universitaria me apoyaron, desafortunadamente
siempre estará incompleta la lista de personas a quienes les debo mi
gratitud, y quiero que se pan que aunque no estén acá, igualmente tienen
toda mi gratitud.
S
O
D
VA
R
SE
E
R
S
O
Principalmente agradezco a Dios y a la Virgen de Chiquinquirá por
H
C
E
ER
siempre estar a mi lado en los buenos y los malos momentos de mi vida.
D
A mis padres Leonardo y Alcira por tenerme paciencia y brindarme su
apoyo durante toda mi vida.
A mi novia Lisbeth por aguantar mis abandonos y a pesar de todo por
alentarme siempre a seguir adelante.
A mis compañeros Carlos, María, Lascario, Andrés, Turcio, Jonn, Janco y
Alexander, por el tiempo que pasamos juntos durante más de dos años
compartiendo el “Lugar Feliz”.
A la Universidad Rafael Urdaneta, por haber facilitado los medios, tanto
académicos como económicos para poder alcanzar esta meta.
A todos los profesores que fueron parte de mi formación académica,
especialmente al Ing. Rainier Araujo por ser tutor de este trabajo especial
de grado, al Ing. Jubert Pérez por los conocimientos y la orientación
profesional brindada, y por ultimo al Ing. Carlos Montes por aportar su
ayuda y conocimiento siempre que lo requeríamos.
Leonardo Fuenmayor
v
AGRADECIMIENTOS
Primeramente quiero agradecer a mi madre Laury por haberme
apoyado y por haberme ayudado a llegar hasta este punto de mi vida.
Agradezco a mi abuela María por sus constantes cuidados y
afectos que he recibido de ella.
S
O
D
A mi hermano Luis por haberme apoyado y dadoA
animo en el
V
R
transcurso de mi carrera universitaria.
SE
E
R
S
O
H
Cpor haberme dado ánimo para seguir adelante,
E
A mi novia
Bárbara
R
DE
por motivarme a ser una mejor persona y por estar siempre conmigo
cuando la he necesitado.
A mis amigos Leonardo Fuenmayor, Andrés Ortega, María Grant,
Lascario Pacheco, John Jordan, Alexander Gamero,Janco Boscan y Luis
Turcio por todos los momentos que compartimos y por estar allí conmigo
en el sitio de la universidad que conocíamos como “Lugar Feliz”.
A mis profesores de la Universidad Rafael Urdaneta Jubert Pérez, Nerio
Villalobos, Genyelber Acosta y Carlos Montes por su apoyo y los
conocimientos que me dieron, los cuales me permitirán avanzar en mi
carrera profesional; y a mi tutor de tesis Rainier Araujo que con sus
incesantes críticas me han permitido mejorarme como profesional.
Carlos Sotolongo
vi
INDICE DE GENERAL
pág.
DEDICATORIA………………………………………………..…...iii
S
O
D
VA
AGRADECIMIENTOS..……………………………………….…...v
ER
S
E
R
RESUMEN..………………………………………………………..xii
S
O
H
C
E
ABSTRACT..………………….…………………………………...xiii
DER
ÍNDICE GENERAL…………………………………………….…..vii
INTRODUCIÓN………………………………………....………….1
1. CAPÍTULO I.EL PROBLEMA…………………………….…...2
1.1. Planteamiento el problema……….……….…………… 2
1.2. Formulación del problema…….……….......……..…... 9
1.3. Objetivos de la investigación .…..………………….... 9
1.3.1. Objetivos Generales ……………………………..… 9
1.3.2. Objetivos Específicos …………………….……….... 9
1.4. Justificación ..………………….….……………...…… 10
1.5. Delimitación……………..…………………….……..... 11
1.5.1. Delimitación temporal …………..............………….11
1.5.2. Delimitación espacial ………..……………...………11
1.5.3. Delimitación científica ……………………………....12
2. CAPÍTULO II. MARCO TEÓRICO ….………….………..….13
2.1. Antecedentes…………………….……………………...13
2.2. Bases Teóricas …………..….…………………….…...16
vii
2.2.1. Unity ……..………………….…….….……..…….....16
2.2.1.1. Introducción…………………....…………….. 16
2.2.1.2. Plataformas .………………….………….…... 17
2.2.1.3. Licencias …………………………................ 18
2.2.1.4. Editor…....………………………………...…. 18
2.2.1.4.1. Ventanas……………….…….…..……. 19
S
O
D
A
V
2.2.1.4.1.2. Ventana de juego……….…..….....
20
R
E
S
E
R
2.2.1.4.1.3. Ventana
de jerarquía ……...……... 22
S
O
HVentana
C
2.2.1.4.1.4.
de proyecto ….…...…..… 22
E
R
E
D
2.2.1.4.1.1. Ventana de escena………………...19
2.2.1.4.1.5. Ventana de inspección …..………. 23
2.2.1.4.2. Escenas ..…………..……………….…. 24
2.2.1.4.3. Objetos de juego ………….………….. 24
2.2.1.4.3.1. GameObjectsvacios ..…….………. 25
2.2.1.4.3.2. Camara …….…………………..…...25
2.2.1.4.3.3. Figuras geométricas…………….... 27
2.2.1.4.3.4. Textos………..…………………….. 27
2.2.1.4.3.5. Luces.……………………..……….. 28
2.2.1.4.3.6. Sistemas de partículas…………... 28
2.2.1.4.4. Componentes ..………………………. 29
2.2.1.4.4.1. Transforms………….……………... 29
2.2.1.4.4.2. Rigid Body ………...………………. 30
2.2.1.4.4.3. Mesh Filter ………………………….30
2.2.1.4.4.4. Mesh Renderer …..………...………31
2.2.1.4.4.5. Scripts…………………..…………...31
2.2.1.4.4.6. Meshes ….…....…………….....…...32
2.2.1.4.4.7. Prefabs .……………………...…… 32
2.2.2. Photon Server………………...……………………. 32
viii
2.2.2.1. CaracterísticasPrincipales …..….......….…...33
2.2.2.2. Exit Games Cloud….……….……….………. 34
2.2.2.3. Photon Server SDK ………………….……… 34
2.2.3. Grid Framework ………………………………...… 35
2.2.4. Unity UI 4.6 ……..……………………………….…. 35
2.2.4.1. Características …………………………........ 36
S
O
D
A
V
2.2.6. Angular JS……………………………………..……..38
R
E
S
E
R
2.3. Lenguajes de programación
a utilizar……………..….40
S
O
CH
2.3.1. C#R
.......................................................................
40
E
E
D
2.3.2. Javascript ............................................................. 40
2.2.5. Postgre SQL………………………………………….37
2.3.3. PHP....................................................................... 41
2.3.4. SQL ...................................................................... 42
2.4. Videojuegos y sus elementos ................................... 42
2.4.1. Videojuego ........................................................... 42
2.4.2. Genero de videojuegos ........................................ 44
2.4.3. Sprites ................................................................. 45
2.4.4. Texturas .............................................................. 45
2.4.5. Soundtracks …......................................................46
2.4.6. Historia ................................................................ 46
2.4.7. UI......................................................................... 46
2.4.8. Jugabilidad ........................................................... 47
2.5. UML .......................................................................... 50
2.5.1. Diagrama entidad relación.....................................50
2.5.2. Diagrama de clases ............................................. 51
2.5.3. Diagrama de casos de uso .................................. 51
2.5.4. Diagrama de componentes .................................. 52
2.6. Pruebas de software ................................................. 53
ix
2.6.1. Prueba de estrés................................................. 53
2.6.2. Beta Testing ....................................................... 54
2.7. Tabla de variables ....................................................55
3. CAPÍTULO III. MARCO METODOLÓGICO…………....….56
3.1. Tipo de Investigación…………….......………………..56
S
O
D
A
V
3.3. Técnica e instrumentos de recolección
de
datos…...58
R
E
S
E
R
3.3.1. Revisión documental………………………….....…58
S
O
H
C directa…………………………...……59
3.3.2. Observación
E
R
DE
3.3.3. Instrumentos……….….………...………………..…59
3.2. Diseño de Investigación………………..……………...56
3.3.4. Cuadernos de notas ……………….……………… 59
3.4. Unidad de análisis ………………………….………… 59
3.5. Fases del proyecto ……………………………….. …. 60
4. CAPÍTULO IV. ANÁLISIS DE LOS RESULTADOS ……....62
4.1. Análisis de los Requerimientos Básicos….……...…..62
4.1.1. Requerimientos de hardware………………….……62
4.1.2. Requerimientos de software ……..…………….…..63
4.2. Requerimientos de diseño……………..…....…..…….63
4.3. Modelado de datos………………………..………..…..64
4.3.1. Casos de uso ………………………………..…...… 65
4.3.2. Modelo de datos…………….……………..…...……68
4.3.3. Entidad relación……………………………….....…..69
4.3.4. Diagrama de despliegue……………………….……75
4.3.5. Diagrama de clases ………………….….............…77
4.4. Diseño y esquematización de los aspectos visuales.89
4.4.1. Diseño de la aplicación web……..……………...…89
x
4.4.2. Diseño de las interfaces del juego……..…….....…94
4.4.3. Diseño de los models de las unidades ………….. 98
4.4.4. Diseño de los ambientes de juego ………….....… 99
4.4.5. Diseño de los efectos especiales del juego…..…109
4.5. Codificación…………………………….........………..110
4.5.1. Codificación del servidor del juego ........……...…111
S
O
D
A
V
4.5.3. Codificación del juego…………………………......121
R
E
S
E
R
4.6. Evaluación del sistema……………………………….132
S
O
H
Caceptación…………………………...…132
4.6.1. Prueba
de
E
R
E
D
4.6.1.1. Diseño de la prueba de aceptación ..…..…133
4.5.2. Codificación de la aplicación web……………......112
4.6.1.2. Resultado de la prueba de aceptación ….. 134
4.6.2. Prueba de estrés…………………………….....….139
4.6.2.1. Resultados de la prueba de estrés…….....140
CONCLUSIONES……………………………….….........……..142
RECOMENDACIONES…………………….…………..............144
REFERENCIAS BIBLIOGRÁFICAS ….……………...……….145
xi
Fuenmayor Rincón Leonardo José, Sotolongo García Carlos Daniel,
“Juego de estrategia por turnos con capacidad multijugador
utilizando el motor gráfico Unity”, Universidad Rafael Urdaneta,
Facultad de Ingeniería de Computación. Trabajo especial de Grado,
Maracaibo Abril, 2015.
R
SE
E
R
S
RESUMEN
S
O
D
VA
HO
C
E
juego de estrategia
ER por turnos con capacidad multijugador utilizando el
D
motor gráfico Unity. La investigación realizada fue de tipo proyectiva,
La presente investigación se realizó con el objetivo de desarrollar un
definida según su diseño como tipo no experimental descriptivo. Se utilizó
la observación directa en conjunto con la recopilación de elementos
documentales para obtener la información necesaria para poder realizar el
juego. Este juego se desarrolló implementando la metodología Scrum, la
cual consiste en trabajar por módulos y realizarlos en varias iteraciones
de alrededor de 2 semanas cada uno. Se utilizó PHP como lenguaje de
servidor, se usó HTML y Javascript para el cliente junto al framework de
Angular; y se utilizó C# para el desarrollo del juego. Para el manejo de
base de datos se utilizó Postgres SQL. Finalmente se logró desarrollar el
juego de estrategia por turnos con capacidad multijugador utilizando el
motor gráfico Unity, que permite a los jugadores gestionar sus cuentas a
través de una aplicación web para luego entrar al juego y poder jugar con
otros jugadores a través de internet.
Palabras claves: Unity, Aplicación web, Juego web, Multijugador.
xii
Fuenmayor Rincón Leonardo José, Sotolongo García Carlos Daniel,
“Multiplayer turnbased strategy game develoved using Unity Engine”,
Universidad Rafael Urdaneta, Facultad de Ingeniería de Computación.
Degree Thesis, Maracaibo April, 2015.
S
O
D
VA
R
E
S
E
This research was conducted with R
the objective of developing a
S
HOgame using Unity Engine. The research
Multiplayer turn based C
strategy
E
ER type, defined according to its design as the type not
was of the
Dprojective
ABSTRACT
experimental and descriptive. Direct observation was used in conjunction
with the collection of the necessary documents to develop the game. The
game was developed to implement the methodology Scrum, which consist
on working on modules and developing each module in different iterations
that last around two weeks. To develop the game, PHP was used as the
server language, the client of the application used HTML and Javascript,
alongside with the Angular Framework, and for the game itself C# was
used to develop it. For the management of the database, Postgres SQL
was implemented. Finally, the development of the Multiplayer turn based
strategy game using Unity Engine was successful, allowing players to
manage their in-game accounts using a web application so they could play
with other players online.
Key words: Unity, Web application Web game, multiplayer.
xiii
4
INTRODUCCIÓN
En la industria del ocio y el entretenimiento audiovisual e interactivo
los videojuegos ocupan un gran lugar, abarcando campos como la
música, el diseño y la programación. Los videojuegos han avanzado
S
O
D
VA
mucho desde sus inicios hasta nuestros días, presentándose en una gran
Rha
variedad de formas, con diferentes historias y mecánicas de juego.
SE
E
R
S
HO
C
E
y rayas en una
pantalla verde, hasta presentar modelos de videojuegos
ER
D
en tercera dimensión (3D) con apariencias que en ocasiones se
La
industria
de
los
videojuegos
evolucionado
enormemente, pasando de videojuegos donde solo se manejaban puntos
confunden con la realidad. En el mercado se encuentra mucha demanda
de algunos géneros de videojuegos, como por ejemplo los llamados
“shooters” en primera persona, en tercera persona y los juegos de
aventura.
Pero géneros como los juegos de puzzles, juegos de plataforma o
juegos de estrategia no son tan buscados y por ello no se desarrollan con
mucha frecuencia. Inclusive, las plataformas a las cuales se dirigen dichos
juegos son únicamente dirigidos a consolas de videojuegos o como
juegos nativos para Windows, sin considerar los juegos para los browsers.
Esta investigación busca crear un juego de estrategia por turnos, el
cual se pueda jugar en browsers, con la finalidad de dar una opción a los
jugadores que deseen incursionar en juegos de este género, y que se
encuentre en una plataforma que esté al alcance de muchas más
personas, sin requerir de grandes inversiones en equipos adicionales.
5
CAPITULO I
EL PROBLEMA
1.1. PLANTEAMIENTO DEL PROBLEMA
S
O
D
VA
ER
S
E
R
niveles de poder de procesamiento
para
diversas actividades, programas
S
O
de cálculo, programas
de H
diseño, navegación web, diversas formas de
C
E
R
entrenamiento
DEy demás beneficios. Además de estos beneficios, el
La creación de las computadoras ha traído unas serie de beneficios
para los seres humanos, entre estos beneficios encontramos grandes
hombre ha sido capaz de encontrar formas de entretenerse y divertirse
utilizando las computadoras; gracias a las imágenes, audio, video, internet
y la integración de todos estos elementos han logrado que las
computadoras sean equipos de alta funcionabilidad y capaces de generar
entretenimiento de diferentes maneras.
Con la proliferación tecnológica de las décadas de los 70’s, 80’s y
90’s surgieron en varios países los equipos llamados Arcádes (Belli y
López, 2008), estos equipos eran máquinas las cuales permitían al
usuario jugar el juego predeterminado instalado en dicho equipo. Para
esto, se requería introducir monedas para que el usuario pudiese jugar, y
para poder interactuar con el juego se tenían una serie de botones y
palancas que se utilizarían para mover al personaje e interactuar con su
entorno. Estos equipos generalmente se encontraban en establecimientos
denominados “Arcádes”, llamados así por estar compuestos de equipos
con el mismo nombre,
en estos establecimientos tenían una gran
cantidad de Arcádes cada uno con un juego diferente, con los cuales cada
cliente podía escoger el juego de su agrado y colocando monedas podría
jugar e él.
2
3
Con la invención de unidades de juegos caseras como fueron el
Atari, el NES (Nintendo Entertainment System), SEGA, entre otros, se
estableció un antes y un después en la relación de las personas con los
videojuegos, al pasar estos sistemas de entretenimiento que se
encontraban en lugares específicos a la comodidad del hogar. Posterior a
esto, con el paso de los años se ha visto un gran cambio en estos
sistemas, al verse mejoradas las gráficas, la jugabilidad y las
funcionabilidades dentro de los videojuegos.
S
O
D
VA
R
SE
E
R
S
HO
C
E
R cualquier plataforma electrónica y la participación
computadora,E
usando
D
de uno o varios jugadores en un entorno físico o de red.” Se utilizará la
Usando la definición de Frassca (2001 p.4) se puede definir un
videojuego como “Cualquier forma de software de entretenimiento por
definición presentada anteriormente como base para definir lo que es un
videojuego. Un videojuego es un software dirigido al entretenimiento, con
el cual uno o más jugadores pueden interactuar entre sí a través de un
entorno físico o de red, bajo una serie de reglas para completar uno o
más objetivos.
Cada juego posee una mecánica la cual dicta el comportamiento
del juego y la forma en la cual los jugadores podrán interactuar entre ellos
y con el sistema. Tomando lo que dicen González, Padilla, Gutiérrez, y
Cabrera, (s.f. p.4) sobre las mecánicas de un videojuego o Gameplay:
“La mecánica de un videojuego es la parte más importante, pues
está formado por el conjunto de elementos que caracterizan y
diferencian un juego de otro. Se concretiza el género del
videojuego (arcade, plataformas, simulación, rol, etc.); las reglas,
los objetivos a conseguir y la forma de interactuar para lograrlos a
lo largo del videojuego. Debe contener los elementos para reflejar
4
qué se quiere contar y cómo se quiere contar (storyline y
storytelling).”
Ahora, el género de un videojuego designa un conjunto de juegos
que poseen una serie de elementos comunes. A lo largo de la historia de
los videojuegos aquellos elementos que han compartido varios juegos han
servido para clasificar como un género a aquellos que les han seguido, de
S
O
D
VA
la misma manera que ha pasado con la música o el cine.
R
SE
E
R
S
HO
C
E
jugador y la máquina,
ER la ambientación y su sistema de juego (Gameplay),
D
siendo este último el criterio más habitual a tener en cuenta. Entre los
Los videojuegos se pueden clasificar como un género u otro
dependiendo de su representación gráfica, el tipo de interacción entre el
géneros de juegos que existen podemos resaltar: Los juegos de pelea,
bélicos, carreras, deportes, fiestas, intelectuales, Sandbox, aventura, RPG
(Role Playing Game), RTS (Real Time Strategy), plataformas, estrategia
por turnos, entre otros.
En la actualidad se observa un marcado incremento en el
desarrollo de juegos bélicos. Este tipo de juegos se caracterizan por
mostrar conflictos modernos en los cuales usando armas de fuego,
vehículos
y
armas
modernas
(misiles
controlados
remotamente,
explosivos de detonación remota, cámaras espías, entre otros) deben de
vencer a sus oponentes.
Considerando la definición de Shooter dada por Belli y López (2008 P.10)
se tiene que:
“Videojuegos
de
disparos o Shooters como
un
género
que
engloban un amplio número de subgéneros que tienen la
característica común de permitir controlar un personaje que, por
norma general, dispone de un arma (mayoritariamente de fuego)
5
que puede ser disparada a voluntad. Pertenecen al género de
acción.”
Los juegos del género Shooter se clasifican de dos tipos:
En primer lugar están, los juegos en primera persona, en estos se
controla a un soldado, se interactúa con
el entorno y se observa el
S
O
D
Aambiente se
de tercera persona son aquellos, en los que la interacción
del
V
R
SalEmismo y su entorno se
da utilizando un personaje pero la forma
de
ver
E
R
S
O
da con una vista “sobre el hombro”.
H
C
E
R
E
D
El inmenso auge del género Shooter ha conllevado a que la
ambiente a través de los ojos del personaje; también existen los shooter
orientación de una gran cantidad de desarrolladores se enfoque en una
misma línea temática y en consecuencia que se hayan desligado de una
amplia variedad de géneros. Esto se puede observar en las cifras de
ventas de videojuegos Shooters, tomando como fuente las paginas
Statistic Brain y Wikipedia, se tiene que las cifras de una franquicia
famosa como Call of Duty se observan alrededor de 139.600.000
unidades vendidas; mientras que en los juegos de estrategia como Age of
Empires, se tienen una cantidad de 13.000.000 unidades vendidas.
Ahora, tomando en cuenta los juegos individualmente, el Shooter
más vendido en el mercado es Call Of Duty Modern Warfare III con
23.500.000 unidades vendidas, y el juego de estrategia más vendido ha
sido Final Fantasy VII con 10.000.000 unidades vendidas.
Con estas cifras, se observa que los juegos Shooters superan en
ventas a los juegos de estrategia, esto conlleva a que las empresas y
6
desarrolladores independientes se centralicen en el desarrollo del género
Shooter, lo cual puede producir la desaparición de distintos géneros.
Entre
estos
géneros
de
juegos
que
pueden
desaparecer
encontramos los juegos de estrategia, estos juegos suelen consistir en 2 o
más grupos o ejércitos que se enfrentan y tienen como objetivo vencer a
los otros contrincantes a través de una serie de estrategias de combate,
S
O
D
A etc.
situaciones dadas, manejo eficiente de las tropas V
y recursos,
R
E
S
También se pueden encontrar misiones
con
objetivos específicos como
E
R
S
O
controlar una zona determinada,
capturar un objeto en particular, proteger
H
C
E
R
objetos específicos
por
DE un tiempo determinado, entre otros.
como acciones en conjunto, utilizar unidades especializadas para
Existen 2 tipos de juegos de estrategia: juegos en tiempo real y por
turnos; Los juegos en tiempo real, como su nombre lo indica, son juegos
en los cuales cada acción que un jugador realice sucede en simultáneo
con todas las acciones de los demás jugadores, esto conlleva a que el
tiempo sea un factor determinante en la victoria dentro de estos juegos.
Es importante resaltar que un característica definitoria de este tipo de
juegos es que existen recursos en el medio ambiente los cuales deben
ser conseguidos, las victorias dependen muchas veces de los recursos
que los jugadores sean capaces de obtener y con estos se puede crear o
fabricar las unidades que se utilizaran en el combate, lo cual consume
tiempo. Entre estos juegos encontramos algunos títulos como Age of
Empires, Starcraft, Warcraft, entre otros.
Por otro lado existen los juegos de estrategia por turnos, este tipo
de juego se caracteriza por tener a cada grupo en regiones opuestas de
un mapa, y se enfrentan en la modalidad de turnos para realizar todos sus
7
movimientos y de esta manera lograr posicionar sus tropas para
desarrollar estrategias y finalmente conseguir el objetivo propuesto por la
modalidad de juego seleccionada.
Usualmente, estos juegos tienen sus propias reglas para los
movimientos y tipos de ataques para cada tipo de unidad que se puede
utilizar, adicional a esto, se diferencian de los juegos en tiempo real,
S
O
D
A caballería,
real, solo se tienen a las unidades de guerra (como soldados,
V
R
SEque permiten realizar,
entre otros) que se posean y la cantidadR
deE
ataques
S
O
el factor determinante de H
este
tipo de juegos está determinado por la
EClas unidades en las zonas estratégicas de los
R
capacidad deE
establecer
D
debido a que no hay recursos de la misma naturaleza que los de tiempo
mapas y la manipulación de este recurso. Entre estos juegos
encontramos algunos títulos como Fire Emblem, Final Fantasy Tactics, Yu
Yu Hakusho Tournament Tactics, entre otros.
De los juegos de estrategia, todas las habilidades necesarias para
poder tener éxito en este tipo de juego pueden ser extrapoladas a la vida
real, teniendo por ejemplo el manejo del tiempo y la debida administración
de los recursos como habilidades esenciales para lograr objetivos, tanto
en los juegos como en la vida real; y acostumbrarse a utilizar estas
habilidades constantemente permiten que una persona sea capaz de
realizarlas con mayor eficiencia en cualquier situación en la cual se
encuentre.
A nivel mundial, en materia de desarrollo de videojuegos se
encuentran compañías como Bioware, Bethesda, EA, Activison, e
inclusive se encuentran grupos de desarrollo independientes como
TeamMeat, Uber Entertaiment, entre otros. Además, existe un gran
número de universidades que incluyen estudios avanzados en esta área,
8
como son las universidades de, Carnegie, Mellon University, la New York
University, entre otras.
En Venezuela, en comparación, el desarrollo de videojuegos es un
campo el cual está muy poco explotado, así lo plantean Ciro Durán,
profesor de Desarrollo de Videojuegos en la Universidad Católica Andrés
Bello (UCAB), y Flavia Cassani, directora ejecutiva de Game Species, una
S
O
D
A2012), ellos
entrevista presentada para el nacional (Videojuegos en V
fuga
R
SE encontrar algunos
concuerdan que en Venezuela se
pueden
E
R
S
O
desarrolladores independientes
o grupos de no más de 8 personas; los
H
C debidamente orientados no constan con los
E
R
cuales a pesar
de
estar
E
D
recursos ni apoyo empresarial necesario para el desarrollo del proyecto,
empresa que creó el videojuego My Neighbor The Zombie (MNTZ) en una
lo cual conlleva a que estos sean abandonados por falta de recursos.
Afirman más adelante en el artículo, que Venezuela está siendo
utilizada como borrador para algunos de los proyectos de desarrollo y
cuando estas empresas o grupos se posicionan fuertemente dentro del
mercado venezolano los desarrolladores deciden migrar al exterior en
busca de mejores oportunidades, generando así un patrón que impide el
crecimiento del mercado de desarrollo de videojuegos en Venezuela y
poder posicionar el país dentro de las estadísticas internacionales.
Por las razones anteriormente expuestas, este trabajo de
investigación tiene el objetivo de incursionar en este campo poco
explorado en Venezuela como es el desarrollo de juegos para una
plataforma web, que permita una multiplataformidad y un fácil acceso al
mismo, así mismo se plantea que éste sirva como pivote para futuros
proyectos de desarrollo de este género de juegos y de esta manera lograr
9
una paridad en la cantidad de títulos de juegos presentes en la palestra
de juegos a nivel regional y mundial.
1.2. FORMULACIÓN DEL PROBLEMA:
Tomando en cuenta lo antes señalado, se planteó la siguiente
S
O
D
A capacidad
¿Cómo desarrollar un juego de estrategia por turnos
con
V
R
SE
multijugador utilizando el motor gráfico Unity?
E
R
S
O
H
CLA INVESTIGACIÓN
E
R
1.3. OBJETIVOS
DE
DE
interrogante:
1.3.1. OBJETIVOS GENERAL:
• Desarrollar un juego de estrategia por turnos con capacidad
multijugador utilizando el motor gráfico Unity.
1.3.2. OBJETIVOS ESPECÍFICOS:
•
Analizar los requerimientos funcionales para el desarrollo de un
juego de estrategia por turnos con capacidad multijugador
utilizando el motor gráfico Unity.
•
Realizar el Modelado de Datos para el desarrollo de un juego
de estrategia por turnos con capacidad multijugador utilizando
el motor gráfico Unity.
•
Diseñar y esquematizar los aspectos visuales para el desarrollo
de un juego de estrategia por turnos con capacidad multijugador
utilizando el motor gráfico Unity.
10
•
Realizar la codificación para el desarrollo de un juego de
estrategia por turnos con capacidad multijugador utilizando el
motor gráfico Unity.
•
Evaluar el funcionamiento del juego desarrollado.
1.4. JUSTIFICACIÓN
S
O
D
A factores
V
venezolano no se encuentra desarrollada ampliamente,
varios
R
SEla poca rentabilidad, la
E
han influido en esta situación, la falta de
inversión,
R
S
O
falta de formación académica
y el bajo nivel técnico, más sin embargo lo
H
C
E
R
atractivo D
de esta
E área es que actualmente ha escalado la demanda de los
Actualmente la producción de videojuegos en el territorio
juegos en distinta plataformas (escritorio, web y plataforma móvil), el norte
de este desarrollo se orienta a la interacción entre plataformas y entre
usuarios mediante unas interfaces, sencillas, intuitivas y visualmente
atractivas.
En el ámbito social, esta investigación está orientada a fomentar el
refuerzo de una cultura de desarrollo de videojuegos más amplia de la
que se tiene en este momento, si bien se sabe que en Venezuela existen
varios grupos y empresas pequeñas incursionando en el desarrollo de
videojuegos
no
existe
una
cultura
de
desarrollo
unificada
ni
esquematizada, en tal sentido este proyecto pretende incursionar dentro
de este ámbito y servir como base para futuros proyectos.
En materia económica, el desarrollo de juegos de alta calidad
resulta
bastante
costosa,
presentando
costos
aproximados
de
$200.000.000, sin embargo las ganancias que pueden generar estos
incrementan el interés de los desarrolladores, conformando así un
mercado que crese cada vez más en relación a la cantidad de títulos
disponibles sumando ganancias para las empresas desarrolladoras
11
aproximadamente en $500.000.000 por título, esta situación ha fomentado
la creación de un gran números de empresas especializadas en el
desarrollo de videojuegos.
En el desarrollo de este juego se utilizarán tecnologías de punta
como el motor gráfico UNITY para el diseño aspecto visual del juego y el
desarrollo de las distintas funcionalidades del mismo, en complemento a
S
O
D
A genera el
Photon Server, el primero posee toda la funcionalidad
que
V
R
SEque el segundo es el
tablero que representa el mapa del juego,
mientras
E
R
S
O
que presta los servicios de H
interconexión.
C
E
R
E
D
En el área teórico-metodológica este proyecto servirá de insumo
este se utilizaran adicionalmente dos frameworks, el Grid Framework y el
para futuros trabajos de investigación con objetivos similares y que se
encuentren enmarcados en el ámbito de la Ingeniería de software y el
desarrollo de sistemas web y móviles, y adicionalmente será una fuente
de consulta para interesados en el ámbito de las nuevas tecnologías
direccionadas a medios de entretenimiento.
1.5. DELIMITACIÓN DE LA INVESTIGACIÓN:
1.5.1. DELIMITACIÓN TEMPORAL:
La investigación se realizó entre el período de Junio - Abril
del 2015
1.5.2. DELIMITACIÓN ESPACIAL:
El desarrollo de esta investigación se realizó en la
Universidad Rafael Urdaneta, localizada en la Av. 2, el Milagro con
12
calla 86, entrada sur del parque Vereda del Lago, Maracaibo,
estado Zulia.
1.5.3. DELIMITACIÓN CIENTÍFICA:
El estudio se circunscribió al ámbito de la Ingeniería en
Computación, en las áreas de programación web, Ingeniería de
S
O
D
VA
Software y computación gráfica; específicamente en las sub-áreas
O
D
H
C
E
ER
R
SE
E
R
S
de programación de Videojuegos.
13
CAPITULO II
MARCO TEÓRICO
El marco teórico busca dar a conocer los basamentos teóricos
utilizados para diseñar y estructurar este proyecto de investigación y para
S
O
D
VA
orientar los resultados de la recolección de información. Es decir, se
R
establece las bases teóricas en las cuales apoya esta investigación.
2.1.
O
H
C
E
ER
ANTECEDENTES
D
SE
E
R
S
Al desarrollar un proyecto de investigación en el campo de la
informática es necesario considerar la rapidez con la cual avanzan las
tecnologías que se pueden utilizar para el desarrollo de aplicaciones, y las
distintas formas en las cuales se pueden utilizar para lograr producir, en el
caso de esta investigación, un videojuego.
Jason Dansie (2013) en su tesis “Game Development in
Unity” para alcanzar el título de ingeniero en Sistemas de Informacion en
la universidad Helsinki Metropolitan University of Applied Sciences,
describe como objetivo de su investigación examinar la forma en la cual
los videojuegos son diseñados y ver como las diferentes mecánicas de
juegos trabajan y la forma de aplicarlas en el desarrollo de un videojuego;
además de los efectos positivos y negativos de los videojuegos en las
niños y adultos. Esta tesis muestra cómo se hacen juegos en general
usando el motor Unity 3D, muestran el uso de la interfaz, la forma de
crear la lógica de varios juegos, la interacción con el juego y otras
mecánicas del juego.
13
14
En sus conclusiones dijeron que los juegos son capaces de afectar
a la persona cuando se tratan de juegos violetos, y que juegos sin
violencia calmaba a los jugadores, además de que este tipo de juegos son
preferidos por las audiencias de entre 4 a 8 años. Esta tesis permite como
aporte a la presente investigación una idea de la forma de crear juegos y
varias de las herramientas presentes en la herramienta Unity 3D, además
de permitir tener idea de lo que se puede hacer con esta herramienta y la
forma de hacerlo.
S
O
D
VA
R
SE
E
R
S
HO
C
E
tecnologías E
de R
telecomunicaciones en la Universidad Politécnica de
D
Catalunya, habla de una de las capacidades más importantes dentro de
En la tesis “Study of Multiplayer Features of Unity Applications” de
David López (2013) para alcanzar su maestría en Ingeniería y Manejo de
los juegos que se están desarrollando hoy en día es la capacidad
multijugador, la cual es la capacidad de 2 o más jugadores participando
en un mismo juego simultáneamente; y gracias al internet, esta capacidad
se ha podido aprovechar de manera extraordinaria.
Para el desarrollo de videojuegos con capacidad multijugador
utilizan Unity, y muestran las herramientas nativas de Unity para lograr la
interconexión entre varios jugadores resaltando las ventajas, desventajas
y limitaciones de dichas herramientas; para posteriormente programar
nuevas herramientas para lograr la interconexión para lograr realizar un
juego con capacidad multijugador. Esta tesis dio el aporte de mostrar el
funcionamiento de las capacidades multijugador de Unity, y con esta base
se decidió utilizar otra herramienta dentro de la tienda interna de plugins
de Unity y se escogió Photon Server para lograr la interconexión entre los
jugadores.
15
En la tesis de Igor Galochkin titulada “Implementation of a crossplatform strategy multiplayer game based on Unity 3D” para su título de
Ingeniero en Informatica en la Universidad Técnica de Múnich, describe
información acerca del desarrollo de las peculiaridades de los juegos de
estrategia y de juegos móviles desde el punto de vista del desarrollador, y
describen la arquitectura del juego y de las tecnologías a utilizar y los
retos técnicos para el desarrollo de un videojuego.
S
O
D
Ademo de un
Los objetivos de la tesis en si fue el desarrollo de
un
V
R
SE
juego de estrategia multijugador en tiempo
real
cross-platform utilizando
E
R
S
Unity 3D Pro. De esta tesisH
seO
tomó algunas de las ideas planteadas del
C
E
R de estrategia del lado del desarrollador y se tomaron
desarrollo deE
juegos
D
en cuenta la forma en la cual implementaron la interfaz de usuario dentro
del juego para permitir un mejor manejo de las unidades y del juego en sí.
Finalmente, en la tesis “Android Shooting Simulation Videogame”
realizada por Pham Dan Tien (2013) para su título de Ingeniero de
Computación en la Vietnam National University, en ella se realizó un
videojuego de simulación de vehículos de combate aéreos, en el cual con
la utilización de aviones tienen que destruir a los adversarios. Los
objetivos de esta tesis consistieron en lograr crear un videojuego para
Android el cual emulara lo más cercanamente posible el movimiento y las
acciones de aviones de batalla implementando una jugabilidad cómoda y
divertida para el usuario; además de integrar un sistema de mejoras y
variedad de escenarios para el juego.
Entre las conclusiones a las cuales llegaron se encuentran que
lograron crear un videojuego el cual era divertido y fácil de utilizar para los
usuarios, siendo esto respaldado por una serie de beta testers que
probaron el juego y dieron respuestas positivas al juego. Esta tesis utiliza
una serie de elementos en común el presente trabajo de investigación,
16
como es el sistema de unidades, clases, tipos de armas, diversidad de
mapas y algunas lógicas de juego que se pueden adaptar para el
funcionamiento del juego a realizar en esta investigación.
2.2. BASES TEÓRICAS
2.2.1. UNITY
2.2.1.1. INTRODUCCIÓN
S
O
D
VA
R
SE
E
R
S
HO
C
E
R esta herramienta ha sido creada por Unity
para diseñarEjuegos,
D
Technologies y que posee más de 1.7 millones de desarrolladores
Tomando como base lo descrito en la tesis de David López,
podemos definir a Unity como una poderosa herramienta de desarrollo
registrados; y algunos de ellos poseen una gran importancia en el campo
de los videojuegos como Microsoft, Ubisoft o Electronic Arts.
Unity está compuesto por dos partes principales, el editor y el
motor:
• Editor integrado de Unity: Permite el diseño y desarrollo de
la aplicación. Además, permite emular la aplicación en
distintas plataformas, de tal manera que pueda verse como
la aplicación se verá y trabajará en la plataforma objetivo; lo
cual permite que el proceso de debuging sea más eficiente.
• Motor Unity (Unity Engine): Incluye las funciones de
renderizado, luces, terrenos, sustancias, físicas (physics),
búsqueda de caminos (path finding), audio, programación y
conexiones.
17
2.2.1.2.
PLATAFORMAS
Unity es una herramienta multi-plataformas (cross platform), lo cual
es una de las características principales de esta herramienta, porque
permite la realización de una aplicación dirigida a varias plataformas, sin
la necesidad de hacer todo el proceso nuevamente. Las plataformas a las
cuales se pueden importar las aplicaciones realizadas son las siguientes
• MAC
O
H
C
E
R
E
Web Player
• Linux
•
D
R
SE
E
R
S
• PC
S
O
D
VA
• IOS
• Android
• Blackberry
• Windows Phone 8
• Sony Play Station 4
• Sony Play Station Vita
• Microsoft Xbox 360
• Microsoft Xbox One
Es necesario resaltar que aunque Unity permite crear juegos para
distintas plataformas, hay que tener en mente a que plataforma se desea
realizar un juego antes de su realización, debido a que partes del código
como la entrada de datos por parte del jugador (ya sea utilizando un
control de Xbox o de Play Station, el mouse y teclado de una
computadora, o la pantalla táctil de un Smart Phone) o posicionamiento
de elementos del UI (User Interface o Interfaz de Usuario), o recursos que
necesitará el juego para ser utilizado correctamente (capacidad del CPU,
18
memoria, etc) varían según las diversas plataformas, así que algunos
ajustes y consideraciones serán necesarias al momento de realizar los
juegos a otras plataformas.
2.2.1.3.
LICENCIAS
Unity posee 2 licencias principales, Unity (gratuita) y Unity Pro
S
O
D
Autilizará la
especiales, pero para propósitos de ésta investigación
se
V
R
SE
licencia gratuita de Unity.
E
R
S
O
H
C
E
R
2.2.1.4.
EDITOR
DE
(paga). La licencia Pro posee mayor funcionabilidad y elementos
El editor integrado es la herramienta que permite el desarrollo y diseño
del juego al permitir acceder a todos las opciones necesarias para las
configuraciones del juego. La primera imagen muestra una escena de un
juego de prueba realizado, enfocando al jugador.
Figura Nº 1: Editor principal
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
19
2.2.1.4.1. VENTANAS
El editor está dividido en 5 sub ventanas importantes, escene
(scene), juego (game), jerarquía (hierarchy), proyecto (proyect) e
inspector. La ventana principal puede ser alterada por los desarrolladores
(cambiar posición de las sub ventanas, sus tamaños, el tipo de sub
S
O
D
VA
ventana que deseen ver, etc) para que muestren únicamente lo que
O
H
C
E
ER
R
SE
E
R
S
deseen observar.
2.2.1.4.1.1. VENTANA DE ESCENA (SCENE WINDOW)
D
Esta ventana representa el ambiente 2D o 3D (según como lo
desee el desarrollador) donde todos los objetos de juego (Game Objects)
se encuentran en una escena en particular. Para navegar a través de la
escena, es posible hacerlo gracias a los 4 botones de la barra de
herramientas o usando sus respectivos atajos:
• Mano (Hand Tool) ‘Tecla Q’: Cuando esto esta seleccionado
es possible hacer click en la Scene Window y arrastrar el
mouse para mover la vsta actual de la escena.
• Mover (Move) ‘Tecla W’: Permite mover los Game Objects
seleccionados y arrastrarlos por la Scene Window.
• Rotar (Rotate) ‘Tecla E’: Permite rotar los Game Objetcs
seleccionados arrastrando el mouse por la Scene Window.
• Escalar (Scale) ‘tecla R’: Cambia la escala de los Game
Objects seleccionados al arrastrar el mouse por la Scene
Window.
La barra de herramientas con los botones para las acciones
explicadas anteriormente es la siguiente:
20
Figura Nº 2: Barra de herramientas de tipo de selección
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
2.2.1.4.1.2. VENTANA DE JUEGO (GAME WINDOW)
La ventana Game Window muestra la aplicación corriendo cuando
S
O
D
A sin la
se puede probar distintas partes del juego durante el V
desarrollo
R
E que se puede probar
Ssino
necesidad de hacer una compilación del
juego,
E
R
S Además, se puede utilizar la
O
partes individuales del juego
directamente.
H
Ca la Game Window para realizar diferentes
E
R
consola integrada
junto
E
D
pruebas y arreglar errores.
la opción “Play Mode” (modo de juego) esta activada. Durante este modo,
En esta imagen se muestra la Game Window y la consola en plena
ejecución de un juego:
21
Figura Nº 3: Game Window en ejecución
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
La barra donde se activa el play mode es la siguiente:
S
O
D
VA
R
SE
E
R
S
HO
C
E
2.2.1.4.1.3.
ER VENTANA DE JERARQUÍA (HIERARCHY
D
Figura Nº 4: Botones para activar el juego
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
WINDOW)
En esta ventana, se muestra un listado de todos los Game Objects
en una escena específica. Los objetos hijos se muestran en un orden
jerárquico de los padres, y los objetos deshabilitados se muestran con
letras de color gris. Esto se puede observar en la siguiente imagen:
Figura Nº 5: Jerarquía de GameObjects en la escena.
22
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
2.2.1.4.1.4. VENTANA
DE
PROYECTO
(PROYECT
WINDOW)
Esta ventana muestra un listado de todos los recursos utilizados en
el proyecto. Todos estos recursos se encuentran en una carpeta llama
S
O
D
A
crear carpetas y algunos objetos haciendo click derecho
y eligiendo la
V
R
S
opción deseada. Todo cambio hecho en
estaEventana se realizará
E
R
S
también el directorio de Unity.
O
H
C se muestra una Proyect Window de prueba:
E
En la siguiente
imagen
R
DE
Assets en el directorio de Unity. Dentro del Proyect Window se pueden
Figura Nº 6: Carpeta assets con todos los props del juego.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
23
2.2.1.4.1.5. VENTANA
DE
INSPECCIÓN
(INSPECTOR
WINDOW).
Toda la información referente a algún Game Object en específico
se muestra en esta ventana, de la cual la información que normalmente
se muestra es la siguiente:
S
O
D
VA
• Un Checkbox que indica si el Game Object está activado o
R
E
S
E
• El nombre del Game Object
R
S
• Un Checkbox
queO
indica si el Game Object es estático o no.
H
C
E
R
• E
El tag del game object seleccionado (por defecto, el objeto
D
no.
es “untagged”).
• La capa del objeto seleccionado (por defecto, el objeto está
en la capa “Default”).
Además de esto, el “inspector” muestra una lista de todos los
componentes adicionales que posea el Game Object, todos estos son los
que le dan la funcionabilidad dentro del juego.
2.2.1.4.2. ESCENAS (SCENES)
Las escenas contienen todos los Game Objects de un nivel del
juego, cada nivel puede tener diferentes ambientes y objetos asociados
dentro de él. Las escenas son útiles porque permiten construir el juego en
diferentes etapas, lo cual es una buena manera de mantener organizado
el juego y así no sobrecargar el juego con elementos que no se estén
utilizando.
2.2.1.4.3. OBJETOS DE JUEGO (GAME OBJECTS)
24
Los Game Objects son contenedores los cuales poseen diferentes
funcionabilidades dentro de ellos. Cada una de estas funcionabilidades es
dada por un componente; por ende un Game Object es un objeto que
tiene componentes que definen el comportamiento del objeto. Cada objeto
que existe en una escena es un Game Object. Ademas de los
componentes, cada Game Object en la escena posee un tag, una capa
(layer), y un nombre asociado, como también posee un indicador si el
objeto es estático o si está habilitado o deshabilitado.
S
O
D
VA
ER
S
E
utilizada para identificar diferentes S
tiposR
de Game Objects.
O
H
C
E
R
E son identificadores asociados a un Game Object que la
Dlayers
Los
Un tag es una palabra clave asociada al Gama Object, la cual es
cámara utilizará para filtrar que objetos va a renderizar.
El atributo estático de un Game Object está relacionado con el
occlusion culling (oclusión selectiva). Un objeto de ser estático otros
objetos detrás de él no serán renderizados porque el jugador no podrá
verlos.
Unity posee algunos Game Objects por defecto con algunos
componentes adjuntados a ellos para ser usados de inmediato por los
desarrolladores. Los tipos de Game Objects más utilizados son las
cámaras, luces, sistemas de partículas, planos (o terrenos) y algunas
figuras geométricas como cubos y esferas.
2.2.1.4.3.1. GAME OBJECTS VACIOS
Este es el tipo más básico de Game Object. Un Game Object no
posee ningún componente adjunto aparte del componente “Transform”, el
cual todos los Game Objects deben de tener. Algunos scripts se le
pueden adjuntar a estos objetos, con estos scripts que contienen código
podrán ser ejecutados independientemente del comportamiento del Game
Object.
25
2.2.1.4.3.2. CÁMARA (CAMERA)
El Game Object cámara captura una porción del mundo 3D (o 2D)
del juego. Esto es lo que usuario verá cuando esté en el juego. Cuando se
selecciona una cámara en la ventana del editor de jerarquía, aparece una
ventana adicional, llamada "Vista previa de la cámara" (Camera Preview),
S
O
D
Ase muestra
ese instante de tiempo. De hecho, en la Game Window, lo
que
V
R
SE
es lo que las cámaras están capturando.
E
R
S
O
H
C importante de los Game Object Camera es el
E
R
El componente
más
DE
mostrando al desarrollador una imagen del mundo que es capturado en
componente llamado “Camera”, este componente es el que le da la
funcionabilidad de cámara como tal. Por medio de este componente es
que es posible definir que atributos son el fondo, definir el campo de
visión de la cámara, cuales capas (layers) serán renderizadas, etc,
No hay un límite definido de cámaras las cuales pueden estar
ubicadas
en
una
escena,
pero
es
necesario
tener
algunas
consideraciones antes de implementar varias cámaras:
• Solo debe de haber un “Audio Listener” por escena. Los
Audio Listeners son un componente que viene por defecto
con cada cámara que es introducida en una escena, actúa
como un micrófono que captura todos los sonidos
producidos en una escena y los reproduce utilizando los
speakers.
Estos componentes deben de ser removidos de las cámaras
adicionales que sean introducidas.
26
• El componente “Camera” posee un atributo llamado
“Normalized view port rect” el cual define cual porción de la
cámara, en unidades normalizadas, en que cámara será
dibujado lo que se está viendo. Es necesario distribuir estos
puertos de rectángulo de manera tal de que no se solapen
las imágenes que se estén mostrando
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
2.2.1.4.3.3. FIGURAS GEOMÉTRICAS
Unity posee unos Game Objects por defecto que son unas
figuras geométricas las cuales pueden ser agregadas en una
escena, como son cilindros, esferas, cubos, cápsulas y planos.
Cada uno de estas figuras posee 3 componentes, un Mesh
Renderer, un Mesh Filter y un Collider.
2.2.1.4.3.4. TEXTO
Los textos son Game Objects que contienen representaciones
gráficas de una cadena de texto. Existen dos tipos de textos: "Texto GUI"
(GUI Text) y "Texto 3D" (3D Text).
El "GUI Text" muestra un texto en la pantalla. Este texto será
siempre perpendicular a la pantalla. Se une al componente "GUIText" que
permite, entre otras opciones, escribir el texto que aparecerá, y permite
seleccionar el tamaño de fuente y el tipo de letra.
27
Por otro lado, "texto 3D" muestra un texto en 3D que puede ser
rotado y escalado. Este objeto tiene dos componentes: "Texto de malla"
(Text Mesh) y "Malla Renderer" (Mesh Renderer). El primero de ellos es el
componente que genera el texto. Este componente define la cadena que
se va a procesar y la fuente que se utilizará. " Mesh Renderer " define el
material de la fuente. Así que un "texto 3D" puede tener transparencia,
puede utilizar una textura en los personajes y otras opciones visuales.
R
SE
E
R
S
HO
C
E
ER LUCES
D2.2.1.4.3.5.
S
O
D
VA
Las luces son Game Objects que iluminan los objetos en la escena.
Existen cuatro tipos de luces: luz direccional (directional light), punto de
luz (point light), luz del punto (spot light) y luz de área (area light) que
requiere licencia Unity Pro; por lo tanto, está fuera del alcance de este
proyecto.
Las directional lights se utilizan comúnmente para iluminar
escenarios al aire libre, porque simula el sol muy bien. Una luz de
dirección es una luz que viene desde el infinito e ilumina toda la escena a
través de un determinado ángulo.
Las Point Lights son un tipo de luz omnidireccional que se genera
en un punto y tiene un radio de acción determinado. Se utilizan para
simular objetos como bombillas.
Las Spot lights son una luz direccional generada en un cierto punto
y el halo de luz es en forma de cono. Permiten, por ejemplo, para simular
un coche frontal de luz o una linterna.
28
2.2.1.4.3.6. SISTEMA DE PARTÍCULAS
Sistema de partículas es un Game Object que genera partículas.
Las partículas son planos (o superficies) con una textura que se muestran
siempre perpendiculares a la pantalla. Un sistema de partículas puede
simular los efectos como una chispa, lluvia, humo, etc. Lo que permite
añadir efectos visuales sorprendentes al juego.
S
O
D
VA
R
SE
E
R
S
HO
C
E
número de partículas
ER y la vida útil de las partículas que se generarán,
D
tamaño, color, el material de la partícula, de forma que el sistema de
El componente "Sistema de partículas" (Particle System) define el
partículas lanzará las partículas (en forma de cono, esfera, forma lineal...)
y la velocidad de movimiento, entre otros. Algunas de estas propiedades
como color y tamaño se pueden cambiar con el tiempo.
2.2.1.4.4.
COMPONENTES
Los componentes definen el comportamiento de los Game Objects,
y están asociados a ellos. Un Game Object puede tener adjuntado más de
un componente, los componentes tienen propiedades que pueden ser
cambiadas programándolas o con el Inspector Window. Cuando
cualquiera de estas propiedades es cambiada, el comportamiento del
Game Object cambia también. Algunos de los componentes más
utilizados son los siguientes:
2.2.1.4.4.1.
TRANSFORM
El componente Transform es uno de los componentes más
importantes en Unity. Este componente es obligatorio en todos los Game
29
Objects, por lo tanto todos los objetos deben tenerlo conectado. Define la
posición, rotación y escala del objeto de juego. Unity utiliza dos tipos de
datos especiales para representar posiciones y rotaciones. Vector 3
representa una posición en el espacio (un punto) definido por tres
coordenadas (X, Y y Z) o una dirección. Por ejemplo, el Vector 3 (0, 0, 1)
es un vector de su dirección es la misma que el eje z. Los cuaternoides
representan la rotación de un objeto tiene, como cuántos grados ha girado
del eje Z, X y Y.
S
O
D
VA
R
SE
E
R
S
HO
C
E
Cuando
EunRcomponente del Cuerpo rígido (Rigid Body) se adjunta
D
a un objeto de juego, el juego objeto seguirá las leyes de la física, por lo
2.2.1.4.4.2.
RIGID BODY
que es sensible a diferentes fuerzas como la gravedad.
Por ejemplo, supongamos que una escena que tiene un plano
situado en origen y un cubo cuya posición inicial es de 1 metro sobre el
plano. Si el objeto juego cubo no tiene un componente “Rigid Body”
conectado, el cubo flotará en 1 m. Por otro lado, si el cubo tiene un "Rigid
Body", la fuerza de gravedad afectará al cubo, haciéndolo caer.
Este componente puede haber activado la opción de "cinemática"
(kinematic). Cuando esta opción está activada, el objeto será un cuerpo
rígido cinemático. Este tipo de Rigid Body no es afectado por cualquier
fuerza como la gravedad o colisiones. Algunos ejemplos de la utilización
de opción cinemática pueden ser los siguientes: un objeto cuya física es
controlada por un script, pero en ciertas situaciones debe seguir las leyes
de la física. Este comportamiento puede lograrse sólo por activar y
desactivar la propiedad cinemática. Otro ejemplo de utilización de
cinemática objeto puede ser un objeto que puede empujar a otros objetos.
30
2.2.1.4.4.3.
MESH FILTER
El componente Filtro de Malla (Mesh Filter) es un componente que
indica al Mesh Renderer cual Malla será renderizada. La Malla deber
estar localizada en algun lugar de la carpeta Assets del directorio de
Unity. Un cubo posee un componente Mesh Filter con una variable para
definir que el objeto será renderizado a un Cube Mesh (Malla de cubo), el
S
O
D
VA
cual es una Malla que gráficamente representa 8 vértices y 6 caras de un
R
SE
E
R
S
cubo.
HO
C
E
El componente
ER Renderizador de Malla (Mesh Renderer) es el
D
componente que toma la Malla del Mesh Fliter y la renderiza en la escena.
2.2.1.4.4.4.
MESH RENDERER
Este componente también indica si el objeto proyectará sombra cuando
una luz se proyecte sobre él.
2.2.1.4.4.5.
SCRIPTS
Este componente asocia un guión (Script) existente con un objeto
de juego. Un script es una pieza de código que proporciona cierto
comportamiento con el Game Object. Este código puede escribirse en los
lenguajes JavaScript, C# o Boo, y pueden utilizarse diferentes scripts
escritos en idiomas diferentes para el mismo objeto.
Es obligatorio que cada script adjunto a un objeto de juego
extienda la clase MonoBehaviour. Esta clase proporciona algunos
métodos especiales de Unity como Start y Update. Se llama Start cuando
el GameObject se crea en la escena y Update se llama en cada frame
durante la ejecución del juego.
31
Unity utiliza Mono framework como su framework
para los
comandos a realizar. Mono framework está definido por el equipo de
Mono como “Una implementación en software libre, multiplataforma de C#
y el CLR que es binariamente compatible con Microsoft.Net” Esta es una
característica muy interesante porque este framework está integrado en
Unity para que los desarrolladores puedan usar casi todas las clases de
extensiones tipo “.NET” en sus proyectos.
S
O
D
VA
R
SE
E
R
S
HO
C
E
Una Malla
ER(mesh) es un objeto 3D formado por triángulos que
D
tienen un material asociados a ellos. Un material define cual textura y cual
2.2.1.4.4.6.
MESHES
color es utilizado para renderizar.
Es importante notar que Unity no posee ninguna herramienta para
crear Mallas. Para lograr usarlos en una escena, las Mallas deben ser
creadas en aplicaciones destinadas al modelado de figuras 3D y luego
importarlas a Unity.
2.2.1.4.5. PREFABS
Los prefabricados (prefabs) son Game Objects especiales que
pueden ser reutilizados a lo largo de la aplicación, en distintas escenas.
Los prefabs pueden instanciarse para crear nuevos Game Objects en la
escena dinámicamente. Toda las instanciadas prefabricadas serán
exactamente los mismos objetos de juegos en el momento de la creación,
pero es posible modificar las características de cada uno a la vez. Así que
es posible obtener dos objetos de juegos diferentes que provienen del
mismo objeto prefabricado.
32
2.2.2. PHOTON SERVER
Photón Unity Network (PUN) es una solución alternativa de redes
para Unity, que tiene como objetivo fijar y extender la red incorporada de
Unity para el desarrollo de juegos en línea. Se hace uso de Photon que
llega a ser más fácil de usar que nunca. El código fuente completo está
disponible, así que puede este plugin se puede escalar para soportar
cualquier tipo de juego multijugador.
S
O
D
VA
R
SE
E
R
S
HO
C
E
estas funciones
ERde Unity deberán de sentirse como en casa. Un
D
convertidor automático ayudará a un proyecto red Unity a pasarse a un
La PhotonNetwork API se ve muy similar a solución de red
implementada originalmente en Unity, y los usuarios que han utilizado
puerto de Photon equivalente sin problemas. Los usuarios que no tienen
experiencia previa con redes usando Unity tendrán una experiencia fácil
a partir de usar photon.
De forma predeterminada, este plugin hace uso del servicio alojado
de "Exit Games Cloud", que corre Photon por ti. Y utilizando una ventana
de configuración, es posible registrarse (gratuitamente) en menos de un
minuto.
2.2.2.1.
CARACTERÍSTICAS PRINCIPALES
• API muy fácil de utilizar.
• Servidor disponible como servicio alojado (actualmente
gratuito).
• Parcialmente automática conversión de la red de Unity a
Photon Networking.
• El modo offline: permite volver a utilizar el código
multijugador en modos de juego singleplayer.
33
• Funcionamiento excepcional del Photón Servidor
• Carga equilibrada escalas de flujo de trabajo a través de
servidores (sin ningún esfuerzo extra).
• No P2P directo y no NAT necesarios.
2.2.2.2.
EXIT GAMES CLOUD
S
O
D
VA
R
E
S
E
El servicio de Exit Games Cloud
provee instancias de Photon
R
S
O por Exit Games, cuyo servicios
“hosteadas” y balanceadas
Hcontroladas
C
E
son gratuitos
DEparaRpruebas y para uso comercial su costo se acerca al de
otras páginas de host.
En el servicio, no se puede implementar una lógica de servidor
propia, en cambio, se hacen clientes autoritativos. Las aplicaciones están
separadas por un "Application ID" y la "Game Version" del cliente. Con
ello, los jugadores no chocaran con los otros desarrolladores o versiones
anteriores del juego.
Cuando se han importado los scripts del editor desde el Paquete
de Photon para red de Unity, se abrirá automáticamente una ventana de
configuración, en la cual se introduce la dirección de correo electrónico y
registro para la nube.
2.2.2.3.
Photon SERVER SDK
Como alternativa a para el servicio de alojamiento de Photon,
puede ejecutar su propio servidor y desarrollar encima de la lógica del
juego "Load Balancing". Esto da control total sobre la lógica del servidor.
34
Si se utiliza un Photon server propio, se debe de utilizar el asistente
de configuración para cambiar la configuración para él. Abrir en el Menú:
Ventana, Photon Unity Networking.
2.2.3. GRID FRAMEWORK
S
O
D
A
Grid Framework es una potente, pero fácil de usar
solución para
V
R
E
Sgrid. Ofreciendo nuevas
todas las necesidades que requeríanR
deE
un
Ses aplicar el componente de grid que
O
clases, todo lo que necesitas
hacer
H
EC
se desee enE
unR
game object, se establecen los valores al gusto del
D
usuario, y de esta manera se puede empezar a escribir la lógica del juego
sin preocuparse por las matemáticas subyacentes. No importa si se está
haciendo un juego de mesa, un juego de estrategia, un juego de puzzle,
un juego de estilo arcade o cualquier otro tipo de juego que necesita
precisión mecánica, el Grid Framework ayudará a configurar un juego y
escribir la lógica del juego de forma intuitiva.
La forma más simple de describir Gris framework sería llamarlo una
librería, que proporciona, con nuevas clases y nuevos componentes
completan con los inspectors, los cuales están listos para usar. También
sirve como una extensión de editor al proporcionarle un panel Alinear, lo
que le permite a la derecha de auto-snap objetos en el editor. Puede
establecer las propiedades de los nuevos componentes de la red en el
editor y utilizarlos en secuencias de comandos, al igual que cualquier otro
componente de la unidad.
35
2.2.4. UNITY UI 4.6
A partir de la salida de la versión 4.6 de Unity, se introdujo una
nueva forma de crear interfaces de usuario, además de poder crear las
interfaces a partir de código, ahora se pueden crear en el editor de Unity
de manera visual, cambiando su apariencia, animaciones, interacciones y
formas de aplicar dichas interfaces, siendo todas estas modificaciones en
S
O
D
A con
de creación de interfaces de usuario y permitiendo mayor
interacción
V
R
SE
el jugador.
E
R
S
O
H
C
E
R
2.2.4.1.
CARACTERÍSTICAS
DE
su mayor parte de manera visual. De ésta manera, acelerando el proceso
•
Integración completa con el “inspector”
•
No hace falta darle Play para ver los resultados
•
Lo que se ve en la Scene View es lo que se ve en la Game
View
•
Naturaleza modular basada en componentes: Permite fijar
comportamientos que se deseen a los widgets que se creen y
pueden hacer lo que el desarrollador desee sin necesidad de
mucho código.
•
Soporte completo para iOS/Android, Blackberry, Win8, WP8,
Flash
•
Posee un flexible sistema de eventos
•
Permite hacer complejos UIs que toman solamente 1 llamada
para dibujar.
•
Permite crear tus Atlas en el editor, deja actualizar y modificar
en cualquier momento, o importar un atlas del Texture Packer.
36
•
Soporte para diferentes tipos de iluminación.
•
Soporte para recortar los paneles con bordes duros o blandos,
dando así diferentes efectos a cada botón y menú que se cree.
•
Soporte para una mesa de tamaño flexible, permitiendo que los
widgets creados puedan automáticamente empujar a otros
fuera del camino para evitar que se solapen unos con otros.
S
O
D
VA
R
•
Soporte para idiomas orientales con IME Input.
•
Sistema de localización integrado.
•
•
O
H
C
E
ER
D
mouse y teclado.
SE
E
R
S
Soporte integrado para controles especiales (Xbox, PS) y
Gran cantidad de scripts integrados que permiten de cambiar el
color de un botón hasta arrastrar un objeto por la pantalla.
•
Sistema simple interpolación incorporada.
•
Limpio, corto, simple y ampliamente optimizado código C#.
•
No requiere recursos externos ni DLLs.
2.2.5. POSTGRE SQL
Según Regina Obe y Leo Hsu en su libro PostgreSQL: Up and
Running, definen PostgreSQL como un sistema de gestión de base de
datos relacional de código abierto que comenzó como un proyecto de
Berkeley, en la Universidad de California. Estaba originalmente bajo la
licencia BSD, pero ahora se llama PostgreSQL. Para todos los propósitos
y efectos, es con licencia BSD. Posee una larga historia, que casi se
remonta al principio de bases de datos relacionales. Este manejador de
base de datos tiene características de clase empresarial como funciones
SQL con ventanas, la capacidad de crear funciones de agregado y
37
también utiliza ventanas construct, tablas de expresiones comunes, tablas
de expresiones comunes recursivas, y esquemas de replicación.
De acuerdo con las investigaciones realizadas y teniendo como
base lo dicho por Korry Douglas y Susan Douglas, llegamos a definir a
PostgreSQL como un manejador de base de datos relacional de software
libre cliente/servidor. PostgreSQL ofrece una combinación única de
S
O
D
A todas las
comerciales como Sybase, Oracle y DB2. PostgreSQLV
ofrece
R
SE
características habituales de una baseR
de E
datos
relacional además unas
S
características únicas. PostgreSQL
HO ofrece herencia (para lectores de
C
E
orientada a objetos).
ER Con PostgreSQL, se puede agregar nuevos tipos de
D
datos fundamentales. PostgreSQL incluye soporte para tipos de datos
características que comparan a las principales bases de datos
geométricos tales como punto, segmento de línea, caja, polígono y el
círculo.
PostgreSQL utiliza estructuras indexación que hacen rápidamente
los tipos de datos geométricos. PostgreSQL fue construido alrededor de
una arquitectura cliente/servidor. Se puede construir aplicaciones para
cliente en varios lenguajes diferentes, incluyendo C#, C++, Java, Python,
Perl, entre otros. Del lado del servidor, PostgreSQL posee un poderoso
lenguaje procesal, PL/pgSQL.
2.2.6. ANGULAR JS
Según Adam Freeman en su libro Pro AngularJS, Angular es un
framework de JavaScript de código abierto, mantenido por Google, que
ayuda con la gestión de lo que se conoce como aplicaciones de una sola
página. Su objetivo es aumentar las aplicaciones basadas en navegador
con capacidad de Modelo Vista Controlador (MVC), en un esfuerzo para
hacer que el desarrollo y las pruebas sean más fáciles. La biblioteca lee el
38
HTML que contiene atributos de las etiquetas personalizadas adicionales,
entonces obedece a las directivas de los atributos personalizados, y une
las piezas de entrada o salida de la página a un modelo representado por
las variables estándar de JavaScript. Los valores de las variables de
JavaScript se pueden configurar manualmente, o recuperados de los
recursos JSON estáticas o dinámicas
S
O
D
A como un
dicho por Shyam Seshadri y Brad Green, definimos a AngularJS
V
R
SEde JavaScript para la
framework de tipo MVC (Model View R
Controller)
E
S
O
Web. AngularJS hace tanto
por nosotros que sólo tenemos que
H
C
E
R
enfocarnos en
nuestra
E aplicación principal y que AngularJS se ocupe de
D
todo lo demás.
A partir de nuestra investigación basándonos principalmente en lo
Angular permite aplicar prácticas de ingeniería de software
estándar, prácticas “tried-and-tested” tradicionalmente utilizadas del lado
del servidor en la programación del lado del cliente para acelerar el
desarrollo del frontend. Proporciona una estructura consistente y
escalable que hace más fácil desarrollar aplicaciones grandes y
complejas como parte de un equipo.
El concepto central detrás del marco AngularJS es el patrón de
arquitectura MVC. El patrón Model-View-Controller (o MVVM, acrónimo de
modelo-View-ViewModel, que es bastante similar) evolucionó como una
manera de separar las preocupaciones y las unidades lógicas en el
desarrollo de grandes aplicaciones. Da un punto de partida para decidir
dónde y cómo los desarrolladores para dividir las responsabilidades. El
patrón de arquitectura MVC divide una aplicación en tres partes
diferenciadas, modulares:
39
• El modelo es la fuerza impulsora de la aplicación. Esto es
generalmente
los
datos
detrás
de
la
aplicación,
generalmente traído desde el servidor. Cualquier interfaz de
usuario con los datos que el usuario ve se deriva del
modelo, o un subconjunto del modelo.
• El punto de vista es que ve el usuario interactúa con la
S
O
D
A
V
El controlador es la lógica y presentación
capa de negocio,
R
E y toma decisiones
Sdatos
E
las acciones que interpreta
como
R
S
O
como la manera
de
presentar el modelo, qué partes debe
H
C
E
R etc.
E
mostrar,
interfaz de usuario. Es dinámico y generado basado en el
modelo actual de la aplicación.
•
D
2.3. LENGUAJES DE PROGRAMACIÓN A UTILIZAR
2.3.1. C#
Según J. Ferguson, B. Patterson y J. Beres en su libro la biblia de
C#
definen
C#
como
un lenguaje
de
programación orientado
a
objetos desarrollado por el danés Anders Hejlsberg que diseño también
los lenguajes Turbo Pascal y Delphi, fue estandarizado por Microsoft
como parte de su plataforma.NET, su sintaxis básica deriva de C/C++ y
utiliza el modelo de objetos de la plataforma.NET el cual es similar al de
Java aunque incluye mejoras derivadas de otros lenguajes (entre ellos
Delphi). Aunque C# forma parte de la plataforma .NET, ésta es una API,
mientras que C# es un lenguaje de programación independiente diseñado
para generar programas sobre dicha plataforma. Ya existe un compilador
implementado que provee el marco Mono - DotGNU, el cual genera
programas para distintas plataformas como Windows, Unix, Android, iOS,
Windows Phone, Mac OS y GNU/Linux.
40
2.3.2. JAVASCRIPT
Según David Flanagan en su libro JavaScript: The Definitive Guide,
en su sexta edición, JavaScript es un lenguaje interpretado orientado a las
páginas web, con una sintaxis semejante a la del lenguaje Java, el
lenguaje fue inventado por Brendan Eich en la empresa Netscape
Communications, que es la que fabricó los primeros navegadores de
S
O
D
y operaciones en el marco de la aplicación cliente. TodosV
losA
navegadores
R
E
S en las páginas web.
modernos interpretan el código JavaScript
integrado
E
R
S
O
Para interactuar con una página
web se provee al lenguaje JavaScript de
H
CDocument Object Model (DOM).
E
R
una implementación
del
DE
Internet comerciales, se utiliza en páginas web HTML, para realizar tareas
2.3.3. PHP
Según Peter B. MacIntyre en su libro PHP: The Good Parts, PHP
es un lenguaje de programación de uso general de código del lado del
servidor originalmente diseñado para el desarrollo web de contenido
dinámico. Fue uno de los primeros lenguajes de programación del lado
del servidor que se podían incorporar directamente en el documento
HTML en lugar de llamar a un archivo externo que procese los datos, el
código es interpretado por un servidor web con un módulo de procesador
de PHP que genera la página Web resultante, se considera uno de los
lenguajes más flexibles, potentes y de alto rendimiento conocidos hasta el
día de hoy. Lo que ha atraído el interés de múltiples sitios con gran
demanda de tráfico como Facebook, para optar por PHP como tecnología
de servidor.
Fue
creado
originalmente
por
Rasmus
Lerdorf
en
1995.
Actualmente el lenguaje sigue siendo desarrollado con nuevas funciones
por el grupo PHP, este lenguaje forma parte del software libre publicado
41
bajo la licencia PHP, que es incompatible con la Licencia Pública General
de GNU debido a las restricciones del uso del término PHP.
2.3.4. SQL
Según Carme Martín Escofet en su libro El lenguaje SQL, el SQL
S
O
D
A
bases de datos relacionales. Es un lenguaje declarativo:
sólo hay que
V
R
E
indicar qué se quiere hacer. En cambio,R
enE
losS
lenguajes procedimentales
S
es necesario especificar cómo
HOhay que hacer cualquier acción sobre la
C
E
base de datos.
DEElRSQL es un lenguaje muy parecido al lenguaje natural;
es el lenguaje estándar ANSI/ISO de definición, manipulación y control de
concretamente, se parece al inglés, y es muy expresivo. Por estas
razones, y como lenguaje estándar, el SQL es un lenguaje con el que se
puede acceder a todos los sistemas relacionales comerciales.
2.4. VIDEOJUEGOS Y SUS ELEMENTOS
2.4.1. VIDEOJUEGO
Según la definición de Frassca, se puede definir un videojuego
como “Cualquier forma de software de entretenimiento por computadora,
usando cualquier plataforma electrónica y la participación de uno o varios
jugadores en un entorno físico o de red.”
Por otro lado, según Johan Huizinga, “un videojuego una actividad
frente a la vida "normal" como algo "no serio", pero al mismo tiempo
absorbe el jugador total e intensamente. Es una actividad conectada con
ningún interés material, y ningún beneficio puede ser adquirido por él.
Procede dentro de sus propios límites apropiados del tiempo y del espacio
según reglas fijas y de una manera ordenada. Promueve la formación de
42
agrupaciones sociales que tienden a rodearse de secretismo y a subrayar
su diferencia con el mundo común por disfraz u otros medios”.
Además, se tiene la definición de Jesper Juule, la cual
consideramos una de la más acertadas, la cual escribe los requerimientos
que para un videojuego pueda considerarse uno como tal, las cuales son
las siguientes:
S
O
D
A que ser
tienen
V
R
SE
E
R
S
1. Reglas definidas: Las reglas de juego
HO
C
E
discutir
ERsobre ellos cada vez que juegas
D
2. Requiere de esfuerzo por parte del jugador: es otra manera de
suficientemente bien definidos que puede ser programados en
un ordenador o suficientemente bien definidos que no tienes a
afirmar que los juegos son difíciles, o que los juegos contienen
un conflicto, o son "interactivos". Es una parte de las reglas de
la mayoría de juegos (juegos de azar) pueden influir en las
acciones de los jugadores el juego estado y resultado del juego.
La inversión de esfuerzo del jugador tiende a conducir a un
resultado, puesto que la inversión de energía en el juego hace
que el jugador sea (en parte) responsable del resultado.
3. Posee consecuencias negociables: En general, esto quiere
decir que cada acción debe producir de alguna manera una
consecuencia, ya sea tan pequeña como poner un objeto en el
inventario o tan grande destruir a un oponente y ganar una
partida.
4. Cantidad variada de acciones: Esta condición indica que las
acciones que puede tomar el jugador son variadas y no
limitadas a una simple acción, como por ejemplo en Ajedrez, en
el cual puedes mover diferentes piezas y cada tipo de pieza
posee un tipo de movimiento distintito de movimiento.
43
5. Resultados variados: En este caso, se refiere a que en un juego
tienen que haber diversos finales o formas de terminar el juego,
puede ser limitado a ganar o perder una partida; o puede ser
tan extenso como tener diversos finales a la historia de un
juego.
6. Los resultados afectan tu motivación: Esta última está
relacionada con la condición anterior, esta condición intenta
S
O
D
A
de afectar de alguna manera al jugador, ya sea
con alegría o
V
R
E
derrota al vencer o ser vencido
porS
un oponente, o algo más
E
R
S
O por el final de la historia de un
complejo como ser
Hconmovido
C
E
juego.
ER
D
explicar que todos los resultados del juego, deben de ser capaz
2.4.2. GÉNEROS DE VIDEOJUEGOS
Según Simone Belli y Christian López, el género de videojuego
designa un conjunto de juegos que poseen una serie de elementos
comunes. A lo largo de la historia de los videojuegos aquellos elementos
que han compartido varios juegos han servido para clasificar como un
género a aquellos que les han seguido, de la misma manera que ha
pasado con la música o el cine.
Los videojuegos se pueden clasificar como un género u otro
dependiendo de su representación gráfica, el tipo de interacción entre el
jugador y la máquina, la ambientación y su sistema de juego, siendo este
último el criterio más habitual a tener en cuenta.
Entre los diversos géneros de videojuegos se encuentran: Beat
them Up, Pelea, juegos de acción en primera persona, acción en tercera
persona, infiltración o Sneak, plataformas, simulación de combate,
arcade, deportes, carreras, agilidad mental, educación, aventura,
44
musicales, party games (juegos de fiesta), juegos On-Line, juegos de
estrategia en tiempo real (RTS Real Time Strategy) y finalmente juegos de
estrategia por turnos (TBS Turn Based Strategy).
2.4.3. SPRITES
S
O
D
A
canalización
de
V
Los sprites son mapas de bits en 2D que se dibujan directamente
la
R
E
transformaciones, iluminación o efectos.
Se S
suelen usar para mostrar
E
R
S
información como las barras
HdeOestado, el número de vidas o texto como
C
E
las puntuaciones.
ERAlgunos juegos, sobre todo los más antiguos, están
D
compuestos en su totalidad de sprites. Los sprites pueden ser estáticos o
en
un
destino
de
representación
sin
usar
dinámicos. Al hablar de sprite estático, nos referimos a un objeto que no
cambiará su posición durante el videojuego, por ejemplo la imagen de una
llama, piedra, etc. En cambio un sprite dinámico, es aquel que tendrá
algún tipo de movimiento, el cual puede ser realizado por el usuario o por
el computador, por ejemplo el sprite de un jugador o de los enemigos.
Representar un sprite en memoria puede ser realizado de
muchísimas formas, y puede depender mucho del gusto del programador
y su experiencia. Normalmente se almacenan sus atributos en una
estructura o clase.
2.4.4. TEXTURAS
Una textura es una imagen del tipo bitmap utilizada para cubrir la
superficie de un objeto virtual, ya sea tridimensional o bidimensional, con
un programa de gráficos especial. En profundidad, una textura es un
conjunto de primitivas o elementos denominados "texels" que se asimilan
a un conjunto contiguo de elementos (pixels en 2D) con alguna propiedad
45
tonal o regional. También existe la textura artística. Por textura se
entiende la estructura de la capa superficial de un material. La textura,
junto con el tono y la forma, transforman los motivos planos en imágenes
con fuerte sensación tridimensional.
2.4.5. SOUNDTRACKS
El soundtrack o banda sonora es la parte de sonido completa y el
S
O
D
A series
sonidos y música de un videojuego u obras como V
películas
R
SseEentiende como banda
animadas, etc, desde un punto de vistaR
musical,
E
S
O
sonora aquella música H
tanto
vocal como instrumental compuesta
C con la función de potenciar aquellas
E
R
expresamente
para
cumplir
E
D
emociones que las imágenes por sí solas no son capaces de expresar.
resultado de la edición de diferentes pistas de sonido, ya sean diálogos,
2.4.6. HISTORIA
La historia de un video juego es la forma en que se desenvolverán
los personajes del juego y la historia del mundo representado y como
avanza. Dependiendo del video juego se determina si posee historia o no.
2.4.7. UI
La UI (User Interface o Interfaz de Usuario) viene a ser aquella
manera en la cual el juego puede mostrar información relevante del juego
de manera visual sin que afecte el juego en si siendo estos algunas cosas
como estado del jugador (como salud, habilidades, dinero etc), un
minimapa mostrando la ubicación de lugares o personajes dentro del
juego, los menús del jugador (inventario, mapa, etc), entre otras cosas.
46
2.4.8. JUGABILIDAD
La jugabilidad se define como "el conjunto de propiedades
que describen la experiencia del jugador ante un sistema de juego
determinado, cuyo principal objetivo es divertir y entretener de
forma satisfactoria y creíble ya sea solo o en compañía de otros
jugadores, la definición de jugabilidad se asienta en el concepto de
S
O
D
A con
jugadores alcanzan metas específicas del V
videojuego
R
SE y especialmente
efectividad, eficiencia, flexibilidad
seguridad
E
R
S
O
satisfacción en un contexto
jugable de uso".
H
C
E
DER
Calidad en Uso. La Jugabilidad representa "el grado en el que
La jugabilidad poseen los siguientes atributos:
•
Satisfacción: Agrado o complacencia del jugador ante el
videojuego completo o en algunos aspectos concretos de éste,
como mecánicas, gráficos, sistema interactivo, historia, etc. La
satisfacción es un atributo con un alto grado de subjetividad, no
sólo por lo difícil de medir, sino porque también influyen
bastante los gustos y preferencias del jugador. Además, este
atributo puede verse afectado, por ejemplo, por el género o tipo
de juego (plataformas, aventura RPG, Sandbox, etc.), el
aspecto estético, la historia o simplemente la atracción o
cercanía de la temática o estilo del juego sobre el jugador.
•
Aprendizaje: Facilidad para comprender y dominar el sistema y
la mecánica del videojuego, es decir, los conceptos definidos en
el Gameplay/Game Mechanic del juego: objetivos, reglas y
formas de interaccionar con el videojuego. El aprendizaje
muestra la capacidad del videojuego en presentar y transmitir el
47
sistema y la mecánica del juego al jugador y que éste,
fácilmente
pueda
llegar
a
comprenderlos,
asimilarlos
y
dominarlos para poder interactuar de la manera más correcta y
precisa posible con el videojuego.
•
Efectividad: Tiempo y
recursos
necesarios
para
ofrecer
diversión al jugador mientras éste logra los objetivos propuestos
S
O
D
A
del juego muestra el grado de utilización de los
recursos para
V
R
E
Sy hacer que se divierta, es
poder envolver al jugador en R
el juego
E
Scumplir con sus objetivos: divertir y
O
decir, que el juego
pueda
H
C jugador que lo juega.
E
R
entretener
a
todo
DE
en el videojuego y alcanza la meta final de éste. La efectividad
•
Inmersión: Capacidad para creerse lo que se juega e
integrarse en el mundo virtual mostrado en el juego. La
inmersión es la característica del juego relacionada con
provocar que el jugador se vea envuelto en el mundo virtual,
volviéndose parte de éste e interactuando con él. En ese
momento el jugador se hace cómplice de la mentira del mundo
virtual, haciéndola verdad y produciéndose una inversión de
creencia, la cual provoca que el jugador, aunque sepa que a lo
que juega es falso, lo tome como algo real y se implique en ello
con todas sus habilidades para superar el reto propuesto,
estando concentrado o envuelto en la tarea propuesta por el
videojuego.
•
Motivación: Característica del videojuego que mueve a la
persona a realizar determinadas acciones y persistir en ellas
para su culminación. Para conseguir una buena motivación, el
juego debe disponer de un conjunto de mecanismos que
48
generen una perseverancia en la acción por parte del jugador
para superar los retos del juego, es decir, se introducen factores
que aseguren el mantenimiento de un comportamiento en la
apreciación del proceso de juego.
•
Emoción: Impulso involuntario originado como respuesta a los
estímulos del videojuego que induce sentimientos y que
S
O
D
VA
desencadena conductas de reacción automática.
•
R
SE
E
R
S
HO
C
E
y distintos
ER sentimientos y emociones por parte del jugador para
D
modificar su actitud y comportamiento cuando juega: alegría,
Los juegos generan distintos estímulos durante la dinámica del
juego para desencadenar reacciones involuntarias automáticas
presión, frustración, miedo, intriga, curiosidad, para construir un
universo virtual capaz de conmover, emocionar, hacer sonreír o
llorar al jugador si es necesario.
•
Socialización: Atributos y elementos del juego que fomentan el
factor social o la experiencia en grupo, lo cual provoca apreciar
el videojuego de distinta manera, gracias a las relaciones que
se entablan con otros jugadores o con otros personajes del
juego y que complementan las acciones a realizar y los retos a
resolver en la dinámica del videojuego. La socialización de un
juego permite a un jugador tener una experiencia de juego
totalmente distinta cuando juega un juego sólo o en compañía
de otros jugadores y fomenta nuevas relaciones sociales
interactuando con ellos, ya sea de manera competitiva,
colaborativa o cooperativa.
49
2.5. UML
El Lenguaje Unificado de Modelado (UML) es un lenguaje gráfico
para visualizar, especificar, construir y documentar un sistema. UML
ofrece un estándar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos de negocio,
funciones del sistema, y aspectos concretos como expresiones de
S
O
D
VA
lenguajes de programación, esquemas de bases de datos y compuestos
reciclados.
R
SE
E
R
S
HO
C
E
para especificar
ERo para describir métodos o procesos. Se utiliza para
D
definir un sistema, para detallar los artefactos en el sistema y para
Es importante remarcar que UML es un "lenguaje de modelado"
documentar y construir. En otras palabras, es el lenguaje en el que está
descrito el modelo.
2.5.1. DIAGRAMA ENTIDAD RELACIÓN (DER)
Un DER es una herramienta de modelado de sistemas, que se
concentra en los datos almacenados en el sistema y las relaciones entre
éstos. Un diagrama de entidad-relación o DER es un modelo de red que
describe la distribución de los datos almacenados en un sistema de forma
abstracta. Regularmente se establecen diferencias entre el diagrama
entidad-relación y el modelo entidad-relación, donde el modelo entidadrelación vendría a ser el "lenguaje" utilizado para crear diagramas de
entidad-relación. Más información en modelo de entidad-relación.
Componentes de un DER:
•
Tipos de objetos o entidades.
•
Relaciones: conectan los objetos o entidades.
2.5.2. DIAGRAMA DE CLASES
50
Un diagrama de clases es un tipo de diagrama estático que describe la
estructura de un sistema mostrando sus clases, orientados a objetos, un
diagrama de clases muestra un conjunto de clases, interfaces, y
colaboraciones y sus relaciones. Gráficamente un diagrama de clase es
una colección de vértices y arcos.
Contenido de un Diagrama de Clases:
•
Clases
•
Interfaces
•
D Generalización
•
R
SE
E
R
S
O
H
C
E
R
Dependencia
E
Colaboraciones
S
O
D
VA
•
•
Relaciones de asociación
2.5.3. DIAGRAMA DE CASOS DE USO
Los diagramas de casos de uso documentan el comportamiento de
un sistema desde el punto de vista del usuario. Por lo tanto los casos de
uso determinan los requisitos funcionales del sistema, es decir,
representan las funciones que un sistema puede ejecutar, su ventaja
principal es la facilidad para interpretarlos, lo que hace que sean
especialmente útiles en la comunicación con el cliente.
Los diagramas de casos de uso poseen los siguientes elementos:
Actores: Los actores representan un tipo de usuario del sistema.
Se entiende como usuario cualquier cosa externa que interactúa con el
sistema. No tiene por qué ser un ser humano, puede ser otro sistema
informático o unidades organizativas o empresas.
51
Caso de uso: Es una tarea que debe poder llevarse a cabo con el
apoyo del sistema que se está desarrollando. Se representan mediante un
óvalo. Cada caso de uso debe detallarse, habitualmente mediante una
descripción textual.
Asociaciones: Hay una asociación entre un actor y un caso de uso
si el actor interactúa con el sistema para llevar a cabo el caso de uso
S
O
D
Escenario: es una interacción entre el sistema yV
losA
actores, que
R
E
puede ser descrito mediante una secuencia
deS
mensajes. Un caso de uso
E
R
S
O
es una generalización de un
Hescenario.
C
E
DER
2.5.4. DIAGRAMA DE COMPONENTES
Un Diagrama de Componente es, como su nombre lo indica, un
esquema o diagrama que muestra las interacciones y relaciones de los
componentes de un modelo. Entendiéndose como componente a una
clase de uso específico, que puede ser implementada desde un entorno
de desarrollo, ya sea de código binario, fuente o ejecutable; dichos
componentes poseen tipo, que indican si pueden ser útiles en tiempo de
compilación, enlace y ejecución.
Este tipo de diagrama se representa mediante componentes unidos
mediante relaciones de dependencia, en los diagramas de componentes
se muestran los elementos de diseño de un sistema de software. Un
diagrama de componentes permite visualizar con más facilidad la
estructura general del sistema y el comportamiento del servicio que estos
componentes proporcionan y utilizan a través de las interfaces. Se puede
52
usar un diagrama de componentes para describir un diseño que se
implemente en cualquier lenguaje o estilo. Solo es necesario identificar los
elementos del diseño que interactúan con otros elementos a través de un
conjunto restringido de entradas y salidas. Los componentes pueden
tener cualquier escala y pueden estar interconectados de cualquier
manera.
2.6. PRUEBAS DE SOFTWARE
S
O
D
VA
R
SE
E
R
S
HO
C
E
Las pruebas
ERde estrés son las pruebas que se realizan, desde una
D
perspectiva, para determinar lo rápido que realiza una tarea un sistema en
2.6.1. PRUEBA DE ESTRÉS
condiciones particulares de trabajo. También puede servir para validar y
verificar otros atributos de la calidad del sistema, tales como
la escalabilidad, fiabilidad y uso de los recursos, esta prueba se utiliza
normalmente para romper la aplicación, se va doblando el número de
usuarios que se agregan a la aplicación y se ejecuta una prueba de carga
hasta que se rompe. Este tipo de prueba se realiza para determinar la
solidez de la aplicación en los momentos de carga extrema y ayuda a los
administradores para determinar si la aplicación rendirá lo suficiente en
caso de que la carga real supere a la carga esperada.
2.6.2. BETA TESTING
Prueba de un producto o servicio prácticamente acabada; se
distribuye fuera de la empresa u organización para que la puedan probar
y detectar posibles fallos que, de este modo, pueden depurarse antes de
lanzar el producto y/o servicio al mercado. Cuando una versión beta llega
a estar disponible para el público en general, a menudo es extensamente
probada por los tecnológicamente expertos o familiarizados con versiones
53
anteriores, como si el producto estuviera acabado. Generalmente los
desarrolladores de las versiones betas del software gratuito o de código
abierto los lanzan al público en general, mientras que las versiones betas
propietarias van a un grupo relativamente pequeño de probadores.
2.7. Tabla de variables
VARIABLES
SE
E
R
S
-Sounds Effects
INDICADORES
-Desarrollo de la
-Modelos Estadísticos
DIMENSIONES
Técnicos
Mecánica del juego -Mecánica del Juego
-Servidor Web
O
H
C
E
ER
D
R
-Requerimientos
Funcionales
- Motor gráfico de
desarrollo
-Socket Server
-PostgreSQL
- Plugin
- JSFramework
-Modelo de datos
-Modelado de
Datos
-Codificación
-Prueba
-Elementos
Multimedia
Juego de
S
O
D
VA
Operativos
-Conexión a
Internet
-Browser
-Unity Web
Plugin
-Diagrama ER
-Diagrama de Clases
-Diagrama de Casos
de Uso
-Diagrama de
Componentes
-C#
-UnityEngine
-Photon Server
-TBTK
-NGUI
-JavaScript
-AngularJs
-PHP
-SQL
-Pruebas de Estrés
-Beta Testing
-Sprites
-SoundTrack
-MonoDevelop
-SublimeText3
-PgAdminIII
-Pruebas de
Funcionalidad
54
CAPITULO III
MARCO METODOLÓGICO
3.1 TIPO DE INVESTIGACIÓN
S
O
D
VA
R
En la presente investigación se utilizó un tipo de investigación
proyectiva.
SE
E
R
S
O
H
C
E
ER
D
Según Hurtado (2000), “consiste en la elaboración de una
propuesta o de un modelo, como solución a un problema o necesidad de
tipo práctico, ya sea de un grupo social, o de una institución, en un área
particular del conocimiento, a partir de un diagnóstico preciso de las
necesidades del momento, los procesos explicativos o generadores
involucrados y las tendencias futuras”. (p.325)
De
acuerdo
con
lo
expuesto
anteriormente,
la
presente
investigación es de tipo proyectiva debido a que tiene como finalidad el
desarrollo de un juego de estrategia por turnos con capacidad
multijugador utilizando el motor gráfico Unity.
3.2 DISEÑO DE INVESTIGACIÓN
Algunos autores hacen mención a aspectos metodológicos para
referirse al concepto de diseño y otros incluyen, además de estos asuntos
de
la
elaboración
del
marco
teórico
y sus
actividades,
aspectos administrativos de la investigación.
Tal es el caso de Ander Egg (2006) quien, además de
metodológicos, involucra aspectos tales como la constitución del equipo
56
55
de investigación, la coordinación de las actividades de investigación y la
definición del esquema presupuestario administrativos.
Sobre este tema no existe un criterio único acerca de lo que es
diseño de investigación. Se le agrega además, que este se encuentra
asociado
a
otros
términos
como
marco
metodológico,
tipo
de
investigación y nivel de investigación, que en ocasiones se usan
indistintamente.
S
O
D
VA
R
SE
E
R
S
HO
C
E
básicamenteE
no R
está interesado en comprobar explicaciones, ni en probar
D
determinadas hipótesis, ni en hacer predicciones. Los autores Hernández,
Esta investigación se encuentra dentro del diseño No Experimental
descriptivo, busca únicamente describir situaciones o acontecimientos;
Fernández
y
Baptista
(1991)
refieren
de
una
investigación
no
experimental:
Es aquella que se realiza sin manipular deliberadamente variables.
Es decir, una investigación donde no hacemos variar intencionalmente
las variables independientes. Lo que hacemos en la investigación no
experimental es observar fenómenos tal y como se dan en su contexto
natural, para después analizarlos. (p.189)
Es debido a las razones anteriormente expuestas que se presenta
un diseño no experimental descriptivo, debido a que se realiza la
descripción de los procedimientos necesarios
para la realización del
juego, según las características indispensables para su elaboración,
adicionando la especificación de los requerimientos mínimos para el
debido funcionamiento del juego, y también debido que para la realización
de este proyecto no se manipula deliberadamente las variables.
56
3.3 TÉCNICA E INSTRUMENTOS DE RECOLECCIÓN DE DATOS
Según Hurtado (2008, p. 153), las técnicas tienen que ver con los
procedimientos utilizado para la recolección de datos, es decir el cómo
estas pueden ser de revisión documental. Además, según el mismo autor
(2006, p.164), la selección de técnicas e instrumentos de recolección de
datos implica determinar por cuáles medios o procedimientos el
S
O
D
VA
investigador obtendrá la información necesaria para alcanzar los objetivos
ER
S
E
R
Para la recolección de información
en la presente investigación, se
S
O
H
Cayudaron al logro de los objetivos y a obtener la
optaron por aquellosE
que
R
DE
información
necesaria de manera organizada y precisa. Las técnicas
de la investigación.
empleadas son las enunciadas y desarrolladas a continuación:
3.3.1 REVISIÓN DOCUMENTAL
Para Hurtado (2008, p. 427), es una técnica en la cual se recurre a
información escrita, ya sea bajo la toma de datos que pueden haber sido
producto de mediciones hechas por otros o como texto que en sí mismo
constituyen los eventos de estudio.
Para esta investigación se aplicó la técnica de revisión documental,
consultando textos asociados a los sistemas de información bajo
ambiente web, de igual forma, fue estudiada la gestión electrónica de
documentos, con el fin de obtener una base de conocimiento.
3.3.2 OBSERVACIÓN DIRECTA
Según Hurtado (2008, p. 459), la observación directa constituye un
proceso de atención, recopilación, selección y registro de información,
para el cual el investigador se apoya en sus sentidos.
57
3.3.3 INSTRUMENTOS
También para Hurtado (2008, p. 153), representa la herramienta
con la cual se va a recoger, filtrar y codificar la información, es decir el con
qué.
Los
instrumentos
pueden
estar
ya
elaborados
normalizados.
incluso
S
O
D
VA
R
SE
E
R
S
3.3.4 CUADERNO DE NOTAS
e
HO
C
E
de notas esE
unRdocumento similar al diario. En él se registran las
D
informaciones de los hechos, eventos o acontecimientos en el propio
Por otra parte, según Finol y Camacho (2006, p. 77) un cuaderno
terreno; ayudará a analizar la situación al momento de recoger el material.
3.4
UNIDAD DE ANÁLISIS
Según Hurtado (2010 p. 267), “La Unidad de Análisis se refiere al
ser o entidad poseedora del evento que se desea estudiar; se define de
tal modo que a través de ellas se puede dar una respuesta a la
interrogante de la investigación”. Ante dicha definición, y evaluando los
eventos a estudiar, concluimos identificando la unidad de análisis como
todos los tipos de usuarios que le darán uso a la aplicación a través de los
navegadores web.
3.5
FASES DEL PROYECTO
• Analizar los requerimientos funcionales un juego de estrategia por
turnos con capacidad multijugador utilizando el motor gráfico Unity.
• Investigar tecnologías actuales para el desarrollo web y
desarrollo mediante Unity
58
o Consultar bibliografía
o Consultar proyectos de desarrollo web recientes y
proyectos realizados con Unity
• Realizar una comparación de dichas tecnologías
• Seleccionar la más óptima
• Diseñar estructuras de información del juego de estrategia por
S
O
D
VA
turnos con capacidad multijugador utilizando el motor gráfico Unity.
R
E
S
E
• Realizar el Diagrama de Clases
R
S
HO de Casos de Uso
• Realizar elC
Diagrama
E
R
• E
Realizar el Diagrama Entidad - Relación
D
• Realizar el Modelo de Datos
• Realizar el Diagramas de Interfaces
• Diagramas de Componentes
• Codificar las clases según el diagrama de clases
• Desarrollar los elementos visuales y multimedia que conforman el
juego de estrategia por turnos con capacidad multijugador
utilizando el motor gráfico Unity.
• Diseñar los Rigs de las Unidades de batalla.
• Aplicar texturas a los Rigs realizados.
• Agregar detalles finales a los modelos 3D
• Diseñar los ambientes de Batalla
• Confeccionar los escenarios en base a dichos ambientes
• Aplicar detalles correspondientes a los escenarios según su
clasificación
• Diseño de las interfaces de usuario
• Aplicación de los efectos de sonido
59
• Codificar el juego de estrategia por turnos con capacidad
multijugador utilizando el motor gráfico Unity.
• Evaluar el juego de estrategia por turnos con capacidad
multijugador utilizando el motor gráfico Unity.
• Aplicar prueba de funcionalidad
• Realizar Beta testing.
D
H
C
E
ER
O
SE
E
R
S
R
S
O
D
VA
60
CAPÍTULO IV
ANÁLISIS DE LOS RESULTADOS
En este capítulo se plasman los resultados de la investigación, los
cuales permiten dar respuesta a los objetivos planteados.
4.1.
S
O
D
VA
R
SE
E
R
S
ANÁLISIS DE LOS REQUERIMIENTOS BÁSICOS
HO
C
E
El análisis
DdeElosRrequerimientos debe ser lo suficientemente flexible y
Al momento de desarrollar un juego online es necesario determinar
los requerimientos básicos para el desarrollo y funcionamiento del mismo.
permitir mostrar lo mínimo necesario para el funcionamiento del juego,
para no exceder en gastos de equipos adicionales. Antes de realizar el
análisis de los requerimientos de un juego de estrategia por turnos con
capacidad multijugador, se procederá a determinar las características
generales del mismo y los requerimientos básicos que necesita.
4.1.1. REQUERIMIENTOS DE HARDWARE
Requerimientos funcionales:
-Intel Core 2 Duo con 2.4 Ghz, su equivalente en AMD o superior.
-Tarjeta gráfica Nvidia 7800, su equivalente en ATI o superior.
-4gb de RAM.
Requerimientos operativos:
-Intel Core i3 de 2Ghz, su equivalente en AMD o superior.
-Tarjeta integrada de Intel.
-4 Gbs de RAM.
60
61
4.1.2. REQUERIMIENTOS DE SOFTWARE
-Windows XP SP3; o Windows Vista o posterior.
-Navegador Web Chrome, Mozilla, Opera o Safari.
-Servidor Web Apache 2.2 o superior
-Gestor de base de datos Postgre 9.1 o superior
-Editor de texto Sublime Text 2 y Brackets 1.1.
-IDE Visual Studio 2013.
S
O
D
VA
R
SE
E
R
S
HO
C
E
R proyecto sin embargo, se maneja mayormente las
al juego. Para
Eeste
D
librerías de AngularJS y las pertenecientes al paquete Grid Framework.
En cuanto a las librerías de desarrollo son muy variadas y pueden
implantarse según convenga para brindar más dinamismo y presentación
Estas otorgan facilidades de configuración y utilización para el proyecto.
4.2.
REQUERIMIENTOS DE DISEÑO
Los requerimientos de diseño para el desarrollo de un juego de
estrategia por turnos con capacidad multijugador
requirieron de la
observación de otros juegos que tuvieran características y funcionalidades
similares, a partir de los cuales se observaron ciertas tendencias a
mantener ciertos elementos presentes para la interacción con el usuario,
la forma de interactuar con el juego y elementos de presentación y
configuración. Estos elementos observados son aplicables tanto para el
juego en si como para la aplicación web, la cual contendrá el juego y
permitirá realizar configuraciones dentro de él.
Debido a esto, se decidió implementar una serie de módulos para
dividir la funcionalidad de la página y manejar las acciones del usuario de
manera más eficiente y cómoda; además la estructura interna del juego
también fue manejada modularmente, de tal manera que el despliegue del
62
juego y su interacción con el juego sean lo más cómodas e intuitivas
posibles.
De este modo, mediante Angular Js se logró estructurar la
aplicación web a través del modelo vista-controlador para obtener una
aplicación organizada y fácilmente manejable, esto se logró mediante el
desarrollo modular y permitiendo la reutilización de varios componentes
S
O
D
A unas
usuario de Unity y usando la opción “+”, es posible crearV
y mantener
R
SE de tal manera que
interfaces cómodas e intuitivas para el E
usuario,
R
S
O
aprender a manejar el juego
sea
un proceso fácil y entretenido.
H
C
E
R
E
D
4.3. MODELADO DE DATOS DEL JUEGO
para facilitar el trabajo. Dentro del juego, con la utilización de la interfaz de
La realización del juego y de la aplicación web requirió de una serie
de diagramas UML para el diseño generalizado y para tener una idea
clara de cómo se realizaría la codificación en su momento.
Para ello se realizaron los diagramas de casos de uso para mostrar
como el usuario interactuaría con la aplicación y el juego,
se realizó
igualmente un modelo de datos con el cual se facilita la visualización del
flujo de datos dentro del juego y la aplicación, este diagrama sirve como
base para la realización del diagrama de entidad-relación, que dentro del
mismo se muestra la estructura de la bases de datos, las tablas que
posee y las relaciones entre ellas, el diagrama de despliegue muestra
como la aplicación, el juego y el usuario se relacionan entre ellos y el
diagrama de clases que muestra las interacciones entre las diversas
clases y sus métodos dentro del código del juego y de la aplicación web.
63
4.3.1. CASOS DE USO
De acuerdo con lo descrito por Dan Pilone y Neil Pitman en su libro
“UML 2.0 in a Nutshell”, los diagramas de casos de uso de son una
manera de capturar la funcionalidad del sistema y los requisitos en UML.
Los diagramas de casos de uso consisten en piezas nombradas de
funcionalidad (casos de uso), las personas o las cosas invocando la
S
O
D
VA
funcionalidad (actores) y posiblemente los elementos responsables de
ER
S
E
R
una clase. Cada caso de uso debe
tener
un nombre que suele ser de
S
O
H
Cdescriben la funcionalidad necesaria.
unas pocas palabrasE
que
R
DE
implementar los casos de uso (temas). Casos de uso representan
distintas piezas de la funcionalidad de un sistema, componente o incluso
A continuación se presentan los casos de uso de la aplicación web
y de juego, en donde se observa la interacción del Usuario con cada
elemento.
FallStar World Game
Figura Nº 7: Casos de uso Fallstar World.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
64
En este diagrama se muestra la interacción que tiene el Usuario
con el Juego, este puede realizar ciertas operaciones básicas como las
que se muestran en el diagrama:
S
O
D
VA
El Usuario realiza las siguientes operaciones en el videojuego:
R
SE
E
R
S
● Login: El Usuario debe iniciar sesión para acceder al juego.
HO
C
E
CreateE
Game:
R Se crea una nueva sala para iniciar una partida.
D
Join Game: Ingresar a una sala creada por un usuario conocido.
● Home: Pantalla principal donde el usuario escoge una acción.
●
●
● Find Game: Lista de todas las salas disponibles, para que el
usuario seleccione en cual entrar.
● Loading: Pantalla de espera mientras se carga la interfaz del juego.
● Play: Pantalla donde se desarrolla el Juego.
● Salir: Volver al home desde cualquier pantalla.
Figura Nº 8: Casos de uso Fallstar World
65
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
En este diagrama se muestra la interacción que tiene el Usuario
con la aplicación web, este puede realizar ciertas operaciones básicas
como las que se muestran en el diagrama:
S
O
D
VA
El Usuario realiza las siguientes operaciones en la aplicación web:
ER
S
E
R
S
SignIn: Si el Usuario no O
tiene
una cuenta, debe registrarse.
H
C
E
Start Game:
abre
en
DER una nueva tab del navegador el juego.
● Login: El Usuario debe iniciar sesión para acceder al juego.
●
●
● User menu: menú donde se despliegan todas las acciones
disponibles para el usuario.
● Ver Record: El usuario visualiza una lista de todas las partidas
jugadas, y sus resultados.
● Ver unidades Disponibles: El usuario visualiza una lista de las
unidades disponibles actualmente en el juego.
● Ver unidades Propias: El usuario visualiza una lista de las unidades
disponibles adquiridas por el usuario.
● Comprar unidades: El usuario visualiza una Pantalla para comprar
unidades nuevas.
● Ver Mapas Disponibles: El usuario visualiza una lista de los Mapas
disponibles.
● Ver tipos de Batalla: El usuario visualiza una lista de los tipos de
batalla disponibles.
4.3.2. MODELO DE DATOS
El modelado de datos es un proceso utilizado para definir y analizar
requerimientos de información necesarios para apoyar el proceso de
66
negocio dentro del rango del sistema de información en organizaciones.
Por ende, el proceso de modelado de datos involucra modeladores de
datos profesionales que trabajan muy cerca de las partes interesadas de
la empresa, como también potenciales usuarios del sistema de
información. De acuerdo con Steve Hoberman, el modelado de datos es
un proceso de aprendizaje de información, y el modelo de datos es el
resultado de los procesos de modelados de datos.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 9: Modelo de datos Fallstar World.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Como puede observarse en la figura, se tienen 7 entidades cuyas
relaciones se puedes apreciar, la entidad “Battle”, relaciona un
“Battle_type” y unos “Mapas” representando que una batalla tiene un tipo
y un mapa, “Player_Battle” representa la relación entre los jugadores y las
67
batallas realizadas, “Player” es la entidad que representa a los usuarios,
“Player_unit” es la relación de las unidades que posee cada usuario y
“Unit” es la entidad que representa las unidades del juego.
4.3.3. ENTIDAD RELACIÓN
Según Dan Pilone y Neil Pitman, el Modelo de Entidad Relación es
S
O
D
Aentidades y
consiste en un conjunto de objetos básicos llamados
V
R
SE en forma gráfica a
relaciones entre estos objetos, implementándose
E
R
S
O
través del Diagrama Entidad
Relación.
H
C
E
R
DE
un modelo de datos basado en una percepción del mundo real que
Se procedió a diseñar la estructura de la base de datos para la cual
se utilizó el manejador PostgreSQL. La base de datos fallstar_world_db
fue creada en PostgreSQL.
Figura Nº 10: Entidad Relacion Fallstar World.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
68
Como puede observarse en la figura, se tienen 9 tablas cuyos
campos se pueden apreciar, entre ellas la tabla “player”, en la cual se
almacenan los usuarios registrados.
Los campos de la tabla son los
siguientes:
• id_player: Existe por motivos de optimización de búsquedas.
S
O
D
A de tipo
• player_nombre: Nombre del usuario de la aplicación,
V
R
SE
Varchar con un máximo de 20E
caracteres.
R
S del usuario de la aplicación, de tipo
O
• player_apellido:
Apellido
H
Cun máximo de 20 caracteres.
E
R
Varchar
con
DE
Es llave primaria, siendo ésta un valor entero.
• player_email: Email del usuario de la aplicación, de tipo
Varchar con un máximo de 40 caracteres.
• player_password: Contraseña de la cuenta de usuario, de
tipo Varchar con un máximo de 15 caracteres.
• player_username: Nombre usuario de la cuenta, de tipo
Varchar con un máximo de 10 caracteres.
• player_color: color de la facción del usuario, de tipo Varchar
con un máximo de 10 caracteres.
• player_money: Dinero con el que cuenta el usuario, de tipo
entero.
En la tabla “unit” se guardan los datos de las unidades, los campos
son los siguientes:
• id_unit: Existe por motivos de optimización de búsquedas.
Es llave primaria, siendo ésta un valor entero.
• unit_name: nombre de la unidad, de tipo Varchar con un
máximo de 40 caracteres.
• unit_prefab_name: nombre del prefab, de tipo Varchar con
un máximo de 30 caracteres.
69
• unit_price: precio de la unidad, de tipo entero.
• unit_img: imagen de la unidad, de tipo Varchar con un
máximo de 20 caracteres.
• unit_color: color de la unidad, de tipo Varchar con un
máximo de 10 caracteres.
• id_unit_atrib: atributos de la unidad, es llave foránea de la
S
O
D
VA
tabla unit_atrib.
R
SE
E
R
S
HO
C
E
ER
los campos
los siguientes:
Dson
En la tabla “unit_atrib” se guardan los atributos de las unidades,
• id_ unit_atrib: Existe por motivos de optimización de
búsquedas. Es llave primaria, siendo ésta un valor entero.
• hp: Cantidad de “puntos vitales” que poseen las unidades,
de tipo entero.
• ataque: Cantidad de “puntos vitales” que poseen las
unidades, de tipo entero.
• defensa: Cantidad de “puntos vitales” que poseen las
unidades, de tipo entero.
• hit: Cantidad de “puntos vitales” que poseen las unidades, de
tipo entero.
• critical: Cantidad de “puntos vitales” que poseen las
unidades, de tipo entero.
• movimiento: Cantidad de “puntos vitales” que poseen las
unidades, de tipo entero.
En la tabla “player_unit” se guardan los datos de las unidades
adquiridas por un jugador, los campos son los siguientes:
70
• id_ player_unit: Existe por motivos de optimización de
búsquedas. Es llave primaria, siendo ésta un valor entero.
• id_unit: id de la unidad, es llave foránea de la tabla unit.
• id_player: id del jugador, es llave foránea de la tabla player.
S
O
D
A
En la tabla “player_atrib” se guardan los datosR
deV
los atributos de
SE
las unidades adquiridas por un jugador,R
losE
campos son los siguientes:
S
O
H
C
E
R
• E
Id_ player_atrib: Existe por motivos de optimización de
D
búsquedas. Es llave primaria, siendo ésta un valor entero.
• Id_ player_unit: id de la unidad perteneciente al usuario, es
llave foránea de la tabla player_unit.
• Hp: Cantidad de “puntos vitales” que poseen las unidades,
de tipo entero.
• Ataque: Cantidad de “puntos vitales” que poseen las
unidades, de tipo entero.
• Defensa: Cantidad de “puntos vitales” que poseen las
unidades, de tipo entero.
• Hit: Cantidad de “puntos vitales” que poseen las unidades,
de tipo entero.
• Critical: Cantidad de “puntos vitales” que poseen las
unidades, de tipo entero.
• Movimiento: Cantidad de “puntos vitales” que poseen las
unidades, de tipo entero.
En la tabla “map” se guardan los datos de los mapas, los campos
son los siguientes:
71
• id_map: Existe por motivos de optimización de búsquedas.
Es llave primaria, siendo ésta un valor entero.
• map_descripcion: descripción del mapa, de tipo Varchar con
un máximo de 40 caracteres.
• map_ancho: ancho del mapa en cuadros, de tipo entero.
• map_largo: largo del mapa en cuadros, de tipo entero.
• map_nombre: nombre del mapa, de tipo Varchar con un
S
O
D
A
V
• map_image: imagen del mapa, de tipo
Varchar con un
R
SE
máximo de 10 caracteres.RE
S
O
H
C
E
R
EnD
la E
tabla “battle_type” se guardan los datos de los tipos de
máximo de 20 caracteres.
batalla, los campos son los siguientes:
• id_battle_type: Existe por motivos de optimización de
búsquedas. Es llave primaria, siendo ésta un valor entero.
• battle_type_name: nombre del tipo de batalla, de tipo
Varchar con un máximo de 15 caracteres.
• battle_type_descripcion: descripción del tipo de batalla, de
tipo Varchar con un máximo de 40 caracteres.
• battle_type_tiempo_total: tiempo total que dura la partida, de
tipo time.
• battle_type_tiempo_por_turno: tiempo por turno para los
jugadores, de tipo time.
• battle_type_max_units: máximo de unidades por jugador, de
tipo entero.
• battle_type_objects: indica si hay obstáculos en el mapa, de
tipo boolean.
• battle_type_time_limit: indica si la partida es contra el reloj,
de tipo boolean.
72
En la tabla “battle” se guardan los datos de las batallas realizadas,
los campos son los siguientes:
• id_battle: Existe por motivos de optimización de búsquedas.
Es llave primaria, siendo ésta un valor entero.
• id_map: id del mapa, es llave foránea de la tabla map.
S
O
D
VA
• id_battle_type: id del tipo de batalla, es llave foránea de la
tabla battle_type.
R
SE
E
R
S
HO
C
E
EunRjugador, los campos son los siguientes:
realizadasD
por
En la tabla “player_battle” se guardan los datos de las batallas
• id_player_battle: Existe por motivos de optimización de
búsquedas. Es llave primaria, siendo ésta un valor entero.
• player_battle_time: duración de la batalla, de tipo time
• player_battle_result: boolean que representa el resultado de
la batalla, true si el usuario gano, false si perdió.
• id_player: id del jugador, es llave foránea de la tabla player.
• id_battle: id de la batalla, es llave foránea de la tabla battle.
• id_adversario: id del jugador contrincante, es llave foránea
de la tabla player.
4.3.4. DIAGRAMA DE DESPLIEGUE
Según Dan Pilone y Neil Pitman, los diagramas de despliegue
modelan la asignación de piezas de software de un sistema para el
hardware que se va a ejecutar. Elementos de software (componentes,
clases, etc.) se manifiestan típicamente usando artefactos y se asignan al
medio ambiente de hardware o software que será la sede de ellos,
llamados los nodos.
73
Porque
muchos
nodos
pueden
estar
asociados
con
la
implementación de un sistema, comunicación entre nodos puede ser
modelada usando vías de comunicación.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 11: Diagrama de Despliegue Fallstar World.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Dentro del primer diagrama se puede evidenciar como interactúa el
usuario con los elementos de hardware, inicialmente el usuario ingresara
a la aplicación web a través de su browser, en esta pude realizar
cualquier operación de mantenimiento de su cuenta, para estas
operaciones se comunica con el servidor principal del juego, y este a su
vez se conecta con la base de datos, dentro de la aplicación igualmente
puede acceder al juego, adicionalmente, puede acceder al juego
introduciendo la URL correspondiente en el explorador, una vez dentro del
juego este también realiza una conexión al servidor principal del juego
para realizar la validación de la cuenta del usuario, está a su vez retorna
74
la información del usuario, necesaria para que el juego funcione, una vez
culminada la validación de la cuenta introducida, el juego se conecta a la
Photon Cloud, en la cual se gestiona el intercambio de información entre
los jugadores.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 12: Diagrama de Despliegue Fallstar World.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
En el Diagrama anterior se representa como se comunican los
usuarios del juego a través del Photon Cloud.
4.3.5. DIAGRAMA DE CLASES
De acuerdo con Dan Pinone y Neil Pitman, los diagramas de clase
son uno de los más fundamentales tipos de diagrama UML. Se utilizan
para capturar las relaciones estáticas de su software; en otras palabras,
cómo las cosas se ponen juntas y se relacionan. Al realizar software, se
están tomando constantemente decisiones de diseño: Qué clases de
sostener las referencias a otras clases, la clase "posee" alguna otra clase
75
y así sucesivamente. El diagrama de clase proporciona una manera de
capturar esta estructura "física" de un sistema.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 13: Diagrama de Clases Fallstar World.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
76
En la figura No X se parecía el diagrama de clases del juego, en él
se tiene un total de 8 clases, de las cuales 5 se encargan de gestionar las
conexiones entre los jugadores y 3 se encargan de la jugabilidad en sí del
juego.
En los diagramas de conexión de los jugadores se encuentran
Menú, Menú Multiplayer, Menu Join y Menú Lobby.
S
O
D
VA
R
SE
E
R
S
La clase Menu usa los atributos y métodos de sus los demás
O
H
C
E
de Menu son un
Rbooleano llamado “requierePlayerName” que dictara
E
D
cuando será necesario ingresar el nombre el usuario y que habilitara los
scripts que dependen de él; posee 7 atributos y 4 métodos, los atributos
demás menús, “playerNameInput” que es el nombre que tendrá el usuario
dentro del juego; posee también los atributos “skin” en el cual se le
adjunta alguna apariencia a los textos y cuadros que se utilizan en el
menú, SP que viene a ser una variable del mismo tipo que la clase que la
utiliza, y variables que llaman a los demás scripts de los cuales dependen
la clase Menu.
Para los métodos de la clase Menu se tienen el método “Awake” en
el cual se inicializan los valores de algunas variables al inicio del juego, el
método “OnGUI” que se encarga de las interacciones con el usuario con
los botones y cuadros de textos, el método “OpenMenu” que tiene como
parámetro un string llamado ‘newMenu’, este método se encarga de
habilitar cuál de todos los menús deben abrirse e identifica cual menú
debe abrirse con el parámetro que recibe; y utiliza el método NameMenu
que tiene como parámetro un int llamado ‘id’ y con este método muestra
el menú en el cual se ingresara el nombre que utilizara el usuario.
En la clase Menu Multiplayer se tienen 2 atributos y 4 métodos, un
booleano llamado ‘showMenu’ que se utiliza para saber cuándo debe
77
mostrarse este menú al usuario y un Rect llamado ‘myWindowRect’ el
cual es simplemente un cuadro en el cual se coloca texto. Entre los
métodos que utiliza se encuentran “Awake” en el cual se inicializa el
cuadro donde se mostrara la información, el método “EnableMenu” que
coloca el booleano ‘showMenu’ como verdadero, y se usan los métodos
“OnGUI” y “WindowGUI” para gestionar la interfaz de usuario.
S
O
D
Ala interfaz,
se utiliza para colocar una apariencia personalizada
a
V
R
SE
‘windowRect1’ y ‘windowRect2’ que son
cuadros
en los cuales se coloca
E
R
S
texto, botones y otros elementos
HO para la interacción con el usuario, un
C
E
string ‘errorMessage’
DER que se utiliza para mostrar que tipo de error ha
En la clase Menu Join se tienen 7 atributos y 5 métodos, ‘skin’ que
ocurrido, un botón llamado ‘customButton’, un booleano llamado
“showMenu” que se utiliza para verificar cuando el menú debe ser
mostrado, y un Vector2 “joinScrollPosition” utilizado para ajustar las
posiciones de algunos elementos de la interfaz de usuario. Los métodos
que posee son “Awake” que inicializa un cuadro donde se mostrará
información, “EnableMenu” que coloca el booleano ‘showMenu’ como
verdadero y permitiendo mostrar el menú, el método “OnJoinedRoom” en
el cual desabilita mostrar el menú actual y muestra el menú del lobby, y
los métodos “OnGUI” y “listGUI” para manejar las interacción del usuario
con la interfaz y el comportamiento de la interfaz.
Para la clase MenuLobby se tienen 10 atributos y 12 métodos, un
int llamado ‘selGridInt’ que se utiliza para la selección del nivel que se
cargará, un arreglo de strings llamado ‘selStrings’ en el cual se almacenan
los nombres de los niveles que se van a cargar, un atributo ‘skin’ para
colocarle una apariencia personalizada al menú, un atributo ‘SP’ de tipo
MenuLobby, dos atributos booleanos ‘launchingGame’ y ‘showMenu’ que
se utilizan para verificar cuando debe cargarse la escena en la que se
desee jugar y cuando debe mostrarse el menú del lobby respectivamente,
78
se tienen dos strings ‘serverTitle’ y ‘hostSettingTitle’ los cuales como sus
nombres lo indican son los nombres que se le asignan a las salas creadas
por los usuarios, y están los int ‘serverMaxPlayers’ y ‘hostSettingPlayers’
los cuales se utilizan para limitar la cantidad de usuarios que pueden estar
en una sala simultáneamente.
La clase MenuLobby posee los métodos “Awake” en el cual se
S
O
D
A
habilita el menú del lobby, el método “OnGUI” en donde
se maneja la
V
R
E
interacción del usuario con la interfaz,
el S
método “LeaveLobby” que
E
R
S
Odel lobby y corte la conexión con él, el
permite que el usuario se H
salga
C
E
método “CreationSettings”
el cual se utiliza para ajustar cómo será la
ER
D
configuración de la sala, el método “StartHost” con el cual se crea la sala,
inicializan algunas variables, el método “EnableLobby” en el cual se
el método “ShowLobby” que muestra el lobby con todas las partidas en
las cuales el usuario puede ingresar.
También posee el método “OnCreatedRoom” en el cual permite
que la sala pueda ser vista desde el lobby, el método “SetServerSettings”
en el cual se realizan las configuraciones deseadas para el servidor, el
método “HostLaunchGame” en el cual se le quita la visibilidad de la sala a
los demás jugadores en el lobby para que no puedan ingresar en una
partida en progreso, y que llama al método LaunchGame, el método
“LaunchGame” el cual setea el booleano ‘launchingGame’ como
verdadero y el método “LaunchingGameGUI” se encarga de mostrar un
menú que dice que está por empezar el juego y carga la siguiente escena
para que todos los jugadores empiecen la partida.
La clase GameScript es una clase la cual funciona mayormente en
el background dentro de las partidas. Esta muestra los estados de
conexión (como la latencia y jugadores conectados) y permite salirse de la
sala. También se encarga de mantener las conexiones de los jugadores
79
del momento de pasar de la sala en el lobby hasta la partida como tal.
Esta clase maneja 5 métodos, los cuales son “Awake” que se encarga de
habilitar que mensajes puedan ser transmitidos entre los jugadores, el
método “OnGUI” que se encarga de mostrar los botones para salir de la
partida y muestra los estados de conexión del jugador, el método
“OnDisconectedOnPhoton” que muestra un mensaje si se pierde la
conexión,
y
los
métodos
“OnPhotonPlayerConnected”
y
S
O
D
A
jugador se ha conectado o desconectado respectivamente.
V
R
SE
E
R
S
La clase DBConnectH
es O
una clase con un solo parámetro y un solo
EparaClograr la conexión con un script de PHP el cual
R
método, y seE
utiliza
D
“OnPhotonPlayerDisconnected” que muestran un mensaje diciendo cual
maneja toda la conexión con base de datos. Esta clase tiene de
parámetro el string ‘url’ el cual contiene la dirección a la cual debe
conectarse, y tiene un método “Connect” con el cual realiza la conexión al
script de PHP y manda y recibe toda la información que necesite de él.
Para el manejo de la jugabilidad del juego, se utilizan 3 clases
“GameUnits”, “RoamGrid” y “GridScript”.
En la clase GameUnits se maneja los atributos que todas las
unidades poseen y se manejan los métodos de atacar a otras unidades,
recibir daño y morir. La clase maneja 16 atributos y 6 métodos. De
atributos posee 4 de tipo int que son ‘hp’, ‘atk’, ‘def’ y ‘dmgResult’ los
cuales son la energía de la unidad, el daño que es capaz de hacer, la
defensa de la unidad y una variable auxiliar que se utiliza para calcular
cuánto daño recibirá una unidad en algún momento. Usa 2 atributos de
tipo float que son ‘hitChance’ y ‘critChance’ los cuales se utilizan para
calcular cuando una unidad acertará su ataque y cuando ocasionará daño
adicional respectivamente. Posee 2 booleanos que son ‘canAttack’ y
‘isSelected’ los cuales se utilizan para identificar cuando una unidad ya
puede atacar y cuando esta seleccionada. Se tienen 5 atributos de tipo
80
GamaObject los cuales son ‘grid’, ‘gui1’, ‘gui2’, ‘gui3’, y ‘explosion’ con los
cuales se seleccionan el grid de referencia, los botones de mover, atacar
y terminar turno, y un sistema de partículas que se activa cuando una
unidad muera.
Los métodos que posee la clase GameUnits son “Awake” con el
cual se inicializan una serie de variables, el método “RecieveDamage”
S
O
D
A por otra y
se disminuye el hp de la unidad cada vez que esta es atacada
V
R
Sa 0,Ese ejecutar el método
cuando esta termina con un hp menor R
o igual
E
Sde instanciar un sistema de partículas
O
Dead. El método Dead se H
encarga
ECla unidad destruida en forma de explosión y
R
en donde seE
encuentre
D
que contiene un parámetro de tipo int llamado ‘damage’, con este método
también se encarga de eliminar la unidad de la escena. El método
“EnableMove” es un método que se encarga de habilitar el movimiento de
una unidad de un sitio del grid al otro. El método “OnMouseOver” se
encarga de que cuando se le haga click en una unidad se habiliten los
botones de acción (moverse, atacar) para que la unidad pueda realizar
cualquier acción que el jugador desee.
La clase RoamGrid es la que se encarga de manejar el movimiento
de la unidad dentro del grid. Esta clase posee 12 atributos y 6 métodos.
Se tienen 6 atributos de tipo Vector3 los cuales son ‘PI’, ‘PF’,
‘newPosition’, ‘lastPosition’, ‘start’ y ‘goal’, todos estos atributos se utilizan
para obtener las posiciones en las cuales debe moverse la unidad.
También posee un atributo de tipo GFGrid llamado ‘grid’ en el cual se
almacena el grid en el cual la unidad se moverá, un atributo tipo transform
llamado ‘mySelf’ en el cual se almacena la unidad como en sí, un atributo
de tipo int llamado ‘distanciaUnidad’ el cual es utilizado para almacenar la
distancia máxima la cual una unidad es capaz de recorrer dentro del grid,
y dos atributos de tipo float que son ‘counter’ y ‘roamingSpeed’ los cuales
son utilizados como variable auxiliar para saber cuándo una unidad se
81
podrá mover y la velocidad a la cual la unidad se moverá dentro de la
animación respectivamente y un booleano llamado ‘myTurn’ en el cual
inidca si la unidad puede moverse o no.
La clase tiene RoamGrid tiene los métodos “Awake” en el cual
inicializa los valores de algunas unidades, el método “SetTurnFalse” que
coloca como verdadero la variable ‘myTurn’, tiene el método “converter”
S
O
D
A“Update” que
posiciones vectoriales a un valor de tipo int, tiene el método
V
R
SE “OnMouseOver” con
en cada frame actualiza algunos valores,
el
método
E
R
S
O
el cual al hacer click en la H
unidad
habilita su turno y adquiere la posición
C
E
inicial del traslado,
ERy tiene el método “MoveUnit” que es el que llama a la
D
animacion de la unidad para moverla de un sitio al otro.
que se encarga de convertir la distancia que recorrerá la unidad de
Y finalmente se tiene la clase GridScript, esta es una clase auxiliar
para la clase Roamgrid ya que le pasa parámetros los cuales necesitará
la mover la unidad al sitio donde se desee. Esta clase posee 5 atributos y
3 métodos, 2 Vector3 llamado ‘newPoint’ y ‘PF’ los cual son utilizados
para almacenar que punto del grid fue clickeado, un GFGrid llamado ‘grid’
que almacena que grid debe de tener como referencia, una variable de
tipo RoamGrid llamada ‘roamgrid’ la cual se utiliza para obtener y pasar
valores a las variables de ese script, y un arreglo de GameObjects
llamado ‘Units’. Tiene como métodos “Awake” el cual utiliza para inicializar
algunas variables y el método “OnMouseOver” con el cual al hacer click
en el grid, almacena que punto del grid fue clickeado.
En la figura No 4, se aprecia el diagrama de clases para la
aplicación web, en él se tiene las siguientes clases:
82
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 14: Diagrama de Clases Fallstar World.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
83
Primeramente se tiene la clase App.js, esta es la encargada de
gestionar el enrutamiento, tiene 2 atributos, $urlRouterProvider y
$stateProvider, el primero representa el actual url que se muestra en el
browser, y el $stateProvider es la nueva ruta referenciada dinámicamente
mediante Ajax, esto se realiza mediante el método state, el cual recibe
como parámetro, un nombre, una url, un template html y de ser necesario
S
O
D
VA
un controlleR y de ser necesario un controller, a esta clase se encuentran
R
SE
E
R
S
asociadas todos los controladores de la aplicación.
Luego tenemos los controladores, estas son las clases responsables de
O
H
C
E
siguientes 8 controladores
DER para este proyecto:
manipular los datos que se despliegan a través de las vistas, se tienen los
• signInCtrl.js: este es el controlador encargado de enviar la
información en forma de JSON al Servidor Web, tiene un atributo
color que representa el color seleccionado por el usuario para sus
unidades, el atributo $scope que se utiliza para manipular la
información que viene desde la vista, el atributo $http es el objeto
encargado de realizar las llamadas asíncronas al servidor, y el
atributo $window que se encarga de redireccionar la pagina al
Login una vez registado el usuario. Adicionalmente se tiene el
método signIn(), que envia los datos en formato JSON al Servidor
Web.
• listCtrl.js: este es el controlador del menú lateral de la aplicación, el
atributo $scope que se utiliza para manipular la información que
viene desde la vista, UserService es un objeto que almacena los
datos del usuario logueado en el localStorage del explorador, el
atributo $window que se encarga de re direccionar la página al
Login en caso que el usuario no este logueado.
84
• cartCtrl.js: este es el controlador que maneja el módulo de comprar
unidades, sus métodos se basan en el funcionamiento en un carrito
de compras, el método findUnits() obtiene la información de las
unidades desde el Servidor web, el método agregar() ingresa una
unidad al carrito de compras, los métodos aumentar() y disminuir()
se utilizan para gestionar la cantidad de unidades dentro del carrito
y el método comprar envía la información mediante json a la base
S
O
D
Aobtener la
V
mapCtrl.js: este controlador es el encargado
de
R
SE
información de los mapas desde
elE
servidor web y desplegarla a
R
S
través de la vista. HO
C
E
R
recordCrtl.js:
DE este controlador es el encargado de obtener la
de datos para realizar la compra.
•
•
información de los records de un usuario desde el servidor web y
desplegarla a través de la vista.
• loginCtrl.js: este es el controlador encargado de gestionar los
ingresos de los usuarios al sistema, valida si el usuario existe
llamando al Servidor Web.
• UnidadesPropiasCtrl.js: este controlador es el encargado de
obtener la información de las unidades propias de un usuario
desde el servidor web y desplegarla a través de la vista.
• UnidadesDisponiblesCtrl.js: este controlador es el encargado de
obtener la información de todas las unidades disponibles en el
juego desde el servidor web y desplegarla a través de la vista.
Una vez definidos los controladores cabe mencionar que estos
trabajan en conjunto con los scripts php respectivos dependiendo de la
función a realizar, los scripts con los que cuenta el proyecto son los
siguientes:
• Constantes.php: clase ne la cual fueron definidas las constantes de
conexión a base de datos.
85
• PhpPDBC.php: clase que gestiona la conexión a base de datos,
tiene 3 metodos fundamentales, conectar (), query () y destruir ().
• fallstar_world_login.php: clase que maneja el Login en la
aplicación, recibe un JSON con el username y el password, realiza
la consulta correspondiente a la base de datos y de existir
coincidencia, retorna un JSON con la cantidad de dinero, el color
S
O
D
VA
de las unidades y el id del jugador, estos datos serán utilizados por
el cliente para búsquedas posteriores, de no existir conincidencia
R
E
S
E
fallstar_world_sigin.php: recibe un
JSON con los datos ingresados
R
S
al formulario delC
cliente
HOy crea el nuevo registro en la base de
E
datos.
DER
retorna un “Error de Usuario o Contraseña”.
•
• fallstar_world_map.php: retorna un JSON con la data de los mapas
que se encuentra en la base de datos.
• fallstar_world_record.php: recibe un JSON con el id del jugador y
realiza una búsqueda en base a este parámetro, retorna un json
con la información encontrada.
• fallstar_world_UnidadesDisponibles.php: retorna un JSON con la
información de todas las unidades que posea el juego actualmente.
• fallstar_world_UnidadesPropias.php: recibe un JSON con el id del
usuario y retorna un JSON con la información de todas las
unidades que posea el jugador actualmente.
• fallstar_world_unit.php: recibe como parámetro un JSON con los Id
de las unidades según su color, y retorna un JSON con la
información de esas unidades.
• fallstar_world_playerUnit.php: recibe un JSON con la información
de las unidades compradas y en qué cantidad, y realiza la inserción
en la base de datos.
• fallstar_world_playerMoney.php: recibe un JSON con el id del
jugador y retorna un JSON con la cantidad de dinero que posee.
86
4.4.
DISEÑO Y ESQUEMATIZACIÓN DE LOS ASPECTOS VISUALES
Una vez terminada la planificación del desarrollo del juego, se
procedió a la parte del diseño, la cual es parte del funcionamiento básico
que debe de tener la aplicación web y el juego, y que ayudó al momento
de realizar la codificación y permitió tener presente la estructura de los
S
O
D
A se maneja
mismos. Los diseños incluyen a la aplicación web, con la
cual
V
R
SEal juego, también se
la cuenta de cada usuario y se puede
acceder
E
R
S
O
diseñaron las interfaces dentro
del juego, con las cuales el jugador
H
C
E
R que se utilizan en el juego, los ambientes en los
interactúa, las
DEunidades
módulos a realizar, la forma de realizarlos y las interacciones entre los
cuales las batallas se realizarán y efectos especiales utilizados en el
juego.
4.4.1. DISEÑO DE LA APLICACIÓN WEB
Una vez terminada la planificación del desarrollo del juego, se
procedió a realizar el diseño de la aplicación web, se planteó el uso de un
esquema SPA (Single Page Application), el cual dictamina que todas las
operaciones dentro de la aplicación web se realizaran en una sola pág., y
las opciones se irán desplegando dinámicamente en concordancia con las
acciones del usuario, en cuanto a la estética de la aplicación se buscó
principalmente la cohesión de los colores junto con la implementación una
interfaz agradable al usuario.
A continuación se presentan las pantallas utilizadas en la aplicación web:
87
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 15: Pantalla de LogIn.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Figura Nº 16: Pantalla de SignIn.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
88
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 17: Pantalla de Menú Principal.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Figura Nº 18: Comprar Unidades.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
89
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 19: Unidades Disponibles.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Figura Nº 20: Unidades del Usuario.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
90
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 21: Records del Usuario.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Figura Nº 22: Tipos de batalla.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
91
4.4.2. DISEÑO DE LAS INTERFACES DEL JUEGO
El diseño de las interfaces se realizó primero determinando cuáles
serían las interacciones adecuadas a las necesidades del usuario.
Entre ellas se encuentran los menús en los cuales seleccionará si
se desea ver las partidas existentes, entrar en una partida o crear una
nueva.
S
O
D
VA
ER
S
E
respectivos lobbies se realizaron S
sin R
la utilización de las herramientas
O
H
C
visuales de Unity, y E
adicionalmente
se utilizó una interfaz básica de Unity,
R
E
además D
de agregarle un Skin adicional que provino del paquete de
La interfaz del menú de acceso a las diferentes salas y a sus
Photon para darle un estilo y color distinto. Se realizó de esta manera ya
que resultaba más fácil para la implementación posterior de los eventos y
las modificaciones que se estarían realizando para la creación de salas y
la conexión hacia las mismas, además de que esta interfaz no requería
ser demasiado elaborada.
La interfaz del juego fue realizada con una herramienta visual para
el desarrollo de interfaces que fue implementada en la versión 4.6 de
Unity, la cual da una mayor libertad y facilidades para el desarrollador.
Ésta metodología requiere un poco más de tiempo pero los resultados son
estéticamente mejores y permiten mayor interactividad con el usuario y
con algunos de los eventos que se estén desarrollando dentro del juego.
El paquete Unity provee una interfaz básica basada en la que está
presente en Unity 4.6 la cual fue modificada de tal manera que se
adaptara mejor a las necesidades del juego, incluyéndole algunos
botones con eventos especiales los cuales no estaban anteriormente y se
eliminaron algunas de las acciones las cuales se realizaban con la interfaz
que se tenía por defecto.
A continuación se presentan las pantallas utilizadas en el juego:
92
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 23: Login.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Figura Nº 24: Menu Principal.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
93
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 25: Crear partida.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Figura Nº 26: Menu partida actual.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
94
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 27: Lobbies partidas Disponibles.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Figura Nº 28: Interfaz del Juego.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
4.4.3. DISEÑO DE LOS “MODELS” DE LAS UNIDADES
95
Para el diseño de los “models” de las unidades, se procedió
primeramente concebir
qué tipo de unidades contendría el juego, se
eligieron tanques y naves debido a que estas eran relativamente fáciles
de crear y requerían pocas animaciones dentro de las batallas y animar
sus movimientos alrededor del campo es más sencillo que con unidades
humanoides. Posteriormente, se dibujaron unos bocetos de cómo se
verían cada una de las unidades y se les dieron nombres a cada una.
S
O
D
A este
cual se crearon los rigs y modelos 3D de cada una de las
unidades;
V
R
SEgeométricas en 3D ya
proceso consistió básicamente en colocar
figuras
E
R
S
predefinidas en la aplicación
yO
‘moldearlas’ de manera tal que tuvieran la
H
C cambiar sus tamaños, sus formas e inclusive
E
R
forma deseada,
esto
incluye
DE
Después de eso se utilizó el programa de modelado 3D Blender con el
tomar varias de estas figuras y juntarlas para obtener el resultado final.
Ese proceso se realizó para todas las unidades de manera tal de
tener todos los models preparados para las siguientes fases del desarrollo
del
juego.
Posteriormente,
se
crearon
una
serie
de
texturas
correspondientes a las diferentes áreas de cada unidad, de tal manera
que tuvieran los colores que originalmente se deseaban. Una vez creadas
las unidades, se exportaba los modelos con sus respectivas texturas a
Unity, y se realizaban las animaciones respectivas para cada unidad,
como las animaciones de ataque, movimiento, entre otras.
4.4.4. DISEÑO DE LOS AMBIENTES DE JUEGO
Los ambientes del juego fueron creados dentro del editor de
escenas Unity. Se crearon 2 mapas distintos, y de cada uno existe 2
96
variantes, en el primero se encuentra el terreno libre de tal manera que
hay total libertad de movimiento, en la segunda forma, se encuentra el
mismo ambiente pero con obstáculos en el campo de batalla, de tal
manera de dificultar el paso y como consecuencia de esto las batallas.
Los mapas fueron creados importando algunos elementos visuales
disponibles dentro de la tienda de Unity de manera gratuita y
S
O
D
VA
colocándolos de manera tal, que se insertó la plataforma principal, los
ER
S
E
R
S
algunos efectos especiales como
sistemas
de partículas e iluminaciones
O
H
C efectos para simular el ambiente donde se
E
especiales, Se R
agregaron
DE
caminos que conducen a las salidas y las paredes que contienen el lugar;
de esta manera obtuvo su forma final. Adicionalmente, se le agregaron
encuentra la plataforma. A parte de esto, se le agregaron algunos
elementos decorativos de tal manera de que el ambiente no pareciera
vacío. Para la versión del mapa que posee obstáculos, se colocaron estos
mismos elementos que se encontraban distribuidos alrededor del mapa
dentro del campo de batalla.
La escena de la plataforma espacial se desarrolló importando un
paquete de props de Unity que contenía los elementos necesarios para la
creación del mapa. Se creó
la escena, y se agregó el grid principal
usando el editor de Grid Framework. Observándose en la figura 29:
97
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 29: Grid.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Posteriormente, se colocó una previamente realizada, dentro del
cual se desarrollan las batallas, se realizaron modificaciones en la
posición para que concordara con el Grid, de tal manera que parezca que
las unidades están sobre la plataforma. Esto se observa en la figura No
30.
98
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 30: Primera plataforma.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Después de eso, se procedió a colocar plataformas de conexión las
cuales conectan
los extremos de la plataforma principal, de tal manera
que da la impresión de que de no estar totalmente suspendida. Estas
tenían las texturas previamente aplicadas, así que se procedió a
posicionarlas de la manera deseada, con la orientación correcta. A su vez,
se comenzó a aplicar efectos especiales, que consisten en los
“propulsores” de la plataforma, pero dentro de esta fase aún no estaban
finalizados. Los resultados pueden observarse en la figura 31.
99
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 31: Plataforma con puentes.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Posteriormente, se colocaron las paredes que cubren la plataforma
espacial de tal manera que de la sensación que se encuentra dentro de
una edificación. Estos muros eran pocos en variedad, por lo cual se
duplicaron de tal manera de cubrir todo el espacio necesario para dar la
sensación anteriormente mencionada. A su vez, se le agregaron una serie
de props como cajas y generadores de energía para llenar espacios
vacíos en la plataforma. Esto se observa en la imagen 32.
100
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 32: Plataforma con ambiente.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Una vez agregados todos estos elementos, se culminaron los
efectos de partículas que simulan los propulsores para la plataforma, y se
agregaron los obstáculos que impedirán el paso de las unidades a través
de ciertos espacios del grid, se inhabilitaron dichos espacios para
asegurarse de que ninguna unidad pudiese posicionarse dentro de ellos.
Esto se observa en la figura 33.
101
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 33: Grid.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Para la realización del mapa de Lava, se empezó por crear una
escena nueva el editor de Unity, para posteriormente agregar el Grid
utilizando el editor de Grid Framework. Después, se creó un terreno
utilizando las herramientas nativas de Unity, y se configuro su tamaño de
tal manera que se adaptara al grid y tuviera un espacio amplio para
colocar elementos adicionales posteriormente. Esto se observa en la
figura 34.
102
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 34: Grid y terreno inicial.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Con el terreno ya creado, se procedió a cambiar su forma utilizando
las herramientas de modelado de Unity, se modificaron de tal manera que
se enfocara el epicentro del escenario como la zona de batallas, y los
alrededores se moldearon de tal manera que quedaran fosas de lava y
algunas montañas que enmarcaran el escenario. Esto se puede observar
en la imagen 35.
103
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 35: Terreno modificado.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Con el terreno ya moldeado, se procedió a la aplicación de las
texturas. Utilizando texturas disponibles gratuitamente de la tienda de
Unity, se descargaron y se le aplicaron con las herramientas de modelado
integradas de Unity. Se utilizaron texturas de tierra rojiza con rocas para
el área de la batalla principal, una textura de lava para las fosas,
marrones, grises con rocas y terrenos para las montañas que cubren el
área. Esto se observa en la figura 36.
104
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 36: Terreno con textura.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Después de eso, se procedió a realizar los efectos especiales de
escena, implementando primero una nueva iluminación rojiza que
produjera el efecto de altas temperaturas, las cuales serían causadas por
la lava. Esto se observa en la figura 37.
Figura Nº 37: Efectos especiales iniciales.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
105
A partir de este punto, se le realizó un cambio al tamaño del grid
perteneciente escena de tal manera que se adaptara un poco más al
tamaño del terreno y para que fuera capaz de albergar más unidades
dentro de la plataforma, y a su vez se ajustó el terreno cambiando el
tamaño y posición de las montañas y de las fosas de lava, de manera tal
que se adaptaran al nuevo tamaño del grid y logrando un mejor acabado
final para el terreno. Estos cambios se observan en la figura 38.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 38: Ajuste de Terreno.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Por último, se implementaron una serie de sistemas de partículas
con los cuales se da el efecto de lava dentro de las fosas, además se
agregaron pilares de fuego en los alrededores para dar una mayor
sensación de inestabilidad al ambiente. Estos pilares se realizaron usando
el sistema de partículas nativo de Unity, se le agregaron texturas nuevas y
se adaptaron nuevos comportamientos para obtener los efectos
deseados.
Una vez aplicados, se agregaron algunos props adicionales como
rocas, el mapa puede observarse en la figura 39.
106
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 39: Versión Final.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
4.4.5. DISEÑO DE LOS EFECTOS ESPECIALES DEL JUEGO
Los efectos especiales dentro del juego vienen a ser los sistemas
de partículas utilizados en todas las escenas y además, la iluminación
especial en algunos de los escenarios para dar un mejor ambiente. En la
realización de los efectos especiales principalmente se utilizó el sistema
integrado de Unity para generar partículas, con este sistema se
modificaron los patrones, forma de la salida, tamaño y duración de dichas
partículas dentro de la escena, para de esta manera añadir los efectos
deseados, como fueron los mares de lava, pilares de fuego y los
propulsores de la plataforma espacial. Pero, estos sistemas de partículas
vienen con texturas blancas las cuales solo sirven de referencia, estas
fueron sustituidas por otras texturas obtenidas de la tienda de Unity de
manera gratuita las cuales transmitían la sensación de fuego, y de esta
manera, permitieron simular los efectos deseados.
107
Para la iluminación de los ambientes se utilizaron los sistemas de
luces de Unity; en particular las Directional Lights, con estas se logra una
iluminación casi total de un área determinada. Para el escenario de la
plataforma espacial se utilizó una Directional Light normal y a su vez
algunos Spot Lights para resaltar algunas áreas en particular dentro de la
plataforma, como los rieles que conducen las entradas; en el escenario de
lava se utilizó una Directional Light de color anaranjado para dar
la
S
O
D
VA
sensación de calor que causa la lava que se encuentra distribuida por
4.5.
O
H
C
E
ER
CODIFICACIÓN
D
R
SE
E
R
S
todo el mapa.
Con el diseño ya definido, se procede a implementar las
herramientas de desarrollo para codificar las instrucciones necesarias
para llevar el diseño a la realidad. Por medio de sprints pertenecientes a
la metodología Scrum, se comenzó a desarrollar el proyecto partiendo
desde la parte lógica hasta la gráfica. La culminación de esta fase
constituye el cumplimiento del objetivo dirigido a la codificación de las
instrucciones.
108
4.5.1. CODIFICACIÓN DEL SERVIDOR DEL JUEGO
Para este proyecto se implementó lenguaje PHP como lenguaje de
servidor, primeramente se desarrolló una clase llamada PhpPDBC.php
que gestionara la conexión con la base de datos, esta cuenta con los
métodos conectar(), query() y destruir(), el método conectar() utiliza la
S
O
D
VA
instrucción “pg_connect("host=$this->host port=$this->port dbname=$this-
ER
S
E
R
establecidos dentro de la misma,S
para
el método query() se utilizó la
O
H$Consulta)” siendo $Valor la conexión a la
C
instrucción “pg_query($Valor,
E
ER
base de D
datos realizada con el método conectar() y $Consulta el query
>db user=$this->user password=$this->pass");” mediante la cual se
realiza la conexión con la base de datos según los parámetros
escrito en lenguaje SQL en formato String, el método destruir() ejecuta la
sentencia pg_close() la cual cierra la conexión realizada.
Una vez terminada la clase PhpPDBC.php se creó una clase
denominada Constantes, esta almacena datos constantes compartidos
por todos los scripts del servidor como por ejemplo los atributos para la
conexión a la base de datos, en total se disponía de 5 constantes:
• define("DB","fallstar_world_db");
• define("SERVIDOR","localhost");
• define("PUERTO","5432");
• define("USER","postgres");
• define("PASS","daniel230394leo");
Posteriormente se fueron desarrollando scripts encargados de
ejecutar determinadas tareas, mayormente de lectura y escritura en la
base de datos.
109
4.5.2. CODIFICACIÓN DE LA APLICACIÓN WEB
Una vez culminada la codificación general del servidor se procedió
a codificar la aplicación web según los parámetros establecidos por el
modelo vista controlador aplicado en el Framework AngularJS, siguiendo
el diseño planteado anteriormente se creó el proyecto de la Aplicación
Web de manera modular, de manera que cada módulo posea una vista y
S
O
D
VA
un controlador asignados, estas vistas serian desplegadas en la página
ER
S
E
R
despliegue de la aplicación Web, estos
son:
S
O
H
C
<header ng-include="'templates/nav.html'"></header>
E
R
DE
<div ui-view></div>
según el usuario las solicite, apegado al modelo de las SPA, la página
principal index.html contiene los 3 elementos fundamentales para el
<footer ng-include="'templates/footer.html'"></footer>
La etiqueta <header> es en la cual mediante la directiva ng-include
se carga el fragmento correspondiente a la barra principal de navegación
contenida dentro de nav.html, donde se encuentran los enlaces al Login,
sigin, about, todos estos organizados dentro de una etiqueta <ul>, luego
de este se colocó un <div> con la directiva ui-view, que es la encargada
de gestionar el enrutamiento dinámico entre los módulos de la aplicación
de manera asíncrona, mediante AJAX, y finalmente una etiqueta <footer>
en la cual se carga el fragmento informativo sobre los derechos de la
página, esto se realiza igualmente mediante la directiva ng-include.
A continuación se describen los módulos de la aplicación web:
110
Módulo Login:
En esta pantalla el usuario podrá hacer Login para ingresar a la
aplicación. Si el usuario no existe, se emitirá un mensaje informando al
usuario para que se registre. Cuando se pulsa el botón Login se llamara
al loginCtrl.js, que es el controlador encargado de manipular la vista del
Login.html, dentro de este controlador se valida que los campos estén
S
O
D
Ade datos, de
encargado de verificar si el usuario existe dentro de la base
V
R
E la cantidad de
Sunidades,
existir retorna el id del jugador, el color
deE
sus
R
S
Units Points y la cantidadH
deO
dinero que posee, todo estos datos se
C de no existir el usuario se retorna “Error de
E
R
retorna en forma
de
JSON,
DE
llenos y se envía la información al script fallstar_world_login.php
Usuario o Contraseña”.
Figura Nº 40: Login.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
111
Módulo Sign In:
En esta pantalla el usuario podrá hacer signIn dentro de la
aplicación, llenando los campos solicitados, una vez presionado el botón
signIn, se llama al controlador siginCtrl.js, este envía todos los datos
introducidos en formato JSON al script fallstar_world_sigin.php, que es el
S
O
D
VA
encargado de escribir en la tabla usuarios y crear el nuevo registro.
O
D
H
C
E
ER
R
SE
E
R
S
Figura Nº 41: SignIn.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
112
Modulo Ver Record:
En este módulo el usuario podrá ver el Record de todas las
partidas jugadas dentro de una tabla, la misma será generada
dinámicamente por el controller recordCtrl.js dependiendo del usuario con
S
O
D
VA
el que se hizo login, los datos desplegados se obtienen del script
O
D
H
C
E
ER
R
SE
E
R
S
fallstar_world_record.php en formato JSON.
Figura Nº 42: Record.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
113
Modulo Ver Unidades:
En este módulo el usuario podrá ver todas las unidades con las que
el juego cuenta actualmente y su variedad de colores, los datos
desplegados
se
obtienen
del
script
fallstar_world_UnidadesDisponibles.php en formato JSON y se despliegan
a través del controller UnidadesDisponiblesCtrl.js.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 43: Ver unidades.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
114
Modulo Ver Unidades Propias:
En este módulo el usuario podrá ver todas las unidades que ha
adquirido y también utilizar los Units Points obtenidos en mejorar los
atributos de sus unidades, los datos desplegados se obtienen del script
fallstar_world_UnidadesPropias.php en formato JSON y se despliegan a
través del controller UnidadesPropiasCtrl.js.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 44: Unidades Propias.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
115
Modulo Comprar Unidades:
En este módulo el usuario podrá adquirir las unidades que desee a
cambio de los créditos que posea, la funcionalidad general de este
módulo se basa en la de un carrito de compras, del lado izquierdo de la
pantalla se encuentran todas las unidades disponibles para comprar,
debajo de cada imagen se encuentra un botón que al ser presionado
S
O
D
A puede
de esa unidad dentro del carrito, del lado derecho del
módulo
V
R
SEdel carrito y el botón
observarse una tabla que muestra elR
contenido
E
Sllamando al cartCtrl.js, y enviando la
O
comprar que finaliza la transacción,
H
C al script fallstar_world_playerUnit.php.
E
R
información mediante
JSON
DE
incluye la unidad al carrito, si vuelve a ser presionado aumenta la cantidad
Figura Nº 45: Comprar Unidades.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
116
Modulo Ver Mapas
En este módulo el usuario podrá ver todos los mapas con los que el
juego cuenta actualmente y una descripción de los mismos, los datos
desplegados se obtienen del script fallstar_world_map.php en formato
JSON y se despliegan a través del controller mapCtrl.js.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 46: Ver Mapas.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
117
Modulo Ver tipos de Batalla:
En este módulo el usuario podrá ver todos los tipos de batalla con
los que el juego cuenta actualmente y una descripción de los mismos, los
datos desplegados se obtienen de manera estática de los recursos
multimedia del proyecto y se despliegan en la vista denominada
verBattleTipes.html.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Figura Nº 47: Tipo de Batalla.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
118
4.5.3. CODIFICACIÓN DEL JUEGO
El proceso de codificación del juego se hizo de manera modular,
siguiendo la metodología Scrum que especifica que se deben realizar
diferentes partes del código dependiendo de la importancia de cada una
la cual debe ser establecida previamente y siguiendo un orden de tareas
asignadas las cuales deben ser completadas durante cada sprint que se
realice.
S
O
D
VA
ER
S
E
R
del movimientos de las unidadesS
dentro
del grid, esto implica tener el
O
H
Cen la escena en el cual se puedan desplazar las
script que genere elE
grid
R
E
unidades,D
un método que permita traducir coordenadas entre el grid y las
El primer módulo consiste en la creación de los scripts encargados
coordenadas que trabaja normalmente Unity, crear una animación en la
cual se pueda indicar punto de inicio de la unidad, punto final de destino,
el tiempo de la animación para el traslado de la unidad, y limitar el
movimiento de cada unidad a cierta cantidad de cuadros de manera que
no pueda recorrer todo el grid en un solo turno.
Para la creación del grid, utilizando el Grid Framework se puede
crear un grid con el editor visual, esto crea un gameObject sencillo el cual
posee el un Script llamado GFRectGrid, este se encarga de crear el grid
en la escena y da las opciones de configurar sus dimensiones en el editor
visual de Unity; y además, contiene métodos adicionales que permiten
utilizar el grid de manera dinámica y cómoda.
Para establecer las rutas que se utilizaran para mover una unidad
de un espacio del grid al otro, se requiere de hacer click en la unidad que
se desee mover, tomar la ubicación y que sea almacenada en una
variable. Luego hacer click en el botón de la UI que dice Move para
activar el booleano que habilitara el movimiento, y posteriormente hacer
119
click en algún lugar que se desee dentro del grid, guardando dicho valor
en una variable.
Para la realización de todos estos procesos fue necesario crear
una serie de métodos los cuales trabajaran en conjunto para lograr
desplazar la unidad de un lugar al otro. En primer lugar, los clicks
normalmente devuelven una posición basada en la escena como tal, no
S
O
D
A esos
a uno relativo al grid para el manejo de las funciones que
requerirán
V
R
E de código:
Sporción
valores. Para realizar esto, se utilizó la siguiente
E
R
S
O
H
C
E
R
DE
una posición relativa al grid, por lo cual es necesario convertir dicho valor
if (Input.GetMouseButtonDown (0)) {
RaycastHit hit;
Ray ray = Camera.main.ScreenPointToRay (Input.mousePosition);
if (Physics.Raycast (ray, out hit) && hit.collider.name=="Grid") {
newPoint = grid.WorldToGrid (hit.point);
roamGrid.PF = newPoint;
}
}
Este método recibe el click del jugador, lanza una línea invisible
desde la cámara principal, si consigue algún objeto con un collider que
tenga el nombre “Grid”, obtendrá la coordenada de colisión. Esta
coordenada la traduce a un valor relativo al grid, y se lo asigna a una
variable. Este método se aplica igual a las unidades, pero en vez de
buscar por el nombre “Grid”, lo realiza por el nombre “Unit”.
Las dos ubicaciones que regresa el método anterior están
referenciadas como un plano cartesiano, por ende, para realizar una
comparación que será necesaria para verificar si la unidad será capaz o
no de moverse hasta cierto punto dentro del grid es necesario convertir a
ese valor a uno comparable con un integer que será el límite de cuadros
120
que podrá moverse una unidad por turno. Para ello se utiliza la siguiente
sección de código:
float converter (Vector3 spot1, Vector3 spot2) {
return (Mathf.Abs (spot1.x - spot2.x) + Mathf.Abs (spot1.z - spot2.z));
}
Y para verificar si una unidad podrá realizar la traslación, se utiliza la siguiente porción
de código:
S
O
D
VA
counter = converter (PF, PI);
if (counter <= distaciaUnidad) {
}
O
H
C
E
ER
D
R
SE
E
R
S
MoveUnit ();
El método para mover a la unidad consiste en verificar si es el turno
de la unidad para habilitar su movimiento, luego utiliza un método de
movimiento de iTween que permite desplazar un gameObject de manera
directa a un sitio con alguna animación en particular (se utilizó el estilo de
animación standard) realizándose en algún tiempo dado, y luego se
deshabilita el turno de la unidad para que esta no pueda moverse
después. El código es el siguiente:
void MoveUnit () {
if (myTurn) {
iTween.MoveTo (gameObject, goal, roamingSpeed);
//GameU.myButton3.interactable = false;
myTurn=false;
}
Una vez terminados las funciones para realizar los movimientos de
las unidades dentro del grid, se procedió a crear las funciones de recibir
daño y las funciones de muerte de las unidades. La función de recibir
daño es una función con un solo parámetro de tipo int, la función consiste
en restar el daño recibido como parámetro menos la defensa de la unidad
atacada, si el resultado es un numero positivo, le reduce a la unidad
121
atacada su vida, y si la vida de la unidad es igual o menor a 0, se
ejecutara el método de morir. Todo esto se realizó en el siguiente código:
public void ReceiveDamage(int damage) {
Debug.Log ("damage" + damage);
dmgResult = damage - def;
Debug.Log ("dmgResult: " + dmgResult);
if (dmgResult > 0) {
S
O
D
VA
hp -= dmgResult;
Debug.Log ("hp: " + hp);
O
H
C
E
ER
if (hp <= 0) {
Dead ();
D
}
}
R
SE
E
R
S
}
La función de morir es una función la cual instancia un sistema de
partículas de una explosión para simular la destrucción de la unidad, y
mientras se realiza la explosión se destruye la unidad. El código de la
función es el siguiente:
public void Dead () {
if (gameObject! =null) {
Instantiate (Explosion, gameObject.transform.position,
gameObject.transform.rotation);
Destroy (gameObject);
isSelected = false;
}
}
Para la función de atacar, se utiliza un método el cual verifica si el
usuario acierta el ataque sobre la otra unidad, después de eso verifica si
la unidad acierta un ataque crítico, y según sea el resultado llama al
método de recibir daño con el daño normal que puede ocasionar la unidad
122
o haciendo un daño crítico. Además, se encarga de colocar en false
algunos parámetros como si es seleccionado o si ya tiene la capacidad de
atacar, de tal manera que no ataque más de un vez por turno. El código
del método de ataque es el siguiente:
public void Attack () {
if (canAttack) {
if (Random.Range (0.0F, 1.0F) <= hitChance) {
if (Random.Range (0.0F, 1.0F) <= critChance) {
int critAttack = atk * 3;
ReceiveDamage (critAttack);
return;
}
ReceiveDamage (atk);
return;
}
canAttack = false;
myButton.interactable = false;
myButton.onClick.RemoveAllListeners ();
myButton.onClick.AddListener (() => {
Attack ();
});
isSelected=false;
}
}
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Una vez terminadas las funciones que se encargarán de la
jugabilidad en general, se pasó a crear un sistema de Lobby que permitirá
a los usuarios crear salas en las cuales podrán conectarse otros
jugadores, y que posteriormente permitirá cargar el escenario que se haya
elegido para que los jugadores puedan jugar entre ellos. El script principal
se encarga de gestionar 2 tipos de usuarios, un MasterClients que será el
que cree la sala, el que decidirá el nivel donde se jugara y el que dira
cuando empieza la partida. El otro tipo de son los clientes normales, los
cuales son los que simplemente entran en la salas. La asignación de
estos clientes se hace por orden de entrada, el primero en entrar a una
sala (que es el que la crea) es el cliente maestro, todos los demás que
entres después de él en esa sala serán clientes normales. Las salas están
123
configuradas para que solo se permitan dos usuarios en cada una, y de
que una vez una partida empiece no se pueda acceder a ella. El script
principal que se encarga de gestionar todo lo mencionado anteriormente
es el siguiente:
public class Example3_Menu_Lobby: Photon.MonoBehaviour {
public int selGridInt = 0;
public string[] selStrings = new string[] { "Space Station 1", "Space Station 2", "Lava
World 1", "Lava World 2" };
public GUISkin skin;
public static Example3_Menu_Lobby SP;
private bool launchingGame = false;
private bool showMenu = false;
private int serverMaxPlayers = 2;
private string serverTitle = "Loading..";
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
void Awake() {
SP = this;
showMenu = false;
}
public void EnableLobby(){
launchingGame = false;
showMenu = true;
}
void OnGUI() {
if (!showMenu) {
return;
}
//Back to main menu
if (GUI.Button(new Rect(40, 10, 150, 20), "Back to main menu")) {
LeaveLobby();
}
if (launchingGame) {
LaunchingGameGUI();
}
else if (!PhotonNetwork.isMasterClient &&
!PhotonNetwork.isNonMasterClientInRoom) {
//First set player count, server name and password option
CreationSettings();
}
else {
//Show the lobby
ShowLobby();
124
}
}
void LeaveLobby() {
//Disconnect fdrom host, or shutduwn host
PhotonNetwork.LeaveRoom();
Example3_Menu.SP.OpenMenu("multiplayer");
showMenu = false;
}
private string hostSetting_title = "No server title";
private int hostSetting_players = 2;
S
O
D
VA
R
SE
E
R
S
void CreationSettings() {
GUI.BeginGroup(new Rect(Screen.width / 2 - 175, Screen.height / 2 - 75 - 50, 500,
250));
GUI.Box(new Rect(0, 0, 350, 150), "Server options");
O
H
C
E
ER
D
GUI.Label(new Rect(10, 20, 150, 20), "Server title");
hostSetting_title = GUI.TextField(new Rect(175, 20, 160, 20), hostSetting_title);
selGridInt = GUI.SelectionGrid(new Rect(25, 50, 180, 100), selGridInt, selStrings, 1);
if (GUI.Button(new Rect(240, 125, 100, 20), "Go to lobby")) {
StartHost(hostSetting_players, hostSetting_title);
}
GUI.EndGroup();
}
void StartHost(int players, string serverName) {
players = Mathf.Clamp(players, 1, 64);
serverTitle = serverName;
PhotonNetwork.CreateRoom(serverName, true, true, players);
}
void ShowLobby() {
string players = "";
int currentPlayerCount = 0;
foreach (PhotonPlayer playerInstance in PhotonNetwork.playerList) {
players = playerInstance.name + "\n" + players;
currentPlayerCount++;
}
GUI.BeginGroup(new Rect(Screen.width / 2 - 200, Screen.height / 2 - 200, 400,
180));
GUI.Box(new Rect(0, 0, 400, 200), "Game lobby");
GUI.Label(new Rect(10, 40, 150, 20), "Server title");
GUI.Label(new Rect(150, 40, 100, 100), serverTitle);
GUI.Label(new Rect(10, 60, 150, 20), "Players");
125
GUI.Label(new Rect(150, 60, 100, 100), currentPlayerCount + "/" +
serverMaxPlayers);
GUI.Label(new Rect(10, 80, 150, 20), "Current players");
GUI.Label(new Rect(150, 80, 100, 100), players);
GUI.Label(new Rect(10, 120, 150, 20), "Selected Map");
GUI.Label(new Rect(150, 120, 100, 100), selStrings[selGridInt]);
if (PhotonNetwork.isMasterClient) {
if (GUI.Button(new Rect(25, 140, 150, 20), "Start the game")) {
HostLaunchGame();
}
}
else {
GUI.Label(new Rect(25, 140, 200, 40), "Waiting for the server to start the
game..");
}
GUI.EndGroup();
}
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
void OnCreatedRoom() {
//Called on masterclient
photonView.RPC("SetServerSettings", PhotonTargets.OthersBuffered,
hostSetting_title);
}
void OnMasterClientSwitched(PhotonPlayer newMaster) {
Debug.Log("The old masterclient left, we have a new masterclient: " + newMaster);
if (PhotonNetwork.player == newMaster) {
photonView.RPC("SetServerSettings", PhotonTargets.OthersBuffered,
serverTitle);
}
}
[RPC]
void SetServerSettings(string newSrverTitle) {
serverTitle = newSrverTitle;
}
void HostLaunchGame() {
if (!PhotonNetwork.isMasterClient) {
return;
}
//Close the room for future connections
PhotonNetwork.room.open = false;
PhotonNetwork.room.visible = false;
photonView.RPC("LaunchGame", PhotonTargets.All);
}
126
[RPC]
void LaunchGame() {
PhotonNetwork.isMessageQueueRunning = false;
launchingGame = true;
}
void LaunchingGameGUI() {
//Show loading progress,
GUI.Box(new Rect(Screen.width / 4 + 180, Screen.height / 2 - 30, 280, 50), "");
if (Application.CanStreamedLevelBeLoaded((Application.loadedLevel + 1))) {
GUI.Label(new Rect(Screen.width / 4 + 200, Screen.height / 2 - 25, 285, 150),
"Loaded, starting the game!");
if (selGridInt == 0){
Application.LoadLevel(("Battle Scene 1 Platform (no obs)"));
}
if (selGridInt == 1){
Application.LoadLevel(("Battle Scene 1 Platform (with obs)"));
}
if (selGridInt == 2){
Application.LoadLevel(("Battle Scene 2 LavaField (no obs)"));
}
if (selGridInt == 3){
Application.LoadLevel(("Battle Scene 2 LavaFiled (with obs)"));
}
}
else {
GUI.Label(new Rect(Screen.width / 4 + 200, Screen.height / 2 - 25, 285, 150),
"Starting..Loading the game: " +
Mathf.Floor(Application.GetStreamProgressForLevel((Application.loadedLevel + 1)) *
100) + " %");
}
}
}
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
Finalmente, dentro de cada una de las escenas que se carguen
dentro del juego, se agregó un script se en encarga de gestionar los
jugadores que se encuentran dentro de la sala, mantiene la conexión
entre los dos, muestra cuando se conectan y cuantos jugadores se
encuentran dentro de la sala y muestra la latencia del jugador. Y además
muestra botones los cuales permiten regresar al menú principal del juego.
Ese script es el siguiente:
127
void Awake() {
//RE-enable the network messages now that we've loaded the right level
PhotonNetwork.isMessageQueueRunning = true;
}
void OnGUI() {
if (PhotonNetwork.connectionState == ConnectionState.Disconnected) {
//We are currently disconnected: Not a client or host
GUILayout.Label("Connection status: We've (been) disconnected");
if (GUILayout.Button("Back to main menu")) {
Application.LoadLevel(("Example3_lobbymenu"));
}
}
else {
//We've got a connection(s)!
if (PhotonNetwork.connectionState == ConnectionState.Connecting) {
GUILayout.Label("Connection status: Connecting");
}
else {
GUILayout.Label("Connection status: Server!");
GUILayout.Label("Connections: " + PhotonNetwork.playerList.Length);
if (PhotonNetwork.playerList.Length >= 1) {
GUILayout.Label("Ping to first player: " + PhotonNetwork.GetPing());
}
}
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
if (GUILayout.Button("Disconnect")) {
PhotonNetwork.Disconnect();
}
}
}
//Client&Server
void OnDisconnectedFromPhoton() {
Debug.Log("Lost connection to the server");
}
//Server functions called by Unity
void OnPhotonPlayerConnected(PhotonPlayer player) {
Debug.Log("Player connected from: " + player);
}
void OnPhotonPlayerDisconnected(PhotonPlayer player) {
Debug.Log("Player disconnected from: " + player); }
Para el manejo de la sincronización de las unidades dentro del
juego, cada prefab de las unidades utiliza un script proveniente de Photon
llamado PhotonView, con este script puesto, todos los jugadores que
128
estén en una partida podrán ser capaces de observar el objeto y ver como
interactúa con su entorno. Para identificar a quien le pertenece cada
objeto dentro del juego con un PhotonView, cada uno posee un id el cual
oscila entre 1000 y 1999 para el primer usuario, entre 2000 y 2999 para el
segundo usuario, y así sucesivamente; por ende, cada usuario puede
poseer hasta 1000 elementos. Y para lograr que los métodos utilizados en
una unidad puedan afectar o ser vistos por otra, es necesario llamarlos
S
O
D
puede ejecutar un método en un cliente y puede ser visto
oA
puede afectar
V
R
E
Smisma sala, para usarlos
a cualquier otro cliente que se encuentre
en
la
E
R
S
O
antes del nombre del método
se
coloca [RPC] y al momento de hacer una
H
Cse desea que afecte a otros se utiliza de esta
E
R
llamada al método
que
E
D
manera:
utilizando los llamados RPC (Remote Procedure Call), con estos, se
photonView.RPC ("LaunchGame", PhotonTargets.All);
Se utiliza la función “photonView.RPC” en la cual se utiliza como
parámetros el nombre del método que se desee ejecutar y el o los
objetivos que serán capaces de detectar dicha función.
Para el manejo de la conexión con base de datos, se utiliza una
clase llamada DBConnect en la cual se tiene una URL con la cual se
conectara a un archivo PHP que maneja todas las conexiones con base
de datos, y se tiene un método Connect al cual se le pasan en forma de
Json la información el archivo PHP debe recibir y él se encargará de
manejar toda esa información de manera transparente para el juego. Para
el manejo de los JSON, se utiliza un código similar al presentado a
continuación:
129
var jsonPrueba = JsonConvert.SerializeObject (new {nick = formNick.Trim (), pass =
formPassword.Trim ()},
new JsonSerializerSettings () {Formatting = Newtonsoft.Json.Formatting.None});
using (WebClient wc = new WebClient ())
{
wc.Headers [HttpRequestHeader.ContentType] = "application/x-www-formurlencoded";
string HtmlResult = wc.UploadString (url, jsonPrueba);
return HtmlResult;
4.6.
EVALUACIÓN DEL SISTEMA
Para determinar la efectividad
S
O
D
A
V
y el alcance
del software
R
E
S
E
R
S
HdeO
del sistema con la finalidad
detectar imperfecciones y posibles errores
C
E
R
E corregirlos de manera efectiva.
a tiempo D
y poder
desarrollado, realizaron pruebas a lo largo de cada una de las iteraciones
4.6.1. PRUEBA DE ACEPTACIÓN
Fine (2002) define la prueba de aceptación como una técnica para
medir la relación entre el usuario y el sistema haciendo énfasis en
factores como la adaptabilidad, rapidez del aprendizaje y la aceptación del
diseño por parte de usuario con las operaciones del sistema. En efecto,
las pruebas de aceptación marcan el camino a seguir en cada iteración,
indicándole al equipo de desarrollo hacia donde ir y en qué puntos o
funcionalidades se debe poner el mayor esfuerzo y atención.
Dado que el presente trabajo de investigación no posee una
muestra a analizar sino una unidad de análisis, las pruebas de aceptación
se aplicaron a diversos usuarios que tuvieron acceso al juego mediante el
uso de un computador.
4.6.1.1.
DISEÑO DE LA PRUEBA DE ACEPTACIÓN
Para el presente proyecto se manejó el test de aceptación como un
cuestionario aplicado a los usuarios que tuvieron acceso al juego, para
130
este caso, un total de 20 usuarios. Con esta prueba se buscó determinar
factores básicos de la integración del usuario con el juego, basándose en
resultados ponderados del uno (1) al cinco (5).
Las condiciones de evaluación fueron explícitas en el cuestionario
el cual estuvo diseñado como se muestra a continuación:
S
O
D
A
ESTRATEGIA POR TURNOS CON CAPACIDAD MULTIJUGADOR
V
R
SE
E
R
S
Test de Aceptación HO
C
E
R
Instrucciones
DE
VIDEOJUEGO DE NAVEGADOR WEB DE GÉNERO
Antes de realizar el siguiente test, por favor asegúrese de haber
realizado todas las operaciones disponibles en el videojuego tantas veces
como desee. Se le realizarán una serie de preguntas con relación al nivel
de aceptación que usted tiene ante la aplicación desarrollada.
Las
respuestas varían en valores numéricos del uno (1) al cinco (5), siendo
uno (1) “Deficiente”, dos (2) “Regular”, tres (3) “Bueno” y cuatro (4) “Muy
Bueno”. Asegúrese de leer cuidadosamente cada pregunta y en caso de
no entender consultar con algún miembro del equipo de desarrollo.
Gracias por su apoyo.
1. Evalúe la interfaz gráfica del juego
1
2
3
4
2. Evalúe el Diseño de las Unidades
1
2
3
3. Evalúe los Mapas
4
131
1
2
3
4
4. Evalúe la jugabilidad
1
2
3
4
5. Evalúe la Aplicación Web
1
2
3
4
S
O
D
6. Evalúe la fluidez en las interfaces del juego VA
ER
S
1
2
3
4
E
R
S
HO
C
E
R la fluidez en las interfaces de la Aplicación Web
7. E
Evalúe
D
1
2
3
4
4.6.1.2.
RESULTADO DE LA PRUEBA DE ACEPTACIÓN
Una vez aplicado el test de aceptación a los usuarios que
accedieron al juego, se procedieron a analizar los resultados de cada
pregunta de manera individual, identificando los resultados por usuario y
finalmente promediando el nivel de aceptación del sistema en cada uno
de estos aspectos. Se considera como buena aceptación de más de tres
y medio (3.5) y poca aceptación las calificaciones inferiores a ésta.
Los resultados del test se muestran a continuación:
En el Gráfico Nº 1 se puede observar que de los 20 usuarios que
probaron el juego, 5 indicaron las interfaces del juego como “muy buena”,
132
8 como “bueno”, 4 usuarios señalaron que era “regular” y un usuario
señaló que eran “deficientes”.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
En el Gráfico Nº 2 se puede observar que de los 20 usuarios que
probaron el juego, 2 usuarios señalaron el diseño de las unidades como
“muy bueno”, 13 “bueno” y 5 usuarios indicaron que era “regular”.
133
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
En el Gráfico Nº 3 se puede observar que de los 20 usuarios que
probaron el juego, 6 usuarios señalaron el diseño de los mapas como
“muy bueno”, 8 “bueno”, 4 usuarios indicaron que era “regular” y 2
usuarios señalaron que era “deficiente”.
134
En el Gráfico Nº 4 se puede observar que de los 20 usuarios que
probaron el juego, 1 usuario evaluó la jugabilidad como “muy buena”, 16
“buena” y 3 usuarios indicaron que era “regular”.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
En el Gráfico Nº 5 se puede observar que de los 20 usuarios que
probaron el juego, 3 usuarios evaluaron la Aplicación Web como “muy
buena”, 10 “buena”, 3 usuarios indicaron que era “regular” y 1 usuario
señalo que era “deficiente”.
135
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
En el Gráfico Nº 6 se puede observar que de los 20 usuarios que
probaron el juego, 2 usuarios evaluaron la fluidez en las interfaces de la
Aplicación Web como “muy buena”, 14 “buena”, 3 usuarios indicaron que
era “regular” y 1 usuario señalo que era “deficiente”.
136
En el Gráfico Nº 7 se puede observar que de los 20 usuarios que
probaron el juego, 4 usuarios evaluaron la fluidez en las interfaces del
juego como “muy buena”, 10 “buena”, 4 usuarios indicaron que era
“regular” y 2 usuarios señalaron que era “deficiente”.
D
R
SE
E
R
S
O
H
C
E
ER
S
O
D
VA
4.6.2. PRUEBA DE ESTRÉS
Esta prueba se utiliza normalmente para romper el sistema. Se va
doblando el número de usuarios que se agregan al sistema y se ejecuta
una prueba de carga hasta que se rompe. Este tipo de prueba se realiza
para determinar la solidez del sistema en los momentos de carga extrema
y ayuda a los desarrolladores a determinar si el sistema rendirá lo
suficiente en caso de que la carga real supere a la carga esperada.
Para el presente proyecto, se aplicó una prueba de estrés haciendo
múltiples solicitudes de registro de usuarios e inicio de sesión, además de
guardado y cargado de una partida respectivamente.
137
4.6.2.1.
RESULTADO DE LA PRUEBA DE ESTRÉS
Resultados de la Prueba de Estrés para el Inicio de Sesión:
Nº de usuarios
Latencia
S
O
D
115msVA
R
ESE
10
15
110ms
R
S
HO
C
E
R
DE
20
118ms
Tabla Nº 1: Resultados de la Prueba de Estrés para el Inicio de Sesión.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Resultados de la Prueba de Estrés para el Registro de Usuarios:
Nº de usuarios
Latencia
10
130ms
15
140ms
20
150ms
Tabla Nº 2: Resultados de la Prueba de Estrés para el Registro de Usuarios.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
Resultados de la Prueba de Estrés de latencia dentro de las
partidas:
138
Nº de usuarios
Latencia
10
150ms
15
180ms
20
200ms
S
O
D
VA
Tabla Nº 3: Resultados de la Prueba de Estrés de latencia dentro de las partidas.
Fuente: Carlos Sotolongo y Leonardo Fuenmayor
O
H
C
E
ER
R
SE
E
R
S
Según Nielsen (1996) existen tres límites importantes en el tiempo de
D
respuesta:
-
0,1 segundo: es el límite en el cual el usuario siente que está
“manipulando” los objetos desde la interfaz de usuario.
-
1 segundo: es el límite en el cual el usuario siente que está
navegando libremente sin esperar demasiado una respuesta del
servidor.
-
10 segundos: es el límite en el cual se pierde la atención del
usuario, si la respuesta tarda más de 10 segundos se deberá
indicar algún mecanismo por el cual el usuario pueda interrumpir la
operación.
Dado que los resultados de tiempo de respuesta arrojaron
unidades de tiempo aceptables en concordancia con la anterior
clasificación, se puede decir el tiempo de respuesta garantiza en un alto
porcentaje la estabilidad y solidez de la aplicación.
139
CONCLUSIONES
Se realizó un proceso de recolección de información mediante la
consulta de manuales y textos referenciales, los cuales permitieron
determinar los requerimientos técnicos y operativos para el desarrollo y
funcionamiento del videojuego de estrategia por turnos, cumpliendo con el
S
O
D
A
V
Se realizó una planificación general del proyecto
de
desarrollo de la
R
SE
E
aplicación involucrando prácticas propias
de
la metodología de desarrollo
R
S distribuyendo el desarrollo de
O
H
SCRUM, como el Release
Planning,
C
E
R
Eperíodo determinado. Esto permitió dedicar más tiempo a
módulos D
en un
objetivo de analizar los requerimientos para el desarrollo mismo.
los módulos de mayor prioridad y garantizar la culminación del proyecto
en el tiempo establecido.
Se diseñaron las estructuras de información que abarcan los
diagramas de casos de uso de la aplicación, de modelado de datos, de
entidad relación, de despliegue y de interfaces, de igual forma se diseñó
el videojuego de estrategia, desarrollando los elementos visuales, los
cuales abarcan las unidades y escenarios; así como también la
composición de los elementos multimedia como los sound Effects.
Una vez finalizado el diseño, se procedió a codificar el mismo,
utilizando PHP como lenguaje de servidor y HTML, Javascript, CSS y el
Framework AngularJs para el desarrollo de las interfaces de la aplicación
Web que será utilizada para la gestión de usuarios. Para el desarrollo del
juego de estrategia por turnos se utilizó el motor gráfico Unity, en conjunto
con una serie de pluggins como GridFramework e iTween.
140
Se aplicaron pruebas de aceptación y estrés, planteadas en la
metodología de desarrollo SCRUM, para determinar la aceptación de los
usuarios y la solidez de la aplicación bajo condiciones de evaluación
específicas. Los resultados obtenidos para ambas pruebas fueron
satisfactorios.
S
O
D
A
futuras investigaciones en el área de desarrollo deV
videojuegos
de
R
E
S el uso de diversas
estrategia por turnos. De igual manera,R
seE
demuestra
S
O
herramientas para el desarrollo
de videojuegos como el Motor gráfico
H
EdeCantecedente para trabajos de investigación con
R
Unity. ServiráE
también
D
objetivos similares, así como fuente de consulta para aquellos interesados
Los resultados de este proyecto pueden servir como insumo para
en el ámbito de las nuevas tecnologías orientadas a medios de
entretenimiento.
141
RECOMENDACIONES
En este proyecto de investigación, se plantearon objetivos dirigidos
a la solución de una problemática específica con la implementación de
herramientas determinadas y concluyendo con el desarrollo de una
S
O
D
A
V
complementación de cualquiera de sus aspectos.
Por tanto, a
R
SE para que futuras
E
continuación, se presentan algunas recomendaciones
R
OS
investigaciones tengan C
unaH
guía de posibles mejoras o ampliaciones que
E tratada en la presente investigación.
R
E
podrían partir
de
la
temática
D
aplicación orientada a satisfacer necesidades puntuales. Sin embargo,
este proyecto abre muchas posibilidades para el mejoramiento o
-
Desarrollar más elementos dentro de la jugabilidad, como
habilidades especiales, Perks y nuevos tipos de Batalla
-
Desarrollar una mayor cantidad de elementos disponibles para
el usuario, como mapas y unidades.
-
Implementar un servidor que permita la conexión simultanea de
más de 20 jugadores.
142
REFERENCIAS BIBLIOGRÁFICAS
LIBROS
• Regina Obe y Leo Hsu (2012). PostgreSQL Up and running.
O’Reilly
• Brad Green y Shyam Sehadri (2013). AngularJS. O’Reilly.
• Alan Thorn (2013). Learn Unity 2D Game Development. APRESS.
S
O
D
VA
• Sue Blackman (2013). Beginning 3D Game Development with Unity
R
E
S
E
Shyam Seshadri y Brad Green (2014).
AngularJS Up and Running.
R
S
O’Reilly
HO
C
E
ER y Susan Douglas (2005). Postgres SQL. Sams.
Korry
DDouglas
4. APRESS.
•
•
Segunda Edición.
• Adam Freeman (2014). Pro AngularJS. APRESS.
TRABAJOS DE GRADO
• Igor Galochkin (2013) Implementation of a cross-platform strategy
multiplayer game based on Unity 3D. (tesis de grado) Universidad
de Munich, Alemania.
• Pan Dam Tien (2013) Android Android Simulation videogame
based on Unity 3D engine. (tesis de grado) Vietnam National
University, Vietnam.
• David Lopez (2013) Study of multiplayer features for Unity
Applications. (tesis de maestria) Universidad Politecnica de
Catalonia, España.
• Jason Dansie (2013) Game development in Unity. (tesis de grado)
Helsinki Metropolia University of Applied Sciences, Finlandia.
• Rainier Araujo, Miguel Peña (2012) Sistema de información web
para a gestión de pólizas para corredores de seguros con interfaz
143
para dispositivos móviles. (tesis de grado) Universidad Rafael
Urdaneta, Venezuela.
• G. Frassca (2001) Videogames of the oppressed: Videogames as a
means for critical thinking and debate. (Magister de diseño de
información y tecnología) Georgia Institute of Technology. Estados
Unidos.
FUENTES ELECTRÓNICAS
•
•
S
O
D
VA
R
E
S
E
http://www.statisticbrain.com/blizzard-entertainment-statistics/
R
S
http://www.statisticbrain.com/call-of-duty-franchise-game-salesHO
C
E
statistics/
DER
• http://vgsales.wikia.com/wiki/Best_selling_Square-Enix_games
• http://vgsales.wikia.com/wiki/Best_selling_Microsoft_games
• http://www.eluniversal.com/vida/121104/videojuegos-en-fuga
• http://www.jesperjuul.net/text/gameplayerworld/
ARTÍCULOS DIGITALES
• Simone Belli y Cristian López Raventós. (2008). Breve historia de
los videojuegos.
http://psicologiasocial.uab.es/athenea/index.php/atheneaDigital/arti
cle/view/570
• J. L. González Sánchez, N. Padilla Zea, F. L. Gutiérrez, M. J.
Cabrera. (s.f) De la Usabilidad a la Jugabilidad: Diseño de
Videojuegos Centrado en el Jugador.
http://aipo.es/articulos/2/10.pdf