Logeon - Engine per "PbC"

Logeon - Engine per "PbC" postato il 28/03/2026 21:26:33 nel forum programmazione, open source e hosting e modificato da moderazione il 07/04/2026 09:18:33

LoreForge — Un motore open source per giochi Play by Chat

Cos'è un gioco PbC e perché è difficile farne uno da zero
Chi ha frequentato la scena del gioco di ruolo testuale online conosce bene la situazione: hai un'idea per un mondo, una storia, un sistema di gioco. Magari hai già una community disposta a giocare. Ma costruire l'infrastruttura tecnica che rende tutto questo possibile: il sistema di personaggi, le posizioni in mappa, i messaggi, le gilde, l'economia, i conflitti, il pannello di gestione, è un lavoro che può richiedere mesi, o anni, a prescindere dal gioco in sé.

LoreForge nasce da questa consapevolezza: non come soluzione definitiva, ma come punto di partenza solido e già funzionante.

Il progetto in breve
LoreForge è un motore open source per giochi Play by Chat (PbC) scritto in PHP, pensato per chi vuole costruire una community di gioco di ruolo testuale persistente senza dover reinventare ogni volta le fondamenta.

L'obiettivo è fornire un sistema completo: backend, frontend, pannello di amministrazione, su cui il creatore di gioco possa lavorare per personalizzare ambientazione, meccaniche e contenuti, concentrandosi su ciò che rende unico il proprio gioco piuttosto che su ciò che è comune a tutti.

Il progetto è attivamente sviluppato, documentato, e viene rilasciato con una struttura pensata per essere estesa in modo sicuro senza dover toccare il nucleo del framework.

A chi è rivolto
LoreForge si rivolge a due tipi di persone, spesso la stessa:
- Sviluppatori con interesse per il gioco di ruolo testuale, che vogliono un codebase pulito su cui lavorare invece di partire da zero o da soluzioni datate.
- Creatori di gioco con competenze tecniche di base, che vogliono concentrarsi sull'ambientazione e sulle meccaniche narrative piuttosto che sull'architettura applicativa.

(modifica) Non è pensato come soluzione “installa e gioca” senza personalizzazione.
Il gioco è già funzionante dopo l’installazione, ma è progettato per essere adattato: inizialmente tramite configurazione e pannello admin, e successivamente, se necessario, tramite estensioni senza modificare il core.

Cosa include
Di seguito una panoramica delle aree funzionali già implementate e disponibili nel progetto.

Personaggi e account
Ogni utente può gestire uno o più personaggi. Il sistema include la creazione guidata, le transizioni di ciclo vitale del personaggio (stati, fasi), richieste di cambio nome e di cessione, e un sistema di attributi completamente configurabile con regole di derivazione e calcolo.

Mappa e luoghi
Il mondo di gioco è organizzato in mappe con luoghi interni. Ogni luogo ha una propria stanza di chat, può avere politiche di accesso ristretto (con sistema di inviti temporanei), tabelle di loot per oggetti, e un log degli accessi. Il meteo globale è configurabile, con override per singola area geografica.





Gilde
Sistema completo di gilde con ruoli, permessi granulari per scope di azione, accesso a luoghi riservati, annunci, eventi, log di attività, sistema di candidatura, richieste di espulsione con voto democratico, e gestione delle entrate economiche della gilda.



Economia e inventario
Valute multiple configurabili, botteghe con inventario gestito dall'amministratore, sistema acquisto/vendita con log delle transazioni, inventari per personaggio con capacità limitata, definizione di oggetti con rarità, categorie e regole di equipaggiamento.



Progressione
Sistema di lavori con livelli e compiti a scelta, log di avanzamento, esperienza e fama con storico variazioni.

Conflitti
Il modulo conflitti supporta sia la risoluzione narrativa che quella casuale (con dado), traccia i partecipanti e i loro ruoli, registra ogni azione e tiro, e gestisce il ciclo di vita di un conflitto dalla dichiarazione alla chiusura.



Quest
Sistema di missioni con definizione a step, condizioni di avanzamento, ricompense (valuta, esperienza, oggetti), integrazione con eventi narrativi, e storico completo per personaggio.

