Nella mia mente questo dovrebbe essere il primo di una serie di articoli veloci, dove esplorare alcuni termini tecnici o elementi di design dei giochi di ruolo. Una rubrica dedicata ai designer, che potrebbe interessare anche a chi di scrivere un gioco non ne ha proprio voglia o intenzione.
Oggi parliamo di due tipi di meccaniche di risoluzione particolarmente famose e chiacchierate, che probabilmente molti di voi avranno già sentito nominare: Task resolution e Conflict resolution. La voglia di trattare l'argomento mi è venuta da una recente conversazione in una chat di telegram, dove ho notato esserci un po' di confusione sulla questione.
Prima di tutto però è importante capire cosa sia una meccanica di risoluzione.
Una meccanica di risoluzione è un tipo di meccanica (regola, procedura) che agisce quando due giocatori hanno due volontà diverse sullo Spazio Immaginato Condiviso (vi consiglio di leggere qua se non sapete cosa sia, perché potreste perdere pezzi di questo articolo) e questo tipo di meccanica può prevedere lanci di dado e altri sistemi aleatori, oppure nessun sistema casuale.
Per dirla in maniera più semplice, una meccanica di risoluzione si attiva in quei momenti in cui due o più giocatori vogliono accada qualcosa nella narrazione e le loro idee entrano in conflitto. Insomma, quando si tirano i dadi. Questa volontà può presentarsi a livello autoriale, ossia del giocatore puro e semplice, e quindi le regole tenderanno a gestire la risoluzione a livello dei giocatori (penso per esempio a giochi come Archipelago o Deus Opera), oppure lo scontro può subentrare a livello del personaggio, quando quest'ultimo è l'unico mezzo che ha il giocatore di impattare sulla narrazione, di solito attraverso le sue semplici azioni. In quest'ultimo caso le regole di risoluzione gestiscono le azioni e la volontà dei personaggi.
La maggior parte dei giochi di ruolo, praticamente tutti quelli più famosi, hanno meccaniche di risoluzione che ricadono nel secondo caso, quindi nell'ambito dei personaggi, gestendo se un personaggio riesce o meno a fare un'azione o a ottenere ciò che vuole. Ed è qui che arriviamo alla differenza tra Task resolution e Conflict resolution, rispettivamente risoluzione di compiti e risoluzione di conflitti. Queste sono i due tipi di risoluzione principali e la loro differenza sta tutta nella tabella qua sotto:
Immaginate un famoso boss del crimine che sta organizzano un importante colpo grosso a una banca; un ladro si presenta da lui per ottenere la sua fiducia e far parte dell'operazione. Questi decide quindi di scassinare una complessa cassaforte davanti al boss, in modo da dimostrargli il suo valore e convincerlo a prenderlo con lui.
È il momento di una risoluzione, ma come la gestiamo? Task o Conflict?
Avete notato le differenze? No? Tranquilli, è normale. Capire al volo cosa cambia tra i due tipi di risoluzione non è automatico. È necessario spenderci qualche parola in più e notare alcune sottigliezze. Probabilmente starete pensando che in entrambi i casi, sia nella Task che nella Conflict, vincendo si convinca il boss scassinando la cassaforte e fallendo non si riesca a convincerlo perché la cassaforte non vuole saperne di aprirsi, giusto? Beh, no.
Nella Conflict resolution la risoluzione serve per decidere se otteniamo il nostro obiettivo: convinciamo il boss oppure no? Di base non ci dice se scassiniamo o meno la cassaforte, perché non è importante ai fini della "meccanica". Possiamo convincere il boss pur fallendo nell'apertura della cassaforte, o viceversa non convincerlo pur riuscendoci, perché la regola ci dice chiaramente se convinciamo o no il boss, ma non se apriamo o meno la cassaforte. Decidere se la cassaforte si apre o no è una decisione estetica arbitraria, che spesso spetta al GM (se c'è) oppure ad altri giocatori.
Per dirla meglio: nella Conflict conta l'obiettivo da raggiungere tramite l'azione (visto che in ballo c'è uno scontro tra due volontà), non l'azione stessa, anche se molti giochi fanno coincidere le due cose. Le regole dicono se a vincere è la propria volontà oppure no, e quindi se si raggiunge il proprio obiettivo oppure no.
Con la Task resolution invece è esattamente il contrario: sappiamo che in caso di riuscita scassiniamo la cassaforte, mentre in caso di fallimento non ci riusciamo. Le regole non dicono niente sul convincere o meno il boss. Dato che la Task ha come obiettivo la task stessa, ossia l'azione e la sua riuscita, e dato che essa regolamenta soltanto l'azione fine a sé stessa, i veri obiettivi di un'azione vanno risolti arbitrariamente da qualcuno al tavolo, di solito il GM. Nel nostro esempio quindi la regola ci dice se apriamo la cassaforte oppure no, ma a decidere se il boss viene convinto o meno è una persona al tavolo, solitamente il GM.
Per dirla meglio: nella Task conta la riuscita dell'azione, non l'ottenimento di un obiettivo. Il conflitto deve essere risolto da qualcun'altro al tavolo, arbitrariamente, e non attraverso i dadi.
Nel suo blog, Vincent Baker (autore di Cani nella Vigna e Apocalypse World), dal quale ho ripreso parecchi spunti presenti in questo articolo, fa un esempio un po' diverso. Nel suo esempio un eroe deve aprire una cassaforte perché al suo interno vi troverà le prove decisive per incastrare il cattivo. La differenza tra Task e Conflict è che con la Task l'obiettivo è l'azione stessa: riuscirà l'eroe ad aprire la cassaforte? Mentre con la Conflict l'obiettivo dell'azione è: l'eroe otterrà le informazioni che gli servono oppure il cattivo riuscirà a tenergliele segrete?
Con la Task tutto quello che conta è aprire la cassaforte: le prove potrebbero non essere lì dentro e l'eroe (e il giocatore, specialmente) potrebbe aver fatto tanta fatica per niente, ma questo non è importante perché la risoluzione era sull'aprire o meno la cassaforte, non sul trovare le prove per incastrare il cattivo; queste magari sono state tutto il tempo sotto il letto. Con la Conflict invece l'obiettivo è proprio ottenere le prove, e quindi se queste non si trovano nella cassaforte il conflitto non si può attivare perché non c'è nulla da risolvere; si attiverebbe, e quindi il giocatore andrebbe a tirare i dadi, pescare le carte o qualsiasi altra meccanica prevista dal gioco, solo se le prove fossero li dentro, e quindi ci fosse effettivamente uno scontro di volontà. In quel caso allora sì, vincere il conflitto significherebbe aprire la cassaforte e trovare le prove.
Adesso la differenza tra i due tipi di azione inizia ad esservi più chiara? Se sì, avrete sicuramente intuito come la Conflict sia di base un po' più chiara della Task. Essa infatti, regolamentando in maniera precisa se un personaggio ottiene o meno un obiettivo, dà una certa certezza al giocatore e toglie d'impiccio qualcun altro (di solito il GM) dal dover decidere arbitrariamente se si ottiene un certo obiettivo oppure no, ed è inoltre ottima per spingere verso la creazione di una storia emergente, poiché risolve i conflitti, che sono il cuore della narrativa, e dà una direzione precisa alla narrazione. Se Tizio e Caio si scontrano, con Tizio che vuole A e Caio B, la storia andrà in direzioni opposte in caso di vittoria di Tizio o di Caio. Pensate a storie come Game of Thrones, dove la volontà dei personaggi è palese e moltissime scene sono veri e propri scontri di volontà.
La Task invece tende a rimanere un po' più fumosa, visto il suo focalizzarsi soltanto sull'azione e non sul suo obiettivo, quindi ha funzionalità un po' più ridotte e più improntate a giochi non focalizzati alla storia; rischia infatti di spingere verso il rail roading perché, non regolamentando l'ottenimento di obiettivi specifici, demanda all'arbitrio di un'altro giocatore (il GM) la risoluzione del conflitto, dato che le regole decidono soltanto la riuscita o meno della pura azione. L'elemento solitamente più importante, ossia: "raggiungo il mio obiettivo?" non è regolamentato, e questo potrebbe portare anche al bloccarsi della storia per un tiro sfigato in un'azione. Devi raggiungere il tempio in cima alla montagna ma fallisci la prova di scalare? Bene, la storia si ferma. Chiaramente la Task ha invece senso se l'intento del gioco non è la storia, ma magari il dungeon crawling semplice e puro. In quel contesto il suo focus sull'azione potrebbe risultare più azzeccato e i suoi contro non rovinare l'esperienza, come insegnano molti giochi OSR (Old School Renaissance) come Lamentations of the Flame Princess (di James Raggin).
Fonti:
Prima di tutto però è importante capire cosa sia una meccanica di risoluzione.
Una meccanica di risoluzione è un tipo di meccanica (regola, procedura) che agisce quando due giocatori hanno due volontà diverse sullo Spazio Immaginato Condiviso (vi consiglio di leggere qua se non sapete cosa sia, perché potreste perdere pezzi di questo articolo) e questo tipo di meccanica può prevedere lanci di dado e altri sistemi aleatori, oppure nessun sistema casuale.
Per dirla in maniera più semplice, una meccanica di risoluzione si attiva in quei momenti in cui due o più giocatori vogliono accada qualcosa nella narrazione e le loro idee entrano in conflitto. Insomma, quando si tirano i dadi. Questa volontà può presentarsi a livello autoriale, ossia del giocatore puro e semplice, e quindi le regole tenderanno a gestire la risoluzione a livello dei giocatori (penso per esempio a giochi come Archipelago o Deus Opera), oppure lo scontro può subentrare a livello del personaggio, quando quest'ultimo è l'unico mezzo che ha il giocatore di impattare sulla narrazione, di solito attraverso le sue semplici azioni. In quest'ultimo caso le regole di risoluzione gestiscono le azioni e la volontà dei personaggi.
La maggior parte dei giochi di ruolo, praticamente tutti quelli più famosi, hanno meccaniche di risoluzione che ricadono nel secondo caso, quindi nell'ambito dei personaggi, gestendo se un personaggio riesce o meno a fare un'azione o a ottenere ciò che vuole. Ed è qui che arriviamo alla differenza tra Task resolution e Conflict resolution, rispettivamente risoluzione di compiti e risoluzione di conflitti. Queste sono i due tipi di risoluzione principali e la loro differenza sta tutta nella tabella qua sotto:
Task Resolution | Conflict Resolution |
Decide se un personaggio riesce in un’azione, e quanto bene.
| Decide il risultato di uno scontro di volontà contrapposte tra due o più personaggi |
Si focalizza sul riuscire / fallire | si focalizza sul vincere / perdere |
La posta della Task resolution è l’azione stessa. | La posta della Conflict resolution è il perché stai compiendo quell’azione. |
Tranquilli, adesso vi spiego tutto meglio e passo passo.
La Task resolution risolve un'azione o una serie correlata di azioni, come scalare, saltare, correre, costruire, e informa se quest'azione riesce, fallisce e, di solito, quanto bene viene svolta. Il personaggio riesce ad arrampicarsi sull'albero? Riesce a leggere l'antica iscrizione? Riesce a guidare la macchina? Riesce a... e così via e così via. La conflict resolution invece, come detto, è uno scontro tra due volontà contrapposte, ossia tra due personaggi che desiderano due cose mutualmente esclusive: se uno dei due ottiene quello che vuole, l'altro non può ottenerlo. Un personaggio fugge, l'altro lo insegue; un personaggio vuole muoversi di nascosto senza farsi scoprire dall'altro; due personaggi vogliono convincere il Boss dell'azienda a dar loro l'incarico prestigioso, e così via. In alcuni giochi, elementi naturali o oggetti possono venire trattati come aventi una volontà propria ai fini dell'intromettersi nei piani dei personaggi giocanti.
Ricapitolando, dunque: la Task risolve un'azione; la Conflict risolve uno scontro di volontà
Ricapitolando, dunque: la Task risolve un'azione; la Conflict risolve uno scontro di volontà
Capiamoci meglio
Vi faccio un veloce esempio per capirci meglio:Immaginate un famoso boss del crimine che sta organizzano un importante colpo grosso a una banca; un ladro si presenta da lui per ottenere la sua fiducia e far parte dell'operazione. Questi decide quindi di scassinare una complessa cassaforte davanti al boss, in modo da dimostrargli il suo valore e convincerlo a prenderlo con lui.
È il momento di una risoluzione, ma come la gestiamo? Task o Conflict?
- Gestendo la cosa attraverso la Task resolution stiamo regolamentando la riuscita dell'azione. Il ladro tira per scassinare la cassaforte. Se riesce la scassina; se fallisce non ci riesce e la cassaforte rimane inviolata.
- Con la Conflict resolution, invece, si regolamenta il convincere o meno il boss a prendere il ladro con se. Se il giocatore del ladro vince, allora il boss accetterà il ladro tra le sue fila; se perde, il boss non lo vorrà e potrebbe cacciarlo via.
Avete notato le differenze? No? Tranquilli, è normale. Capire al volo cosa cambia tra i due tipi di risoluzione non è automatico. È necessario spenderci qualche parola in più e notare alcune sottigliezze. Probabilmente starete pensando che in entrambi i casi, sia nella Task che nella Conflict, vincendo si convinca il boss scassinando la cassaforte e fallendo non si riesca a convincerlo perché la cassaforte non vuole saperne di aprirsi, giusto? Beh, no.
Nella Conflict resolution la risoluzione serve per decidere se otteniamo il nostro obiettivo: convinciamo il boss oppure no? Di base non ci dice se scassiniamo o meno la cassaforte, perché non è importante ai fini della "meccanica". Possiamo convincere il boss pur fallendo nell'apertura della cassaforte, o viceversa non convincerlo pur riuscendoci, perché la regola ci dice chiaramente se convinciamo o no il boss, ma non se apriamo o meno la cassaforte. Decidere se la cassaforte si apre o no è una decisione estetica arbitraria, che spesso spetta al GM (se c'è) oppure ad altri giocatori.
Per dirla meglio: nella Conflict conta l'obiettivo da raggiungere tramite l'azione (visto che in ballo c'è uno scontro tra due volontà), non l'azione stessa, anche se molti giochi fanno coincidere le due cose. Le regole dicono se a vincere è la propria volontà oppure no, e quindi se si raggiunge il proprio obiettivo oppure no.
Con la Task resolution invece è esattamente il contrario: sappiamo che in caso di riuscita scassiniamo la cassaforte, mentre in caso di fallimento non ci riusciamo. Le regole non dicono niente sul convincere o meno il boss. Dato che la Task ha come obiettivo la task stessa, ossia l'azione e la sua riuscita, e dato che essa regolamenta soltanto l'azione fine a sé stessa, i veri obiettivi di un'azione vanno risolti arbitrariamente da qualcuno al tavolo, di solito il GM. Nel nostro esempio quindi la regola ci dice se apriamo la cassaforte oppure no, ma a decidere se il boss viene convinto o meno è una persona al tavolo, solitamente il GM.
Per dirla meglio: nella Task conta la riuscita dell'azione, non l'ottenimento di un obiettivo. Il conflitto deve essere risolto da qualcun'altro al tavolo, arbitrariamente, e non attraverso i dadi.
Nel suo blog, Vincent Baker (autore di Cani nella Vigna e Apocalypse World), dal quale ho ripreso parecchi spunti presenti in questo articolo, fa un esempio un po' diverso. Nel suo esempio un eroe deve aprire una cassaforte perché al suo interno vi troverà le prove decisive per incastrare il cattivo. La differenza tra Task e Conflict è che con la Task l'obiettivo è l'azione stessa: riuscirà l'eroe ad aprire la cassaforte? Mentre con la Conflict l'obiettivo dell'azione è: l'eroe otterrà le informazioni che gli servono oppure il cattivo riuscirà a tenergliele segrete?
Con la Task tutto quello che conta è aprire la cassaforte: le prove potrebbero non essere lì dentro e l'eroe (e il giocatore, specialmente) potrebbe aver fatto tanta fatica per niente, ma questo non è importante perché la risoluzione era sull'aprire o meno la cassaforte, non sul trovare le prove per incastrare il cattivo; queste magari sono state tutto il tempo sotto il letto. Con la Conflict invece l'obiettivo è proprio ottenere le prove, e quindi se queste non si trovano nella cassaforte il conflitto non si può attivare perché non c'è nulla da risolvere; si attiverebbe, e quindi il giocatore andrebbe a tirare i dadi, pescare le carte o qualsiasi altra meccanica prevista dal gioco, solo se le prove fossero li dentro, e quindi ci fosse effettivamente uno scontro di volontà. In quel caso allora sì, vincere il conflitto significherebbe aprire la cassaforte e trovare le prove.
Adesso la differenza tra i due tipi di azione inizia ad esservi più chiara? Se sì, avrete sicuramente intuito come la Conflict sia di base un po' più chiara della Task. Essa infatti, regolamentando in maniera precisa se un personaggio ottiene o meno un obiettivo, dà una certa certezza al giocatore e toglie d'impiccio qualcun altro (di solito il GM) dal dover decidere arbitrariamente se si ottiene un certo obiettivo oppure no, ed è inoltre ottima per spingere verso la creazione di una storia emergente, poiché risolve i conflitti, che sono il cuore della narrativa, e dà una direzione precisa alla narrazione. Se Tizio e Caio si scontrano, con Tizio che vuole A e Caio B, la storia andrà in direzioni opposte in caso di vittoria di Tizio o di Caio. Pensate a storie come Game of Thrones, dove la volontà dei personaggi è palese e moltissime scene sono veri e propri scontri di volontà.
La Task invece tende a rimanere un po' più fumosa, visto il suo focalizzarsi soltanto sull'azione e non sul suo obiettivo, quindi ha funzionalità un po' più ridotte e più improntate a giochi non focalizzati alla storia; rischia infatti di spingere verso il rail roading perché, non regolamentando l'ottenimento di obiettivi specifici, demanda all'arbitrio di un'altro giocatore (il GM) la risoluzione del conflitto, dato che le regole decidono soltanto la riuscita o meno della pura azione. L'elemento solitamente più importante, ossia: "raggiungo il mio obiettivo?" non è regolamentato, e questo potrebbe portare anche al bloccarsi della storia per un tiro sfigato in un'azione. Devi raggiungere il tempio in cima alla montagna ma fallisci la prova di scalare? Bene, la storia si ferma. Chiaramente la Task ha invece senso se l'intento del gioco non è la storia, ma magari il dungeon crawling semplice e puro. In quel contesto il suo focus sull'azione potrebbe risultare più azzeccato e i suoi contro non rovinare l'esperienza, come insegnano molti giochi OSR (Old School Renaissance) come Lamentations of the Flame Princess (di James Raggin).
I giochi che le utilizzano
Storicamente parlando, molti giochi hanno utilizzato più la Task che la Conflict. Giochi classici come Dungeons & Dragons (D&D), Vampiri la Masquerade, Call of Cthulhu e altri gestiscono la maggior parte dei tiri come fossero Task, e questo è palese se si osserva come funzionano le abilità e i tiri in generale. I tiri di saltare, scalare o di conoscenza di D&D sono chiari esempi di Task, e regolamentano la riuscita o il fallimento dell'azione pura e semplice. Un esempio di Task purissima lo si può trovare in Sine Requie (di Leonardo Moretti e Matteo Cortini; Anno XIII prima edizione, pag. 100-103) in cui è presente l'abilità Lingua straniera (da prendere più volte per ogni lingua differente) e ci si aspetta che i giocatori peschino le carte su quell'abilità per verificare se il personaggio riesca effettivamente a parlare e capire in maniera corretta quando conversa utilizzando quella lingua. È l'esempio più estremo di Task che mi possa venire in mente.
Alcuni giochi d'impostazione comunque tradizionale utilizzano o hanno utilizzato accorgimenti legati alle Task. 13th Age (di Rob Hensoo e Jonathan Tweet) consiglia caldamente di utilizzare il metodo del fail forward, ossia di inserire degli imprevisti in caso di fallimento, in modo da non bloccare la storia: il ladro fallisce scassinando la cassaforte? Allora è possibile che quando è li intento a lavorarci sopra un coltello si poggi sulla sua gola e una voce profonda gli dica: "sai cosa facciamo noi ai ladri?" Un altro esempio ce lo fornisce la 4th edizione di Dungeons & Dragons con le sue sfide di abilità, in cui, almeno nel modo in cui il manuale intende debbano essere utilizzate, una serie di Task correlate porta alla risoluzione di una Conflict (o comunque qualcosa di somigliante).
A pensarci bene, il combattimento di D&D (e di tutti i giochi che lo utilizzano in maniera più o meno simile) è esso stesso un insieme di Task (il tiro per colpire, per esempio) che portano alla risoluzione di un Conflitto con obiettivo fisso uccidere ed evitare di venire uccisi. D'altronde, anche i giochi classici devono utilizzare la Conflict qualche volta, perché alcune skill sociali sono impossibili da gestire come Task. Esse infatti sono spesso uno scontro tra due volontà contrapposte, e quindi sono Conflict. Prendete per esempio l'abilità Diplomazia di D&D 3.5; è praticamente impossibile da utilizzare come Task (anche se il manuale riesce anche in quest'intento, con la tabella per modificare le intenzioni).
Veniamo quindi ai giochi che invece utilizzano chiaramente la Conflict come risoluzione base. Uno degli esempi più lampanti è senza dubbio Trollbabe (di Ron Edwards), in cui il tiro dei dadi risolve un conflitto di volontà e porta all'ottenimento di un goal (obiettivo); in questo contesto ogni successo viene narrato dal Master, mentre ogni fallimento dal giocatore. Questo accorgimento, che può apparire stupido, porta in realtà a dare un certo peso all'azione. Anche non ottenendo la posta un giocatore è spinto a narrare la riuscita della sua azione, cosa che rende sensato e più semplice continuare il conflitto sacrificando cose. Trollbabe è effettivamente il gioco che consiglierei a tutti per capire la Conflict resolution e le sue potenzialità.
Altro gioco interessante è The Mountain Witch (di Timothy Kleinert), che estende i conflitti anche ad oggetti o elementi naturali, dotandoli di volontà propria ai fini del conflitto. In questo frangente ha senso fare un conflitto contro una valanga, il cui scopo potrebbe essere "seppellirci". Sempre utile è considerare che alcuni giochi tendono a risolvere intere scene attraverso un conflitto, il quale può accorpare diverse azioni differenti e un certo lasso di tempo. Penso per esempio a come funzionano i conflitti in Grey Ranks (di Jason Morningstar) o Avventure in Prima Serata (di Matt Wilson). Altri giochi, per esempio Fate, possono spezzettare la Conflict in tante Task diverse (è così che funzionano Sfide, Competizioni e Conflitti all'interno del gioco). Quello che conta capire è che non tutti i giochi risolvono tutto con un solo tiro di Conflict, altri necessitano di tiri diversi e ripetuti. È tutta una questione di obiettivi di Design.
Emblematico è il caso di Apocalypse World (AW) e dei PbtA in generale (ossia tutti i giochi che utilizzano il motore di AW). Moltissimi giocatori tendono a considerare molte delle mosse di AW (le mosse sono le meccaniche di risoluzione del gioco) come delle Task resolution, mentre altri sostengono che tutto il gioco in realtà utilizzi solamente (o principalmente) Conflict resolution. A guardarle bene, mosse principali come Agire sotto il fuoco, Aggrare, Prendere con la forza e Sedurre e manipolare sono smaccatamente delle Conflict resolution. Prendere con la forza, per esempio, si attiva quando si utilizza la violenza per ottenere qualcosa da qualcun'altro, quindi come potrebbe non essere una Conflict? Le cose cambiano per mosse come Leggere una situazione o Leggere una persona, e specialmente per mosse come la postazione di lavoro del Fortificatore (che non tira dadi ma rimane comunque una Task), che paiono risolvere azioni piuttosto che scontri di volontà. Altre mosse, come Branco di Ladri del Chopper, dove si tira per vedere se qualcuno della banda ha l'oggetto che serve in quel momento, spostano il livello della risoluzione dal personaggio al giocatore, anche se in maniera impercettibile.
Lascio inoltre decidere a voi il tema del prossimo articolo della rubrica. Quale specifico argomento di design vorreste vedere affrontato?
Alcuni giochi d'impostazione comunque tradizionale utilizzano o hanno utilizzato accorgimenti legati alle Task. 13th Age (di Rob Hensoo e Jonathan Tweet) consiglia caldamente di utilizzare il metodo del fail forward, ossia di inserire degli imprevisti in caso di fallimento, in modo da non bloccare la storia: il ladro fallisce scassinando la cassaforte? Allora è possibile che quando è li intento a lavorarci sopra un coltello si poggi sulla sua gola e una voce profonda gli dica: "sai cosa facciamo noi ai ladri?" Un altro esempio ce lo fornisce la 4th edizione di Dungeons & Dragons con le sue sfide di abilità, in cui, almeno nel modo in cui il manuale intende debbano essere utilizzate, una serie di Task correlate porta alla risoluzione di una Conflict (o comunque qualcosa di somigliante).
A pensarci bene, il combattimento di D&D (e di tutti i giochi che lo utilizzano in maniera più o meno simile) è esso stesso un insieme di Task (il tiro per colpire, per esempio) che portano alla risoluzione di un Conflitto con obiettivo fisso uccidere ed evitare di venire uccisi. D'altronde, anche i giochi classici devono utilizzare la Conflict qualche volta, perché alcune skill sociali sono impossibili da gestire come Task. Esse infatti sono spesso uno scontro tra due volontà contrapposte, e quindi sono Conflict. Prendete per esempio l'abilità Diplomazia di D&D 3.5; è praticamente impossibile da utilizzare come Task (anche se il manuale riesce anche in quest'intento, con la tabella per modificare le intenzioni).
Veniamo quindi ai giochi che invece utilizzano chiaramente la Conflict come risoluzione base. Uno degli esempi più lampanti è senza dubbio Trollbabe (di Ron Edwards), in cui il tiro dei dadi risolve un conflitto di volontà e porta all'ottenimento di un goal (obiettivo); in questo contesto ogni successo viene narrato dal Master, mentre ogni fallimento dal giocatore. Questo accorgimento, che può apparire stupido, porta in realtà a dare un certo peso all'azione. Anche non ottenendo la posta un giocatore è spinto a narrare la riuscita della sua azione, cosa che rende sensato e più semplice continuare il conflitto sacrificando cose. Trollbabe è effettivamente il gioco che consiglierei a tutti per capire la Conflict resolution e le sue potenzialità.
Altro gioco interessante è The Mountain Witch (di Timothy Kleinert), che estende i conflitti anche ad oggetti o elementi naturali, dotandoli di volontà propria ai fini del conflitto. In questo frangente ha senso fare un conflitto contro una valanga, il cui scopo potrebbe essere "seppellirci". Sempre utile è considerare che alcuni giochi tendono a risolvere intere scene attraverso un conflitto, il quale può accorpare diverse azioni differenti e un certo lasso di tempo. Penso per esempio a come funzionano i conflitti in Grey Ranks (di Jason Morningstar) o Avventure in Prima Serata (di Matt Wilson). Altri giochi, per esempio Fate, possono spezzettare la Conflict in tante Task diverse (è così che funzionano Sfide, Competizioni e Conflitti all'interno del gioco). Quello che conta capire è che non tutti i giochi risolvono tutto con un solo tiro di Conflict, altri necessitano di tiri diversi e ripetuti. È tutta una questione di obiettivi di Design.
Emblematico è il caso di Apocalypse World (AW) e dei PbtA in generale (ossia tutti i giochi che utilizzano il motore di AW). Moltissimi giocatori tendono a considerare molte delle mosse di AW (le mosse sono le meccaniche di risoluzione del gioco) come delle Task resolution, mentre altri sostengono che tutto il gioco in realtà utilizzi solamente (o principalmente) Conflict resolution. A guardarle bene, mosse principali come Agire sotto il fuoco, Aggrare, Prendere con la forza e Sedurre e manipolare sono smaccatamente delle Conflict resolution. Prendere con la forza, per esempio, si attiva quando si utilizza la violenza per ottenere qualcosa da qualcun'altro, quindi come potrebbe non essere una Conflict? Le cose cambiano per mosse come Leggere una situazione o Leggere una persona, e specialmente per mosse come la postazione di lavoro del Fortificatore (che non tira dadi ma rimane comunque una Task), che paiono risolvere azioni piuttosto che scontri di volontà. Altre mosse, come Branco di Ladri del Chopper, dove si tira per vedere se qualcuno della banda ha l'oggetto che serve in quel momento, spostano il livello della risoluzione dal personaggio al giocatore, anche se in maniera impercettibile.
In conclusione
Per oggi ci fermiamo qua. L'articolo è servito a qualcosa? Sono riuscito a spiegarvi la differenza tra i due tipi di risoluzione oppure no? Avete dubbi o critiche? Se sì non esitate a commentare.Lascio inoltre decidere a voi il tema del prossimo articolo della rubrica. Quale specifico argomento di design vorreste vedere affrontato?
Fonti:
- D. Vincent Baker, Conflict Resolution vs. Task Resolution, 2004, in Lumpley.Com/hardore che trovate a questo indirizzo.
- Moreno Roncucci, Breve Storia del Game Design intelligente, 2016, in gentechegioca.it, specificatamente questo doppio post.
- Big Model Wiki, Conflict resolution e Task resolution.
Nessun commento:
Posta un commento