top of page

El postmortem está dedicado específicamente al proyecto de titulación Tinkerers Inc. y en él se abordan las problemáticas que se enfrentaron durante el desarrollo del juego, cómo fue que se resolvieron y todas aquellas que tampoco se resolvieron.

 

RESUMEN DEL JUEGO

​

Tinkerers Inc. es un twin-stick shooter para uno, dos, tres o cuatro jugadores con vista cenital en tercera persona que usa un sistema de crafting llamado Toolbox mediante el cual el jugador puede crear armas más poderosas. También debe resolver puzzles sencillos en el que todos lo jugadores deben participar para resolverlos.

​

El diseño de niveles implementa una verticalidad nunca antes vista en el género que propone un cambio en la manera en que se aborda el gameplay a través de a implementación de nuevas mecánicas que haces uso de dicha característica.

​

El juego fue desarrollado durante 9 mese a partir de abril del año 2018 y se libreró en Gamejolt y Itc.io en diciembre del mismo año.

 

BACKGROUND

​

  • Sebastian Ari de la Brena Meza: Modelado de Escenarios, Objetos y Niveles, Iluminación y Concept Art.

  • Gerson Luis Mastachi Ramírez: Modelado y Animación de Personajes.

  • Mauricio Fuentes Martínez: Programación y Diseño de Niveles.

  • Jorge Sinaí Gutiérrez Carpio: Modelado de Main Menú y Diseño de Interfaces.

 

TOOLING

​

Unity Engine Student Version

Maya 3D - Autodesk

Substance Painter - Allegorithmic

Adobe Photoshop

Adobe Illustrator

Lenguaje Utilizado: C#

 

RESUMEN DEL PROCESO

​

La primera etapa del desarrollo constó de toda la conceptualización del proyecto: primero se decidieron las mecánicas principales con las que contaría el juego y se comenzó a desarrollar una versión ALPHA del proyecto para comenzar con las pruebas. Después se realizaron exploraciones de personajes, enemigos, escenario y armas para poder comenzar con la elaboración de los artes de concepto.

​

En los mese siguientes se pulió el prototipo con el que se contaba hasta llegar a una versión BETA y se realizaron un par de pruebas de concepto y usabilidad. Al término de estas se comenzaron a crear todos los elementos 3D y 2D del juego a partir de los artes de concepto. Para este prototipo ya se contaba con la integración de algunos niveles y la mayoría de las interfaces por lo que el resto del proyecto se enfocó a encontrar errores y hacer pruebas de gameplay.

​

Para el producto final se integraron las animaciones de los personajes y audio y se mejoró la iluminación de los escenarios. Para este build el juego estaba funcional con algunos problemas que no competían a la experiencia. Se entregaron cuatro niveles que constaban de un tutorial, dos niveles con hordas de enemigos y puzzles y una secuencia final de batalla con un jefe.

 

MODELADO DE PERSONAJES

​

- Lo que salió bien:

 

El modelado de los personajes 3D se puede considerar un éxito. Las animaciones se pudieron lograr a partir de una buena topología en el caso de los niños, aunque sí hubo algunas con problemas por la construcción de los rigs.  Los enemigos al ser robots fue fácil pensar en su estructura, por lo mismo, muchas de sus partes están divididas en módulos. El jefe final, al ser un cubo, no tiene tanta complejidad en su modelo lo que también ayudó en el momento de realizar las animaciones para éste.

​

Los modelos estuvieron bien escalados para que su transición al motor de juego Unity fuera mucho más sencilla y se pudieran adaptar a los modelos de las armas y modelos de escenarios.

​

- Lo que no salió bien:

 

Por la naturaleza del juego (Top Down Shooter), los modelos del juego se verían a una distancia considerable de la cámara. Sin embargo, consideramos que los modelos de todos los personajes pudieron tener un trabajo más detallado. Por ejemplo, a los niños les faltó una cara que tal vez al estar  jugando no se hubiera notado, pero el hecho de que estuviera ahí sería mejor. Por lo mismo, los conceptos de arte de los personajes no quedaron exactamente igual con los modelos 3D, aunque en esencia el concepto sí se respetó.

