L’arte del playtest – Parte 2

di Walter “Plautus” Nuccio

Nella prima parte di questo articolo eravamo partiti da una premessa: affrontare l’argomento “playtest” con un approccio un po’ più scientifico e un po’ meno artistico. C’eravamo quindi lasciati con un interrogativo: qual è la vera missione di un playtester, ovvero cosa può aspettarsi l’autore dalle persone cui sottopone un suo prototipo? La risposta che avevamo dato è che, al pari di quanto accade per i tester di un software, il ruolo dei playtester di un gioco da tavolo dovrebbe essere principalmente quello di evidenziare i difetti e le criticità che emergono durante la partita. Per illustrare meglio questo aspetto, immaginiamoci per un momento catapultati nel bel mezzo di una sessione di testing…

Una “tipica” sessione di playtest
L’autore e i suoi prodi collaboratori sono seduti allegramente attorno al tavolo, immersi nella prova di un nuovo prototipo. A un certo punto della partita, uno dei giocatori nota che ciascuno sta giocando per conto proprio, senza minimamente badare agli altri. Ecco quindi che si sente in dovere di intervenire con un suggerimento del tipo “qui sarebbe bello poter attaccare un avversario! Perché non facciamo in modo che io possa tirare un dado e, se ottengo più di te, ti rubo una carta?”. A questo punto il gioco si ferma e tutti prendono a considerare questa possibilità, con le implicazioni che comporta. Magari l’autore si convince che è una buona idea, torna a casa, ci lavora, e torna la volta dopo, con la nuova meccanica aggiunta ma anche con … il suo carico di nuovi problemi da correggere.

Cosa è accaduto in realtà? Che non è stato messo in luce il vero problema del gioco, e si è saltati immediatamente ad una soluzione, alla prima che è venuta in mente, per caso, ad uno dei tester. Quale era il vero problema del gioco? La mancanza di interazione, ovviamente. Invece di sottolineare questo aspetto è stata invece proposta immediatamente una modifica, probabilmente banale (l’attacco diretto tra giocatori è la prima cosa cui pensa un qualsiasi giocatore o designer alle prime armi), con le seguenti conseguenze:

1. la modifica proposta non ha necessariamente risolto il problema originario. Ciò dipende, in realtà, da tanti fattori, ad esempio: i giocatori sono davvero motivati ad attaccarsi l’un l’altro? E’ conveniente attaccare un avversario o è strategicamente preferibile starsene per conto proprio?
2. La modifica proposta non è in alcun modo coerente con lo spirito e l’atmosfera che l’autore vuole infondere nel gioco.
3. Non sono state nemmeno prese in considerazione altre possibili soluzioni.
4. La quantità di regole è aumentata: il gioco ora ha nuove regole che i giocatori dovranno imparare.
5. La meccanica aggiunta ha introdotto nuovi potenziali problemi nel sistema di gioco.

Esaminiamo questi punti uno alla volta:

1. A volte una nuova meccanica, o una nuova regola, sposta il focus del gioco nascondendo i vecchi problemi senza risolverli davvero. Ciò accade quando non si ha ben chiaro il problema che si vuole risolvere, e si procede per tentativi, inserendo nuove regole un po’ a caso per vedere cosa accade.
2. L’autore di un gioco ha in mente, per i giocatori, un certo tipo di esperienza. Se, ad esempio, non desidera inserire nel gioco una componente di “guerra” o di attacco diretto, tutte i suggerimenti che vanno in questa direzione saranno semplicemente fiato sprecato. E’ del tutto inutile, quindi, proporre all’autore del gioco di inserire nuovi elementi o meccaniche che, per una precisa scelta di design, sono state già escluse fin dal principio dall’idea di gioco.
3. Il design è un’attività creativa, e creatività implica libertà di scelta. Concentrarsi subito sulla prima soluzione che passa per la testa esclude da subito tutta una serie di possibilità alternative, magari meno ovvie e istintive ma potenzialmente più interessanti. Nell’esempio che abbiamo descritto vi sarebbero probabilmente molti altri modi di aumentare il grado di interazione nel gioco, senza necessariamente ricorrere all’attacco diretto.
4. Quando lo stesso prototipo viene proposto più volte di seguito allo stesso gruppo di tester, è facile per queste persone assorbire nuove regole di volta in volta, perché l’apprendimento avviene in modo graduale. Il rischio, però, è quello di trovarsi con un gigantesco polpettone, un pasticcio di regole che rivelerà tutta la sua pesantezza la prima volta che si renderà necessario spiegarlo ad un gruppo nuovo. Meglio quindi evitare di aggiungere nuove meccaniche (cosa a cui i playtester in erba sono molto propensi) senza aver prima messo a punto quelle già presenti.
5. Quando si aggiunge una nuova meccanica sulla spinta di un suggerimento, è facile che questa introduca nuovi problemi nel gioco. Questo perché i playtester tipicamente non sono pienamente coscienti (e come potrebbero esserlo?) delle relazioni che esistono tra le varie meccaniche e degli impatti che ciascuna aggiunta o modifica può avere sul resto del sistema. Per correggere i nuovi problemi emersi, qualcuno suggerirà probabilmente di aggiungere nuove regole, e così via, in una spirale senza fine…

Morale della favola: analizzare prima di risolvere
Qual è l’approccio giusto da usare, quindi? Non ho la presunzione di fornire una risposta definitiva, ma penso che sia utile riflettere sul seguente principio: “playtest vuol dire individuare problemi, con la maggiore accuratezza possibile, non necessariamente proporre soluzioni”.

Knizia una volta ha dichiarato che preferisce ragionare non su un singolo problema di design alla volta, ma su due problemi contemporaneamente, in modo da trovare una soluzione unica per entrambi. Questo, oltre a far risparmiare tempo, porta spesso a meccaniche più eleganti. Personalmente trovo estremamente utile seguire l’esempio del grande Reiner, per cui al termine di una sessione di test procedo innanzitutto ad evidenziare ed elencare i problemi, senza saltare immediatamente alle soluzioni.

D’altra parte è doveroso  fare una precisazione: finora ho riportato solo esempi di playtest condotti con l’ausilio di semplici giocatori, nemmeno troppo esperti. Se al tavolo del vostro prototipo siedono altri autori o dei playtester che hanno già una buona esperienza, allora le cose stanno diversamente. Un autore, infatti, guarda ad un gioco con l’occhio del designer, cioè in modo differente da un giocatore; è maggiormente consapevole delle relazioni che legano le varie meccaniche di un sistema e delle motivazioni che stanno dietro certe scelte di design; egli, ben conscio che non avrà mai lo stesso livello di conoscenza approfondita che può possedere solo chi il gioco lo ha ideato in prima persona, sarà sicuramente più cauto nel proporre regole aggiuntive, dando invece maggior risalto all’individuazione dei punti deboli del sistema.

Un’ ultima riflessione vorrei rivolgerla, quindi, ai playtester, soprattutto se alle prime armi: se state provando un prototipo, focalizzatevi soprattutto sul tentativo di individuare esattamente i difetti del gioco, possibilmente analizzandone le cause. Non accontentatevi di un semplice “non è divertente”, ma cercate di capire il perché di questo giudizio, magari confrontando il gioco in esame con altri giochi simili. E se proprio non resistete alla tentazione di proporre una soluzione, esponetela pure, ma non cercate di convincere a tutti i costi l’autore della sua validità: lasciatelo libero di valutare e di scegliere con calma, successivamente, l’approccio da seguire.