Estratti di Dottrina LudusLab: Esempi di Terminologia

Quando due game designer parlano di un sistema di gioco, usano spesso le stesse parole per indicare cose diverse — o parole diverse per indicare la stessa cosa. “Meccanica” e “regola” vengono usate indifferentemente. “Sistema” può indicare tutto o niente. “Framework” è un prestito dall’informatica che nel design ruolistico ha assunto un significato specifico, ma non sempre condiviso.

Questa imprecisione non è innocua: rallenta la critica, confonde il playtest, rende difficile imparare dagli errori propri e altrui. Un designer che non sa distinguere una procedura da una meccanica non riesce a isolare il problema quando qualcosa non funziona al tavolo.

Questo articolo è un estratto dalla Dottrina LudusLab, il corpus di strumenti analitici e progettuali che orienta il nostro approccio al design. Presentiamo qui la nostra tassonomia operativa: sette termini, organizzati in una gerarchia compositiva più due voci trasversali, pensati non come definizioni da manuale ma come strumenti di lavoro.

Framework → Regolamento → Motore Regolistico → Procedura → Meccanica → Regola · Meta-Meccanica · Actual Play

Ogni livello si costruisce sul precedente. Comprendere dove si trova un problema — se nella regola, nella meccanica, nella procedura o altrove — è il primo passo per risolverlo.

FRAMEWORK · La Struttura

Il termine più alto nella gerarchia è anche il più frainteso. Un Framework non è un sistema, non è una licenza, non è un genere. È una grammatica del design: un insieme di scelte progettuali fondanti — meccaniche, procedure, assunzioni — che definiscono uno stile riconoscibile e a partire dal quale è possibile costruire giochi coerenti tra loro.

Il primo titolo che adotta un Framework ne è il capostipite, ma l’identità del Framework si consolida solo quando altri designer lo riconoscono, lo adottano e lo declinano in direzioni proprie. È un fenomeno collettivo, non individuale.

Vale la pena distinguere tra Framework espliciti — documentati, nominati, dotati di System Reference Document o licenza aperta — e Framework impliciti, riconoscibili solo per affinità stilistica e meccanica ma mai formalizzati. L’OSR è in larga parte un Framework implicito: non esiste una definizione canonica, eppure chiunque lavori nel settore lo riconosce immediatamente.

Esempi

• OSR (Old School Renaissance): derivato dalle edizioni originali di Dungeons & Dragons (Gygax/Arneson, 1974). Si riconosce per la mortalità elevata, la risoluzione leggera e spesso arbitrale del GM, la centralità dell’esplorazione e della gestione delle risorse. Il mondo non è bilanciato per i personaggi: è indifferente ad essi.
• Powered by the Apocalypse (PbtA): formalizzato da Vincent e Meguey Baker con Apocalypse World (2010). Fondato sulla struttura delle mosse come unità meccanica primaria, sul principio ‘to do it, do it’, e su un’agenda di design esplicita che orienta il comportamento al tavolo.
• Forged in the Dark (FitD): derivato da Blades in the Dark (John Harper, 2017). Condivide con PbtA l’attenzione all’agenda, ma si distingue per posizione/effetto come assi della risoluzione, flashback proceduralizzati, progresso tramite orologi.
• FATE: formalizzato con FATE Core (2013). Caratterizzato dalla centralità degli Aspetti come unità narrativo-meccanica duale e da una struttura modulare che consente ampia adattabilità di genere e tono.
• D100 / BRP (Basic Role-Playing): originato da RuneQuest (1978). Fondato sulla risoluzione percentile e sulle abilità come vettore principale di definizione del personaggio. Radice di Call of Cthulhu, Pendragon, Mythras.

REGOLAMENTO · Il Manuale

Il Regolamento è il prodotto editoriale nella sua interezza: ciò che il giocatore acquista, tiene in mano, consulta al tavolo. È composto da tre elementi distinti: la parte grafica (layout, illustrazioni, impaginazione), l’ambientazione (il mondo fittizio e il suo apparato narrativo) e il Motore Regolistico (il sistema di gioco vero e proprio).

