Logeon - Engine per "PbC"

02/04/2026 18:17:43

thetestuser ha scritto:

Devo dirti che tutto è chiarissimo e lo ripeto è tutto davvero molto interessante, si vede che ci hai ragionato parecchio.
In particolare mi hanno colpito l'approccio domain-isolated (ogni estensione vive nel suo dominio) e soprattutto il builder con GrapeJS integrato nel sistema, anche io stavo pensado di fare qualcosa di simile.

Di fatto mi chiarisce molto che il tuo sistema è fortemente config-driven in modo molto avanzato cioè definizione delle logiche di gioco via struttura dati JSON + Builder.

Però ho una curiosità:
Quanto è estensibile quel modello quando si esce dai casi previsti?

Provo a spiegarmi meglio, finché resti dentro il perimetro che hai previsto hai un'enorme flessibilità e sei libero di gestirlo un po' come ti fa comodo, ma se uno vuole introdurre una logica completamente nuova, non prevista dal sistema? Cosa succede?

Qui, secondo me, è la grande differenza tra i due approcci, risultiamo essere due facce della stessa medaglia cioè
- tu punti a dare massima libertà senza usare codice, ma dentro un sistema definito
- io punto a dare più libertà strutturale, ma richiede interventi tecnici quando esci dal seminato
In pratica nel tuo caso il GM costruisce tantissimo da interfaccia, nel mio cosa il GM configura ma quando serve rompere gli schemi può liberamente creare un modulo/custom code

In ogni caso, complimenti davvero per il lavoro che hai fatto, soprattutto sulla parte bulder + configurazione logica, non è per niente banale.

Se in futuro aggiungerai anche un layer che permette di agganciare logiche custom a quelle chiavi JSON, diventa una bomba 😁

03/04/2026 08:06:41

geko ha scritto:

Ti rigiro io la domanda perché non sono nemmeno sicura di aver capito, pensavo di averti già risposto in merito. Quanto è estensibile Lore forge quando esci dalla casistica prevista?

03/04/2026 10:23:58 e modificato da geko il 03/04/2026 11:02:43

thetestuser ha scritto:

È più una domanda retorica che invita a riflette piuttosto che una domanda che vorrebbe una risposta.

Come hai sottolineato per il tuo sistema, hai volutamente bloccato alcuni aspetti dell'estensibilità.

LoreForge è molto estensibile anche fuori dalla casistica prevista, se resti dentro i boundary del core.
In pratica puoi aggiungere nuove logiche.

Dove si estende tecnicamente:

