» English version

El Rincón de Arturo

Juegos de Rol (Role-Playing Games)

Resolución de tareas vs. resolución de conflictos

Los juegos más tradicionales suelen basar su sistema de resolución en tareas. Sin embargo, muchos otros (especialmente juegos indie) utilizan resolución de conflictos. Aunque un sistema puede construirse con cualquiera de los dos (o incluso utilizar los dos en diferentes partes de la mecánica), pueden existir razones para preferir uno u otro en un diseño concreto.

¿Qué son tareas, qué son conflictos?

En los sistemas de resolución de tareas la negociación de lo que hace o no un personaje se centra es si una cierta acción se realiza o no. En cambio en resolución de conflictos, la negociación se centra en si el objetivo que mueve al personaje a realizar las acciones se consigue o no.

Por ejemplo: "Descerrajo la cerradura de la puerta de la habitación". "¿Para qué?". "Para pillar por sorpresa a los mafiosos que están dentro". En resolución de tareas lo que se va a jugar es si se consigue descerrajar la cerradura o no. En resolución de conflictos lo que se va a jugar es si el personaje pilla por sorpresa a los mafiosos o no (para lo cual pueden ser necesarias una o más acciones).

La resolución de conflictos aparece cuando los jugadores declaran explicitamente sus objetivos/intenciones antes de proceder a la resolución (lanzar los dados).

La resolución de conflictos también se define a veces como aquellos mecanismos para resolver conflictos de intereses entre personajes. En ese caso los objetos inanimados se pueden concebir como entes con intereses contrapuestos a los del personaje. Por ejemplo, cuando un personaje se enfrenta a una tormenta, la tormenta lucha contra el personaje para evitar que llegue a donde este quiere. Cuando un personaje intenta escalar una montaña, la montaña no quiere dejarse escalar.

Resolución y ritmo

Mucha gente que no ha probado aún un sistema de resolución de conflictos tiende a pensar que implica resolver toda la escena con una sola tirada. No es así. Esto es una cuestión completamente diferente que tiene que ver con el Ritmo (Pace) que los jugadores quieran imponer a la resolución. Igual que se puede resolver toda una escena con una sola resolución de tareas, se puede resolver un combate con resolución de conflictos para cada maniobra.

Un ejemplo de resolución de conflictos para una maniobra dentro de un combate. "Le ataco con mi espada". "¿Para qué?". "Para dejarle una marca en la cara que le abochorne". En resolución de tareas sabremos si el ataque con la espada tiene éxito y se consigue golpearle. En resolución de conflictos sabremos si queda abochornado con su nueva marca facial. Si eso afecta (y cómo) al resto del combate, o a lo que pase después de éste, es otra cuestión que cada juego puede reglamentar de una forma distinta. En las últimas secciones de este documento volveremos sobre el tema.

Un ejemplo interesante es el juego Trollbabe. Trollbabe utiliza resolución de conflictos. Cada vez que se produce una situación que necesita resolución, los jugadores escogen el ritmo que prefieran. Tiene tres ritmos: conflicto entero, intercambio a intercambio, acción a acción. La única diferencia es el número de victorias (1,2 ó 3) que hacen falta para ganar realmente el conflicto y conseguir el objetivo marcado. Para conseguir cada victoria, el jugador debe plantear las acciones que intenta llevar a cabo como un mini-objetivo y lanzar dados, una o más veces (sin entrar en todos los detalles). En cada intento, se narran acciones, golpes, intercambios y otros detalles que van acercando o alejando al personaje de su objetivo. En la lucha por cada victoria el personaje puede ser herido o acabar aún peor. Un conflicto a una sola victoria se resuelve rápidamente con unas pocas tiradas. En cambio, un conflicto a 3 victorias se convierte en una detallada secuencia de acciones, maniobras y eventos en los que cada situación aporta algo al resultado final del conflicto. En ambos casos el sistema de resolución nos dirá si el personaje consigue su objetivo final o no.

