Gdr non GdrCd

18/09/2014 12:25:47

A livello di grafica giocando semplicemente con i css specie i css3 e con qualche minima modifica si possono fare le stesse cose di chi usa codice proprietario. Anche qui non è questione dei gdrcd o non gdrcd ma di come uno lo utilizza.

A livello di funzioni anche li dipende da quanto uno ci lavora.

quota

18/09/2014 23:29:19

Come già è stato scritto nelle pagine precedenti, un'affermazione del genere è totalmente falsa, perchè il problema non è l'utilizzo del GDRCD, ma la poca fantasia dei gestori che usano la piattaforma tutti nel medesimo modo - arrivando in alcuni casi perfino al plagio della grafica e di quant'altro.
L'esempio è sempre quello: se entrambe usiamo WordPress e nessuna delle due cambia il tema lasciando quello di default, la colpa di chi è?
Di WordPress o di noi due che non abbiamo cambiato il tema avendo, di fatto, due siti fotocopia per quanto riguarda grafica e funzioni?

Per le modifiche grafiche, poi, quoto in toto dyrr: con i CSS, specialmente i CSS 3, si possono fare delle cose spettacolari. Ci vuole solo un po' d'impegno. Non è niente di così complicato come possa sembrare.

Stessa cosa per le funzionalità, anche se in questo caso il discorso è un po' più complicato perchè ci vogliono sia la conoscenza del PHP che un minimo studio della struttura del GDRCD.
È innegabile che vi sono delle restrizioni - specialmente per quanto riguarda le bacheche, che sono ben lungi dall'essere equiparabili ad un vero e proprio forum - ma mettendocisi d'impegno si possono ottenere dei prodotti che sono estremamente originali.
Tutto sta a cosa vogliono ottenere i Gestori.

Insomma, la "colpa" non è del prodotto ma di chi lo utilizza.

---

quota

19/09/2014 10:05:42 e modificato da iko93 il 19/09/2014 10:07:58

Quando mi faccio un piatto di pasta i maccheroni li compro già fatti. Di solito da soli fanno schifo, ma se li condisco con un sugo fatto da me sono decisamente più buoni. Se poi chiedo ad un cuoco di farmi il sugo probabilmente sarà anche più buono, ma più caro.

C'è anche chi ama farsi la pasta in casa, chi è capace farà un piatto magnifico, chi non è capace rovinerà il piatto (imprecando per non aver usato la pasta già fatta).

Ultimo appunto, chi compra la pasta già fatta e il sugo pronto forse farà un piatto discreto, ma limitato a ciò che può trovare, difficilmente migliorabile.

Ogni chef era un cuoco che ha fatto molta pratica. Prova e riprova a fare piatti, le prime volte saranno vomitevoli, ma prima o poi diverrai chef!

👋

quota

21/09/2014 18:35:45

Sì È nelle intenzioni della domanda. Il gioco di ruolo playbychat è in calo da anni, almeno secondo esperienza personale, forse perché dopo un po' risulta stantio. Un gioco che aggiunge funzionalità e si rinnova probabilmente mantiene attiva l'utenza. Intendo, con un codice scritto da zero potrò decidere di costruire una nuova idea nel sito? Oppure non è vero che si tratta di qualcosa di limitato in altri sistemi gestione dei contenuti. Questo aspetto viene valutato?

(Es stupido: voglio inserire nella scheda del personaggio alla voce "storia" un log delle volte che ruola, oppure delle giocate che lui decide di salvare fin da subito perché ritiene rilevanti, per testimoniare il suo percorso, con data luogo ecc, come fanno alcuni gdr, salvano le varie quest. E magari a fine anno premiare alcune tra le migliori)

quota

21/09/2014 19:11:06

Come lo puoi fare su un sistema creato da zero lo puoi fare anche con il gdrcd.

Anzi il gdrcd 5.2 per quanto poco è strutturato in moduli d apoter aggiungere e togliere o spostare.

quota

22/09/2014 12:04:59 e modificato da staff em il 22/09/2014 12:06:00

Anche noi la pensiamo allo stesso modo...e abbiamo più volte richiesto di apportare questa modifica alla scheda del gioco.

Infondo è giusto, anche, riconoscere l'impegno di chi si dedica alla programmazione di un gioco che si riassume, solo, in un'informazione in più alla scheda rendendola completa e corretta.