​

Se pensó en un momento en tener cuatro niños diferentes, pero por motivos de tiempos se dejó esa idea.

 

MODELADO DE ESCENARIOS Y CONCEPT ART

​

- Lo que salió bien:

​

El diseño de producción con base en Hack n´ Plan resultó efectivo, tanto para registrar horas como para la asignación de tareas. Es una gran herramienta para mantener bien organizadas todas las tareas y así tener un ritmo durante todo el desarrollo.

​

El tiempo de conceptualización ayudó a formar las bases del aspecto visual del juego.

Al modelar los objetos se creaban los UVs así para variar las tareas y no tener que hacer todos los mapas de un golpe.

​

Los modelos terminaron fieles al concept art tanto en forma como en texturización.

Se terminó a tiempo los niveles principales, esto dio la oportunidad de continuar la generación de contenido.

De tres niveles en desarrollo se terminaron haciendo cuatro.

​

- Lo que no salió bien: La escala de los escenarios contra la escala de los personajes.

​

Variación de tamaños entre los niveles, unos niveles más pequeños que otros.

​

Durante el desarrollo se fueron creando nuevas ideas incluso ya cuando los escenarios finales estaban terminados, esto causó el regresar al nivel de conceptualización para crear el nuevo contenido y como consecuencia el tiempo que se perdió al hacer estos niveles.


 

DISEÑO DE NIVELES

​

- Lo que salió bien:  

 

Una de las propuestas del proyecto fue añadir verticalidad al espacio de juego para diferenciar el diseño del nivel del resto de juegos top-down que limitan el diseño de su espacio a solo un nivel de piso sin contar con  variaciones en la altura por lo que el movimiento del jugador queda restringido en los ejes X y Z sin aprovechar de forma significativa el Y para oportunidades de gameplay, por lo que se  optó diseñar espacios que añadieran verticalidad al nivel para el diseño de este fuera una propuesta de valor del juego cosa que usualmente no es el caso en este género ya que toda su propuesta radica en las mecánicas.

​

El juego consta de cuatro niveles, los primeros dos fueron diseñados con las convenciones del género, es decir sin variaciones de altura en el acomodo de piso eso fue hecho para acostumbrar a los jugadores a las mecánicas del juego en un espacio familiar a las convenciones del género en el tercer nivel fue cuando se introdujeron espacios verticales en el juego.

​

La problemática fue adaptar el disparo a espacios verticales y es la razón por la cual varios juegos omiten la verticalidad en juegos del género debido a que su esquema de control y visión impide un control directo sobre el ángulo de disparo.

 

Al disparar en un terreno con cierta inclinación el disparo no se adapta a esta la forma en la que se solucioné esta problemática fue implementando un raycast emparentado al jugador con dirección hacía el piso (-y) y al chocar con el suelo se obtenía el ángulo de inclinación del piso del nivel, dicho parámetro se le indicaba al objeto padre que controlaba la posición de las armas para que todas fueran inclinadas con respecto al ángulo del piso en el que estuviera posicionado el jugador: https://youtu.be/MPIvvRss5_c

 

Disparo Adaptado a los inclinaciones del nivel representación de la función del raycast implementada en el juego, el rayo (línea azul) se origina desde el centro del jugador, cuando este choca con una superficie obtiene el ángulo perpendicular al esta y el jugador lo que hace que el ángulo siempre apunte a la dirección de la rampa, dicho ángulo se le transmite al personaje del jugador para que apunte en la dirección que este indica.

 

Solamente los extremos de la rampa tienen 30° en dirección relativa al personaje (punto rojo), pero cuando el jugador rota en la rampa el ángulo cambia, lo que hace que la dirección de disparo no se adapte en las diagonales de esta al ser de 15°

 

El adaptar la dirección de disparo a espacios inclinados nos dio más libertad de crear espacios de juegos más dinámicos al eliminar una limitante común dentro del género.

 

- Lo que no salió bien:

 

