Nuova piattaforma OpenSource per il Play by Chat

02/08/2017 16:35:08

Lo sviluppo di GDRCD6 è stato interrotto anni fa, non vedrà mai la luce, ma ci sono altri progetti in lavorazione.

Alla fine non è una questione di "concorrenza" ma di offrire quanta più scelta possibile agli utilizzatori finali e spero che il 2018 possa vedere aumentare le opzioni software disponibili per chi vorrà creare un gioco di ruolo via chat.

Sono sinceramente contento che questo progetto riuscirà a vedere la luce e passerò volentieri a dare una sbirciata su github quando lo rilascerete.

quota

02/08/2017 16:44:45

riesumare un post di aprile 2016 è niente male... qualcuno ci crede ancora? :D

---

quota

02/08/2017 16:47:56

Geko ha detto che ci sta lavorando eh, è stato lui a riesumare il post.

Per il resto questo coso mi dà l'idea di essere usabile quasi esclusivamente da chi ci ha lavorato su per crearlo, quindi una trovata per chi lo ha progettato di farsi pubblicità ed eventuali clienti.

quota

02/08/2017 16:48:11

Beh, long, sono state riportate delle news a riguardo.. non ci vedo niente di male

quota

02/08/2017 16:54:16

"ci stiamo lavorando" non è propriamente una news. Soprattutto rapportata al fatto che GDRCD6 non sia stato messo in fase di sviluppo: non è una corsa, per fortuna.

---

quota

02/08/2017 17:01:12 e modificato da blancks il 02/08/2017 17:02:35

Il fatto che sono vicini ad una release però lo è, così come il fatto che ad un anno di distanza il progetto è ancora in piedi. Notizia utile per chi teneva d'occhio il topic tramite il sistema dei preferiti, per dirne una.



Conclusione molto affrettata e miope per certi versi.
E' un prodotto destinato prevalentemente ad un pubblico che ha più dimestichezza con lo sviluppo software rispetto al gestore medio, ma questa scelta non comporta nulla di così malizioso a monte: fuori da questo ambiente molti progetti open source sono sviluppati con tecnologie simili o anche più complesse.

quota

04/08/2017 11:13:21

Quoto solo l'ultimo messaggio, ringraziando Blanks per il sostegno e il pragmatismo nelle risposte.

La mia non voleva essere una forma di marketing ma un modo per far sapere al community che si sta lavorando a qualcosa di diverso da GDRCD anche se lo si fa nel tempo libero.

Capisco la paura per alcuni di trovare un prodotto che si distacca dal consueto GDRCD ormai presente dal 2007 con la prima release "Le due città" ( e forse prima ancora con altre release ) ma il tutto è sviluppato appunto per favorire la stesura del codice di back-end (php) secondo dei criteri molto basilari, lasciando libero sfogo agli sviluppatori sul lato front-end per modificare le views.
Il progetto intero si basa su Laravel 5.x e quindi documentazione trovabile online sul sito ufficiale del framework, il quale ha una curva di apprendimento molto elevata.
Quindi l'affermazione "lo può modificare solo chi lo ha creato" non è proprio esatta, sicuramente chi prenderà in mano per la prima volta il nostro prodotto dovrà fare un po' di pratica e prendere dimestichezza con le logiche.

Con questo continuo ad affermare che siamo vicini a un primo rilascio!

---

quota

04/08/2017 14:54:43

Premesso che chi scrive ha sviluppato in proprio un motore di gioco che ha ormai, nelle sue strutture portanti, quasi otto anni; premesso che oggi diverse cose le avrei costruite diversamente; premesso che detesto i cms in genere per il modo in cui ti rendono schiavo di una struttura pensata da altri e che appena ti serve qualcosa di più del modello base ti tocca comunque lavorare in prima persona e sviluppare quello che tiserve pregando che le tue modifiche funzionino ancoa dopo il prossimo update/patch del cms che hai usato come struttura....

Un altro cms? Non credo se ne senta il bisogno. Ma non vedo neanche perché no. Nel senso che gdrcd ha già fatto abbastanza danno almondo del pbc
Illudendo carrettate di gestori improvvisati che mettere in piedi e far funzionare una land con qualcosa di originale da dire rispetto all'esistente richiefa poco più che la capacità di installare un cms e personalizzarlo. Quindi un cms in più non peggiorerebbe certolo scenario, anzi. Probabilmente riabituerebbe i giocatori a una varietà di schemi e di interfacce che si è un po' persa. Questo lo dice uno sviluppatore che si altera un po' ogni volta che un giocatore si lamenta di non essere abituato a trovare rte funzionalità in un punto anziché in un altro, o peggio ancora che si lamenta perché "sono abituato a trovare l'elenco degli online lì, tutte le land ce l'hanno lì perché voi ce l'avete là??". Non è certo la deriva spuria peggiore di gdrcd, ma c'è da considerare anche questo: gdrcd non ha impigrito solo i gestori, ha impigrito e assuefatto anche i giocatori. Quindi ben venga un cms in più a variare un po' e a desclerotizzare il panorama.

Un framework? Ecco questo lo troverei già più interessante e più utile. mi lasciano solo perplesso alcuni problemi di catattere generale.