Non ci vedo niente di male in questo e meno che meno la solita 'fantomatica' crociata contro GDRCD.

---

quota

22/09/2014 20:44:41

Onestamente, non credo che ci sia una "caccia alle streghe" verso GdrCd.
Semplicemente, si è fatto una "brutta nomea" perché ha permesso a chiunque di crearsi il proprio gdr, spesso e volentieri con risultati poco soddisfacenti (lo confermano la miriade di gdr chiusi e abbandonati che vediamo nelle categorie del sito).

Invece, dovendo creare e gestire il proprio codice, è più facile che sia curato, è più facile da modificare, gestire i bug, ecc

Ad esempio, il programmatore attuale della mia land, nonostante l'Isola sia stata creata 10 anni fa e da due player che ormai non giocano più, riesce a modificare senza alcun problema il codice, essendo proprietario e costantemente aggiornato.

quota

22/09/2014 21:13:48

Certamente, poporoso, chi si costruisce il codice cerca di confenzionare un prodotto che possa essere il più flessibile possibile e quindi non solo graficamente gradevole (tutti lo possono e lo devono essere) ma anche con funzioni che lo contraddistinguono (anche se poi alcune verranno magari copiate ^_^) e che possono essere immediatamente(!!! ... più o meno ^__^) implementate laddove servono.

---

quota

24/09/2014 11:22:12 e modificato da ilgrandeinverno il 24/09/2014 11:39:52

La domanda che ha fatto, forse, può essere malposta, per il semplice motivo che parlare di classifiche del codice, come ha detto Blancks in uno dei primi interventi, è impossibile, irrealistico e impraticabile. O meglio, come molte cose discusse qua dentro, è teoricamente possibile, ma alla pratica inattuabile senza sforzi colossali assolutamente sproporzionati all'utilità della cosa.

Altro "errore" se così vogliamo chiamarlo, è l'aver puntato in qualche modo l'indice su un singolo CMS per play by chat ossia gdr-cd: il discorso dovrebbe essere più generale, ossia sull'uso o meno di un CMS opensource per lo sviluppo del gioco. Anche se GDRCD (old style 3.0 ed extreme, o new one 5.x e succesive) è quello che fa la parte del leone, a mio parere la domanda dovrebbe essere più generalizzata.

Metterei da parte la questione 'classifica' e domanderei più banalmente, se c'è un valore aggiunto nello sviluppo di un codice proprietario.

C'é? A mio parere sì.

Il punto che trovo sottovalutato da molti intervenuti in questo thread, e che questo thread credo miri a mettere in luce è un altro: quanto il codice influenza la meccanica e le convenzioni di gioco, le modalità di accesso ai contenuti e le abitudini dei frequentatori.

Questo non vale solo per il play by chat, vale anche per i cms in genere, da joomla a wordpress, passando per drupal e altre mille piattaforme prefabbricate.

Il vantaggio dei CMS é che non devi reinventare ogni volta da zero l'acqua calda o la ruota, se ti servono solo le funzioni base e poco altro, e puoi concentrarti sulla personalizzazione grafica e sui contenuti.