A pesar de que se logró implementar un sistema que hacía que el disparo se adaptara a los espacios verticales del nivel a los jugadores se les hizo incómodo el espacio diseñado para acentuar la verticalidad del espacio por los siguientes factores:

 

  • La proximidad del nivel se pierde conforme a más jugadores se encuentren activos: El juego soporta desde uno a cuatro jugadores por lo que la cámara tiene un nivel de zoom dinámico en  comparación de juegos del género donde únicamente se tiene a un solo jugador, la manera en la que funciona es que la cámara calcula un punto en el espacio donde pueda tener en encuadre a todos los jugadores, lo ocasiona que la cámara se acerque,entre más cerca estén los jugadores entre ellos y se aleje más mientras ellos estén más separados. La cámara fue diseñada así por cuestiones de usabilidad para que los jugadores tuvieran a la vista a sus personajes todo el tiempo.
    Sin embargo, la cámara resultó ser contraproducente a los niveles verticales del juego debido a que al alejarse ocasiona que la profundidad del espacio se pierda, lo que desorienta a los jugadores y que ocasionó esfuerzo cognitivo mayor solamente para percibir la posición de su personaje en el nivel 2 (nivel donde se llevó a cabo la hipótesis) debido a que era difícil poder percibir a su personaje en el espacio.


 

  • Complica la retroalimentación del juego: Algo que notamos al hacer el juego es que los juegos top-down shooter requieren de uso de iconografía constante para indicar acciones o estados del jugador. Por ejemplo recargar un arma es una de las acciones más comunes en juegos de disparos y el sistema de retroalimentación más usado para indicar al jugador que la está llevando a cabo es una animación, cuando esta se activa indica al jugador que ha reconocido el input de la recarga, la duración de esta indica cuánto tiempo el arma no estará disponible hasta que esta finalice, es una forma diegética, es decir dentro del contexto del juego, de indicar retroalimentación.
    Sin embargo, en juegos top down aunque hay animaciones de este tipo generalmente es difícil que el jugador se percate de estas debido a la dificultad que le ocasiona leerlas por la posición alejada de la cámara, en nuestro juego se tuvo que implementar una barra que aparece una vez se inicia una recarga encima del personaje y se llena conforme esta se lleva a cabo, lo mismo ocurrió con el sistema de construcción de armas, el indicador siendo un círculo que llena su área conforme al tiempo e indica que la acción terminó hasta que éste se llena por completo. Elementos de este tipo ayudaron  a los jugadores a leer mejor el estado de sus personajes debido a que sin estos indicadores no tenían claro muchas veces las acciones que ellos mismos habían activado.
    Sin embargo, el problema anterior está relacionado a este debido a que la cámara al adaptarse al encuadre hace que los jugadores pierdan la lectura de los íconos y por consecuencia se les dificulte la retroalimentación del estado de su personaje.


 

Todos estos fallos se atribuyen principalmente a que los niveles con verticalidad se construyeron en un sentido perpendicular a la cámara, la mayoría de la orientación de estos era paralela a la posición de la cámara que fue la razón por la cual los jugadores se desorientaron en el espacio, en especial cuando disparaban al no saber de forma inmediata la dirección de este. Sin embargo en los pocos espacios perpendiculares a la posición de la cámara se reportó que la retroalimentación tanto como de posición en el espacio y orientación del disparo era mucho más clara. También la escala debería ser mucho mayor, un fallo en el diseño es que los espacios creados para probar la verticalidad en el proyecto era relativamente pequeña al tamaño de los personajes jugables, que tenía una fuerte estética en términos de peso visual pero en términos jugables frustró a los jugadores.

​

También otro fallo fue la escala de los espacios verticales ya que resultó demasiado estrechas para el gusto de los jugadores debido a que limitaba el movimiento de forma innecesaria.

 

En la imagen superior el espacio está posicionado de forma perpendicular a la posición de la cámara.

​

