Quando fare la prova nella Task

[Zaidar]

Rispondo:

Ottimo modo per decidere quando una prova è da farsi oppure no... è il metodo migliore.
mi spiace solo sia a Conflict perché mi stava interessando

Io sono assolutamente convinto che il metodo del "se il fallimento non produce risultati interessanti per il prosieguo della storia/avventura non tirare" sia applicabilissimo anche alla task resolution. Ma nessuno ha mai approfondito il concetto, almeno che io sappia.

(PS se mi sbaglio e qualcuno vuole portare esempi, apriamo un altro thread così non facciamo Off Topic)

E' molto facile infatti. So che non fa testo, però nel nostro Horizon abbiamo focalizzato l'attenzione su quando una prova è da farsi o non farsi, e abbiamo scritto questo:

In generale, una Prova va effettuata sempre e solo quando il suo esito può portare a due sviluppi differenti dell'avventura entrambi interessanti. Quindi, niente prove inutili, noiose, che non aggiungono niente, che fallirebbero automaticamente o il cui successo è scontato: in tutte queste situazioni, non importa che facciate una prova. Descrivete semplicemente come svolgete l'azione, e come questa si risolve. Se non interessa a nessuno, se è solo una seccatura se fallisce... in tutti questi casi, risparmiatevi la Prova. Infatti, la Prova va “chiamata” da qualcuno: se nessuno la richiede, descrivetre cosa fate, e lo fate. Effettuate la Prova quando il momento è concitato, quando superarla o meno potrebbe fare la differenza, quando è strettamente necessario un risultato numerico.

e ancora, nella sezione riguardante il Master:

Ricordati quindi che una Prova deve esser fatta solo e ogni volta che entrambi gli esisti di essa possono condurre a sviluppi differenti ed ugualmente interessanti o cruciali. Chiediti sempre, tu Master, prima di far effettuare una prova: “cosa succede se fallisce?”. Se non riesci a trovare una risposta a questa domanda, probabilmente quella Prova è inutile, e potreste andare anvanti senza farla e passare a qualcosa di più interessante. Se per certe cose il fallimento delle prove rappresenta solo una seccatura, o il loro successo è impossibile, non fate alcuna Prova, ma narrate direttamente l'esito! Non ci sono Prove che servano per parlare, per camminare o per aprire la porta: sono cose automatiche! Se vuoi che i giocatori trovino un indizio particolare per completare l'indagine, non fargli fare Prove per trovarlo: appena descrivono che "frugano nella stanza alla ricerca di indizi", basta semplicemente che tu dica "trovate una macchia di sangue nell'angolo, che prima non avevate notato". Una Prova in quel caso, se fallisse, non farebbe che perdere tempo ai giocatori. Tutt'altra faccenda è quando, se dovessero non notarla subito, quella macchia di sangue strana, la polizia potrebbe fare irruzione beccandoli proprio sul luogo del misfatto ritenendoli colpevoli! Quello sì che può essere un bivio interessante!

Ci sono poi delle ulteriori clausole:

