Raph Koster: Cómo analizo un juego (parte I)

Esta semana os dejamos con la primera parte (de 2) de la traducción de un artículo de Raph Koster, lead designer entre otros de los MMORPG Ultima Online y Star Wars Galaxies y autor del libro sobre game design "A theory of fun". Sin más, os dejamos con ello.

Lo primero que hago es ignorar la experiencia de juego. Es solo relativamente útil dado que la experiencia del usuario es subjetiva. Oh, me gustaría pensar que de algún modo es más valiosa mi experiencia que la de un jugador típico. Después de todo, tengo un set muy específico de experiencias que puedo aportar. Pero en la práctica, lo único que hace es que mi opinión esté bien informada, pero que sea menos útil.

Si uno mira a la experiencia es como mirar la cima de una montaña sin conocer las placas tectónicas. Uso esa analogía porque la típica es la de la punta del iceberg, pero un iceberg es sustancialmente parecido por encima y por debajo del agua. Sí, hay mucho más bajo el agua, pero no es diferente en su naturaleza. Cuando miramos al mundo, lo que vemos, lo que experimentamos, está formado por cosas que no vemos. Sin entender la actividad volcánica, o las fallas, o todo lo demás, no acabaremos de entender por qué una cordillera está donde está y por qué toma esa forma u otra diferente.



Eso es por lo que empiezo con las cosas "bajo" la experiencia. Mecánicas, inputs, procesos, reglas y acciones. Quito la supreficie hasta que Gone Home es un juego sobre dar vueltas a cartas en una mesa para ver qué hay debajo. Papers, please es un juego de "Encuentra las siete diferencias". The Stanley Parable es un "elige tu propia aventura" donde algunas de las opciones están escritas en tinta invisible.

En todos estos casos ignoro gran parte de las cosas que haces en el juego, de momento. El movimiento en The Stanley Parable no es siquiera un medio para un fin el 99% de las veces. Son ciclos de decisión vacíos que existen solo por tener una experiencia.

¿Cuáles son los sistemas?

Ahora puedo examinar la mecánica principal. Existen grandes posibilidades de que la haya vitso antes. De hecho, las mecánicas nuevas son raras en el game design. Pulsa un botón antes de que se acabe el tiempo. Mueve algo de un sitio a otro. Escoge ir en una dirección u otra en un entorno simulado.

A veces te llevas una sorpresa agradable: Papers, please es la versión más robusta de "Encuentra las siete diferencias" que has visto jamás. Encuentra diferentes maneras de cambiar a lo largo del tiempo, fuerza la tensión entre la velocidad y la precisión, fuerza a que hagas juegos de memoria, levantando diferentes capas de dificultad según avanzas.

¿Qué estoy intentanto entender? Quiero saber cuál es el espacio de posibilidades, extrapolando el cómo las diferentes curvas que veo se desarrollarán. No necesito jugar toda la historia hasta el final del juego para ver cómo se desarrolla cada variación – solo necesito ver cuán amplio es el espacio de variaciones. Quiero saber qué elecciones tengo que tomar, y qué consecuencias tendrán sobre el sistema. Solo sobre el sistema, no sobre la experiencia de juego. Quiero saber si puedo abusar del sistema que veo. Quiero saber si mi habilidad importa o no. Quiero saber si estoy aprendiendo algo mientras juego. Quiero saber cómo el sistema va montando un modelo mental en el jugador.



Todas esas cosas son elementos en mi checklist para mi propio trabajo. Las busco para poder observar el diseño de este o aquel nivel mecánico. Principalmente porque analizo juegos para mejorar mis diseños. A veces lo hago para ayudar a alguien a mejorar su diseño. Hay otras razones para analizar un juego, pero estas son las mías.

¿De qué van los sistemas?