- Backend: nuovi endpoint in custom/routes.php, controller/service dedicati, patch DB idempotenti.
- Frontend: nuove pagine/feature in assets/js/app/features/* e moduli API in assets/js/app/modules/*.
- UI: Twig + componenti riusabili (DataGrid, SwitchGroup, RadioGroup, Calendar, Modal, Paginator, etc...).
- Moduli: se la feature è opzionale, la metti in /modules con module.json, routes.php, bootstrap.php, migrations/.

Esempio reale (fuori casistica standard):
Vuoi introdurre un sistema "Taglia/Crimine" per personaggio, non previsto nativamente.

- Aggiungi tabella character_warrants + log dedicato (patch SQL idempotente).
- Espone API: /warrants/list, /warrants/report, /warrants/resolve.
- In /game mostri badge "Ricercato" nel profilo/location.
- In /admin crei datagrid gestione taglie con filtri live.

Risultato: nuova meccanica completa (DB + API + UI game/admin) senza rompere il core e disattivabile se la isoli come modulo.

03/04/2026 12:53:10 e modificato da brom87 il 03/04/2026 13:09:54

geko ha scritto:
Risultato: nuova meccanica completa (DB + API + UI game/admin) senza rompere il core e disattivabile se la isoli come modulo.

La vera domanda che mi sorge spontanea è, a parte magari nuovi moduli, interfaccia diversa e codice rivisto, cosa offre di diverso da GDRCD? Nel senso, quello che descrivi è possibile farlo anche con GDRCD perchè sono tutte cose che comunque necessitano di un programmatore per essere fatte, altrimenti qualunque cosa ti rompe il sito, anche se non metti mano al core.

Magari offri qualche pacchetto in più, qualche modulo prestabilito, ma tutti devono comunque sottostare ad una lista di moduli e comportamenti previsti a monte dal programmatore se non sei in grado tu di apportare modifiche al codice, almeno che non utilizzi un sistema IA, ma dubito visto che queste necessitano di un piano a pagamento e un grosso dispendio di token.

Quindi in soldoni perchè scegliere LoreForge (nome provvisiorio) e non magari un GDRCD 5.6 o 6 quando uscirà? Perchè ci stiamo girando attorno da 3 pagine ma onestamente non ho ancora capito quali sono le reali migliorie che stai apportando al mondo del GDR. Se possibile usa meno tecnicismi e parla più potabile perchè l'utente medio lo stai ubriacando di nozioni e si sente distratto, non è un buon metodo di marketing e promozione del prodotto.

03/04/2026 13:18:26

brom87 ha scritto: ...

Sto seguendo la conversazione con grande interesse e mi permetto di quotare, visto che il progetto appare super interessante, ma anche a me manca capire perché preferirlo a GDRCD, da parte di un Gestore non programmatore, ed esulando quindi da un tema di preferenza/competenze di programmazione su cui mi sembra si stia iniziando a focalizzare la conversazione.

03/04/2026 13:48:48 e modificato da moderazione il 03/04/2026 14:19:29

brom87 ha scritto: Se possibile usa meno tecnicismi e parla più potabile perchè l'utente medio lo stai ubriacando di nozioni e si sente distratto, non è un buon metodo di marketing e promozione del prodotto.

Concordo.
Anche perché, pure chi mastica nel quotidiano certe terminologie fa fatica a comprendere esattamente cosa stai proponendo e quanto possa essere effettivamente utilizzabile.


Non perché non penso che il prodotto sia interessante eh, tutt'altro! Ma leggo un sacco di giri di parole che rendono difficile estrapolare i concetti utili.

Se posso, ti consiglio di usare meno aiuto da parte di assistenti AI nel preparare le risposte... in modo da riuscire ad esprimere meglio i punti chiave del progetto e le scelte che hai fatto.

Kasa.

03/04/2026 14:44:30 e modificato da pharros il 03/04/2026 15:04:25

Buondì/buonasera, dipende quando leggerete. Ho combattuto molto con me stesso cercando di capire se fosse o meno il caso di rispodere a questa presentazione. Nessuno mi conosce, probabilmente, nonostante io sia iscritto da anni... ma questo perché non sono un tipo molto social, e tendo a non scrivere mai da nessuna parte. Ma in questo caso specifico alla fine ho deciso di offrire qualche spunto di riflessione - benché contenuto.

Ho letto con molta attenzione la discussione e si percepisce chiaramente l'enorme mole di lavoro che c'è dietro.

Tuttavia, benché non mi reputi uno sviluppatore iper affermato e competente - perché non si finisce mai di imparare e ci sono tantissime cose che devo ancora imparare io stesso - vorrei offrirvi degli spunti di riflessione basati sulla mia esperienza pluriennale in questo settore specifico (quello del web dev in generale ma soprattutto dei gdr pbc). Sono mie opinioni e potete buttarle nel cestino, se credete. Anche perché potrei finire per dire un mare di castronerie.

Innanzitutto ho notato una certa sovrapposizione nei termini usati nel corso di tutta la conversazione che è stata fatta sotto la presentazione del progetto: Framework, Engine, CMS... ho visto che già si è creata confusione, e francamente a me LoreForge sembra più un ibrido. Non è né carne né pesce. Troppo specifico per essere un framework (che solitamente non impone logiche e sistemi predefiniti) e richiede troppa competenza tecnica per essere definito come un CMS 'plug-and-play', su vostra stessa ammissione.
Senza contare che definirlo un "engine" è totalmente sbagliato.

Francamente, credo che il rischio a cui il vostro progetto va incontro - come del resto è capitato e capiterà sempre a tutti i progetti di questo tipo nati per i PBC - è quello di scoraggiare tutti quanti: sia lo smanettone di turno, che continuerà a preferire la semplicità di GDRCD (che offre poco, ma ha anche poche pretese a livello di competenze richieste per l'utilizzo, benché sia un pozzo senza fondo di problemi di design e sicurezza), sia lo sviluppatore esperto, che invece preferirà costruire la propria applicazione per conto suo per avere pieno controllo e garanzie di sicurezza a lungo termine, cosa che voi non potreste mai offrire per tutta una serie di motivi che non sto qui ad elencare perché ci metterei tutto il giorno.

Avete, tra l'altro, fatto delle scelte che mostrano il fianco a dei grossi problemi che riscontrerete di sicuro. Per esempio, la scelta di non voler adottare un framework backend mi sembra un errore madornale. Capisco il desiderio di non volere vincoli architetturali, ma oggigiorno i framework non sono limiti, sono garanzie di sicurezza, efficienza ed efficacia.

Affidarsi a standard industriali risolve a monte il problema dell'obsolescenza - del quale il vostro progetto soffrirà, è sicuro al 100% - e della sicurezza e necessità di rilasciare patch costanti - cosa che un framework di terze parti gestisce senza problemi, visto che migliaia di persone lo utilizzano e tantissimi sviluppatori contribuiscono al debugging e al miglioramento.

Una soluzione in-house, per quanto ben scritta, richiederebbe un team dedicato alla manutenzione del core che in una community di nicchia come questa è difficilissimo da metter su e questo porterà il progetto a morire in pochissimo tempo, è un dato di fatto. In tanti ci hanno provato, nessuno è sopravvissuto e non per mancanza di competenze: è proprio la strada peggiore che si possa intraprendere, e ci vuole anche l'umiltà di ammetterlo.

Le soluzioni proprietarie sono ben accette, ma soltanto se sono ad uso personale, didattico o se dietro c'è un team (nemmeno troppo piccolo) che porti avanti la cosa a tempo indeterminato e non penso sia il vostro caso. Come potrebbe? Non so quanti siate, ma so che siete troppo pochi per gestire un progetto di questa entità senza avere un framework di terze parti dietro a coprirvi le spalle su questioni importantissime come la sicurezza & affini. Io stesso, quando ero agli albori della mia carriera e provai a tirar su un progetto simile, alla fine mi resi conto di quanto fosse poco saggia questa strada. Ed è il motivo per cui per i miei progetti lavoro sempre con dei framwork alle spalle. Consolidati, moderni, efficienti e tutt'altro che limitanti.
Chi si fa limitare da un framework è perché non ha competenze, tempo o pazienza di espanderlo in base alle proprie esigenze ed è forse rimasto a 10-20 anni fa da questo punto di vista.

Al giorno d'oggi i framework più moderni danno la possibilità di espandere o rivedere certe strutture proprio perché devono anche adattarsi loro allo sviluppatore, non solo il contrario; è un lavoro di concerto ed è triste vedere che vengono così tanto bistrattati come se fossimo ancora negli anni 2000.

Inoltre, i framework di terze parti danno sicurezza e la possibilità di concentrarsi sull'applicativo di per sé, e c'è anche la consapevolezza che, se un domani viene scoperta questa o quell'altra vulnerabilità, in pochissime ore/un paio di giorni basterà fare un composer update (o qualsiasi gestore di pacchetti si voglia usare) e il problema è risolto. Niente buchi di sicurezza a lungo termine - se non quelli che eventualmente introduco io mentre sviluppo le mie feature, ma quelli sono un problema mio - e niente drammi di alcun tipo.

Lo stesso vale per il non voler adottare un framework frontend o il non voler puntare a crare una SPA... qui credo ci sia un po' di confusione. Chi conosce questo ambito conosce anche tecnologie come il tree shaking, che tutti i framework moderni gestiscono già nativamente e già di per sé questo rende ottimizzati i caricamenti di pagine e moduli (il classico: viene caricato soltanto quel che serve, e ciò che non serve più viene eliminato dalla memoria). Quindi, dire di non voler adottare un framework frontend o di non voler costruire una SPA per i motivi che citate è un po' un ossimoro che non ha alcun senso di esistere.

Ne avrei a pacchi da dire, ma passerebbero tutte come critiche e attacchi. Credo di aver reso l'idea.

A volte si vuole perseguire la strada del purista, ma il buon 80% delle volte queste scelte portano ai peggiori disastri.

Sì, avere dei framework sotto che girano e rubano risorse per fare le loro cose è sicuramente meno performante rispetto all'avere un sistema che gira tutto in plain js, html e css... ma al giorno d'oggi o fai così o fai disastri. Non è che si tratta di competenze, si tratta di efficienza. Puoi essere lo sviluppatore più bravo del mondo, ma nessuno è in grado di stare dietro a tutto ciò che capita al giorno d'oggi nel mondo del web e della sicurezza, delle innovazioni e quant'altro. Affidarsi a terzi, che hanno team dedicati (e a volte enormi), è l'unica scelta da fare. Non c'è nemmeno da discuterne. Gli unici casi in cui si può fare tutto totalmente in-house è a scopo didattico o se devi progettare dei sistemi per delle aziende e hai dei team dedicati esclusivamente a tenere su il progetto attivo e aggiornato per anni già a partire dal core; altrimenti, è soltanto un errore.

Come ripeto, ne avrei a pacchi da dire e il tutto passerebbe quasi come una critica ad un progetto sul quale di sicuro sputate sangue giornalmente e io stesso odierei leggere tutte queste critiche rivolte ai miei progetti - che ovviamente tutto sono tranne che perfetti, ci mancherebbe altro.

Però... a me LoreForge sembra sicuramente un esercizio tecnico notevole, ma temo che gli sviluppatori più competenti preferiranno sempre scrivere il proprio codice che non adottare un sistema che ha così tanti problemi di design già alla base, e i neofiti troveranno la barriera d'ingresso troppo alta rispetto a soluzioni più semplici. Al massimo questo progetto attirerà gli sviluppatori in erba, che vogliono tirar su un gioco di ruolo ma che non hanno competenze o tempo per fare tutto per conto proprio, e che si accontentano di "poco" a livello di implementazioni. E non ce ne sono molti di sviluppatori così, in questa nicchia che sono i gdr PBC. Si trovano gli smanettoni o gli sviluppatori competenti; credo sia difficile trovare la via di mezzo. Anche perché la via di mezzo in genere fa come voi: creano cose in-house e dal canto loro magari (non sto dicendo che è il vostro caso, parlo di come ragiona lo sviluppatore mid level) illudendosi di essere più bravi di tutta la community di laravel o codeigniter o cakephp o react o... chi più ne ha più ne metta, e finiscono per non concludere niente 🤔

03/04/2026 14:45:59

Ho seguito pure io con interesse e curiosità il thread, ma ammetto che l'unica cosa che ho capito è che LoreForge è una soluzione che si propone come alterativa a GDRCD.

Seppur dell'ambito informatico, ammetto che qulche concetto ho fatto fatica a capirlo perché troppo prolisso da farmi perdere il centro del concetto espresso.

Ho dei dubbi, e delle perplessità e te li espongo qui, apertamente anche perchè vedo altri utenti che seguono e forse si chiedono se possono intervenire o meno.

Inizio col dire: Non mi sembra che sia rivolto a un pubblico "agnostico" , anzi. Mi sembra che chi voglia adottare la tua soluzione, comunque debba conoscere la programmazione perché il pacchetto base, avrà delle configurazioni in un perimetro che hai definito tu.
Estendere quel perimetro vuol dire, scrivere codice, script, e pagine nuove.

Il mio ulteriore dubbio è proprio l'assenza dell'uso di un framework (qualunque eh) e tutto il vantaggio che esso ne porta dietro: una documentazione super vasta online, una comunity, un prodotto pluritestato e soprattutto, per gli utenti meno esperti o pratici, dei modelli AI che già "conoscono" il prodotto o il framework che quindi pescano da internet soluzioni qui e lì e le possano macinare meglio per offrire soluzioni "corrette".

Insomma, il fatto di non "dipendere" da un framework e sganciarsi totalmente da ogni dipendenza, secondo me non è un punto di forza, ma una debolezza.
Il tuo codice, seppur organizzato in maniera professionale e corretta, leggibile, sarà completamente custom, anche in quelle parti come security, routing ( e tante altre cose ) e qundi sarà comunque da studiare da zero.
Un utente, non esperto dovrà affidarsi ad una IA e questa non avrà grossi riferiementi online da cui rastrellare portando a possibili strafalcioni (che comunque fanno anche con i framework più famosi eh).

Come dicevo, ho seguito con interesse la discussione , il progetto mi sembra interessante, ma non riesco a capire cosa davvero abbia di appetibile per un Gestore medio che , SENZA conoscenze informatiche, debba usare LoreForge al posto di GDRCD.

03/04/2026 16:01:59

La presentazione del progetto è decisamente più che "potabile": copre in modo completo i contenuti, mantenendo un linguaggio accessibile e riservando il tecnicismo alla sola sezione Architettura tecnica.

Nel resto della discussione, il livello è volutamente meno tecnico: vengono introdotte solo alcune parole chiave, giusto come punti di riferimento.

Quando sono entrato nel tecnico?
Principalmente in uno scambio quasi 1-to-1 con un utente, nel confronto diretto tra progetti.
Capisco che questo possa aver disorientato l'utente medio su questo non posso darvi torto.
D'altra parte, mi è stato anche fatto notare in più occasioni come mancasse un certo livello di approfondimento... incluso quello tecnico.
Diciamo che trovare il "giusto mezzo" è ancora un work in progress😏

Accolgo quindi molto volentieri i feedback e i suggerimenti ricevuti, soprattutto i riferimenti all'utilizzo di tools alternativi: mi stanno aiutando a definire meglio il target.

Per quanto riguarda il confronto tra LoreForge e GDRCD, al momento non esiste una risposta netta alla domanda "perché scegliere uno rispetto all'altro?".
È un po' come chiedere perché scegliere WordPress invece di Drupal o Ghost: la scelta dipende dalle esigenze dell'utente finale e dalla sua percezione, influenzata anche dalle competenze che possiede.

C'è però una differenza sostanziale che rende il confronto, ad oggi, poco significativo: GDRCD è una piattaforma pubblica e consolidata nel tempo, mentre LoreForge non è ancora stato rilasciato.

Di conseguenza, qualsiasi paragone diretto, o l'etichettarlo come "alternativa", potrà essere fatto solo nel momento in cui LoreForge sarà effettivamente disponibile al pubblico.

Colgo l'occasione per ringraziare tutti per il contributo alla discussione e alla presentazione del progetto: il confronto è stato (ed è) estremamente costruttivo e utile.

03/04/2026 18:19:15 e modificato da thetestuser il 03/04/2026 18:22:09

ciao di nuovo, comincio con il rispondere a geko :

Guarda che a me sembra di averti detto che è prevista la possibilità di estendere qualsiasi cosa. Esattamente come hai fatto tu XD cambiano alcune cose? Secondo me, sicuramente si : ma tu non mi hai detto come fai a estendere le logiche [Sono anzi stata io che ti ho detto: è un sistema tipo wordpress, ma in assenza di hook io sono tranquilla. Non c'è nessuna funzione globale da potere chiamare da nessuna parte. Inoltre i miei manifest sono in JSON, e JSON non può eseguire codice].

E' più limitato? Si. Ma relativamente: non vedo cosa dovrebbe volere di più un utente dal sistema che ho messo sopra, così come non vedo cosa si dovrebbe volere di più a livello di funzionalità da un GDR-CD, che mi pare abbia già tutto [e le ottimizzazioni possono solo venire, secondo me, dallo snellimento di processi e miglioramento delle UI e UX]. E' più sicuro? Si. E io voglio la sicurezza? Si.

Colgo la palla al balzo. Siccome è evidente che stai usando un agent per rispondere, ma proprio su ogni cosa, non individuo mezza frase che non mi sembri un agent AI - ma voglio sottolineare una cosa: se anche tu fossi un Vibe Coder non ci sarebbe nulla di male, a maggior ragione quando la tua intenzione è apportare beneficio alla community , e veramente alcune risposte sono un carrozzone di paroloni o inglesismi gratuiti, la cosa migliore da fare sarebbe questa per placare ogni dubbio: che tu condividessi il progetto git di Loreforge, appena pronto, così che si possa vedere il codice.

Perché puoi usare quel che vuoi per metterlo su ma se non ci sai spiegare in parole semplici cosa stai facendo, senza tecnicismi, fai credere a tutti noi - anche se magari non è così - che hai una vaga idea (magari da utente finale) di cosa debba fare il programma e stai lasciando libera di fare la AI. E se non ci sai buttare dentro un occhio, il rischio che sia codice-groviera [più che spaghetti] è alto.

In nessuna risposta c'è stato neppure un: "Il mio fa così, invece GDR-CD fa colà, e i benefici sono questi".

Voglio anche sottolineare che ho avuto da subito l'impressione che le domande che mi hai fatto mirassero a cogliere spunti, e quindi voglio dirti apertamente che per me non c'è problema, o non ti avrei risposto.