Pattern di game design – La Corsa

di Walter “Plautus” Nuccio

Chi come me lavora nel campo dell’informatica avrà certamente sentito parlare di design pattern. Un design pattern è un’idea di progettazione, una sorta di schema o di procedimento concettuale, che viene impiegato con successo per la risoluzione di tipici problemi di progettazione. Per la sua dimostrata efficacia, un pattern è un’idea che è possibile ritrovare di frequente nei lavori dei progettisti più esperti.  La prima persona ad utilizzare intensivamente questo concetto è stata l’architetto Christopher Alexander, il quale notò che alcuni problemi ricorrenti in architettura potevano essere affrontati tramite delle soluzioni standard, ciascuna rappresentabile sottoforma di design pattern. Nel suo saggio A Pattern Language, Alexander descrive un catalogo di oltre 200 pattern, ciascuno dotato di un proprio nome e di una serie di caratteristiche. Successivamente questa idea è stata ripresa nel campo dello sviluppo software, dando vita ad una folta produzione di libri e pubblicazioni sull’argomento, il più celebre dei quali rimane Design Pattern: Elementi per il riuso di software ad oggetti  (Gamma, Helm, Johnson, Vlissides; Ed. Pearson).  Se questo strumento si è rivelato così utile, ho pensato, non c’è dubbio che possa esserlo altrettanto nel campo del game design. E’ da diverso tempo, quindi, che dedico molte energie a raccogliere, classificare e catalogare decine di pattern relativi ai giochi da tavolo. Per inaugurare il nuovo anno, oggi vi propongo il primo.

Corsa: la forma più antica di competizione

Chi di voi non ha mai giocato a “chi arriva prima in fondo al viale”? Probabilmente tutti ci siamo trovati almeno una volta a gareggiare in una situazione simile, e l’occhio attento del designer può ben riconoscere come quest’idea sia stata ripresa in molti giochi, antichi e moderni: è questo il primo passo per l’individuazione di un potenziale design pattern. Ma perché il pattern prenda forma occorre arricchirlo di dettagli e considerazioni, affinché possa diventare uno strumento effettivamente utile. La prima cosa da fare è quella di dargli un nome significativo, che comunichi nel modo più sintetico ed efficace possibile l’idea che è alla sua base. In questo caso il nome più naturale sembra essere Corsa. Ora proviamo a vedere in quante varianti e declinazioni diverse si manifesta questo pattern. Il classico gioco dell’Oca riprende quest’idea in modo molto fedele: il vincitore è il primo giocatore che arriva col proprio segnalino al termine di un percorso. Ma sorprendentemente anche I coloni di Catan, un gioco moderno, riprende un’idea simile, benché non si tratti di un gioco di percorso: il vincitore, in questo caso, è il primo giocatore che totalizza 10 punti vittoria. In questi due esempi il pattern è stato utilizzato per definire un criterio di vittoria, ma ad un’analisi più approfondita scopriamo che le sue potenzialità non finiscono qui: esso può essere impiegato anche in relazione a degli obiettivi intermedi, dei traguardi che il giocatore raggiunge nel corso della partita e non soltanto nel finale.  Naturalmente in questo caso il giocatore che “arriva primo” non otterrà la vittoria ma soltanto un premio o un compenso di qualche altra natura. thurnPensiamo, per esempio, a Thurn and Taxis:  in questo gioco i partecipanti creano dei percorsi di collegamento tra le città sul tabellone, occupandole con i propri uffici postali. Per aggiungere pepe al gioco l’autore ha pensato bene di associare un bonus a ciascuno degli obiettivi presenti nel gioco: quando un giocatore completa un percorso di lunghezza 5 o superiore ottiene una tesserina bonus con un certo valore in punti vittoria; lo stesso accade al giocatore che occupa un’intera regione con i propri uffici. Ma un momento: se tutti i giocatori che raggiungono questi obiettivi ottengono il bonus relativo, dov’è la Corsa in questo caso? Semplice: le tessere bonus associate a ciascuno degli obiettivi sono ordinate in una pila di valore decrescente, per cui il primo giocatore che consegue l’obiettivo ottiene la tessera di valore più alto, mentre gli altri devono accontentarsi delle rimanenti. In altri termini, qui l’arrivare “per primi” non è premiato con la vittoria ma semplicemente con una ricompensa in punti più alta.

Definizione e conseguenze

