Alternative al GDRCD - Pagina 3

06/01/2014 17:24:22

daiana ha scritto: [quote]tsukihoshi ha scritto: ...

John tu dici prima che c'è la dietrologia poi ora dici cose che non sono vere: uccisione di linguaggi? Ma dove e soprattutto quando?[/quote]... °-°?Il primo esempio che mi viene in mente http://it.wikipedia.org/wiki/C_sharp ↗Poi il momento della dimostrazione e della misura dell'e-pen non mi serve, ho già diversi siti dove volendo te ne posso spiegare le funzioni, ma onestamente non è il mio obiettivo. Era ed è mio obbiettivo invece sostenere che per essere concorrenziale e accattivante per l'utenza il GDR-CD come suoi simili deve essere perennemente aggiornato e (necessariamente) essere summa di tutti gli sforzi di tutti i programmatori che ci rosicano attorno.Finita la vetrina, torno a ripetere che se state ancora parlando di cosa sia il GDR pbc e cosa possono fare le anime del purgatorio per renderlo migliore, vi rispondo, ancora, che non sto trattando di questo argomento, ma sto parlando solo di web programming, della sua naturale evoluzione, e di come sia difficile e dispendioso starne al passo...La programmazione è per forza di cause parte integrante se non fondamentale di una "Land"Paradossalmente, la tua "collega" suggerisce che "Chi vuole fa", ma è un concetto che cozza con il più ampio "Facciamo per gli altri" che dovrebbe avere un "Open Source".Forse lo devo scrivere, così è più chiaro: Sostengo a vita i pacchetti distribuiti e gli "Open Source", ma sostengo allo stesso tempo che GDR-Cd e gli altri (necessariamente considerati minori) non sono oggettivamente concorrenziali ne al momento sufficienti a se stanti.

06/01/2014 17:40:40

john galt ha scritto: Il primo esempio che mi viene in mente http://it.wikipedia.org/wiki/C_sharp ↗

... parlando di web programing tu mi tiri fuori il c sharp, un linguaggio a programmazione ad oggetti usato per le applicazioni e non per i siti web... è come se mi dicessi che java viene usato per fare i siti web (applicazioni web sì, ma siti web no caro mio), e comunque non è di certo un linguaggio "completamente nuovo" di 3 annii linguaggi per il web programing sono: php, sql(se si vuole usare un database, altrimenti c'è l'alternativa di usare i file per registrare le informazioni, alternativa scomoda se le informazioni sono tante), html, css, ruby on rails, javascript, xml...ma non c, c++, c# e xD mi fermo qui per i linguaggi di programmazione per le applicazioni (ce ne sono infiniti e non stiamo parlando di questo)---fine off topiccomunque in sostanza non hai capito il mio discorso: certo, vi sto dicendo: se uno vuole fare una miglioria nel suo piccolo la fa per conto proprio, se uno HA un'IDEA per una miglioria da integrare nel gdrcd in GENERALE basta che la esponga chiaro e tondo, nei dettagli, e chieda CORTESEMENTE a chi ne sa qualcosa di aggiornare il codice gdrcd integrando quella sua IDEA. ma se venite qui a dire "sono stufo/a del gdrcd voglio qualcosa di nuovo" senza specificare che cavolo volete di più da quel che vi offre il gdrcd campa cavallo che l'erba cresce.Siete stufi del gdrcd ed avete qualche idea per renderlo accattivante? esponete tale idea nel dettagliosiete stufi del gdrcd e non avete idee però pretendete che un santo di turno vi offra la pappa pronta inventandosi pure di sana pianta un'idea? per me potete cavarvela da soli e accontentarvi di quel che avete.per me ripeto, è la gestione che fa morire le land, l'utente player non si interessa come è stato programmato, per lui è importante che possa divertirsi giocando senza che spuntino errori che gli interrompono il gioco (per quel che gli riguarda del codice) e che la gestione sia presente portando aggiornamenti e eventi in land, ma nell'accezione di CONTESTO di gioco, di codice se ci sono va bene, ma se non ci sono aggiornamenti poco gli importa.