Narrative ed eventi
Il motore narrativo permette di definire stati di gioco con trigger automatici, tag per categorizzare contenuti, eventi narrativi visibili ai giocatori, ed eventi di sistema (tornei, spedizioni, eventi globali) con partecipazioni, ricompense e log.

Messaggistica e forum
Sistema di messaggi diretti tra personaggi con threading, sistema forum multi-tipo con thread e risposte, segnalazioni messaggi con moderazione integrata.

Notifiche e presenza
Notifiche evento-driven, tracking della presenza online dei personaggi con stato di disponibilità, lista giocatori attivi.

Contenuti e lore
Sezioni configurabili per regolamento, storyboard (lore del mondo), guida al gioco, e sistema news/avvisi in-game.

Pannello di amministrazione
Un pannello completo con oltre quaranta pagine di gestione: utenti, personaggi, contenuti, moderazione, configurazione di ogni sistema di gioco, e sette tipologie di log analitici (conflitti, valute, esperienza, fama, gilde, lavori, accessi ai luoghi, log di sistema).





Architettura tecnica (per chi vuole saperne di più)
LoreForge è costruito su PHP 8.1+ con Twig come template engine lato server. Il frontend è JavaScript vanilla (ES6+ module pattern) senza framework SPA: ogni pagina carica solo il modulo che le serve, il che mantiene i tempi di caricamento bassi e il codice organizzato.

Il database è MySQL/MariaDB con uno schema di oltre 110 tabelle, accessibile tramite un adapter MySQLi personalizzato. Le migrazioni sono gestite tramite patch SQL versionati.

Struttura applicativa:
- core/ — Router, AuthGuard, ResponseEmitter, SessionGuard, adapter DB, sistema di upload, gestione moduli
- app/controllers/ — Oltre cinquanta controller HTTP (uno per dominio)
- app/services/ — Oltre centoventi service layer con la logica di business
- app/views/ — Template Twig per area pubblica, di gioco e amministrativa
- assets/js/app/ — Runtime frontend modulare con feature, moduli e service client

Il sistema di autorizzazione è server-side su ogni endpoint. Non esiste logica di accesso che viva solo nel client.

Il progetto include punti di estensione sicuri (custom/routes.php, custom/bootstrap.php, sistema di moduli con hook) per aggiungere funzionalità senza modificare il nucleo, che rimane aggiornabile in modo indipendente.

Stato del progetto
LoreForge è in sviluppo attivo ed è in procinto di essere rilasciato pubblicamente nella sua prima versione beta, nel giro di pochi giorni. Il nucleo del framework, il set completo di funzionalità di gioco, e il pannello di amministrazione sono già implementati e funzionanti. La documentazione tecnica è disponibile nella directory docs/ e copre architettura frontend, sistema di moduli, pattern API, e guida alla personalizzazione del gioco.

Il progetto non è ancora una distribuzione "produzione pronta per tutti i casi d'uso", siamo in fase beta e ci sono aree in evoluzione, e la configurazione richiede competenze tecniche di base. È, però, un codebase serio e strutturato, non un prototipo.

Come iniziare
L'installazione richiede un ambiente PHP 8.1+, MySQL, e un web server compatibile (Apache o Nginx). Il progetto include un installer guidato con inizializzazione del database e applicazione delle patch.

La struttura di personalizzazione consigliata segue un percorso documentato: partendo dalle configurazioni di sistema, poi la definizione delle entità di gioco (mappe, luoghi, gilde, lavori, oggetti), fino all'integrazione di moduli personalizzati per meccaniche specifiche dell'ambientazione.

Community e supporto
A breve sarà disponibile il server Discord ufficiale di LoreForge, che raccoglierà in un unico posto:

- discussioni generali sul progetto
- segnalazioni di bug e richieste di assistenza
- guide complete e aggiornate
- annunci di nuove versioni e aggiornamenti

Il link al server verrà pubblicato qui non appena sarà operativo.

