Come procede?

koteko Ven 24 Feb 2012, 03:45

Ciao! Questo progetto mi è sempre sembrato molto promettente...ma qui non si scrive da mesi. Mollato tutti o pausa di riflessione? Forza, anno nuovo speranze nuove Smile

Un neo-sviluppatore di mud Smile

Gadda Ven 02 Mar 2012, 18:26

koteko ha scritto:Ciao! Questo progetto mi è sempre sembrato molto promettente...ma qui non si scrive da mesi. Mollato tutti o pausa di riflessione? Forza, anno nuovo speranze nuove

Un neo-sviluppatore di mud

ciao purtroppo è naufragato un po tutt Sad

senza forze vicine da impiegare è davvero difficile produrre qualche cosa, se sei interessato fammi sapere nel caso

koteko Ven 02 Mar 2012, 18:43

Ciao, mi spiace! Qualche mese fa mi sono imbarcato anch'io nello sviluppo di un MUD, lo sto scrivendo da zero in Java e va piuttosto spedito. Prima di iniziare pensai di contattarvi ma ho avuto l'impressione che il tutto fosse molto poco definito (ed era chiaramento lo scopo iniziale del progetto...un framework per sviluppo MUD).

Io penso che un progetto del genere dovrebbe essere realizzato solo dopo aver sviluppato e pubblicato un MUD completo. All'inizio avevo fatto molti progetti, schemini, ma alla fine cambiavo struttura mano a mano che mi rendevo conto di cosa veramente serve a un mud.

Ora, ho notato che anche voi avete deciso di sviluppare un singolo MUD per concentrare le energie e avere qualcosa di tangibile, però mi sembra che non vi sia un filo conduttore preciso: ambientazione, skill system etc. Mi sbaglio?

Perché in caso contrario, vi serve solo un buon programmatore, e mi sembra di ricordare che il vostro lo sia. Ho dato un'occhiata sul vostro wiki e mi sembra che la struttura che state delineando sia buona...il linguaggio di programmazione è semplice e potente...su che punto vi siete bloccati?

Jumping Jack Ven 02 Mar 2012, 19:26

Non è realmente un blocco, è solo una perdita di interesse causata da una concomitanza di fattori.
Comunque i progetti singoli sono destinati a naufragare, perchè, nel moneto in cui la mente principale non ha tempo o perde di interesse il progetto muore.
In questo momento seguire il progetto Aarit mi sembra una buona cosa per tutti. Smile

Gli italiani doverbbero imparare ad unirsi, ci sono mud stranieri con decine e decine di persone che partecipano allo sviluppo.
Per lo meno ci vuole una comunity, che condivida idee, soluzione e forza lavoro.
Con questo non voglio dire che il tuo progetto (anche se non condivido la scelta di java) sia da buttare, solo che il tuo come i molti altri mud semi-vivi dovrebbero mettersi assieme per potenziarsi.

Condivisione è la parola chiave per progredire verso una strada in cui non ci sono soldi in mezzo.

JJ

Gadda Ven 02 Mar 2012, 20:25

Jumping Jack ha scritto:Non è realmente un blocco, è solo una perdita di interesse causata da una concomitanza di fattori.
Comunque i progetti singoli sono destinati a naufragare, perchè, nel moneto in cui la mente principale non ha tempo o perde di interesse il progetto muore.
In questo momento seguire il progetto Aarit mi sembra una buona cosa per tutti.
Gli italiani doverbbero imparare ad unirsi, ci sono mud stranieri con decine e decine di persone che partecipano allo sviluppo.
Per lo meno ci vuole una comunity, che condivida idee, soluzione e forza lavoro.
Con questo non voglio dire che il tuo progetto (anche se non condivido la scelta di java) sia da buttare, solo che il tuo come i molti altri mud semi-vivi dovrebbero mettersi assieme per potenziarsi.

Condivisione è la parola chiave per progredire verso una strada in cui non ci sono soldi in mezzo.

JJ

in linea di massima condivido il pensiero di JJ credo che avere un buono staff di programmatori che possano gestire ogni aspetto del codice è fondamentale

koteko Sab 03 Mar 2012, 01:07

In realtà JJ non condivido per nulla, né per quanto riguarda il successo dei mud in italia, né sul linguaggio di programmazione Smile

Guarda al panorama "muddistico" italiano recente. Aarit è un eccellente progetto anche se molto giovane, e il coder è uno solo, è scritto in Python e non ha problemi di efficienza se non vado errato. Isylea è un eccellente progetto ormai attivo da 7 anni, con un solo coder ed è scritto in Java, ha picchi anche di 200 persone connesse, nonostante siano un po' draconiani sul rispetto delle regole (a detta di quelli che se ne sono andati). Sword of Darkness ha un solo coder (è scritto in C++ questo, ma parlando con lui mi ha detto che se l'avesse scritto in .NET, si sarebbe risparmiato un sacco di fatica..solo che al tempo conosceva solo il C++), ancora un po' immaturo come progetto ma con un discreto seguito e un insieme di meccaniche di tutto rispetto.

Questi sono i MUD moderni a cui il progetto the keeper si rifaceva mi pare: client avanzato (aarit è web, isylea e SoD client dedicato), scritti da zero e non su vecchi codebase che ormai sono stati spremuti all'osso un po' ovunque, tecniche di programmazione moderne (specialmente aarit e isylea, il secondo non è open source ma ho contattato Athulea e mi ha dato qualche consiglio quindi posso confermarlo), meccaniche complesse e ambientazioni originali.

Ormai un mud, anche scritto in modo non divino, si puo' far girare su un qualsiasi serverino...ci sono videogiochi 3D in python e java, il discorso "linguaggio di programmazione" lascia il tempo che trova Smile

Questo ragionamento l'ho fatto sotto capodanno, quando per passare il tempo mi sono deciso a implementare il mud che avevo semi-progettato su carta (conosco il C, il C++, il Java, il Python e un paio di altri linguaggi quindi il punto non erano le mie competenze). Da dicembre a oggi, lavorandoci saltuariamente, ho un mini-mud funzionante con qualche meccanica e un'architettura facilmente estendibile. Java ha praticamente ridotto il tempo di sviluppo a un quarto di quello richiesto in C e a circa metà, forse, col C++. Il debug e la gestione degli errori è la cosa che più aiuta dopo aver implementato l'architettura iniziale.

Ora, tutto questo per dire: dov'è che The Keeper (e poi il Core, il mud) ha "sbagliato" o si è bloccato? Questo intendevo. Veniva sviluppato in Python, mi sembra, e il coder era esperto quindi il problema non dev'essere stato quello.