Ahora que puedo ver el esqueleto, las placas tectónicas, puedo ver cómo los sistemas interactúan. Me pregunto a mí mismo, ¿qué quería conseguir el designer aquí? Y hago una hipótesis. No es más que una hipótesis, a no ser que haya alguna señal explícita dándome la respuesta. Dicho esto, las hipótesis no son tan difíciles de montar, porque suelen estar telegrafiadas de diferentes maneras. Las cosas más comunes que busca un designer son:
  • Hacer que el jugador siga jugando
  • Hacer que el jugador gaste dinero
  • Hacer que el jugador preste atención a una experiencia en lugar de a un sistema
  • Hacer que el jugador se sienta bien, normalmente haciéndolo poderoso
Hay varias excepciones, por supuesto, pero esas cuatro son las más habituales. De hecho, me suelo emocionar cuando veo un objetivo más interesante que los anteriores. Por ejemplo, cuando veo una estructura de mecánicas diseñadas para que:
  • El jugador quiera ayudar a otros jugadores
  • El jugador sospeche de las reglas
  • El jugador entienda un nuevo "lenguaje", o más bien una nueva forma de pensar y resolver problemas
  • El jugador se sienta bien pero con cosas diferentes al poder: altruismo, cooperación, creatividad, su propia inteligencia...
La mayoría de sistemas no son así. La mayoría tienen los objetivos habituales. Y un juego no tiene por qué tener más que esos objetivos. Puedes tener un sistema poco ambicioso y ejecutarlo realmente bien, y al analizar el juego de este modo me servirá para saberlo.

¿Cómo interactúo con el sistema? Y ¿cómo interactua el sistema conmigo?

Una vez he entendido lo anterior, puedo centrarme en dos aspectos sobre la interacción con el sistema: los inputs que puedo darle, y el feedback que obtengo a cambio. Nos acercamos peligrosamente a la "experiencia" por este lado, pero si vamos con cuidado podemos relacionarlo más bien con el "game feel", la responsividad, las recompensas, la curva de aprendizaje y tal, sin necesidad de adentrarme en la particular ficción que quiera contarme el juego.



En otras palabras, puedo observar cosas como si los controles son amigables, dado el sistema que el juego me ofrece. Puedo llegar a la conclusión de que la mejor manera de marcar mis propios avances en Gone Home es dejar la casa hecha un trapo, porque el juego da mínimas pistas sobre qué objetos son clicables, y ninguna indicación sobre los objetos que ya he examinado anteriormente.

Ahora tengo suficiente para hacer un primer juicio, aunque sea solo para mis propios diseños. He decidido ver los juegos bajo la lente de un "objetivo artístico". Y he observado cómo los juegos me permiten entenderlo. Así que puedo decidir por mí mismo si un juego es Bueno o Malo al intentar cumplir su propio objetivo.

Por ejemplo, puedo observar la escena inicial del robo del banco en GTA V y darme cuenta de que funciona como un tutorial. Puedo ver cómo va abriendo puertas según tengo que hacer ciertas acciones correctamente. Puedo notar cómo no me dice qué botón hace tal acción, sino que asume que he leído el manual o he jugado otros juegos antes que usan los mismos controles. Puedo ver que me dice que me cubra en un área donde hay muchos puntos de cobertura, pero que el juego espera que lo haga en uno en concreto que está marcado en el minimapa con un punto que no ha sido explicado previamente. Puedo observar que en algunas áreas de este tutorial, el no hacer la acción correcta no tiene un efecto negativo, pero que en otros significaría fracaso en la misión y reset. Al final, todo esto me lleva a un juicio en el que digo que se podría haber añadido algo de usabilidad en este tutorial.



Es muy posible que haya captado mal ese "objetivo artístico" (aunque, en general, asumir que el opening de un juego está para enseñarte los controles básicos suele ser una apuesta segura, a no ser que estés jugando a 868-HACK o algo por el estilo). Seguiremos con eso más adelante, puesto que ahora puedo darme la vuelta y fijarme ne la experiencia de juego.

¿Te ha gustado este artículo? ¡Compártelo!

Sé el primero en dejar un comentario...

Nota: ¡El código HTML no será interpretado!
* Campos obligatorios