30 de septiembre, 2013
Artículo indiespensable
Indiespensable
Ensayo y error: «Escape Sequence» 7DFPS post-mortem
Ensayo y error: «Escape Sequence» 7DFPS post-mortem

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.

The Last of Us

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.

ModuleCMapMi 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.

Espectro

¿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).

      TextureGlitch

      • 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.

      Espectro

      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

Acerca de Enrique Hervás


Humano Nivel 32. Diseñador y Programador de videojuegos Nivel 6. De esos a los que sus padres prohibieron jugar a "las maquinitas" por estar demasiado enganchados. No sabían lo que les esperaba. Actualmente trabajo como Game Designer en Exient, e intento no olvidarme de mi pasado indie de Game Jams y jueguitos con Join2 Games

6 comentarios
  • [Chapa ahead]

    Veo la reflexión de la que parte la entrada y me parece genial como planteamiento filosófico y como muestra de análisis profundo a la hora de plantearse la experiencia de los jugadores. La cosa es que tengo dos pegas, o comentarios, y quiero dejarlos por aquí: a) ¿No cumple cualquier juego tipo Puzzle con las tres premisas? Quizá ‘cualquier’ no es la palabra, pero sí para puzzles con escenarios diseñados. Son puzzles con una solución única (generalmente) por nivel, no hay habilidad usualmente (basta con elegir una pieza, configurar elementos del mapa, etc.) y si hay suficientes elementos en pantalla que sean accionables, también se cumple la premisa. Se me ocurre un juego para móviles llamado Bubble-algo, donde resuelves puzzles rompiendo bolitas de colores. En un mapa de 10×10 tienes 100 huecos con bolitas que puedes romper o desgastar y el escenario puede resolverse con 4 o 5 toques muchas veces. Lo comento como ejemplo ‘más sencillo’ que el que has expuesto con tu juego por destacar que creo que hay muchos juegos que, por su naturaleza, se enfrentan al ensayo y error aunque no sea un objetivo expreso en su diseño.

    Creo que el asunto de evitar el ensayo y error hay que confrontarlo con lo básico: la diversión. Imaginemos que tuviésemos una base de datos enorme con una clave personal intransferible, segura, blablabla. Al conectarnos a cualquier juego, consulta esa clave y nos repone un estado concreto en ese juego. Algo así como partidas grabadas que no podemos modificar y que evitan el volver atrás en el tiempo. ¿Sería eso divertido para una gran cantidad de juegos y jugadores? ¿No causaría frustración a alguien que busca echar el rato y que, generalmente, ha pagado por un juego y busca desestresarse, desentrañar una historia o sentirse bien en general?

    El caso más flagrante de no poder hacer ensayo y error lo vi hace años en un juego flash en el que jugabas como francotirador. Debías acertar entre varios posibles objetivos del escenario. En cualquier caso, cuando disparabas, matabas a alguien. Si volvías a cargar el juego, ese aparecía muerto desde el comienzo de la partida. Era un experimento/excusa para ver la reacción de la gente ante el afrontar las consecuencias de nuestras acciones y me parece muy representativo de lo que explicas en el post. Desgraciadamente no me acuerdo ni de como se llama ni de donde lo vi.

    Bueno, espero que la parrafada se entienda como positiva, porque el post me ha hecho pensar.

    Saludos.

    • Enrique Hervas

      Efectivamente, hay ciertos tipos de juego que no invitan al ensayo y error. Es más, yo creo que un puzzle bien diseñado debe evitarlo por completo: se trata de que reflexiones y halles la solución, no de que pruebes a lo loco hasta que te salga por potra. Otro ejemplo de juegos que tampoco suelen invitar al ensayo y error son las aventuras gráficas. Sin embargo, no pasa tan a menudo en los FPS, que es de lo que trata la jam. Pongamos a Portal por ejemplo, es un juego FPS de puzzles, y en ciertos niveles en los que no puedes morir se evita el ensayo y error por completo, sin embargo hay otros en los que una vez resuelto el puzzle no tienes más remedio que intentarlo varias veces hasta que salga, ya que tienen un componente de habilidad bastante acentuado. Lo interesante aquí es que el puzzle no lo puedes resolver por ensayo y error, el ensayo y error viene en la ejecución. Una cuestión interesante también es: ¿se puede considerar Escape Sequence como un juego de Puzzle?

      En cualquier caso, lo de intentar evitar el ensayo y error no es más que una forma de hacer diseño basado en restricciones, que suele dar buenos resultados cuando tienes bastante libertad para hacer algo.

      • Ahora es cuando yo me leo de qué va la Jam y comento en consecuencia :)

        Me había planteado el caso general, no sólo FPS. De hecho, fui a poner como ejemplo Portal, pero en Portal si se requiere habilidad y a veces puedes resolver de un par de formas. Por ahí me he escapado en el comentario.

        La vuelta que le das es la lógica: ¿es tu juego un puzzle FPS? Yo, por lo que cuentas y por el diseño, diría que sí.

  • israel

    Lo de evitar el ensayo y error no creo que dependa del juego, más bien depende de la capacidad del jugador. Por ejemplo, he probado tu juego y realmente lo que fuerzas es la memoria, el jugador tiene que memorizar el mapa y ejecutar el camino. Los primeros niveles son faciles obviamente, solo tienes que girar 2 o 3 veces y es facil memorizarlos completos.

    ¿Pero que pasa en los niveles altos?

    Pues pasa una cosa muy sencilla, que el jugador cuando va por la mitad del nivel olvida el mapa.

    ¿Y que pasa después?

    pues ensayo y error.

    Con esto me refiero que el hecho de que el jugador no use el ensayo y error depende del jugador y no del juego. En tu juego yo llegue al tercer nivel sin usar ensayo y error (lo sé, soy torpe) pero seguro que hay muchos jugadores que llegan al quinto o sexto antes de usar el ensayo y error y esta claro que el juego es el mismo para todos.

    Y creo que esto se puede llevar a cualquier juego de puzzle, el jugador piensa y ejecuta por defecto hasta que ya no sabe como solucionar el puzzle (o se le olvida en el caso de tu juego). Acabo con esta frase, las pruebas empiezan cuando se terminan las capacidades del jugador.

    Buen post, hace pensar.

    • Enrique Hervas

      No sólo es que te olvides del camino, sino que también ocurre que el propio escenario te desorienta al ser prácticamente igual y sin ninguna referencia visible, ni nada que te indique si estás avanzando de forma correcta.
      Si de verdad no hubiera nada de ensayo y error, básicamente jugarías hasta llegar a un punto en el que directamente no tendrías capacidad para seguir por muchas veces que lo intentaras (a no ser que mejoraras tu habilidad para orientarte y recordar el camino). Y en realidad ese era el objetivo inicial, pero ¿sería divertido? ¿es capaz este juego de hacerte mejorar esas habilidades lo suficiente para engancharte? Para comprobarlo tal vez serían necesarios laberintos más grandes y generados proceduralmente, para que no puedas aprendértelos.

      • israel

        ¿Puede arkanoid mejorar los reflejos? ¿Puede LOL mejorar tu velocidad mental? ¿Puede track and field mejorar la velocidad de tus manos?

        Siempre que fuerces una capacidad acabará mejorando. Si yo que en el tercer nivel llego un momento que me perdi, seguro que si juego X veces más podría mejorar mi memoria fotografica.

        Lo de hasta que punto se podría mejorar las habilidades sin que el jugador se aburriese depende de los gustos del jugador. A mi los laberintos me gustan, pero quizas a otro jugador que repita 2 o 3 veces el mismo laberinto sin pasarselo se aburra y deje el juego. Es como tirar de una cuerda hasta que se rompa.

        Molaría un post/debate de este tema “Cuanto es capaz de aguantar un jugador antes de mandar el juego a la mierda” ;-)