Contribuire
Il progetto accoglie contributi su segnalazioni di bug, miglioramenti alla documentazione, e nuove funzionalità allineate con la filosofia del progetto. Le linee guida sono nel file CONTRIBUTING.md.

Chi vuole capire la visione architetturale completa prima di proporre modifiche può leggere description_project.md, che descrive in dettaglio vincoli, pattern obbligatori, e ragionamenti dietro le scelte di design.

Conclusione
LoreForge non pretende di essere la risposta a ogni esigenza. È uno strumento per chi ha chiaro cosa vuole costruire e ha bisogno di un punto di partenza ben strutturato piuttosto che di un foglio bianco.

Se stai pensando di avviare un gioco PbC e non vuoi passare i primi sei mesi a scrivere sistemi di autenticazione, gestione del personaggio e pannelli di moderazione, potrebbe valere la pena darci un'occhiata.

Domande, feedback e impressioni sono benvenuti nei commenti.

LoreForge è rilasciato come progetto open source. Linguaggio principale del codice: PHP/JavaScript. Lingua dell'interfaccia: italiano (localizzazione in roadmap).

29/03/2026 00:35:37

Innanzitutto complimenti per il progetto!
Viste le nomenclature che mi ricordano molto la convenzione Laravel, mi chiedevo se l'engine si basasse su quel framework.

Solo dev, oppure c'è già un core team ?

Per il resto, forse riconsidererei il nome del progetto.
Esiste già un LoreForge: https://loreforge.com/ ↗

In realtà avrei un infinità di curiosità a livello di scelte architetturali, ma per quello aspetterò la release per spulciare con mano!

Grazie per le eventuali risposte e good luck!

29/03/2026 08:52:59

Molto Interessante. Seguirò sicuramente gli sviluppi.

29/03/2026 15:50:08

blancks ha scritto:

Grazie per i complimenti e per le domande dirette!

Sul framework: LoreForge non è basato su Laravel. È un framework custom leggero, un router, un sistema di autorizzazione (AuthGuard), gestione sessioni, un adapter MySQLi e qualche boundary HTTP. Le convenzioni che ti ricordano Laravel (service layer, controller per dominio, model base) sono pattern PHP abbastanza diffusi in generale; in questo caso la scelta è stata deliberata: nessuna dipendenza da un framework full-stack significa meno vincoli sull'evoluzione architetturale e più controllo su quello che gira effettivamente sotto. La dipendenza esterna principale lato backend è Twig, il template engine. Il resto è tutto scritto per il progetto.
È un engine custom con architettura modulare propria, costruito per avere:
- core minimale e indipendente
- moduli completamente opzionali e plug-in
- separazione forte tra runtime, dominio e UI

Quindi alcune scelte possono sembrare familiari, ma sotto il cofano la logica è molto più "module-first" che framework-driven.

Sul team: per ora è un progetto solo-dev. Questo ha i suoi vantaggi (coerenza delle scelte, decisioni rapide) e i suoi limiti ovvi. L'obiettivo con la release pubblica è costruire un piccolo gruppo nel tempo, ma non c'è fretta di allargare prima che il codice parli da solo.
Ad esempio, ho già definito linee guida precise per evitare regressioni sul core e mantenere coerenza architetturale.
L’idea non è tanto avere subito un "core team", ma costruire una base abbastanza solida da permettere contributi senza rompere tutto, cosa che nei PbC storicamente succede spesso. 😅

Sul nome: il punto è legittimo e lo prendo seriamente. Il dominio esiste e appartiene a qualcosa di diverso, è una sovrapposizione che va valutata. Grazie per la segnalazione, meglio saperlo adesso che dopo.
Il naming attuale nasce più come placeholder progettuale (altrimenti continuava a chiamarsi engine-pbc) che come scelta definitiva, quindi è probabile che cambi prima della release pubblica.

