Alternative al GDRCD

06/01/2014 17:06:53

john galt ha scritto:
Negli ultimi 3 anni ho visto la nascita le release e la morte di due linguaggi di programmazione completamente nuovi.

ò.ò al massimo due OPEN SOURCE nuovi, di linguaggi di programmazione nuovi proprio NON NE SONO USCITI per il web, al massimo l'aggiornamento "recente"(relativamente recente) di html 5 e css 3, ma sono AGGIORNAMENTI. Poi volendo(anche se è un macello farlo) uno può pure usare ruby on rails(anche questo vecchiotto come linguaggio, è quello con cui è stato fatto twitter) per fare una land, ma è un linguaggio abbastanza scomodo con cui programmare soprattutto per scopo ludico senza nulla in cambio.

per favore, non parlare come se fossi un programmatore se poi usi in maniera sbagliata il termine BASE "linguaggio di programmazione" scambiandolo come "open source" è questo che poi frega noi reali programmatori: c'è tanta gente che si finge tale, frega la gente prendendosi pure soldi e poi nessuno vuole avere a che fare con chi è programmatore REALMENTE.

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 anni

i 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 topic

comunque 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 dettaglio
siete 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.

/OT

Il 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 e modificato da ulvai il 18/01/2014 02:47:47

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.

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.