28 ene 2016

Mecánicas desde cero: Simplificar el juego

En el artículo anterior iniciábamos una reflexión sobre los aspectos que nos acercan a definir si un juego es complejo o no desde el punto de vista mecánico, para así poder llegar a una conclusión cercana con nuestros proyectos.


Antes de meternos en camisa de once varas, me parece oportuno aclarar que en este artículo se emplearán términos que acotamos en el anterior (Y que encontraréis en cursiva), y que por supuesto las conclusiones finales han de ser resultado de una combinación de elementos que tu, como autor o consumidor, debes decidir. Este artículo no busca establecer a rajatabla un baremo para medir la complejidad de un diseño.


Difícil, complejo o complicado

Anteriormente hablamos de las diferencias entre simple, sencillo y fácil, pero también hay que tener en cuenta sus opuestos.

Aunque en la vida diaria usamos difícil y complejo como sinónimos, en este caso debemos darle un nuevo matiz. Cuando usamos el adjetivo 'difícil' hablamos de lo opuesto a fácil, algo que cuesta entender, algo que requiere inteligencia, habilidad o esfuerzo, e incluso, puede que nunca llegue a superarse esa barrera por la renuncia a este esfuerzo.

Para complejo y complicado, Spencer Johnson, escritor y psicólogo, establece en su libro 'Sí o no' una definición que creo que viene perfecta cuando de mecánicas se trata. Dice así: 'Complejo significa que el problema tiene varias partes. Complicado quiere decir que no logras distinguir entre esas partes.'

Además, debemos tener en consideración el concepto de curva de aprendizaje, término empleado para referirnos a la cantidad de tiempo o esfuerzo que ha de invertirse para el aprendizaje de algo concreto. Para esto, debemos tener en cuenta el perfil de usuario al que enfocamos el juego, ya que no todos buscan lo mismo.



Tiempo de ejecución 

Existe un factor muy importante que creo que es vital tener en cuenta sobre todos los demás, y es lo que yo llamo 'Tiempo de ejecución' (TE), término muy informático (Deformación profesional...) con el que suelo referirme al tiempo que tarda un Jugador en resolver una mecánica, a falta de una palabra oficial para referirnos a ello.

Cuando aumenta el TE, causamos varios efectos nocivos en el juego: Interrumpimos la acción en que nos encontremos 'sacándonos' de la ficción, tomando consciencia de que estamos jugando. Por otro lado, si la mecánica es además compleja o difícil de recordar, aumentamos la posibilidad de que se necesite consultar el manual, perdiendo tiempo y causando la inviabilidad de escenas de acción.

Lo ideal es que la mecánica sea tan veloz como sea posible, según mi experiencia personal, el TE debe estar entre 1 y 3 segundos como máximo. Con todo esto en mente, podemos obtener ciertos patrones que dificultan las mecánicas y aumentan el tiempo de ejecución de forma exponencial.


Simplificando la mecánica

Sabemos que estamos ante un gran comunicador cuando éste se hace entender, y esta diferencia se encuentra en el emisor. Al igual que los buenos cuentahistorias, nuestro juego debe hacerse entender, no requerir que lo entiendan. Es decir, no cargar al receptor de toda la responsabilidad del entendimiento mecánico, ya que esto abre la puerta a más trabajo por parte de ambos, precisando nosotros más ejemplos y espacio para redactar cada una de esas reglas innecesariamente complejas, y causando más dudas y lagunas en playtest y en los futuros Jugadores. Además, las partes en las que REALMENTE necesitemos explicarnos extensamente se verán ya saturadas por el esfuerzo anterior. Es una prioridad focalizar la atención en los puntos que no podemos simplificar, y poder usar el comodín de 'Esto es una parte compleja/difícil' con aquellos mecanismos que no podemos o no hemos sabido simplificar más.



En base a todo lo anteriormente mencionado, podemos usar ciertos trucos sencillos para evitar ralentizar el juego y hacerlo más complejo. Estos trucos son los siguientes:

