Alternative al GDRCD

18/01/2014 15:43:37 e modificato da ilgrandeinverno il 18/01/2014 16:08:57

Premettendo che, per non fare confusione, sarebbe stato meglio specificare che si sta parlando, immagino, di GDRCD 5.x dal momento che sono ancora in circolazione land che utilizzano il vecchioo GDRCD Extreme di MrFaber.

Dal punto di vista tecnico non c'é discussione. Blancks ha detto più o meno tutto quello che c'era di sensato da dire. A mio parere Accent aveva le potenzialità per essere una valida alternativa ma dal momento che sviluppo e supporto sono cessati, Accent ha fatto più o meno la fine di OS/2 Warp di IBM.

Ottimo sistema operativo, che avrebbe dato le mele, come si suol dire, a Windows, ma ... un binario morto. Se si parla di pacchetti per l'utente finale la manutenzione e l'aggiornamento costante del codice sono quello che fa la differenza tra un prodotto di successo ed uno destinato a finire, appunto, sul binario morto.

Quando iniziammo lo sviluppo di IGI Accent era agli albori, GDRCD 5.x non c'era, e le alternative valutabili erano GDRCD Extreme e RpgEngine.
Valutabili, significava avere la consapevolezza che in un caso e nell'altro non sarebbe bastato "personalizzare" il pacchetto ma sarebbe stato necessario:

a) installare vagonate di patch antibug e provvedere manu propria a correggerne altri per i quali non esistevano patch e sempre col terrore di "manomettere" qualche oscuro parametro o funzione piazzato a mo' di "toppa" qua o la senza alcun commento o esplicitazione della sua funzione.

b) fare lavori enormi di adattamento per implementare la meccanica di gioco che avevamo in mente e che si discostava nettamente dagli strumenti messi a disposizione dai pacchetti OS scaricabili dal portale.

Sono bastate poche settimane di lavoro su GDRCD per renderci conto che era un'impresa dispendiosa e disperata e che per quante implementazioni potessimo fare saremmo comunque (problemi di sicurezza a parte) rimasti sempre prigionieri della logica di fondo e della struttura di base di GDRCD.

Di qui la scelta di passare a un progetto basato su codice proprietario.

L'allenamento su GDRCD Extreme é stato utilissimo. Una volta, scherzando, dissi che GDRCD Extreme era, per un aspirante programmatore, l'equivalente del "puttan-tour" che nei ruggenti anni 50-70 i buon padri di famiglia facevano fare ai figli alle soglie della maggiore età per svezzarli.

A conti fatti, anche oggi che c'è sul mercato un prodotto molto più affidabile, elastico e soprattutto ben mantenuto come GDRCD 5, la scelta per noi sarebbe per il codice proprietario.

Non perchè ci sia qualcosa di romantico nel fare di mano propria (c'è, è innegabile, dal punto della soddisfazione personale) o perchè si pensi di poter fare meglio (soprattutto se il programmatire è un autodidatta mentre lo sviluppatore dell'OS é un programmatore professionista), ma per i limiti che qualunque OS (che sia un forum, un blog, un CMS, un pacchetto per e-commerce o di gestione di wiki, o un cms per comunità virtuali) porta con sè.

Alla fine la valutazione da farsi é solo una: la "personalizzazione" quanto incide e quanto va a cambiare il "pacchetto base"?

Se va a cambiare poco o ad aggiungere due o tre tool che su GDRCD puoi aggiungere facilmente senza stravolgerne la struttura, é stupido e antieconomico costruire da zero le basi. Il principio della riutilizzabilità del software é sempre valido.

Se viceversa le implementazioni vanno a stravolgere radicalmente il "pacchetto base" e richiedono un lavoro enorme di messa a punto per le implementazioni che si hanno in mente, si può (anzi si dovrebbe) valutare la costruzione da zero di un sistema proprietario.

