Logeon - Engine per "PbC"

30/03/2026 10:19:53

blancks ha scritto:
[quote]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.

[/quote]

Non ho mai affermato che un framework è un ostacolo al dominio, anzi, come stai ribadendo permette proprio di concentrarsi su quello evitando di reinventare ogni volta le stesse basi.
Il punto che volevo far passare e che probabilmente ho espresso male io nel tentativo di sintentizzare è questo:

LoreForge non cerca di sostiutire un framework general purpose, ne di negarne il valore.
La scelta di non basarsi direttamente su uno di essi non nasce dall'idea che "rallentino" o complicano lo sviluppo del dominio, ma da un'altra esigenza più specifica:
avere un runtime già costruito attorno a un dominio preciso (PbC), che resti stabile e indipendente nel tempo.
Un concetto espresso più volte quando mi è stato proposto anche di utilizzare Lit: è stata una scelta arichitetturale.

Quindi non è framework vs dominio ma dominio già implementato + architettura controllata

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

Il paragone con Wordpress in realtà è abbastanza centrato, con una differenza:
Non è pensato come sistema "config-first" ma come base che puoi usare subito e poi estendere in modo progressivo

Sul resto del tuo messaggio, lo prendo come feedback valido anche sul modo in cui sto comunicando il progetto.

Se alcune risposte risultano troppo verbose o poco precise, è un segnale utile:
Significa che devo essere più diretto e meno "astratto" nel raccontare le scelte, soprattutto sulla parte architetturale.
In ogni caso vorrei cercare di mantenere un linguaggio "soft" e sintetizzare alcuni concetti (forse è proprio quello il problema, altrimenti sarei ancora più prolisso) proprio perché voglio che sia LoreForge a parlare per me.

Grazie mille per la tua disponibilità e per il confronto costruttivo.

31/03/2026 14:10:49

Wow seguo! Troppo interessante.

01/04/2026 17:46:18

Molto fico! Anche io sto lavorando a una cosa del genere, anche io ho inziato qualche anno fa. Forse sono andata oltre con l'integrazione di cose, rispetto a un plain "play-by-chat". Anche io ho scelto di non usare ORM o routing framework, più che altro perché rifare tutto mi sarebbe costata un sacco di fatica : ma per altri progetti di lavoro con livewire + blade + laravel, mi sono trovata molto bene. Se avessi cominciato da zero oggi, probabilmente avrei scelto di usare un framework. Il mio progetto si chiama OmniGrid vRPG.

Ho scelto però di non farlo self-hosted [il progetto iniziale lo era, poi ho lasciato perdere] e l'ho trasformato in un "subdomain provisioning" per ogni utenza che attivo sul VPS sul quale ho montato il sistema. E' sempre possibile gestire da interfaccia i DNS delle singole utente per far rispondere domini proprietari e non i sottodomini che si creano automaticamente.

Ho letto che hai usato bootstrap mi pare, anche io: poi ho slittato a tailwind e sto finendo il refractoring per eliminare bootstrap dove lo avevo usato qualche anno fa.

Seguirò con curiosità il tuo progetto!

Keep up the good work

01/04/2026 21:37:58 e modificato da geko il 01/04/2026 21:40:41

thetestuser ha scritto:

Grazie mille!
Molto interessante anche il tuo progetto.

Il passaggio da self-hosted a provisioning su sottodomini è una scelta interessante, soprattutto lato gestione e scalabilità per più utenze.

Piccola nota su quello che hai letto:
non sto usando Bootstrapo il framework UI. Probabilmente hai incrociato il riferimento a bootstrap.php, che però è solo bootstrap applicativo (inizializzazione runtime), non c'entra con https://getbootstrap.com/ ↗

Detto questo, sì: in passato ho usato Bootstrap 4.x per la UI, ma attualmente sto andando nella direzione opposta:
- sto lavorando a una libreria UI proprietaria
- mantenendo solo le icone, Bootstrap Icons, per praticità

Un po' per lo stesso motivo di altre scelte: ridurre dipendenze e avere più controllo sul lungo periodo.