Questa distinzione — banale in apparenza — ha implicazioni progettuali rilevanti. Un Motore Regolistico può essere estratto dal suo Regolamento originale e trapiantato in un contesto ambientale diverso, come accade con i retrocloni OSR o con i giochi PbtA di genere. Due Regolamenti possono condividere lo stesso Motore pur differendo radicalmente nella presentazione grafica e nell’ambientazione — come dimostrano le molteplici edizioni di D&D.

Va anche notato che il design grafico e editoriale non è neutro rispetto all’esperienza di gioco: orienta le aspettative, gerarchizza le informazioni e costruisce un’identità culturale attorno al sistema. Un Regolamento ben progettato è già esso stesso una promessa su ciò che il gioco produrrà al tavolo.

Esempi

• Dungeons & Dragons 5a Edizione (WotC, 2014): un’ambientazione implicita di fantasy epico, un apparato grafico standardizzato, e un Motore (5e SRD) successivamente rilasciato sotto licenza aperta e adottato da centinaia di prodotti terzi.
• Call of Cthulhu 7a Edizione (Chaosium, 2014): il Regolamento fonde in modo inscindibile l’ambientazione lovecraftiana con il Motore BRP — la coerenza tra tono editoriale, scelte grafiche e meccaniche di Sanità è un esempio raro di design pienamente integrato.
• Ironsworn (Shawn Tomkin, 2018): un Regolamento in cui l’ambientazione è volutamente leggera, e il Motore (derivato PbtA) è progettato per essere il vero protagonista — disponibile gratuitamente e pensato per essere adottato da altri designer.

MOTORE REGOLISTICO · Il Sistema di Gioco

Il Motore Regolistico è il cuore logico del gioco: l’insieme autosufficiente, completo e coerente di procedure, meccaniche e regole che ne governano il funzionamento. È ciò che effettivamente si gioca — non ciò che si compra.

L’aggettivo autosufficiente merita una precisazione: non significa generico o privo di tono. Significa che la logica interna è completa, che le parti si tengono insieme senza dipendere da elementi extra-sistemici. Un Motore tematicamente orientato — come quello di Dogs in the Vineyard di Vincent Baker, progettato per esplorare temi morali in un contesto di frontiera religiosa — è altrettanto autosufficiente di FATE Core, ma produce e vincola una specifica gamma di esperienze.

Il Motore Regolistico è il livello in cui si esercita la maggior parte del lavoro critico del designer: è qui che si valutano coerenza interna, economia delle regole, distribuzione dell’agency tra i partecipanti, e allineamento tra meccanica e tema.

Esempi

• Motore di Apocalypse World (PbtA): costruito attorno alla struttura delle mosse, alla conversazione come unità di gioco, e a un’agenda che assegna ruoli distinti al GM e ai giocatori.
• Motore di Blades in the Dark (FitD): organizzato attorno al ciclo score/downtime, alla risoluzione tramite posizione/effetto, e all’economia dei punti stress e trauma. La sua coerenza interna è tale da rendere quasi impossibile estrarne singole meccaniche senza alterare l’equilibrio complessivo.
• Motore di Cairn (OSR semplificato): volutamente minimalista, derivato da Into the Odd e Knave. Riduce la complessità al minimo indispensabile per produrre un’esperienza OSR riconoscibile.

PROCEDURA · Sequenza e Flusso di Gioco

Una procedura è un insieme ordinato di passi da seguire in un contesto specifico di gioco. Risponde alla domanda “come si fa X?” e ha natura temporale e sequenziale: i passi vanno eseguiti in un ordine preciso per raggiungere un esito definito.

La procedura principale di un gioco descrive l’intero flusso dalla sua apertura alla sua chiusura; accanto ad essa esistono procedure secondarie dedicate a singoli aspetti. La distinzione tra procedure principali e secondarie è spesso rivelatrice: ciò che viene proceduralizzato è ciò che il designer considera degno di attenzione strutturata, e quindi significativo per l’esperienza che intende produrre.

Un errore comune nel design è confondere procedura e meccanica: la meccanica definisce come funziona qualcosa (la logica); la procedura definisce quando e in quale sequenza quel qualcosa si attiva (il flusso). La stessa meccanica di risoluzione — un lancio di dado con soglia — può comparire in procedure diverse, con effetti esperienziali molto diversi.

Vale anche notare che l’assenza di procedura esplicita è essa stessa una scelta di design: molti giochi narrativisti affidano il flusso alla conversazione libera, proceduralizzando solo i momenti di frizione. Questa scelta trasferisce responsabilità dal testo al tavolo — con tutto ciò che ne consegue in termini di dipendenza dall’esperienza dei giocatori.

Esempi

• Combattimento in D&D 5e: lancio dell’iniziativa → ordine dei turni → movimento + azione (+ azione bonus + reazione) → risoluzione dell’attacco → fine round. Una procedura altamente strutturata che occupa decine di pagine di regole accessorie.
• Mossa in Apocalypse World: il giocatore descrive l’azione → il GM valuta quale mossa si innesca → tiro 2d6 + attributo → con 10+ esito pieno, 7-9 parziale con costo, 6- il GM fa una mossa. Snella, integrata, inscindibile dalla fiction.
• Ciclo Score/Downtime in Blades in the Dark: pianificazione del colpo → esecuzione → conseguenze → downtime → prossimo score. Una procedura macro che scandisce il ritmo dell’intera campagna.
• Turno di esplorazione in OSR (Old School Essentials): avanzamento → verifica del rumore → tiro incontri casuali → consumo risorse → mappatura → trappole. L’esplorazione diventa gestione di risorse sotto pressione temporale.

MECCANICA · Sistema Strutturale

Una meccanica è un insieme coerente di regole che governa un dominio specifico del gioco, producendo un tipo riconoscibile di interazione o decisione. A differenza della singola regola — atomica e normativa — la meccanica opera a un livello strutturale più ampio: definisce la logica con cui un certo aspetto del gioco funziona in modo ricorrente.

Le meccaniche non sono mai neutre rispetto all’esperienza che producono. Ogni meccanica modella il comportamento dei giocatori, orienta le loro decisioni e costruisce aspettative ricorrenti. Il designer esperto le progetta non solo per la loro coerenza interna, ma per gli effetti comportamentali e narrativi che generano al tavolo.

È utile distinguere tra meccaniche di risoluzione (come si determina l’esito di un’azione), di progressione (come cambiano i personaggi nel tempo), di economia (come si gestiscono risorse finite), di interazione sociale (come si strutturano i rapporti tra personaggi) e di worldbuilding (come il mondo viene costruito collaborativamente). Questa distinzione aiuta a mappare la copertura meccanica di un sistema e a identificare i domini lasciati intenzionalmente o involontariamente privi di struttura.

Esempi

• Classe Armatura (D&D): meccanica di risoluzione difensiva che trasforma la protezione fisica in una soglia numerica. La sua semplicità è eleganza progettuale: astrarre la difesa in un numero permette una risoluzione rapida, a costo di verosimiglianza simulativa.
• Sanità Mentale (Call of Cthulhu): meccanica di progressione negativa che traccia la degradazione psicologica del personaggio. Produce un arco esperienziale predefinito — l’inevitabile declino — coerente con il tono lovecraftiano.
• Aspetti e Invocazioni (FATE): meccanica ibrida narrativo-meccanica. Brevi descrizioni (gli Aspetti) hanno sia valore diegetico che meccanico. Produce una costante negoziazione tra finzione e sistema.
• Posizione ed Effetto (Blades in the Dark): prima di ogni tiro, si stabilisce la pericolosità della situazione (posizione: controllata/rischiosa/disperata) e l’impatto del successo (effetto: limitato/standard/ottimo). Ogni azione diventa una micro-negoziazione.
• Mosse (PbtA): ogni mossa è un blocco if/then: “quando fai X, tira e ottieni Y”. Scrivere le mosse significa decidere quali azioni il sistema ritiene degne di struttura e conseguenza.
• Orologi (FitD e PbtA): cerchi divisi in segmenti da riempire. Rendono visibile la tensione narrativa, producono aspettativa e urgenza, permettono di gestire obiettivi complessi senza perdere leggibilità.

REGOLA · Istruzione Minima

