Progetta Le Tue Avventure #1: Tutto é Storia
Progetta Le Tue Avventure #2: I Primi Passi
Progetta Le Tue Avventure #3: Ferrorie e Scatole di Sabbia
Progetta Le Tue Avventure #4: Si Va in Campagna
Progetta Le Tue Avventure #5: Tessitura di una Campagna - Teoria
Progetta Le Tue Avventure #6: Tessitura di una Campagna - Pratica
Progetta Le Tue Avventure #7: Va In Scena La Sfida
Progetta Le Tue Avventure #8: Fallire Senza Morire

Tra le molte lacune di questa mia serie sulla creazione di avventure ce n’è una a cui non avevo fatto caso, e che di recente mi è balzata agli occhi grazie a una discussione sull’ottimo gruppo Telegram DungeonsAndDragonsITA.

Abbiamo visto che un’avventura è fatta di incontri, alcuni dei quali sono sfide (ricordatevi che c’è il Glossario per questi termini). E abbiamo visto come si progetta un’avventura nel complesso (qui) e come si progetta una singola sfida (qui). Ma come si mettono insieme le due cose? Qual è il modo migliore di “assemblare” gli incontri dentro un’avventura?

Programmazione con la condizionale

Non so se qualcuno di voi conosce la programmazione (intendo, un linguaggio di programmazione per computer). Tranquilli, non è necessaria per capire questo articolo, quindi se non avete 2 ore di tempo per imparare Python o 2+ mesi per imparare qualunque altro linguaggio fa lo stesso.

Detto brutalmente, la programmazione consiste nello spiegare a una macchina molto veloce ma molto stupida (il computer) cosa deve fare. Nella sua forma più semplice (lasciando stare algoritmi d’avanguardia, reti neurali eccetera) la spiegazione consisterà in una sequenza di istruzioni:

Se però le istruzioni si potessero disporre solo in sequenza la macchina farebbe sempre la stessa serie di cose, giusto? Non potremmo aggiungere alcuna logica o complessità al nostro programma.

Bene, uno degli strumenti più semplici e più potenti (al tempo stesso!) a disposizione di un programmatore è una diramazione condizionale: un if, si direbbe in gergo. La possibilità di dire al computer: se si verifica questa condizione, allora fai questo, altrimenti fai quest’altro.

Basta combinare diversi if e subito, dalla semplice sequenza, si può passare a programmi estremamente complessi.

Strutture di avventura

Tutto questo discorso non serve solo a giustificare il titolo dell’articolo: in effetti, la struttura di un’avventura si può raffigurare con un diagramma di flusso vagamente simile a questi.

E i vari if potrebbero rappresentare una parte dell’agency dei giocatori, vale a dire la loro possibilità di scegliere un percorso piuttosto che un altro verso l’obiettivo dell’avventura.

Nota doverosa

Qui si parla di progettazione delle avventure, non della loro conduzione durante il gioco (di quella, invece, parlerò in quest’altra serie nuovissima).
Sappiamo dai precedenti episodi che, qualunque stile di gioco si scelga, è compito del DM progettare gli ostacoli che si frappongono tra i PG e i loro obiettivi, in modo da rendere avventurosa la storia. Sappiamo anche che, qualunque cosa un Diemme progetti, deve lasciare ai giocatori libertà decisionale ed essere aperto all’imprevisto.
Nel seguito, quando parlerò di progettare incontri e “disporli” in un certo modo, non intendo dire che dobbiamo progettare cosa faranno i PG, né tantomeno che dobbiamo “costringerli” a tornare sul percorso “previsto” se per caso se ne discostassero.
Quello che intendo è che progetteremo una situazione, cioè la configurazione degli ostacoli tra i PG e l’obiettivo, e che questa situazione comprenderà di fatto un qualche ordine (perché fare A è oggettivamente necessario per poter fare B, e così via).

Avventure sequenziali

La struttura più semplice che ci può venire in mente, data un’avventura composta da certi incontri, è disporre banalmente gli incontri in sequenza, in questo modo:

Questa struttura indica che gli incontri sono obbligati: i PG devono per forza superare il primo prima di poter fronteggiare il secondo, e così via; finché non avranno superato tutti gli incontri nella sequenza prevista non potranno giungere all’obiettivo.

Si tratta di una struttura lecita, specie per Diemme principianti. Se state pensando “non c’è agency” (sento già qualcuno in sottofondo che grida: railroad!) vi sbagliate, perché ci potrebbe essere (in effetti ci dovrebbe essere) l’agency interna a ciascun incontro. In particolare, per ciascuna sfida, i giocatori dovrebbero essere liberi di decidere con quale approccio affrontarla: se c’è un minotauro a guardia di un passaggio potrebbero ucciderlo, certo, ma anche corromperlo, distrarlo, metterlo sotto charme o sgattaiolare alla chetichella senza farsi vedere. E i diversi approcci potrebbero avere diverse conseguenze di lungo termine, anche senza incidere sull’obiettivo dell’avventura.

Ma in generale siamo d’accordo che si può fare di meglio rispetto a una cosa super-semplice come questa.

Avventure ramificate

Per aggiungere complessità alla nostra struttura possiamo far sì che alcuni incontri non siano obbligati. Un’obiezione che spesso mi viene fatta è: “Ma questo è allungare il brodo! Se un incontro non porta avanti la storia, a che serve?” (la gente non è mai contenta). In realtà chi fa questa obiezione ha in mente questo tipo di struttura:

Questa è in effetti una struttura non molto buona, in generale. Ma può avere il suo perché, in certe situazioni. Per esempio, l’incontro inutile può essere un diversivo divertente per far sfogare un po’ i giocatori; che so, con un bel combattimento di intermezzo tra tanti lunghi dialoghi.