06/01/2014 18:04:59

OT.Infatti in quel trafiletto non sto parlando di linguaggi, ma di altre cose :-D

john galt ha scritto: P.s.Aggiungo, servirebbe (per essere ben fatta e "concorrenziale") almeno una release ogni 2 mesi dal mio punto di vista. Negli ultimi 3 anni ho visto la nascita le release e la morte di due linguaggi di programmazione completamente nuovi. Alcune versioni aggiornate dello stesso pacchetto secondo me è un po' pochino... Se per voi non è così, amen eh.

Rispondo al tuo OT quotandomi.Sto parlando di Release. Di aggiornamenti. Di evoluzione di linguaggi e tecniche.Il "sono morti linguaggi" è un parallelismo per spiegare meglio cosa intendo. Ti lino il c# perché nel giro di 3 anni di esistenza, si è visto soppiantare nello stesso ambiente da f# con facilitò estrema. Pur essendo aggiornato continuamente.Poi ti posso parlare anche della fine del dotNet e dell'avvento di Azure, del massiccio orientamento alle app e python, del desktop 8.1... Magari in privato così non rompiamo le scatole qui e non andare off topic...Io parlavo di come si debbano (per forza di cause) trattare le release ^_^Se trattate il GDR-CD come un "Open Source"(e non lo è), dovrebbe sottostare a logiche precise. E ciò non accade. Come detto nei post successivi./OTIl resto del discorso non è necessario a quello che esprimo, però va contro alla logica "dell'open source" come ho già detto. Il che è deleterio per il pacchetto quanto per l'evoluzione di esso.Perché?Perché se l'utente chiede, il programmatore genera, collega e riscrive il pacchetto o una libreria da agganciarci. Non ci si deve fermare a "Il programmatore Genera". Altrimenti (ed è il mio discorso) è normale che il GDR-CD "non piace più"Hai scritto qualcosa per GDR-CD? Benissimo! Pubblicalo e collegalo in modo facile a GDR-CD. Tutto li... °-°

17/01/2014 03:47:02

mai usato gdrcd. solo codice proprietario. ftw! 😎

17/01/2014 08:11:26

DreamOfYou si basa su codice proprietario in quanto per sua fortuna ha un suo programmatore personale che se ne occupa (in realtà da qualche tempo siamo in 2), e quindi possiamo garantire assistenza e nuove funzionalità continue e senza il pericolo di esser "abbandonati" a noi stessi.Forse la scelta di alcuni neo-gestori di utilizzare dei pacchetti già pronti nella gran maggioranza delle volte si basa dalla mancata conoscenza dei linguaggi programmativi utili per creare un gdr personalizzato. Comunque sia questo alla fine non risulta un grosso problema in quanto la velocità in cui vengono create alcune land risulta poi proporzionale alla velocità in cui vengono chiuse. Probabilmente ciò è dipeso dall'inesperienza, dalla conoscenza reale delle responsabilità a cui deve adempiere un Gestore e probabilmente dalla scoperta che il codice deve evolversi insieme alla land ed alle esigenze degli utenti, cosa che non può esser fatta in mancanza di staff qualificato (o almeno che ne sappia qualcosa sulla programmazione). Alcuni Gdr però si salvano in quanto comprendono che un pacchetto già pronto non è seempre sinonimo di garanzia, ma una base su cui poi bisogna lavorare rendendolo man mano nel tempo sempre più personale fino a trasformarlo completamente. Qui su gdr-online abbiamo grandi esempi di giochi basati su gdr-cd resi quasi irriconoscibili e credo che dovrebbero esser esempio per tutti quelli che usano la loro stessa base :)

18/01/2014 02:44:58

Io non comprendo quelli che giudicano negativamente una land dal punto di vista del codice se questo non è proprietario. GdRCd lo trovo fatto bene (parlo da profano) e concede tutti gli strumenti utili per poter scatenare la propria fantasia. Ovvio che almeno un minimo di personalizzazione ci vuole, ovvissimo. Personalmente non ho mai pensato che grafica e codice (a meno che questo non renda ben fruibile il sito) contino più di tanto nel giudicare un gioco.

