Meccaniche

“Le meccaniche sono ciò che fa sì che l’artefatto sia un gioco.”
(M. Bertolo)

Non so se l’avete notato, ma è difficile leggere un articolo o un thread su un gioco da tavolo senza che si senta parlare di meccaniche. Non “regole”, non “procedure di gioco”: meccaniche.
Però, alla richiesta di produrre una definizone per il termine – feci questo gioco anni fa coinvolgendo diversi amici gamers e qualche operatore – si ottengono risposte di molto diverse fra loro, che talvolta vanno dalla pseudo-filosofia al tentativo di infilare a martellate l’idea che il giocatore ha in una definizione che sembri davvero una definizione.

Secondo me una definizione è tanto più buona quanto più è funzionale al proprio scopo. Per cui, se per voi lo scopo di una definizione è quello di farvi vincere una disputa in un forum, probabilmente potete trovare qualcosa di meglio cercando su google una citazione a effetto.
Se invece vogliamo riflettere su come designer e giocatori vedano le meccaniche, e se vogliamo fare un tentativo di trovare un vocabolario comune con questo discorso, vale la pena parlarne.
Ho sempre cercato il senso di “meccaniche” rispetto all’attività di design: capire cosa sono per capire come farle, per comprendere e conoscere meglio il mio lavoro, per avere un maggiore controllo rispetto a quello che sto progettando.

Ovviamente molti game designer all’ascolto sapranno di cosa sto parlando: per reperire testi dedicati, anche decidendo che la teoria dietro al proprio lavoro non merita la lettura di un libro, basta un motore di ricerca e la capacità di riconoscere se un testo è stato scritto con cognizione di causa.
Ma visto che dell’argomento si discute anche su blog e forum, immagino che il discorso interessi anche altri, per cui proverò a fare un riassunto. Ovviamente lo farò dal mio punto di vista e, a scanso di equivoci, senza la minima pretesa di analizzare la questione per intero: a ogni definizione corrispondono spesso studi e analisi lunghe e complesse, e se l’argomento vi interessa (o una definizione vi affascina in particolar modo) vi invito a cercare il libro o il paper di riferimento e prendervi un po’ di tempo per studiare il tutto.

La prima cosa che ho scoperto è che c’è una distinzione da fare: quella fra meccaniche, o più propriamente mechanics, plurale, con cui normalmente s’intende il complesso di elementi che compongono il gioco e le relazioni che li legano, e meccanica, mechanic o più raramente mechanism, al singolare, che si usa di solito per indicare quella regola o quel set di regole che regolamentano un’attività fondamentale all’interno del sistema di gioco che i giocatori o il sistema stesso reiterano nel tempo.

Le meccaniche intese come insieme (mechanics, quindi) definiscono, in sostanza, il gioco in quanto sistema di regole, specificando come si comporta quando il giocatore interagisce con esso. Io le definisco come il mezzo che permette alle scelte dei giocatori di avere un significato nel mondo di gioco.  
Questo perché, se le prendiamo nella loro totalità, hanno esattamente questa funzione: dato un mondo di gioco, le meccaniche sono gli strumenti che consentono al designer di tradurre in regole, interazioni e procedure di gioco quelle che vogliamo siano le scelte e le azioni dei giocatori, e le loro conseguenze.

Ovviamente esistono definizioni più tecniche o più estese: Rouse (in Game Design Theory and Practice), definisce per esempio le meccaniche come “il modo specifico con cui si implementa una parte del gameplay”, ciò che descrive “quello che i giocatori sono in grado di fare nel mondo di gioco, come lo fanno, e come tutto questo conduce ad un’esperienza di gioco avvincente”. Cook (nell’interessante articolo “what are game mechanics”) le definisce come “sistemi\simulazioni basati su regole che facilitano e incoraggiano l’utente a esplorare e imparare le proprietà dello spazio di possibilità, attraverso l’uso di meccanismi di feedback”, una cosa interessante perché pone al centro il concetto di “imparare” già valorizzato da studiosi come Koster, e cita nella definizione stessa i feedback come sistema per incoraggare l’esplorazione e l’apprendimento delle varie possibilità offerte dal mondo di gioco.

Proababilmente la definizione più famosa è quella di Robin Hunicke, Marc LeBlanc e Robert Zubek, che nel Framework MDA definiscono le meccaniche come 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 le meccaniche vengono poste in uso. L’esperienza vissuta dal giocatore (divertimento, tensione, appagamento) è invece detta estetica. Il che crea sempre qualche problema di confusione con la parte estetica (intesa come grafica e sensoriale) del gioco, tanto che da diversi anni qualcuno tende a preferire il termine “esperienza”, come per esempio nel Framework DPE di Brian Winn (che chiama “Design” tutta la parte progettabile dal designer – quindi le meccaniche, la storia, l’interfaccia utente, etc; “Play” tutta la parte dinamica, ossia l’atto del giocare, e “Experience” l’esperienza vissuta dal giocatore, le emozioni, le sensazioni, etc).

Dato che però parlare sempre di “tutte le meccaniche” rende difficile concentrarsi su aspetti particolari di un gioco, spesso viene naturale parlare di “meccanica”, ossia un pezzo dell’ingranaggio che permette a tutto il gioco di girare.
In tal senso, la coppia Salen\Zimmerman, in Rules of Play, definisce il concetto di core mechanic, o meccanica principale: la core mechanic è l’attività fondamentale allo svolgimento del gioco che coinvolge i giocatori quando giocano, l’azione che “definisce” il gameplay.