Per la parte architetturale: fai benissimo ad aspettare di metterci mano.
È proprio uno di quei casi in cui leggerla non basta: bisogna "sentire" come si comporta il core senza moduli e con moduli attivi.
Alcuni moduli sono già stati sviluppati (6 moduli in totale) che estendono funzionalità e entità già presenti, mentre alcuni aggiungono nuove funzionalità e entità.
In progettazione ci sono altri 11 moduli ma la mia priorità attuale è quella di terminare il debug e correggere i bug ancora presenti nella versione base.
Sottolineo un appunto: i moduli non saranno integrati con la versione di base potranno essere scaricati separatamente.

Se poi vorrai confrontarti su scelte specifiche quando sarà disponibile, mi fa solo piacere, anzi, è il tipo di discussione più utile.

Ci tengo a ribadire che a giorni verrà aperto un server discord dedicato proprio per questo genere di confronti insieme ad altre tematiche inerenti al progetto.

Grazie ancora per il tempo e l’interesse!

29/03/2026 16:19:24

Ottimo lavoro! Non sono uno sviluppatore (vengo dal mondo del design/management in altri campi), quindi non posso entrare nei dettagli tecnici, ma la struttura mi sembra davvero pensata e curata, si vede che c'è del ragionamento dietro. 😊

Sto seguendo il progetto con molto interesse e sono curioso di vedere come evolve.

Buttando lì un'idea random, visto che si stava parlando di un nome: se vuoi mantenere un po' l'anima di quello che avevi già proposto, magari qualcosa tipo GDRForge potrebbe funzionare? Ma è solo un suggerimento, ovviamente tu sai meglio di me dove vuoi andare!

Comunque, ottima direzione - continua così, seguo con piacere e curiosità. 👀

29/03/2026 20:01:07 e modificato da geko il 29/03/2026 20:02:24

thelandshark ha scritto:

Grazie per i complimenti e l'incoraggiamento!

In realtà la questione nome è più delicata di quanto sembri, perché come si faceva notare il nome placeholder che uso ora è di fatto già utilizzato per qualcosa di simile anche se si allontana dal concetto e dall'ambito in cui siamo, comunque crea una dualità soprattutto nelle ricerche.

GdrForge è semplice e intuitivo, carino un po' troppo "italianizzato".
Inizialmente (anno 2022) il progetto si chiamava PbCEngine acronimato come PbC-e semplice, ma molto generico.

Nel frattempo che oggi ho poco da fare in casa e fuori di casa mi sono messo a pensare a dei nomi, ho cercato e tra servizi di AI, servizi di site-builder, aziende nel settore software e servizi analoghi, i nomi che ho pensato sono tutti presi o associati a qualcosa e la dualità è negativa, confonde, tu cerchi qualcosa e ti appare un servizio che non ha nulla a che vedere con quello che stai offrendo.
Ho interrogato GPT che a volte porta buoni consigli e anche lì ogni lista di nomi che proponeva o erano banali o già utilizzati.

Sono arrivato alla conclusione di utilizzare un nome che non abbia un riferimento alla piattaforma in sé ma che sia solo evocativo.
Al momento i migliori candidati non utilizzati in qualche ambito sono:
- Narrion (combinazione con il latino)
- Logion (combinazione con il greco)
- Mythion (sempre dal greco)

Sono convinto che si arriverà a una decisione e a qualcosa che non è ancora stato utilizzato. 😅

29/03/2026 21:34:41

Ciao!

Il progetto è interessantissimo ed appoggio moltissimo il layering e l'architettuta che hai utilizzato (io stesso nel mio codice ho sfruttato un layering simile che poi difatto è lo standard). Leggevo che hai Usato JS Vanilla, hai preso in considerazione l'uso di Lit. Nel mio codice (LiminalCode, pubblicato sulla land di cui sono gestore) mi ha dato un'enorme mano ed è leggerissimo, dacci un occhio!

Ancora complimenti!

29/03/2026 21:59:33

liminal ha scritto:

Ciao, grazie mille per i complimenti!

Come ho già accennato, sto cercando di evitare dipendenze da framework full-stack: meno vincoli, più controllo sull’evoluzione del core e soprattutto maggiore stabilità nel tempo (che per un progetto PbC è fondamentale).

