Onyrea MUD

Schivare, parare, bloccare

Sat, 23 May 2026 00:00:00 +0000

Negli ultimi due post abbiamo osservato il combattimento dal lato di chi attacca: critici, peso dell’arma, cenni sui dadi. Oggi guardiamo dal lato di chi i colpi li riceve.

Quando il tiro per colpire stabilisce che un attacco ha i requisiti per andare a segno, non è ancora detta l’ultima parola: il personaggio bersaglio dispone di tre difese: schivare, parare, bloccare.

Le tre difese

Il giocatore può decidere quanto investire nelle difese che ha a disposizione. Il comando dedicato è combattimento.

combattimento schiva: concentrarsi sull’elusione.
combattimento para: concentrarsi sulla parata.
combattimento schiva para: schiva come primaria, parata come ripiego.
combattimento para schiva: viceversa.

Il blocco non è selezionabile: se c’è uno scudo, verrà sempre fatto un tentativo di bloccare.

Il comando, senza argomenti, mostra un riassunto delle preferenze correnti.

Limitazioni

Ovviamente, nessuna delle tre difese è gratuita né universalmente migliore.

La schivata soffre il peso. Più oggetti si trasportano, meno efficacemente si schiva, e a pieno carico si riduce a poco più di un’intenzione.

La parata dipende non solo dall’abilità del difensore nella parata stessa, ma anche da quanto bene sa usare l’arma che impugna.

Il blocco soffre la concorrenza. Lo scudo è uno strumento eccezionale quando è l’unica difesa attiva, ma rende molto meno se si starà già tentanto di schivare e parare.

Ogni difesa effettua un tiro, e vince quella con il margine più ampio di successo. Se almeno una riesce, l’attacco è completamente evitato.

Rinunciare alla difesa

Esiste anche la possibilità di spegnere completamente le difese. Con combattimento difesa no il personaggio incassa ogni colpo che arriva. È una scelta che ha senso in pochi contesti narrativi: un allenamento controllato, una sottomissione, una scena di esecuzione.

Cosa vede il giocatore

Le tre difese si traducono in verbi distinti (schiva, para, blocca), e quando il margine di successo è particolarmente ampio compare un avverbio di qualità.

Difesa mista, margine medio

Specialista della schivata, margine elevato

In conclusione

Una buona difesa è un notevole differenziatore tra sopravvivenza e sconfitta in mischia. Le scelte relative all’equipaggiamento, quindi, sono ancora più importanti: ogni grammo che si aggiunge ha ricadute ampie non solo a livello di danni, ma anche sulla capacità di evitare il prossimo colpo.

Sulle armi pesanti

Mon, 18 May 2026 00:00:00 +0000

Nel post precedente abbiamo visto come la destrezza prediliga le armi leggere, premiando con critici frequenti e poderosi chi sa indirizzare con precisione i propri colpi. Oggi parliamo del concetto opposto: l’effetto della forza e delle armi pesanti, per una volta concedendoci qualche cenno alle meccaniche sottostanti.

Tre archetipi di dado

Per differenziare tra le diverse armi, ci si è affidati a variazioni tipiche nella geometria dei dadi XdY. Prendiamo ad esempio una mazza che abbia come dado 4d3, una spada lunga 2d6, e un pugnale 1d12. Tre massimali di danni identici, tre medie di danno leggermente diverse, ma un comportamento radicalmente diverso una volta che entra in gioco il peso dell’arma.

Ipotizziamo un aumento di +2 facce per ogni dado:

Arma	Base	Con +2 facce	Guadagno
Mazza	4d3 (max 12)	4d5 (max 20)	+8
Spada	2d6 (max 12)	2d8 (max 16)	+4
Pugnale	1d12 (max 12)	1d14 (max 14)	+2

A parità di bonus, la mazza a quattro dadi guadagna quattro volte quanto il pugnale a un solo dado.

Si delineano così tre archetipi:

La mazza, con più facce ma meno dadi, con andamento dei danni regolare e prevedibile.
La spada, bilanciata, con più varietà di colpi e più dipendente da destrezza.
Il pugnale, un solo dado con molte facce: imprevedibile, il cui buon uso è legato a fortuna e destrezza.

Perché le armi pesanti

Più l’arma è pesante, più la forza ne amplifica le facce. Una mazza ferrata, una grossa ascia, una spadone: in mano a un personaggio gracile rendono poco (ammesso che riesca a brandirle), ma in mano a Hafþór Björnsson si trasformano in strumenti devastanti.

Le armi leggere, al contrario, traggono pochissimo dalla pura forza: sono già rapide e maneggevoli, e nessun quantitativo di muscoli cambierà significativamente il loro danno.

Il rovescio della medaglia

Tutto ciò ha un costo. Oltre a crittare meno spesso, sono più lente da brandire, più faticose da impugnare, meno reattive in mischia. Un guerriero costruito sulla forza vivrà di scambi più infrequenti ma più decisi: ogni suo colpo conta parecchio, ma fra l’uno e l’altro l’avversario ha tempo di muoversi, ritirarsi, riposizionarsi.

Cosa vede il giocatore

Possiamo infine vedere l’effetto, in termini pratici e a parità di skill arma, che un aumento considerevole di forza ha sull’andamento dei colpi brandendo una mazza da 3 kg.

Esempio di personaggio gracile con arma pesante

Esempio di personaggio fortissimo con la stessa arma pesante

Lo stesso personaggio fortissimo con arma leggera, con dado massimale analogo

In conclusione

Destrezza e forza rappresentano quindi due archetipi diametralmente opposti: il primo veloce e imprevedibile, il secondo lento ma implacabile. Sono naturalmente concepibili anche sfumature intermedie: vivere agli estremi non necessariamente è sempre premiante, ma offre ancora una volta due strade distinte alla caratterizzazione, che è quello che ci dovrebbe interessare.

Sui colpi critici

Thu, 14 May 2026 00:00:00 +0000

Parliamo di un aspetto dapprincipio poco visibile del combattimento, che però introduce una prima significativa differenziazione tra gli stili: i colpi critici.

La ratio

Su Onyrea, un critico non sostituisce il tiro per colpire né rende in alcun modo più facile andare a segno. I critici amplificano semplicemente il danno.

Tale scelta differisce quindi da sistemi misti in cui il critico è parte integrante del tiro per colpire, oltre che determinante del danno: pensiamo ad esempio a come un 20 naturale garantisca il colpo, ignorando la difesa e conferendo un bonus al danno.

Qui si è scelto diversamente: i critici non sono particolarmente frequenti o straordinari di per sé, ma la loro esistenza apre la possibilità, a coloro che decidano di specializzarvisi, di trarne determinati vantaggi. Tali vantaggi sono sia meccanici che ruolistici, con l’evidente finalità di favorire una maggiore varietà di gioco anche fra i ruoli picchia-picchia.

Cosa succede sotto la prosa

La probabilità che si manifesti un danno critico dipende da due variabili familiari: la destrezza dell’attaccante e il peso dell’arma impugnata.

Più si è agili, maggiore è la probabilità che il colpo si trasformi in un affondo letale. Più l’arma è leggera e maneggevole, più questa probabilità sale: una lama corta premia una mano particolarmente lesta, mentre un’alabarda non si presta a finezze del genere e tende a fare male in modo più prevedibile.

C’è inoltre un tetto invalicabile: nemmeno lo schermitore più destro, impugnando un’arma sopraffina, potrà sperare in un critico a ogni fendente.