- Evita las divisiones en la medida de lo posible. Si no te queda más opción, haz que no deban redondearse o que no den resultados con decimales. Lo ideal es que sea entre pares (Dividir entre 2, y 4 suele ser aceptable por ejemplo)

- Usa números pequeños. La mente trabaja más lento con números grandes.

- Evita sumar muchas cifras y que sean de números 'grandes'. Por ejemplo, es más sencillo sumar 4+2 que 4+27+34, y es aún más difícil sumar 145+64+3.

- Evita las reglas que requieran de la presencia contínua del manual. Existen ciertas opciones aceptables como la creación de Personajes manual mediante, ya que están fuera de la narración misma, sin embargo, si el sistema requiere por diseño la contínua revisión del manual, tarde o temprano se darán casos de minutos de búsqueda entre páginas, con la consecuente fragmentación de la narración.

- Si tienes duda sobre una determinada regla, hazla opcional. Muchos juegos se apoyan sobre la misma base y ofrecen sistemas escalonados de dificultad.

- No abuses de abreviaturas. Y si en el caso de que debas usarlas son estándar, mejor, ya que el usuario nuevo aprende aquellas que van a serle de utilidad en el futuro y los Jugadores veteranos ya saben a qué te refieres o al menos tienen una idea aproximada de ello.


¡Mecánica fuera de control! ¿Qué podemos hacer?

Si cuando estás leyendo estas líneas ya tienes entre manos un juego al que llamas difícil, y el problema tiene origen numérico, aún te quedan opciones.

Si los números que mueves son demasiado grandes, a veces podemos dividirlos con mínimo impacto en el sistema de juego. Por ejemplo, si un Personaje tiene 100 Puntos de Vida y puede recibir daños por valor de 50 es equivalente a que tenga 10 puntos de vida y sufra daños de 5. En ambos casos reflejan un 50% del total de vida del Personaje.

En otros casos, la solución pasa por el pensamiento lateral. Solemos enfocar el problema en vez de buscar los elementos que lo causan. Con el ejemplo anterior, supongamos que en nuestro sistema nos encontramos con Personajes que tienen una gran cantidad de Puntos de vida para evitar que caigan fácilmente con los daños que pueden sufrir, haciendo que debamos sumar y restar cifras grandes. Quizá en realidad, el problema es que la cantidad de daño es de por sí, elevada, y disminuyendo ésta podamos reducir también el resto de cifras implicadas.

Ahora solo queda sumarlo todo y dividirlo entre 3.75

Otra situación similar del mismo tipo que suelo ver por ejemplo es el uso del d100 con aumentos de 5 en 5, que a efectos prácticos es equivalente a usar un d20 con aumentos de 1 en 1, ya que en todos los casos equivale a un aumento porcentual del 5%.

No siempre podremos usar estas opciones por diversos motivos, pero conviene tenerlos en cuenta cuando buscamos una solución a problemas numéricos. Por contra, la solución a otros problemas mecánicos pasa por la reestruturación completa de la mecánica, en la cual debemos identificar el nexo, lo importante de la misma, limpiarlo de todo lo superfluo y trabajar desde ese punto. Creo que merece la pena invertir tiempo en la depuración del juego para evitar futuros problemas de diseño que deriven de una base mal planteada.

Cuando se aborda la solución de un problema, sea cual sea, las primeras soluciones que surgen son siempre muy complicadas y muchos no pasan de ahí. Pero si se sigue pensando, profundizando en el problema y quitando capas a la cebolla, se llega a soluciones muy sofisticadas y al mismo tiempo sencillas. La mayoría de las personas no dedican a este proceso suficiente tiempo y energía. Nosotros pensamos que nuestros clientes son inteligentes y que quieren objetos bien resueltos.
- Steve Jobs

Ante la duda, usa la regla KISS (Keep it simple, stupid.) 


No hay comentarios:

Publicar un comentario