Interessante anche il passaggio che hai fatto verso Tailwind, immagino sopratutto per flessibilità e controllo sul design system.

Se ti va, sono curioso:
- quanto ti ha impattato quel refactor?
- lo rifaresti o con il senno di poi resteresti su Bootstrap?

Grazie ancora per aver condiviso OmniGrid vRPG

02/04/2026 09:31:27 e modificato da thetestuser il 02/04/2026 09:50:23

geko ha scritto: [quote]thetestuser ha scritto:

ah, allora ho letto male! Ho dato una scrollata, poiché un utente di gdr-online mi ha detto "Devi proprio andarlo a vedere" e mi ha mostrato il post qui sul forum: ho letto velocemente [ero anche in orario di lavoro] e mi sono fermata ad a "bootstrap", andando oltre, eheh. Ho creato un account apposta per potere interagire nella conversazione :D

Per rispondere alle tue domande:
- refractoring: guarda, è stata una rottura in partenza. Praticamente chi aveva visto la versione 1.0 mi ha detto "Che schifo, sembra una cosa aziendale" (non che ora sia tanto diverso, ma ha un design più aggressivo-gamer style) e li mi erano venute le fisse sul rifare tutto in modo "meno aziendale". Problema: Bootstrap ha quella pulizia e quella base pensati proprio per la semplicità e l'intuitività dei prodotti "standard", che ritrovi in molte Admin Dashboard e la gente si è abituata ad associarlo al business. Quindi, all'inizio sono partita con VS Code -> replace all delle classi di ogni elemento coinvolto tra quelli che potevo gestire così, come i div, rimpiazzare le card come div con utility classes e quant'altro, ma era una cosa che andava fatta documentazione ft. documentazione alla mano. Da impazzire. A un certo punto ho chiesto tabelle comparative a chatgpt per ridisegnare alcuni elementi principali. Ma comunque non ho tolto tutto, come ti anticipavo, per esempio modal, dropdown e collapse sono ancora di bootstrap, per comodità. Qunidi ho ancora bootstrap nel progetto. Devo valutare se e quando, appunto, terminare la migrazione. A livello operativo, questa cosa non ha riguardato chiaramente le logiche di esecuzione, che sono state pulite [devo dire che avevo già fatto il grosso del backend].