Non tutte le armi danno critici uguali

L’entità del moltiplicatore dipende dalla categoria dell’arma:

Armi di precisione (lame corte, archi, balestre) producono i critici più devastanti, sfruttando traiettorie pulite e punti vulnerabili.
Armi da taglio e inastate (lame lunghe, lance, alabarde) producono critici sostanziosi, di entità intermedia.
Armi contundenti (mazze e bastoni) producono critici meno spettacolari (ci saranno altre ragioni per preferirle…).

Naturalmente, lo scopo non è ordinare le armi in “migliori” e “peggiori”, quanto piuttosto caratterizzarle. Un barbaro armato di clava non critta come un arciere, ed è giusto che sia così. L’armatura, in ogni caso, continua a contare: un colpo critico ben piazzato su un difensore corazzato non equivale a un colpo critico inflitto a chi è vestito di solo tessuto.

Cosa vede il giocatore

Nessun messaggio speciale, nessuna colorazione aggiuntiva. I descrittori di danno mostrati nel post precedente sono calibrati su una scala continua di intensità: un critico fa semplicemente virare il messaggio verso danni più ingenti.

Personaggio con destrezza alta, utilizzando una mazza

Stesso personaggio e stesso livello di skill arma, utilizzando un pugnale

Com’è possibile vedere, un’arma poco incline ai critici tende a restituire danni regolari e prevedibili. A parità di skill arma e di avversario, un personaggio con bassa forza ma con buona destrezza ha maggiore probabilità di lasciare il segno impugnando un’arma adatta.

Devlog: necessario reboot?

Sun, 03 May 2026 00:00:00 +0000

A quattro lunghi mesi dall’ultimo post, una riflessione sul significato di questo devlog e qualche nuovo cenno vitale riguardo allo stato di sviluppo del MUD sono opportuni.

L’approccio sbagliato

Prendendo ad esempio proprio l’ultimo articolo, contenente una serie di futuribili considerazioni sul combattimento, risulta evidente che l’introduzione di massimi sistemi prima che la loro fase progettuale venga realizzata e testata è scarsamente compatibile con un devlog che non voglia essere d’intralcio all’attività di sviluppo vero e proprio. “Soft commitment” e toni ipotetici si sono di fatto tradotti nel cercare di evitare quello che, in questa fase, sarebbe stato uno sviluppo più sensato delle relative meccaniche.

Senza addentrarmi in dettagli che saranno materiale per successivi post (sperabilmente tra giorni invece di mesi), ho di fatto gettato la spugna dopo vari tentativi di creare un sistema a turni fruibile per un gioco che, anche nei suoi aspetti PvE, vuole essere anzitutto multiplayer.

Specificare, spedire, descrivere

Mi dedicherò quindi, d’ora in avanti, quasi esclusivamente a descrivere il frutto dei recenti sforzi implementativi. Evitando invece di anteporre desiderata e divagazioni programmatiche alla stesura dei ben più utili documenti interni di sviluppo, al testing, e alla programmazione stessa.

Verso un combattimento funzionale

Qual è il frutto dello sviluppo degli ultimi mesi? L’urgenza di avere qualcosa di concreto per poi proseguire verso altre meccaniche mi ha spinto a ricercare uno stile già consolidato nel tempo, che risulterà familiare a molti.

Il combattimento procede a round automatici, in tempo reale, con messaggi che descrivono attacchi e difese attraverso verbi calibrati sull’intensità del colpo.

Esempio di attacchi vari e difesa ibrida

I messaggi di danno sono proporzionali alla salute massima del bersaglio e vengono così di seguito codificati.

Color coding dei messaggi di danno

Infine, il lavoro di “collegamento” alle varie stat e skill non è stato banale: ogni volta che un “tiro” sollecita un determinato parametro, il sistema ha la possibilità di allenarlo, attenendoci dunque al paradigma fondamentale di “apprendere tramite l’uso”.

Prime riflessioni sul sistema di combattimento

Sun, 28 Dec 2025 12:00:00 +0100

Spostiamo la nostra attenzione verso uno degli aspetti più delicati: il combattimento. In questo articolo affronteremo alcune riflessioni preliminari su come potrebbe funzionare, tenendo presente che nulla è ancora definitivo.

A turni vs. tempo reale

La prima scelta di design riguarda il ritmo dello scontro. Invece del classico combattimento in tempo reale dei MUD tradizionali, dove i colpi vengono scambiati automaticamente ogni pochi secondi, Onyrea utilizzerà molto probabilmente un approccio a turni.

In pratica, ogni round presenterebbe fasi distinte: prima tutti i partecipanti sceglierebbero cosa fare, poi il sistema risolverebbe movimenti e posizioni, quindi verrebbero eseguiti gli attacchi, e infine si applicherebbero eventuali effetti tardivi.

In questo modo le decisione tattiche dovrebbero essre privilagiate. Invece di reagire freneticamente, vi sarebbe tempo (limitato) per valutare la situazione e prendere decisioni ponderate.

Distanza

Elemento centrale sarà il posizionamento relativo tra i combattenti. Ipotizziamo vi sia una linea immaginaria tra noi e il nostro avversario: possiamo essere a contatto ravvicinato, a qualche passo di distanza, o più lontani ancora per sferrare colpi a distanza (armi da lancio o magie).

Durante ogni turno, potremmo scegliere di avanzare verso l’avversario, mantenere la posizione, o indietreggiare. Queste scelte si risolverebbero in base alla destrezza dei combattenti: chi è più agile riuscirebbe a imporre la propria volontà sul terreno di scontro.

Accerchiamento

Quando più combattenti attaccano lo stesso bersaglio da vicino, si avrebbe una situazione di accerchiamento che penalizzerebbe il difensore. Tale condizione sarebbe dinamica e non permanente: se il difensore riuscisse a creare distanza anche da uno solo degli attaccanti, l’accerchiamento si spezzerebbe.

Questo spingerebbe i combattenti solitari a cercare di gestire lo spazio con attenzione, evitando di farsi circondare. Al contempo, gruppi coordinati potrebbero tentare di chiudere un avversario in una morsa.

Armi inastate

Le armi con portata estesa, come lance e alabarde, potrebbero interferire con chi cerca di avvicinarsi. Un picchiere potrebbe tentare di fermare un avversario che avanza, costringendolo a superare la sua guardia prima di combattere corpo a corpo.

Naturalmente, chi riesce a superare questa barriera e chiudere la distanza metterebbe il lanciere in difficoltà: le armi lunghe sono goffe negli spazi ristretti.

Timer di scelta

Altro aspetto su cui occorre riflettere è il timer di scelta. Ogni combattente avrebbe un tempo limitato per decidere cosa fare ogni turno. Se non si sceglie in tempo, il personaggio difenderebbe in modo passivo per quel round.

L’idea è che questo timer dovrebbe adattarsi al comportamento del giocatore: chi decide rapidamente vedrebbe il proprio tempo aumentare di poco, mentre chi sfrutta sempre tutto il tempo a disposizione lo vedrebbe ridursi turno dopo turno. Questo premierà la prontezza decisionale senza punire eccessivamente chi ha bisogno di riflettere prima di fare la propria mossa.

Intento letale

Sarà possibile scegliere se combattere con intento letale o meno. Attaccare qualcuno per sopraffarlo sarebbe diverso dall’attaccare per uccidere: nel primo caso, lo scontro terminerà prima di portare l’avversario sotto la soglia dell’incapacitazione.