È vero che uso JavaScript Vanilla (ES6+), ma non in modo "grezzo": è strutturato con un’architettura modulare abbastanza rigida (feature → modules → services → componenti), proprio per evitare il classico caos da script sparsi. In pratica cerco di prendere i vantaggi organizzativi dei framework senza portarmi dietro il loro peso o lock-in.

Su Lit: sì, lo conosco e capisco perfettamente il valore, soprattutto per i Web Components. Il dubbio principale che mi frena non è tanto tecnico, quanto progettuale:

introdurre anche una libreria leggera significa comunque fissare uno standard UI nel core
questo potrebbe andare in contrasto con l’idea che il frontend sia estendibile e "sostituibile" tramite moduli

Detto questo, non lo escludo a priori, anzi, potrebbe avere senso come layer opzionale o come scelta per moduli specifici, piuttosto che come base del core.

Se hai esempi concreti su come lo stai usando in LiminalCode, li guardo volentieri 👀

Grazie ancora!

30/03/2026 00:34:54

geko ha scritto: ...

Diciamo che dopo aver letto gli ultimi interventi, e provando ad immaginarmi il quadro generale dietro il progetto, ho diversi dubbi che mi saltano in mente, ma proverò a focalizzarmi su quello che trovo sinceramente più critico.

A chi si rivolge questo engine, esattamente?

Nel thread di apertura si parla sia di sviluppatori che di persone con competenze di base, ma subito dopo leggo una frase che suona in contraddizione:

- Creatori di gioco con competenze tecniche di base, che vogliono concentrarsi sull'ambientazione e sulle meccaniche narrative piuttosto che sull'architettura applicativa.

Non è pensato per chi cerca una soluzione "installa e gioca" con zero personalizzazione. È pensato per chi ha qualcosa da costruire e vuole un punto di partenza serio.

Esattamente cosa si intende quando viene indicato come potenziale target qualcuno "che vuole concentrarsi su ambient e meccaniche narrative" col fatto che "non è pensato per chi cerca una soluzione installa e gioca"?

Basandomi sulle risposte fornite, a me sembra invece che l'intento sia di orientarlo più verso lo sviluppatore consapevole ma, ad essere sincero, vedo problemi anche a cercare di giustificare questa linea di pensiero avendo scelto di non basare l'engine su un framework (o su pacchetti) pre-esistente, dove tutti i paradigmi evidenziati sono garantiti da corpose suite di test automatici oltre ad essere quotidianamente utilizzati da una community di esperti, risultando quindi di provata affidabilità in contesti reali.
Da sviluppatore navigato, un engine completamente custom, anche li dove non servirebbe, non ha una grande attrattiva in sostanza.

Magari ho frainteso qualche passaggio?

In ogni caso, grazie per provato a dare risposta alle mie domande!

30/03/2026 03:33:14 e modificato da geko il 30/03/2026 03:44:41

blancks ha scritto:

Hai centrato esattamente il punto critico, e no, non hai frainteso, è una zona che può sembrare contraddittoria se non la esplicito meglio.

Quando dico che non è “installa e gioca”, non intendo dire che devi mettere mano al core o scrivere codice complesso per farlo funzionare.

Intendo questo:
- il gioco funziona già dopo l’installazione
- ma non è pensato per essere usato “così com’è” senza adattarlo
La differenza è sottile ma importante.

In pratica, i livelli sono questi:
Senza codice (base)
- configuri il gioco (mappe, luoghi, gilde, oggetti, quest, ecc.)
- usi il pannello admin
- personalizzi contenuti e struttura narrativa
già qui puoi mettere online un PbC funzionante.

Con interventi leggeri (target principale)
- modifichi configurazioni più avanzate
- aggiungi o adatti meccaniche tramite punti di estensione già previsti
- lavori in app/ o nei moduli, senza toccare il core
qui sta il “creatore con competenze tecniche base/intermedie”

Estensione avanzata (dev)
- crei moduli
- estendi sistemi esistenti
- integri logiche nuove
questo è il livello più da sviluppatore

Il punto chiave è questo:
1. il core non va toccato per costruire un gioco
2. è stato progettato proprio per evitare quella necessità
Anzi, una delle regole principali del progetto è evitare modifiche dirette al core e lavorare tramite estensioni (moduli, services, hook), proprio per non rompere aggiornamenti e stabilità.