Ritentare una Prova
Quando una Prova viene fallita non potete semplicemente fare spallucce e riprovare. No. Questo vi suggerisce che state sbagliando qualcosa. Se il fallimento della prova non implica nessuna conseguenza interessante, allora probabilmente la Prova stessa non era da compiere. Infatti, ogni volta che una prova viene Fallita significa che un'occasione è stata persa, che non si hanno le competenze giuste, che un guaio non è stato evitato. Se non avviene nessuna di queste cose... allora perchè avete fatto una Prova? In generale, le Prove non si possono semplicemente "ritentare". Se falliscono, qualcuno si farà del male, perderete del tempo (minuti o ore, non semplici AE), sprecherete risorse o soldi, oppure il Master vi dichiarerà che non avete le conoscenze adeguate e che quindi quella Prova diviene per voi Impossibile, almeno finchè non cambiano le condizioni con cui la tentate.
Prove che diventano Impossibili: quando un personaggio effettua una prova, molto spesso questo serve a determinare se sia in grado o meno di compierla. Se fallisce, essa può provocare esiti immediati (il personaggio spreca delle risorse, subisce dei Danni o effetti collaterali eccetera), ma altre volte potrebbe essere un semplice "non ce la faccio". Questo potrebbe avvenire ad esempio con prove di precisione o di abilità particolari, come saper guidare un veicolo, scassinare una porta, bypassare un sistema informatico. Ogni volta che, ad eccezione di poche AE di tempo perse, non vi è alcun effetto immediato e/o irrevocabile in conseguenza di una prova Fallita (nessuna risorsa consumata, nessun evento innescato, nessuna penalità subita ecc.), dovete considerarla come Impossibile da riprovare. Se ad esempio fallite la prova per vedere se riuscite a creare un contatto elettrico per rubare un'auto, vuol dire che non sapete come fare, o che vi manca uno strumento adatto, o che non ce la fate da soli. Non potrete riprovare, a meno che non cambi qualcosa: vi dotate di qualche strumento differente, vi fate aiutare da qualcuno, le condizioni dell'oggetto cambiano in modo interessante e così via. Finchè non si verifica uno di questi eventi, non avrebbe senso ripetere la Prova, e così non la fate.
Prove che diventano Automatiche: ma a volte può succedere anche l'opposto, e cioè che una prova, una volta passata, diventi automatica. Ad esempio, se dovete sabotare dieci porte di sicurezza tutte uguali usando il vostro perforatore protonico, non dovrete compiere 10 prove! Sarebbe un incredibile spreco di tempo! Una volta che avete dimostrato che sapete farcela con la prima porta, potrete fare lo stesso con tutte le altre senza dover ripetere la prova. Questo è il caso di una prova che una volta superata diviene Automatica. Al solito, la Prova è da ripetere se le condizioni cambiano in qualche modo: avete uno strumento in meno, avete consumato delle risorse che vi servivano, avete accumulato una penalità o in qualche modo le condizioni dell'oggetto della vostra prova sono cambiate in modo interessante. Quando succede una di queste cose, può essere necessario effettuare di nuovo una prova, altrimenti no.

E' in qualche modo simile mi pare a come avviene la valutazione in Nameless Streets, però il gioco è a task.

 

[xarabas81]

è un pò strano, nel senso che nel vostro gioco state formalizzando alcune procedure di gioco che sono anche alla base di giochi più moderni ed insieme ci mettete anche altr procedure che sono invece state sempre sottintese anche in giochi più tradizionali:

l'esempio dell'indizio mi ricorda il gumshoe.
il fatto di non fare prove se il successo è autamatico o troppo difficle, c'è praticamente anche in D&D.

ma alcune dubbi mi vengono in mente.

sempre l'esempio dell'indizio:

i giocatori sanno che la polizia li può trovare nella stanza? lo sa solo il master? in quel caso solo lui può chiamare la prova...

alla fine messa così, spero di non sbalgiare, ma sembra quasi una risoluzione mascherata da task, oppure una risoluzione a conflitti non completa.

perchè dico questo?

perchè tiri la task solo se ci sono esiti interessanti sia in un caso che nell'altro, ma poi in gioco nessuno ti assicura che quell'esito entrerà in gioco, sia in un caso che nell'altro.

faccio un esempio:

dovete sfondare una porta velocement eperchè qualcuno vi sta inseguendo.

tirate quindi, perchè il risultato è interessante sia per un successo che per un insuccesso.

solo che il successo o l'insuccesso non vanno ad incidere sui risultati supposti interessanti. se ho successo sfondo la porta, ma nessuno mi assicura che comunque i nemici non mi raggiungeranno, se fallisco, potrei comunque scappare dai nemcii che mi inseguono.

