The Kernel in Yellow 10 X 10
Last updated: 2019-12-10
The Kernel in Yellow:~ Desktop$ node Appunti di game design: sistemi di tipi.js

> Post.all
Appunti di game design: sistemi di tipi

Questo interessantissimo post di The Angry GM mi ha fatto venire voglia di esplicitare un paio di considerazioni di game design che uso attivamente da un po’.

L’idea è semplice: se volete modificare un sistema in modo decente (al di là del banale refluff), dovete capire il suo type system. D’altra parte, se volete che il vostro sistema sia facilmente modificabile, dovete avere un buon type system e fare in modo che sia comprensibile.

Type che?

Il concetto di Type System viene dall’informatica teorica, in particolare dal mondo della linguaggistica (cioè quella branca dell’informatica teorica che studia come funzionano e si progettano i linguaggi di programmazione). Ora, non serve tuffarsi fino in fondo in questo mondo (se siete curiosi, comunque, ho un buon ricordo di questa breve introduzione), vi faccio un bigino io.

L’idea di base è che nel mondo di gioco abbiamo una serie di entità (i personaggi, i mostri, gli oggetti…) che hanno delle proprietà comuni (ad esempio, tutti i mostri hanno uno stat block). Prendiamo ad esempio Gobbutz, un goblin: possiamo considerarlo un’istanza dell’idea platonica di goblin (il concetto di “idea platonica” in questo mondo ha un nome ben preciso, che purtroppo vuol dire un’altra cosa nel mondo del GdR: classe), che a sua volta è una versione dettagliata dell’idea di “mostro”. Questo vuol dire che avrà:

  1. Una serie di caratteristiche comuni a tutti i mostri (compie azioni, ha uno stat block)
  2. Una serie di caratteristiche comuni a tutti i goblin (le statistiche tipiche dei goblin)
  3. Una serie di caratteristiche specifiche al nostro Gobbutz (i PF, l’equipaggiamento…)

Aggiungiamo un paio di termini per tagliare sui giri di parole:

  1. goblin eredita le caratteristiche da mostro (e ne aggiunge di altre)
  2. Gobbutz è un’istanza di goblin (ovvero, non è più “un generico goblin”, ma diventa “uno specifico goblin”, con il suo equipaggiamento, i suoi PF e via dicendo, che si possono modificare nel mondo di gioco senza bisogno di modificare la descrizione di goblin).

Sul concetto di istanza c’è poco da aggiungere, mentre l’idea di ereditarietà ci dà un altro paio di concetti utili:

  1. Anche gnoll eredita da mostro, quindi posso avere più discendenti da uno stesso genitore
  2. Posso modificare alcune delle caratteristiche ereditate (ad esempio, i non-morti non hanno Costituzione)
  3. Posso costruire una catena di eredità: mostro -> non-morto -> zombie
  4. Non piace a tutti i teorici, ma posso ereditare da più genitori (quindi potrei avere un goblin zombie)

Ora, fermerei qua i formalisimi che se no diventa un casino (specie se iniziamo a guardare le magie) e andrei oltre.

Ok, ma che me ne faccio?

Per gli smanettoni

Se riconosco la logica che c’è dietro, diventa molto più facile aggiungere nuovi elementi (o riusare in maniera elegante gli elementi presenti per farci altre cose), riporto dal post di Angry GM:

I could, for example, show that you could model fire – normal fire – as a monster. It’s immune to all damage except cold and its immune to all conditions. On its turn, it attacks anyone sharing its space or adjacent to it with fire damage. And it can also move 5 feet on its turn as long as it enters a space that contains something flammable. And whenever it moves, it leaves behind another fire. Now, you have a nice rule for a fire that breaks out during combat and spreads on each initiative count. And since each instance of the fire is its own creature, it doubles the number of instances of itself every time it spreads.

Sfruttando gli strumenti che il gioco mette a disposizione per creare un mostro, abbiamo un buon modo di gestire gli incendi (o i combattimenti durante gli incendi). E’ un ottimo modo per avere delle HR che siano originali ma non troppo in conflitto con il gioco, così come è estremamente funzionale per la creazione di incantesimi, oggetti e mostri.

Per i game designer

Qua diventa più difficile. Innanzitutto perché dovete identificare i tipi del vostro gioco: alcuni sono intuitivi (incantesimi, oggetti, oggetti magici), altri meno (mostri e trappole sono distinti?), e poi c’è anche da tenere conto del rapporto tra di loro (i mostri sono una specializzazione di un generico “personaggi”?). E poi dovete fare in modo che siano chiari e comprensibili a chi vuole rimetterci mano.

Un esempio pratico

Proviamo a scrivere un sistema di tipi per un gdr fantasy generico, vagamente dndesco. Poi se volete riempirlo con dadi, fluff e un vero regolamento, sentitevi liberi.

Per semplicità di notazione, i tipi saranno indicati così Tipo (sempre al singolare), mentre le istanze saranno istanza. Quando un tipo eredita da un altro, lo indicherò con Tipo [Tipo1].

Secondo me, ci sono due tipi di entità basilari in un gdr: i personaggi (cioè quelli che fanno cose, giocanti o meno) e gli oggetti (che sono inanimati e, al massimo, reagiscono alle azioni dei personaggi). Quindi partiamo con una coppia facile: Personaggio e Oggetto.

Per dare un po’ di caratteristiche ai nostri tipi, ci servirebbe un altro tipo, che descrive gli oggetti del regolamento (come ad esempio i concetti di caratteristiche, HP e via dicendo), ma non ci formalizziamo troppo e facciamo finta che esistano queste cose (se invece volete diventare davvero formali, le cose si fanno interessanti, perché se descrivete abbastanza bene il concetto di HP, potreste scrivere regole che cambiano come funzionano gli HP).

Che cos’ha un Personaggio? Ha uno stat block, può compiere un certo numero di azioni e possedere uno o più oggetti.
Che cosa può essere un Personaggio? Innanzitutto può essere manovrato da un giocatore (PG [Personaggio]) o dal DM (PNG [Personaggio]). In realtà questa è una distinzione che non ha senso, perché hanno le stesse caratteristiche. Diciamo che un personaggio può essere Umano [Personaggio], Goblin [Personaggio] o Gnoll [Personaggio].

Che cos’ha un Oggetto? Ha un prezzo, un peso, un ingombro e degli effetti.
Che cosa può essere un Oggetto? Arma [Oggetto] (che ha un dado di danno), Armatura [Oggetto] (che dà un bonus alla CA), Edificio [Oggetto] (che ha una mappa e uno spazio interno), Trappola [Oggetto] (che ha degli effetti automatici), Oggetto Magico [Oggetto] (che ha un’aura e delle regole di attivazione ben precise).

Ora, diciamo di fermarci qua. Indipendentemente dal regolamento (d20, d10, tarocchi…) abbiamo già abbastanza materiale per:

  1. Giocare razze mostruose (in fondo è tutto Personaggio, no?)
  2. Avere armi magiche (Spada Magica [Arma, Oggetto Magico])
  3. Avere armi trappola!
  4. Avere edifici trappola!

E in realtà, giocando con la definizione di razza e classe (ci serve davvero che siano estensioni di Personaggio? potremmo dire che ogni Personaggio ha una Razza e una Classe - o anche di più) possiamo allargare molto l’estensibilità del gioco.