¿Olvidates tu contraseña?

Postmortem – [Almost] One Room – Ludum Dare #37

2016-12-23
No hay comentarios
Ludum Dare #36 fue una edición especial para mi. Estaba en mi pueblo, a 1400m de altura, sin apenas conexión a Internet (solo una débil señal WiFi del ayuntamiento, sin cobertura de móvil). Estaba sólo, y quería aprovechar la jam para aprender Unity3D. Dediqué los días anteriores al evento a mirar vídeo tutoriales y pude completar un pequeño juego.

 

Creando [Almost] One Room quería repetir con el espíritu de aprendizaje. Pero esta vez no estaba sólo, uní fuerzas con Carlos Coronado (@CarlosGamedev), el creador de MIND: Path to Thalamus y extraoficialmente evangelista de Unreal Engine. También es amigo mío y uno de mis clientes. Aún recuerdo cuando un chavalín de 16 años llegó a los foros que tenía por entonces y que hoy son parte de ZehnGames preguntando si había algún proyecto al que unirse para aprender; hicimos un sistema de barricadas para L4D. Ahora soy yo el que le pide ayuda.

La idea era simple, yo me encargaría de “programar” (con blueprints) y Carlos se encargaría del arte y de enseñarme lo básico del motor y a ayudarme cuando me quedara encallado y ¡sorpresa!, fue muchas veces.

De hecho no abrimos UE4 hasta la tarde del primer día porque Carlos llegó muy tarde, de modo que dediqué toda la mañana a tomar notas en papel, jugando con ideas con el tema de la Ludum (One Room) en la cabeza.

Cuando Carlos apareció le presenté la mejor idea a la que había llegado y preferimos dedicarle tanto tiempo como fuera posible a la fase de diseño.

ludum-dare-almost-one-room-notepad-videojuegos-zehngames

Queríamos hacer un juego de puzles alrededor del concepto de los room escape. Para mi era muy importante encontrar un giro a la temática de la Ludum, ir más allá de la elección obvia y es por ello que no quería hacer un juego sólo con una sala. Jugué con ideas como darle la vuelta a las palabras, “¿Qué hay tras la Sala 1?” o “Tú eres la sala”, partiendo de los mapas “rats” de CounterStrike intenté encontrar una forma de ir más allá haciendo que los jugadores no fueran humanoides. Por último encontramos algo en la idea inicial de room escape que nos gustó, solo una sala, pero muchas veces.

La idea inicial era dejar al jugador encerrado en una habitación como en un room escape clásico, pero una vez habría la primera puerta, te ibas a encontrar con la misma habitación otra vez. Con este punto de partida empezamos a pensar qué debería hacer el jugador para abrir las puertas, desde ganzúas con mini-juegos hasta encontrar varias piezas de un aparato, pero era difícil encontrar algo realmente divertido o que el jugador no pudiera resolver por prueba y error. Y más importante, algo que se pudiera hacer en el plazo de tiempo que teníamos. Plazo que ya había sido más corto por la tardía incorporación de Carlos, y porque el lugar donde lo hicimos, las instalaciones de ENTI, cerraban a las 20h y nos auto-impusimos no hacer horas de más, nada de crunch cuando la idea era divertirse y aprender.
Llegado cierto punto pensábamos que lo teníamos, la habitación sería “la misma” pero en diferentes líneas temporales, pasado, presente y futuro, y debías hacer cosas en una época que cambiaba las otras y de esta forma acabar desbloqueando la puerta de salida. Era genial, pero fue imposible encontrar algo que el jugador pudiera entender y no se convirtiera en una experiencia frustrante. Por pensar, incluso habíamos jugado con árboles genealógicos donde al cambiar en el pasado una foto cambiabas los descendientes, o incluso dejaban de existir. Pero como digo, imposible transmitir eso fácilmente.

ludum-dare-almost-one-room-screenshot-videojuegos-zehngames

Se nos acababa el tiempo y al final volvimos al inicio. Decidimos seguir el principio KISS (Keep It Simple Stupid) y hacer un juego de puzles más simple: Encuentra la combinación de la puerta de salida. ¿El giro? El número estaría oculto en las salas, un número por sala, cada sala la misma con pequeñas variaciones.

 

Empezamos pensando como esconder los números y teníamos claro qué queríamos ir más allá de el evidente esconderlos tras los muebles. Queríamos que el jugador pensara “out of the box”, y nuestro principal miedo era que fuera demasiado difícil entender los puzles. Con las restricciones de tiempo de un jam lo más difícil es equilibrar la dificultad, y teniendo en cuenta lo subjetiva que ésta es en un juego de puzles, la única forma de saber cuán complicado es, es que lo pruebe gente, y no teníamos a nadie.

Lo primer que hicimos fue dibujar una habitación genérica con cuatro puertas, una por muro, pero no en el centro. Las habitaciones en la vida real no suelen tener la puerta en el centro, se pierde espacio y desde un punto de vista de jugabilidad, puede limitar qué puedes colocar y pueden comprometer la facilidad de paso.