trovo questa possibilità un fatto che porta contraddizione all'interno delle regole.

spero di essermi spiegato.

 

[Zaidar]

premetto che i pezzi li ho tratti da paragrafi e forse qualcosa c'era anche prima o dopo che completava il senso.

i giocatori sanno che la polizia li può trovare nella stanza? lo sa solo il master? in quel caso solo lui può chiamare la prova...

solo il Master, e se a lui sembra che ci voglia una prova, ci vuole. Quando si parla di giocatori con la G minuscola intendiamo le persone fisiche al tavolo, quindi anche lui conta come un "chiamatore di prove autorizzato".

dovete sfondare una porta velocement eperchè qualcuno vi sta inseguendo.

tirate quindi, perchè il risultato è interessante sia per un successo che per un insuccesso.

solo che il successo o l'insuccesso non vanno ad incidere sui risultati supposti interessanti. se ho successo sfondo la porta, ma nessuno mi assicura che comunque i nemici non mi raggiungeranno, se fallisco, potrei comunque scappare dai nemcii che mi inseguono.

trovo questa possibilità un fatto che porta contraddizione all'interno delle regole.

spero di essermi spiegato.

non riesco a capire dove sia il controsenso... cioè, nell'esempio, perché la prova la fai? O meglio, perché i giocatori (tutti) dovrebbero farla? Presumo perché a qualcuno (ne basta 1 chiunque sia) il fallimento pare interessante e il successo possibile, sono due situazioni diciamo "incerte". Ci è capitato a volte di fare delle prove così, senza pensare a quanto scritto sopra, e incappare in fallimenti noiosi (Stasera per esempio ho giocato a pathfinder ed ho tirato 3 volte Sapienza Magica per identificare un oggetto... è quello che vogliamo evitare!). Pian piano s'impara, c'è un po' da perdere il vizio. Solitamente nelle sfide è il Master che deve "mettere alla prova", ma non è raro che gli altri compagni richiedano prove ad altri personaggi (per una meccanica di competizione interna che ora mi fa fatica spiegare potrebbero anche averci profitto se un compagno fallisce ma soprattutto per gustarsi la scena). Potrebbe anche il master ritenerla cosa da bypassare e farla sfondare e pace, e proseguire, magari perché gli pare logico così. Se nessuno prende i dadi in mano o lo chiede a qualcun altro, non si fanno prove.
Sul raggiungimento degli inseguitori quello è ben determinato dal fatto che le distanze sono univoche in metri al turno (varie, non rigide come i 9 metri per tutti di D&D), e sfondare sebbene possa avere un successo automatico costa comunque tempo non eliminabile.

EDIT: ah comunque che l'esito alternativo sia interessante è ovviamente una possibilità, non una sicurezza. Sinceramente però che non fosse tale mi è capitato solo facendo prove senza pensare, o da master senza pensare agli esisti di un fallimento "ridicolo", quindi senza avere quei concetti di cui sopra in mente.

EDIT 2: ah, dimenticavo: ovviamente essendo a task non tiri "per sfuggire agli inseguitori" ma per "sfondare la porta", non hai comunque controllo sugli esiti... quindi di ogni prova (ogni task) dovresti a senso capacitarti se è topica o no, e lo fai istintivamente senza sforzo mi pare.

 

[xarabas81]

È quello che trovo contraddittorio: tiri quando l'esito può essere intetessante, ma l'esito non c'entra niente con il risultato della prova.

Vediamo se mi spiego meglio:

Nel mio esempio sopra (molto banale, ma basta che sia comprensibile pet lo scopo della discussione) che cosa è interessante e quindi mi fa chiamare la prova da uno dei giocatori al tavolo? Lo sfondare la porta oppure no o la possibilità di scappare o no dagli inseguitori?

In questo senso trovo la possibilità del chiamare la prova secondo le regole esposte molto interessante, ma fuorviante inserito in quel contesto di regole. Infatti

a[/quote

Lo fai pensando come fosse un conflitto, cioè al risultato non della dingola porta (sfondare o no che di per se è una prova banale) ma scappare o no

 

[Zaidar]

Continuo a non trovare il problema sinceramente, forse perché non avviene mai in gioco.
l'Esito è "della prova", non "del conflitto/scena". Se non è interessante l'esito DELLA PROVA.
Cioè non ti stai chiedendo se essere raggiunto o no sia interessante, ma ti stai chiedendo se sfondare la porta direttamente o doverci spendere altro tempo o fatica lo sia. E ovviamente questo idealizzando le possibili conseguenze. Non c'entra niente con la mentalità da Conflict.

Nella mente quando penso di trovarmi nei panni del mio personaggio e penso "devo scappare da qui" io indirizzo le mie azioni a quel fine, che poi lo realizzino o meno sta alla mia intelligenza, abilità e ad un sacco di altri fattori.
Nella fattispecie, "scappare" non è una cosa con cui mi cimento immediatamente, ma è composta da "muovo questo passo" "muovo questo passo" "muovo più veloce" "porto la spalla avanti" "colpisco porta".
Insomma per raggiungere uno scopo devi comporre delle piccole azioni, che solo la tua intelligenza (e istinto e altre cose) presume che porteranno alla fine ad avere un risultato. Questo è quanto vogliamo riportare nel gioco, con delle ovvie ed enormi semplificazioni.
Ma è automatico (almeno per me date quelle premesse) valutare quando una prova per questa task sia necessaria e quando no. Ad esempio se sto scappando per strada non dovrei fare prove per vedere se inciampo (nel mio gruppo), mentre se corro nel sottobosco lo "sento" più difficile e chiamerei una prova. E' interessante per me (personalmente, tutto il metodo è soggettivo) perchè mi da il senso della verosimiglianza della scena e appunto mi allontana da un sistema a Conflict dove questi dettagli non ci sono. Ma al contempo mi evita anche che le prove da fare siano un numero esoso (vedi Ritentare) e mi assicura la loro rapidità.
Come dire: ognuno ha una visione differente della scena e per ciascuno "il difficile" può nascondersi in qualcosa, e quindi può chiamarlo. esperienza insegna che 8 volte su 10 è il Master a chiamare queste prove (per suo dovere), ma non è raro che lo siano anche i giocatori stessi, quando avvertono che l'azione tentata non è "così banale".
Ah, e ovviamente non è scritto da nessuna parte che non si possa discuterne.

Riassumento:
A qualcuno interessa? Si -> prova.
A qualcuno interessa? No -> no prova, narri come se successo.
Fine.

Della serie: se non siamo in un combattimento o abbiamo fretta, a nessuno frega di sfondare la porta di legno al primo tentativo. Quindi semplicemente il tiro in quel caso a cosa servirebbe? E' senso comune che lì non c'è "ciccia", mentre giochi lo percepisci.
Se il Master la pensa diversamente, o se la porta è un aspetto Competitivo di un box, ti dice invece: "fammi una prova". Tu giocatore a quel punto drizzi le orecchie: se fallisci dovrebbe succedere qualcosa. Magari vi sentono, magari c'è una trappola, ma tant'è che ormai non ti puoi tirare indietro perché ormai l'hai fatto. Comunque, da quella prova in poi qualcosa cambierà. Perchè se fallisci avviene qualcosa, e se non avviene niente, allora quella porta è per te Impossibile da aprire (vedi Ritentare).
Magari la cosa è interessante per il Master perchè vuole rendervi le cose difficili. Magari perchè vuole che passiate da un'altra parte. Magari perchè è interessante mostrare che in quel palazzo non si entra facilmente (aspetto Competitivo del box).

 

[Arioch]

Il titolo del thread non dovrebbe essere "quando fare la prova in Horizon"?

 

[Zaidar]

Il titolo del thread non dovrebbe essere "quando fare la prova in Horizon"?

no no, con la Task... Rosen chiedeva di titoli che usavano un sistema simil-Nameless e che non fossero a Conflict... io conosco solo questo, ma se qualcun altro può arricchire ben venga!

 

[RosenMcStern]

è un pò strano, nel senso che nel vostro gioco state formalizzando alcune procedure di gioco che sono anche alla base di giochi più moderni ed insieme ci mettete anche altr procedure che sono invece state sempre sottintese anche in giochi più tradizionali:

Sempre? No, non sempre. Ormai la maggior parte dei giochi tradizionali include questo tipo di regole.

il fatto di non fare prove se il successo è autamatico o troppo difficle, c'è praticamente anche in D&D.

ATTENZIONE: c'è una enorme differenza tra "non tirare se la matematica dice che difficilmente fallirai/riuscirai" e le regole suesposte da Zaidar. E la maggior parte dei giochi tradizionali "ultima edizione" (con Savage Worlds come grande assente) introduce regole simili.

Esempio tipico: Sine Requie. In Sine hai sempre almeno una probabilità su 7 di fallire un task, e anche essendo bravo è difficile avere 10 come livello di successo. Ma le regole ti dicono con molta precisione quando non tirare e quando si, e non c'entra niente il numero complessivo, si considera solo il livello di abilità e non la caratteristica dominante.

Immaginiamo di volere sparare contro un bersaglio fisso "per fare gli sboroni". La prova è "Mira + metà di uso -pistola-" e il Task è facile (+4). Django è un talento naturale e ha Mira 5 ma è un pivello con 2 di uso -pistola-, raggiunge il 10 per via del bonus ma deve estrarre un Arcano Minore, se esce il Fante o la Donna farà brutta figura. Fratello Ralph ha Mira 2 për via dell'età ma è un veterano con 5 di uso -pistola-, in tutto raggiunge un modesto 8 ma secondo il regolamento, siccome ha 5 nell'abilità e il task è facile, NON DEVE ESTRARRE UN TAROCCO: colpisce automaticamente.

Come vedi le regole sono ben più sofisticate del "se il numero è alto non tirare", e prendono in considerazione il tipo di task, non la mera matematica che in teoria sarebbe stata in favore di Django.

solo che il successo o l'insuccesso non vanno ad incidere sui risultati supposti interessanti. se ho successo sfondo la porta, ma nessuno mi assicura che comunque i nemici non mi raggiungeranno, se fallisco, potrei comunque scappare dai nemcii che mi inseguono.

Embé?

Il discriminante è di tirare quando l'azione potrebbe essere significativa, non di tirare solo quando l'azione è risolutiva. Non vedo alcuna contraddizione. Il fatto che poi sia necessario inserie nella narrazione altre azioni per completare la scena non inficia i due fatti seguenti:

1) il tiro era necessario perché aprire o meno la porta potrebbe "fare la differenza"

2) il fatto di avere descritto se il personaggio apre o no la porta, anche a scena non risolta, aiuta a creare la tensione che dovrebbe accompagnare una buona scena di azione

 

[Domon]

Com si dichiara "facile" un task di sine?e

 

[RosenMcStern]

Ci sono un paio di pagine di criteri per capire che cosa si intende per "facile", "medio" ecc.., a differenza di GURPS 3e o Savage Worlds dove c'è un laconico "decide il Master". Nel caso specifico credo che uno degli esempi sia proprio quello del tiro con la pistola a un bersaglio fisso, per cui se il Cartomante sta ********ndo il regolamento per "farti tirare per forza" te ne accorgi subito.

 

[crotalo]

Ci sono un paio di pagine di criteri per capire che cosa si intende per "facile", "medio" ecc.., a differenza di GURPS 3e o Savage Worlds dove c'è un laconico "decide il Master". Nel caso specifico credo che uno degli esempi sia proprio quello del tiro con la pistola a un bersaglio fisso, per cui se il Cartomante sta ********ndo il regolamento per "farti tirare per forza" te ne accorgi subito.

in realtà per esperienza diretta secondo me non è così facile ... molte volte cose che per me erano facili per il GM erano difficili. cioé si tende sempre più alle sfumature

è un po' come l'occasione d'oro di DW. quando è un occasione d'oro? c'era un post mio che facevo un esempio di azione che per non era ma pe Zaidar era occasione d'oro ... mi pare che DW si salvi dicendo che occasione d'oro è solo se una soft move viene ignorata, ma in molti regolamenti a task che ho letto non viene stabilito un criterio oggettivo o un meccanismo di salvaguardia (spesso nei conflict le poste sono scelte dal giocatore o concordate)

 

[RosenMcStern]

in realtà per esperienza diretta secondo me non è così facile ... molte volte cose che per me erano facili per il GM erano difficili. cioé si tende sempre più alle sfumature

è un po' come l'occasione d'oro di DW. quando è un occasione d'oro? c'era un post mio che facevo un esempio di azione che per non era ma pe Zaidar era occasione d'oro ...

Infatti è esattamente lo stesso: la regola si basa sul "comune sentire" tra giocatori, quindi richiede che i due si mettano d'accordo secondo il comune buon senso. La differenza è tra giochi in cui ti spiegano come usare correttamente il buon senso e giochi in cui l'autore se la cava con un "tanto c'è il GM per quello", aprendo la strada al GM-dio e tutto ciò che sappiamo. Se poi i due non riescono a raggiungere un compromesso manco con le "istruzioni per l'uso", c'è il forte sospetto che i problemi siano di natura sociologica e non di regolamento.

 

[Arioch]

Sostanzialmente vi interessano esempi di giochi con quello che alcuni chiamano "fail forward"?
La task resolution dei giochi di Crane (Burning Wheel, Mouse Guard, Torchbearer) funziona così, i fallimenti generano sempre risultati interessanti.
Non ho letto 13th Age, ma mi pare si basi sullo stesso concetto.
Ho invece letto e giocato di recente Tenra Bansho Zero, che funziona sempre nello stesso modo: si tira solamente se sia il fallimento che il successo sono interessanti.

 

[RosenMcStern]

Sostanzialmente vi interessano esempi di giochi con quello che alcuni chiamano "fail forward"?

Direi che ci interessano piuttosto giochi con sistemi di Task "che funzionano". Il semplice "non ci riesci" è già un risultato interessante se ti costringe a cercare un metodo alternativo. La discriminante qui è che in un gioco a Task "che funziona" il GM deve prima chiedersi se in caso di fallimento esiste un metodo alternativo. Se la risposta è "no", ossia la storia si pianta in caso di fallimento, allora il task non va tirato.

Notare inoltre che anche Sine Requie ha il "fail forward". Ogni volta che esce la donna c'è un "insuccesso però", in cui il fallimento è accompagnato da eventi che consentono o facilitano una soluzione alternativa. Se uno prova a leggerlo, questo benedetto Sine, si accorge che ha alcune meccaniche ben fatte.

 

[crotalo]

Sostanzialmente vi interessano esempi di giochi con quello che alcuni chiamano "fail forward"?
La task resolution dei giochi di Crane (Burning Wheel, Mouse Guard, Torchbearer) funziona così, i fallimenti generano sempre risultati interessanti.
Non ho letto 13th Age, ma mi pare si basi sullo stesso concetto.
Ho invece letto e giocato di recente Tenra Bansho Zero, che funziona sempre nello stesso modo: si tira solamente se sia il fallimento che il successo sono interessanti.

ma nei giochi di crane la task a me pare quasi sempre un conflict resolution (forse torchbearer meno). magari mi sbaglio

 

[xarabas81]

Direi che ci interessano piuttosto giochi con sistemi di Task "che funzionano". Il semplice "non ci riesci" è già un risultato interessante se ti costringe a cercare un metodo alternativo. La discriminante qui è che in un gioco a Task "che funziona" il GM deve prima chiedersi se in caso di fallimento esiste un metodo alternativo. Se la risposta è "no", ossia la storia si pianta in caso di fallimento, allora il task non va tirato.

riprendendo un'altra discussione in corso, quindi cercate qualcosa di diverso dai famosi fallimenti nelle prove di cercare indizi nel d100 di cthulhu?

Notare inoltre che anche Sine Requie ha il "fail forward". Ogni volta che esce la donna c'è un "insuccesso però", in cui il fallimento è accompagnato da eventi che consentono o facilitano una soluzione alternativa. Se uno prova a leggerlo, questo benedetto Sine, si accorge che ha alcune meccaniche ben fatte.

se non erro c'è anche il "successo però", nel senso che l'azione ha successo, ma non nel modo previsto dal giocatore.

 

[RosenMcStern]

riprendendo un'altra discussione in corso, quindi cercate qualcosa di diverso dai famosi fallimenti nelle prove di cercare indizi nel d100 di cthulhu?

No, cerchiamo qualcosa che usa la soluzione più semplice ("non mettere indizi indispensabili dietro tiri che possono impantanare la storia", ossia "se sai che ti impantana non far tirare") piuttosto che quella "insipida" che usa GUMSHOE o quelle complessa che usa Cthulhu 7 per "metterci una pezza" dopo avere fatto tirare.

 

[Arioch]

Direi che ci interessano piuttosto giochi con sistemi di Task "che funzionano". Il semplice "non ci riesci" è già un risultato interessante se ti costringe a cercare un metodo alternativo. La discriminante qui è che in un gioco a Task "che funziona" il GM deve prima chiedersi se in caso di fallimento esiste un metodo alternativo. Se la risposta è "no", ossia la storia si pianta in caso di fallimento, allora il task non va tirato.

Io lascerei stare il concetto di storia, perché è un po' un ginepraio. Mi fermerei al "produrre conseguenze interessanti".

ma nei giochi di crane la task a me pare quasi sempre un conflict resolution (forse torchbearer meno). magari mi sbaglio

Nì, nel senso che ci sono tutte e due (BTW, se non lo conoscete e volete darci un'occhiata, trovate i primi capitoli di BW tradotti in ita qui).

Il fatto è che, secondo me, questo tipo di gestione delle task (tira solo per generare risultati interessanti) tende (e sottolineo tende) a far virare verso la conflict, perché si va automaticamente a dare più importanza al risultato finale che non all'azione intrapresa in sé.
Ovviamente non voglio dire che basta questo per trasformare magicamente una task resolution in conflict, dico solamente che diventa più simile.

Ma, domanda da assolutamente ignorante visto che devo ancora provarlo, Apocalypse World non è fatto proprio per questo?

 

[Domon]

"In BW there are 3 different systems of detailed conflict resolution."

secondo me i giochi di crane sono a conflict resolution

 

[Arioch]

"In BW there are 3 different systems of detailed conflict resolution."

Che sono Duel of Wits, Range and Cover e Fight!, i tre sistemi di conflitto dettagliati di BW. Dettagliati nel senso che sono più complessi del semplice Versus Test, che è invece il metodo di risoluzione dei conflitti meno dettagliato. E ci si aggiungono i test normali, che vengono usati anche per risolvere delle semplici task.

Insomma, credo tu abbia preso un granchio con quella quote, perché intende proprio tutta un'altra cosa. Piuttosto avresti potuto citare il capitolo "Vincent's Admonition", che parla proprio dei tiri in gioco e dei conflitti (è incluso nella parte tradotta linkata sopra, se volete leggerlo).

Ed è uno dei motivi per cui credo che prendendo in considerazione queste cose si viri in automatico verso la conflict.