Guida pratica per aspiranti game designer (parte terza: l’artefatto)

Dopo aver presentato, seppur brevemente, il nostro eroe e il settore in cui andrà a operare, possiamo passare all’oggetto della sua attività: il potentissimo artefatto noto ai più come gioco.

Di definizioni di gioco, nel corso dei secoli, ne sono state date moltissime, più o meno applicabili al concetto attuale che ha di gioco la persona comune e più o meno fantasiose o pragmatiche. Per la Treccani, il significato più comune di “gioco” è “qualsiasi attività liberamente scelta a cui si dedichino, singolarmente o in gruppo, bambini o adulti senza altri fini immediati che la ricreazione e lo svago, sviluppando ed esercitando nello stesso tempo capacità fisiche, manuali e intellettive”. Giova ricordare che in realtà il gioco può avere anche altre funzioni oltre a quella di intrattenimento (che comunque rimarrà quella cui ci dedicheremo principalmente in questa sede): può essere utilizzato, fra gli altri, anche nel campo dell’educazione, della formazione, della comunicazione; a parte questo dettaglio, però, appare subito chiaro come dal nostro punto di vista – ossia “lato progettista” – si renda necessaria una definizione un po’ più precisa, che ci aiuti a capire un po’ meglio cosa dobbiamo fare per progettare un gioco.

Magari un filino meno inquietante di questo.

La definizione da cui parto sempre è quella utilizzata da Salen e Zimmerman in Rules of Play:

Un gioco è un sistema al cui interno i giocatori si impegnano in un conflitto artificiale, definito da regole, che porta a un risultato quantificabile. [1]

Questa definizione, che ha il pregio enorme di identificare il gioco (game) con un sistema – ossia qualcosa di diverso dall’attività (play) – però, ha un paio elementi che mi piacciono poco: il primo è il termine “conflitto”, a cui preferisco il più generico “sfida”; in secondo luogo, non concordo con il “risultato quantificabile”: un gioco di ruolo può non avere un risultato quantificabile, ma non per questo è meno “gioco” di altri.

Prendiamo allora un’altra definizione, quella di Ernest Adams in Fundamentals of Game Design:

Un gioco è un tipo di attività ludica, condotta in un contesto di realtà fittizia, in cui i partecipanti cercano di raggiungere almeno un obiettivo, arbitrario e non-triviale, agendo in accordo con delle regole. [2]

Questa, a meno che non abbiate letto Fundamentals of Game Design, va un po’ spiegata. Adams intende con “gioco” l’attività, e la descrive in modo abbastanza preciso: quest’attività è ludica (nel senso di “attività interattiva volta a intrattenere”, anche se come abbiamo visto può avere altre finalità parallele), si svolge in una realtà fittizia (ossia un mondo immaginario, diverso da quello reale) e chiede ai giocatori di raggiungere un obiettivo deciso arbitrariamente dal designer (“ottenere più punti vittoria”, “conquistare 24 territori”, “risolvere l’enigma”, “raccontare una storia di vampiri”) che costituisce una sfida significativa (“non triviale”) seguendo delle regole.

Ok. Questo mi piace di più, ma manca l’importante distinzione fra il gioco e l’attività. Perché? Perché, come vedremo, il game designer non ha il controllo completo su tutta l’equazione, anzi. Possiamo fare un gioco che permetta di bluffare, rischiare o pianificare ma non possiamo obbligare i giocatori a bluffare, rischiare o pianificare.

Sfortunatamente, l’autore non è incluso nella scatola.

Quindi, da queste due definizioni, che hanno come “centro” il concetto di sistema da un lato e il concetto di attività ludica dall’altro, possiamo provare a fare un passo ulteriore, avendo come focus la finalità del gioco: far vivere ai giocatori un’esperienza (possibilmente appagante, divertente e coinvolgente, ma su questo torneremo in seguito). Per quanto ci riguarda, dunque, definiremo il gioco – inteso come l’oggetto che intendiamo progettare – in questo modo:

Un gioco è un sistema che coinvolge uno o più giocatori in un’attività volontaria, il cui scopo è vivere un’esperienza, condotta in un contesto di realtà fittizia, in cui i partecipanti affrontano almeno una sfida significativa agendo in accordo con delle regole.

La cosa fondamentale da capire, a questo punto, è che il designer in tutto questo ha un’unica area d’azione: la progettazione del sistema. Vale a dire che noi possiamo definire la “realtà fittizia”, le sue regole e gli obiettivi che avranno i giocatori; starà poi a loro affrontare la sfida proposta e vivere l’esperienza che stiamo cercando di proporre loro.

Questo concetto è magnificamente espresso da un framework (o “struttura”), il Framework DPE [3], sviluppato da Winn nell’ambito dei giochi in campo educativo, che riprende ed amplia il più famoso Framework MDA [4] di Hunicke, LeBlanc e Zubek.