Problemas de indefinición en resolución de tareas, el poder del master

La resolución de tareas nos indica si la tarea se consigue realizar o falla. La resolución de conflictos nos indica si el personaje consigue su objetivo o no. Lo importante es notar que el personaje podría conseguir realizar la tarea pero no conseguir su objetivo, o fallar en la resolución de la tarea pero sí conseguir su objetivo.

En los juegos de rol tradicionales con resolución de tareas la asociación entre una acción exitosa y conseguir el objetivo, o una acción fallida y no conseguir el objetivo, está en manos del master. De hecho, es perfectamente posible y habitual que el master rompa esa relación, convirtiendo una colección de tareas exitosas en un fracaso (el personaje no consigue el objetivo), o una tarea que falla en un momento crítico en un éxito (se consigue el objetivo de todas formas).

Volviendo sobre el ejemplo de la cerradura: "Descerrajo la cerradura de la puerta de la habitación". "¿Para qué?". "Para pillar por sorpresa a los mafiosos que están dentro". Supongamos que usamos resolución de tareas y el personaje descerraja la cerradura. Sin embargo, el master decreta que la puerta tiene además un tranco por dentro, con lo que la puerta aún no está abierta. O que la puerta se abre, pero los mafiosos ya no están allí. O que al descerrajarla se hace ruido y están prevenidos. O que se abre la puerta pero una vez abierto el paso aún es necesaria otra resolución para ver si realmente se les pilla por sorpresa. En cualquiera de estos casos el jugador ha invertido en conseguir una resolución exitosa (quizá incluso gastando recursos de su personaje), pero no ha conseguido su objetivo.

Por el contrario, el personaje podría fallar en descerrajar la puerta, pero el master puede decretar que el personaje nota que la puerta es endeble y se puede derribar con facilidad para entrar por sorpresa, dándole una nueva oportunidad. O que al intentar descerrajarla advierte que un cartón está tapando una claraboya por donde el personaje se puede colar para sorprenderlos. O que mientras se trabaja sin éxito en la complicada cerradura se oye a los mafiosos trasladándose a otra habitación más accesible. En estos casos, el master está posibilitando al personaje conseguir su objetivo a pesar de haber fallado la resolución de la acción.

Así pues, independientemente de los dados o las reglas, independientemente de si la acción es exitosa o no, el master es el que está decidiendo si se consigue el objetivo o no. Por tanto el verdadero sistema de resolución que se está utilizando es el juicio del master (al que pueden afectar su humor, la excitación del momento, sus expectativas narrativas, la relación que existe entre los jugadores y todo tipo de cuestiones sociales que se supone que el sistema debería minimizar).

La resolución de tareas pone al master en una posición de autoridad privilegiada, en la que la colaboración o intereses narrativos del otro jugador se diluyen.

Resolución de tareas sin indefiniciones

Estas situaciones de indefinición no ocurren en los tipos de tareas para los que el sistema de resolución está suficientemente detallado y preescribe de alguna forma la escala o las consecuencias de las acciones. Por ejemplo: En un sistema de combate clásico, cuando un personaje ataca a otro para hacerle daño, la resolución del ataque seguida de la resolución del daño, implica un efecto ineludible y reglado que era el objetivo del personaje. No hay indefiniciones que queden a juicio del master.

Sin embargo, pensemos de nuevo en objetivos de otra índole, como en el ejemplo del personaje que quiere marcar la cara de otro. Una de dos, o el sistema incluye reglas específicas para llevar a ese resultado, o éste vuelve a quedar indefinido. Si queremos evitar que sea el juicio del master el que decida el sistema de resolución de tareas tendría que tener reglas para todo tipo de objetivos.

Esto se puede hacer por asimilación. Añadiendo una regla para cada nuevo caso particular. Sin embargo, el número de reglas para cubrir excepciones puede crecer tan deprisa que el sistema se vuelve inmanejable. Además, muchas de esas reglas se utilizarán, si es caso, muy ocasionalmente.