Ovviamente può non trattarsi di un’azione singola, ma di micro-sistema di regole; la definizione è interessante perché ai boardgamers viene abbastanza naturale chiamare “meccanica” un gruppo di regole connesse fra loro rispetto al focus del gioco e all’esperienza proposta (siano esse core o secondarie), anche a causa del fatto che questo è il senso che viene più o meno dato al termine su boardgamegeek (sebbene lo stesso sito abbia una lista di “meccaniche” decisamente caotica e incoerente, forse perché è stata fatta “dal basso” senza che ci fossero linee guida chiare per la redazione delle voci, basti pensare che la “definizione” di meccanica su BGG viene troncata, parafrasando la wiki, con “beh, magari è meglio se facciamo degli esempi”).

Andando un attimo oltre Rules of Play, senza però discostarci dall’approccio “funzionale”,  trovo molto interessante lo schema proposto da Wil Mozell, che divide il gioco in meccaniche principali, meccaniche secondarie, sistemi progressivi e narrativa. E’ stata studiata partendo dai videogiochi, ma si adatta molto bene anche ai giochi da tavolo.

La meccanica principale è l’interazione volontaria fra giocatore e gioco che occorre il più spesso possibile. In un worker placement, sarà il binomio “piazza omino, esegui azione”, in un gioco di corse sarà l’azione che permette alla propria pedina di avanzare, e così via. Prendendo come esempio Puerto Rico, la meccanica principale è “scegli un personaggio, esegui l’azione collegata”.

Le meccaniche secondarie sono interazioni meno frequenti (in giochi molto semplici potrebbero addirittura non essere presenti): proseguendo con Puerto Rico, stiamo parlando del mercato, della costruzione degli edifici, delle spedizioni delle merci.

I sistemi di progressione sono tutto quello che succede e cambia indipendentemente dai giocatori o in maniera automatica mano a mano che il gioco procede (fasi di mantenimento, rigenerazione di risorse, respawn di mostri etc). In Puerto Rico sono tutte le sotto-regole che riguardano il numero di Coloni che si mettono sulla nave, il refresh delle piantagioni, e così via.

Il livello della narrativa è quello che contestualizza tutto il resto (il “salva la principessa” che fa correre Super Mario). Non va preso alla leggera, perché non si tratta “solo dell’ambientazione”; tranne rare eccezioni, è qui che si colloca lo scopo del gioco (“hai un solo obiettivo: ottenere il maggior benessere e il più alto rispetto!”), anche se poi il raggiungimento dello stesso verrà probabilmente “regolamentato” da altre meccaniche. A meno che il gioco non sia completamente astratto e così semplice da avere un sistema di punteggio o di assegnazione della vittoria radicamente incastonato nella meccanica principale, dovrebbe esserci un minimo di coerenza fra chi sono i giocatori e come si vince (o, almeno, io la penso così).

Ovviamente si può obiettare che definire le meccaniche secondo questa scala di priorità sia solo un modo di vedere le cose. Ed è assolutamente vero. A me piace perché offre un buon punto di partenza per dividere le meccaniche – intese come micro-sistemi – in categorie, legandole in modo stretto all’uso che ne fa il giocatore, e a quanto strettamente è legata la meccanica al gameplay, al gioco in pieno svolgimento.

Come ho detto all’inizio, a me interessa dare nomi alle cose in modo che mi sia più chiaro quello che faccio. La cosa che mi piace del Framework DPE è che descrive in modo più che chiaro come un game designer possa intervenire solo sul “design” e non sul resto: il suo “lavoro” è quello di creare la prima parte dell’equazione; le meccaniche verranno poi  “messe in moto” dall’atto del giocare, e si tradurranno in esperienza. Dal punto di vista del giocatore il percorso è inverso: il giocatore percepisce in primis l’esperienza, ottenuta attraverso il giocare; le meccaniche sono la parte più nascosta, quello che c’è sotto il cofano, gli ingranaggi che girano mentre si gioca.

Preferisco approcciare la progettazione in modo “giocatore-centrico” (rubando il termine a Tracy Fullerton), partendo dall’esperienza che voglio far vivere a chi giocherà. In questo modo mi viene abbastanza naturale pensare prima al tipo di scelte che voglio che il giocatore faccia (sulla base di quali sensazioni, pensieri ed emozioni voglio far emergere nel gioco), e poi modello delle meccaniche funzionali a tradurre quelle scelte in qualcosa di coerente rispetto al progetto.

Allo stesso modo, credo che per parlare in maniera costruttiva di meccaniche, posto che il termine non serva solo per riempirsi la bocca con un vuoto tecnicismo, serva definire prima cosa siano e a cosa servano, queste benedette meccaniche.
Se lo scopo è quello di dare ai giocatori e ai designer un modo per chiamare parti dei sistemi di gioco riconoscibili, al fine di avere un linguaggio comune e magari creare un sistema di generi che vada oltre il binomio euro-american (che peraltro inizia già a traballare, vista la mole di ibridi che escono ogni anno) credo che possa aver senso definire le meccaniche a partire dal modo in cui consentono ai giocatori di interagire col sistema di gioco, magari recuperando alcuni dei termini più calzanti e più riusciti (e non a caso più usati) del vocabolario dei boardgamers.

Ovviamente questo è quello che penso io, mi piacerebbe proseguire la discussione sia con altri autori che con giocatori e operatori del settore interessati, sono convinto che si possa trovare un “linguaggio comune”, soprattutto se si ha l’obiettivo comune di imparare a capirsi.

Advertisements

2 thoughts on “Meccaniche

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s