- "Col senno di poi" : allora, domanda da un milione. Bootstrap ha la comodità di avere componenti già pronti [che infatti uso ancora], e di essere super documentato / pieno di esempi etc.. Ma per quello che stavo facendo, che cambia poi direzione anche rispetto al tuo progetto (ad esempio io ho già implementato three.js per la gestione di modelli glb con mesh layerati, anche nel progetto di partenza avevo iniziato test con phaser in isometria che poi ho lasciato comunque, vado in un'altra direzione ibrida col videogioco) volevo un kit personale \ proprietario di tipografia, colori e token da usare come default, senza dovere lottare con i file core di bootstrap e i suoi primary, secondary etc. da dovere forzare ogni volta.
Contro: per non faticare troppo, adesso ho sia tailwind che bootstrap caricati. Risultato: peso "doppio". Bug possibili e difficili da vedere perché in certe pagine ci sono entrambi i sistemi che usano le stesse classi, e puoi avere conflitti. Per questo sto pensando alla migrazione completa, anche se diventa, di nuovo, pesante, perché tailwind non essendo un framework non mi da niente out of the box. E' una lotta tra "originale" (più o meno) + componenti separati (o alla peggio farteli tu), e "bello e pronto".

Io per ora ho scelto originale, poi se non impatta molto - e al momento non mi pare - lascio così, 70-30.

In ultimo: a farlo da zero avrei usato un framework come Laravel con Laravel Reverb, perché mi da pacchetti già pronti utili al caso senza dovere scrivere PDO a mano. Non sono esperta di questo framework ma ripeto, mi ci sono trovata bene usandolo sul lavoro, e oltre al mare magnum di risorse sul web, mal che vada una mano la si può chiedere interattivamente alle AI oggi come oggi, santa cosa.

Sul punto dei subdomains: ho pensato che desse diversi vantaggi.
Il Primo: nessun problema di compatibilità per nessuno. Nessuno degli utenti deve sapere dove andare a configurare cosa sul proprio server \ hosting condiviso.
Il Secondo, non meno importante: istanze condivise. Ho sempre e comunque il controllo su tutto, perché ogni utente-GM condivide la stessa istanza, cambiano i dati visualizzati.
Il Terzo: manutenzione facilitata, per tutti.
Il Quarto: Scalare i servizi a cui voglio fare accedere. C'è chi parte con licensing base free, avrà il pbc, avrà possibilità di creare 1 solo gioco, e così via. C'è chi prende una licenza differente, potrà accedere agli editor 2D delle mappe e dei personaggi, creare 3 giochi e così via. Il database è centralizzato, ma dal pannello superadmin cui ho accesso io posso anche migrare le istanze su database esterni\ separati, a richiesta degli utenti, sempre a seconda dell'accesso ai servizi. E così, anche per il caso del DNS [non voglio mioNome.dominio.estensione, voglio mionome.estensione : faremo rispondere mionome.estensione per caricare la tua istanza, l'utente non deve essere tecnico né toccare le sue configurazioni, venire a chiedere a me di farlo lato server etc. E' stato tutto "frontendizzato"]

02/04/2026 09:53:12 e modificato da brom87 il 02/04/2026 10:08:52

thetestuser ha scritto:

Non credo di aver capito la questione dei sottodomini. Il pacchetto che stai creando non è a "gdr singolo" ma è un motore che ti crea una o più land in sottocartelle del progetto? Una sorta di "fabbrica di GDR", se mi concedi il termine? xD

Per il discorso laravel e framework, io sono abituato ad utilizzarli oltre per la documentazione anche perchè comunque i repository vengono costantemente aggiornati per mantenerli vivi nel tempo e per apportare fix e controlli sulla cybersecurity. Ovviamente questo significa aggiornare composer e vendor all'occorrenza con le nuove versioni e fare gli opportuni test di allineamento, e questo lo fai ad ogni versione del software che stai sviluppando, ma è uno standard ormai farlo. Senza framework significa restare costantemente aggiornati su ogni punto del sistema per correre ai ripari. Come viene gestito questo inconveniente?

Aggiungo anche che lo sviluppo andrebbe utopicamente sviluppato a reparti, quindi con un team. A fare tutto in poche persone si allungano i tempi e si rischia che il lavoro fatto diventi obsoleto in corsa, perchè cambia PHP, perchè vengono trovate nuove falle di sicurezza... E più tempo passa e più può rendersi necessario un reset o rivedere grosse porzioni di codice.

Bootstrap poi lo uso principalmente per avere un aiuto nelle versioni mobile. Senza è comunque fattibile anche questo creando CSS apposito che ragiona in percentuali e vh con i corretti tag media, ma ovviamente necessita di una costruzione da zero che ti offre la possibilità di nominare a piacere le classi e aggiungere variazioni. Alla fine capita spesso anche a me comunque di mettere mano al contenuto delle classi bootstrap per personalizzarle. Usare due componenti "simili" si, fa scattare l'inconveniente che hai descritto, ovvero avere classi omonime che si sovrascrivono a vicenda.

Per il resto aspetto di capire di più su questo progetto, se è come l'ho inteso potrebbe essere molto interessante seguirne gli sviluppi :)

02/04/2026 11:09:07 e modificato da thetestuser il 02/04/2026 11:27:40

brom87 ha scritto: [quote]thetestuser ha scritto:

N[/quote]

Ciao, hai capito bene, il concetto è proprio "Fabbrica di gdr", ma con reparti ben separati :D Non crea "sottocartelle", lancia istanze. I file sono sempre quelli, non viene duplicato niente: tutto il resto è gestito da database.
Io ti creo un sottodominio [un record DNS che risponde al mio indirizzo ip], il motore riconosce CHI sta chiedendo accesso a quella url specifica, e carica di conseguenza personaggi, mappe, regole, utenze di quel GM.


Ho pensato di farlo con questo flusso:
GM Side
Fase 1: utente-GM si iscrive => si attiva la sua istanza => l'attivazione comporta la creazione di un sottodominio (che attualmente è nomeutente.dominio.estensione).
Fase 2: l'utente-GM accede per la prima volta. Ha a disposizione il pannello di controllo per creare N giochi - a seconda di come vorrò gestire il numero di giochi creabili - ciascuno con il proprio sistema.

Player side
Fase 1: l'utente si iscrive liberamente raggiungendo il sottodominio specifico / il GM crea manualmente il giocatore. Il giocatore con la sua utenza != personaggio del giocatore.
Fase 2: il giocatore accede ad un hub, dove sceglie il gioco a cui vuole accedere. il GM può abilitare o meno un player a N giochi esistenti, e quei giochi il player vedrà nel proprio hub.
Fase 3: Scelto il gioco, il player viene reindirizzato al character creator. Dopo aver creato il personaggio, può vedere quanti personaggi ha per quel singolo gioco, e decidere con quale di questi accedere.
Può sempre tornare all'Hub centrale per cambiare gioco e quindi personaggi con cui accedere alla specifica ambientazione.

Sulla manutenibilità: hai ragione, ed è uno dei motivi per cui al momento ho un mio server virtuale dove ho stabile la configurazione. Non avendo un team, e avendo già vecchio codice a disposizione, appunto non ho ricominciato da zero. Mi sono limitata a patchare un codice che già avevo, per capire se potesse funzionare.

Se dovesse diventare un progetto serio, un prodotto "enterprise", non potrei esimermi dal riscriverlo.

Questo è un prototipo, praticamente e, come ho detto a Geko e ribadisco : se avessi cominciato tutto da zero ora, avrei cominciato usando un framework. Ma non avendolo iniziato adesso, ho preferito proseguire con quello che c'era, gettare le basi e poi se va, pensare a regolarizzarlo.

Questo a differenza di Loreforge che (mi pare di aver capito) al momento rimane puro php \ vanilla js. Come WP. Non so se abbia un team dietro, ma in effetti l'unico modo per ovviare al problema di non usare un framework è proprio rilasciare costantemente aggiornamenti e patch [come avviene per WP], che sono anche sempre belli pesanti.

02/04/2026 12:31:02 e modificato da geko il 02/04/2026 13:13:03

thetestuser ha scritto:

Che bello che ti sia iscritta solo per partecipare alla discussione, davvero 😀
Significa che il progetto ha almeno acceso una scintilla, ed è esattamente quello che speravo.

Problema: Bootstrap ha quella pulizia e quella base pensati proprio per la semplicità e l'intuitività dei prodotti "standard", che ritrovi in molte Admin Dashboard e la gente si è abituata ad associarlo al business.

Capisco perfettamente cosa intendi, ed è vero: Bootstrap si porta dietro quell’effetto "dashboard aziendale".

Io, nel mio caso non lo vedo come un problema o come un limite, anzi, al contrario, la vedo come un'opportunità.
Preferisco partire da qualcosa di molto standard, leggibile e prevedibile piuttosto che spingere subito su un'identità grafica forte.
Offro un prodotto ben progettato e ordinato, questo non da effetto "wow!" all'utente "giocatore" ma da un senso architetturale a chi ci mette mano, a chi, almeno, ha conoscenze tecniche di base.
Perché il focus principale non è la UI, ma il dominio.
Poi sopra quella base puoi stravolgere completamente l'aspetto oppure sostituire progressivamente la UI (come sto facendo io).
Il fatto che sia modulare va proprio in quella direzione:
non voglio imporre uno stile, ma dare una base solida su cui costruire.

Se poi con il tempo l'utenza di chi utilizza o vuole utilizzare il progetto insiste posso iniziare a pensare di implementare 2 o 3 temi alternativi, o addirittura l'utenza stessa che vorrà contribuire, potrà farlo e deciderò se implementarli nella base come alternative in fase di setup.

Quindi, all'inizio sono partita con VS Code -> replace all delle classi di ogni elemento coinvolto tra quelli che potevo gestire così, come i div, rimpiazzare le card come div con utility classes e quant'altro, ma era una cosa che andava fatta documentazione ft. documentazione alla mano. Da impazzire.

Ti capisco fin troppo bene 🙃

Ci sono passato anche io quando ho iniziato a staccarmi da Bootstrap.
all'inizio ho fatto esattamente quello che descrivi: una ricerca per sostituire tutte le classi di Bootstrap con replace massivi, override e tentativi di adattare componenti già esistenti.
Alla fine ho cambiato approccio, ho optato per la soluzione più facile e immediata: mantenere il naming bootstrap-friendly e invece di "romperlo", ho iniziato a mimarne le convenzioni e costruire sopra un mio layer compatibile.
Quindi stesso tipo di naming, stessi pattern mentali ma con un'implementazione totalmente mia.
All'inizio era solo un override ma adesso sta diventando una sostituzione progressiva.
Bootstrap è ancora lì in parte, per il 20% circa, ma sempre meno centrale e sempre più marginale.

La differenza, forse, sta qui:
tu sei partita dalla UI e l'hai dovuta rifare per adattarla al progetto, mentre io sono partito dal dominio e ho lasciato volutamente la UI "neutra".
Perché quello che voglio evitare è quello di dare un sistema bellissimo visivamente ma difficile da modificare e preferisco dare un sistema "sobrio" visivamente ma facile da smontare e ricostruire.

Questa cosa tra l'altro è abbastanza allineata con quello che succede realmente nei PbC:
- il core viene mantenuto quasi intatto
- vengono aggiunte alcune funzionalità ma non sempre
- re-naming di alcune entità (es. razze come etnia, gilde come casate etc...)
- l'interfaccia viene stravolta completamente la maggior parte delle volte

Sul resto del tuo progetto, devo ribadire che è una direzione molto interessante.
Se ho capito bene stai andando verso un modello quasi SaaS, più che self-hosted puro ed ha senso:
- abbassi quasi completamente la barriera tecnica
- centralizzi manutenzione e aggiornamenti
- puoi costruire anche un modello di licensing sopra
È una strada completamente diversa dalla mia.

Io per ora sto volutamente sull'approccio opposto, self hosted + controllo totale per l'utente finale, ma non escludo che in futuro possano convivere entrambe le modalità.

Inoltre leggo come descrivi il tuo modello subdomain + licensing e se ho capito bene stai andando verso un approccio più "servizio centralizzato", con accessi e funzionalità scalate per piano.

Nel mio caso sto andando in una direzione un po' diversa, quasi opposta.
LoreForge di base è completamente open-source e gratuito e chi lo usa ha pieno controllo sull'istanza.
Poi sopra questo alcuni moduli sono gratuiti, altri sono a offerta libera (tipo: offrimi un caffè se vuoi dare un supporto al progetto), altri invece saranno a costo fisso, ma solo per quelli con funzionalità più avanzate e che hanno richiesto uno sviluppo importante.

Se ti va, una cosa che mi incuriosisce davvero:
- quanto controllo lasci all'utente finale sull'estensione del sistema?
- può creare logiche sue o è più "config-driven"?

Ti ringrazio per la tua risposta e per il contributo che stai dando per costruire questo confronto in questa discussione e presentazione del progetto.

02/04/2026 13:45:42 e modificato da geko il 02/04/2026 13:48:05

brom87 ha scritto:

thetestuser ha scritto:

Nel frattempo che scrivevo per rispondere e ho risposto a una chiamata ci sono state una "sovrapposizione" di risposte e di scambi alla quale mi sento di dare anche io una risposta, per quello che riguarda LoreForge

Domanda assolutamente sensata, ed è probabilmente una delle criticità più importanti quando uno decide di non appoggiarsi a un framework.

Framework come Laravel offrono un vantaggio enorme lato manutenzione, perché hanno una community attiva, riceve patch costanti e centralizza molti aspetti di sicurezza.

Detto questo, il problema della sicurezza non sparisce usando un framework, viene "spostato" perché devi comunque aggiornare, testare e verificare compatibilità ad ogni rilascio e soprattutto: molte vulnerabilità nascono nel codice applicativo, non nel framework.

Nel caso di LoreForge la gestione è impostata in modo diverso, ma non lasciata al caso:
- il core è volutamente ridotto e controllato, senza dipendenze esterne critiche
- i punti sensibili (auth, sessioni, accesso DB, validazione) sono centralizzati e non sparsi
- l'autorizzazione è sempre server-side su ogni endpoint
- non esistono scorciatoie lato client che possano bypassare controlli
Questo mi permette di avere meno superficie "esterna" da aggiornare e più controllo diretto su quello che succede nel runtime.

Utopicamente si, ti do ragione, dovrebbe esserci un team che sviluppa un prodotto, realisticamente ho scelto di essere solo io con i suoi pro e i suoi contro, ne sono consapevole e l'ho affermato in discussioni passate.

Proprio per questo sto terminando la configurazione del server Discord che sarà un fulcro centrale per la community di LoreForge.
L'idea è che il progetto non resti "chiuso", ma che possa anche crescere con contributori esterni nel tempo e perché no un ampliamento del team.

Quindi per rispondere direttamente a TheTestUser:
Io sono solo-dev come lo sei tu, per quello che mi è parso di capire e si, io ho scritto tutto con PHP e JavaScript Vanilla con la scelta di adottare un'architettura strutturata.

02/04/2026 14:12:16 e modificato da thetestuser il 02/04/2026 14:12:54

geko ha scritto: [quote]thetestuser ha scritto:

Se ti va, una cosa che mi incuriosisce davvero:
- quanto controllo lasci all'utente finale sull'estensione del sistema?
- può creare logiche sue o è più "config-driven"?

[/quote]

Cerco di risponderti nel modo più puntuale possibile:
Libertà degli utenti sull'estensione del sistema
Ho pensato anche io - proprio ispirandomi a joomla o wordpress - di consentire il caricamento di alcuni plugin. Ciò che ho fatto per salvarmi la salute è procedere - e credo l'abbia fatto anche tu - e gestire tutto per domini. Ho un registro moduli fatto similmente a wordpress (ma più semplice, perché io non ho creato hook), per come è stato pensanto. Ma quello che è possibile manipolare è limitato, anche perché voglio evitare il caricamento di immondizia \ codice potenzialmente fragile o pericoloso. Per questo, tra l'altro, ogni estensione è indipendente: riguarda uno specifico dominio [es. Gioco, Classi, Razze] e non parla con nessun altro dominio del sistema.

Ulteriori libertà:
Ho integrato grape.js e modificato il funzionamento affinché sia possibile per i GM costruirsi con un builder drag & drop, che contiene gli elementi attivi del sistema (area di gioco, utenti online, messaggi, scheda del personaggio, sottoelementi della scheda) la grafica che vuole in liberà;
C'è un importer che consente il caricamento massivo dei dati, con ovviamente lo step della mappatura manuale csv-xlsx, per evitare la rottura di creare tutto manualmente

Configurazione:
il GM può creare quel che gli pare, col sistema che gli pare. Può creare quanti tipi di punti vuole [mana? sangue? Due sistemi di punti esperienza?] decidere come distribuirli [collegati a razze? classi?] e come vengono calcolati [nel caso dei punti esperienza: stai giocando via chat? Si\No. Si => per messaggio inviato? Per numero di parole? Per numero di caratteri? No => Stai giocando con la mappa creata con phaser? => il Gm può creare mostri nel bestiario, e decidere in quali punti della mappa farli spawnare, con quale frequenza, e quanti punti assegnano].
Non voglio le classi, creo i mestieri, posso? Si, puoi. Non mi bastano razze, classi e mestieri, voglio avere la discendenza come entità? Posso crearla e attivarla nel gioco.

Logiche alternative:
il GM può creare ciò che gli pare, come homebrew etc Lo fa tramite interfaccia appunto, ma tutto è gestito da un JSON che configura poi il gioco. E' possibile anche editarlo e aggiungere nuove chiavi e relativi valori, anche se al momento non supporto ancora la logica che interpreta nuove chiavi e crea nella UI i campi dedicati.