Tenendo presenti gli esempi fatti, proveremo ora a tirar fuori una definizione generale del pattern, che ne catturi lo spirito di fondo. Possiamo dire che una Corsa consiste nella assegnazione di un premio al giocatore che consegue per primo un determinato obiettivo. Questa definizione sembra abbastanza generale da includere tutti gli esempi finora riportati, fermo restando che il premio in questione è in alcuni casi un piccolo beneficio, mentre in altri coincide addirittura con la vittoria della partita.

Siamo a buon punto nella nostra analisi; tuttavia un nome, una definizione e un elenco di varianti non sarebbero sufficienti a descrivere esaustivamente un design pattern: occorre anche individuare quali sono le conseguenze che l’applicazione del pattern produce all’interno del sistema di gioco, conseguenze che, in generale, potrebbero anche non essere del tutto positive. Nel nostro caso le conseguenze principali sono due. La prima è che il pattern consente di inserire nel gioco una componente di interazione indiretta, che assume la forma di una competizione tra i giocatori: se è importante che io sia il primo a raggiungere quella determinata casella o a costruire quello specifico edificio, dovrò necessariamente tenere conto delle intenzioni dei miei avversari e tentare di anticiparli. Un’ulteriore conseguenza di ciò, quindi, è la tensione che si genera, ed è interessante notare che questa tensione è presente anche in assenza di interazione: nel Gioco dell’oca, dove le possibilità di controllo sul mio e sull’altrui gioco sono nulle, il semplice fatto che lo scopo del gioco sia arrivare per primi al traguardo aumenta la mia percezione degli altri giocatori al tavolo e mi spinge a confrontare continuamente le posizioni del mio e degli altri segnalini.

I pattern come strumento

Quali sono, quindi, i vantaggi che derivano dall’uso dei pattern? Proviamo a riassumerne qualcuno.

  1. I pattern migliorano la comunicazione: l’uso di un nome appropriato per un pattern consente ad un game designer di comunicare con altri addetti ai lavori in modo più efficace. Invece di dire “usiamo la meccanica delle tesserine bonus come in Thurn and Taxis” possiamo semplicemente dire “applichiamo una Corsa”; questo, peraltro, permette anche di focalizzarci di più sull’obiettivo di design che vogliamo raggiungere piuttosto che sul semplice riutilizzo di una meccanica nota.
  2. I pattern catturano l’esperienza: chi sono i nostri maestri se non i giochi di successo? Se determinati espedienti di design sono stati e continuano ad essere utilizzati da autori affermati è perché, evidentemente, funzionano. Diventare consapevoli di ciò è un passo importante per migliorare come game designer, e i pattern possono offrire un valido supporto in tal senso, “catturando e sintetizzando” l’esperienza di chi ci ha preceduto.
  3. I pattern offrono soluzioni ai problemi più comuni: il game design consiste per una larga parte nel risolvere problemi e malfunzionamenti delle meccaniche. Nel gioco c’è poca tensione? Oppure c’è scarsa interazione tra i giocatori? Perché, quindi, non provare ad aggiungere una Corsa? Questo è un piccolo esempio di come un pattern possa fornire uno spunto per la risoluzione dei problemi di design più ricorrenti.

augustus 3Reinterpretare i pattern

Prima di concludere è importante fare una precisazione: il fatto che un pattern rappresenti un concetto largamente utilizzato in molti giochi non deve far credere che utilizzarlo comporti necessariamente un sacrificio all’originalità. Al contrario, un designer esperto è in grado di reinterpretare un pattern largamente diffuso creandone nuove e interessanti varianti , come ha dimostrato di recente il nostro Paolo Mori in Augustus. In questo gioco sono presenti cinque ricompense di 2,4,6,8 e 10 punti vittoria, destinate al giocatore che per primo completa, rispettivamente, 2,3,4,5 e 6 tessere-obiettivi. Si tratta quindi di una Corsa a chi per primo completa un certo numero di obiettivi. Dov’è l’innovazione? E’ nel fatto che un giocatore può conseguire solo una di queste ricompense, e solo se il numero di obiettivi completato è esattamente uguale a quello richiesto. La dinamica che si genera, quindi, è la seguente: quando il giocatore completa, ad esempio, il secondo obiettivo, deve fare una scelta: prendere subito la ricompensa da 2 punti, rinunciando alle successive, oppure puntare a quella da 4 punti col rischio che, se un giocatore dovesse anticiparlo, perderebbe anche quella.

La breve panoramica sui pattern di game design si conclude qui. I pattern, purché accuratamente catalogati ed analizzati, vengono a costituire una sorta di ideale cassetta degli attrezzi per il game designer, che potrà farne l’uso  che preferisce: essi saranno perciò un semplice strumento di apprendimento, un supporto alla risoluzione di problemi o addirittura, per i designer più esperti, un mezzo di stimolazione della creatività.