Perchè alla fine tra lo studiare a fondo il pacchetto OS che si vuole usare (anche un OS ben mantenuto e soprattutto ben documentato come GDRCD 5.x a differenza dell'augusto predecessore 3.x) e l'adattarlo a ciò che si ha in mente, e il costruire da zero il motore di gioco sapendo quindi per filo e per segno tutto quello che ci metti dentro dal momento che l'hai costruito tu, tempi ed energie finiscono per equivalersi. Almeno, nel nostro specifico caso sarebbe stato così.

Il problema di qualsiasi OS (ribadisco non parlo del solo ambito CSM per play by chat) é che nel momento in cui inizi ad utilizzarlo resti più o meno "prigioniero" della sua logica, per quanto tu possa lavorarci sopra. E se hai bisogno - nel caso del PbC - di staccarti nettamente dalla meccanica di gioco che va per la maggiore, partire da un OS "buono per tutti" potrebbe non essere la scelta migliore.

Vantaggi e svantaggi del costruire un motore proprietario poi si misurano con la bilancia, quotidianamente.

Nel caso dell'utilizzo dell'OS puoi contare su patch e plugin prodotti e mantenuti a livello centralizzato. Più o meno, eh? Insomma non facciamo finta che il sistema dei download di gdr-online sia l'equivalente di sourceforge. Ma c'è comunque una fonte alla quale rivolgersi.
Trasferisci, in pratica, parte del lavoro di manutenzione e miglioramento del codice, esternamente al tuo team gestionale. Se hai un problema che non riesci a risolvere hai dozzine di altri gestori che usano lo stesso pacchetto e che volendo, qui, possono darti dritte e consigli anche se Blankcs parte per le Maldive e sta via 3 anni.

Nel caso del motore proprietario conosci (si suppone) alla lettera, riga per riga, quello che hai fatto e se hai lavorato decentemente, puoi fare tutto in casa. Ti sobbarchi anche tutti i rischi in prima persona perchè se sbuca un bug non hai neanche nessuno con cui prendertela e nessuno da insultare se non te stesso. E se ti serve una mano dall'esterno coinvolgendo altre "risorse" per la manutenzione e sviluppo del codice, non puoi avvarlerti di collaboratori esterni che magari conoscono l'OS in questione ma davanti al tuo motore di gioco dovranno imparare tutto da zero prima di poterci mettere le mani.

Quindi è abbastanza ovvio che se punti sul motore proprietario (soprattutto se come nella maggior parte dei casi non sei un programmatore professionista) conviene valutare bene; conviene comunque studiarsi bene uno o più OS per farsi un'idea precisa dei problemi che potresti daver risolvere; conviene non mettercisi neanche se si sa già che si passerà più tempo sul forum di gdr online a domandare che differenza c'è tra il fare una SELECT usando "WHERE ID=XX OR ID=YY ... OR ID=ZZZ" o usando "WHERE ... IN (XX,YY,...,ZZZ)" o chiedendo come mai arrivano messaggi d'errore ogni volta che un utente invia in chat una frase con un apostrofo o un paio di virgolette.

Le valutazioni sulle land fotocopia sono altre, e non dipendono certo da GDRCD. GDRCD é uno strumento messo a disposizione. Se chi decide di usarlo é convinto che una land si costruisca buttando giù due righe di ambientazione minimali giusto per non essere accusati di plagio dal gestore di una land già esistente, installare GDRCD cambiando un po' i CSS e poi iniziando il betatest... beh quello é un limite degli aspiranti gestori.

E, azzardo, un limite del portale, che forse prima di offrire spazio a nuovi progetti, potrebbe pretendere qualche verifica di affidabilità in più, perchè credo che sia innegabile coi tempi che corrono, che l'offerta mostruosa di giochi "attivi" anziche essere un valido esempio del principio di qualità e selezione naturale indotta dalla libera concorrenza, rappresenta invece una dispersione e un pugno in un occhio di qualunque VERO niubbo del genere, che magari prova 5 o 6 land "fotocopia" da 3/4 utenti online e dopo tre giorni si stufa dell'intero genere e torna a giocare a Skyrim.

Con tanti ringraziamenti ai gestori che non si pigliano manco 5 minuti di riflessione prima di scaricare GDRCD, installarlo su altervista e mettere la land sul portale annunciando il betatest della NUOVA land che rivoluzionerà il panorama del pbc in italia e nel mondo.

Ma non oso immaginare in che modo e da chi dovrebbero essere fatte queste valutazioni imparziali e attendibili (cortesemente, niente suggerimenti bisclacchi sull'imparzialità dello staff), quindi sospetto che ci terremo le dozzine di land fotocopia. Ma darne la colpa a GDRCD é miope. Anzi... is futile.

{Ghennadi of Borg}

---

quota

18/01/2014 16:06:44

Infatti non "riporto", dico quello che mi piacerebbe. E sono consapevole che fa a pugni con la "politica" del portale, più volte esplicitata da Gianluca. E, a conti fatti sulle risorse disponibili, purtroppo e mio malgrado non posso che concordare con gianluca sull'infattibilità della cosa.

La politica è l'arte del possibile.

---

quota

18/01/2014 16:14:08

Il discorso di darkabe è comprensibilissimo se la si vede dall'ottica di un programmatore.
Dall'ottica di un utente medio che utilizza il gdrcd per un progetto no, perché una programmazione ad oggetti è molto complessa da capire se si è alle prime armi e il vantaggio attuale di gdrcd 5.x è quello di essere facilmente comprensibile a patto di sottostare alle sue logiche di sviluppo il che, se sai di non essere un programmatore esperto, fa da ottimo tutor che ti guida nella creazione del codice che ti serve (il famoso "guardo una pagina simile per fare una cosa che mi serve").

La programmazione ad oggetti invece ti fa scrivere e sfruttare i neuroni più intensivamente in un primo momento ma tutto a vantaggio della manutenzione o implementabilità futura del software.

Queste sono esigenze che capisco e come ho scritto nel mio precedente intervento (ma soprattutto come ribadisce Ghenna) se si hanno altri bisogni/necessità/esigenze o lo strumento non offre quello che ti occorre è naturale ponderare altre strade, puro e semplice.

In ogni caso, è ovvio che ogni progetto CMS avrà una sua logica di sviluppo, soltanto ci sono quelli sviluppati da team di persone che ti offrono un vero e proprio framework alla base che ti permette anche di adottare logiche differenti per lo sviluppo di un applicazione che vi ci si basa e poi ci sono progetti più amatoriali come GDRCD che, gestito nel tempo da vari volontari, è difficile riesca a raggiungere un simile obiettivo, se non con un lavoro di riprogettazione alla base fatto come si deve (ci sarebbe GDRCD6, ma al momento finché me ne sto alle maldive è in stop; Ghenna ti sei giocato il biglietto gratuito che ti volevo mandare).

Per il resto, in linea generale, concordo col Borg.

---

quota

18/01/2014 16:29:07 e modificato da ilgrandeinverno il 18/01/2014 16:32:20

Azz, brutta storia il biglietto saltato -____-

Comunque da programmatore non professionaista, mi sento di ribadire un punto. Costruire un motore di gioco proprietario, specie se non si é programmatori professionisti, é un impegno mostruoso dal punto di vista del tempo e delle energie, intermini di sviluppo, manutenzione ed avanzamento del codice.

Valutare troppo alla leggera di imbarcarsi nella costruzione di un motore proprietario può fare imboccare un vicolo cieco anche peggiore di quello del CMS poco adattabile alle proprie esigenze.

Onestamente non si dirti, Blancks, cosa avrei fatto se fossi partito oggi avendo a disposizione GDRCD 5.x
Sospetto che alla fine avrei puntato comunque sul proprietario, o comunque su un "fork" di GDRCD 5, magari "riciclando" abbondanti porzioni di codice.

Perchè comunque guardando al mio codice con un occhio spassionato, a distanza di 5 anni dall'inizio dello sviluppo, per quanto ogne scarrafone é bello a mamma soje... certe volte mi fustigherei da solo. La mia impostazione da programmazione strutturata (te lo dissi, no, che la mia "scuola" fu Turbo Pascal?) si vede e si sente, per quanto gradualmente stia correggendo delle storture e delle ingenuità fatte all'inizio dello sviluppo.
Ma tanto per dirne una sto tremando all'idea che in futuro le librerie mysql vengano definitivamente accantonate in favore delle mysqli. E sto già correndo ai ripari. In questo se mi fossi "attardato" di più e mi fossi imposto qualche mese di studio in più, ora avrei le cose molto più facilitate e meno patemi 😶

Alla fine al giocatore importa poco che la land sia sviluppata usando i paradigmi della programmazione strutturata o quelli della OOP, o che siano utilizzati i principi del MVC o di sapere se e quali framework sono stati utilizzati nello sviluppo. Ma credo che se programmare non fosse anche una passione avrei gettato la spugna, quindi torno a ribadire:

Imbarcatevi nella costruzione di un motore proprietario se e solo se GDRCD non può essere ragionevolmente adattato alle vostre esigenze.

Oppure se avete qualche perversa forma di masochismo e se per voi la soddisfazione di aver costruito qualcosa di funzionante da zero vale più delle ore di fatica, delle capocciate contro la tastiera e delle frustrazioni davanti a un vicolo cieco imboccato che vi costringe a tornare indietro e fare tutto daccapo.

---

quota

18/01/2014 17:07:26 e modificato da ilgrandeinverno il 18/01/2014 17:11:14

Concordo anche con spykes.

Soprattutto nel marcare la differenza tra un OS per pbc e un cms stile wordpress, joomla, phpbb, drupal, magento ecc, e il come l'aspirante smanettone nonchè gestore di un pbc si pone davanti ad essi.

Facciamo un esempio pratico. Forum o bacheche che dir si voglia. Esistono dozzine di forum scaricabili, più o meno complessi e articolati per gestione dei livelli di accesso e via dicendo. Il tal gestore ha bisogno di rivedere il suo vecchio sistema di bacheche.

Beh, fico no? Mi scarico phpBB o miniBB e li integro nel gioco.
Fichissimo sulla carta e indubbiamente all'altezza dei sacri principi di riutilizzabilità del codice e di non reinvenzione della ruota.

Al pratico?

Al pratico le cose non sono così semplici. Perché il phpBB/miniBB che dir si voglia ha la sua logica, il suo sistema di gestione dei permessi e non sa un tubo di quello che serve a te. A partire dall'integrazione della base utenti e finendo con la gestione dei permessi. Sì sì, anche quei forum permettono la creazione di gruppi di utenti quindi volendo puoi forzarli a considerare le tue gilde/clan/corporazioni come gruppi e trattarli come tali nel passaggio al forum.

Ma poi quanto ci metti a livello di adattamento? A livello di gestione degli accessi. A livello di modifiche che devi fare per accordare il sistema di ingressi nelle corporazioni della land col sistema di ingresso nei gruppi di miniBB?

Conosci miniBB o phpBB così bene e così intimamente da essere sicuro di poter integrare i due sistemi senza che qualche famigerato hacker turco specializzato nello sfruttare i bug di phpBB possa entrare e piallarti la base utenti della land?

Come ti comporterai e cosa ti comporterà cambiare, una volta fatta l'integrazione, quando uscirà la patch 2.3.56.XYZ del forum OS che hai usato e dovrai di nuovo, daccapo, intervenire sul codice del forum (modificato dalla patch) per riadattarlo alle tue esigenze?

Peggio: domani il gioco richiede un nuovo sistema di categorizzazione dei personaggi e, di conseguenza, un altro sistema di gestione dei permessi: se ti sei legato mani e piedi al forum OS, quanto tempo dovrai metterci a riadattare di nuovo tutto?

La riutilizzabilità del codice e l'utilizzo di pacchetti OS prefabbricati ha anche degli svantaggi, o meglio dei prezzi, che chiunque dovrebbe valutare attentamente prima di decidere di usarli.

---

quota

19/01/2014 03:33:46

IGI è un pacco di funzionalità complesse, penso che per quel che ho visto quando ci sono stato dentro probabilmente ti sarebbe stato utile soltanto il core di gdrcd 5.x, il file functions, come framework di partenza base.

Grazie a varie accortezze è quello che ti permette di mantenere e avanzare il codice con comodità (un esempio è quando ho introdotto il layer di astrazione per il db nella 5.1 per sostituire le chiamate dirette alle funzioni di mysql, che poi nel 5.2 ho converito interamente a mysqli sostituendo poche righe di codice)

In sintesi, la sostanza di un buon codice si vede principalmente dallo sviluppo del suo nocciolo: se questo è ben ragionato sarà difficile incappare in quei punti ciechi di cui parli, se invece non si ha ben cognizione di come progettare un simile applicativo, il rischio di cestinare e rifare tutto da capo è molto alto e se si persiste, si potrebbe arrivare ad ottenere un codice si difficile da mantenere ed implementare.



(Si, ricordo)
Seguo le mailing list di php.net da diverso tempo, fu proposto di eliminare completamente il supporto a mysql nelle release che sono uscite negli ultimi mesi ma sembra che invece abbiano posticipato la discussione del problema per php 6, così da dare ulteriore tempo prima di troncare definitivamente il supporto ad una libreria che per molti anni è stata utilizzata dagli sviluppatori.
Il punto comunque è che mysqli è oggi semplicemente l'estensione più aggiornata e permette di rendere più sicuro il proprio codice grazie ai prepared statements e altre implementazioni.

Ecco, parlandone mi è venuta in mente anche un altra questione.
Ultimamente ho visto molte persone continuare ad utilizzare gdrcd 5.1 scaricato dal portale per i nuovi progetti, alcuni mi hanno detto di preferirla alla 5.2. Non fatelo.
GDRCD 5.1, per quanto alcuni bug verificatisi siano ormai stati corretti, presenta comunque altri problemi minori o procedure che la versione 5.2 corregge e migliora (esempio: il passaggio di mysql a mysqli), di conseguenza vi invito a scaricare la 5.2 se state ponderando di creare un nuovo progetto, offre sicuramente di più.



In linea generale sono d'accordo con te, spyker, è però indubbio che la costruzione di un sorgente simile possa giovare non poco al progetto in sè, perché permetterebbe tutta una possibilità di mantenere, aggiornare e sviluppare patch/plugin per l'engine a livelli che prima erano impensabili oltre ad avvicinare un parco di programmatori più esperti al progetto (con la possibilità di ottenere più feature di qualità).

Sicuramente, a quel punto uno smanettone medio potrebbe trovare difficile alterare le logiche che sono alla fondamenta della struttura, ma con un pò di abilità nello sviluppo dell'engine si può cercare di costruire il sorgente di modo che per l'utente sia più semplice operare determinati tipi di modifiche come quelle riguardanti il layout e la formattazione html/css in generale, oltre all'uso di javascript vario permettendo magari la totale personalizzazione grafica senza saperne un'H di PHP.

E' un tentativo che cercheremo perlomeno di sviluppare con GDRCD6, senza però interrompere la continuità delle versioni 5.x

---

quota

25/01/2014 11:18:13

W gdr-cd u_u/

---

quota

25/01/2014 11:25:41

Se doveva essere l'ennesimo tentativo di trolling, haedium, lasciatelo dire: stai perdendo colpi!

---

quota

25/01/2014 14:30:11

... pant

Che delirio.

Ho terminato di rintracciare tutte le chiamate dirette alle funzioni mysql che erano rimaste "appese" dai primi tempi e negli script più vecchi, creati all'inizio, prima che iniziassi a usare una funzione personalizzata delle funzioni che accedono al database @_@

Al momento della migrazione a mysqli* sarà sufficiente ritoccare due soli file -___-

Ecco cosa vuol dire costruire una land con motore proprietario se si é, come diceva spiker, lo "smanettone" con una (almeno) decente conoscenza di php ma privi di una preparazione professionale alla gestione di un progetto di medie dimensioni e, come avviene di solito, privi di una solida preparazione nell'uso della programmazione ad oggetti.

Nella migliore delle ipotesi: scaricatevi GDR-CD (5x) e studiatevelo prima di mettervi a scrivere codice.

Nella peggiore: usatelo.

A meno che non siate masochisti.

---

quota

Role Players Community

Intervista al gestore di Role Players Community il servizio gratuito di creazione di GdR Play By Chat!

Loot Box

Loot Box nei giochi online: 15 paesi vogliono regolarizzarle: scopriamo i retroscena!

Psicologia PG

La Psicologia dietro i Personaggi: come creare una profondità emotiva

Shannara

Recensione del GDR ambientato nel mondo creato da Terry Brooks