La regola è l’unità normativa minima del Motore Regolistico: un’istruzione prescrittiva che stabilisce cosa è permesso, obbligatorio o vietato in una situazione specifica. Non descrive un flusso — quello è compito della procedura. Non definisce una struttura ricorrente — quello è compito della meccanica. Si limita a normare un singolo e specifico fatto di gioco.

È il livello in cui la complessità di un sistema si rivela con maggiore chiarezza. Un sistema con poche regole ben scelte è generalmente più robusto, leggibile e gestibile di uno con molte regole che si sovrappongono. Ogni regola aggiuntiva è un costo — cognitivo, strutturale, editoriale — e la tendenza alla proliferazione è uno dei rischi più comuni nel design di sistemi complessi.

Vale anche la distinzione tra regole costitutive — che definiscono cosa esiste e come funziona il mondo di gioco — e regole regolative, che disciplinano comportamenti all’interno di una struttura già definita. Questa distinzione, mutuata dalla teoria dei giochi di Searle e Suits, aiuta a comprendere perché alcune regole, se rimosse, collassano l’intera struttura del gioco, mentre altre possono essere modificate senza conseguenze sistemiche rilevanti.

Esempi

• “Un personaggio con 0 HP è incapacitato.” — Regola costitutiva che definisce una soglia di stato del personaggio.
• “Il turno inizia sempre dal giocatore alla sinistra del GM.” — Regola regolativa che disciplina l’ordine procedurale senza incidere sulla logica del sistema.
• “Un esito di 1 naturale su d20 è sempre un fallimento, indipendentemente dai modificatori.” — Introduce un rischio assoluto e irriducibile. Nessuna build è infallibile.
• “Non puoi usare la stessa abilità due volte di fila per convincere lo stesso personaggio.” — Regola regolativa che previene ottimizzazione ripetitiva e spinge verso varietà narrativa.
• “Quando un personaggio muore, il giocatore può immediatamente introdurre un nuovo personaggio nella scena.” — Gestisce la continuità dell’esperienza, con implicazioni sulla mortalità come strumento di design.

META-MECCANICA · L’Esperienza di Gioco Progettata

Il termine più sofisticato di questa tassonomia. Una meta-meccanica è una dinamica — in termini di modalità, risultanze o effetti — ricercata attivamente dal game designer perché ritenuta essenziale per produrre una specifica esperienza al tavolo.

Le meta-meccaniche sono raramente esplicitate nel testo di gioco: emergono dall’interazione profonda e spesso invisibile di elementi formali. Il designer le progetta; i giocatori le vivono senza necessariamente nominarle. Un designer che costruisce un sistema ad alta mortalità con risorse scarse non sta scrivendo regole difficili: sta progettando una meta-meccanica di tensione, parsimonia e rispetto del rischio.

Le meta-meccaniche sono anche il principale punto di confronto critico tra sistemi diversi. Due giochi possono condividere meccaniche superficialmente simili — entrambi usano d20, entrambi hanno classi — ma perseguire meta-meccaniche radicalmente diverse, producendo esperienze al tavolo incomparabili.

È utile distinguere tra meta-meccaniche di tono (registro emotivo e narrativo), di agency (distribuzione del potere decisionale), di rischio (percezione del pericolo e della posta in gioco) e di coesione (appartenenza al gruppo, conflitto interno al party).

Esempi

• La mortalità come rispetto del rischio (OSR): HP bassi, danni letali, nemici non bilanciati, risorse limitate. Non produce ‘difficoltà’: produce una meta-meccanica in cui ogni decisione ha peso reale. Il morire non è un fallimento narrativo — è una conseguenza strutturalmente prevista.
• Il fallimento produttivo (FitD): in Blades in the Dark, le conseguenze negative — stress, traumi, orologi avanzati — non interrompono il flusso narrativo ma lo alimentano. Il sistema è progettato per rendere interessante perdere.
• La pressione da agenda esplicita (PbtA): i principi e le mosse del GM in Apocalypse World sono una meta-meccanica di tensione costante. Il GM è incaricato di non lasciare mai i personaggi in una situazione stabile. “Fan of the characters, not their friend.”
• L’urgenza da compressione temporale: orologi che avanzano, torce che si consumano, rinforzi che arrivano. Il tempo diventa una risorsa meccanica oltre che narrativa.
• L’attaccamento tramite investimento progressivo: sistemi come D&D 5e o Ironsworn producono una meta-meccanica di investimento emotivo nel personaggio attraverso la progressione graduata. Ogni aumento di livello aumenta il peso delle situazioni di rischio.