dreamofyougdr ha scritto: DreamOfYou si basa su codice proprietario in quanto per sua fortuna ha un suo programmatore personale che se ne occupa (in realtà da qualche tempo siamo in 2), e quindi possiamo garantire assistenza e nuove funzionalità continue e senza il pericolo di esser "abbandonati" a noi stessi.

Spero non venga presa come un'offesa, perché offendere non è mia intenzione. Ad ogni modo penso che il codice di DreamOfYou sia tale a quale a quello di Extremelot, almeno questo mi suggeriscono grafica e layout, praticamente uguali.

Modificato da ulvai il 18/01/2014 02:47:47

18/01/2014 12:03:44

Io programmo e le mie land sono sempre state codice proprietario.Alla fine il grosso delle funzioni è quello GDRCD insegna ma vuoi metterci funzioni extra quali mappe interattive, abilita, automatismi e cose cosi?GDRCD se non sai programmare ti da una mano ma alla fine se vuoi distinguerti o crei qualcosa di unico o amen dimenticatoio come il 95% delle land esistenti.

18/01/2014 13:37:34

Vorrei partire da una semplice premessa.Tralasciando che non ho letto molti degli interventi precedenti, quindi chiedo scusa se finirò col ripetere cose già dette, non sono qui per iniziare crociate di alcun genere ma soltanto per esprimere il mio modestissimo (e perfettamente opinabile) parere in proposito.GDRCD non è una macchina da monopolio, chi lo ha sviluppato/migliorato/integrato lo ha sempre e solo fatto per perfezionare uno strumento e non per affossare altri progetti rilasciati come free open source software.L'obiettivo è soltanto quello di fornire una base di partenza funzionante, bene impostata e implementabile per permettere anche a chi poco ci mastica di programmazione di poter mettere in piedi il proprio progetto, perché come magari un bravo programmatore potrebbe non essere un altrettanto in gamba gestore, viceversa ci sono persone che hanno una capacità unica di relazionarsi con l'utenza, idee splendide per un buon gioco di qualità ma scarse competenze tecniche per poter creare il gioco come vorrebbe che fosse ed è a questo punto che GDRCD diviene una delle possibili strade da intraprendere.Se devo dare un mio parere sul perché gli altri progetti sono scarsamente utilizzati è perché, semplicemente, non c'è alcun supporto ad essi. Alcuni hanno avuto una piccola comunità attorno nei primi momenti della loro creazione (vedi accent, rpgengine, opengdr) ma successivamente questa si è pian piano dissolta, nessuno (o quasi) ha sviluppato grazie a quei software o se lo hanno fatto non ne hanno condiviso le modifiche lasciando semplicemente quei progetti morire.Sotto questo punto di vista purtroppo poche persone hanno condiviso ciò che facevano anche per lo stesso GDRCD, ma a differenza di altri progetti non è in stato di abbandono: vedo periodicamente il rilascio di nuove funzionalità o mini tutotial per fare determinate cose con gdrcd. Inoltre è un codice con cui tutti hanno avuto a che fare una volta o due ed è quindi molto facile ricevere supporto dalla comunità in caso di problematiche e per di più al momento ci sono delle persone che si sono incaricate di produrre aggiornamenti più o meno "ufficiali" (si beh, aggiungete 10 virgolette in più) e questo giova al progetto che quindi chiaramente è infinitamente più appetibile degli altri qui presenti.Vorrei spendere due parole su TDL OS, dal momento che è stato citato nel topic di inizio discussione.Il suo unico problema è che è un copy-paste di ciò che era la land per cui è nato, è un codice molto complesso per la media dei potenziali utilizzatori sul portale e non è pensato per un rilascio pubblico. E' infatti difficile senza le dovute competenze apportare modifiche atte a stravolgere le varie meccaniche di funzionamento, per cui è un sorgente che va preso in considerazione solo nel momento in cui vuoi sviluppare un progetto con regolamento D&D 3.5, stop.Codice proprietario o GDRCD ?E' provato che non bisogna essere programmatori esperti per customizzare GDRCD ad un livello tale da poterci fare davvero di tutto, sono riuscito a dare un occhio all'interno di giochi come lebensborn projekt (prima del suo ritiro, ma non è questo il punto) norse eventyr e altri che hanno raggiunto livelli di personalizzazione grafica ineccepibili.Ci sono poi progetti come Tales Of Fomoria, che anche se magari ricordano ancora alla lontana le loro origini da GDRCD e sono sicuramente giochi che lasciano un segno per freschezza e innovatività del progetto, di conseguenza non mi sento d'accordo con le parole di faelsel quando scrive che per distinguersi bisogna obbligatoriamente utilizzare un codice sorgente differente dagli altri, visti gli esempi concreti citati.(Comunque, sono 20€ e accetto assegni.)GDRCD è un progetto creato a più mani e senza un idea precisa alla base, di conseguenza ci sta che un programmatore esperto non avendo bisogno di alcune delle funzionalità, oppure non piacendogli la logica utilizzata, possa decidere di intraprendere altre soluzioni al fine di ottimizzare il suo codice al meglio. Non è costretto a contruibuire al perfezionamento di GDRCD o altro. Trovo invece stupido e insensato chi decide di creare una base proprietaria prendendo "in prestito" del codice dal GDRCD.Così come l'utilizzo di una base quale può essere GDRCD non dovrebbe essere criticata a prescindere, anche la scelta di voler comporre un codice proprietario non lo dovrebbe.Anche perché non è detto che il codice sia interamente proprietario, ad esempio alcuni progetti come Tales of The Silver Sword e Shenteon adoperano Symfony alla base.Queste le considerazioni, ma se devo dirvi una cosa in tutta franchezza: è un pò ridicolo leggere di persone con l'ego a mille soltanto perché hanno sviluppato una base proprietaria. Se hai fatto un buon lavoro sono il primo a complimentarmi con te, ma se forte di questo ti senti in diritto di lasciare commenti ai singoli giochi penalizzandoli solo perché usano soluzioni pronte o assumi atteggiamenti di superiorità in un forum.. beh meglio che mi fermo qui.Chiedo scusa per il muro di testo e ringrazio i temerari che sono giunti fino a qui con la lettura.