Questo permetterebbe duelli d’onore, catture, e situazioni in cui la violenza non deve necessariamente concludersi con la morte. L’intento potrebbe anche cambiare nel corso dello scontro, a discrezione dell’attaccante o per il verificarsi di particolari condizioni.

Fuga

Infine, scappare da un combattimento non sarà banale. La possibilità di ritirarsi dipenderebbe dalla distanza dagli avversari, dal loro numero, e dalla destrezza relativa. Essere circondati da più nemici renderebbe la fuga molto più difficile che affrontare un singolo avversario da lontano.

Naturalmente, per fuggire è necessaria una via d’uscita: se la stanza non ha uscite accessibili, non c’è scampo.

Considerazioni finali

Il sistema di combattimento è forse l’aspetto più complesso da bilanciare in un MUD interpretativo: deve essere abbastanza tattico da risultare interessante, ma non così complicato da diventare un gioco a sé stante, a detrimento dell’immersione narrativa.

Molti dettagli restano da definire. Per ora, l’obiettivo è trovare un equilibrio tra profondità tattica e fluidità narrativa, in modo che lo scontro non sia solo routine meccanica.

In futuro parleremo anche di ferite, armature, pozioni e di come i danni potrebbero influenzare le capacità del personaggio oltre al semplice calo di punti vita.

Comandi specifici per contenitori

Mon, 22 Dec 2025 17:00:44 +0100

Oggi passiamo brevemente in rassegna alcuni comandi per la gestione di oggetti e contenitori. Si tratta di azioni concettualmente banali ma la cui implementazione ha richiesto una certa cura in ottica quality of life.

Caricare e scaricare: contenitori in stanza

I comandi carica e scarica servono per interagire con contenitori che si trovano in stanza, come un baule o un armadio.

Con carica spada baule prendiamo la spada dal pavimento e la riponiamo nel baule. Diventa particolarmente utile nelle operazioni di massa: carica tutto baule raccoglie tutti gli oggetti sparsi nella stanza e li sistema nel contenitore. Possiamo anche usare pattern come carica *monete baule per selezionare solo certi tipi di oggetti.

Il sistema rispetta i limiti fisici: se il baule è troppo piccolo per contenere un’alabarda, o troppo pieno per accogliere altro peso, l’operazione si ferma e ci viene comunicato il motivo.

scarica funziona in modo speculare: svuota il contenitore lasciando cadere gli oggetti a terra nella stanza.

Esempio carica/scarica

Oltre un certo numero di oggetti, diventa un’azione a tempo, mentre sotto una certa soglia è immediata.

carica/scarica con molti oggetti

Riempire e svuotare

Mentre carica e scarica operano su contenitori appoggiati nella stanza, riempi e svuota fanno lo stesso per i contenitori tenuti in inventario.

Se portiamo una borsa e nella stanza ci sono oggetti sparsi, riempi borsa tenterà di raccoglierli tutti. Possiamo come al solito essere più selettivi con riempi borsa *gemme.

svuota borsa lascia cadere tutto il contenuto a terra.

Esempio riempi/svuota

🔮 Restano da implementare i liquidi, nei confronti dei quali è facilmente intuibile come i comandi riempi/svuota assumeranno una funzione diversa.

Contare

Quando ci troviamo di fronte a una grande quantità di oggetti simili, il sistema li raggruppa in pile mostrando descrizioni come “alcune monete” o “molte gemme”. Ma quante esattamente?

Il comando conta ci permette di scoprirlo. Con conta monete otteniamo il numero esatto di oggetti in una pila. Possiamo anche specificare dove cercare: conta gemme borsa conta le gemme all’interno di un contenitore specifico.

Contare non è immediato: il nostro personaggio deve effettivamente manipolare e contare gli oggetti.

Contare oggetti

Trascinare oggetti pesanti

È possibile trascinare oggetti che pesano fino a tre volte il nostro carico massimo trasportabile. trascina statua aggancia l’oggetto e ce lo trasciniamo dietro mentre ci muoviamo. Il peso ha conseguenze: oggetti più pesanti rallentano significativamente il nostro movimento tra una stanza e l’altra.

Con lascia molliamo la presa e l’oggetto rimane dove ci troviamo. Possiamo anche impostare una determinata azione per l’oggetto appena rilasciato con il suffisso :_<azione>, descrivendone la posizione nella stanza.

Uso del comando trascina, visuale in terza persona

In conclusione

Chi ha giocato ai MUD tradizionali sa che interagire con gli oggetti in stanza o dentro contenitori può talvolta essere frustrante e confusionario, oltre che ripetitivo.

Senza la pretesa di rivelare nulla che non sappia di già visto, e benché questi comandi servano a rappresentare azioni di per sé tediose, ho pensato che potesse essere ugualmente utile darne concisa dimostrazione.

Composizione del guarda e descrittori

Sun, 07 Dec 2025 11:08:22 +0100

Al fine di mitigare la verbosità degli ultimi post, ho deciso di provare ad attenermi a due sottogruppi di contenuti: pochi articoli lunghi e discorsivi, e un numero maggiore di articoli brevi in formato sneak peek. Il presente articolo vuole essere della seconda tipologia.

Guardare nel dettaglio

Tipicamente, nei MUD, quando guardiamo un personaggio o un oggetto vediamo in primo luogo la sua descrizione. A corredo, il sistema elenca informazioni come lo stato di salute e il vestiario. Come possiamo rendere questo sistema più elaborato e adattarlo a un MUD interpretativo? La tensione è, come sempre, tra discorsività e immediatezza informativa dei contenuti a schermo.

Nei post precedenti ci siamo sforzati di caratterizzare gli oggetti del nostro mondo con una serie di parametri fisici: dimensioni, peso, slot corporei, ecc. Queste informazioni sono importanti per l’effettiva interazione con gli oggetti, e risulta utile mostrarle quando esaminiamo qualcosa.

D’altro canto, non possiamo delegare ai giocatori l’onere di includerle manualmente nelle loro descrizioni, né sarebbe deterministico affidare soltanto al lavoro di building l’integrazione di queste caratteristiche.

I descrittori

La soluzione adottata è implementare una serie di descrittori: concisi blocchi di testo generati dinamicamente che si aggiungono alla descrizione base di un oggetto o personaggio. Ogni descrittore è configurabile nell’ordine di apparizione e può essere attivato o disattivato.

Guardare dentro contenitori

Per i personaggi, i descrittori includono informazioni come l’altezza relativa rispetto a chi guarda, lo stato di salute apparente e l’equipaggiamento visibile. Per gli oggetti, mostrano dimensioni approssimative, materiale, stato di usura, peso spannometrico (se lo stiamo tenendo) e se si tratta di un contenitore aperto o chiuso.

Guardare qualcuno o guardare se stessi

Guardare oggetti tenuti e non

Degno di nota è che i descrittori cambiano a seconda del contesto. Guardare se stessi produce un output diverso dal guardare un altro personaggio. Esaminare un oggetto nel proprio inventario mostra informazioni diverse rispetto a esaminare lo stesso oggetto appoggiato su un tavolo o indossato da qualcun altro.

Osservare l’equipaggiamento altrui

Guardare un oggetto indossato

Inoltre, talvolta vengono affissi dei riferimenti aggiuntivi al nome dell’oggetto osservato, che si richiamano al punto di vista dell’osservatore e rendono più immediata la comprensione di cosa si sta guardando.