ACTUAL PLAY · Il Gioco Come Viene Effettivamente Giocato

L’Actual Play è ciò che accade realmente al tavolo, in contrapposizione a ciò che il testo del gioco prescrive. È l’esperienza viva e situata: il prodotto dell’interazione tra regole scritte, persone che giocano, contesto sociale, interpretazioni, abitudini e negoziazioni tacite o esplicite tra i partecipanti.

Comprendere l’Actual Play è fondamentale perché rivela lo scarto tra design inteso e design vissuto — e quindi le possibilità reali di miglioramento del sistema. Questo scarto non è necessariamente un errore: a volte segnala che il sistema funziona meglio di quanto scritto, grazie all’intelligenza adattiva dei giocatori; altre volte rivela che una meccanica produce effetti indesiderati che il playtest non ha intercettato.

L’Actual Play ha anche una dimensione culturale irriducibile. Il D&D degli anni ’70 era giocato in modo profondamente diverso da come viene giocato oggi, pur usando le stesse regole. Il D&D di un gruppo di veterani OSR produce un’esperienza incomparabile con quello di un gruppo cresciuto sulla 5a edizione. Per il designer, l’osservazione sistematica dell’Actual Play — tramite playtest strutturati, analisi di sessioni registrate, studio delle comunità online — è uno dei metodi più potenti per verificare le proprie ipotesi progettuali.

Esempi

• La ‘diplomazia con i mostri’ nell’OSR: molti giochi OSR prevedono meccanicamente la negoziazione con i mostri (reazione, morale), ma il testo non la enfatizza. Nell’Actual Play di gruppi esperti diventa una strategia centrale — uno scarto tra opzione prevista e norma praticata.
• L’uso selettivo delle mosse in PbtA: molti gruppi alle prime armi trattano le mosse come una lista di azioni disponibili (come in D&D), anziché come trigger condizionali della fiction. Una delle frizioni più comuni nell’onboarding del sistema, che molti hack successivi hanno cercato di colmare.
• Il ‘railroading’ involontario: un GM che prepara un’avventura con struttura narrativa forte può produrre un’esperienza in cui le scelte dei giocatori hanno impatto percepito limitato — anche se le regole non lo prescrivono. Uno degli scostamenti più studiati nell’etnografia del gioco di ruolo.
• L’attaccamento inverso in sistemi ad alta mortalità: in contesti OSR dove la morte è frequente, alcuni giocatori sviluppano un attaccamento al giocatore più che al personaggio, godendo della varietà dei personaggi come esperienza in sé. Una meta-meccanica non progettata, emersa dall’uso reale.
• La deriva procedurale nei giochi senza agenda esplicita: in sistemi che non forniscono un’agenda chiara al GM, l’Actual Play tende a divergere significativamente tra tavoli diversi. Uno dei dati empirici che ha motivato la scelta di PbtA di rendere l’agenda un elemento esplicito e prescrittivo del testo.

Una tassonomia come strumento, non come gabbia

Queste sette voci non sono definizioni da imparare a memoria. Sono lenti di ingrandimento: usate bene, permettono di vedere in un sistema di gioco ciò che altrimenti resterebbe invisibile — la logica nascosta di una procedura, la meta-meccanica che orienta silenziosamente ogni decisione al tavolo, lo scarto tra ciò che il testo promette e ciò che il tavolo produce.

Il designer che impara a distinguere una regola da una meccanica, una meccanica da una procedura, e una procedura da una meta-meccanica, acquisisce qualcosa di più prezioso di una terminologia condivisa: acquisisce la capacità di intervenire sul sistema nel punto giusto, con lo strumento giusto.

Questo estratto proviene dal Manuale delle Procedure del LudusLab, il documento interno che orienta il nostro lavoro di design e critica. Nei prossimi articoli approfondiremo ciascuna di queste voci con analisi di casi specifici, esempi di playtest e strumenti pratici per il designer.

— Daniele ‘DM’ Maviglia · LudusLab