Una delle "bellezze" del pbc è l'enorme varietà di sistemi di gioco offerti (appiattimenti e standardizzazione virale imposta dall'uso massivo di gdrcd a parte). E' pur vero che concettualmente i sistemi si possono riassumere in poche grandi famiglie ma l'implementazione locale fa la differenza. In questo senso vedo difficile, si tratti di un nuovo cms o di un framework, scappare al tradizionale collo di bottiglia dello strumento "all purposes" che comunque costringe chiunque voglia andare oltre il pacchetto base a fare per sé. E sempre col rischio dietro l'angolo di imporre una standardizzazione de facto che oltre ad appiattire e assuefare e impigrire gestori e giocatori, ti rende nuovamente prigioniero di strutture prefabbricate, o schiavo di prodotti di terze parti che in qualunque momento potrebbero cessare di supportarne lo sviluppo, la manutenzione o creare problemi di integrazione con altro codice (proprio o di terze parti ancora).

Personalmente vedrei con molto favore lo sviluppo, piuttosto, di pacchetti limitati per funzionalità, che non costringano ad adottare un intero sistema dalle fondamenta, ma che siano in grado di integrarsi, ad esempio tramite un ben documentato passaggio di variabili, a qualunque sistema in grado di passargli quelle variabili.

Provo a spiegarmi con un esempio. Molte land hanno costruito le loro mappe usando flash. Quell'esrcrato flash che, se non usato in modo improprio, non ha paragoni per semplicità di sviluppo e manutenzione.
Ora le stesse cose che in molti eravamo abituati a farci in flash in pochi minuti, dovremo industriarci a gestirle diversamente, potendo (e dovendo) scegliere tra (o come integrare) css3, html5, jquery, uno o più framework per le UI e avendo sempre sul collo la spada di damocle dell'usabilità su diversi dispositivi.

Vuoi rendere un servizio davvero utile? Ecco per esempio potresti pensare alla produzione non dell'ennesimo plugin per gdrcd o di un framework all inclusive, ma di pacchetti in gradi di ricevere variabili (chissenefotte se a passarglieli è una pagina php, uno script perl, uno script bash, python o un eseguibile compilato) e renderizzarli.
Nell'esempio della mappa, potrebbe ricevere immagine di sfondo piuttosto che tiles del terreno, griglie, coordinate dei marcatori ed azioni associate all'uso dei marcatori in risposta alle azioni degli utenti, e via dicendo.

Naturalmente era solo un esempio. In quest'ottica se posso esprimere un suggerimento ti suggerirei anch'io di evitare il ricorso a strumenti che restringono l'usabilità in funzione delle disponibilità economiche dei gestori. Nella stragrande maggioranza dei casi lo spartiacque tra un buon gdr e un gdr pessimo non è la disponibilità di risorse economiche o la disponibilità a investirle, ma l'adozione di una mentalità "professionale" nel presentare e gestire un progetto, e questo non ha alcun rapporto con le disponibilità economiche né con la caratteristica amatoriale della maggior parte dei giochi.

Comunque in bocca al lupo!

---

quota

04/08/2017 15:59:55

Dovessi sviluppare un framework per un pbc, sinceramente, costruirei le features principali (chat, forum, posta, profilo, etc), tuttavia lascerei all'implementazione delle specifiche direttamente lo sviluppatore che adotterà il framework.

Ad esempio, sarebbe divertente costruire le fondamenta con varie classi, con alcuni metodi astratti; quindi lo sviluppatore avrà si una base da cui partire per, che ne so, la classe Personaggio, con varie funzionalità di base già pronte da essere usate, tuttavia allo stesso modo, ci saranno funzionalità non standard da implementare obbligatoriamente (un metodo astratto va implementato per forza). Inoltre se si vuole sovrascrivere qualsiasi altro metodo "standard" basta farlo nella classe che si deve per forza andare a scrivere.

Inoltre utilizzerei una quantità di interfacce pressochè infinita, in modo da rendere molto semplice cambiare le dipendenze del framework. In questo modo non si forzano gli sviluppatori ad usare dipendenze, se si vuole utilizzare altre librerie basta scrivere un adapter, implementare l'interfaccia ed il gioco è fatto.

quota

04/08/2017 16:20:43

Da notare che questo discorso si sta facendo in un panorama dove il 90% dei gestori a malapena si raccapezza su qualche pagina di procedurale.

Per quanto mi piaccia l'idea (io stesso ho finito per costruirmi un framework personale per monahven) temo che sarà vincolata a pochissimi eletti, e tutti con sufficienti capacità da non avere forse bisogno di qualcosa di pronto.

Se si fa "troppo poco" chi ha le capacità per fare il resto, fa prima a farsi tutto come più gli piace.

Se si fa "troppo troppo" chi ha le capacità per usarlo, sarà comunque vincolato da scelte di progettazione non adatte alle sue esigenze.

Chi invece non ha ancora le capacità per avvicinarsi ad una programmazione a oggetti, salvo fornirgli la più corposa, semplice e chiara documentazione del mondo, dubito andrà oltre la configurazione di base.

Insomma, per come la vedo io, per quanto lodevole sia il progetto, temo che sarà solo alla portata di pochi, e tutti gli altri continueranno tranquillamente ad usare il gdrcd senza creare un tangibile cambiamento nel panorama attuale del pbc.


PS. quanto a facilità di utilizzo, io avrei optato per Slim in favore di Laravel.

quota

San Giorgio e il Drago

San Giorgio e il Drago: Il gioco di ruolo come metodologia e metafora della formazione

Niubbo Armageddon

Il niubbo, in un gdr online, può essere considerato un Armageddon. Scopriamo come...

Slice and Dice

Intervista a Slice and Dice il sito dei sistemi di gioco per play by chat!

Personaggio Fico

Lo sai fare un personaggio figo? Io sì. Vediamo come!