Un proceso UX fuera de la pantalla: El desarrollo de un juego de mesa

Desde hace dos años he estado llevando un proceso UX desarrollando un juego de mesa. 

Me gustan los juegos; entretienen, relajan, divierten; cuentan historias; crean conexiones entre quienes los juegan. Esto es igual en los deportes, en los videojuegos y en los juegos de mesa. De adolescente, me imaginaba en el futuro programando videojuegos (e hice algunos pininos con QBasic).

Mi apretado modus vivendi actual me impide dedicarme al hobby como antes. Sin embargo, un día me topé con Tabletop, el programa de juegos de mesa de Wil Wheaton, y redescubrí una pasión en mí… la de crear mundos, crear reglas y competir con ellas en un ambiente de camaradería. Tras no mucho tiempo, comencé a formular juegos en mi cabeza a la hora de la ducha.

Poco a poco surgió en mi cabeza la imagen del juego que quería. El (auto-)análisis de requerimientos me dio objetivos claros. El juego debía ser:

  • Rápido de jugar: que pudiera jugarse durante la hora de la comida,
  • fácil de entender: de modo que gente no familiarizada con los juegos de mesa pudiera entenderlo sin mucho problema,
  • de acción rápida: que hubiera acción y atención en cada turno,
  • donde el desenlace no fuera fácilmente anticipable, 
  • de producción relativamente barata, de modo que pueda tener un costo relativamente bajo con buenos valores de producción.

Considerando mi realidad, me enfoqué en dos personas:

  • El jugador casual, novicio y con poco tiempo como yo.
  • El jugador empedernido, con suficiente tiempo y que busca una experiencia más plena e inmersiva.

Si bien ya tenía en mi cabeza ideas sobre algunos tipos y patrones de diseño de juegos de mesa, no tenía idea sobre el proceso. Resulta que es un camino que muchos han tomado, sea como hobby o como su profesión. Este artículo me dio una hoja de ruta; notarán que existen gruesos paralelismos con los procesos de UX, de modo que decidí abordarlo como proceso de UX.

Estableciendo los principios de diseño

Comencé, pues, una serie de ciclos de creación de reglas, prototipos y pruebas con jugadores. El primer ciclo dio origen al tema del juego (entiéndase: el look and feel).

collage

Un juego de mesa, al igual que un sistema y un sitio web, es una experiencia formada de diversos factores:

  • Las reglas, que definen tanto el propósito de cada jugador como su conducta, usando las abstracciones definidas en el juego: ¿ganar a los demás o colaborar con los otros?, ¿amasar recursos, administrarlos, intercambiarlos?, ¿a qué poner atención en los turnos de los demás?, etc.
  • La transmisión de información entre actores; los elementos gráficos y físicos (fichas, etc.), lo cual permite que las reglas funcionen y también ayuda también a establecer el tercer punto,
  • la temática del juego – y la ficción que se desarrolla en la mente del jugador, que puede ser muy sólida e importante (en juegos como D&D) o inexistente, en el caso de juegos matemáticos abstractos como el solitario o el comesolo.

Decidí guiarme por la máxima de Sid Meier, legendario autor de videojuegos como Civilization:

Un juego es una serie de decisiones interesantes.

Decidí quedarme con los siguientes patrones de diseño:

  • El modo de juego sería altamente competitivo.
  • El ambiente sería de batalla campal.
  • Los recursos serían limitados y su administración estratégica sería clave para el éxito de un jugador.
  • El resultado de cada acción sería determinado en parte por la estrategia del jugador y en parte por el azar.

De aquí derivó una primer serie de reglas que ponían a los jugadores en un tablero con 19 celdas, o cuartos, hexagonales. Cada jugador tendría una cantidad limitada de “vida”. Tendría que correr entre cuartos para recoger “recursos” representados por cuadritos en el tablero. Los mismos recursos bloquearían los pasajes entre cuartos, creando una dinámica de flujo geográfico.

Dichos recursos, al tomarse, se volverían cartas, usables para atacar a otros jugadores, defenderse u obtener atributos especiales. Los jugadores tendrían siempre hasta 6 cartas, tres de las cuales podrían ocultarse estratégicamente a otros jugadores.

Adicionalmente, establecí un objetivo adicional: encontrar tres cartas específicas que, al acumularlas, darían la victoria. La otra manera de ganar era simplemente eliminar al resto de los participantes, atacándolos y resistiendo sus ataques.

En este momento no tenía idea de cuánto podría durar una sesión de juego, pero sabía que mi meta era que una sesión durara entre 30 minutos y una hora, con hasta 6 jugadores.

La primera prueba con usuarios

Ensamblé, pues, un prototipo de baja resolución e hice una primer prueba con usuarios, aprovechando un evento en mi empresa.

Prototipo de baja resolución

