lunedì 5 maggio 2014

Sul fallimento, il successo e le loro conseguenze

Avanti eri, parlando con un ragazzo molto appassionato che mi ha sottoposto il suo neonato gioco di ruolo, mi è capitato di parlare del ruolo del fallimento e del successo nei giochi di ruolo. Si tratta di un aspetto che potrebbe sembrare scontato ma che però, a pensarci bene, è molto, molto importante perché aiuta e spinge il ritmo della storia.

Riesco o fallisco?
Analizziamo più nel dettaglio cosa intendiamo per successo e per fallimento.
Intanto, fallire e riuscire... in cosa? ovviamente, in una prova. E cos'è una prova? In molti GDR (non in tutti, sia chiaro) una prova avviene quando un personaggio tenta di fare qualcosa di difficile in cui potrebbe fallire. Insomma, un'azione non di routine. In quasi nessun GDR è richiesta una prova per leggere o per spostare un bicchiere o parlare nella propria lingua. Sono azioni di routine che si ritiene un personaggio possa compiere senza problemi.
Una prova è invece richiesta quando un personaggio si arrampica, fugge, combatte, nuota, vuole convincere qualcuno, salta un fossato e così via. Si tratta di azioni non di routine, cose che il personaggio potrebbe fallire. Nessuno fallirebbe nel sollevare un bicchiere d'acqua, ma potrebbe invece fallire nel saltare un fossato di due metri. Quindi, ecco che diviene importante sapere se una data azione riesce oppure fallisce.

Molti giochi utilizzano un sistema casuale e aleatorio, e spesso e volentieri i dadi, proprio per ottenere la risposta alla domanda: "l'azione riesce oppure fallisce?". I dadi, le carte, e qualsiasi altro sistema casuale sono ottimi perché sono imparziali. Un essere umano, per quanto cerchi di essere obiettivo, troverà molto difficile decidere se un'azione riesce o fallisce senza essere guidato da motivi soggettivi, e a pensarci, questo potrebbe portare a malcontento e a conflitti sociali al tavolo. Immaginate che sia il GM a decidere se un giocatore riesce o fallisce! Chi ci dice che il GM non farà preferenze, avvantaggiando così la bella bionda (o il bel biondo) seduta al suo fianco? Con i dadi non ci sono questi problemi. Il caso non fa mai preferenze.
Quindi, a pensarci, il vero motivo per cui i dadi sono importanti non è perché simulano la casualità del mondo fisico (sarebbe stupido pensarlo, nel mondo reale le variabili  sono infinitamente più complesse), ma perché tolgono d'impiccio le persone nel decidere se una prova riesce oppure no.

Ogni gioco suggerisce o utilizza metodi diversi per capire se una prova riesce oppure no. Si chiama metodo di risoluzione. In ogni caso, sia che si usino d20, d10, d6, carte o tarocchi. Che ci siano tiri contrapposti, classi difficoltà da superare o altri metodi, tutto porta al capire chi vince e chi perde, se si riesce oppure si fallisce. Insomma, come si risolve un'azione. Per il discorso che stiamo per fare non ci interessa quale metodo aleatorio verrà utilizzato per la prova. Non è importante saperlo.

Quel fatidico momento in cui i dadi rotolano e la propria sorte è lasciata al caso.

Azione VS Obiettivo
Ma cosa succede quando si riesce o si fallisce?
Semplificando, ci sono due modi di gestire una prova e tutto sta nel decidere se una prova gestisce la riuscita dell'azione oppure il raggiungimento di un obiettivo.

Focus sull'azione
Questo tipo di approccio, che possiamo chiamare anche Task Resolution, si focalizza sulla riuscita o meno della singola azione che il personaggio sta svolgendo. Se un personaggio sta saltando un muretto la prova ci dirà se ci riesce o meno. Con un successo, bene, il personaggio salta il muretto. Con un fallimento, no, mi spiace, non ci riesce.

Focus sul raggiungimento di un obiettivo
Questo tipo di approccio, che possiamo chiamare anche Conflict Resolution, si focalizza sul raggiungimento di una posta, e non unicamente sulla riuscita dell'azione. Non ci interessa sapere che cosa fa il personaggio, ma perché lo fa. Perché salta il muretto? Beh, potrebbe star scappando da degli inseguitori. Se riesce allora semina gli inseguitori tramite il salto del muretto. Se fallisce, beh, non li semina. Da notare come questo tipo di risoluzione esista solo in concomitanza con un contrasto tra due o più entità per l'ottenimento di obiettivi diversi. Il pg vuole seminare gli inseguitori, ma loro lo vogliono raggiungere. 

Paragoniamo i due metodi
Ragioniamo velocemente su questi due punti, tenendo conto anche del fatto che, se si tirano i dadi, vuol dire che quell'azione vene posta sotto i riflettori e diviene importante per l'economia del gioco e per la storia.
Quando un personaggio fa qualcosa, lo fa semplicemente per farlo oppure per ottenere qualcosa? In una storia, saltare un muretto tanto per saltarlo è un'azione neutra, persino noiosa, perché non porta in una direzione precisa. Non fa succedere nulla di davvero significativo. Addirittura, vedere il protagonista che non riesce a saltare un muretto potrebbe essere ridicolo. Ha senso darle risalto mettendo in gioco una prova, con il rischio di bloccare il gioco?
Saltare il muretto per seminare gli inseguitori, invece, è un'azione "attiva", perché la sua riuscita comporta qualcosa all'interno della storia. Se riesce, il personaggio semina gli inseguitori. Se non ci riesce, invece, non significa che non salta il muretto. Potrebbe saltarlo, ma nonostante questo non seminare gli inseguitori.

Immaginiamoci quindi una situazione dove è importante sapere se il personaggio raggiunge un obiettivo e proviamo a gestirla focalizzandoci sull'azione (ricordate? Task Resolution!). Immaginiamo il classico guerriero di D&D. Si trova nella cantina di una taverna. Davanti a lui, due orchi armati di ascia gli stanno correndo addosso. Vicino a lui, una pila di barili molto pesanti. Decide quindi di rovesciare i barili in modo da frenare l'avanzata degli orchi. Vuole proprio fermarli. 

Ora, lasciamo perdere la necessità di prove contrapposte, CD, metri al secondo, azioni per round e altri elementi simili. Basiamoci solo su ciò che è importante: riesce oppure fallisce? Li ferma oppure no? Ricordatevi anche che il focus è sull'azione, sulla Task, quindi la prova è per vedere se il guerriero butta giù i barili oppure no. Se ci riesce, i barili cadono. Se fallisce, i barili non cadono. Ma in ogni caso, non sappiamo se gli orchi vengono frenati, perché la prova non è stata effettuata per sapere quello. La prova riuscita ci dice che i barili cadono, non che gli orchi vengono frenati. A questo punto, la persona che narra l'esito dell'azione, tipicamente il GM ma non è detto, potrebbe descrivere che si, i barili cadono, ma gli orchi saltano i barili, trasformando in insuccesso il successo del guerriero, tutto a discreto arbitrio del narratore. A questo punto, che fine fa il discorso dei dadi come arbitri imparziali? Alla fine, la cosa davvero importante (se gli orchi vengono fermati  o meno) l'ha decisa una persona. 

Orchi in carica! Orchi in carica! Preparate i barili!
Dunque, a ben vedere, è molto meglio se la prova regoli il raggiungimento o meno di una posta, di un obiettivo. Non solo spinge la storia in maniera molto più netta, ma anche in maniera più chiara e giusta. Se il guerriero tira per fermare gli orchi con una prova di forza per far cadere i barili, e vince, gli orchi vengono fermati. Chiaro e semplice. Lo ha deciso la fortuna, non una persona.

La Conflict, quindi, è più chiara e imparziale della Task. A volte, è anche l'unico modo di gestire una prova. Pensate ad una prova di "ammaliare" per convincere la bella barista a farci uno sconto. Anche nel più classico dei giochi, nessun GM la gestirebbe come una Task, anche perché è proprio difficile pensare a Task in un contesto simile. Persino il famoso Tiro per Colpire di D&D è un Conflict. La prova non regola se muoviamo o meno la spada, ma se colpiamo il nemico. L'obiettivo è colpire il bersaglio.

Prima di passare oltre, vorrei soffermarmi sul fatto che anche il "come lo fai" è importante, persino e specialmente in un sistema a Conflict. Riprendiamo l'esempio degli orchi che corrono contro il povero guerriero. Il guerriero ha diversi modi per fermare gli orchi. Potrebbe lanciare loro i barili, e sarebbe un'azione basata sulla forza (molti giochi chiederebbero una prova di forza o su un'abilità simile, altri permetterebbero di mettere in gioco tratti come "muscoli possenti" o simili). Potrebbe spaventarli in qualche modo, o corromperli, o convincerli, e sarebbe sicuramente un'azione sociale. Se al posto del Guerriero ci fosse un Mago, potrebbe fare una magia per bloccare gli orchi.
Sapere "come lo fai" è importante perché, a ben vedere, spinge la storia e mostra i PG che fanno cose, mostrandoci la loro natura. 

Mi spiace, non succede nulla!
Abbiamo detto che la Conflict Resolution è migliore della Task se si vuole dare importanza alla storia e se si vuole rendere davvero imparziali gli esiti delle prove (almeno, io la penso così). Probabilmente qualcuno non sarà d'accordo con me, nel caso lo invito a commentare in maniera pacifica e argomentata, in modo da far nascere una discussione interessante. Comunque, diamo la cosa per assodata e andiamo avanti. 

Avete presente quando in seguito ad una prova, solitamente con un fallimento, la risposta che otteniamo è "non ci riesci?". In gioco non succede nulla e il ritmo cala o, nei peggiori dei casi, si interrompe, si impalla. Immaginate la situazione in cui un personaggio debba salire sul tetto di una casa per affrontare un avversario che lo aspetta proprio lassù. Il giocatore tira e... fallisce! Risultato: non riesce a salire sul tetto. Aaaargh! Tremendo, il gioco entra in stallo. Certo, il giocatore potrebbe riprovarci nuovamente, più e più volte, finché non ci riesce, ma in quel caso sarebbe noioso e bruttissimo da vedere. Immaginate di leggere un libro in cui il protagonista prova per mezz'ora ad arrampicarsi su un tetto. Quel libro finirebbe nel camino in 0,1 secondi. 
I casi in cui una prova potrebbe comportare un nulla di fatto sono tanti, molti di più di quanto si crede. Cerchi degli indizi su un cadavere? Se fallisci non trovi nulla e quindi non succede NULLA. Immaginate, addirittura, se persino con un successo non si trovasse nulla. Che noia!

Più su ho detto che spesso è il fallimento a significare un nulla di fatto. A volte, però, specialmente se il sistema utilizzato è la Task (focus sull'azione), anche un successo può risolversi nel nulla. Con la Conflict è più difficile, perché si tira per raggiungere un obiettivo. Se la prova è un successo, l'obiettivo è raggiunto e qualcosa succede. Però alcuni obiettivi potrebbero essere così futili da significare un nulla di fatto anche in caso di successo. In caso di fallimento, invece, sia con Task che con Conflict, il gioco potrebbe fermarsi o rompersi. 

Ma come ovviare al problema?
A ben pensarci, esistono diversi accorgimenti, molti dei quali possono fondersi tra loro o essere utilizzati in maniera più o meno marcata.

Solo se è interessante
Il modo più semplice per ovviare al problema è inserire la regola per cui si tira solo quando tirare è interessante, ossia, sia che si fallisca o che si riesca, accade qualcosa che spinge la storia in avanti. Azioni come parlare in una lingua straniera che si conosce poco, oppure salire sul tetto per il solo scopo di salirci, non richiederebbero nessun tiro, proprio perché il fallimento sarebbe noioso. In alcuni casi, ma questo solo con il focus sull'azione, persino riuscire sarebbe noioso. Tirare per salvare la principessa che sta morendo tra le proprie braccia invece è interessante. Se si riesce, la principessa è salva. In caso contrario, muore.
Un gioco che utilizza questo metodo è Avventure in Prima Serata, ma anche Marvel Heroic RPG, di cui ho parlato nel precedente articolo.  

13th Age è un d20 system molto riuscito dove i
fallimenti sono gestiti con il sistema del Fail
Forward. 

Fail forward
Un altro modo di ovviare al problema è far accadere qualcosa quando il risultato è un fallimento. Con questo metodo il fallimento non significa non riuscire nell'azione o non ottenere l'obiettivo, o almeno non sempre, ma significa anche che accade qualcosa che complica il tutto. Immaginate un ladro che sta cercando di scassinare un baule contenente chissà quali tesori. Fallisce nell'impresa, ma dato che seguiamo la regola del fail forward, il risultato non è un noioso "non succede nulla". Che ne dite se attiva una trappola per sbaglio? Oppure se, per pura sfortuna, viene beccato con le mani nel sacco? Potrebbe addirittura succedere qualcosa di interessante scollegato dall'azione, dipende tutto da come si vuole gestire la cosa a livello di design.
Un gioco che utilizza questo metodo è Apocalypse World, ma anche 13th Age.

C'è un articolo molto interessante sul blog di Francesco Felici che parla proprio del fallimento e del fail forward.

Controposta
Un terzo modo è quello di inserire una controposta, ossia un obiettivo contrario a quello del giocatore, che si avvererà in caso di fallimento. Per esempio, se il giocatore descrive il suo personaggio che si intrufola di nascosto nella residenza di un ricco signore, e la posta è non essere scoperti, la controposta potrebbe essere: "vieni scoperto".
Un gioco che utilizza questo metodo è Burning Wheel.

L'opposizione
Un quarto modo ancora è quello di richiedere un tiro solo quando qualcuno o qualcosa si oppone attivamente (o persino passivamente) all'azione del giocatore, o quando il giocatore si oppone all'azione di qualcun'altro. In quel caso, cosa succede con un fallimento è solitamente molto chiaro. Se un PG cerca di colpire un orco PNG, e quell'orco sta alzando lo scudo per pararsi, c'è un'opposizione, e quindi in teoria anche una prova.

Più metodi in uno
Come ho accennato più su, molti giochi utilizzano due o più dei metodi prima elencati fondendoli assieme, e lo fanno con intensità variabili. Faccio un esempio che dovrebbe chiarire questo punto. Apocalypse World!
In Apocalypse World si tira solo quando è interessante farlo. Cosa è interessante non viene deciso arbitrariamente, ma è prescritto da delle mosse. Quando un giocatore attiva una mossa, ossia quando il suo personaggio fa qualcosa che vale come l'attivazione di una mossa, allora quel giocatore solitamente deve tirare i dadi (solitamente, perché alcune mosse si risolvono senza nessun tiro). Gli attivatori delle mosse sono azioni importanti per il tema del gioco, quindi azioni interessanti per il conseguimento dell'obiettivo del gioco.
Ma Apocalypse World, e lo abbiamo già detto, ha anche un metodo fail forward. Quando si fallisce, il GM (chiamato Maestro di Cerimonia, o MC) può e deve fare una e una sola mossa. Le mosse del GM sono elencate e sono cose tipo: "annuncia cose brutte", "infliggi danno", "attiva i lati negativi delle cose". Mettendo in gioco una di queste mosse, declinandola in modo che abbia senso in gioco (in fiction), il GM spinge la storia verso direzioni impreviste e interessanti. Non è detto che il PG non ottenga quello che voleva, d'altronde si tratta di un fallimento in termini, non di fatto, ma la mossa ci vuole comunque. In questo modo il ritmo è incalzante e il gioco procede con estrema fluidità.

Quello di Apocalypse World è solo un esempio. Ne potrei fare a miliardi, ma perderei tempo e occuperei spazio, specialmente se consideriamo l'esistenza di giochi che non utilizzano nessun sistema aleatorio per gestire le prove, o giochi che nemmeno gestiscono le prove, e credo proprio che se continuassi a scrivere ancora qualche riga nessuno di voi troverebbe il coraggio di leggere questo articolo.
Quindi per ora vi saluto, sperando che l'argomento e la trattazione siano stati interessanti. 

13 commenti:

  1. Notare come questi metodi - soprattutto il primo - possono essere applicati anche alla Task Resolution.

    RispondiElimina
    Risposte
    1. Certamente, e immagino pure che lo si faccia, ma in quel caso ci si porterebbero ancora dietro i problemi della task.

      Elimina
  2. Trovo che la Task Resolution si possa far convergere, volendo, verso la Conflict. Mi immagino una partita di D&D, gli orchi, i barili. Il giocatore che dice che vuol far cadere i barili e -importantissimo- il master che lo informa delle possibili conseguenze. "Si troveranno i barili in mezzo, dovranno fare una prova di saltare, ma anche se ci riuscirai non sarà sufficiente da solo a fermarli.". Si parla, si ragiona. Si discute sulla possibilità di far cadere loro i barili addosso, invece che in mezzo. La difficoltà del tiro sale, si preannuncia quanto danno potrebbero fare i barili rovinando loro addosso.
    Il giocatore informato può decidere se le conseguenze della prova valgano o meno il tempo speso a rovesciare quei barili. E' diventata Conflict Resolution: se riesco farò questo danno (come un attacco), se riesco introdurrò questo ostacolo sul loro percorso.

    Se invece il master dicesse "tu tira, poi decido io"... sono nelle sue mani. Meglio che sguaino e carico, va'.

    RispondiElimina
    Risposte
    1. Come ho anche scritto nell'articolo, in D&D alcuni tiri vengono già gestiti come Conflict. Gran parte di quelli sociali vengono bene solo se sono Conflict.

      A pensarci, qualsiasi sistema a task può essere convertito in Conflict. Alcuni però richiedono un po' di fatica.

      Elimina
    2. Richiedono fatica e consapevolezza. Da qui l'innegabile fatto che viene ripetuto da anni: il peggiore dei sistemi, nelle mani di un "bravo DM", funziona.

      Elimina
    3. Bravi giocatori farebbero funzionare qualsiasi cosa.
      Purtroppo, i Bravi DM non vengono venduti insieme al gioco!

      Elimina
  3. Perchè il problema è sempre quello di un'impostazione simulativa vs una narrativa. Molti continuano a giocare non "per creare storie" ma per "affrontare l'avventura, il dungeon, la missione" della serata. In questo approccio sono le azione fisiche, e dunque le Task, ad avere importanza, non gli intenti dei personaggi in quanto tali.

    RispondiElimina
    Risposte
    1. Io credo che anche in quel contesto la Conflict funzionerebbe meglio rispetto alla Task. Mi pare di aver dimostrato che in alcuni contesti la Task si presta al giudizio personale, lasciando da parte l'imparzialità del risultato aleatorio.

      Inoltre, anche se l'obiettivo non è la storia, il fatto che certi tiri comportino un nulla di fatto è un problema, perché blocca comunque il gioco. Il cercare di impedire il whiff factor è importante anche quando si vuole solo un buzzurrissimo (e dignitosissimo) Dungeon Crawling.

      Elimina
    2. la Task si presta pressoché SEMPRE al giudizio personale... :) Però io la trovo più corretta in gioco per due motivi:
      1) per me, i personaggi fanno le cose. mi aspetto che il mio eroe abbia caratteristiche come Forza, Agilità, Manualità ecc ecc... Se metto alla prova le caratteristiche del pg (che è quello che mi piace fare), metto alla prova la sua forza, la sua agilità, la sua manualità, non il suo apporto narrativo alla vicenda, il suo ruolo, i ricordi della sua infanzia ecc ecc... Il mio pg tira per sfondare a spallate una porta. E' quello che fa, perché esercita la sua Forza. Quanto sia "difficile da sfondare una porta", chi ci sia dietro, quante persone possano udirlo sfondare non dipendono piu dal pg ma dal Master o dall'avventura preparata, in una impostazione classica che mi sento ancora di tenere su e reiterare. Non riuscirei a credere in un pg che gioca a livello metanarrativo. A volte, gli eroi girano a vuoto, perdono tempo, falliscono bruttamente o compiono azioni sbagliate. Ci può stare. Ci deve stare.
      Sono però d'accordo nell'usare dosandolo il fail forward e accumulare le cavolate dei giocatori tutte alla fine (della sessione) o poco dopo...

      Elimina
    3. Risposta breve: Io credo che, a rigor di logica, se il guerriero riesce a far cadere i barili, gli orchi dovrebbero quanto meno tenare un tiro acrobazia per saltarli.
      Risposta lunga: per dimostrare una determinata tesi, ogni tanto bisogna tirar fuori un master cattivo che trasforma un successo del personaggio in un nulla di fatto.
      "A questo punto, la persona che narra l'esito dell'azione, tipicamente il GM ma non è detto, potrebbe descrivere che si, i barili cadono, ma gli orchi saltano i barili, trasformando in insuccesso il successo del guerriero, tutto a discreto arbitrio del narratore." Questo non è MAI successo nei miei gruppi di gioco. Ogni azione produce una reazione, contestuale alla situazione. Del tipo: il guerriero cerca di tirar giù i barili: se riesce, gli orchi devono fare tiro Acrobazia per schivarli, come sopra. Se NON riesce, una risposta possibile (la risposta "standard", oserei dire) è:
      - "Non riesci a ostacolarli, ti raggiungono. Fai un tiro Iniziativa" e poi inizia il combattimento.
      In ogni caso, è scorretto dire "non è successo nulla".

      Elimina
    4. @Marco: non vorrei che passasse l'idea che il fail forward sia un metodo per punire i giocatori che fanno cazzate, perché non lo è. è uno strumento molto bello per far accadere qualcosa di interessante, tant'è che sia in 13th Age che in AW è possibile che il PG riesca nell'azione anche se il GM aggiunge una complicazione.

      Capisco anche il discorso che fai prima. C'è un interessante tesi di Claudio Freda che ti consiglio di leggere: http://www.raminghi.it/discussion/700/giocare-attraverso-gli-occhi-dei-personaggi-il-patto-diegetico/p1

      In questo caso, però, Marco, potresti fare a meno di qualsiasi regolamento e lasciarti semplicemente guidare dal GM. Ma siccome io voglio un regolamento che funzioni, non posso non riconoscere i limiti della task. A me non va che decida il GM, voglio avere voce in capitolo sulla storia.

      @Cristian: il fatto che tu non abbia MAI visto succedere uno scenario simile non significa che possa succedere. Infatti io ho detto che è possibile, non ho detto che è obbligatorio, non mettermi in bocca cose che non ho detto. :)

      E in ogni caso, dato che la prova è una Task, il Guerriero tira per far cadere i barili, NON per fermare gli orchi, o vuoi negarlo?
      Poi gli orchi magari tireranno per saltare i barili, ma la CD è da decidere e non è nemmeno detto che succeda.

      Elimina
    5. Cristian: Mi sono dimenticato una cosa. Non ho detto che in quel caso, con un fallimento, non succede nulla. Ho detto che con una task non succede nulla. L'azione è per far cadere i barili, non per fermare gli orchi. Se fallisci, i barili non cadono = non succede nulla.
      Se il tiro fosse per fermare gli orchi, allora si, in caso di fallimento gli orchi ti raggiungono, qualcosa succede.

      Spero che questo sia ben chiaro.

      Elimina
  4. Se la Conflict Resolution è più chiara, la Task Resolution è più intuitiva: è più facile dire quello che vuoi fare che non quello che vuoi ottenere. Il personaggio è inseguito dagli orchi, vede una pila di casse, il giocatore decide di farla cadere: qual'è il suo scopo? Fermarli? E non è mica detto: potrebbe voler far loro danno, crearsi un vantaggio per poterli affrontare, attirare l'attenzione di qualcuno... Se si usa la Conflict Resolution, bisogna estrapolare dall'azione, interromperla, spezzarla per capire qual'è l'obbiettivo del giocatore. E la prossima volta si ricomincia perché il giocatore dirà di nuovo quello che farà il personaggio, non quello che vuole ottenere.
    Altre volte ti ritrovare che una serie di Task saranno molto utili, rispetto ad una semplice Conflict: devi preparare le difese prima che arrivino i nemici. Con la Conflict hai un "ci riesci", "non ci riesci" oppure un risultato parziale, ma ben poco sul come: se invece hai, che so, tre task: rafforzare le difese, preparare le trappole, dare l'allarme in tempo, ecco che sai non solo se ci riesce o meno, ma anche in cosa, come e quando! Un discorso analogo può essere fatto anche per quelle serie di azioni che portano ad un risultato: per giungere in tempo in città, devi attraversare Bosco Fosco; non devi perderti, non devi incontrare nemici, devi avere sufficiente cibo per affrontare la traversata senza attardarti a far "rifornimento" (sì, è il viaggio pericoloso di Dungeon World). Eppure tutte e tre sono Task perché l'obbiettivo non è nessuno dei tre...
    Infine un caso limite: una stanza con tre porte aperte ed una chiusa a chiave. Il personaggio vuole aprire la porta chiusa a chiave. Qual'è il suo obbiettivo? Solo riuscire nel compito, visto che non ha la minima idea di cosa vi sia dall'altra parte...
    Con questo voglio dire che la Task è meglio della Conflict. No. Solo che in realtà la divisione non è così netta: a) spesso le migliori Conflict si servono delle Task; b) le Task non spezzano l'azione, quindi una o più Task creano una Conflict.

    Sul resto sono d'accordo (il Fail Forward è una cosa che ho sempre usato, senza mai sapere che si chiamasse così). Il "non è successo niente, riprova" l'ho sempre considerato noioso. Tuttavia a volte è proprio quello che possa sembrare in apparenza: passaggio del tempo, allarmi silenziosi od altro possono far sembrare un fallimento senza conseguenze, mentre quelle conseguenze si vedranno più avanti.

    Ciao :)

    RispondiElimina