🔮 In futuro, i descrittori saranno influenzati anche dalle abilità del personaggio. Un guaritore esperto potrebbe percepire dettagli sullo stato di salute che sfuggono ad altri. Un fabbro potrebbe riconoscere la qualità di un’arma a colpo d’occhio. Questo aggiungerà un ulteriore livello di profondità all’esplorazione del mondo.

Roadmap preliminare e aspirazioni del progetto

Wed, 26 Nov 2025 00:00:00 +0000

Dopo aver esplorato nei post precedenti alcuni dei sistemi fondamentali, è tempo di fare un passo indietro e guardare il quadro generale. Dove stiamo andando con Onyrea? Quali sono le aspirazioni del progetto?

Al cuore della visione di Onyrea c’è un MUD moderno che mira a fondere gli strumenti meccanico-ruolistici, che abbiamo già iniziato a introdurre, con un’interfaccia grafica dotata di elementi punta-e-clicca.

Il mondo è in via di definizione e si fonderà su tre pilastri: la cooperazione tra giocatori, la scoperta graduale dell’ambientazione e l’emergere naturale delle dinamiche tra i personaggi.

Il cuore del gioco

Ruolo centrale lo avrà il PvE: esplorazioni e combattimenti pensati per piccoli gruppi, dove anche due o tre giocatori possano vivere avventure significative.

Le dinamiche PvP e i contrasti tra personaggi nasceranno invece dall’iniziativa dei giocatori stessi. Non saranno mai forzate da elementi di background o, men che meno, da volontà di mastering.

Vie alternative al combattimento

Per chi preferisce un approccio meno incentrato sul combattimento, Onyrea offrirà percorsi dedicati all’artigianato, alla raccolta e all’esplorazione pacifica. Non si tratterà di semplici attività secondarie, ma di esperienze di gioco pienamente autonome dotate di una profondità e potenzialità proprie.

Un principio guida è che il gioco non deve mai trasformarsi in “lavoro”. Ho opinioni piuttosto forti rispetto al concetto di grinding che presto o tardi approfondirò in un post dedicato.

Quello che posso anticipare è che verrà dedicato molto impegno per fare in modo che le scelte dei giocatori siano sempre deliberate e il meno possibile scontate. Non sarà mai conveniente “annoiarsi” in gioco per ottenere progressi.

Dove siamo adesso

Visioni programmatiche a parte, quindi, a che punto siamo con lo sviluppo? Vale la pena chiederselo anche se abbiamo appena iniziato. L’obiettivo non è correre verso una prima apertura, ma costruire con coerenza rispetto alle aspirazioni descritte sopra.

Fase attuale: il prototipo

Il cuore del prototipo è ora funzionante. Il riconoscimento dei personaggi permette di ricordare chi abbiamo incontrato e di vederli con i nomi che gli abbiamo dato. Il sistema di comunicazione è articolato, con direzionalità e riferimenti dinamici. Gli esprimi complessi reagiscono al contesto e riconoscono automaticamente chi abbiamo di fronte.

Le dimensioni fisiche degli oggetti definiscono come i personaggi interagiscono con essi e quali informazioni vengono presentate ai giocatori al fine di favorire l’immersione.

Le stesse regole a cui sono sottoposti tutti gli oggetti di gioco valgono anche per personaggi giocanti (PG) e non giocanti (PNG). I PNG, in particolare, si basano sulle stesse meccaniche che sostengono i PG. L’unica differenza è che non sono governati da giocatori umani.

Il sistema di equipaggiamento attualmente prevede diciannove slot corporei e un sistema di stratificazione. Possiamo indossare più oggetti nello stesso punto: un corpetto sopra una camicia, una corazza sopra entrambi. La stratificazione influenza sia la visibilità che la protezione.

Certi indumenti possono nascondere parzialmente o completamente l’identità di chi li indossa. Ciò apre possibilità interessanti per travestimenti e anonimato.

La creazione del PG prevede un numero limitato di statistiche di base, che possono essere influenzate, più un certo numero di statistiche derivate. Le statistiche base sono soggette a variazioni casuali che rendono ogni personaggio leggermente diverso nelle fasi iniziali di crescita.

Il sistema di azioni a tempo gestisce operazioni che richiedono intento o concentrazione. Queste azioni possono essere interrotte, volontariamente o meno. Questo sistema getta le basi per meccaniche più complesse che verranno sviluppate in seguito.

Le tappe verso l’alpha

Lo sviluppo seguirà una serie di milestone interne. Non verranno fornite tempistiche rigide: ogni nuova fase verrà intrapresa quando la precedente funzionerà a dovere.

Gettare le fondamenta (completata)

Implementazione/affinamento dei sistemi essenziali: tempi delle azioni di base (come lo spostarsi), calibrazione del sistema equip, fluidità del riconoscimento e meccaniche social. Assicurarsi che tutto risponda in modo naturale.

Progressione e crescita (iniziata)

Implementare la crescita basata sull’uso effettivo delle abilità, con tempi realistici di progressione del PG. L’obiettivo è dare un senso di sviluppo continuo alle azioni, definire le fasi di accrescimento e applicare la legge dei ritorni decrescenti.

Combattimento

Implementazione del ciclo di combattimento e delle meccaniche di base: ingaggio, reazioni e conseguenze. Sarà importante definire le relazioni tra gli scontri e l’ambiente circostante, e l’effetto su partecipanti diretti e indiretti.

Mondo esplorabile

Al momento esiste solo un’area introduttiva, il tutorial. Vari dettagli relativi all’hub centrale di gioco, al mondo esterno (wilderness), le aree/dungeon… sono al momento solo teorici. È in programma una commistione di elementi statici e procedurali.

Lingue

I PG saranno tutti “connazionali” e parleranno quindi una lingua comune. Tuttavia, non sarà sempre facile e immediato comunicare con le varie fazioni di PNG. Inoltre, lo studio delle lingue aiuta anche a comprendere il passato.

Crafting, risorse, sopravvivenza

Introdurre sistemi di raccolta e artigianato per dare ai personaggi non-combattenti modi significativi di contribuire al mondo. Molta attenzione verrà dedicata alle meccaniche che consentiranno ai personaggi meno orientati al combattimento di avventurarsi ed esplorare con efficacia, senza dover per forza impugnare una spada.

Sistema magico

Non potrebbe mancare. 😉 Cercheremo di andare oltre cure, buff e dardi incantati. L’idea è che un utilizzatore di magia dovrebbe poter influenzare quasi ogni aspetto del mondo tangibile, proporzionalmente alla potenza delle sue abilità.

Test su invito

Un gruppo ristretto di volenterosi avrà l’onore e l’onere di collegarsi prima degli altri e fornire feedback prezioso. L’obiettivo sarà validare ritmo, bilanciamento, divertimento e scelte di design in generale. Sarà una fase di ascolto e iterazione continua.

Open Alpha

Aprire Onyrea al pubblico e continuare a costruire insieme.

In conclusione

Onyrea sta prendendo lentamente forma. Continuerò a condividere informazioni sul funzionamento dei vari sistemi di gioco, e a un certo punto inizierò a parlare anche di ambientazione.

Le informazioni saranno volutamente frammentarie, sia per come è strutturato il flusso di lavoro, sia perché lo sviluppo è svolto in solitaria. Spero comunque che la direzione appaia chiara e comprensibile. Nulla verrà fatto frettolosamente.

Partecipare alla community

Gli aggiornamenti principali continueranno a essere pubblicati su questo blog. Per chi desidera seguire più da vicino lo sviluppo o partecipare ad eventuali sondaggi di community, esiste il canale Telegram dove è possibile condividere commenti e impressioni. Quanto ai sondaggi, è uno strumento che mi riservo di utilizzare con moderazione e più avanti nel tempo.