Percibir la inclinación del espacio y la posición del jugador sobre este se dio de manera directa en los jugadores, mientras que la imagen inferior cuando el espacio está posicionado de forma paralela a la cámara  ambos criterios resultan más difíciles e incómodos de identificar, el problema de tinkerers fue que se le dio preferencia a este acomodo de elementos verticales y no al primero.

​

ANIMACIONES

​

- Lo que salió bien:

 

Las animaciones representa de buena manera los estados del jugador y de los enemigos.  En un principio, se tenían en mente menos animaciones de las que realmente se usaron.

​

Les ayudó a los modelos a darles más personalidad. El jefe fue el que más se benefició de esto ya que era un cubo. Estas animaciones hicieron que sus estados y ataques fueran sencillos de entender por los jugadores.

​

- Lo que no salió bien:

 

Al ser animadores primerizos, hubo procesos que no salieron del todo bien al momento de llevar las animaciones de los modelos al juego. Las animaciones pueden mejorar mucho, sobre todo las de los niños y los enemigos robots. Los riggings de los personajes son muy básicos, lo cual limita mucho el potencial del modelo para ser animado. También los pesos de estos riggings no fueron los mejores, haciendo imposible posar a los modelos en posiciones específicas.

 

ILUMINACIÓN

​

- Lo que salió bien:

 

La luz terminó fiel al concept art, esto gracias a la correcta concepción desde los conceptos.

​

El postprocessing aportó soporte visual para mejorar la calidad general.

​

Las herramientas de luz de Unity son suficientes para obtener una buena calidad.

​

La calidad general del juego es buena.

​

- Lo que no salió bien:

​

Falta de tiempo y dedicación en el producto final, durante el tiempo de planificación, no se tomó en cuenta la aplicación de la luz en el juego y esto afectó al resultado final.

​

Efectos de luz aplicados al juego como la luz volumétrica y niebla no se cargaron en el ejecutable final.

​

La saturación y brillos terminaron distintos para así mejorar la experiencia de jugabilidad. En un principio el juego era más oscuro pero era incomodo al jugar.

​

Durante el desarrollo, la iluminación se trabajó simultáneamente a la programación, se incluyen mapas de bakelights pero al importarlos al proyecto madre se perdieron y se tuvo que rehacer todo este apartado.

 

UI

​

- Lo que salió bien:

 

Como se planeó el diseño de las interfaces contó con características minimalistas y simples para que no intervinieran y no sintieran invasivas con la acción frenética del gameplay. Se crearon 4 modelos diferentes de Toolbox del el Sistema de Combos para poder diferenciar a todos los jugadores, se les asignó un color a cada una (rojo, azul, verde y amarillo) y una calcomanía que no interfiere con la lectura de los íconos para darle personalidad a cada una de ellas.

​

Se le asignó un ícono a cada una de las opciones del crafting que retratara su personalidad de la mejor manera y se jugó con el acomodo de los elementos para tener una interfaz más limpia y concisa.

​

El Menú Principal se construyó lo más diegético posible por lo que se modeló una mesa de trabajo que encajó muy bien con estilo general del juego y se incluyeron assets finales como algunas armas, herramientas, la batería de los generadores y el blueprint que sirvió para los cambios de canvas y fungió como base de experimentación con las ilustraciones del menú: se generaron 3 ilustraciones dedicadas a cada opción (Start, Options, Exit) del juego con un estilo de dibujo a mano.

​

Se implementó un sistema de partículas e iluminación que dotó al menú de más realismo

​

- Lo que no salió bien:

 

Al final el tamaño de las Toolbox no fue el adecuado ya que los elementos indicadores de armas, munición y scrap no son los suficiente visibles para el jugador y se sienten amontonados por el poco espacio con el que se cuenta. También faltó feedback en el sistema de combos al introducir un combo mal ya que las flechas sólo cambian al color gris y es difícil distinguir cuando alguien se equivoca.

​

Por otro lado lado los globos de texto del tutorial resultaron no tener el tamaño adecuado ya que los textos son pocos visibles y el jugador no le presta la atención debida por lo que algunas mecánicas no son del todo explicadas.

Sae.png
bottom of page