Forse è solo che l'ideatore, il vero motore creativo del progetto (Gadda) non era il coder. Per mia esperienza questo è un problema grosso a meno che non ci sia grande interazione e grande passione in entrambi. Io per esempio sono il coder E il creativo principale del mio progetto, un paio di amici di sono uniti successivamente e per quanto si siano appassionati al progetto, sono io che se mi viene un'idea sia di codice sia per l'ambientazione, accendo il pc e la scrivo o la implemento. E poiché il mio progetto mi piace, di idee me ne vengono, non implemento quelle di altri.

Ci dev'essere un "centro" gravitazionale, credo, e gli altri collaboratori possono "permettersi" di essere saltuari, lui no. Forse ricontattando il coder, parlandosi seriamente e delineando su carta un mud con un'ambientazione e una struttura meccanica precisa potrebbe funzionare.

Per concludere questo post chilometrico, io dico che in Italia c'è ancora spazio per nuovi MUD, che siano però innovativi, che varino l'ambientazione rispetto a quella esistente. I MUD inglesi che hanno decine di persone in sviluppo sono lì da anni, addirittura ve ne sono alcuni a pagamento..! E' una comparazione che non può essere fatta. Io vedo persone che appena si iscrivono a uno dei nuovi MUD, spesso se ne vanno perché non soddisfatte: questo vuol solo dire che esiste ancora domanda, il tutto sta a creare qualcosa che la intercetti Smile

Jumping Jack Sab 03 Mar 2012, 01:40

koteko ha scritto:In realtà JJ non condivido per nulla, né per quanto riguarda il successo dei mud in italia, né sul linguaggio di programmazione

Guarda al panorama "muddistico" italiano recente. Aarit è un eccellente progetto anche se molto giovane, e il coder è uno solo, è scritto in Python e non ha problemi di efficienza se non vado errato. Isylea è un eccellente progetto ormai attivo da 7 anni, con un solo coder ed è scritto in Java, ha picchi anche di 200 persone connesse, nonostante siano un po' draconiani sul rispetto delle regole (a detta di quelli che se ne sono andati). Sword of Darkness ha un solo coder (è scritto in C++ questo, ma parlando con lui mi ha detto che se l'avesse scritto in .NET, si sarebbe risparmiato un sacco di fatica..solo che al tempo conosceva solo il C++), ancora un po' immaturo come progetto ma con un discreto seguito e un insieme di meccaniche di tutto rispetto.

Questi sono i MUD moderni a cui il progetto the keeper si rifaceva mi pare: client avanzato (aarit è web, isylea e SoD client dedicato), scritti da zero e non su vecchi codebase che ormai sono stati spremuti all'osso un po' ovunque, tecniche di programmazione moderne (specialmente aarit e isylea, il secondo non è open source ma ho contattato Athulea e mi ha dato qualche consiglio quindi posso confermarlo), meccaniche complesse e ambientazioni originali.

Ormai un mud, anche scritto in modo non divino, si puo' far girare su un qualsiasi serverino...ci sono videogiochi 3D in python e java, il discorso "linguaggio di programmazione" lascia il tempo che trova

Questo ragionamento l'ho fatto sotto capodanno, quando per passare il tempo mi sono deciso a implementare il mud che avevo semi-progettato su carta (conosco il C, il C++, il Java, il Python e un paio di altri linguaggi quindi il punto non erano le mie competenze). Da dicembre a oggi, lavorandoci saltuariamente, ho un mini-mud funzionante con qualche meccanica e un'architettura facilmente estendibile. Java ha praticamente ridotto il tempo di sviluppo a un quarto di quello richiesto in C e a circa metà, forse, col C++. Il debug e la gestione degli errori è la cosa che più aiuta dopo aver implementato l'architettura iniziale.

Guarda che io non ho detto di usare C o C++... Semplicemente non vedo in Java un sistema adeguato per un server di quel tipo. Poi si può fare, ma Python è, a mio avviso, decisamente una scelta migliore.
Riguardo alla gestione degli errori sono perfettamente daccordo peccato che la gente metta davanti un sacco di pregiudizi. Per esempio io ho sempre usato Pascal, ora Delphi, perchè estreamente più facile da correggere e mantere rispetto al C++.
Comunque il vataggio di Python è che compilabile e esegue a runtime comandi Python. Inoltre con, stackless python, si può ottenre una altissima velocità di gestione delle connessioni.

Il discorso linguaggio di programmazione invece non lascia il tempo che trova, è fondamentale valutare prima i requisiti, la forza lavoro e poi scegliere il linguaggio.

koteko ha scritto:Ora, tutto questo per dire: dov'è che The Keeper (e poi il Core, il mud) ha "sbagliato" o si è bloccato? Questo intendevo. Veniva sviluppato in Python, mi sembra, e il coder era esperto quindi il problema non dev'essere stato quello.

Forse è solo che l'ideatore, il vero motore creativo del progetto (Gadda) non era il coder. Per mia esperienza questo è un problema grosso a meno che non ci sia grande interazione e grande passione in entrambi. Io per esempio sono il coder E il creativo principale del mio progetto, un paio di amici di sono uniti successivamente e per quanto si siano appassionati al progetto, sono io che se mi viene un'idea sia di codice sia per l'ambientazione, accendo il pc e la scrivo o la implemento. E poiché il mio progetto mi piace, di idee me ne vengono, non implemento quelle di altri.

Ci dev'essere un "centro" gravitazionale, credo, e gli altri collaboratori possono "permettersi" di essere saltuari, lui no. Forse ricontattando il coder, parlandosi seriamente e delineando su carta un mud con un'ambientazione e una struttura meccanica precisa potrebbe funzionare.

Per concludere questo post chilometrico, io dico che in Italia c'è ancora spazio per nuovi MUD, che siano però innovativi, che varino l'ambientazione rispetto a quella esistente. I MUD inglesi che hanno decine di persone in sviluppo sono lì da anni, addirittura ve ne sono alcuni a pagamento..! E' una comparazione che non può essere fatta. Io vedo persone che appena si iscrivono a uno dei nuovi MUD, spesso se ne vanno perché non soddisfatte: questo vuol solo dire che esiste ancora domanda, il tutto sta a creare qualcosa che la intercetti

Con questo messaggio hai confermato tutto quello che ho detto io. Ovvero che in Italia si fa capo a uno solo, se questo sparisce fine progetto. Nel mondo invece sono così aperti da poter guadagnare un po' di soldini per pagare anche delle persone.
I nuovi mud devono essere accattivanti, per che lo siano 1 sola persona che programma non ha materialmente il tempo per farlo, inoltre serve un adeguato supporto web e un client di qualità. Tutti lavori che richiedono una immensità di tempo.