18/01/2014 13:41:59

ouroboros ha scritto: Non vedo il problema.

Io purtroppo sì.Sono sicuro che dall'ottica del giocatore fra GDR-CD ed un codice proprietario non cambia nulla. Sono consapevole che poi quello che si vede sulla pagina è praticamente lo stesso gioco, ed è lecito domandarsi a che diavolo serve sprecare millemila energie e tempo se poi il pacchetto offre già tutto. Ma la programmazione non è un layout messo a destra piuttosto che a sinistra. Non è una mappa navigabile con le aree sensibili piuttosto che con i pulsantini.Chi gioca non potrà mai capire fino in fondo cosa cambia fra una o l'altra soluzione, ma non perché sia stupido, semplicemente non spetta a lui occuparsi di questo.Parlo per me, perché è questa la ragione che mi tiene sempre a 10m di distanza da GDR-CD: non è ad oggetti. All'utente finale non può fregar di meno, anzi nemmeno può capire che cosa cambia fra codice procedurale e codice ad oggetti, ma per me che devo scrivere quel gioco cambia l'universo intero.Non posso spiegare in maniera valida quale sia la differenza, ma i suoi effetti sono quantificabili in ore di lavoro e linee di codice. Un po' come sapere di star facendo più fatica adesso ma di aver sistemato le cose in modo da sforzarsi solo il minimo domani, anche se ci fosse da cambiare mezzo gioco tutto insieme.Questa per me è un'ottima ragione per non usare GDR-CD, ma è un mio pensiero personale. Se dovessi riscrivere daccapo un gioco e farlo strutturalmente uguale a gdrcd.. eh beh a quel punto significa che dovevo averne di tempo da sprecare.

18/01/2014 15:43:37

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}

Modificato da ilgrandeinverno il 18/01/2014 16:08:57