Introduzione al mondo fisico di gioco: oggetti ed equip

Sun, 16 Nov 2025 00:00:00 +0000

Per il tipo di gioco che abbiamo in mente, è essenziale che gli oggetti abbiano una presenza fisica tangibile e consequenziale. Vediamo come le grandezze fisiche influiscono su ciò che vedono i personaggi e sulla gestione di inventario ed equipaggiamento.

Percepire le dimensioni dei personaggi

Quando incontriamo qualcuno, alcune caratteristiche fisiche saltano immediatamente all’occhio. Guardando qualcuno significativamente più alto, leggeremo in calce alla descrizione frasi come “È un gigante in confronto a te” o “È notevolmente più basso di te”.

Il sistema confronta l’altezza del personaggio osservato con quella di chi guarda e genera dinamicamente parte della descrizione. Un personaggio alto due metri che ne osserva uno di un metro e mezzo percepirà una differenza sostanziale, mentre due personaggi di altezza simile si vedranno alla pari.

Descrittore altezza dinamico

Le dimensioni degli oggetti: una semplificazione

Invece di riprodurre le tre dimensioni di altezza, larghezza e profondità, ogni oggetto è caratterizzato da una singola misura che rappresenta la sua dimensione più significativa.

Un letto, ad esempio, è alto solo 50 centimetri da terra ma lungo due metri. Nel nostro sistema avrà un’altezza di 200 centimetri perché quella è la dimensione più rilevante per determinare dove può stare o come interagisce con altri oggetti.

Questa semplificazione si applica a tutto:

Una spada lunga ha un’altezza di 120 centimetri (lunghezza della lama più l’elsa)
Una camicia misura 40 centimetri (la sua larghezza quando riposta, ai fini dell’ingombro)
Un tavolo misura quanto il suo lato più lungo

Quando esaminiamo un oggetto, vediamo le sue dimensioni approssimate tramite una breve frase: “minuscolo” come una moneta, “compatto” come un pugnale, o “enorme” come un dolmen.

🔮 Occorrerebbe a un certo punto differenziare per categoria di oggetto, altrimenti una statua equestre e un veliero apparirebbero “enormi” allo stesso modo.

Il peso degli oggetti

Le dimensioni di un oggetto sono sempre visibili, ma il peso si rivela solo quando cerchiamo di sollevarlo. Una spada appoggiata su un tavolo mostra le sue dimensioni ma non il peso. Solo prendendola in mano scopriamo se è “leggera”, “di peso moderato” o “molto pesante”.

Come nella realtà: possiamo vedere quanto è grande un baule, ma solo sollevandolo scopriamo se è vuoto o pieno di oggetti.

Interazione con oggetti di diverso peso

Contenitori indossabili

I contenitori indossabili come zaini e borse distribuiscono meglio il peso del loro contenuto sul nostro corpo. Quando indossato correttamente, uno zaino pieno che pesa dieci chili potrebbe gravare su di noi come se ne pesasse solo cinque, permettendoci di trasportare più peso di quello che la sola forza delle nostre braccia consentirebbe.

La dimensione del contenitore determina cosa può contenere: un marsupio può contenere monete e piccoli oggetti, ma non una spada lunga. Un grande baule può contenere armature complete, ma è troppo ingombrante per l’inventario.

Il sistema di slot corporei

Il corpo del nostro personaggio è suddiviso in diciannove posizioni dove possiamo indossare equipaggiamento: testa, orecchie, viso, collo, schiena, torso, spalle (x2), braccia (x2), mani (x2), dita (x2), vita, gambe e piedi. Inoltre, abbiamo due “pugni” che rappresentano ciò che stiamo attivamente impugnando.

🔮 La necessità di distinguere tra i due arti superiori permetterà, quando il sistema di ferimento verrà implementato, di differenziare tra colpi alla mano/braccio/spalla con cui si tiene lo scudo e quella in cui è impugnata l’arma. Questa suddivisione sarà essenziale dal punto di vista tattico. Con gli arti inferiori questa complicazione ce la siamo risparmiata. Inoltre, in futuro potrebbe essere introdotta anche una distinzione tra strati, per cui indossare una cotta di maglia sotto un’armatura a piastre consentirebbe di sommare due tipi di protezione (ad esempio contro armi contundenti e trafiggenti).

Oggetti che occupano slot multipli

Alcuni oggetti occupano più zone del corpo contemporaneamente. I guanti coprono entrambe le mani: quando ne indossiamo un paio, occupiamo sia lo slot della mano destra che quello della sinistra. Lo stesso vale per i bracciali che coprono entrambe le braccia, o gli spallacci che proteggono entrambe le spalle. Il sistema non esclude si possano avere spallacci, bracciali o guanti singoli, tuttavia al momento non riesco a vedere il merito di un simile approccio.

Similmente, alcuni tipi di protezione potrebbero coprire ampie porzioni del corpo, come una tuta Hazmat, ad esempio.

Infine, le armi a due mani richiedono ovviamente entrambe le mani: per brandire un’alabarda o un arco lungo dobbiamo impegnarle completamente. Il sistema riconosce automaticamente questi oggetti e occupa entrambi gli slot dei pugni, impedendoci di usare contemporaneamente uno scudo o un’altra arma.

Impugnare un’arma a due mani

Indossare oggetti multipli

È possibile indossare o rimuovere più oggetti contemporaneamente. Mentre un oggetto singolo è un’azione istantanea, indossa tutto o rimuovi tutto richiedono tempo a seconda del numero di oggetti e del loro peso: un anello richiede circa un secondo, un’armatura pesante ne richiede diversi.

Esempio di indossa tutto

Cenni sul sistema statistiche

Forza e peso trasportabile

La quantità di peso trasportabile dipende dal peso corporeo e dalla forza. Un personaggio alto e muscoloso potrà trasportare molto più equipaggiamento di un gracile. La formula tiene conto di entrambi i fattori: un personaggio piccolo ma incredibilmente forte potrà comunque trasportare un carico proporzionalmente elevato, mentre uno molto alto ma debole potrebbe faticare nonostante la stazza.

Con forza minima ed escludendo particolari malus, riusciremo a trasportare faticosamente un po’ meno di metà del nostro peso corporeo. Personaggi dotati di forza leggendaria potrebbero riuscire a trasportare anche il doppio del proprio peso!

Capacità dell’inventario

Anche il numero di oggetti gestibili contemporaneamente nell’inventario (escluso ciò che indossiamo) dipende dalle stat, nella fattispecie da destrezza e forza (quest’ultima in misura minore). Non si tratta solo di quanto peso possiamo sopportare, ma anche di quanto siamo abili nel gestire e organizzare i nostri averi. Un personaggio equilibrato tra forza e agilità avrà quindi vantaggi significativi. Il numero di oggetti trasportabili è volutamente basso, inferiore a venti anche per i più destri, per non risultare eccessivamente irrealistico.

Requisiti dell’equipaggiamento

Alcuni oggetti richiedono caratteristiche minime per essere utilizzati. Un’armatura pesante potrebbe richiedere una certa forza per essere indossata efficacemente, mentre armi particolari come un nunchaku potrebbero richiedere destrezza o un livello minimo in una certa skill per essere brandite con efficacia.

Un mondo fisico e tattile

Perché sbattersi tanto per dare coerenza interna a un mondo di gioco? Perché la tangibilità e la relazionabilità del sistema fisico sono elemento cardine per spingere un po’ più in là la sospensione dell’incredulità. In un libro fantasy posso accettare l’esistenza dei draghi, ma non che il protagonista abbia un salto verticale di sei metri, o che possa trasportare una montagna.

Questi sistemi lavorano insieme per creare un mondo dove gli oggetti hanno peso e presenza, gravando sul nostro personaggio in modo possibilmente non oppressivo, ma volutamente costante e ineludibile. Scegliere cosa portare in un’avventura diventa oggetto di strategia, come un guerriero che si equipaggia bilanciando protezione e mobilità. Zaini e borse non sono orpelli, ma elementi essenziali per la quality of life.

Tutto ciò sarà inevitabilmente affinato in base ai feedback dei giocatori, per trovare il giusto equilibrio tra realismo e giocabilità.

Prossimamente

Mi rendo conto che questa sbrodolata di informazioni possa risultare noiosa e che molti aspetti meccanici potrebbero ugualmente scoprirsi in gioco senza tanti preamboli. La realtà è che, essendoci di fatto un mondo intero da implementare, mi è di aiuto soffermarmi e mettere per iscritto i ragionamenti che hanno portato a determinate scelte. Per variare un po’ i contenuti del blog, e nel frattempo che le fondamenta meccaniche di Onyrea prendono forma, con il prossimo articolo parleremo per sommi capi di fasi di sviluppo e roadmap del progetto.

Esprimersi nel gioco di ruolo: comandi base

Thu, 13 Nov 2025 00:00:00 +0000

Nel precedente articolo abbiamo visto come il sistema di riconoscimento e il comando dici costituiscano la base della comunicazione nel MUD. Ma parlare non è l’unico modo per esprimersi, come possiamo quindi permettere ai personaggi di agire, seppure interpretativamente?

In questo articolo esploriamo gli strumenti che permettono di arricchire l’interpretazione: dalle espressioni facciali, alle forme alternative di comunicazione, fino al versatile comando esprimi.

Discorso diretto ed emozioni

Il comando dici ci permette di includere espressioni facciali mediante simboli noti:

dici ciao a tutti :)

Il sistema riconosce automaticamente l’emoticon e la trasforma in una descrizione narrativa:

Utilizzo di base delle emoticon

Le emoticon supportate includono:

:) - sorridendo
:( - triste
:d - ridendo
:e - con esitazione
:f - felice
:i - con indifferenza
:m - mestamente
:o - sconvolto/sconvolta
:p - scherzosamente
:x - sottovoce
;) - ammiccando
;( - piangendo

Personalizzazione

Utilizzando la sintassi :_ è inoltre possibile imprimere al dici azioni o emozioni più specifiche e articolate:

Esempio di comando dici e sintassi :_

Questo apre infinite possibilità espressive. Possiamo descrivere gesti, espressioni facciali complesse, sguardi, posture. L’unico limite è la nostra capacità di descrivere ciò che il personaggio sta facendo mentre parla.

Usare la voce in altro modo

Non sempre parliamo a voce normale. Alle volte ci troveremo a voler sussurrare qualcosa a qualcuno, oppure gridare, o ancora cantare.

Sussurrare

Il comando sussurra permette di dire qualcosa a qualcuno privatamente:

sussurra, visuale in prima persona

sussurra, visuale in seconda persona

sussurra, visuale in terza persona

Chi riceve il sussurro lo sente chiaramente, mentre gli altri nella stanza percepiscono solo che stiamo sussurrando, senza riuscire a distinguere le parole.

Gridare

Al contrario, grida proietta la voce in modo che tutti possano sentire, anche a una certa distanza:

grida attenti al lupo!

Pensare

Non tutto ciò che passa per la mente del nostro personaggio deve essere condiviso con gli altri. Il comando pensa serve per esprimere o annotare i pensieri del personaggio:

pensa devo trovare una via d'uscita

Solo noi vediamo il pensiero, ma potrebbero esistere situazioni, abilità o oggetti speciali che permettono di percepire i pensieri altrui.

Cantare

Infine, il comando canta permette di intonare canzoni o melodie:

canta la la la, che bella giornata

🔮 Cantare è un’azione sociale che può animare una taverna, accompagnare un viaggio, o semplicemente esprimere la gioia del personaggio. In futuro, cantare potrebbe diventare un’abilità vera e propria. Bardi e menestrelli potrebbero usare il canto per influenzare gli ascoltatori, richiamare magie, o semplicemente intrattenere per guadagnarsi qualche moneta. La qualità del canto potrebbe dipendere da statistiche del personaggio e dalla pratica.

Il comando esprimi

Abbiamo visto come arricchire il dialogo con espressioni, e come usare forme alternative di comunicazione. Ma c’è un ultimo strumento, forse il più versatile: il comando esprimi.

Questo comando permette di descrivere qualsiasi azione non verbale del nostro personaggio:

esprimi si siede lentamente, osservando gli altri

Produce un messaggio visibile a tutti nella stanza:

Un uomo con una lunga barba e capelli grigi si siede lentamente, osservando gli altri.

Facile. Ora complichiamoci la vita e vediamo come il comando esprimi si presti a elaborazioni più sfiziose.

Integrare descrizioni brevi

Il comando esprimi si integra perfettamente con il sistema di riconoscimento visto nel precedente articolo. Quando eseguiamo un’azione, gli altri giocatori vedono la nostra descrizione breve o il nome con cui ci hanno riconosciuti.

Se un giocatore non ci ha ancora assegnato un soprannome, vedrà la nostra sdesc. Se invece ci conosce, vedrà il nome che ci ha dato. Questo mantiene la coerenza con il resto del sistema, e fin qui tutto bene.

Riferirsi ad altri personaggi

La vera potenza di esprimi emerge quando dobbiamo interagire con altri personaggi nelle nostre azioni. Il sistema usa riferimenti speciali:

@ o /me per riferirci a noi stessi
/nome per riferirci ad altri personaggi

Per esempio:

esprimi con un gesto solenne, @ porge la mano a /brom

Il sistema risolve automaticamente i riferimenti usando i riconoscimenti di tutti i presenti. Ogni giocatore vede l’azione con i nomi che conosce:

esprimi, visuale in prima persona

Nel frattempo, un altro giocatore che conosce lo stesso personaggio con un nome diverso, vedrà:

esprimi, visuale in terza persona

Questa risoluzione automatica permette di costruire scene complesse dove ogni giocatore mantiene la propria prospettiva narrativa, ma tutti stanno assistendo alla medesima scena.

Libertà interpretativa e limiti del sistema

Anche se disponiamo di una base meccanica versatile, non ogni gesto che è possibile immaginare può ragionevolmente tradursi in un esprimi. Eventuali considerazioni, anche relative all’etichetta interpretativa, sono lasciate alla discrezionalità dei giocatori e al libero accordo tra essi, per esempio in relazione ad esprimi che presuppongono una qualche forma di forzatura o coercizione, o altre limitazioni della libertà altrui.

🔮 Un importante limite meccanico è invece la non-distinzione tra prospettive in prima e terza persona. Sia l’autore dell’esprimi che eventuali personaggi inclusi tramite la notazione /nome vedranno se stessi in terza persona. Poco ci si può fare, per il momento. Quando saranno oggetto di implementazione, i comandi sociali (o esprimi preimpostati) saranno esenti da questa problematica.

Azioni persistenti

Mentre esprimi descrive azioni momentanee, a volte vogliamo comunicare una postura o un’attività che dura nel tempo. Per questo esiste il comando azione.

Quando impostiamo un’azione, questa viene mostrata a chiunque guardi la stanza. È un modo per arricchire la scena con dettagli persistenti:

azione sta in piedi vicino al muro, sorridendo

Ora, quando qualcuno guarda la stanza, non vedrà solo che siamo presenti, ma anche cosa stiamo facendo. L’azione rimane finché non la cambiamo o la rimuoviamo con azione reset.

Azioni predefinite

La forma più semplice del comando azione prevede l’annullamento automatico ogni volta che ci spostiamo. Tuttavia, possiamo anche impostare un’azione predefinita che appare automaticamente ogni volta che entriamo in una nuova stanza:

azione default sta distrattamente in un angolo

Mettere in posa gli oggetti

Infine, non solo i personaggi possono avere azioni. Possiamo anche descrivere come sono posizionati gli oggetti nella stanza:

azione ogg spada = è appesa sopra il camino

Questo crea dettagli ambientali che arricchiscono lo spazio condiviso. Gli oggetti con azioni diventano parte della scena, non solo voci nell’inventario della stanza.

Creare scene vive

Tutti questi strumenti lavorano insieme per trasformare la comunicazione da semplice scambio di informazioni a vera narrazione collettiva.

Possiamo:

Mescolare parole e gesti: usando :_ per integrare azioni nel dialogo
Creare atmosfera: scegliere tra sussurrare, gridare, cantare o parlare normalmente
Costruire azioni complesse: con esprimi e riferimenti dinamici ad altri
Modificare la scena: tramite azione per descrivere posture e comportamenti che durano nel tempo

Questo è il grado di libertà espressiva opportuno per un MUD il più possibile moderno, che voglia individuare nel GDR un suo carattere fondativo.

Prossimamente

Nel prossimo articolo esploreremo alcune caratteristiche fisiche del mondo di gioco, soffermandoci sugli oggetti che lo popolano e su come i personaggi interagiscono con essi.

Riconoscimento e comunicazione di base

Sat, 08 Nov 2025 00:00:00 +0000

Nel primo articolo ho accennato a come Evennia includa un modulo chiamato RPSystem che fornisce strumenti specifici per il gioco di ruolo. Tra questi, il più importante è probabilmente il sistema di riconoscimento: un meccanismo che permette ai giocatori di scoprire gradualmente l’identità degli altri personaggi, invece di vedere immediatamente il nome di tutti.

L’uso dell’emoji della palla di cristallo (🔮) sta a indicare considerazioni su implementazioni future.

Il problema dei nomi fissi

Nei MUD tradizionali, quando incontriamo un personaggio ne vediamo subito il nome: “Frodo è qui”. Questo è semplice da implementare, ma crea un problema per l’immersione narrativa.

Nella realtà, quando incontriamo qualcuno per la prima volta, non conosciamo il suo nome. Ciò che si vede è un aspetto, forse un abbigliamento particolare, e solo dopo una presentazione ne scopriamo il nome. Nei MUD tradizionali questa scoperta graduale è impossibile.

Per un gioco che punta al GDR immersivo, questo è limitante. Come si può creare mistero, intrighi, o semplicemente l’esperienza naturale di fare nuove conoscenze, se tutti sanno già chi siamo?

Descrizioni brevi: chi abbiamo di fronte?

La soluzione parte dal concetto di descrizione breve (in originale short description o sdesc). Invece di mostrare il nome del personaggio, il gioco mostra una breve frase.

Invece di vedere:

Gandalf è qui.

Potremmo vedere:

Un uomo con una lunga barba e capelli grigi è qui.

Per impostazione predefinita, ogni giocatore definisce la propria descrizione breve usando il comando sdesc. Questa descrizione sostituisce il nome in tutte le situazioni: quando qualcuno ci guarda, quando parliamo, quando ci muoviamo da una stanza all’altra.

🔮 A questo punto si aprono due strade: la prima, consentire in autonomia di impostare la propria descrizione breve, in fase di creazione del personaggio, o la seconda, vincolare l’aspetto, in modo dinamico, a una matrice di parametri come stazza e muscolarità. Entrambi gli approcci hanno dei meriti, per il momento una decisione non è ancora stata presa.

L’effetto è in ogni caso immediato: i personaggi diventano figure misteriose da scoprire, invece che etichette immutabili e inconfondibili. Ecco che guardare semplicemente qualcuno, notare come si comporta e ascoltare cosa dice, diventano una parte significativa del gioco, ancor prima delle presentazioni.

Il sistema di riconoscimento

Ma cosa succede quando incontriamo di nuovo la stessa persona? O quando finalmente scopriamo il suo nome?

È qui che entra in gioco il sistema di riconoscimento. Usando il comando ricorda, è possibile assegnare un soprannome personalizzato a qualcuno:

ricorda uomo come Mithrandir

Da quel momento in poi, solo l’osservatore vedrà il personaggio con il nome assegnato. È un riconoscimento personale: altri giocatori, altri popoli potrebbero conoscerlo con un nome diverso, o perfino averlo dimenticato.

Questo crea dinamiche sociali interessanti:

Identità multiple: un personaggio potrebbe presentarsi con nomi diversi a persone diverse
Scoperta graduale: le relazioni si costruiscono nel tempo, come nella realtà
Prospettive individuali: ogni giocatore ha la propria versione della storia, basata su chi ha conosciuto e come

Il sistema tiene anche traccia di quando vediamo un personaggio per l’ultima volta. I riconoscimenti più vecchi di tre mesi vengono rimossi automaticamente: se non vediamo qualcuno per tanto tempo, è naturale che la memoria svanisca. Ogni volta che interagiamo con un personaggio conosciuto, estendiamo la durata del riconoscimento.

Il comando ricorda in azione

Utilizzo del colore

Per aiutare i giocatori a distinguere i personaggi a colpo d’occhio, il sistema usa colori diversi per rappresentare il genere. Quando si crea un personaggio, si sceglie il genere (maschile o femminile) e questa scelta determina il colore con cui appare la descrizione breve.

Per esempio:

Maschile: azzurro chiaro
Femminile: rosa chiaro
Neutro: viola (riservato alle entità sovrannaturali)

Questa scelta è permanente e fatta una sola volta durante la creazione del personaggio. Non è qualcosa che influenza le meccaniche di gioco, per ora, ma solo come si appare agli altri giocatori.

🔮 Un’alternativa da considerare è di vincolare il colore allo stato di salute: verde se in salute, giallo se ferito, rosso se grondante di sangue o in fin di vita.

Comunicare: l’interfaccia italiana

Una volta risolto il problema dell’identità, si è reso necessario costruire un’interfaccia di comunicazione che funzionasse in italiano e rispettasse il sistema di riconoscimento.

Il comando dici

Il comando base per parlare è dici:

dici ciao a tutti

Il sistema riconosce la punteggiatura finale per scegliere il verbo più appropriato:

Effetti della punteggiatura sull’output del dici

Parlare a qualcuno in particolare

Naturalmente è possibile dare anche una direzionalità al dialogo. Il sistema usa i riconoscimenti personali per capire a chi ci si sta rivolgendo. La persona riceverà un messaggio che indica chiaramente che stiamo parlando con lei, mentre gli altri nella stanza assisteranno alla scena ancora da un’altra prospettiva:

Dialogo con prospettiva in terza persona

Ogni giocatore vede i nomi in base ai propri riconoscimenti: se mi ricordo di qualcuno come “Brom” ma un altro giocatore lo riconosce come “lo straniero”, ciascuno vedrà la versione che ha assegnato personalmente.

L’impatto sull’esperienza di gioco

Tutti questi sistemi lavorano insieme per creare un’esperienza di gioco più immersiva e sociale.

Invece di un flusso costante di informazioni immediate e complete, il giocatore vive in un mondo dove:

Le relazioni richiedono tempo: dobbiamo conoscere le persone gradualmente
L’identità è fluida: chi siamo dipende da come ci presentiamo
La prospettiva è personale: la nostra storia è unica, basata su chi abbiamo incontrato e cosa abbiamo vissuto
La comunicazione è naturale: il linguaggio scorre più fluidamente, senza artifici o traduzioni goffe

Questo crea la base per il gioco di ruolo. Non si tratta solo di variazioni cosmetiche, ma di veri e propri strumenti che facilitano le interazioni sociali e narrative tra giocatori.

Prossimamente

Nel prossimo articolo tratteremo approfonditamente il comando esprimi e altri strumenti per arricchire l’interpretazione, come il comando azione e alcune forme “potenziate” del comando dici.

Sulle spalle di giganti: verso un nuovo MUD italiano

Tue, 04 Nov 2025 00:00:00 +0000

Ogni progetto inizia con un primo passo. Per capire da dove partiamo, vale la pena ripercorrere brevemente la storia dei MUD in Italia.

Un po’ di storia

Trovo che al panorama muddico italiano non sia mancato davvero niente. Dai fulgidi esempi di MUD classici e old-school, alcuni dei quali con community tuttora in discreta salute, fino all’epocale apripista che fu The Gate. Quest’ultimo aveva introdotto un client proprietario e faceva del GDR il caposaldo dell’interazione fra giocatori.

Vi è poi stata la parabola dodecennale di Isylea, vero erede del The Gate originale. È l’esempio più “alto” di mudding dove abbia avuto modo di trascorrere il mio tempo. Se è lecito estendere un concetto come quello di “democratizzazione” anche all’universo MUD, ad Isylea va il primato per l’ampiezza (non solo numerica) della base di utenti che ha saputo raggiungere.

Tra gli altri giochi ambiziosi nel corso degli anni ‘10, trovo utile menzionare: Sword of Darkness, coraggiosa riscrittura di un già meritorio gioco preesistente che prevedeva sia un’interfaccia che delle meccaniche ben oltre le convenzioni dei MUD; e Zenith of Magic, interessante iniziativa di sviluppo i cui blog post un po’ mi facevano sognare, poi svanita con una criptica e altisonante dichiarazione dello sviluppatore.

Dopo la chiusura di Isylea a fine 2019, fecero la loro apparizione diversi progetti più o meno ispirati a essa. A titolo di esempio cito Races at War (forse anche antecedente) e Run With Wolves, senza pretesa di esaustività.

Quanto a chi scrive, una prima infruttuosa parentesi di sviluppo MUD è attestata da un lapidario articolo apparso su mud.it l'8 marzo 2021. Forse qualcuno ricorderà anche l’annesso canale Telegram.

Screenshot dell’articolo ‘Nuovo MUD ancora senza nome’ su mud.it

Il progetto si arenò per una serie di motivi: la mia scarsa esperienza, alcune digressioni fatali (come spendere troppe energie in elementi di generazione procedurale), e gli impegni tipici della real life.

Passati cinque anni, cosa è cambiato e qual è il lascito concreto di due colossi come The Gate e Isylea? Veri eredi di quello spirito di gioco temo non se ne siano visti, e a volerne cercare qualche esponente si farebbe fatica anche nella ben più ampia MUD community anglofona.

Eppure, nonostante questo scenario, ho deciso di ritentare. Ammetto che devo alle cosiddette IA il rinnovato entusiasmo per cimentarmi di nuovo. In particolare, l’avvento dei modelli denominati agentic: quelli che non solo imitano secondo un modello probabilistico un output umano (sia esso prosa o altro), ma possono operare ed essere istruiti all’uso di strumenti. Questo consente, nella pratica, di ridurre considerevolmente l’attrito dato dallo scrivere tonnellate di codice boilerplate (o “di servizio”), specialmente quando lo sforzo viene affrontato sostanzialmente in solitaria, come in questo caso.

Da ciascuno dei progetti che ho citato, anche quelli che non hanno visto la luce, è possibile trarre insegnamenti di vario tipo. Vedremo dove questo ci porterà.

Perché Evennia?

Evennia è un framework Python per la creazione di MUD che offre un’architettura stabile e moderna. A differenza di altri sistemi più vecchi, ha un backend web basato su Django, supporta nativamente un webclient, e fornisce un sistema di persistenza basato su database facilmente estensibile.

Quindi, in breve:

Codice Python moderno e ben documentato
Architettura modulare basata su import e override
Supporto integrato per funzionalità web
Netta separazione tra dati, logica e interfaccia
Hot reload durante lo sviluppo e correzione bug
Comunità attiva e contributori esperti
Ho già detto Python?

Gioco di ruolo e non

Esiste uno spettro piuttosto ampio che va dai giochi puramente orientati alla progressione e al combattimento (i cosiddetti MUD “hack and slash”) fino a quelli dove l’interpretazione del personaggio è centrale e obbligatoria.

La classificazione tipica prevede:

Non-RP: il focus è su combattimento, esplorazione, livelli e oggetti. L’interpretazione di un personaggio è opzionale o assente.
RPE (Roleplay Enforced): il GDR è richiesto, ma con una certa flessibilità. È possibile affrontare mostri o fare quest senza necessariamente una giustificazione narrativa approfondita.
RPI (Roleplay Intensive): il GDR è il cuore del gioco. Ogni azione dovrebbe avere una motivazione del personaggio. Il combattimento esiste, ma è secondario rispetto alle interazioni sociali e narrative.

Al di là di quanto questa suddivisione ci convinca, questo progetto mira decisamente verso l’intento ruolistico. L’astrazione delle meccaniche è, a mio modo di vedere, l’unico modo possibile per favorire l’immersione narrativa. Quanto a disincentivare l’ottimizzazione numerica, empiricamente non ritengo si possa fare molto, ma vedremo come provarci. Quantomeno questo non sarà il tipo di gioco in cui i personaggi vanno in giro con “Livello 50” stampato in fronte.

A questo scopo, Evennia include un modulo chiamato RPSystem che fornisce strumenti specifici per il GDR:

Descrizioni brevi (sdesc) invece di nomi fissi visibili a tutti
Sistema di riconoscimento per “imparare” chi sono le persone
Mascheramento per cambiare temporaneamente il proprio sembiante
Comandi di espressione avanzati per descrivere azioni in modo narrativo

Tuttavia, RPSystem è stato pensato per giochi in inglese. Per un MUD italiano, molte sue parti vanno riscritte e adattate. Non si tratta solo di tradurre stringhe, ma di ripensare come il gioco costruisce le frasi parola per parola (ad esempio, gestire articoli, genere e accordo) per avere un’esperienza testuale naturale in italiano.

Evennia rende questo possibile grazie alla sua architettura modulare: è possibile prendere un modulo esistente, comprenderne la logica e ricostruirlo in tutto o in parte, mantenendo le idee di base ma adattandolo completamente a un contesto linguistico diverso.

Di quest’ultimo tema parlerà il prossimo articolo. Questo viaggio è appena iniziato.