JJ

koteko Sab 03 Mar 2012, 02:53

Jumping Jack ha scritto:
Guarda che io non ho detto di usare C o C++... Semplicemente non vedo in Java un sistema adeguato per un server di quel tipo. Poi si può fare, ma Python è, a mio avviso, decisamente una scelta migliore.
Riguardo alla gestione degli errori sono perfettamente daccordo peccato che la gente metta davanti un sacco di pregiudizi. Per esempio io ho sempre usato Pascal, ora Delphi, perchè estreamente più facile da correggere e mantere rispetto al C++.
Comunque il vataggio di Python è che compilabile e esegue a runtime comandi Python. Inoltre con, stackless python, si può ottenre una altissima velocità di gestione delle connessioni.

Oh non avevo inteso, scusami Smile

però c'è qualcosa che non quadra: Python è più lento di Java, parli di compilazione JIT che hanno sia il .NET, che il Java, che il Python, ma nei primi due è più efficiente Smile

io adoro il Python ma l'unico vantaggio rispetto al Java è che è ancora più semplice, e tutto ...che però sul lungo termine crea casini per il debug, se non c'è un'estesa documentazione. Quindi se il Python è buono, perché non lo sarebbe il Java? (sono curioso perché c'è sempre da imparare)

Jumping Jack ha scritto:
Con questo messaggio hai confermato tutto quello che ho detto io. Ovvero che in Italia si fa capo a uno solo, se questo sparisce fine progetto. Nel mondo invece sono così aperti da poter guadagnare un po' di soldini per pagare anche delle persone.
I nuovi mud devono essere accattivanti, per che lo siano 1 sola persona che programma non ha materialmente il tempo per farlo, inoltre serve un adeguato supporto web e un client di qualità. Tutti lavori che richiedono una immensità di tempo.

Uhm, certo quello è un problema enorme per quanto il programmatore principale si stufa/non ha tempo, ma in questi casi si arriva a prodotti eccellenti che poi muoiono dopo qualche anno, è un problema diverso per così dire.

Per aprire un mud decente non ci vuole un'immensità di tempo e di lavoro, solo una "gran mole" Smile

qualcosa che si fa se chi ci lavora duramente vuole _realmente_ vederlo realizzato. Quando si implementano le idee degli altri, senza troppa convinzione, si molla dopo qualche difficoltà Smile

Lo sviluppo di gruppo può essere estremamente inefficiente: che succede se si hanno idee discordanti? Si litiga, spesso, se non si vive vicini o se non si è grandi amici.

E' difficile unirsi ad altri mud comunque, se si hanno idee originali: a me piacciono sia Isylea che sword of darkness (aarit un po' meno) come struttura e ambientazione, ma non posso andare là e dire: cambiamo questo e quello Smile

dovrei fare la gavetta...ma perché farlo se penso di poter fare io stesso qualcosa di nuovo e inesplorato? E questo era l'obiettivo di questo progetto, altrimenti bastava mettere su un circle mud e fare l'ambientazione, o come dici tu unirsi ad un altro gruppo.

Comunque nei mud inglesi, almeno nella mia limitata esperienza, il codice principale è fisso da anni (alcuni sono lì dall'alba di internet..!) e le modifiche sono tutte nello scripting, building, amministrazione, quest (decine di master, vari scripter..ma pochi programmatori, a volte nessuno in grado di modificare il codice!). Lavoro immenso, e assolutamente necessario (Isylea ha un solo coder, ma vari builder/master/responsabili, e da quando SoD si è "riempito" di master e quester i giocatori sono aumentati e sembrano più soddisfatti).

Quindi il tuo discorso è valido, da soli non si va avanti, ma il primo codice deve essere fatto: bene, in relativa fretta, e con coerenza e passione. Se poi si parte da un'idea "diversa", originale, non c'è verso che si possa entrare in un mud già in beta e dirgli: cambiamo tutto, ho quest'idea! Si può provare ma è irrealistico. Quindi, si ritorna al problema iniziale: chi si occupa di implementare quest'idea nuova?

Se lo fa il creativo, l'ideatore, secondo me non si ferma per difficoltà "logistiche". Al massimo quando si è stufato. Se lo fa qualcun altro che quest'idea non la sente sua dubito il progetto possa decollare.

My 2 cents eh Smile

ps: vedo che Onirik frequenta questo forum, mi piacerebbe sapere la sua opinione a riguardo Smile

Jumping Jack Sab 03 Mar 2012, 03:29

Riguardo Python è più lento di Java solo alla prima esecuzione, inoltre Python è compilabile e lo porta ad una velocità notevole, ovviamente questo solo se necessario. Python va programmato con più cura, perchè ci sono delle best practice da seguire per ottenere prestazioni e qualità del codice. Inoltre, se serve, python è totalmente integrabile con codice C, sia con Python dipendente da C che C dipendente da Python, questo in Java non si può fare e può diventare un problema in un codice che, prima o poi, richiederà prestazioni. Se il tuo mud arriva a centinaia di giocatori, dubito fortemente che il sorgente Java non sia il più grosso problema.
Comunque, una dozzina di anni fa, avevo seguito un progetto di laurea che poi è stato abbandonato, si trattava di un codice per un mud totalmente persistente e Java era il linguaggio ideale, in particolare grazie alla serializzazione. Però non conoscevo Python, lo trovo decisamente più versatile.
Comunque, non son un esperto di Java e nemmeno di Python, se tu conosci bene Java e non conosci Python fai bene ad usare Java. Come ho detto la forza lavoro conta molto sulla scelta del linguaggio.

Riguardo allo sviluppo invece non sono d'accordo che il creativo sia anche il programmatore. Primo perchè può avere buone idee chiunque, secondo un bravo programmatore, a mio parere, non è molto creativo perchè deve essere preciso e calcolatore. Le idee certamente servono ma per inventare cose nuove, non buttare giù codice...
L'ideale è avere una guida (personaggio carismatico con una chiara idea degli obiettivi), un analista (persona in grado di tradurre le idee in qualcosa di più concreto, ben definito) e uno o più programmatori che si occupano di codificare il lavoro dell'analista.
Questa è una idea un po' vecchia, ma visto che non si parla di avere soldi da spendere a destra e a manca, credo sia necessario per procedere con qualità e rapidamente.

L'idea inziale di The Keeper era proprio di creare un motore generico, configurabile, in modo che tutte quella marea di cose comune ad ogni mud venissero implementate.
Il discorso che si litiga è solo perchè uno dice che un mostro va fatto in modo, che una abilità deve avere una certa difficoltà, una premio va così e l'altro cosà, troppi hp, troppo poche monete, più attacchi meno attacchi, più abilità meno abilità ecc... Tutte cose che dovrebbebro essere svincolate dal motore.
A me è piaciuto molto lavorare un po' su Neverwinter Nights, la grafica è preterminata ma puoi inventare, tipo usare gli effetti magici per fare fuochi artificiali, ho visto server di NWN estremamente diversi, con grandi idee al loro interno, compreso un sistema di craft che non è nemmeno previsto del codice...
E' solo questione di collaborazione, se io sono programmatore non è che se uno vuole la fireball che colpisce tutta la room e io non sono d'accordo perchè valuto che 4 bersagli è il massimo, devo litigare. Parlo e discuto, ma non mi impunto su cavolate. Invece i ho solo visto litigi su cavolate.
L'ambientazione non ti piace? Prendi il codice migliore, collabora con loro, e poi fatti il tuo mud con anche quel codice.
Mai sentito parlare di Open Source? I programmi open source si basano proprio su questo concetto. E' un tu generico, vale per tutti quelli che si mettono a programmare qualcosa che già esiste.

Per quello che vedo, ci sono due scelte, o codice chiuso e un sacco di soldi o codice open e soldi moderati o nulli. Queste sono le uniche scelte che portano avanti rapidamente e con qualità un codice.

JJ

koteko Sab 03 Mar 2012, 04:34

Divido la risposta in sezioni così risulta più leggibile, credo

Linguaggi:

Per il discorso Python/Java, credo ti sbagli: python è nato interpretato e poi e' diventato compilabile in bytecode, cosa che il Java già faceva. Un linguaggio con tipizzazione totalmente dinamica NON è compilabile staticamente. Entrambi usano un JIT "just in time" compiler (traduce il bytecode in codice macchina a tempo di esecuzione, a volte compilando e riutilizzando pezzi di codice che si usano spesso per velocizzare il tutto), che a seconda del tipo di ottimizzazione che fa può dare risultati migliori o peggiori. Qui puoi avere un'idea degli ordini di grandezza..è un sito molto affidabile di comparazione performance perché cerca costantemente l'implementazione migliore possibile per ogni linguaggio, scritte da chi il linguaggio lo conosce (se hai un implementazione piu' efficiente, mettono la tua):

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=python3

Io conosco entrambi, e li uso entrambi "professionalmente" (machine learning, AI), e come ho detto amo il python, ma se il problema sono le performance, una volta ottimizzato il codice se non ci sono miglioramenti bisogna cambiare linguaggio (cosa che come detto in un mud non succede, Isylea ha meccaniche complessissime (malattie, effetti a lunga durata, persistenza ovunque, semi-persistenza di personaggi non loggati) e picchi di 200 giocatori contemporaneamente, e fin dalla alfa 7 anni fa (a cui partecipai) le performance non sono mai state un problema).

La feature bellissima del python di supportare direttamente moduli scritti in C è una meraviglia, ma se voglio posso fare lo stesso in Java tramite binding. Scriversi una piccola, iperspecializzata libreria in C++ e chiamarla da dentro Java è efficiente e semplice quasi quanto il sistema di python, con il vantaggio che i colli di bottiglia in Java sono molti di meno, quindi lo si fa solo per cose estremamente intense (che non si hanno in un mud ma in un MMORPG Smile

)

Comunque è un problema secondario, come detto Smile

non prenderlo come una flammata, se hai opinioni differenti le rispetto. Fra qualche mese potremo fare un crash test sul mio server Smile

Sviluppo

Capisco cosa intendi (è software engineering) ma quello che manca _sempre_ nei mud e' l'analista separato dal programmatore (anche perché un'analista, in azienda, è stato anche programmatore Smile

) quindi de facto è il programmatore che deve fare tutto. Questa è l'esperienza di tutti i mud di successo che conosco, quindi varrà qualcosa Smile

anche se non ci piace, così è andata finora. Il problema principale è che tutto ruota attorno al programmatore stesso, ovviamente.

Se ci fosse l'analista, comunque, il problema sarebbe più o meno lo stesso: rimane il creativo, rimango i programmatori "monkey coders" che implementano quello che l'analista gli passava, che succede se se ne va lui? Sicuro il tutto sopravviva? Se c'è un problema grosso che va risolto, chi ci mette le mani? Un mud anni fa mori' per questo motivo: "Land of Darkness". C'erano due-tre degli amministratori che sapevano mettere mano al codice ma riuscivano a fare solo modifiche limitate: quelli "bravi" se ne erano andati anni prima. Provarono, gli utenti si arrabbiarono perche' non si riusciva a implementare neanche mezza idea, e dopo un po' chiusero. Era un mud che viveva da anni e aveva una buona base giocatori.

Ecco il problema non esiste se si ha un codebase "dinamico" e ben fatto, per questo all'inizio The Keeper era un progettone che poteva fare veramente il "botto"...purtroppo come si è visto, le energie interne si sono disperse e dal panorama muddistico non è venuto fuori nessun altro che fosse interessato.

Mi piacerebbe però provare ad analizzare perché. Io ci ho messo due settimane ad avere un sistema scheletrico di gestione connessioni, comandi, eventi basilari, persistenza mondo (usando un database), caricamento mondo (utilizzando strutture dati efficienti). E' stato anche divertente ed istruttivo. Con questo piccolo sforzo, ho un codice che è completamente mio.

Quindi, quando il programmatore coincide con l'analista ed eventualmente anche il creativo, si va spediti perché impieghi meno tempo a scriverti la tua "mudlib" basilare che ad imparare quella degli altri.

Una mudlib efficiente, dinamica, open source, è utile solo ai creativi/analisti che non sanno programmare bene. Ma se non ci sono programmatori per fare questa mudlib, di nuovo, c'è poco da fare..

E infatti anche qui si passo' alla creazione di un mud specifico (The Core), che eventualmente, se programmato bene, può indirettamente portare allo sviluppo di una mudlib generica. Anche il mio codice sarà open source non appena raggiunta una certa maturità, senza ovviamente le meccaniche, solo lo scheletro: quanto basta a programmatori di livello medio-basso, dopo essersi studiati la documentazione, per svilupparsi il loro mud.

Collaborazione
Guarda, seguo il mondo open source da più di 10 anni e ne sono un convinto utilizzatore (e collaboratore occasionale). Come accennato sopra, però, l'open source funziona se c'è almeno un programmatore convinto del progetto che lavora sodo, e gli altri che lo aiutano con bugfix ed estensioni.

E soprattutto, funziona se il "prodotto" è richiesto. Prima di iniziare a scrivere il mio ho cercato delle "mud engine" in Java, che fossero open source. Ve ne sono varie, anche molto eleganti e che mi avrebbero tolto quelle prime 2-3 settimane di sviluppo. Però erano tutti a sviluppo fermo da anni, perché i collaboratori si erano annoiati. E alla fine ho preferito avere una comprensione totale del codice, "partorendolo" da zero.

The Keeper

Ritornando strettamente al progetto The Keeper, la mia personale opinione è che sviluppando un mud con un buon design, si potrebbe a mud finito distribuire un "The Keeper" (come pensato inizialmente), un'engine per sviluppare mud. L'idea è la stessa di LPMud, che ha parecchi annetti alle spalle...solo che sarebbe molto più completo, con molte più possibilità.

E' un'idea affascinante ma per realizzarla, io vi consiglio di partire da qualcosa di concreto, che vi dia "gioia" e piacere nel portarlo "in vita". Se avrete successo poi, avrete ottenuto 2 prodotti: un mud nuovo, originale, che possa immettere nuova linfa nel panorama muddistico italiano, e la mudlib per gli aspiranti amministratori di mud senza conoscenze di programmazione.

Jumping Jack Sab 03 Mar 2012, 05:08

koteko ha scritto:Divido la risposta in sezioni così risulta più leggibile, credo

Linguaggi:

Per il discorso Python/Java, credo ti sbagli: python è nato interpretato e poi e' diventato compilabile in bytecode, cosa che il Java già faceva. Un linguaggio con tipizzazione totalmente dinamica NON è compilabile staticamente. Entrambi usano un JIT "just in time" compiler (traduce il bytecode in codice macchina a tempo di esecuzione, a volte compilando e riutilizzando pezzi di codice che si usano spesso per velocizzare il tutto), che a seconda del tipo di ottimizzazione che fa può dare risultati migliori o peggiori. Qui puoi avere un'idea degli ordini di grandezza..è un sito molto affidabile di comparazione performance perché cerca costantemente l'implementazione migliore possibile per ogni linguaggio, scritte da chi il linguaggio lo conosce (se hai un implementazione piu' efficiente, mettono la tua):

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=python3

Il confronto che viene riportato nel link che hai postato non è rilevante, l'enorme differenza di velocità è data dal fatto che si confronta python alla prima esecuzione e/o senza ottimizzazione alcuna.
Generalmente python è di poco più lento di java, un valore poco rilevante.

koteko ha scritto:
Io conosco entrambi, e li uso entrambi "professionalmente" (machine learning, AI), e come ho detto amo il python, ma se il problema sono le performance, una volta ottimizzato il codice se non ci sono miglioramenti bisogna cambiare linguaggio (cosa che come detto in un mud non succede, Isylea ha meccaniche complessissime (malattie, effetti a lunga durata, persistenza ovunque, semi-persistenza di personaggi non loggati) e picchi di 200 giocatori contemporaneamente, e fin dalla alfa 7 anni fa (a cui partecipai) le performance non sono mai state un problema).

Ho sempre reputato Isylea un buon lavoro, non ho idea di quali fossero le porformance del server al tempo, in quanto il client era lentissimo. Non era possibile valutare i tempi di risposta del server e eventuali variazioni a seconda del numero di giocatori.

koteko ha scritto:
La feature bellissima del python di supportare direttamente moduli scritti in C è una meraviglia, ma se voglio posso fare lo stesso in Java tramite binding. Scriversi una piccola, iperspecializzata libreria in C++ e chiamarla da dentro Java è efficiente e semplice quasi quanto il sistema di python, con il vantaggio che i colli di bottiglia in Java sono molti di meno, quindi lo si fa solo per cose estremamente intense (che non si hanno in un mud ma in un MMORPG )

Un mmorpg è più leggero di un mud a livello di server, sia come carico dati che come potenza di calcolo.

koteko ha scritto:Comunque è un problema secondario, come detto non prenderlo come una flammata, se hai opinioni differenti le rispetto. Fra qualche mese potremo fare un crash test sul mio server

Non c'è problema anche perchè tu intanto vai avanti con il tuo lavoro e questo conta veramente.

koteko ha scritto:Sviluppo