Capisco perfettamente il dubbio che sollevi:
se non è “plug & play” e non è basato su framework standard, come mi oriento?
È una domanda giusta.

La risposta è che LoreForge cerca di risolverla non con un framework esterno, ma con:
- una struttura coerente e ripetibile (controller/service/module)
- documentazione guidata per i flussi principali
- punti di estensione espliciti (non devi “indovinare” dove mettere le mani)

Poi sì, qui c’è una scommessa progettuale:
non avere un framework standard sotto significa che la curva iniziale è diversa, e va compensata con chiarezza architetturale e documentazione.
Ma anche (per citare il framework che hai nominato) Laravel all’inizio era nella sua fase “quello sconosciuto” e a suo modo era grezzo anche se ben strutturato e con il tempo si è evoluto e perfezionato, fornendo documentazione e suggerimenti.
Se vogliamo pensare a LoreForge con un paragone sempre di “casa” Laravel è come se fosse OctoberCMS che utilizza Laravel ma di fatto è una piattaforma per la creazione di applicazioni web.

Sul discorso “attrattività per dev esperti”, sono d’accordo con te:
un engine custom non è automaticamente un vantaggio.
Infatti non sto cercando di posizionarlo come alternativa a framework general purpose, ma come soluzione specifica per un problema molto verticale (PbC), dove il valore è:
- avere già risolto il dominio, non il framework.

In sintesi:
- non è zero-code
- non è neanche “costruisci tutto da solo”
- è un sistema già funzionante che puoi usare subito e poi piegare gradualmente alle tue esigenze, senza toccare il core

Se questa via di mezzo funziona davvero o no… è esattamente quello che sto cercando di validare con questo tipo di feedback

30/03/2026 09:33:55

geko ha scritto:
In pratica, i livelli sono questi:
Senza codice (base)
...

Con interventi leggeri (target principale)
...

Estensione avanzata (dev)
...

Questo adesso è più chiaro: in breve è un po' il concetto alla Wordpress.

Per quanto riguarda la spiegazione sulla parte più tecnica, consiglio caldamente di evitare di far rispondere a chatgpt (o suoi simili). Nel suo solito tentativo di compiacere la richiesta formulata via prompt, scrive una quantità tale di inesattezze e argomenti concepiti male in partenza che risulta davvero scomodo anche per me fornire un feedback onesto e puntuale senza che venga scambiato per accanimento, quando invece vorrei soltanto capirne davvero di più sulle intenzioni dietro il progetto.

Un esempio tra i tanti, per spiegare cosa intendo:

Infatti non sto cercando di posizionarlo come alternativa a framework general purpose, ma come soluzione specifica per un problema molto verticale (PbC), dove il valore è:
- avere già risolto il dominio, non il framework.

Si usa un framework (o anche solo un pacchetto che implementa una funzionalità specifica) per velocizzare una parte che, in ogni caso, è stato comunque necessario sviluppare. E' sì general purpose, ma lo è sui concetti astratti (esattamente come quelli descritti nel post) e non sul dominio, su cui infatti non entra mai nel merito.

Il vantaggio, quindi, è proprio sul fatto che permette di concentrarsi esclusivamente sul dominio appoggiandosi a componenti generici già pronti per quello di cui si ha bisogno. Non è qualcosa che rende difficoltoso lo sviluppo di un progetto specifico, come invece chat gpt vorrebbe far credere.

Se stiamo parlando di una torta di mele, parlare di pere risulta strano e fuori luogo. E' forse il paragone che meglio mi viene in mente per esprimere la perplessità nel leggere questi interventi.

Chiedo scusa per aver sottolineato l'ovvio, ma è proprio questo il motivo per cui invito a formulare una risposta un po' meno guidata dall'IA. Nell'immane wall-of-text di cose generate, inevitabilmente, qualche castroneria di Antaniana memoria finisce sul post.

Grazie intanto per aver chiarito quanto meno il dubbio sul target, che ho davvero apprezzato!