La 7DFPS es una game jam de una semana de duración en la que los participantes han de crear un first person shooter con el objetivo de innovar y hacer que los FPS sigan siendo interesantes. Y da la casualidad de que este año he tenido a bien participar y dejarme los cuernos durante una semana para llevar a cabo un juego completo sin más ayuda que Google, un pack de Coca-Cola (Zero, para cuidar mi curvilínea) y el motor Unity. Mi meta ha sido revolucionar los FPS erradicando el ensayo y error. ¿Por qué? ¿Acaso hay algo de malo en el ensayo y error? No, nada de eso, es, sencillamente ¡porque puedo! [inserte su risa maligna preferida aquí]
De entre todas las propuestas de juegos en la 7DFPS hay juegos interesantes, extraños, divertidos y extraordinarios. Incluso el mismísimo Markus ‘Notch’ Persson se aventuró a hacer uno. Hoy os presento con orgullo mi modesta aportación y las idas de olla que me llevaron a diseñar Escape Sequence.
La reflexión inicial
Este verano he perdido bastante tiempo jugando a dos juegos: Un FPS, FarCry 3 (Ubisoft, 2012) y un survival horror, The Last of Us (Naughty Dog, 2013). Ambos son juegos muy buenos, muy entretenidos, muy poco indies, y desde cierto punto de vista, bastante diferentes. Sin embargo, caí en la cuenta de que siempre jugaba igual. Primero intentaba eliminar a unos cuantos enemigos de forma sigilosa, y cuando me pillaban, me liaba a tiros. Si me mataban, lo volvía a intentar de la misma forma, o variando un poco la estrategia, por ejemplo, el orden en el que atacaba a los enemigos. Tanto en FarCry 3 como en The Last of Us he podido seguir la misma estrategia. Y he terminado los dos juegos sin demasiados problemas, algunos niveles con más dificultad que otros, pero a la hora de la verdad sólo cambiaba el número de intentos que tenía que hacer para acabar.
Creo que esto se debe principalmente a que en este tipo de juegos influyen muchos factores: elementos azarosos, mecánicas que desafían tu habilidad (normalmente falible) y otros demasiado complejos para entenderlos al diseñar una estrategia con la que vencer el juego. Así que muchas veces no queda otra que jugar a ensayo y error. Pero me pregunto si es lo que los diseñadores querían que ocurriera.
La mayoría de los que jugamos a videojuegos tenemos muy mecanizado el ensayo y error. Estamos acostumbrados a tener varias (normalmente infinitas) oportunidades de hacer lo mismo, y lo aprovechamos. De tal forma que, si nos dan tres posibles estrategias para acabar una misión, en lugar de pararnos a pensar qué estrategia es la más adecuada intentaremos con una y, si no sale bien, pasaremos a la siguiente. Así hasta que algo funcione. Esto es un hábito que el propio diseño de los juegos durante años ha permitido y ha ido fomentando, por ejemplo, acortando la distancia entre check-points (hoy en día, la partida casi siempre se reinicia justo antes del momento en el que hemos perdido), por lo que suele ser mucho más eficiente intentarlo un par de veces a lo loco que andar parando a pensar.
La muerte permanente es una mecánica que consigue evitar gran parte del ensayo y error, ya que los errores se pagan y el jugador tiene suficiente que perder como para pensarse las cosas bien, lo que hace muy interesantes algunos juegos como XCOM: Enemy Unknown (Firaxis Games, 2012).
No digo que el ensayo y error sea malo, en absoluto. El que puedas perder e intentarlo de nuevo es la esencia de todo juego, y hay productos geniales que se basan precisamente en que hagas ensayo y error continuamente de forma masiva, como Super Meat Boy (Team Meat, 2010). Pero en la vida real la mayoría de las veces sólo tienes una vida, ¿se puede hacer un juego cuyo objetivo sea pensar antes de actuar? ¿Cómo evitar estos comportamientos de ensayo y error?
Tras una larguísima reflexión de varios minutos, llegué a la conclusión de que un juego que no tenga ensayo y error debe cumplir los siguientes principios:
- Sólo puede haber una estrategia correcta para cada situación. Seguir cualquier otra estrategia, significará perder la partida.
- Si el jugador escoge la estrategia correcta y la sigue, no puede perder. Hay que evitar, por tanto, eventos aleatorios, desafíos de habilidad, y cualquier tipo de mecánica que pueda dar resultados negativos durante la ejecución.
- El número de posibles estrategias tiene que ser muy alto. Si hay tres formas de hacerlo y sólo una correcta, el jugador probará hasta que encuentre la que funcione, pero si hay 1.000, forzosamente tiene que averiguar antes cuál es la buena.
Concepto
Partiendo de esas directrices, pensé que un juego que las cumplía razonablemente bien era escapar de un laberinto:
- Si es un laberinto suficientemente complejo, sería muy difícil encontrar la salida sin conocer el mapa, ya que el número de posibilidades es muy elevado, lo que cumple el tercer requisito. Si limitamos el tiempo, será casi imposible escapar sin conocer la ruta.
- Si además no hay enemigos ni trampas ni nada por el estilo, y no hay nada que evite que lo atravieses una vez conoces el camino, se cumple el segundo principio.
- Presentando al jugador el laberinto con anterioridad, se cumple el primer requisito: El jugador ve el mapa y puede hallar el camino correcto para después atravesarlo.
Mi primera idea fue ambientarlo en un edificio en llamas. El jugador tendría a su disposición el plano de evacuación de un edificio, y trataría de escapar antes de que el fuego lo echara todo abajo. Pero tras ver Oblivion y recordar lo que me gusta la ciencia ficción, decidí ambientarlo en una estación espacial que se está autodestruyendo al estilo del final de Alien: El octavo pasajero (hoy en día, todo el mundo sabe que las estaciones espaciales siempre tienen un dispositivo listo para hacerlas estallar, me pregunto cuál es el protocolo para activarlo en la ISS). Además esta idea era considerablemente más fácil de montar.
Se me ocurrió también encajarle una pequeña historia para dar interés a la búsqueda de un ítem que habría en todos los niveles, más allá de conseguir la típica medalla o estrella. Este ítem desvelaría la historia nivel a nivel, y contendría información esencial para acabar el juego. Inspirado por el No-one has to die (Stuart Madafiglio, 2013), decidí que el ítem mostraría un chat interno, en el que varios personajes comentarían la situación.
¿Qué fue bien?
- UN JUEGO REDONDO. Ha salido un juego bastante completo a pesar del limitado tiempo para hacerlo. Tiene siete niveles distintos, una mini-historia, una mini-cinemática final, menús, música, etc. Debido a la simpleza de la mecánica principal, que consiste en ir del punto A al punto B, pude dedicar más tiempo a introducir todos los elementos que se esperan en un juego, crear los niveles, los menús y pulir un montón de detalles.
- CIERTA CALIDAD GRÁFICA. A pesar de no ser modelador y no tener muchos recursos al respecto, conseguí un juego con cierta calidad gráfica. Pude perder los primeros días en buscar una estética que me convenciera y entrara dentro de mis posibilidades técnicas, modelando tiles para el escenario y adaptando las texturas de modelos cogidos de la demo Angry Bots incluida con el motor Unity3D, hasta que encontré un estilo que encajara con la temática del juego. Gracias a algún truco que aprendí con Unity (como cambiar el tamaño de la cuadrícula para que los tiles encajaran) pude montar todos los niveles sin demasiada dificultad, y a pesar de la repetición de modelos, creo que no quedó nada mal.
- ENTRE LOS MÁS POPULARES. El juego ha quedado como uno de los juegos más populares de la 7DFPS. Actualmente se sitúa en el puesto 13, lo que no está nada mal teniendo en cuenta que se subieron 282 juegos de los cuales están terminados 173. El juego ha salido destacado en un artículo de Rock Paper Shotgun dedicado a la jam y en el blog oficial de Unity. Es posible que sea gracias a haber publicado una primera demo del juego (bastante avanzada), a mitad de la jam, lo que me conseguiría unos pocos votos positivos haciendo resaltar mi proyecto entre los demás.
- SUPERANDO PROBLEMAS TÉCNICOS. Tuve la mala suerte de que mi ordenador de sobremesa reventara durante el desarrollo del juego. El Windows 7 dejó de arrancar debido a una partición de disco duro dañada. Afortunadamente, esa partición no era la importante, por lo que pude extraer el proyecto desde un sistema operativo alternativo (cosa que recomiendo tener) y pasarlo al portátil donde tengo casi todas las herramientas instaladas. Pude completar el desarrollo del juego desde el portátil sin haber perdido más que una mañana y parte de la tarde.
¿Qué fue mal?
- FALTA DE MODELOS GRÁFICOS. El primer problema fue la falta de modelos. Al no ser modelador y no haber contado con ayuda, he tenido poco tiempo para obtener modelos adecuados, por lo que todos los niveles se encuentran plagados de los mismos objetos, resultando bastante repetitivo todo. Tampoco dio tiempo a modelar tiles distintos que dieran un poco más de variedad, como el tile que quería hacer con una ventana al exterior.
-
- LA ESTACIÓN ESPACIAL. Desde casi el primer momento pensé en utilizar una estación espacial como escenario, y es lo que está en el juego, pero ahora, pensándolo más en frío, encuentro que tiene sus problemas. La idea encajaba con la posibilidad de hacer algún nivel con un laberinto en tres dimensiones y quitar la gravedad para poder recorrerlo sin necesidad de escaleras ni ascensores ni nada parecido. Sin embargo, no dio tiempo a montar ese nivel, por lo que desde ese punto de vista carece de sentido. Además tampoco es que la historia necesite de una estación espacial, y dado que no pude hacer los modelos adecuados, ni siquiera da la sensación de que lo sea. Parece más bien un laboratorio subterráneo, ya que carece de ventanas. Tal vez haberlo enfocado a eso hubiera sido una mejor idea desde un principio (eso sí la cinemática hubiera sido mucho más complicada de hacer).
-
PROBLEMAS GRÁFICOS Y DE RENDIMIENTO. Al girar ciertos tiles para formar los escenarios, las baldosas del suelo no terminaban de encajar perfectamente. Tras investigar un poco pude averiguar que el problema se debía a la forma en la que se realiza el normal mapping. Sin embargo, no tuve el tiempo requerido para investigar más a fondo y arreglarlo, o corregirlo directamente recolocando los suelos que salieran mal, lo que era mucho trabajo. También el uso de tiles en el Unity 3D ha dado lugar a algún otro problema gráfico (por mi culpa) al haber movido ligeramente algunos de ellos sin darme cuenta, por lo que en algunos lugares del juego se observan ranuras en las paredes.
Además, en algunos niveles (sobretodo en el Modulo E) se observan grandes bajadas de frame-rate. Mi impresión es que se debe al exceso de luces, ya que cada puerta tiene una luz del color identificativo del nivel, y al haber muchas puertas, puede que el rendimiento se viera afectado. Posiblemente todo se hubiera podido solucionar estudiando un poco más la configuración de la iluminación y el renderizado en el motor para optimizarlo adecuadamente, pero no hubo tiempo.
- PROBLEMAS CON LAS PLATAFORMAS. Hubo ciertos problemas con las versiones para distintas plataformas, comenzando por la versión de navegador. Uno de los plugins que usé (Detonator) para crear explosiones con facilidad, dejaba de funcionar en el navegador. Tras hacer una serie de pruebas, dí con la solución, pero durante el proceso me cargué la configuración de las explosiones de la cinemática que antes de corregir el fallo habían quedado un poco mejor. También existe un bug en la versión de Windows de escritorio, que impide que el juego vuelva al menú principal una vez se pierde o gana la partida. Esto no me dio tiempo a corregirlo, de hecho ni me di cuenta hasta pasados varios días, es lo que pasa cuando no haces el testeo mínimo.
Conclusión
Viendo jugar a la gente, puedo decir que el ensayo y error no ha sido eliminado por completo. Sin embargo, ha resultado un juego razonablemente divertido que pone a prueba tu memoria y orientación espacial en un escenario confuso y laberíntico. Precisamente creo que el que todo sea repetitivo es lo que hace que te puedas perder incluso habiendo estudiado bien el mapa, lo que, en esencia, es un desafío de habilidad que debería haber eliminado. Pero es lo que le añade el toque que le podría faltar de otra forma: El sentirte perdido y descubrir por sorpresa que no lo estás, es una sensación bastante divertida.
También me he dado cuenta de que casi nadie va al terminal de chat de primeras, incluso estando muy fácil de conseguir en el primer nivel. Quizá esto tiene que ver con lo de las distintas estrategias que comentaba al principio del artículo: una estrategia es atravesar el nivel sin pasar por el chat. Otra es ir hasta el chat y después a la salida. Como a priori no se sabe cuál es la correcta, y está claro que la más fácil es la primera, esa es la que escogen casi todos.
Hubiera sido muy interesante generar algún nivel con un laberinto tridimensional, lo que añadiría sin duda un nuevo giro en el reto del juego. Sin contar con eso, no da para mucho más: Más niveles podrían ser tediosos, y añadir más mecánicas hubiera ido en contra de las premisas iniciales. Por otro lado, la mecánica base por sí sola puede ser un añadido interesante para algún otro juego, obligando al jugador a memorizar el mapeado con anterioridad. Tal vez veamos un nivel así en FarCry 4. Bah, seguro que no.
7DFPS
Escape Sequence