Capisco cosa intendi (è software engineering) ma quello che manca _sempre_ nei mud e' l'analista separato dal programmatore (anche perché un'analista, in azienda, è stato anche programmatore ) quindi de facto è il programmatore che deve fare tutto. Questa è l'esperienza di tutti i mud di successo che conosco, quindi varrà qualcosa anche se non ci piace, così è andata finora. Il problema principale è che tutto ruota attorno al programmatore stesso, ovviamente.

Se ci fosse l'analista, comunque, il problema sarebbe più o meno lo stesso: rimane il creativo, rimango i programmatori "monkey coders" che implementano quello che l'analista gli passava, che succede se se ne va lui? Sicuro il tutto sopravviva? Se c'è un problema grosso che va risolto, chi ci mette le mani? Un mud anni fa mori' per questo motivo: "Land of Darkness". C'erano due-tre degli amministratori che sapevano mettere mano al codice ma riuscivano a fare solo modifiche limitate: quelli "bravi" se ne erano andati anni prima. Provarono, gli utenti si arrabbiarono perche' non si riusciva a implementare neanche mezza idea, e dopo un po' chiusero. Era un mud che viveva da anni e aveva una buona base giocatori.

Ecco il problema non esiste se si ha un codebase "dinamico" e ben fatto, per questo all'inizio The Keeper era un progettone che poteva fare veramente il "botto"...purtroppo come si è visto, le energie interne si sono disperse e dal panorama muddistico non è venuto fuori nessun altro che fosse interessato.

Mi piacerebbe però provare ad analizzare perché. Io ci ho messo due settimane ad avere un sistema scheletrico di gestione connessioni, comandi, eventi basilari, persistenza mondo (usando un database), caricamento mondo (utilizzando strutture dati efficienti). E' stato anche divertente ed istruttivo. Con questo piccolo sforzo, ho un codice che è completamente mio.

Quindi, quando il programmatore coincide con l'analista ed eventualmente anche il creativo, si va spediti perché impieghi meno tempo a scriverti la tua "mudlib" basilare che ad imparare quella degli altri.

Una mudlib efficiente, dinamica, open source, è utile solo ai creativi/analisti che non sanno programmare bene. Ma se non ci sono programmatori per fare questa mudlib, di nuovo, c'è poco da fare..

E infatti anche qui si passo' alla creazione di un mud specifico (The Core), che eventualmente, se programmato bene, può indirettamente portare allo sviluppo di una mudlib generica. Anche il mio codice sarà open source non appena raggiunta una certa maturità, senza ovviamente le meccaniche, solo lo scheletro: quanto basta a programmatori di livello medio-basso, dopo essersi studiati la documentazione, per svilupparsi il loro mud.

Collaborazione
Guarda, seguo il mondo open source da più di 10 anni e ne sono un convinto utilizzatore (e collaboratore occasionale). Come accennato sopra, però, l'open source funziona se c'è almeno un programmatore convinto del progetto che lavora sodo, e gli altri che lo aiutano con bugfix ed estensioni.

E soprattutto, funziona se il "prodotto" è richiesto. Prima di iniziare a scrivere il mio ho cercato delle "mud engine" in Java, che fossero open source. Ve ne sono varie, anche molto eleganti e che mi avrebbero tolto quelle prime 2-3 settimane di sviluppo. Però erano tutti a sviluppo fermo da anni, perché i collaboratori si erano annoiati. E alla fine ho preferito avere una comprensione totale del codice, "partorendolo" da zero.

The Keeper

Ritornando strettamente al progetto The Keeper, la mia personale opinione è che sviluppando un mud con un buon design, si potrebbe a mud finito distribuire un "The Keeper" (come pensato inizialmente), un'engine per sviluppare mud. L'idea è la stessa di LPMud, che ha parecchi annetti alle spalle...solo che sarebbe molto più completo, con molte più possibilità.

E' un'idea affascinante ma per realizzarla, io vi consiglio di partire da qualcosa di concreto, che vi dia "gioia" e piacere nel portarlo "in vita". Se avrete successo poi, avrete ottenuto 2 prodotti: un mud nuovo, originale, che possa immettere nuova linfa nel panorama muddistico italiano, e la mudlib per gli aspiranti amministratori di mud senza conoscenze di programmazione.

Per risparmiare poca roba, è meglio partire da zero, possibilmente però mantenendo il massimo della versatilità.
Il problema resta comunque di avere un serie di persone che riescono a lavorare assieme. Il principale problema è che lavorare a distanza è dispersivo, io sono un fan della extreme programming che è proprio l'opposto.
E' anche il motivo per cui vedi meglio un progettista/analista/programmatore che una serie di persone che ricoprono questi ruoli, non si può andare avanti come si deve a distanza. Tempi troppo lunghi e scarsa possibilità di comunicare.
Una riunione a settimana, di persona, esponendo idee, perplessità, pensieri in breve tempo e tra tutti è necessario.
Come si risolve? Con una unica entità che è in grado di gestire tutto, purtroppo.

Io giocavo a Lumen et Umbra, un mud che avuto successo perchè nato a Roma e molto seguito da gruppi vari con il grosso di romani. Se fosse nato a Biella sarebbe rimasto di nicchia come gli altri. Ho partecipato a diversi raduni, ma mai è successo che si parlasse di come migliorare il gioco. Tanto non sarebbe servito, parlavano tra loro quei pochi amici e basta. (questo è tipico italiano)

Comunque al momento, mattsteel pare disperso (stava lavorando lui al codice).
Per conto mio si potrebbe lavorare al tuo codice, anche se non so come l'hai sviluppato, ovvero generico o stretto sulle tue idee. Anche se io, come ho detto, ho perso la capacità di concentrarmi a lungo su qualcosa (fondamentalmente programmare è diventato difficilissimo). Idem lavorare su una idea vasta.

Il portale si risvegliato da pochissimo, un paio di giorni, vedremo chi torna e chi arriva Smile

JJ

Gadda Sab 03 Mar 2012, 10:04

ma avete dette delle cose corrette, sicuramente tra i motivi di "fallimento" del progett TK vi è la mia non produttività a livello di codice, ma anche il fatto che un solo coder (come alla fine si è strutturato il progetto TK con Maan) può avere dei periodi in cui non riesce a portare avanti questo "hobby" e il progetto si ferma non avendo altri coder che possono prendere in mano il codice da lui scritto.

Sinceramente mi piacerebbe ripartire con qualcuno a lavorare su un progetto anche eventualmente nuovo e cercare di creare davvero qualche cosa di interessante ma soprattutto appetibile agli utenti.

Onirik Sab 03 Mar 2012, 14:23

Bhe bella discussione, ci voleva, dopo tanti anni...
Visto che sono stato chiamato in causa dico la mia, anche se più o meno avete detto tutti tante cose e tutte corrette, ho comunque dei punti di vista.

Innanzittutto vi ringrazio per aver associato Aarit ad un progetto innovativo, sì per certi versi lo è per altri è così indietro che affiancarlo a Mud ben più completi come Isylea e Sword of Darkness un po' stona, comunque son soddisfazioni Smile

Riguardo alla scelta del linguaggio di programmazione a me affascinò il Python principalmente per la sua semplicità, e devo dire di aver fatto una buona scelta anche per le sue potenzialità; non ho problemi prestazionali in aarit, anzi ultimamente sto iniziando un lavoro di refactoring per avere maggiore manipolabilità sulle deferred di twisted (coppia di callback-errback) e possibile relativa persistenza, refactoring che andrebbe a pesare sulle prestazioni.
Aarit utilizza dei costrutti chiamati behaviour, che lo si può vedere come un meccanismo molto grezzo di gestione pseudo-AI dei mob e degli item (muoversi, raccogliere, guardare, annusare etc etc) sostanzialmente ciò significa che un certo tot di mob e item (non so quanti ma cmq non pochi) eseguono ogni tot di tempo dei comandi come se fossero dei giocatori, attualmente è la parte più esosa di Aarit (e ben venga! visto che alla fin fine è come emulare su di un server tot player e quindi potenzialmente migliorare le prestazioni a riguardo) c'è stato un momento in cui con quella parte andavo a consumare il 10% del processore del server, attualmente e principalmente grazie ad un paio di trucchi, consuma il 2%; i "trucchi" sono: spostare il massimo possibile dei calcoli in una struttura di precaching calcolata all'avvio e utilizzata a runtime, l'altro è aver utilizzato la libreria numpy per il calcolo dei numeri random che uso estensivamente, quella della libreria standard è l'apoteosi della lentezza (il problema sta nelle chiamate di funzioni, un classico, utilizzare Stackless Python risolverebbe il problema alla radice).

Vi parlo di Aarit un po' per portarvi casi reali, un po' per ricavarne qualche cosa sulla mia esperienza: se lavori con uno strumento che ti piace sei produttivo, questo a prescindere che sia lo strumento migliore per fare quella cosa; certo bisognerà vedere se tutto questo sarà vero quando il progetto diverrà dannatamente grande. Un linguaggio di programmazione sostanzialmente è uno strumento per pensare, e visto che siamo diversi uno dall'altro ognuno pensa, cioè risolve problemi, a modo suo, se si trova meglio in un linguaggio piuttosto che con un altro ben venga, significa che si trova meglio a pensare con quel linguaggio (io ora se dovessi riniziare un lavoro mud lo farei in Erlang tanto per buttarla lì).
L'altra cosa che se ne evince dalle mie esperienze è che non ci sono grossi problemi prestazionali con il Python, basta avere un po' di inventiva qui e là e laddove non si può utilizzare libreria di terze parti migliori.

Koteko ha scritto che il python alla lunga è più difficilmente debuggabile se non ben documentato rispetto al Java, ciò può essere vero, tuttavia (entro certi limiti) io lo trovo uno pseudo-problema per una scelta di linguaggio; il vero problema è se il progetto ha o meno gli unit test, che diverrebbero la base solida; quello che penso è che qualsiasi linguaggio alla lunga sia difficilmente debuggabile e questo forse addirittura che vi sia la documentazione o meno! Un progetto senza unit test lo ritengo "fucked up" per definizione, quindi Aarit è "fucked up", perchè il suo programmatore (io) è un dannato smanettone che rifà i sistemi anche da zero, e quindi dovrebbe proprio rifare anche la suite di unit test da zero, e sì, sono pigro...

Riguardo al fatto del problema: "un programmatore da solo non può avere idee veramente buone (ed affiancarlo conseguentemente ad un ideatore-analista)" posso dire la mia esperienza a riguardo, essendo sempre stato il programmatore capo progetto/coder; quello che posso dirvi è stata la grande differenza di mentalità che ho utilizzato tra un progetto scritto in C e un progetto scritto in Python; quando progettavo bard in C mi sono intriso di mentalità da c-ista (come la chiamo io) il cui uno dei punti è fondamentali: prestazione a tutti i costi. Fa sorridere puntare a ciò quando si ha un linguaggio che se anche scrivi maloccio il codice l'eseguibile protrebbe girare comunque veloce. Sta di fatto che tale mentalità, e la difficoltà con cui codare in C, mi "castrava" molte idee.
Una volta passato al Python è come se mi si fosse aperto un mondo, questo perché il linguaggio è più vicino al pensare umano ed ho potuto quindi mettere da parte gran parte dello spreco di energie in cose prettamente tecniche ("oddio, i puntatori sono tutti a posto?" in C) per concentrarmi invece alle problematiche prettamente legale alle idee da implementare e non alla sua implementazione. Alcune innovazioni in aarit le ho potute inserire riuscendo ad uscire dall'ottica: "oddio mi consumerà un sacco di ram e cpu", una volta superata questa fissa ho implementato quello che dovevo e spesso non ci sono stati problemi prestazionali, altre volte ho rifatto il sistema, ma fino ad ora non ho mai buttato via nulla perchè "troppo esoso". In definitiva lo zen del Python mi ha aiutato molto.

E basta, per il resto avete detto tutti e due cose su cui io concordo, un po' Jumping Jack un po' Koteko, forse dovrei fare un riassuntino sulla mia filosofia, ma vi annoierei...
Forse il punto di maggior spicco è quello detto da Jumping Jack:
"L'ambientazione non ti piace? Prendi il codice migliore, collabora con loro, e poi fatti il tuo mud con anche quel codice."
E la cosa più pratica da fare, specie per Aarit che non essendo pensato come framework, ma come mud-game cmq reso open source: è inutile da affrontare di petto cercandolo di capire partendo dal codice, bisognerebbe entrare nella mia testa (visto che non c'è documentazione), quello che si può fare è conoscerlo poco a poco tra building e gamescripting (che è python stesso con tutte le funzioni importabili dal core)

Per concludere mi permetto di chiedere a koteko feedback su aarit visto che ha indicato in qualche modo disapprovazione a riguardo, sai è sempre utile per migliorare.

koteko Sab 03 Mar 2012, 20:55

Ciao Onirik, grazie di aver partecipato! Mi ritrovo in pieno con la tua filosofia, devo dirlo Smile

personalmente uso vari linguaggi per compiti differenti (o per imposizione dall'alto) e ho le mie preferenze, quello su cui si discuteva alla fine era se, performance-wise, python fosse meglio del java cosa che non reputo vera (come chi dice che il java è più performance del c). Per il tempo-uomo (e l'aiuto alla creatività), invece, è tutto un altro discorso, e condivido del tutto la tua view.

Per quanto riguarda Aarit, che come ho detto è un'eccellente progetto (l'ho citato sul neo-aperto blog di sviluppo del mio futuro muddino :°) http://zenithmud.wordpress.com/il-mud/ ), ciò che non mi piace è lo stile "pre thegateiano", da mud classico. Non so quanto di queste cose che sto elencando sono ancora così nel mud o se hai piani di eliminarle, in caso correggimi:

Nomi al posto delle descrizioni (Un uomo alto è qui)
Punti ferita, mana, etc, visibili e non "mascherati" da un sistema pseudo-realistico (fratture, malattie dovute al clima etc)
"Troppe" razze, creazione del pg troppo "a punti"...ma questo credo sia legato al fatto che non c'è un background definito, credo
Stile "eroico" piuttosto che legato a mestieri

Questo ovviamente è strettamente legato alla mia personale preferenza, quindi non era una vera e propria disapprovazione. In generale non mi piacciono più i mud "classici", e preferisco questi "nuovi". Il piano su cui giudico Aarit invece è nella sua gestione e nella sua innovazione tecnica, nonché sul fatto che hai rilasciato il codice open source. E il mio giudizio non può che essere positivo..con un grande incoraggiamento, continua così! Smile

Onirik Sab 03 Mar 2012, 21:24

Grazie per la risposta Smile

posso dirti che il sistema di presentazione ci sarà, quindi niente long poco simpatiche che finiscono per "è qui"
per il resto sì, aarit è un misto tra mud classico, the gate (anche se in molti punti non si nota ancora perchè non implementati) e innovazione, i mestieri ci saranno ma più come skill ausiliaria che come integrazione economica vera e propria, ma su questo mi riserbo di cambiare idea, per i punti invece non ritengo che il gdr venga "traumatizzato" in maniera tale da doverli nascondere, probabilmente al posto del prompt attuale ci saranno le barre in percentuale tipiche dei mud grafici.

koteko Sab 03 Mar 2012, 21:45

uhm con il primo punto mi sa che ho incasinato un po', mi ricordavo che su Aarit ci fossero solo i nomi, come i vecchi mud. Si vedono invece le descrizioni? Quindi è eliminato come punto (soprattutto se poi ci saranno le presentazioni) :°D

mi ricordavo infatti che tu non volessi abbandonare il "feeling" dei vecchi mud, pur mettendo meccaniche fighe. Son proprio curioso comunque di vedere il risultato finale Smile

Jumping Jack Dom 04 Mar 2012, 06:29

koteko ha scritto:
Nomi al posto delle descrizioni (Un uomo alto è qui)
Punti ferita, mana, etc, visibili e non "mascherati" da un sistema pseudo-realistico (fratture, malattie dovute al clima etc)
"Troppe" razze, creazione del pg troppo "a punti"...ma questo credo sia legato al fatto che non c'è un background definito, credo
Stile "eroico" piuttosto che legato a mestieri

Eccetto il discorso mestieri, tutti gli altri punti sono abbastanza indipendenti dall'engine, non ci vuole molto ad adattare il codice per gli altri punti.

Comuqnue io più che di parlare di mestieri o combattimento parlerei di skill, come entità generica per fare qualcosa, così facendo diventa semplice dare l'impronta che si vuole al mud. Non ho visto nessun codice che sia fatto in questo modo.

JJ

koteko Dom 04 Mar 2012, 06:42

In realtà tutti quelli della "nuova" scuola sono fatti così, se intendi che è presente un albero di skill collegate ad ogni azione che possiamo compiere, ad esempio correndo potrei allenare il fiato e migliorare anche un po' l'equilibrio, e combattendo dovrei aumentare almeno 5-6 skill diverse con diverso "peso". Non c'è una classe iniziale da scegliere, si può diventare quello che si vuole.

Per ora Aarit mi sembra non abbia ancora un sistema di progressione del personaggio, quindi non saprei se si orienterà verso le classi o verso un sistema a skill.

Sottolineo poi come io non parlassi dell'engine. Semplicemente, come si sta sviluppando il mud rispecchia le inclinazioni del suo creatore, ed è possibile quindi capire, approssimativamente, se si sta muovendo in una direzione che ci piace o no.

ps: se invece intendevi un codice open source a skill, non mi sembra di averlo visto, a parte worldforge che però è un mmorpg open source.

Onirik Dom 04 Mar 2012, 12:36

Aarit avrà un sistema a skill alcune tra loro dipendenti, quindi non è uno skill-tree vero e proprio, è un misto tra vecchio sistema a livello e dipendenza-singolo-ramo potrei dire

koteko Dom 04 Mar 2012, 19:40

Uhm, ricordo un mud (piuttosto classico, ipotizzo fosse un DikuMUD) dove a ogni livello si sbloccavano dei punti abilità, questi punti andavano spesi con un insegnante per poter imparare alcune delle abilità sbloccate dal livello (o incrementare vecchie abilità), e poi con l'utilizzo dell'abilità stessa, in stile trial and error, si poteva arrivare alla conoscenza "ottima" di quell'abilità che finalmente permetteva di non fare più errori.

E' un sistema di questo tipo?

Onirik Dom 04 Mar 2012, 21:03

In pratica ad ogni livello accedi ad una rosa di skill da poter imparare, e alcune di queste possibilmente sono imparabili e dipendenti da altre imparate a precedenza, detto così sembra uno skill tree, ma la differenza è la diffusione di tali dipendenze, in Aarit ritengo saranno poche le skill legate tra loro quindi se uno cercherebbe di creare un disegno di skill tree di tree avrebbe ben poco se non qualche ramo qui e là

koteko Dom 04 Mar 2012, 21:32

Ok, credo di aver capito. Per curiosità, con dipendenti intendi che se non hai una precedente skill non puoi apprendere una nuova che dipende da quella, oppure che quando usi una certa skill alleni anche quelle che vi sono collegate?

Onirik Dom 04 Mar 2012, 22:50

la prima di quelle che hai detto, tra l'altro probabilmente farò in maniera che se della skill precedente conosci 50 per quella successiva puoi imparare un massimo di 50 e basta

Gadda Dom 04 Mar 2012, 23:12

ho dato una lettura alle discussioni qua sopra tra voi coder, due anni fa si parlava delle stesse identiche cose e quando aprrimmo The Gate si parlava delle stesse cose (2001).

Non credete che forse il MUD per come è concepito è un prodotto vecchio anzi per meglio dire obsoleto?

Io sono dell'idea che qui intorno ci sono tante buoni spunti ma alla fine si rimane inchiodati su dei concetti che non sono certamente vincenti ne innovativi un mud senza player non è nulla...

koteko Dom 04 Mar 2012, 23:32

Capisco perfettamente cosa intendi, ma l'evoluzione dei mud c'è già: si chiama MMORPG. Per vedere un cantiere di buone, innovative idee in quell'ambito puoi dare un'occhiata al progetto WorldForge, in caso non lo conoscessi già.

Allora perché la gente continua a giocare ai MUD? Evidentemente, c'è ancora spazio per quel tipo di gioco. Le innovazioni invece a volte tardano ad arrivare, tuttavia The Gate fu un'enorme innovazione quando nacque, Isylea è andata anche oltre, per colori i quali amano un tipo di gioco complesso, basato sulle descrizione, sulla coerente interpretazione di un ruolo in un'ambientazione ben fatta.

Quindi le innovazioni arrivano, e sono "premiate". Il punto è: che altre innovazioni si possono implementare adesso? Io qualche idea ce l'ho, ed è per questo che sto sviluppando il mio MUD invece di unirmi ad altri. Una tra l'altro ho scoperto di averla in comune con te/voi: integrare il mud con un sistema gestionale via web, in modo da permettere a chi ha una visione più strategica del gioco, e magari ha poco tempo, di divertirsi lo stesso. Vedremo se poi alla fine la implementerò, un gioco multiutente è una cosa viva che "decide per sé", a volte, come svilupparsi.

Le idee innovative hanno un problema: se restano idee, sono inutili. Vanno implementate in un prodotto completo, vagliate dai giocatori e modificate se non piacciono. Per questo il mio suggerimento era ed è: decidete un insieme coerente e definito di regole, un'ambientazione, un sistema di meccaniche, e sviluppate un mud che punti ad avere un seguito, non solo ad essere una piattaforma per altri. In questo modo costruirete una "piattaforma di test" per le vostre idee, e saprete portare innovazione in caso che piacciano, quanto ridimensionarle nel caso contrario.

Se ti va, Gadda, elabora un po' il concetto, credo che sia una discussione interessante e degna di essere approfondita. Me lo sono chiesto anch'io mesi fa se ne valeva la pena, e uno sguardo al "mercato" mi è sembrato dire di si ma...quali sono invece le vostre impressioni? C'è ancora spazio per mud in italia? (nel mondo la risposta è si credo: http://mudstats.com/ )

Contenuto sponsorizzato

Come procede?

Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?

Re: Come procede?