Esta prueba (comparable a un test de usabilidad) fue, necesariamente, una en la que yo participé como moderador y explicando reglas. Al final, pregunté a los participantes su opinión y recolecté sugerencias de mejora, en una mini-dinámica de diseño participativo.

Resultó que la dinámica del juego era interesante y daba pie a decisiones constantes. La temática del juego llamó la atención incluso de los no jugadores. Sin embargo, había muchos factores en contra:

  • Las reglas no eran rápidas de explicar ni de entender.
  • Había demasiados componentes, de modo que el estado del juego era difícil de seguir en cualquier momento.
  • El diseño visual del juego era contraintuitivo: al iniciar el turno de un jugador, no era evidente qué es lo que se debía hacer. Aún más: el juego incluía dados y un tablero, de modo que el instinto inicial de los jugadores (acostumbrados a juegos como Monopoly, por ejemplo) era tirar el dado y mover su ficha. Esto, sin embargo, no era siquiera una acción válida.
  • La sesión de juego fue muy tardada: en 30 minutos, seis jugadores lograron terminar tres turnos cada uno.
  • Y, por supuesto, las reglas mismas no habían sido probadas, estaban en constante flujo y necesitaron cambios y correcciones en el instante en que eran jugadas.

Sin embargo, de esta primera primera prueba, el resultado más alentador fue que los jugadores se divirtieron y se emocionaron. Esto me indicó que el diseño iba por el camino correcto.

Estableciendo un proceso cíclico

El siguiente paso fue integrar los aprendizajes para modificar reglas y dinámicas. Recluté a algunos de mis compañeros de trabajo para ir probándolas; para esto, organicé reuniones donde también cenábamos, ya fuera en casa de alguno de nosotros o en un restaurante (recordemos que el investigador debe recompensar a sus participantes).

IMG_3812

Gracias a esto pude comenzar a generar nuevas reglas y prototipos en ciclos, cuya duración variaba entre una semana y varias. Nuevas ideas fueron probadas, implementadas, cambiadas, desechadas y vueltas a probar.

El principal objetivo de estos ciclos era reducir la complejidad del juego sin detrimento de los factores que lo hacían interesante. Gracias a esto, el juego fue cambiando de forma y poco a poco fue llegando a sus objetivos iniciales.

IMG_20150611_210138895

A la mitad de este periodo invertí en componentes para crear un prototipo de mediana definición. Al tener un grupo estable de testing, mi participación en las pruebas fue haciéndose más externa, recorriendo así la gradiente que Jared Spool define. Ya podía dejar que el panfleto de reglas escritas explicara cómo jugar, efectivamente acercando la dinámica del test play a la de un estudio de campo.

Todo fue muy bien hasta que sucedió lo que suele pasar en estas empresas meramente creativas: me estanqué.

Saliendo del pozo creativo

El profesional de UX tiene un arsenal de medios para la consecución de sus objetivos. En un proceso de UX formal, el investigador generalmente procurará ir cambiando de sujetos de prueba, usará diferentes tipos de pruebas, etc. y tiene objetivos de negocio claros. Se pueden emplear métodos como las lluvias de ideas para “salir de la caja”. Esto permite que el proceso avance.

A mí me costó salir de esta caja. El principal causante quizás fue no utilizar dichas técnicas o no involucrar a una mayor variedad de personas en el proceso creativo.

Dejar pasar el tiempo y obtener nuevas ideas fue lo que me permitió volver a abordar el problema inicial y deshacerme de algunos de los paradigmas iniciales. Dejé de lado el tablero y muchas de las fichas. Inicié, pues, una “nueva rama” de diseño, donde el juego se rige principalmente por sus cartas.

IMG_20160319_141009159

Cambiar a un paradigma de “juego de cartas” implicó regresar a una fase de prototipo de baja resolución. Sin embargo, esta edición está construida utilizando los aprendizajes recogidos durante dos años.

Los test plays más recientes se han logrado terminar en media hora. Los nuevos participantes lo entienden en menos de cinco minutos mediante mera observación y breves explicaciones. El factor diversión sigue presente; las decisiones siguen siendo una combinación de azar y estrategia, y la dinámica del juego es tal que, incluso al final del juego, el desenlace no puede ser claramente predicho, haciendo de éste un buen “juego de espectador”.

En conclusión

Aún estoy consolidando las reglas de esta versión del juego y sus posibles extensiones. Seguirán nuevos prototipos de mayor definición y pruebas con usuarios externos. Luego decidiré si pretenderé comercializarlo o distribuirlo libremente, y de qué manera será.

Sin embargo, ya en este momento me siento satisfecho por haberme demostrado a mí mismo que el proceso de UX funciona en muchos medios y que los resultados son altamente gratificantes, como el proceso mismo.

Publicado por

flopez

Desarrollador web con énfasis en front-end y usabilidad. Actualmente trabajo en Justia, Inc.

Un comentario en “Un proceso UX fuera de la pantalla: El desarrollo de un juego de mesa”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *