Precisamente la habilidad de detectar errores en el texto preliminar puede hacer mucho más fácil y fluidas las pruebas de juego y de hecho ayuda a que los lectores cero centren su ojo crítico en los menos evidentes, precisamente aquellos que a ti como autor te costará más detectar. Hoy nos ponemos el uniforme reglamentario de cazadores de bugs y salimos en su busca. ¿Cómo buscar bugs y errores en nuestro juego? ¿Cuáles son los más frecuentes? Aquí van dos métodos que funcionan bien por separado, pero mucho mejor combinados.
Cada autor tiene su método para localizar bugs dependiendo del conocimiento de su propia obra, del género, estilo o el juego para el que esté creando el material si es el caso. Son factores que conviene tener muy presentes para determinados pasos ya que nublan con una facilidad pasmosa nuestra visión de análisis crítico.
Para este caso y explicar mejor mis métodos y técnicas vamos a emplear el ejemplo de una mecánica básica, es decir, el núcleo de un juego, lo que más vamos a usar. Hemos terminado de redactar el cómo funciona (o debería funcionar) nuestra mecánica y debemos buscar los primeros errores. Aquí lo difícil es ponerse en el estado mental de un cazador de bugs, de un tester, olvidando que conocemos el juego y sus métodos.
Planteamiento inicial: Olvida tu juego
El primer paso es olvidar nuestro propio juego. Esto puede lograrse dejándolo descansar un tiempo prudencial y dedicándonos a otros juegos o actividades, la idea es que olvidemos cómo lo hemos redactado y con suerte algunos detalles del funcionamiento. Esto nos permitirá que al leerlo posteriormente veamos de forma muy clara los puntos que están redactados de forma confusa o crean dudas, ya que nos la generarán a nosotros mismos.
Esta segunda lectura hemos de realizarla OBVIANDO POR COMPLETO que somos Jugadores de rol. De repente ya nos sabemos jugar. Si te decides a leerlo mientras juegas sólo o reconstruyes en tu mente los pasos, cíñete de forma estricta al texto, no obvies ni supongas NADA.
 |
| Buscar bugs y errores en textos preliminares es una tarea ardua y solitaria |
Si tomaste notas durante el diseño y la redacción tiene vacíos, muy probablemente seas capaz de recordar cómo querías que fuesen dichas mecánicas e incluir los detalles faltantes en base a ellas, solucionando los bugs en una primera instancia. Dicho esto, pasamos las técnicas.
Método 1: Reconstrucción mecánica
Tienes delante un texto que describe como funciona la mecánica básica de tu juego. Puede ser similar al siguiente...
"Cuando un Personaje intente superar un obstáculo, el Jugador propietario tira los dados. Empieza con un dado y añade otro por cada Habilidad que pueda ayudarle.
Tira todos los dados que haya reunido. Cada dado que obtenga un 4 o más es un éxito. Necesitará tantos éxitos como el nivel de dificultad para superar el obstáculo. Los niveles son Fácil (2 éxitos), Normal (3 éxitos), Difícil (4 éxitos) y Extremo (5 éxitos). Si supera el nivel, el Personaje tiene éxito en su acción, si no, fracasa. En ese caso el DJ complicará la situación de alguna forma y podrás intentarlo de nuevo con las nuevas condiciones."
(Adaptación libre de la mecánica básica de Lady Blackbird con fines de ejemplo.)
El primer paso es reconstruir en nuestra mente, paso por paso, sin omitir detalle alguno, cómo debería ser la ejecución stándar de la mecánica básica. Y digo stándar porque recordemos que estamos con la mínima unidad de juego y todas las capas posteriores son precisamente interacciones con ésta, excepciones o modificaciones a ella. Podemos imaginar que estamos en plena partida y toca ejecutarla, a partir de ahí la escribimos sin mirar nuestra redacción inicial, en sucio pero con todo detalle. Luego, la comparamos con el primer texto redactado para ver si hemos omitido u olvidado algún detalle importante. Si lo hacemos tras el planteamiento inicial, es decir, redactando de memoria tras un tiempo de pausa, la comparación es aún más bestia, a veces porque tenemos mucho más clara la mecánica que la etapa de redacción inicial.
 |