Nel Framework MDA, il gioco viene diviso in tre “segmenti”: meccaniche, dinamiche ed estetica (Mechanics, Dynamics, Aestethics, che formano appunto la sigla “MDA”). In questo caso le meccaniche indicano le azioni, i comportamenti e meccanismi di controllo regolamentati e forniti ai giocatori all’interno del mondo di gioco. In armonia coi vari contenuti di gioco (scenari, risorse, etc), le meccaniche sono la base di tutte le dinamiche di gioco, che invece sono i comportamenti che emergono dalla “messa in moto” del gioco, quando i giocatori fanno “funzionare” il gioco. L’esperienza vissuta dal giocatore (divertimento, tensione, appagamento) è invece detta estetica.

Tutto chiaro?

Per fare un esempio banale, le regole degli scacchi dicono come si possono muovere i vari pezzi e come si fa a vincere. Le dinamiche sono ciò che succede quando i pezzi vengono mossi, e sono ciò che ha portato a sviluppare i vari stili di gioco e le varie tecniche (forchetta, infilata, ma anche, per esempio, tutte le aperture e i finali) che sfruttano le meccaniche per ottenere risultati migliori. L’estetica è la somma di tutto quello che vive lo scacchista: la tensione, il senso di sfida, ma anche il piacere di toccare i pezzi e di veder “funzionare” una strategia vincente o la frustrazione per un errore.

Nel Framework MDA, inoltre, viene descritto come ogni gioco dovrebbe tendere a incentivare uno o più tipi di piacere o divertimento (in inglese “kind of fun“). Preferisco evitare il termine “divertimento” perché viene associato alle risate, o comunque a qualcosa di vago, mentre i kind of fun sono concetti abbastanza precisi: il piacere della scoperta e dell’esplorazione, il piacere di affrontare una sfida, il piacere di utilizzare la propria creatività, il piacere sensoriale dato da pezzi gradevoli da toccare o da una grafica appagante, e così via. Ogni gioco dovrebbe avere il suo (o i suoi) kind of fun, e fare di tutto perché essi siano il centro dell’esperienza di gioco.

Il Framework DPE non si occupa tanto del lato “kind of fun”, ma in compenso amplia il concetto di Meccaniche-Dinamiche-Estetica, mettendo in campo tre diversi elementi:

1) Design, ossia il nostro progetto, è tutto quello su cui abbiamo controllo. Meccaniche, regole, procedure, ma anche scelta di materiali e ambientazione.

2) Play, l’atto del giocare, è tutto ciò che riguarda le dinamiche di gioco: cosa fanno i giocatori con le regole e i materiali che hanno a disposizione. Sono i comportamenti che emergono durante le partite.

3) Experience, l’esperienza di gioco, è quello che viene percepito dai giocatori durante la partita: emozioni, coinvolgimento, interesse.

Dunque, quello che faremo sarà realizzare un sistema (o, se preferite tornare al titolo del capitolo, un artefatto [5]) composto da materiali e da regole. Queste regole stabiliranno una serie di limiti alle azioni dei giocatori e cercheranno di gestire una serie di elementi (incertezza, interazioni etc), nonché di prevedere e indirizzare il flusso di gioco, in modo da riuscire a veicolare ai giocatori l’esperienza che vorremmo che vivessero.
Facile, no?

Per capire un po’ meglio come realizzare il nostro progetto, dunque, dobbiamo capire quali sono gli elementi che lo compongono e che grado di controllo abbiamo su di essi. Ma questo, per vostra fortuna, lo vedremo la prossima volta.

Se avete appunti, domande o commenti, ovviamente lasciateli liberamente qua o sulla mia pagina Facebook.

Alla prossima!

NOTE

[1] “A game is a system in which players engage in an artificial conflict, defined by rules, that results in a quantifiable outcome.” (da Rules of Play – Game Design Fundamentals di Katie Salen e Eric Zimmerman)

[2] “A game is a type of play activity, conducted in the context of a pretended reality, in which the participant(s) try to achieve at least one arbitrary, nontrivial goal by acting in accordance with rules.” (da Fundamentals of Game Design di Ernest Adams)

[3] DPE Framework, di Brian M. Winn, tratto da Handbook of Research on Effective Electronic Gaming in Education di Richard E. Ferdig

[4] MDA Framework, MDA: A Formal Approach to Game Design and Game Research di Robin Hunicke, Marc LeBlanc, Robert Zubek

[5] Ovviamente l’artefatto può essere concreto o astratto, ma per fortuna nel caso dei giochi tabletop c’è da fare un po’ meno fatica con questo concetto, visto che ogni gioco tabletop ha quantomeno un regolamento e – tolto qualche gioco di ruolo minimale – qualche tipo di elemento fisico (pedine, dadi, carte). Quindi possiamo tranquillamente parlare di “artefatto” nel senso di “gioco”, intendendo il sistema nella sua interezza, coi i suoi componenti e le sue regole.

 

One thought on “Guida pratica per aspiranti game designer (parte terza: l’artefatto)

Leave a comment