Lo svantaggio? Sei prigioniero di un codice altrui, di un modello base che propone una sorta di "approccio standard". Come dice akaja_cain questo può essere un vantaggio: il giocatore cambia land e si sente comunque "a casa". Sa già dove trovare cosa e come muoversi.
Lo svantaggio (per il giocatore e per chiunque tenti vie alternative all'approccio standard) è che il giocatore si abitua.

Va detto che con GDRCD 5.x sono stati fatti passi da gigante rispetto al caro vecchio GDRCD Extreme, in termini di flessibilità.

Se ne è parlato tante volte, GDRCD Extreme ha facilitato la vita a dozzine di gestori, ma ha anche propagato e reso uno 'standard' un solo modello di gioco, che per comodità chiameremo "modello extremelot", con l'aggiunta di poco altro accessorio: albergo a ore invece della famigerata rocca dei venti (per chi non sapesse: chat private), tiradati e statistiche basilari del pg per accontentare i fan del cartaceo e conteggio dei PX illudendoli di avergli dato gli strumenti necessari a simulare efficacemente la sessione di cartaceo al tavolo.

Ma per il resto, riproposto pari pari come pacchetto base il modello di gioco lottiano, basato su razze, gilde, mestieri e clan.
E sapendo quante gestioni sono nate da ex giocatori di quella land in fuga dopo un esilio, dopo una delusione di gioco, dopo la chiusura della loro fichissima gilda e intenzionati solo a riproporre lo stesso modello ma con gestori diversi, GDRCD è stato nient'altro che l'arma di propagazione a macchia d'olio del modello di gioco lottiano.

Ecco cosa intendo quando dico che si diventa prigionieri del codice e si finisce per non mettere nemmeno in discussione un approccio al gioco.

Personalmente mi sono fatto le ossa scriptando per un emulatore di Ultima Online, su uno shard tuttora attivo. Per quanto potessi scriptare, personalizzare, inventare nuovi effetti, incantesimi ed eventi, il motore di gioco quello era e certe cose non potevi fargliele fare.

Con un CMS le cose sono più semplici ma qui entra in gioco una valutazione di tempi e risorse ossia di "il gioco vale la candela"? Vale la candela mettersi a programmare da zero o quasi una land?

La risposta è tristemente una: no, non vale la candela.

Un buon 90% dei giochi pubblicati dal portale non avrebbe avuto alcuna ragione di sviluppare un codice proprietario avendo GDRCD e altri cms opensource a disposizione. Perchè a parte ambientazione, regole di moderazione e grafica non hanno bisogno di offrire nulla se non quanto offre il pacchetto base + una o due 'espansioni'.

Resta il punto: che succede se hai deciso di scostarti dalla meccanica di gioco modello base? Succede che a seconda di quello che vuoi implementare, la convenzienza (e, scusate, il valore aggiunto) della creazione di codice proprietario c'è eccome.

Basti pensare al mostruoso lavoro di sviluppo che è stato fatto per OiM. Mal accolto e maldigerito, temo, anche "grazie" al fatto che da anni i giocatori sono abituati (atrofizzati e narcotizzati) a "trovarsi sempre a casa". A trovare o il modello lottiano riproposto o il modello D20 *malamente* riproposto tramite adattamento di GDRCD.

E di questo possiamo ringraziare fifty-fifty la poca fantasia dei gestori, come ha detto qualcuno, ma anche la disponibilità di CMS che hanno permesso a questi gestori di mettere in piedi con poco sforzo carrettate su carrettate di land che proponevano e riproponevano da anni lo stesso identico sistema di gioco, senza alcun tentativo di innovazione concettuale, prima ancora che di innovazione grafica o del codice.

Classifiche del codice? No, per carità. Ce ne sono già troppe.

GDRCD/GDRCD-NO? No, per carità. Evitiamo di puntare l'indice sul singolo CMS.

Evidenziare sulla scheda il valore aggiunto rapppresentato da chi ha fatto lo sforzo di pensare anche a proporre e implementare una meccanica di gioco, oltre che adattare i contenuti a un CMS prefatto?

Sì, io lo farei.

E non ditemi che è inutile. Su questo portale c'è addirittura una pagina che "evidenzia e consiglia" le land dotate di utenza test, considerando "valore aggiunto" la semplice aggiunta di un record user=test, password=test in un database, al punto che ormai tutti ce l'hanno, o quasi. Alla faccia dell'evidenziazione di un elemento utile.

Codice proprietario non è garanzia di funzionalità, di usabilità per il giocatore, nè di successo. ma almeno di una cosa è garanzia: ci dev'essere stato dietro uno sforzo dei gestori di PENSARE un modello di gioco alternativo ai classici "lot-variato" e "D20 con tiradadi in chat e menu delle azioni a tendina".

Caspita se è un valore aggiunto.

Di sicuro un valore aggiunto "meritevole" di essere "evidenziato" sulla scheda del gdr molto più dell'esecuzione di una stupidissima query


{Ghennadi of Borg}

---

quota

24/09/2014 11:52:00

Mi trovo d'accordo con quanto scritto da IGI.
Solo su un punto ho un dubbio:

Mi auguro che questa valutazione esuli dal discorso di utilizzo o meno di un cms, perché pensare e implementare un sistema di gioco non c'entra nulla con la base impiegata (se non a livello di quantità di lavoro richiesto).

---

quota