| Allé voy con las piezas |
Método 2: Pregúntame cosa básicas
Este método puede aplicarse a muchas mecánicas diferentes, pero funciona de forma óptima en la redacción y análisis de la básica, pues trata de cubrir la mayoría de sus factores: Consiste en preguntarle al texto todos los puntos básicos que están involucrados en ella. Las preguntas, junto a las respuestas basadas en el ejemplo anteriormente mencionado, serían las siguientes:
- ¿Cuándo se activa la mecánica básica? (¿O cuándo se realiza la tirada?): En el ejemplo anterior dejamos claro que se activa cuando "(...) un Personaje intente superar un obstáculo (...)"
- ¿Quién la realiza? ¿Porqué?: En esta pregunta buscamos quién es el encargado de llevar a cabo el proceso que supone la mecánica básica, en este caso "(...) el Jugador propietario (del Personaje) (...)" y porqué, en este caso queda obviado en el texto, pero se hace para determinar si su Personaje tiene éxito o no, como veremos más adelante en los resultados que puede ofrecer.
- ¿Cómo la realiza? ¿Qué interviene y en qué orden?: Describimos todo el proceso a detalle y en orden, "(...) Empieza con un dado y añade otro por cada Habilidad que pueda ayudarle. Tira todos los dados que haya reunido. (...)" Como puedes ver se indican los factores que intervienen en mayúscula (Por ejemplo Habilidad) para que el lector pueda identificarlos fácilmente. De hecho, uniendo esta frase con la anterior, las palabras clave Personaje y Jugador también llevan mayúsculas. Reconozco que es una manía personal, pero resulta útil para buscar en el texto y luego podéis eliminarla fácilmente o sustituirla por un formateo en negrita o en cursiva.
- ¿Qué resultados puede ofrecer y qué significan?: O de otro modo ¿Qué puede ocurrir tras estos pasos? En este caso, se especifica en "(...) Necesitará tantos éxitos como el nivel de dificultad para superar el obstáculo. (...) Si supera el nivel, el Personaje tiene éxito en su acción, si no, fracasa. En ese caso el DJ complicará la situación de alguna forma y podrás intentarlo de nuevo con las nuevas condiciones." En ambos casos se incluyen las consecuencias tras la lectura.
- ¿Qué variables pueden intervenir?: En este caso la única variable mínima y más frecuente la hemos incluido al inicio en "(...) añade otro por cada Habilidad que pueda ayudarle.", pero si en nuestro sistema incluimos más variables, debemos tenerlas en cuenta.
- ¿Se rompe el sistema al introducir las variables?: Esta es la pregunta con respuesta menos clara. Sin embargo he omitido, de forma intencional, un dato importante en el ejemplo. ¿Sabéis cual es? Os sugiero volver y releer el enunciado, porque en función del diseño de nuestro juego puede ser importante o no. ¿Ya? ¿Lo habéis encontrado? En cualquier caso, la respuesta es que no se indica número de dados máximo posible, con excepción de ser uno por Habilidad involucrada. ¿Que tenemos diez Habilidades? Tiramos 11 dados. ¿Que son 20? Tiramos 20 dados.
A priori puede parecer poco importante, pero recordad que dependiendo de cómo el sistema interprete las tiradas puede ser mucho o poco y quizá sea recomendable o necesario establecer un límite, sea en el texto en forma de regla explícita o mediante otros métodos (Por ejemplo la limitación de Habilidades por Personaje, pero eso es tema de otro artículo...)
Una vez hemos observado si hay limitaciones en las variables y lo que aportan, debemos observar en este caso el cómo se leen las tiradas. En el ejemplo se sugiere número de éxitos, con lo cual evaluamos si pueden darse números negativos, si todos los Personajes pueden lograr todas las acciones, si se logran automáticamente en cierto punto, la frecuencia en que ocurre cada cosa, etc. adaptando cada caso a nuestra conveniencia y temática del juego. Como es obvio, si en algún punto nos da resultados extraños o no deseados hemos de evaluar la mecánica y establecer o retirar límites si fuese necesario.
Una cosa más, como puede observarse en estas preguntas hemos obviado el material necesario para poder jugar (dados, hojas, etc.) porque se asume que ya se han indicado llegados a este punto, pero es importante incluir en el manual todo lo requerido para jugar.
 |
| Eh, eso de allí es un bug. Maldito hijo de Vecna. |
Aclaraciones y comentarios adicionales
Es muy probable y casi con total seguridad que, si os encontráis con un juego que emplea mecánicas poco tradicionales, novedosas o redactadas de un modo diferente, estos métodos deban ser adaptados al texto en sí, pero aún puedan realizar sus funciones del mismo modo. En muchos casos, si hemos depurado las partes más pequeñas del sistema podemos ir pasando a las interacciones entre las mismas y de esta forma ir asegurando que no hay errores en cada uno de esos sectores para centrarnos en su interacción.
Estos no son mis únicos métodos, pero sí forman parte de los principales y en muchas ocasiones detectan errores con bastante efectividad y velocidad en relación al esfuerzo que conllevan. Si bien normalmente los realizo de forma intuitiva y casi por costumbre, he tratado de verbalizarlos como si de una guía se tratase para poder haceros llegar mis técnicas y procesos mentales, con lo cual es posible que esté pasando por alto algún punto, de ser así, agradecería si podéis indicarlo en los comentarios y así subsanar el error lo antes posible. Ahora es vuestro turno ¿Qué otros métodos conocéis vosotros?
Si te gustó este artículo, échale un ojo a cómo, cuando y porqué realizar un playtesting, los consejos avanzados acerca del mismo, o cómo hacer playtest más veloces. Y sí, en el futuro hablaremos de otros métodos más avanzados (¡Y de vez en cuando hasta aparecen juegos gratuitos por el blog!) de modo que si no quieres perderte nada, recuerda que puedes encontrarnos en Twitter, Facebook y Google+.
No hay comentarios:
Publicar un comentario