Frozen Fury
Versión Beta
Plantilla de GDD por Alberto Blanco, Cosmic Works Studios.
Frozen Fury es un juego que bebe del género Tower Defense donde el usuario tendrá que luchar contra hordas de enemigos que intentarán llegar a un punto que debe ser defendido. Para defenderse de la horda, el usuario podrá utilizar diversas infraestructuras típicas de juegos de este estilo (como torres con ballestas, torres eléctricas, torres con dragones, muros, trampas de pinchos…) que podrán ser mejoradas para mejorar su eficacia.
Un joven heladero intenta crear el mejor helado casero del mundo, pero siente que los ingredientes industriales de hoy en día no le permiten crear el helado casero definitivo, así que decide tunear su camión de helados y convertirlo en una máquina del tiempo para visitar a Leonardo da Vinci y robarle su cuaderno, donde se dice que describió en su momento el ingrediente final para el Gelato de Dios, un helado tan majestuoso que permitía ver como era el cielo.
Sin embargo, lo que no se esperaba es que su máquina del tiempo estuviese defectuosa y en vez de llevarlo directamente a su destino, le hacía viajar por diferentes épocas y universos hasta llegar finalmente a la Italia Renacentista.
En ese viaje, el heladero robará diferentes recursos para conseguir crear su helado definitivo, encontrándose siempre que la gente a la que se lo roba no permitirá tan fácilmente que se salga con la suya…
Se quiere generar una sensación de diversión y entretenimiento indefinido en los clientes que favorezca la acogida del videojuego entre el público.
Se debe crear un buen producto con el que el equipo y los diferentes contribuyentes del mismo estén satisfechos.
El público objetivo del videojuego está conformado por jugadores casuales que no dedican mucho tiempo a diario a jugar a videojuegos y por jugadores que sí basan su ocio en este sector.
Se dirige a un público casual debido a que las partidas no tienen una duración determinada, dependiendo esta de la destreza y habilidad del usuario, y se pueden pausar para ser continuadas en cualquier otro momento. Además, permite disfrutar de una plena experiencia de juego independientemente de la cantidad de horas disponibles por el jugador. También se dirige a jugadores experimentados y consumidores de juegos de estrategia en tiempo real, ofreciendo características novedosas poco vistas en productos relacionados del mismo género.
El juego está desarrollado para plataformas de distribución digitales como Steam o Play Store, y plataformas de distribución digitales web como Itch.io. Las plataformas físicas objetivo del videojuego son el ordenador y el teléfono móvil.
Frozen Fury seguirá una sola estrategia principal de monetización una vez publicado el producto. La característica principal del videojuego es que se trata de un Free to Play. Los usuarios no están obligados a gastar dinero en ningún complemento, o producto adicional que ofrezca el juego.
La estrategia de monetización es la siguiente:
- Complementos adicionales: En caso de que el producto vea cumplidos sus objetivos de ventas principales y el negocio comience generar rentabilidad (en un plazo máximo de dos años), se incluirá contenido adicional como personajes nuevos, mapas (que conlleva la aparición de nuevos enemigos diferentes), edificaciones y construcciones nuevas…
El juego se presentará con un solo mapa jugable. A medida que el jugador termina las partidas, a éste se le recompensa con una divisa gratuita del juego. Esta divisa se podrá emplear para adquirir algunos cosméticos de los personajes en la tienda.
La divisa de pago del juego se podrá emplear para desbloquear personajes, comprar la divisa gratuita y desbloquear cosméticos entre otros.
Frozen Fury no se trata de un proyecto de gran envergadura. Es por ello que no cuenta con una infraestructura que demande la participación de una gran cantidad profesionales técnicos y artísticos muy capacitados que supongan un coste superior a los ingresos que se generarán en un principio con el producto.
TheNides R.A. cuenta con un equipo de trabajo polivalente que cubrirá las necesidades y asumirá tareas específicas de las distintas áreas de desarrollo del producto final.
El equipo de trabajo de la empresa se compone de los siguientes miembros, los cuales se especializan en áreas concretas, al mismo tiempo que cuentan con la autosuficiencia necesaria para cubrir el puesto de otros de los miembros del equipo en caso de baja o problema. El coste de contratación de los trabajadores del equipo está medido en horas de trabajo.
- Bozhidar Petrov Valchev: Pertenece al área técnica del proyecto. Lead programmer que coordina al equipo técnico de programación y comunica y asigna las distintas tareas a los distintos miembros del mismo. Adicionalmente, participará en la programación de la jugabilidad y las mecánicas del producto, además de desenvolverse adecuadamente en el área de creación de agentes e inteligencia artificial para el videojuego.
- Daniel Sánchez Cánovas: Pertenece a las áreas técnica y de diseño del proyecto. Se encarga junto a otro miembro del equipo, del Diseño del Gameplay del producto, que involucra el planteamiento de las mecánicas y la jugabilidad del mismo, además de la programación de estas dos facetas.
- Miguel Vidal de la Plaza: Pertenece al área técnica del proyecto. Se encarga de la programación de las distintas herramientas del producto, además de la programación de mecánicas y jugabilidad junto al resto del equipo técnico.
- Jorge Galiano García: Pertenece a las áreas técnica y de diseño del proyecto, especializado en el área técnica mayoritariamente. Se encarga de la programación de mecánicas y jugabilidad y es flexible y polivalente respecto al apartado artístico, pudiendo asumir cargos y tareas de animación 3D de los modelos del videojuego.
- Javier Morales Lasheras: Pertenece al área artística del proyecto. Se encarga de la elaboración del concept art del producto, que incluye personajes y escenarios jugables. Adicionalmente, lleva a cabo tareas de 3D como modelado de personajes y animación de los mismos.
- Paloma Leiva Haro: Pertenece al área artística del proyecto. Se encarga de la elaboración de assets 3D para escenarios y el diseño y modelado del propio escenario jugable de los distintos niveles del producto.
- Adrián Valiente González: Pertenece al área artística del proyecto. Se encarga de coordinar las distintas tareas del equipo de 3D (Lead 3D Artist) y de la realización de tareas de modelado de personajes y creación de assets, rigging y animación de los mismos
El desarrollo del proyecto tendrá una duración máxima de 4 meses. Durante la primera semana del proyecto se llevará a cabo la planificación del negocio, los modelos de monetización, actas de constitución de proyecto, registro de interesados y plan de comunicaciones, además de planificar el planteamiento, dinámicas, mecánicas, jugabilidad y aspecto visual del producto final. Con el objetivo de establecer una visión clara y concisa del proyecto y su elaboración.
A lo largo del proyecto se han establecido una serie de hitos en unas fechas concretas que el equipo de desarrollo deberá tratar de cumplir.
Se llevarán a cabo un total de tres entregables entre los que se encuentran: Una fase Alpha del producto, una fase beta del producto y la fase final (o Gold Master). **
- Fase Alpha: Su realización está prevista para la tercera semana de octubre, el día 31 del mes. Los hitos previos a esta fase se especificarán en otro apartado del documento.
- Fase Beta: Su realización está prevista para la segunda semana de noviembre, el día 21 del mes. Al igual que con la fase anterior, los hitos previos a esta fase se especificarán en otro apartado del documento.
- Gold Master: Su realización y acabado está prevista para la segunda semana de diciembre, el día 12 del mes. Para entonces, el juego habrá visto corregido los errores derivados de fases anteriores, y modificados aquellos aspectos del producto puntualizados durante la fase de testing.
Debido a que se trata del primer proyecto como estudio indie, la infraestructura del mismo durante su desarrollo y primer lanzamiento, no conllevará una inversión muy alta, tan solo la de los equipos de trabajo de los miembros de la empresa, las licencias de software empleadas durante el desarrollo del proyecto o el empleo de assets externos que se incluirán en él.
Se ha establecido una planificación de trabajo necesario para poder acometer el correcto mantenimiento, modificación o aumento de contenido del producto de cara a dos años después del lanzamiento del mismo.
Esta planificación está desglosada por semestres y en ella se establecen tres posibles escenarios a partir de los cuales se tomarán decisiones que cambiarán de una forma u otra el producto resultante. Cada escenario dependerá del grado de cumplimiento de los objetivos de trabajo establecidos.
Adicionalmente, se llevará a cabo una evaluación trimestral desde el lanzamiento del producto para medir el comportamiento de las ventas, analizar si se mantienen estáticas o evolucionan favorable o negativamente y, en tal caso, aplicar correcciones a la planificación de trabajo establecida.
Para poder valorar si los escenarios planteados son pesimistas, normales u optimistas, se deberá proyectar las horas de trabajo reales del equipo de la empresa y establecer un objetivo de horas definido. El objetivo se establece de forma mensual para poder realizar un seguimiento cercano de su cumplimiento y rectificar, si procede. Este objetivo estará relacionado con una estimación del tiempo de trabajo necesario de cada área para poder abarcar con holgura y, cumpliendo los plazos a tiempo, todas y cada una de las tareas planificadas en el proyecto, incluyéndose modificaciones o actualizaciones del mismo a lo largo de un plazo máximo de dos años.
Así, una vez conocidas la cantidad de horas invertidas y objetivadas la cantidad de horas ideales, se podrá valorar si los resultados son los esperados o no.
La mecánica principal del juego consistirá en el desplazamiento por el entorno para la eliminación de hordas de enemigos. Esto se llevará a cabo mediante el uso del personaje y sus habilidades junto al posicionamiento de trampas y edificaciones ofensivas (o defensivas) que afectarán al entorno y al comportamiento de los enemigos.
Todo esto se observará desde una vista ligeramente picada, las hordas de enemigos serán cambiantes y se adaptarán al jugador para ajustar la dificultad de la partida. Adicionalmente, el jugador tendrá todo un elenco de personajes y edificaciones que seleccionar para que cada una de las partidas sea diferente. Además, tanto la construcción de elementos como las mejoras de personaje requerirán del uso de recursos que el jugador deberá gestionar tras recolectarlos eliminando hordas enemigas.
El usuario tendrá movimiento libre alrededor del mapa. Para ello, dependiendo de la plataforma desde la que se esté accediendo al videojuego, se empleará un PAD que comenzará oculto en la pantalla y que se mostrará únicamente cuando el usuario presione la misma (en el caso de dispositivos móviles), o alternativamente, el movimiento responderá a la interacción que tenga el usuario con el teclado (en el caso de jugar desde ordenador).
Los ataques que realiza el personaje a los distintos enemigos del juego se hacen de manera automatizada. Si el jugador está lo suficientemente cerca de un enemigo, su personaje disparará automáticamente y, sin fallar los disparos, a los diferentes enemigos que divise.
Esta es una de las principales mecánicas de Frozen Fury. Nada más iniciar la partida, el usuario podrá interactuar tanto con el dedo (en caso de móviles) como con el ratón (en caso de ordenador), con un botón de una flecha desplegable. Si se acciona el mismo, aparecerá en la parte derecha de la pantalla un menú de construcción. En él, figuran todas las estructuras posibles que el jugador puede construir en el terreno de juego. Cada estructura del menú de construcción cuenta con una previsualización del modelo 3d, el nombre y la cantidad de recursos con las que el jugador debe contar para poder construirla. Una vez se selecciona una estructura en el menú de construcción (mediante interacción dedo/ratón), en el mapa de juego aparecerá una rejilla o grid con los cuadrantes en los que se puede posicionar dicha estructura.
Se podrá observar también que el menú de construcción se actualizará una vez seleccionada una estructura, mostrando estadísticas concretas del edificable seleccionado y, en la parte inferior, varios botones de interacción.
Una vez el usuario selecciona el área del grid en la que desea colocar la estructura, ésta quedará fija, dando pie al jugador a interactuar con los nuevos botones del menú de construcción. Entre ellos se encuentra un botón para rotar la estructura, un botón para mover la estructura (en caso de haberla posicionado en un sitio no deseado), un botón de confirmación para colocarla definitivamente en el mapa y un botón de cancelar, que cerrará el modo construcción y cancelará la estructura que se fuera a fijar.
Otra de las mecánicas incluidas es la capacidad de mejorar estructuras además del propio jugador. Las mejoras conllevan un gasto de recursos y afectan principalmente a estadísticas como la vida, el daño, o la velocidad de ataque.
-
Las estructuras se podrán mejorar accediendo primero al menú de mejora de estructura manteniendo el clic izquierdo sobre ella (siempre y cuando ya se haya construido), y presionando los botones de mejora correspondientes “Level up”. Esto conlleva un gasto de los recursos principales de la partida.
-
La opción de mejorar el personaje aparecerá si el usuario mueve el mismo hacia la furgoneta del mapa. Una vez cerca de ella, se desplegará el mismo menú de mejora mencionado previamente.
Otra de las mecánicas principales de Frozen Fury se centra en lograr que el objetivo principal que el jugador debe defender, quede con al menos un punto de vida al final de la partida. Los encargados de atacar este objetivo principal son los distintos enemigos del juego, a los cuales se les ha dotado de comportamientos distintos en partida que se especificarán en un apartado dedicado exclusivamente a ellos.
Dichos enemigos aparecerán por oleadas, y una vez que el usuario elimina toda la oleada, este tendrá un tiempo para volver a construir edificables en el mapa antes de comenzar la siguiente ronda (con la siguiente oleada).
Como se ha mencionado previamente, los enemigos son otro de los elementos principales del core del videojuego. Se pueden diferenciar los mismos según su comportamiento y características principales:
- Enemigos aéreos: ignoran muros y trampas de pinchos pero pueden ser avistados por el jugador y por edificables de tipo torreta.
- Enemigos terrestres: pueden ser avistados tanto por las torretas y el jugador, como afectados por los muros y obstáculos y las trampas de pinchos.
- Avistamiento del jugador: El objetivo principal de todos los enemigos es avanzar hacia la meta, pero un número reducido de ellos se dirigirán hacia el jugador una vez que éste es detectado.
- Avistamiento de edificables y obstáculos: al igual que en el anterior punto, este tipo de enemigos comenzarán dirigiéndose a dañar al objetivo principal, pero si en su camino encuentran un edificable, lo podrán destruir. Cabe destacar que, enemigos como los golems, destruirán un muro que se encuentren en su camino si y sólo si la opción de rodearlo les resulta más costosa (en cuanto a tiempo de llegada), que derribándolo. Nuevamente, se comentará en un apartado dedicado a enemigos.
Frozen Fury es un videojuego multiplataforma que se puede jugar tanto en dispositivo móvil como en ordenador. Las acciones son las mismas en ambas plataformas, pero los controles se han adaptado en los distintos dispositivos.
- Clic izquierdo en menú desplegable → Acceso al modo construcción.
- Tecla 1 → Selección de estructura: Cañón de helado
- Tecla 2 → Selección de estructura: Catapulta de guindas
- Tecla 3 → Selección de estructura: Muro de helado
- Tecla 4 → Selección de estructura: Trampa de conos
- Tecla R → Rotar estructura
- Tecla E → Cancelar construcción de estructura
- Tecla Enter → Confirmar construcción de estructura
- Clic izquierdo en el mapa en modo construcción → Fijación de estructura y actualización de opciones en el modo construcción.
- Clic izquierdo en botón de rotar (modo construcción) → Rotación de la estructura fijada previamente en el mapa
- Clic izquierdo en botón de mover (modo construcción) → Permite el movimiento libre de la estructura previamente fijada.
- Clic izquierdo en botón de confirmación (modo construcción) → Coloca definitivamente la estructura fijada previamente en el mapa en una posición y con una rotación determinada.
- Clic izquierdo en botón de cancelar (modo construcción) → Elimina la construcción fijada previamente y cierra el modo construcción.
- Clic izquierdo en botón de inicio de ronda → Iniciar ronda
- Pulsar menú desplegable → Acceso al modo construcción.
- Pulsar en el mapa en modo construcción → Fijación de estructura y actualización de opciones en el modo construcción.
- Pulsar botón de rotar (modo construcción) → Rotación de la estructura fijada previamente en el mapa
- Pulsar botón de mover (modo construcción) → Permite el movimiento libre de la estructura previamente fijada.
- Pulsar botón de confirmación (modo construcción) → Coloca definitivamente la estructura fijada previamente en el mapa en una posición y con una rotación determinada.
- Pulsar botón de borrado (modo construcción) → Elimina la construcción fijada previamente y cierra el modo construcción.
- Pulsar botón de inicio de ronda → Iniciar ronda
Frozen Fury se trata de un juego de tipo endless, por lo que como tal, no cuenta con un número de ronda determinada para acabar la partida en victoria. Pero se ha establecido otra condición de victoria implícita:
Una vez el jugador haya alcanzado la ronda 8, si este “pierde” (la vida del objetivo principal llega a 0), se considerará como victoria, permitiendo al usuario visualizar una pantalla o splash art de la victoria. Sin embargo, si el jugador no logra defender el objetivo principal por debajo de la ronda 8, se considerará como derrota.
Tay y como se acaba de mencionar, se considerará una partida como victoria cuando el jugador haya alcanzado al menos la ronda 8, sin embargo, esto sólo supondrá un desafío inicial pues se incentiva al jugador a continuar la partida mediante un sistema adaptación de los enemigos (Dynamic Difficulty Adjustment) a las capacidades del jugador para hacer la partida desafiante en todo momento mediante el uso de algoritmos genéticos. De esta forma, el jugador podrá saciar su curiosidad por ver hasta qué punto puede evolucionar una partida a la par que enfrentarse a un desafío a medida.
Para defender el objetivo principal, el usuario deberá hacer uso del propio disparo del personaje o de los edificables mencionados en el apartado de Descripción detallada de mecánicas. A continuación se describen las distintas estructuras que el jugador puede construir en la partida:
CAÑÓN HELADO
Estructura con velocidad de disparo y daño moderado. El disparo es directo a los enemigos y es de impacto a un único target (objetivo)
CATAPULTA
Estructura con velocidad de disparo lenta y daño alto. El disparo se mueve mediante tiro parabólico y el impacto afecta a varios enemigos, es decir, es en área.
TRAMPA DE CONOS
Estructura que aplica un daño continuado mientras los enemigos están encima de ella. Adicionalmente, aplicará una reducción en la velocidad de movimiento de los mismos.
MURO DE GALLETA
Estructura que no inflige daño a los enemigos pero sirve para obstaculizar su paso.
Frozen Fury no cuenta como tal con distintas armas entre las que cambiar, sino que existen tres personajes jugables que el usuario puede escoger. Dichos personajes tienen distintos modos de disparo:
- Tiro disperso: propio del personaje principal, el heladero, el cual cuenta con una escopeta de dos cañones que dispersará varias balas en un área cónica. Las balas tienen un daño moderado y la cadencia de ataque también es moderada
- Tiro a ráfagas: propio del personaje Coneman. Es un disparo desde un único punto de ataque y con ráfagas de tres balas. El daño será menor que las balas del tiro disperso, pero a cambio, la cadencia de disparo será mayor.
- Tiro potente: propio del personaje Torrine. La cadencia de disparo será lenta puesto que se trata de un tiro con un daño elevado.
En este apartado se detallarán los distintos enemigos con los que el juego cuenta, su comportamiento y su interacción con el mundo.
GOLEM
El Golem es un enemigo cuya característica principal es su gran capacidad de recibir daño y resistir en el terreno de juego. A cambio, su velocidad de movimiento es muy reducida respecto al resto de enemigos del juego.
Su objetivo principal es el de destruir la furgoneta del heladero (objetivo que el jugador debe defender en todo momento), y para poder alcanzarlo, se deberá mover por el mapa hasta entrar en su rango de ataque. Si en su camino se encuentra un obstáculo que entorpezca la ruta, el golem decide entre dos acciones:
- Si la distancia directa, en caso de no existir obstáculo alguno a la meta, es menor que la distancia que tendría que recorrer rodeando el muro, el golem se acercará al muro y lo destruirá.
- Si la distancia directa, en caso de no existir obstáculo alguno a la meta, es mayor que la distancia que tendría que recorrer rodeando el muro, el golem rodeará el muro y continuará hacia la meta.
Adicionalmente, se comportará de la misma forma con las estructuras de tipo torreta, dirigiéndose a ellas si se encuentran dentro de su rango de visión y si obstaculizan su paso.
DIABLILLO CUCURUCHO
El diablillo cucurucho es un enemigo cuyo objetivo principal, al igual que el golem, es ir a por la furgoneta del heladero. Si durante su camino avista al jugador, este pasará a ser exclusiva prioridad hasta derrotarle.
Su velocidad de movimiento es moderada/alta, su daño de ataque moderado y su salud igual. Se podría considerar como el enemigo con estadísticas estándar y neutras.
BOOMFFIN
Boomffin es un enemigo escurridizo y rápido cuyo principal objetivo es la furgoneta del heladero, pero también establecerá como prioritaria la destrucción de las estructuras que el jugador tiene construidas en el terreno de juego. Este posee poca vida, pero se compensa con su alta velocidad de movimiento. El jugador debe ser rápido para evitar que destruya los edificables, ya que este enemigo derribará los mismos de un solo golpe cuando explote.
Adicionalmente, otra de sus tareas de comportamiento es la de ayudar a un golem que está golpeando un muro. Lo primero que el Boomffin comprueba al aparecer en el terreno de juego es esta condición; en caso afirmativo, facilitará el trabajo del golem destruyendo de un golpe la correspondiente estructura y liberando el camino del mismo.
PASCUAL
Pascual se puede considerar como el enemigo de apoyo para el resto de enemigos del juego.
Posee un comportamiento parecido al Diablillo cucurucho, con algunas adiciones y diferencias. En primer lugar, es un enemigo aéreo, por lo que estructuras como los muros o las trampas de pinchos no le afectarán. En segundo lugar y, como se ha mencionado, se trata de un enemigo de apoyo. Cuando su vida es menor que un umbral definido, se activará un potenciador que aumentará la velocidad de movimiento de él y de todos los enemigos que se encuentren en el área del mismo.
DRAGÓN DE AZÚCAR
El comportamiento de este enemigo es directo y sencillo. Hay que destacar que, al igual que Pascual, se trata de un enemigo volador, con todo lo que conlleva. Su comportamiento se limita a aparecer en el mapa y dirigirse con una velocidad moderada/alta directamente a atacar a la furgoneta del heladero.
Un joven heladero intenta crear el mejor helado casero del mundo, pero siente que los ingredientes industriales de hoy en día no le permiten crear el helado casero definitivo, así que decide tunear su camión de helados y convertirlo en una máquina del tiempo para visitar a Leonardo da Vinci y robarle su cuaderno, donde se dice que describió en su momento el ingrediente final para el Gelato de Dios, un helado tan majestuoso que permitía ver como era el cielo.
Sin embargo, lo que no se esperaba es que su máquina del tiempo estuviese defectuosa y en vez de llevarlo directamente a su destino, le hacía viajar por diferentes épocas y universos hasta llegar finalmente a la Italia Renacentista.
El primer destino del joven heladero fue el “Bosque de las virutas multicolor”, un colorido bosque donde todos los frutos de los árboles eran virutas de diferentes colores. Cuando el heladero prueba las virutas, se asombra con el suave pero dulce sabor de estas, pues no eran virutas industriales, sino que eran un fruto de los mágicos árboles.
El heladero decide empezar a recoger todas las virutas ayudándose de la aspiradora que siempre lleva en su camión, pero en ese momento le atacan los habitantes del sitio…
El segundo destino del heladero fue el “Pueblo de las nubes de azúcar” un lugar donde los ríos contenían enormes cantidades de azúcar y, que al evaporarse, formaban gigantes y esponjosas nubes de azúcar. Cuando el heladero sube a la montaña del pueblo, agarra un trozo de la nube y prueba el azúcar de esta, dándose cuenta de que ese ingrediente no era como el que él conocía, sino que uno mucho más dulce. De forma que agarra su aspiradora y comienza a absorber todas las nubes. Sin embargo, al hacer eso, los habitantes del pueblo se enfadan mucho y van a por él…
El tercer destino del heladero fue el “Valle de la galleta” un lugar donde el tronco de los árboles era galleta. Cuando el heladero descubre esto, comienza rápidamente a talar todos los árboles que ve en su camino, pero cuando los habitantes del pueblo se dan cuenta, comienzan a ir en su búsqueda…
Heladero (Ice cream man): excéntrico joven que está en una búsqueda de crear el helado casero definitivo y, para ello, crea una máquina del tiempo para robarle a Leonardo da Vinci el ingrediente que él tiene escrito en su cuaderno.
ConeMan: Un loco heladero que defiende que el helado siempre se debe comer en cucurucho, acérrimo enemigo de Torrine, suele comerse los helados de un solo bocado pues así asegura que se disfrutan mucho más. Es posible que de hacer tantas veces eso y sufrir de congelaciones cerebrales, se haya vuelto un poco demente.
Torrine: Una presumida niña que asegura que el helado es un producto de la nobleza y, que como tal, debe comerse delicadamente en una tarrina. Es enemigo de ConeMan desde que se conocen debido a sus ideologías diferentes.
Dragón de azúcar: dragón del pueblo de las nubes de azúcar que debe defender el reino. Aunque tenga partes de azúcar, no hay que dejarse engañar, pues es capaz de escupir bolas de azúcar fundidas a más de 100º.
Diablillo cucurucho: rápido cucurucho con patas que no es muy peligroso, sin embargo, deja que se acumulen y pueden suponer un gran problema.
Pascual: es un conejo de chocolate volador que dejará caer sus bombas de pascua sin pensarlo dos veces, arrasando con todo aquello que se tope con su camino sin apenas poder pestañear, ¡deja que se acerque y serás hielo picado!
Golem de carbón dulce: una gigante criatura de carbón dulce que avanza a paso lento, no te confíes con su pausado paso, porque una vez que te alcancen son capaces de derribar estructuras a base de puñetazos. Si los eliminas lo suficientemente rápido quizás puedas darle un lametón al carbón a ver que tan dulce está.
Boomffin: escurridizo muffin que en vez de llevar un delicioso topping lleva una bomba rellena de chocolate. Como se sitúe cerca de alguna estructura no dudará en explotar y llenarlo todo de delicioso chocolate.
Reino dulzón: Su ubicación es desconocida en el dulciverso. Tan solo se tienen noticias de que todo elemento de la naturaleza, objeto o estructura que forma parte de él tiene un símil con uno de los dulces que normalmente se consumirían de almuerzo o postre en una comida en el planeta Tierra... pero a escala real!. Galletas gigantes, vallas hechas de marshmallow, piedras de caramelo… Es difícil querer salir de ahí por voluntad propia una vez se entra…
Bosque de las virutas multicolor: un gran bosque situado en el reino de las virutas. Sus árboles dan como fruto virutas de diversos colores que van cambiando su sabor y textura dependiendo de la estación. Los árboles dan fruto a diario. Las virutas que caen de los árboles sirven de abono para otros árboles.
Valle de la galleta: un valle situado en el reino de la galleta crujiente en el cual los tallos y troncos de los árboles están formados por una crujiente y deliciosa galleta. Este destino será el que se presenta en la versión final del juego.
Un videojuego con temática de monstruos puede llegar a interpretarse como un videojuego con ambientación terrorífica y oscura, pero no es el caso de “Frozen Fury”. La estética del videojuego es de tipo “cartoon”, “chibi”, es decir, personajes se representan de forma exagerada con cuerpos pequeños y cabezas grandes. De esta manera se consigue una versión más infantil, inocente y adorable del producto final.
Todos los assets visuales del juego han sido modelos 3D creados con el software de modelado “3Ds Max”. El personaje principal controlado por el jugador, los enemigos, las edificaciones a construir, e incluso los posibles escenarios jugables serán modelados por el equipo de trabajo y serán completamente originales.
Para conseguir esa estética especial, que deja un acabado final muy singular, se ha aplicado un “toon shader” a todos los modelos 3D.
El jugador puede acceder a menús desplegables para consumir los recursos que consiga a lo largo de la partida y abarcar las diferentes edificaciones que desee construir. Todos estos apartados están etiquetados, marcados con el valor de los recursos y acompañados de ilustraciones 2D. De esta manera se simplifica la información para no saturar demasiado al usuario.
Algunos juegos móviles de la compañía “Supercell”, como “Clash of Clans” y “Hay Day”, cuentan con estos menús desplegables que se desean conseguir en el producto final de “Frozen Fury”, por lo que sirven de gran inspiración.
Adicionalmente, las interfaces y estética general y disposición de los elementos de los menús del juego están fuertemente influenciadas por videojuegos como “Brawl Stars”
Frozen Fury cuenta con piezas musicales que van muy relacionadas con la propia temática y el aspecto visual y la armonía que transmite el videojuego.
La música del menú principal es una melodía animada, y de temática cartoon. Esta acompaña correctamente a todos los elementos que el usuario puede visualizar en pantalla: colores vivos, logos y botones en movimiento, interacción con los mismos con retroalimentación.
Una vez el usuario entra a la pantalla de juego, la música cambiará a una melodía relajada mientras el usuario construye sus edificables en el mapa. Una vez empezada la ronda, se reproducirá una melodía de acción que pondrá en situación de combate al mismo. La melodía sigue siendo de tipo cartoon y está muy inspirada en el videojuego Plants vs Zombies.
La música mencionada en al apartado anterior estará acompañada de diversos efectos de sonido. Se pueden distinguir entre efectos de sonido de interacción con botones neutros y otros efectos relacionados con la comida (un splash o chapoteo, trozo de comida que se puede caer al suelo etc…), melodías de comienzo y fin de ronda, impacto de proyectil con el enemigo, músicas de victoria y derrota... El volumen general del juego y de los efectos de sonido podrá modificarse en la pantalla de ajustes del mismo.
También se han incluido efectos de sonido para la partida, tales como la muerte del jugador, sonidos y efectos de disparo o construcción…
Menú principal
Pestaña de compra de personaje (tienda)
Pestaña de confirmación de compra personaje (tienda)
Pestaña de compra de cosméticos (tienda)
Pestaña de confirmación de compra skin (tienda)
Pestaña de compra de recursos (tienda)
Pestaña de selección de personaje
Pestaña de selección de personaje
Bestiario
Ejemplo Bestiario
Ejemplo Tutorial 1
Ejemplo Tutorial 2
Menú de pausa
Menú options in-game
Menú options en menú principal
HUD in-game
Menú desplegable construcción
Menú de estructura
Menú de mejora de construcción
Pantalla de victoria
Pantalla de derrota
Pantalla de créditos
Behaviour Tree Editor es un asset gratuito que permite visualizar y desarrollar de manera más gráfica árboles de comportamiento para personajes con inteligencia artificial. Se basa en un sistema de nodos y selectores que permiten simular el flujo de comportamiento de una IA definida por el programador. El verdadero potencial de este asset radica en la posibilidad de crear nodos personalizados con comportamientos a gusto del desarrollador. Cada nodo de los árboles lleva asociado un script encargado de realizar una acción o ejecutar sentencias de código completamente independientes de los scripts que se puedan ejecutar en otros nodos (“atomicidad”).
Se puede descargar el asset de manera gratuita en la siguiente página: https://thekiwicoder.com/behaviour-tree-editor/
La música y los efectos de sonido no han sido obtenidos de librerías de sonido, sino que han sido compuestas y realizadas por un integrante externo del equipo. El equipo de desarrollo se ha puesto en contacto con él, se le ha presentado la idea de videojuego y los diferentes aspectos del mismo que necesitaban audio, y en un periodo aproximado de un mes, se han llegado a componer más de 15 piezas de audio para Frozen Fury.
Su nombre es Andoni Plaza, y se puede acceder a su trabajo, redes sociales y portfolio desde el siguiente enlace:
El shader aplicado a los modelos 3D ha sido comprado entre todos los miembros del equipo de trabajo de la asset store de Unity.
El creador del shader es el usuario https://mjqstudioworks.weebly.com/ y el shader se puede obtener en el siguiente enlace https://assetstore.unity.com/packages/vfx/shaders/realtoon-65518.
Se ha empleado un template obtenido de Itch.io para hacer que el juego sea responsive en WebGL. Emplear este template ha conllevado un mayor tiempo de carga del juego en Itch.io.
Se puede acceder al template en el siguiente enlace: https://seansleblanc.itch.io/better-minimal-webgl-template.
Para reforzar la retroalimentación en las acciones del usuario y en las de los enemigos del juego, se ha empleado un asset con diferentes efectos de partículas obtenido de la asset store de Unity.
Se puede acceder al asset en el siguiente enlace: https://assetstore.unity.com/packages/vfx/particles/cartoon-fx-free-109565
Como se ha mencionado en apartados previos, el primer entregable del prototipo del videojuego permitirá que el usuario pueda llevar a cabo el transcurso de una partida de comienzo a fin. A falta de implementar un gran número de funcionalidades, esta versión del producto posee las características más relevantes del mismo. Entre ellas se encuentran:
- Mecánicas principales de juego como el movimiento y disparo del personaje, la generación de oleadas de enemigos que se dirigirán hacia el objetivo principal que el jugador debe defender, la implementación de un modo construcción donde el usuario puede elegir una estructura para situar en un grid y de esta forma defender el objetivo mencionado, implementación de varios tipos de disparo de personaje (tan solo uno de ellos se podrá usar en la alpha), implementación de diferentes tipos de enemigos (en cuanto a sus estadísticas se refiere).
- Pantallas de Menú principal, ajustes, contacto con el equipo de desarrollo, victoria y derrota.
- Primera aproximación de la estética visual final que tendrá el videojuego, con un shader de tipo 'toon', donde el sombreado será plano y tanto personajes como escenario y edificables, tendrán un outline alrededor.
La idea del juego
Desde un principio nos pusimos de acuerdo en el producto que íbamos a crear. Sabíamos que los cimientos son lo más importante a la hora de construir cualquier cosa, si los cimientos se tambalean, el edificio se cae.
La comunicación
No creo que haya pasado tanto tiempo con alguien durante el desarrollo del producto como con los miembros del equipo. Todos los días nos pasábamos horas y horas trabajando en el producto y, mientras lo hacíamos, estábamos siempre en llamada para decir cualquier problema que tuviésemos.
La distribución del trabajo
Al principio del proyecto nos dividimos las tareas para que cada uno trabajase en un área concreta. Eso me permitió concentrarme en mi tarea sin tener que preocuparme de lo demás. Yo me centraba en programar mis tareas y, ya más adelante, lo juntaría con el resto de tareas de los demás.
Hacer un nuevo repositorio
Crear un nuevo repositorio cuando los problemas empezaron a florecer fue la mejor decisión que tuvimos en el proyecto. En el momento que empezamos con el nuevo repositorio los problemas dejaron de ocurrir y pudimos volver a trabajar con seguridad.
Github y Gitkraken
Comenzamos el proyecto sabiendo que teníamos que usar algún sistema de control de versiones. Sin embargo, de saber que había que usar un sistema de este tipo, a usarlo bien, hay un trecho.
El primer problema fue que no todos sabían usar bien github (entre las personas me incluyo, que solo lo había usado para controlar pequeños proyectos individuales donde siempre subía cosas al main).
Entonces llegado a un punto, comenzaron a llegar los problemas. Uno subía código y se subía al main, pero luego otra persona hacía pull y por algún motivo no se le descargaba el último commit, mientras que a una tercera si.
Hubo un momento donde en algún commit que hizo otro de los miembros se borró parte del proyecto y hubo que regresar a una versión anterior. Lo mejor que hicimos fue crear un nuevo repositorio.
Tocar varias personas la misma parte
Hubo un punto donde varias personas teníamos una tarea similar que tenía que ver con los enemigos, las balas y el apuntado a los enemigos. En ese punto, quizás por no haberlo hecho del todo bien o porque colisionaban nuestras ideas, no paraban de ocurrir errores cada vez que alguien añadía/retocaba algo de los scripts que tenían que ver con esas tareas. Era común encontrarse con un NullPointer o algún otro error a la hora de hacer un pull, por suerte en cuanto hice la refactorización de mi código y nos pusimos de acuerdo, ese problema dejó de ocurrir. La comunicación a la hora de añadir/modificar algo del código cobró mucha mayor importancia.
Programar antes de planear
Me gusta programar. Escribir líneas de código y luego unir todo para que funcione es un gusto. Sin embargo, me ocurre muchas veces que me pongo a escribir sin pensar en el futuro de mi código. ¿Realmente necesito tantas clases para hacer la funcionalidad que estoy creando?
Si antes de ponerme directamente a programar dedicase un momento a planear mi código, quizás podría ahorrarme una refactorización del código cuando de pronto vea que tengo varios métodos que tienen código duplicado.
- La comunicación ha sido buena, al vernos 4 días a la semana y estar prácticamente todos los días en llamada nos ha permitido ser conscientes del estado del trabajo en todo momento.
- Al haber una constante comunicación el equipo se ha apoyado entre ellos, y se ha podido detectar problemas antes de tiempo y se han podido solucionar antes de que estos generen conflictos
- Una mala planificación inicial. Creo que se asignaron pocas tareas para esta primera parte pensado que no llegaríamos, y en algunos casos se terminaron bastante holgados o tal vez se asignaron tareas que no eran tan importantes para la primera entrega. Además debido a la inexperiencia del grupo, creo que no se crearon las tareas realmente necesarias que había que implementar para la primera fase, teniendo que improvisar nuevas durante el desarrollo de la misma.
- Falta de coordinación, a pesar de estar bien comunicados ha habido una falta de coordinación, es decir, al no tener unas entidades de referencia desde un principio cada uno de los miembros del equipo de programación programo sus utilidades para su propio tipo de entidades y no para las entidades creadas para el proyecto (porque no las había) generando conflictos.
- El uso del repositorio online. La falta de experiencia del equipo en el uso de servicios tipo git hizo que se generasen conflictos teniendo que crear uno nuevo para solventar este problema.
Debería mejorar la comunicación con el equipo de diseño, ya que algunos de los modelos realizados por estos no satisfacen las necesidades de los comportamientos diseñados debido a que no se lo especifique en un inicio.
Uno de los aspectos que ha ido bien hasta la entrega de la fase beta se trata de la comunicación.
El equipo ha estado en constante comunicación y todo el mundo sabía que estaba haciendo el resto de personas, también se conocía si alguna persona estaba teniendo problemas y si alguien necesitaba ayuda.
Otro aspecto que ha funcionado correctamente ha sido el reparto del trabajo, este ha estado bastante equilibrado entre los diferentes miembros del grupo, tanto en el apartado de arte como en el de programación.
Gracias a este reparto equitativo de las tareas se ha conseguido llegar al objetivo de entregar la beta a tiempo.
Por último, el ambiente de trabajo es algo que ha ido especialmente bien ya que se ha sumado a un grupo de amigos un trabajo serio en el que todo el mundo se ha involucrado correctamente.
En general no han habido muchos problemas en el proyecto pero el principal ha sido con GitKraken y GitHub.
A mitad del sprint empezaron a surgir problemas con los commits en los que se borraban datos y se perdían partes del código, se hacía pull de las diferentes branches y tampoco se actualizaba el proyecto en local con los últimos datos que estaban en el repositorio de GitHub. Este error nos hizo perder bastante tiempo ya que tuvimos que repetir el desarrollo de scripts numerosas veces porque no se guardaban. La solución a este problema vino con la creación de un nuevo repositorio.
Otro problema que surgió fue debido a conflictos en el código. El disparo del jugador y el movimiento del personaje en cierto punto empezó a dar problemas debido a que no se habían realizado de la misma forma. Este problema se solucionó con una refactorización del código.
Al inicio de esta entrega desarrollé ciertos scripts los cuales daban como resultado la funcionalidad que se quería obtener, es decir, eran “correctos”, pero para conseguir este resultado estaba reinventando la rueda en algunos casos. Lo que tengo que mejorar personalmente es el no aferrarme a un código que a pesar de que sea correcto, se pueda conseguir una funcionalidad más adaptada a lo que se pide de una forma más fácil. Por tanto, no siempre tengo que quedarme con el primer código correcto, si no con el mejor de los correctos.
Uno de los factores más importantes en un equipo de trabajo es la comunicación constante. Es fundamental que todos los miembros del equipo sepan en qué punto concreto se encuentra el proyecto, problemas que surgen en los distintos equipos o áreas de trabajo para ponerles una solución, y es ese uno de los aspectos más positivos del equipo de TheNides R.A. Nos comunicamos todos los días y se organizan diariamente reuniones de trabajo (no son necesariamente dailys de 15 minutos, si no que nos metemos en llamada y trabajamos cada uno en nuestras tareas). Todo ello genera un buen ambiente de trabajo en el que todos nosotros nos sentimos cómodos.
El correcto reparto de las tareas también favoreció el trabajo independiente de cada uno de los miembros del equipo. Las áreas de trabajo han estado bien diferenciadas en todo momento, y dentro de ellas, cada integrante ha tenido en todo momento asignado al menos una de ellas; ninguno de ellos se ha quedado sin hacer tareas.
El propio equipo de trabajo. Debido a que ha habido una comunicación constante entre los distintos miembros y cada uno de ellos ha tenido una asignación de tareas diferenciadas, cuando alguno de ellos ha terminado sus tareas, se ha dedicado a ayudar a otros miembros con lo suyo. Tanto en la parte artística como en la parte técnica.
Principalmente por puro desconocimiento han surgido varios problemas con el sistema de control de versiones. Se ha corrompido el proyecto una vez, ha desaparecido trabajo y ha habido que repetirlo varias veces por problemas con los pulls en el main y en las distintas ramas… Como se ha mencionado, esto ocurre por desconocimiento de Github y de Git Kraken principalmente.
Además de mantener la comunicación por llamada directa, se ha ido plasmando en un documento excel todo el trabajo realizado a modo de daily escrito. A pesar de mantener una comunicación constante diaria, es importante que todo el mundo sepa en qué punto concreto se encuentra el trabajo, y ha habido numerosos días en el que ese trabajo diario no se ha documentado. De cara a posteriores trabajos, se debería mejorar este aspecto y mantener una constancia respecto a los dailys.
Actualmente se está utilizando Scrum como framework de trabajo. Para la organización de las tareas, la empresa cuenta con un Trello en el que cada uno de los miembros se debería asignar una serie de tareas e ir marcándose como hechas una vez acabadas. Como tal, las tareas figuran en el trello, pero no se realiza un seguimiento y actualización de las mismas a diario. Al igual que con los dailys, se debería mantener esa constancia en el Trello para ver el punto en el que se encuentra el proyecto.
Creo que soy una persona a la que se le da bien organizar el trabajo, dividir las tareas y comunicarse con el equipo, pero no siento que haya ejercido correctamente de scrum master. Es cierto que, nuevamente, es por inexperiencia y por no haber ejercido muchas veces el papel. Tan solo tuve una ocasión a lo largo del curso para ejercer como Scrum Master, y no fue por mucho tiempo. Me he documentado y leído sobre las tareas y las actividades que debe llevar a cabo una persona con este rol, pero no he sabido ejecutarlas correctamente.
A raíz de lo anterior, no me comuniqué correctamente con el equipo para poner en el Trello las tareas a realizar en la fase Alpha. Al revisar lo que había puesto en el tablero de cara a la fase Beta, me di cuenta de que muchas de las divisiones de tareas que realicé carecían de sentido; muchas de las tareas no se habían planteado realizar en el videojuego y terminaron por eliminarse en una de las revisiones del tablero. Es por ello que de cara a futuras entregas, debo estar con el equipo entero para establecer la correcta división de las tareas del tablero.
Creo que es complicado compaginar este trabajo con el resto de asignaturas, dado que es a lo que prácticamente se le dedica la mayor parte de tiempo a lo largo de la semana. Muchas veces conviene descansar y hay días en los que no se realiza mucho trabajo. Hemos ido bien de tiempo con esta primera fase, pero estaría bien establecer deadlines a las distintas tareas para mantener esa constancia y que sepamos todos las fechas concretas en las que se vaya a terminar el trabajo. Son muchos los factores que hacen que una tarea lleve más o menos tiempo, pero se debería estudiar en profundidad esos riesgos para establecer los deadlines adecuados.
- El comienzo del proyecto: al comienzo, el proyecto se inició con mucha ligereza y con mucha motivación por parte de todo el equipo, lo que favoreció la creación de una idea inicial que de base era sencilla y que además nos daba margen para desarrollar nuestra ambición y sacarle el máximo partido al proyecto.
- La comunicación con el equipo: durante todo el proyecto, muy pocos han sido los fallos por comunicación, esto se debe a que a lo largo del desarrollo se han mantenido reuniones de forma prácticamente diaria que nos permitían estar al tanto de los avances llevados por nuestros compañeros.
- El ambiente de trabajo: gracias a la comunicación constante, en nuestro grupo de trabajo siempre se ha facilitado ayuda a aquellos compañeros que la necesitaban, lo cual ha favorecido enormemente al desarrollo de habilidades de trabajo en equipo de todos los miembros.
La mayoría de los problemas que nos hemos encontrado a lo largo del proyecto surgen de nuestra inexperiencia con el trabajo en equipo y sobre todo con el desarrollo de proyectos “grandes” (en comparación con los proyectos que se nos suelen pedir para otras asignaturas).
- Problemas con GitHub: aproximadamente a mediados del desarrollo de la alpha, ya más próximos a la finalización del plazo, el repositorio de GitHub comenzó a darnos errores de código, aparentemente debido a un desfase en la cantidad de commits que contenía cada repositorio. Este problema nos hizo perder varios fragmentos de código en los que se había trabajado y otros avances en el proyecto. Finalmente se solucionó creando un nuevo repositorio para el proyecto, que es el que seguimos utilizando hoy en día.
- Mala distribución de tareas: en este caso se trata de un fallo en la distribución inicial, tal vez para evitar este error deberían haberse seleccionado más tareas para completar durante la fase alpha del proyecto y finalizar esta con un producto más funcional que vistoso. Parte de esta distribución se debió al miedo de sobrecargarse con un exceso de tareas por parte del equipo y otra parte por la decisión de esperar a que se impartiera el temario sobre árboles de comportamientos en la asignatura de Comportamiento de personajes.
- Forma errónea de trabajar: al comienzo del proyecto, por pura comodidad, decidimos que cada uno trabajaría en una escena distinta para desarrollar las distintas mecánicas. Esto no tiene por que suponer un problema, pero el error reside en el hecho de que cada integrante del equipo trabajó con sus propios prefabs con mecánicas que luego nos dieron muchos problemas para cohesionar. Creo que estos problemas no habrían surgido de haber trabajado sobre los mismos prefabs desde un inicio.
A título personal, creo que mis errores durante el desarrollo del proyecto han estado bastante definidos. Por un lado, a pesar de asistir a todas las reuniones, resultaba extraño que rellenase la ficha de los Daily Standups al finalizar la jornada, dejando a mi equipo colgado en ese aspecto hasta que me acordase de ello. Por otro lado, puede que como programador tenga que practicar más la comunicación constante con el equipo de desarrollo para no tener que rehacer trabajo por culpa de un cambio en la base.
Más allá del trabajo en equipo, personalmente me he visto torpe a la hora de programar, esto puede deberse a mi rechazo a construir versiones base de los distintos elementos sobre las que empezar a construir y realizar pruebas.
Como conclusión creo que debería integrarme más con las rutinas de Scrum y comenzar a hacer más versiones de testing de las cosas antes de aspirar a una versión plenamente funcional.
Creo firmemente que los puntos fuertes de nuestro equipo de desarrollo han sido la comunicación y el reparto de tareas.
Al conectarnos la mayoría de las tardes por llamada, siempre hemos sabido en qué estado del desarrollo del videojuego estábamos.
Antes de comenzar a trabajar cada día realizamos una pequeña reunión con lo que habíamos estado trabajando el día anterior y lo que haríamos ese mismo día, para que ningún miembro del equipo se quedase sin hacer nada.
En cuanto al reparto de tareas, también ha sido un éxito desde mi punto de vista, porque nunca ha habido un momento en el que nadie no estuviese sin tareas pendientes como he comentado anteriormente.
Es complicado trabajar con tanta gente ya que se puede correr el riesgo de que haya personas que trabajen más o menos que otras, pero en nuestro caso todo el mundo ha trabajado equitativamente en su área específica. Desde el primer momento, se le asignó a cada uno de los miembros del equipo varías tareas y con pequeños plazos para tenerlas listas a tiempo con la herramienta de Trello.
Uno de los problemas más perjudiciales con los que nos topamos durante el desarrollo del videojuego fue el repositorio. Al haber trabajado muy poco con los servicios de tipo git y tener muy poca experiencia con el mismo, nuestro equipo tuvo problemas con él, haciendo que se generasen conflictos y perder fragmentos de código a mediados de la elaboración de la Fase Alpha. Para solucionar este problema, se creó un repositorio nuevo.
Pese a la gran comunicación que teníamos por llamada casi todo los días, no éramos del todo constantes a la hora de dejarlo por escrito, pues teníamos que rellenar al final de cada día el excel del Daily Standup con las cosas que habíamos hecho el día anterior y las de ese mismo día. Muchas veces se nos olvidaba de rellenarlo dejando desinformado al resto del equipo.
Desde mi punto de vista creo que he notado un cambio en mí mismo desde el comienzo del proyecto a día de hoy.
Al principio del mismo, no sabía prácticamente nada de como usar Github y GitKraken y me resultaba complicado e incluso tenía miedo a usar la herramienta por si estropeaba algo del código. Con ayuda del resto del equipo me han enseñado a cómo juntar la parte de arte con el resto del proyecto para tener todo junto en un mismo proyecto de Github. Aún me queda mucho por aprender de esta herramienta y en un futuro no muy lejano espero poder usarla con fluidez.
Como he dicho anteriormente, las llamadas han sido un punto crítico en el desarrollo del proyecto, pero debo mejorar en la parte de rellenar al final de cada día en lo que he estado trabajando en el Daily Standup, ya que la mayoría de veces, se me olvidaba hacerlo.
La comunicación
Desde el comienzo del proyecto, el grupo no tuvo dificultades para ponerse de acuerdo en el tipo y la temática deseada para el videojuego, escogiéndose así un producto que nos podía agradar a todos a lo largo de su desarrollo.
Por otra parte, se han realizado reuniones constantes que nos han permitido disponer de información sobre el estado del proyecto en todo momento. Además, el hecho de estar siempre conectados nos ha sido muy útil a la hora de detectar cualquier error que pudiese surgir y resolver dudas con otros compañeros de grupo.
La organización del trabajo
Todas las tareas fueron definidas y repartidas entre los miembros del grupo antes de comenzar a trabajar en cualquiera de ellas. De esta forma se llevó a cabo una división del trabajo lo más equitativa posible, y permitió que cada uno de los miembros se especializase en aquella parte del proyecto que desempeñaría mejor. Esta organización también ha permitido priorizar unas tareas sobre otras, lo que ha llevado al equipo a cumplir con los requisitos que se exigían para la fase Alpha del producto.
Problemas con el repositorio
La falta de experiencia y conocimiento en el manejo de GitHub o GitKraken llevó a la producción de errores en el repositorio que se arrastraron durante gran parte del desarrollo de la Alpha.
Finalmente, la solución pasó por la creación de un nuevo repositorio, lo que tuvo como consecuencia la pérdida de las versiones anteriores del proyecto. Este hecho nos podría haber puesto en apuros en caso de haber cometido errores graves en algún momento del desarrollo.
Constancia con el Excel del trabajo realizado
A pesar de realizar Daily Standups de forma constante, el contenido de estas reuniones debía ser plasmado por cada miembro del equipo en un documento Excel accesible para todos. Sin embargo, en múltiples ocasiones no se llevó a cabo un seguimiento exhaustivo de esta tarea, dejando el documento bastante incompleto para el final de la primera fase del proyecto.
Hacer pruebas con más frecuencia con el equipo de programadores
A pesar de mantener una buena comunicación con el equipo artístico, los requisitos que debían tener algunas estructuras que programaría el equipo de desarrollo no se han transmitido con claridad, de modo que ciertos modelos realizados no se ajustan como deberían a las características que exige su correcto funcionamiento.
De cara al futuro trataré de pedir la información más detallada posible sobre las características que exige el modelo, de forma que el trabajo que emplee en el desarrollo del mismo no sea en vano.
No extender tanto el tiempo que me ocupa una tarea
En ocasiones, la ejecución de una tarea me ha llevado más tiempo del que creo que puedo necesitar. Es por esto que trataré de reducir el tiempo que me ocupa la finalización de una actividad y, de este modo, estar más disponible para ocuparme de nuevas actividades o para ayudar a mis compañeros del equipo de diseño en las suyas.
GitKraken
El desconocimiento sobre el uso de GitKraken limitó la cantidad de commits que realizaba sobre el proyecto y la nitidez de los mismos. La falta de experiencia me producía inseguridad a la hora de actualizar el contenido del repositorio, optando por hacerlo la menor cantidad posible de veces.
Aprender a usar correctamente el entorno es una de mis prioridades de cara a futuras entregas.
La fase alpha del producto sirve como una primera toma de contacto con el flujo principal del videojuego, las mecánicas básicas y fundamentales, el arte, estética y temática... y en general, una experiencia inicial de juego que el mismo usuario experimentará en mayor medida en fases posteriores del mismo.
Para la fase Beta, se debe procurar lograr un producto prácticamente completo, con todas las funcionalidades estipuladas en los documentos de diseño del juego. De esta forma:
- En cuanto a la parte artística, se incluirán animaciones de todos los personajes del juego para las acciones que lleven a cabo durante el desarrollo de una partida (saltar, caminar, correr, atacar, morir, disparar, idle etc.). Adicionalmente, se refinaron los shaders empleados en la Alpha, y se completaron todos los elementos visuales del HUD (iconos, botones, menús restantes...)
- Se incluirán elementos sonoros tanto para SFX como para música de menús y de juego.
- Se implementará un inventario de personajes, donde el usuario podrá establecer una configuración de las estructuras que desee construir en el mapa de cara a la siguiente partida. Adicionalmente, en el inventario, se podrá escoger al personaje con el que el usuario jugará la siguiente partida (lo que conlleva un cambio en las mecánicas de disparo) e invertir recursos para mejorar tanto a él como a las estadísticas de las estructuras que posea en ese momento.
- Se creará una tienda donde el usuario podrá invertir la divisa gratuita del juego en la compra de cosméticos para los personajes. En un principio, cada personaje cuenta con dos cosméticos cada uno.
- Se desarrollará más en profundidad los distintos tipos de enemigos con los que cuenta el juego y sus respectivos comportamientos. Se estudiarán también diversos artículos de investigación sobre el ajuste de dificultad dinámica de los enemigos, basados en fórmulas matemáticas y factores multiplicadores dependientes de estadísticas del jugador o del entorno de juego para fomentar la rejugabilidad del producto. Se pretende en todo momento que el usuario se proponga un reto y trate de superar su marca en cada partida que juegue. Es precisamente por ello por lo que la IA de Frozen Fury contará con un ajuste de dificultad dinámica; el desarrollo de una partida puede ser completamente diferente a otra, lo que despertará la curiosidad del jugador por descubrir los límites que la IA será capaz de superar o alcanzar.
En primer lugar, el equipo de desarrollo ha decidido mantener para la beta un solo mapa jugable. Esto es debido a que era necesario ajustar, corregir, balancear y pulir todos los elementos del gameplay del juego. Al fin y al cabo, los nuevos mapas no varían mucho; se modifica el modelo 3d del mismo, la disposición de elementos del escenario, los spawn points de los enemigos y del objetivo a defender. Es por ello que se ha establecido como prioritario el desarrollo completo del gameplay del juego antes de añadir nuevos mapas.
Aun así, se han incluido un elemento que varía ligeramente el aspecto y sensación de el mapa jugable:
- Disposición aleatoria de props en el escenario, donde cada vez que se inicia una partida, un número determinado de props del escenario cambian de posición.
Como se ha mencionado en el apartado de mecánicas, se ha dotado a los enemigos de una inteligencia artificial que les permite llevar a cabo diversos comportamientos según el estado del jugador y de la partida. En la fase Alpha los enemigos se limitaban a caminar el línea recta hacia la meta y el usuario podía aprovechar los edificables para bloquearles el camino y encerrarlos. Esto se ha corregido y ahora se puede distinguir entre enemigos que se dedican a destruir estos edificables, enemigos que van hacia el objetivo principal y enemigos que van a por el jugador.
El algoritmo está todavía pendiente de ajustarse y balancearse, pero supone un punto de partida para desafiar al jugador y fomentar la rejugabilidad del videojuego. El algoritmo tiene en cuenta diversas variables y situaciones para aplicar los cambios; estos cambios se aplican cuando termina una ronda, de cara a la siguiente.
Algunos de estos factores pueden ser el número de enemigos que ha alcanzado la meta, vida con la que los enemigos han llegado a la meta, puntos de habilidad del jugador…
Otros de los grandes cambios que ha sufrido el videojuego y, que eran necesarios, ha sido la modificación de la estética de la interfaz del mismo. En general, las distintas pantallas de los menús ya no se encuentran tan recargadas de elementos, se le ofrece retroalimentación visual al usuario sobre aquellas opciones que escoge de cada menú y todas ellas tienen en común un mismo estilo de arte (paletas de color, fuentes de texto etc…)
Se ha implementado una primera versión de la tienda del juego de cara a su lanzamiento. Debido a que había muchos otros elementos prioritarios del videojuego por encima de la tienda del mismo, esta se ha implementado con placeholders. La estética y el aspecto visual sí es el final que se presentará en el videojuego de lanzamiento, pero como tal, las acciones de comprar divisas, cosméticos o personajes, se han implementado indicando al usuario la acción que lleva a cabo en cada momento.
Para la fase beta del videojuego, se ha implementado una primera versión de un menú de selección de personaje. En este menú, el usuario podrá elegir el personaje que quiera utilizar en la partida. Una vez selecciona una pestaña de personaje, tendrá también opción a cambiar su aspecto (siempre y cuando lo haya comprado previamente en la tienda. Esto también se aplica con el propio personaje; se podrá escoger siempre y cuando se haya comprado en la tienda)
Al incluir sonido en el juego, es necesario que el usuario pueda modificar los valores del volumen del mismo desde un menú de ajustes, el cual se ha incluido para esta fase beta. Adicionalmente, se le ofrece la posibilidad al jugador de abandonar la partida si así lo desea. En caso de equivocación, se ha añadido una pestaña de confirmación de abandono de partida si el jugador presiona el botón correspondiente.
En cuanto a las opciones que tiene el usuario para defender el objetivo principal, se han añadido dos nuevos edificables ya mencionados en el apartado de mecánicas del documento; una potente catapulta que inflige daño en área y una trampa de pinchos que ralentiza e inflige daño continuado a los enemigos mientras están sobre ella.
En este apartado se citarán un listado de cambios conocidos que se aplicarán al juego en adición a la retroalimentación recibida en la fase de beta testing:
-
Implementación funcional de la tienda: Para la fase beta, debido a la falta de tiempo y a una mayor prioridad de otras tareas del proyecto o correcciones de código, se ha implementado una tienda con placeholders para que el usuario pueda ver su funcionamiento de cara a posteriores versiones del juego. En versiones futuras, la divisa del juego (tanto de pago como gratuita) será funcional (sin emplearse dinero real, se simularán transacciones) y se podrá emplear para comprar cosméticos.
-
Selección de cosméticos en inventario de personaje: Como tal, actualmente el juego cuenta con cosméticos funcionales y sus correspondientes modelos 3D, pero no se han incluido todavía dentro de él. Junto a las funcionalidades añadidas en la tienda, se incluirá esta nueva.
-
Ajuste de dificultad: El juego está en sus primeras fases de desarrollo y faltan todavía muchas pruebas; tanto pruebas de juego del equipo de desarrollo como pruebas de juego con usuarios testers. De cara a posteriores entregas se ajustará y refinará más el algoritmo de ajuste de dificultad dinámica implementado para los enemigos del juego.
-
Aspecto visual: Para la fase Alpha se incluyó una versión aproximada del aspecto visual del que se quería dotar al juego con un toon shader basado en colores planos y outlines de personajes y objetos de la escena. En esta versión beta, no se ha podido desarrollar una mejor versión del mismo, pero de cara a futuras versiones, se aplicará un Asset de unity que mejorará el aspecto visual final del videojuego.
-
Tweaks y timing de animaciones: Actualmente, todos los modelos exceptuando algunos casos por errores internos, cuentan con animaciones que aportan dinamismo al videojuego respecto a la anterior entrega. A pesar de ello, todavía falta por modificar y calcular correctamente los tiempos de las animaciones de los personajes y de las estructuras para una mayor fluidez visual
De unas simples mecánicas a un juego Cuando se terminó la alfa, “Frozen Fury” era una combinación de mecánicas muy lejos de parecerse a un juego. Además al ser una alfa, también quedaba mucho por pulir de la parte de gráficos. Sin embargo, al acabar la beta, es increíble en lo que se habían convertido unas simples mecánicas. Cada vez el producto se parecía más a un juego de verdad.
Uso de las herramientas de control de versiones Todos los problemas que tuvimos en la fase alfa sobre Gitkraken, no volvieron a ocurrir en esta fase. Los errores del pasado nos hicieron ganar una experiencia que sería vital para que ningún miembro del equipo tuviese problemas con la herramienta.
Gran cantidad de contenido y feedback positivo Mirando hacia atrás, el juego se sometió a un rediseño completo. Se metieron animaciones para los personajes, enemigos, una tienda de personajes y otra de skins. Además metimos pantallas de derrota y otra de victoria y, por primera vez, vimos a personas externas al proyecto jugando a “Frozen Fury” y pensando que era un juego (con muchos detalles por pulir, por supuesto, pero aun así, se divertían con la experiencia jugable).
La organización del Trello y la metodología ágil. En esta fase volvió a ocurrir lo mismo que en la alfa. El trello y los dailies volvieron a quedarse en el olvido. Los primeros días lo usamos y fuimos actualizando el progreso, pero pasada una semana, el uso de estas herramientas era menos constante. Los dailiess sobre todo, era muy común ver que ninguno de nosotros había rellenado nada en los dailies durante varios días. Estoy totalmente seguro de que el motivo de esto es debido a que nos pasábamos reunidos todos los días en llamada durante horas avanzando el proyecto y sabíamos con exactitud qué estaba haciendo cada miembro.
Saber cómo están haciendo sus tareas los otros miembros del grupo Al principio, como era un proyecto pequeño, sabía con exactitud de qué forma estaban implementando sus tareas los otros desarrolladores, sin embargo, a medida que el proyecto fue avanzando, me fui centrando en mis tareas y abstrayéndome de las tareas de los demás, si funcionaban, para mí era suficiente. Ya fuese porque teníamos más actividades o porque estaba falto de tiempo, consideré que esto era correcto, sin embargo, esto luego tuvo sus consecuencias cuando tuve que implementar algunas funcionalidades que se solapaban a algunas ya existentes. En ese momento tenía que meter mi parte de código en otro código ya existente, y para ello, tenía que saber lo que hacía ese código. Había veces que era sencillo entenderlo, pero en otras situaciones, el código era extenso y tenía que recurrir a la ayuda de las personas que lo desarrollaron, ralentizando así al equipo. Como mínimo, creo que debería de saber cómo están desarrollando los demás sus tareas.
Se refinaron las mecánicas planteadas y se creó una IA básica de los personajes así como un DDA que dieron lugar a la base de lo que teníamos planteado, creando así una buena experiencia jugable (según el feedback recibido).
Se añadieron las animaciones a los diferentes personajes y se creo un escenario que dio vida al juego.
El uso del repositorio fue correcto en esta fase y no hubo ningún error grave y la mayoría supo utilizarlo correctamente.
Se dejó atrás el apartado visual y no conseguimos el estilo que toon que estábamos buscando.
También obviamos la retroalimentación, en muchos escenarios el jugador no sabe exactamente lo que está pasando y hasta que no lleva un tiempo jugando no se da cuenta de lo que ocurre en algunos casos. El uso de las metodologías ágiles, similar a la primera fase, se empezó muy bien haciendo los dailies y actualizando el trello, pero conforme íbamos avanzando se fue quedando atrás llegando con esto un poco de desorganización, aunque nada grave debido a que siempre estábamos en llamada comunicándonos las cosas pero siempre se podía olvidar algo. Mucha carga de trabajo para esta entrega, nos habíamos puesto unos mínimos muy altos y nos costó llegar a la entrega con un juego completo y medianamente pulido.
Mis commits en el github, sigo sin poner descripciones, al principio las escribía pero con el paso del tiempo solo lo dejaba en el título.
En primer lugar, la comunicación ha sido uno de los aspectos más importantes en el desarrollo de la beta, se ha mantenido durante toda la fase y ha sido muy buena, creando un muy buen entendimiento entre los diferentes miembros del equipo. Otro apartado que ha sido positivo se trata del contenido del trabajo. En la Alpha aunque se consiguiera una buena entrega, el contenido únicamente trataba las mecánicas más básicas del juego , no habían modelos en algunos casos y existían bastantes errores aún por solucionar. Para la Beta, a parte de solucionar errores existentes, se han ido refinando las mecánicas, introduciendo modelos y creando algo más parecido a un juego, generando así mucho más contenido en el videojuego. El uso del repositorio en esta entrega también ha mejorado gracias a conseguir conocimiento sobre el uso del mismo, en la anterior fase se produjeron ciertos errores de uso que ralentizaron el proyecto. Gracias a esto se han evitado muchos errores y se ha conseguido tener un buen ritmo de trabajo durante la versión Alpha.
Un aspecto que ha ido mal se corresponde al apartado gráfico del videojuego, más concretamente a los shaders. Este trabajo se ha ido posponiendo hasta que el equipo concretó que no se implementaría en esta entrega, perdiendo así calidad visual para la versión Beta. Otro aspecto que poco a poco ha ido a peor durante la fase Beta se trata del uso de una metodología ágil. Al comienzo de la entrega se hacían dailies para saber qué tareas íbamos a hacer y si alguien necesitaba ayuda, pero esto conforme avanzó el tiempo se dejó de hacer.
A lo largo de la fase Beta, he ido perdiendo contacto con otras partes del código ya que el trabajo estaba dividido. Esto en algunos casos ha podido llegar a ralentizar el proyecto cuando tenía que relacionar mi parte con la de otro compañero y necesitaba que me ayudara a entender el código para poder continuar con la tarea asignada.
Nuevamente, uno de los factores clave para el desarrollo de la fase beta del juego ha sido la comunicación del equipo de trabajo. La versión Alpha tenía las mecánicas básicas más importantes del videojuego (en su fase más temprana), pero en la versión Beta se ha tenido desarrollar un juego completo sin placeholders y con un menor número de errores, lo que conllevaba en 3 semanas, un trabajo exhaustivo y constante para sacar la mejor versión beta del juego posible.
Al mismo tiempo, y siendo más importante en esta entrega, se ha mantenido la correcta división de las tareas y roles de los diferentes equipos de trabajo de la empresa. El área técnica y artística del proyecto ha establecido una correcta prioridad de las diferentes actividades y han trabajado mano a mano si surgían imprevistos o errores, dedicando el tiempo necesario para solucionarlos lo antes posible.
Otro factor muy importante de haber aprendido es el correcto uso del sistema de control de versiones GitKraken. Para la versión Alpha, había cierto desconocimiento del mismo, de hecho, se produjeron diversos errores derivados de sobreescribir trabajo, tener que repetirlo numerosas veces por ello, corrupciones de archivos… Para esta versión beta, se ha sabido manejar y gestionar correctamente y no ha dado problemas.
En cuanto al seguimiento de la metodología ágil, se ha llevado una mejor organización de las tareas del tablero Trello debido a que las historias de usuario se escribieron entre todos los miembros del equipo, y dichas tareas se asignaron de forma equilibrada entre las distintas áreas del proyecto.
Como ya se mencionó en el Post-Mortem de la versión Alpha, se ha estado siguiendo Scrum como framework de trabajo. A pesar de haber llevado una mayor constancia con el tablero Trello, no se ha plasmado el trabajo diario en el documento Excel de Daily Meetings. No era obligatorio, puesto que el equipo se ha reunido todos los días un mínimo de dos horas y se ha sabido en todo momento el punto concreto en el que se encontraba el proyecto pero, en caso de haber tenido constancia con el documento, se reforzaba este aspecto habría sido más fácil establecer una traza de la cantidad de trabajo dedicada diariamente. En cuanto a las reuniones diarias, como se ha mencionado en el anterior apartado, el equipo de trabajo ha llevado a cabo reuniones todos los días de un mínimo de dos horas cada una, hasta llegar a dedicar tardes y mañanas enteras reunidos en llamada. Como ha resultado difícil seguir correctamente el framework de trabajo debido a que es la primera vez que nos configuramos como empresa, la rutina de los daily standup meetings no se ha cumplido correctamente. La planificación inicial consistía en una reunión al comienzo del día de aproximadamente 15 minutos, y una reunión al final del día con todo el trabajo llevado a cabo cada día. Al final, como se ha mencionado, ha habido reuniones diarias pero de más de dos horas cada una.
El rol de Scrum Master es un cargo de suma importancia para un proyecto como este, pero debido a mi inexperiencia y, tras haber ejercido una única vez en otra de las asignaturas del grado, siento que es un cargo que me ha venido un poco grande y no he sabido gestionar correctamente. Pienso que ha sido porque, como no somos un equipo de trabajo muy grande y, hay diversas personas que tienen que ejercer varios roles al mismo tiempo, no se le puede dedicar el tiempo suficiente a cada rol para perfeccionarlo. Si quiero ejercer correctamente de Scrum Master tengo que dedicarle el tiempo de estudio suficiente, y ahí entonces, ejercer el rol.
La comunicación en el equipo ha resultado ser todo un éxito durante la fase de desarrollo de la beta ya que hemos conseguido un ritmo de trabajo común al que nos hemos sincronizado todo el equipo. Por otro lado, la división de tareas durante la práctica ha sido eficiente y funcional, de manera que siempre teníamos a un miembro especializado en cada tarea. De esta manera se aseguraba que cuando hubiese un error de cualquier tipo, siempre habría alguien especializado en ese campo. Otro de los aspectos positivos de nuestra dinámica de trabajo ha sido el aprendizaje y la experiencia obtenida durante el desarrollo de la metodología SCRUM, reuniéndonos diariamente para trabajar y discutir los avances llevados a cabo el día anterior. Finalmente, merece la pena mencionar todos los conocimientos adquiridos durante esta fase sobre Git y cómo utilizarlo correctamente (en nuestro caso mediante el uso de GitKraken).
A pesar de funcionar bastante bien como equipo y haber llevado a cabo una buena metodología SCRUM, hemos dejado algo de lado el tablero de Trello, quedando este casi en el olvido. Por otro lado, la organización general del equipo con respecto a otras asignaturas tambien ha sido un error a tener en cuenta que ha causado problemas a todos nuestros miembros, obligándolos a hacer jornadas intensivas para llegar a todas las entregas.
Personalmente creo que podría esforzarme más en rellenar diariamente todos los documentos relativos a la metodología SCRUM. También mencionar que de cara al final de la entrega, debido problemas mencionados anteriormente (principalmente otras asignaturas) no he podido mantener el mismo ritmo de trabajo que hasta ese momento había llevado. Por último, como programador debería acostumbrarme a escribir más comentarios en el código para facilitarme la tarea de regresar a código ya escrito (ya sea para la resolución de posibles errores o para la expansión de este).
La buena comunicación y la buena relación que hay entre todos los miembros son unos de los aspectos más fuertes del equipo. Al realizar videollamadas la mayoría de las tardes, siempre hemos sabido en qué estado del desarrollo del videojuego estábamos. En cuanto al reparto de tareas, también ha sido un éxito desde mi punto de vista porque se han dividido en las categorías de desarrollo y de arte y se han cumplido los plazos propuestos. Es complicado trabajar con tanta gente ya que se puede correr el riesgo de que haya personas que trabajen más o menos que otras, pero en nuestra situación, todo el mundo ha trabajado equitativamente en su área específica. Al igual que en la Alpha, se asignaron a cada uno de los miembros del equipo varias tareas y con pequeños plazos para tenerlas listas a tiempo con la herramienta de Trello. Por último, mencionar que finalmente he aprendido a usar una herramienta tan importante como Gitkraken, gracias a mis compañeros de trabajo, para tener todos los archivos del desarrollo en un mismo proyecto, aún siendo de la parte artística.
Pese a la gran comunicación que teníamos por llamada casi todos los días, hemos seguido siendo irregulares a la hora de dejarlo por escrito en la hoja del excel del Daily Standup. Muchas veces se nos olvidaba rellenarlo, dejando desinformado al resto del equipo. Añadido a esto, al principio del proyecto realizamos pequeñas reuniones diarias de unos 15 minutos de duración aproximadamente, y también hemos perdido la costumbre de realizarlas ya que nos reunimos directamente por videollamada para teletrabajar.
Desde mi punto de vista, podría mejorar todo lo que está comentado en el apartado anterior. Ser más constante e intentar rellenar el excel de los Daily Standups porque al fin de al cabo es una tarea que no consume nada de tiempo. Por último, una mala costumbre que he tenido alguna vez por vaguería es pasar alguno de mis archivos por Discord en vez de subirlos al repositorio haciendo commits en Gitkraren. De cara al futuro evitar que esto se vuelva a repetir y subirlos directamente al repositiorio.
Un aspecto destacable del equipo durante el desarrollo de la Beta ha sido la comunicación entre sus miembros. Esta fue muy buena a lo largo de toda la Alpha y se ha mantenido y perfeccionado durante la Beta, así como la división y el reparto de las tareas del proyecto. Del mismo modo, se ha llevado a cabo un uso correcto del Trello al contar con la participación de todos los miembros del equipo para su gestión, y también se ha mejorado en el uso de GitKraken. Durante esta Beta se ha aumentado el número de Commits sobre el proyecto, además de incluir mejores descripciones y etiquetas.
A pesar de hacer reuniones diarias para trabajar en grupo mediante plataformas como Discord, se ha perdido la costumbre creada durante la Alpha de realizar Daily StandUp Meetings al inicio y al final de cada sesión de trabajo, como dicta la metodología ágil que el equipo está tratando de seguir: Scrum. Por otra parte, de nuevo el equipo no ha sido capaz de mantener la constancia para describir el trabajo diario en el Excel de Daily Meetings.
Personalmente, considero que aún debo seguir mejorando en el uso de GitKraken, haciendo un commit del trabajo que realizo cada día en lugar de acumular todo lo que voy creando para una única entrega final.
Por último, debería ser más constante con el documento Excel de Daily Meetings y describir de forma apropiada lo que he hecho cada día.
Tras haber recibido retroalimentación de los usuarios durante la fase de Beta Testing, se enumerarán y desarrollarán en este apartado las características más importantes implementadas para la fase final del videojuego:
Para la fase Beta no dio tiempo a incluir los controles y las mecánicas de Frozen Fury dentro del propio videojuego. Tan solo se indicaron en la propia página de Itch.io pero no conviene explicarlos en este apartado puesto que el juego se reproduce en pantalla completa y pueden pasar desapercibidos. En la versión final del juego se incluye un tutorial ilustrativo con las distintas acciones y controles que se pueden llevar a cabo durante el desarrollo de una partida.
A petición de muchos usuarios beta testers, se ha incluido un bestiario con la información de las acciones de los distintos monstruos que pueden aparecer durante el desarrollo de una partida. En cada apartado de cada monstruo, se incluye una descripción de sus acciones junto a la visualización de su modelo 3D.
Éramos conscientes de que el escalado de dificultad del juego era demasiado alto cuando se alcanzaban rondas cercanas a la octava. Se ha llevado a cabo un balance general del juego en el que se incluyen Nerfs de las estadísticas de daño de algunos personajes, mejoras de los edificables para que la partida no dependa en gran parte de las acciones del jugador para defender el objetivo principal, aparición aleatoria y mezclada de enemigos (previamente, aparecían pequeñas oleadas de cada tipo de enemigo en orden), reaparición más rápida de enemigos etc...
Otro de los aspectos importantes de los que carecía Frozen Fury era la falta de retroalimentación en las acciones del jugador y en las de los enemigos. Como se ha mencionado en el apartado de assets externos, se ha empleado unos efectos de partículas ya diseñados implementados de tipo cartoon que se relacionan con la estética del juego.
Se han añadido otras piezas musicales adicionales al videojuego como:
- Música de victoria y derrota.
- Efectos de sonido de impacto de proyectil en enemigo.
- Efecto de sonido de impacto de enemigo con objetivo principal.
- Efectos de sonido de comienzo y fin de ronda.
- Distinción entre música de entre rondas y de música de ronda.
Como se ha mencionado previamente en el documento, se ha establecido un total de 3 hitos fundamentales en el desarrollo del producto. Se deben cumplir en los plazos indicados y se estructuran de manera jerárquica, es decir, el comienzo de unos hitos dependen el cumplimiento de otros
El primer hito que el equipo de desarrollo debe terminar es una Fase Alpha del producto. En esta etapa se mostrarán las funcionalidades básicas del mismo, y se podrá terminar una partida entera, dejando ver al usuario el desarrollo completo del flujo principal de eventos en el juego. Existe la posibilidad de fallos en el producto durante esta fase, modelos 3d sin animaciones o texturas… que de cara a fases posteriores, se irán completando y mejorando.
El segundo hito que el equipo de desarrollo deberá completar es la Fase Beta del producto. Es de gran importancia que durante esta fase, se vea un producto prácticamente terminado. Los principales fallos de programación y aspectos que falten de arte se deberán completar y solventar debido a que el resultado de esta fase se pasará a un equipo de testing para evaluar el producto. Con ello, se recibirá la retroalimentación correspondiente para terminar de refinar el producto de cara a la fase final de su desarrollo.
La retroalimentación recibida sobre aquellos aspectos más importantes en el juego a modificar o mejorar es importante llevarla a cabo porque, una vez terminados los cambios, se deberá presentar el producto final a un Jurado de expertos que lo evaluarán en sus distintos aspectos de uso (mecánicas, jugabilidad, arte, gameplay design etc…). La fase final o Gold Master, es el hito previo al lanzamiento del producto al mercado.
El lanzamiento del producto está previsto para el 12 de Diciembre del 2021