almost-one-room-postmortem-room-videojuegos-zehngames

Por otro lado empecé a “programar”. Para los qué no hayan trabajado aún con Unreal Engine 4, tiene un sistema de programación visual llamado blueprints. En el editor podemos crear lógica conectando cajas; por ejemplo, tienes el nodo “branch“, recibe una expresión booleana y tiene 2 salidas, una para verdadero y otra para falso, el flujo del código irá por una salida en función de cómo se evalúe la expresión, tal como un estamento if-else de programación tradicional.
Lo primero que programé fue el selector de número que el jugador usará para colocar los números de la combinación. La idea es simple, habrá una caja de colisión para saber si el jugador está bien situado para interactuar con el selector y, cada vez que le de al botón izquierdo del botón, aumentaremos el número hasta 9, y entonces, volveremos a 0. Además, necesitaremos varios de estos selectores ya que la combinación tendrá 5 números y cada selector le permitirá elegir un número del 0 al 9. Para poder reutilizar estos assets crearemos una Blueplint Class, algo como una clase en orientación a objetos, qué agrupa código y otros assets. En la blueprint class de nuestro selector de número tendremos una mesh de caja, un widget de texto, la caja de colisión y el código en sí. Podremos instanciar tantos como necesitemos y acceder a sus variables públicas locales para interactuar desde el level blueprint.

almost-one-room-postmortem-blueprint-videojuegos-zehngames

Seamos sinceros, llevo más de 15 años programando y el cambio mental que tienes que hacer para trabajar con blueprints es destacable. No por dificultad, en el fondo no deja de ser lógica aplicada e importa poco si es una cajita o un bloque de código, sino por cómo debes crear el flujo de ejecución. Me es complicado explicarlo porque no es algo concreto. Por ejemplo, para el selector de número necesitamos incrementar la variable interna entera que guarda el número actual, algo que podemos hacer en una línea de código ( this.number = (this.number+1)%9) en blueprints requiere de unos pocos nodos: un getter para recuperar el valor de la variable, luego incrementar el valor, entonces hacer el módulo y finalmente guardarlo en la misma variable. Se puede hacer con menos pasos con un nodo de tipo Math Expression, pero es por poner un ejemplo. Lo que intento explicar es que incluso sabiendo programar la curva de aprendizaje del motor es elevada, especialmente cuando se trata de moverse por el editor debido a su cantidad de botones, ventanas y pestañas.

Volviendo al tema del diseño de puzles, decidimos que íbamos a necesitar enseñar al jugador qué tiene que encontrar números. Por esa razón cerramos las cuatro puertas de la sala inicial blanca y pusimos un código inicial. El primero es el más fácil, con un 35 gigante de color negro en el techo, solo parcialmente oculto haciendo que parezca una mancha de humedad. Al cerrar al jugador también obtuvimos un momento de sorpresa al abrir las puertas y encontrar la misma habitación una y otra vez.

 

almost-one-room-postmortem-35-videojuegos-zehngames

En cuanto Carlos me había enseñado lo básico de los blueprints y el sistema de eventos empecé a preparar el mecanismo de apertura de la puerta. Por su lado Carlos estaba trabajando en los assets que íbamos a necesitar, muebles, puertas, etc. Necesitábamos que fueran funcionales y fáciles de crear y, ¿qué muebles son los más genéricos, fáciles y reusables del mundo?

(Advertencia, ninguna marca o compañía nos ha pagado por hacer nuestro juego). 

¡IKEA por supuesto! :V

Aprovechamos el vertex painting de UE4 para pintar cada habitación, un material con un parámetro de color para algunos de los assets, lo que nos daba un potencial brutal para tener todas las habitaciones con un impacto mínimo de rendimiento y ahorrando un montón de tiempo.

La única textura aplicada era un ambient oclussion precalculado para darles ese pequeño sombreado.

Por último, para crear los puzles usamos varias técnicas. Para el de distancia es un simple material cuya opacidad varía en función de la distancia a la cámara. Algo similar ocurre con el de los reflejos, hay una copia de la habitación debajo y el suelo usa un material que cambia su opacidad usando una función Fresnel. Queríamos que los detalles que cambian de sala a sala fueran la pista que ayudara al jugador a resolver el puzle. Por ejemplo la sala azul es la única que tiene 2 lámparas, o la verde, qué es la única en que la estatua es diferente.

Y esto es todo, querríamos haber puesto más contenido, pero estoy contento porque el producto mínimo que nos habíamos planteado fue entregado tal y cómo lo imaginábamos, y el proceso era lo suficientemente bueno que si hubiéramos tenido más tiempo, podríamos haber creado más material rápido, siendo por tanto el diseño de nuevos puzles lo que más tiempo nos hubiera consumido.

 

Muchas gracias por leer hasta aquí, probad el juego y comentad, ¡necesitamos vuestro feedback!

 

Inicio Foros Postmortem – [Almost] One Room – Ludum Dare #37

Viendo 1 publicación (de un total de 1)

Debes estar registrado para responder a este debate.