Una aproximación de diseño típica es centrarse en las tareas que son interesantes para el tipo de juego que se pretende producir. El resto se cubre con reglas genéricas que muchas veces dejan abierta la puerta a la interpretación del master, suponiendo que su impacto está quedando restringido a áreas de poco interés para ese tipo de juego. Esta aproximación puede ser peligrosa si no queda claro para todo el grupo de jugadores cuál es el área de interés y en qué situaciones el juicio del master es el verdadero mecanismo de resolución. Más información en "Lo imposible antes del desayuno" (Encarrilamiento, ilusionismo, etc.).

Otra opción es utilizar síntesis. Agrupar y clasificar los posibles efectos u objetivos y asignar una regla (o combinación de reglas) para cada clase significativa. Cuando el número de clases se reduce lo suficiente, el sistema se puede estar convirtiendo en un sistema de resolución de conflictos, poniendo atención a los objetivos en vez de a las acciones. Sin embargo, si las reglas sólo fijan la escala o tipo de las consecuencias, sin tener que decidirlas antes de la resolución, sigue siendo resolución de tareas.

Transición entre resolución de tareas y de conflictos

La pregunta es, ¿se puede utilizar un sistema de resolución de tareas para resolver conflictos? La respuesta es sí, con un añadido mecánico sencillo.

Cada vez que se va a resolver una tarea, los jugadores deben declarar explícitamente cuál es el objetivo del personaje, y a qué se arriesga si falla. Si no lo hacen, el master o los otros jugadores deben preguntarles.

Según Vincent Baker (a.k.a. lumpley), existen unas preguntas clave que deben ser repetidas cada vez que un jugador coge los dados para resolver. Cada grupo responde mejor a unas u otras. Algunos posibles ejemplos: "O sea que lo que quieres conseguir es...", "Entonces el peligro es...", "Lo que te estás jugando es...", "A lo que te estás arriesgando es a...". Aunque al principio sea el master el que tiene que completar las frases, la repetición de estas invitaciones crean de forma natural la tendencia de los jugadores a responder por si mismos a esas preguntas e introducir en sus declaraciones sus objetivos y riesgos.

En la resolución todos tienen que tener claro que la tarea va asociada a la intención. Si la tarea es exitosa, se consigue el objetivo. Si no lo es, las consecuencias del fracaso deben ser ineludibles. El objetivo y el riesgo deben ser de similar envergadura. En general el fallo en la resolución hace que el objetivo ya no sea accesible para el personaje hasta otra escena o hasta que cambie la situación de forma que se justifique un nuevo intento.

¿Cómo proceder cuándo se desea utilizar un ritmo de acción a acción? Primero se define el objetivo final del conflicto. Luego, para cada maniobra o acción se define un objetivo táctico y el riesgo particular para ese momento. Existen diversas formas de construir la mecánica que lleva a la resolución final del conflicto.

Por ejemplo, el fallo en una acción/maniobra se asocia a un riesgo que no bloquea directamente el conseguir el objetivo. Pero la situación empeora generando inmediatamente otro conflicto, más grave, en el que el personaje está en una situación de desventaja. En ciertos sistemas esto se puede asociar a bonificaciones o penalizaciones para la siguiente acción. Lo importante es que el riesgo aumente con cada fallo hasta que una de dos, el jugador ceda en su intento de conseguir el objetivo final o el personaje quede inhabilitado o incapacitado para seguir luchando por ello. La mecánica de "Bringing Down the Pain" del juego La Sombra del Ayer (The Shadow of Yesterday) puede ser un ejemplo. Es una mecánica interesante porque introduce también la posibilidad de cambiar el objetivo general del conflicto sobre la marcha con un coste mecánico.

Referencias

Última modificación: 24 June 2008 13:58

 

 

Registro (Log)

 

Tags

 

© 2008-2009, Arturo González-Escribano       arturo[at]infor.uva.es
Última modificación: « 23 April 2016 03:37 »
Valid XHTML 1.0 Strict     Valid CSS!