Ovviamente esistono anche incontri inutili che non sono previsti ma sono frutto di un errore o del caso: un mostro errante, o i PG che scatenano di loro iniziativa una rissa in taverna. Quelli, però, non fanno parte del diagramma perché non vengono progettati, emergono lì per li.

Una struttura ramificata migliore è quella in cui i “rami secondari” portano a conseguire obiettivi secondari, cioè qualcosa di utile, anziché non portare a niente:

Esempi di obiettivo secondario possono essere:

• guadagnare del tesoro aggiuntivo;
• trovare delle risorse (pozioni, informazioni, alleati…) che rendano gli incontri obbligati più agevoli;
• modificare il mondo di gioco in qualche modo, con ripercussioni a lungo termine (es. ottenere la gratitudine di un potente, o far crollare un passaggio per impedire ad altri di utilizzarlo in futuro);
• conseguire uno scopo individuale di qualche PG (ad esempio, salvare un innocente in pericolo, anche se l’obiettivo principale non ne viene impattato, potrebbe essere un degno successo per un PG buono ed eroico).

Un altro modo di rendere interessante uno schema ramificato è prevedere più percorsi alternativi per arrivare all’obiettivo principale:

Scegliere uno tra due incontri tende a dare ai giocatori una sensazione di agency superiore rispetto a scegliere una tra le varie modalità di affrontare uno stesso incontro; questo, ovviamente, a patto che la scelta tra i due incontri sia consapevole e non casuale (altrimenti non c’è agency).

A questo punto è facile aumentare la complessità a piacimento:

Ricordate, però, che una maggiore complessità non garantisce maggiore divertimento. I giocatori apprezzeranno di più poter compiere poche scelte importanti e dense di pathos, piuttosto che tantissime piccole scelte in cui si sentono poco coinvolti.

Diagrammi e dungeon: un disclaimer

L’ultimo diagramma di flusso sembra quasi un dungeon, vero? Se pensiamo agli incontri come stanze e alle frecce come corridoi otteniamo in apparenza una bella mappa. C’è del vero in questo parallelismo: un dungeon è un’ottima base di partenza per un diagramma di flusso, e qualunque avventura può essere vista come un “dungeon generalizzato” dove si parla di luoghi e situazioni anziché di stanze vere e proprie.

Detto ciò, è importante non confondere il diagramma che ho presentato qui con la mappa del nostro dungeon, perché potrebbero essere molto diversi. Nel diagramma, si ha una freccia dal blocco A al blocco B se è necessario superare l’incontro A prima di poter superare l’incontro B. Questo non corrisponde per forza all’avere un corridoio tra la stanza A e la stanza B del dungeon.

Ad esempio, ecco un pezzo di dungeon con 6 stanze (la F è dietro un passaggio segreto). Le vie di accesso, tutte per la stanza A, sono indicate dalle frecce rosse, l’uscita dalla freccia viola.

Saremmo tentati di schematizzarlo così:

Ma non è affatto detto che sia lo schema giusto. Supponiamo, ad esempio, che nella stanza E un mostro guardiamo protegga una chiave necessaria per sbloccare la porta che dalla B conduce alla D. A quel punto E diventa un incontro obbligato! Lo schema corretto sarebbe:

ad indicare che sia B, che C, che E sono obbligatori per poter affrontare D; B non è obbligatorio per affrontare C ed E, né viceversa, ma C è obbligatorio per poter affrontare E.

E se invece la chiave in E non fosse l’unico modo per aprire la porta tra B e D, ma permettesse semplicemente di farlo senza far scattare una trappola? Allora sarebbe corretto lo schema precedente, con C ed E non obbligatori che porterebbero ad un obiettivo secondario (una risorsa per rendere più facile un altro passaggio).

Spazio e tempo non c’entrano: un altro disclaimer

I diagrammi di questo articolo non rappresentano una sequenza spaziale o temporale di avvenimenti. In effetti, se si volesse rappresentare in un grafico gli eventi come effettivamente avvengono nel gioco ne risulterebbe sempre un grafico sequenziale, perché li si gioca uno dopo l’altro (salvo eccezioni come gruppi che si dividono e affrontano cose diverse in contemporanea).

Ogni blocco non rappresenta un luogo, un nemico o un PNG, rappresenta invece una singola “scena” interattiva con un esito; se in tre momenti diversi dell’avventura posso andare dallo stesso PNG a fare cose diverse, queste tre cose saranno tre blocchi separati del diagramma.

E ogni freccia rappresenta il fatto che superare un certo incontro è un requisito per poterne affrontare un altro. Non si parla di un ordine arbitrario con cui il Diemme ha previsto che le cose avvengano! Se metto una freccia da A a B, deve essere perché c’è una ragione oggettiva e sensata, nel mondo di gioco, per cui A debba essere superato per poter passare a B.

Conclusione

Abbiamo visto che ci sono vari modi per “assemblare” gli incontri fino a formare un’avventura. Abbiamo anche visto come sia importante distinguere ciò che è indispensabile per raggiungere l’obiettivo finale e ciò che è opzionale, e come inquadrare gli incontri opzionali in modo da renderli comunque interessanti.

Nel prossimo episodio vedremo un utile esempio.

Per approfondire:

Su La Locanda del GdR mi hanno consigliato questo post ad opera di Ron Gilbert. Non lo conoscevo ma è un brillante esempio di convergenza evolutiva: il suo dependecy chart è esattamente lo stesso concetto (spiegato meglio) dei diagrammi che ho presentato qui. Consigliatissimo!