Plautus

Walter (Plautus) Nuccio è un appassionato di giochi da tavolo e di game design, disciplina della quale ama indagare ed approfondire gli aspetti teorici. Ha partecipato al concorso Miglior Gioco Inedito Lucca Games 2011, arrivando in finale con Evolution.

15 pensieri riguardo “Pattern di game design – La Corsa

  • 2 Gennaio 2014 in 10:53
    Permalink

    Ho segnalato l’articolo sulla mia pagina fb, perchè mi pare molto interessante l’intento di catalogare una serie di pattern utilizzabili nella progettazione di un gioco da tavolo.

    Personalmente non concordo affatto con l’idea che un “race patern” sia sovrapponibile a un “reward pattern”, anche se le due cose sono spesso correlate fra di loro. In molti degli esempi citati, si stanno applicando, come minimo, due diversi pattern e non uno solo, ma questa è una considerazione molto “accademica”. L’articolo è molto interessante e attendo con interesse di leggere i prossimi.

    • 2 Gennaio 2014 in 13:43
      Permalink

      Grazie Spartaco mi fa molto piacere conoscere la tua opinione al riguardo. E non la trovo affatto accademica, anzi..
      Per il monmento vorrei comunque sottolineare come personalmente trovi del tutto usuale individuare, in una stessa meccanica di gioco, due o anche più pattern diversi, dato che un pattern può benissimo identificare un singolo aspetto elementare di una meccanica.

  • 2 Gennaio 2014 in 17:41
    Permalink

    Un gran bell’articolo. Un’altra funzione che vedo nei game design patterns è quella di permetterti di “identificare” immediatamente la regola e le sue implicazioni.
    A proposito del race sovrapponibile al reward, diciamo che estendendo il concetto possono essere assimilati a parer mio.

    • 2 Gennaio 2014 in 19:46
      Permalink

      Personalmente preferisco tenere distinti i due concetti per il seguente motivo:

      una reward è una ricompensa o un premio dato al giocatore, quando questi raggiunge un obiettivo; in generale più giocatori possono ottenere lo stesso premio;

      una Corsa, invece, corrisponde all’idea di “premiare soltanto il primo” (che raggiunge l’obiettivo) e quindi crea una dinamica diversa, più particolare e tesa. Direi che è un caso particolare, una variante del precedente, ma talmente ben caratterizzata da meritare, a mio avviso, una trattazione a sè stante, come pattern separato.

  • 7 Gennaio 2014 in 20:55
    Permalink

    Ottimo articolo! Grazie come sempre a tutto il team che lavora dietro a Gioconauta!

    Vi auguro un GRANDIOSO 2014

  • 9 Gennaio 2014 in 10:03
    Permalink

    Veramente un bell’articolo: originale, espresso con competenza. Personalmente, sono sempre attratto da tutto ciò che cerca di individuare le strutture di un’opera (un gioco, un libro, una sinfonia, un edificio) e trovo che questa chiave di lettura sia estremamente stimolante.
    Bravo!

    Aspetto il prossimo articolo, almeno tanto quanto un videotutorial di Alkyla!!! ;)

    • 9 Gennaio 2014 in 22:11
      Permalink

      Ti ringrazio molto, è davvero un piacere leggere di persone così interessate a questi temi :)

  • 21 Gennaio 2014 in 09:48
    Permalink

    Oltre alle dovute citazioni in campo architettonico e informatico mi sarei aspettato almeno la menzionedegli studi sui “Game Design Patterns” di Holopainen e Bjork, visto che alla fine quello che dici è più o meno un “riassunto velocissimo” di quello che hanno detto i due studiosi scandinavi in libri, articoli e conferenze. Non ho il libro sottomano ma mi pare che “race” sia uno dei pattern formalizzati da loro. Sai che io sono particolarmente pignolo sulle fonti…
    Comunque il discorso è interessante, a me interessa molto per il lato “chiamiamo le cose a seconda della funzione”, nonostante ovviamente lo scopo primario sia fornire un “tool” (in realtà più versatile di quel che può sembrare) ai designer.
    Comunque ti ringrazio molto dell’articolo, mi ha spinto ad approfondire concetti che avevo lasciato un po’ indietro (e mi ha fatto conoscere Alexander) e che invece potrebbero tornarmi utlissimi per progetti futuri!

    Per i curiosi: “The Case For Game Design Patterns” di Kreimeier! :)
    https://www.gamasutra.com/view/feature/4261/the_case_for_game_design_patterns.php

    Marco

    • 21 Gennaio 2014 in 15:01
      Permalink

      Mi sono reso conto che manca un “passaggio”: il mio commento non vuol essere una critica alla “mancanza di citazione” per i ricercatori scandinavi ma, semmai, un invito ad approfondire il discorso :)

      Per esempio, mi premerebbe sapere se si trova un elenco aggiornato dei pattern…

      • 21 Gennaio 2014 in 17:39
        Permalink

        Ciao Marco, sono io a ringraziare te per questa osservazione, che mi offre l’opportunità di esplicitare meglio i miei intenti.

        Il motivo per cui non ho citato il lavoro di Holopainen e Bjork è che non corrisponde alle linee guida che ho seguito nella stesura del mio catalogo di pattern, e dunque non ha rappresentato per me una fonte di ispirazione nè un punto di riferimento.

        Senza voler assolutamente sminuire il testo che citi, ho tuttavia alcuni dubbi sulle scelte che sono state fatte in quella sede. In particolare non mi convince l’aver messo in uno stesso calderone pattern relativi a meccaniche, pattern che descrivono dinamiche (Temporary Alliance) o percezioni del giocatore (Perceived Chance of success), pattern che mi sembrano un po’ troppo astratti (Tension) e addiritura anti-pattern (Analysis Paralysis).

        E’giusto essere pignolo sulle fonti, lo è altrettanto esserlo sui propri criteri di lavoro: io ho preferito seguire una strada differente, dando al termine “pattern” il significato di “micro-meccanica” o “frammento di meccanica” ed evitando, quindi, di classificare come pattern elementi quali dinamiche, processi, problematiche, che compaiono invece quali conseguenze effettive o potenziali dei pattern veri e propri.

        Non a caso il pattern che ho descritto nell’articolo (peraltro molto breve, non ho riportato certo una scheda esaustiva, sarebbe stato fuori luogo) descrive più in dettaglio gli espedienti di meccanica che lo rappresentano (es. criteri di premiazione) piuttosto che la dinamica di “corsa” che ne scaturisce. Ho inoltre deciso di adottare nomi italiani per i pattern, li ho scelti in modo che risultassero allo stesso livello di astrazione (evitando il più possibile di avere relazioni gerarchiche tra di essi ed enfatizzando invece le relazioni di complementarietà) e ho seguito molti altri criteri guida che sarebbe lungo (e noioso) descrivere qui.

        Basta dire che il risultato è qualcosa di diverso (non migliore, ci mancherebbe, ma certamente diverso).

        Il testo che ho citato (quello di Gamma) è a mio avviso uno dei migliori manuali mai scritti, per chiarezza espositiva, coerenza di intenti e densità di informazioni. In poche pagine gli autori hanno creato un classico che chiede di essere letto più volte e che rappresenta, secondo me, un riferimento fondamentale per chiunque voglia interessarsi di design pattern in generale, indipendentemente dal campo di applicazione. La struttura dei loro pattern, schematici e ricchi di esempi, offre un eccellente esempio di come dovrebbe essere fatto un catalogo di design pattern.

        • 21 Gennaio 2014 in 21:14
          Permalink

          Chiarissimo :)
          Non mi sono ancora fatto un’opinione precisa, il mio approccio è molto “esperienza-centrico” e i pattern come credo di capire li intendi tu – e di cui intravedo comunque l’utilità – hanno qualcosa che non mi torna, come se il giocatore fosse più una parte dell’ingranaggio, e non il destinatario dell’esperienza.

          Ovviamente mi baso sul poco che hai scritto, credo che non costretto dai limiti dell’articolo avresti molto più da dire, e probabilmente troveremo più punti in comune di quanti non ne permetta un breve scambio nei commenti :)

          Comunque ribadisco, bell’argomento.

          • 22 Gennaio 2014 in 10:20
            Permalink

            Si, capisco cosa intendi e concordo; i pattern hanno un’utilità limitata a certi aspetti del design, molti altri vanno affrontati tenendo presente che l’esperienza del giocatore è la chiave di tutto. E’un argomento interessante! Davvero vorrei dire tante cose ma sono sicuro che avremo modo di approfondire! ;)

  • 14 Febbraio 2014 in 17:40
    Permalink

    Grazie ragazzi, non conoscevo Holopainen e Bjork, a prescindere dalle somiglianze col lavoro di Plautus mi fa piacere approfondire l’argomento. Per quel che riguarda la rilevanza e la centralità del giocatore, spero ci sarà modo di approfondire in altra sede.

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.