La lunga avventura che mesi or sono è cominciata con i giocatori che loro mal grado hanno liberato un potente negromante al servizio di oscuri poteri, prosegue. Non si sa che fine egli abbia fatto: nelle mani dei giocatori un misterioso scrigno e tanti guai che costringono gli abitanti di Silmaril a dover fare continuamente i conti con il loro coraggio. Le cose sembravano volgere al meglio, quando un gruppo di avventurieri provenienti dalle varie capitali del Regno ha deciso di imbarcarsi in una rischiosa spedizione. Ma solo uno di loro è tornato, ed è diventato un bodak. Il negromante sembra ogni giorno più potente, quali saranno le sue mire di conquista? Riusciranno gli abitanti di Silmaril a fermarlo?

Infine, per tenerci aggiornati con i tempi e poter offrire una maggiore interazione tra i giocatori che rappresentano la comunità di Silmaril, abbiamo deciso di creare una pagina Facebook, da affiancare al già esistente forum e alla storica mailing list. Vista la grande diffusione di cui i social network come FB godono, ci piace pensare che questo possa essere un modo per rimanere in contatto anche con i vecchi giocatori, che in passato si sono divertiti con noi e che, pur avendo scelto strade diverse o non giocando più ai mud, sono ancora affezionati a Silmaril così come noi lo siamo a loro.

I contenuti della pagina su Facebook saranno allora costantemente aggiornati con Eventi, Quests, i disegni dei giocatori, le foto dei raduni e dei contenuti che i giocatori di Silmaril vorranno condividere con il resto della comunità.

Links alle pagine di Facebook:

• Bacheca di Facebook
• Galleria “Piazza degli Eroi”
  Una galleria potrete conoscere i ritratti dei volti dei tanti eroi ed avventurieri che solcano le terre di Silmaril, ad opera dei rispettivi giocatori.
• Galleria “Bestiario Bestiale”
  Una galleria dedicata a tutti coloro che non vedono il fantasy con i paraocchi, dove le “stranezze” dei mostri di Silmaril sono visti e ridisegnati dagli occhi divertiti dei giocatori.
• Galleria “SilmaComics”
  Una galleria sono raccolte le caricature, le strisce brevi e vignette divertenti che provenienti dalla fantasia dei giocatori che attingono alle vicissitudini del mondo di Silmaril.

Le estrazioni avverranno una volta al giorno, ai reboot, se il banditore avrà venduto un numero minimo di biglietti, e contemporaneamente a ciò parte il successivo ciclo. Il numero di biglietti vincitori dipende anche dalla quantità di biglietti venduti.

Ad ogni estrazione i personaggi in possesso del biglietto vincente verranno avvisati con una mail dallo scriba inviata loro dal banditore. Per ricevere il premio basta recarsi dal banditore e ovviamente consegnare il biglietto. I premi secondari sono in monente, il primo premio è una Pozione Divina casuale tra 5 tipi.

Contiamo nel periodo di pausa che ci attende di operare affinamenti sulle aree esistenti e tornare per Ottobre con alcune novità, ad esempio la contestualizzazione di un misterioso cubo apparso di recente su Waverlay e con cui qualche giocatore già si è trovato letteralmente a fare i conti.

Ringraziamo tutti i giocatori per i contributi apportati al mud tramite le segnalazioni critiche ricevute, ma anche per i sinceri e sempre graditi attestati di stima. Inoltre questa sera (10.05.2010) vi diamo appuntamento online su rdamud.afraid.org:4000 alle 21:30 per un saluto ed una piccola caccia al tesoro adatta ad ogni livello.

by Rocca d’Argento

Personalmente trovo la cosa abbastanza futile, tuttavia appena ho avuto occasione ho voluto provare a realizzare tale funzionalità a scopo puramente ricreativo avvalendomi  della linea guida suggeritami dallo stesso Arthedain:

Arthedain, 09/02/2010:
…quello che dico io e’ semplicemente: Il tuo mud fa’ un chi e salva i dati su un file, poi manda il file al mio server, e abbiamo finito.

L’idea mi pare sensata anche se probabilmente potrebbero essere sviluppate meccaniche più funzionali ed economiche, ad esempio producendo la lista degli utenti connessi solo su richiesta e non magari periodicamente: ciò, nel caso dei mud italiani in cui l’utenza è  esigua, ridurrebbe senz’altro il carico di trasmissione dati tra mud-server e web-server. Per contro però l’utenza web potrebbe influenzare in modo indefinito il carico di richieste verso il mud-server, salvo ricorrere a strategie di controllo che esulano dalla mia competenza di programmatore dilettante.

L’implementazione che segue è basata sul sorgente smaug 1.4 usato da RDA e operativo su server Linux, ma credo possa essere facilmente adattato ad altri sorgenti o piattaforme. Si tenga conto tra l’altro che lo smaug a quanto pare aveva abbozzato una simile funzionalità, che potrebbe persino essere stata completata nelle versioni più recenti del codice. Troviamo infatti nella funzione do_who, responsabile della visualizzazione degli utenti connessi mentre si è in gioco, la variabile fShowHomepage che permette la stampa sul file degli utenti connessi.

Codice C

La prima cosa da fare quindi è scrivere una funzione che stampi su file la lista degli utenti connessi, e io per comodità ho fatto in modo che il file generato sia già in formato html di modo che possa essere incluso facilmente in qualunque pagina web con la direttiva include o readfile di php. Ecco come potrebbe apparire la funzione di base:

#define WHOWEB_FILE SYSTEM_DIR "whoweb.php"
void whoweb_check( )
{
  DESCRIPTOR_DATA *d; CHAR_DATA *wch; int count = 0;
  FILE *fp = fopen( WHOWEB_FILE, "w" );
  if ( !fp )
  { bug( "Impossibile scrivere il file whoweb.php!", 0 ); return; }
  fprintf( fp, "Utenti connessi...<hr>" );
  for (d = last_descriptor; d; d = d->prev)
  {
    if ( !d ) continue;
    if (d->connected != CON_PLAYING && d->connected != CON_EDITING)
    continue;
    wch = (d->original ? d->original : d->character);
    if ( IS_NPC(wch) || xIS_SET(wch->act, PLR_WIZINVIS) )
    continue;
    count += 1;
    fprintf( fp, "%s<br>", wch->name );
  }
  fprintf( fp, "%s<hr>Giocatori: %d | %.24s | <a style=\"href=\"#\"
  onclick=\"javascript:window.location.reload(true)\">Aggiorna</a>",
  count ? "" : "Nessuno.", count, ctime(&current_time)  );
  fclose( fp );
  return;
}

Come si può notare, in questo esempio, ho predisposto semplicemente la stampa del nome del giocatore online e, in fondo a seguire, il loro numero complessivo,  il riferimento alla data e ora in cui il listato è stato generato, e un link per il refresh della pagina web. Chiaramente, volendo, si potranno registrare per ciascun utente ben piu’ informazioni del nome. Nel caso di RDA, ad esempio, ho incluso la razza, l’età, l’altezza, il peso, la classe d’appartenenza, il livello, il luogo in cui il pg si trova al momento, etc… Per fornire tutte queste informazioni in modo compatto mi sono servito dei cosiddetti tooltips multiline in javascript di cui ho inserito la sintassi specifica direttamente nella funzione whoweb_check() (…nb: il tooltips usato da me è reperibile QUI).

ATTENZIONE! Tra le info del pg che potrete stampare su file sconsiglio vivamente d’inserire: il titolo, la biografia, o in generale elementi che il pg può modificare più o meno a piacere, salvo introdurre funzioni di sicurezza specifiche che blocchino eventuali tag inseriti dal giocatore e che sappiano rielaborare anche eventuali codici colori utilizzati. La ragione è semplice: cosa accadrebbe se un pg scrivesse nel proprio titolo una cosa come “<div>“?

Ora la domanda è: “dove inserire nel codice la chiamata alla nostra funzione whoweb_check()?”. La mia scelta è stata di farlo ogni due tick, generando dunque indicativamente un aggiornamento del listato ogni due minuti e mezzo. Nulla vieta comunque d’invocare la funzione con differente frequenza,  ma in ogni caso la zona d’inserimento della nostra procedura cadrà quasi senz’altro all’interno della update_handler(), ovvero la funzione che gestisce la maggior parte degli update periodici nello smaug.

Codice Linux

Giunti a questo punto, se il web-server coincide col computer sul quale gira il nostro mud la storia si può dire conclusa. Basterà infatti porre in una qualunque pagina web del nostro sito un get_file_content, un include, o un readfile che punti al nostro neonato file whoweb.php. Diversamente dovremmo preoccuparci di inviare il file al nostro web-server ogni tot tempo, che di regola dovrebbe corrispondere all’intervallo di tempo con cui il listato viene prodotto. Su server linux creeremo dunque un file whowebloop a cui attribuiremo permessi d’esecuzione e nel quale inseriremo uno script di questo tipo:

#!/bin/bash
while :
do
#Aggiornamento ogni 90 secondi
sleep 90 & pid=$!
 curl -m 30 --connect-timeout 30 -s -T /directory/mud_server/whoweb.php
 ftp://host.web.server --user nome_utente:password
 wait $pid
done

Chiaramente /directory/mud_server dovrà coincidere col percorso ove è collocato il vostro file whoweb.php, l’host.web.server sarà l’indirizzo di connessione ftp al server in cui risidere il vostro sito e a cui vi autenticherete tramite il vostro nome_utente e password.

Codice Web

Un aspetto ulteriore da tenere in conto è l’eventualità che un utente acceda alla pagina web contenente il nostro listato mentre questo viene aggiornato. Il mio consiglio in questo caso è di inserire, tramite la whoweb_check(), un tag commento di verifica in coda al file whoweb.php come segue: <!--WHOWEBEOF--> ed effettuare poi il caricamento del file whoweb.php in modo tradizionale invece che tramite include. Ecco come:

<?php
  if (is_file("whoweb.php"))
  { $handle = fopen ("whoweb.php", "r");
    $whowebtxt = fread($handle, filesize("whoweb.php"));
    fclose($handle);
  }
  $checkEOF=substr($whowebtxt, -16);
  if ( $checkEOF == "<!--WHOWEBEOF-->" )
  { echo $whowebtxt; }
  else 
  { echo "Attendere: la lista dei giocatori sta temporaneamente aggiornandosi.";
    echo "<script>var t; t=setTimeout('window.location.reload(true)',7500)
          </script>";}
?>

Potete vedere QUI lo script in azione ed eventualmente studiare la sintassi completa impiegata sul sito di RDA visualizzando l’origine della pagina. Se non ci sono giocatori connessi – mannaggia – entrate voi stessi e ricaricate la pagina dopo 2 minuti circa per vedere il risultato. Gli aggiornamenti da me imposti sono ogni 2,5 minuti per la precisione, valore che ritengo un buon compromesso tra informazioni fornite e “privacy” per chi gioca. Per dubbi o commenti: rdamud@gmail.com.

Un saluto,
Matteo (Alek)

Il team di MUD.it

Analisi storica e critica dei MUD

La nuova miniera dell’intrattenimento elettronico, da sfruttare fino all’ultimo grammo, pare stia ormai diventando quella dei MMORPG (Massive Multiplayer Online RPG). Molti attribuiscono la paternità di questo genere a Richard “Lord British” Garriot che ormai quattro anni fa diede luce a quel capolavoro che è Ultima Online. Pochi invece sanno che il primo accenno di mondo persistente ha visto la luce agli inizi del 1979 sui dischi di un Mainframe universitario Inglese.

Cosa sono i MUD

Ci sono diversi correnti di pensiero riguardo la definizione dell’acronimo MUD. I canonici lo traducono in Multi User Dungeon mentre altri ne condannano la troppo limitante definizione e preferiscono utilizzare Multi User Dimension. In verità il termine MUD non è nato come definizione di un genere ma era il nome di un particolare gioco creato nella primavera del 1979.

Comunque possono essere definiti MUD tutti quegli ambienti virtuali dove è possibile esplorare interagendo con gli altri utenti (tipicamente chattando o combattendo) che sono connessi al server contemporaneamente a noi. I MUD possono essere testuali o grafici, possono prevedere dei client proprietari ma la maggior parte delle volte è sufficiente utilizzare un terminale TELNET, alcuni MUD sono orientati al combattimento, altri all’esplorazione di caverne – i Dungeon appunto – e mondi alla ricerca di tesori nascosti, altri ancora sono orientati alla socializzazione con altri utenti.

Riassumendo un MUD è un programma per computer nel quale gli utenti possono connettersi, giocare ed esplorare nuovi mondi. Ogni utente controlla un proprio alter ego attraverso il quale cammina, parla con altri personaggi, esplorare aree infestate da mostri pericolosi, risolvere enigmi, evitare trappole e a volte avere anche una propria dimora dove riposare e riporre gli oggetti, frutto di gesta eroiche, furti o missioni. Capiamo quindi che applicando quanto detto finora anche le ultimissime produzioni MMORPG come Anarchy OnLine possono definirsi dei “particolari” e sofisticati MUD Grafici. Ma adesso vediamo di scorrere brevemente la storia dei MUD.

Gli antenati dei MUD

La prima (conosciuta) avventura dotata di parser testuale mai realizzata è stata creata da Will Crowther su un DEC PDP-10 agli inizi del 1970, essa fu in seguito ampliata e perfezionata da Don Woods alla Stanford University nel 1976, che decise di ambientare il gioco nell’universo Tolkeniano del “Signore degli Anelli” e di chiamarlo semplicemente Adventure.

Scopo di Adventure era quello di trovare un certo numero di tesori nascosti dando dei comandi a riga di comando in base alle descrizioni che di volta in volta il programma emetteva, il giocatore poteva interagire con il computer in questo modo:

Adventure è spesso riconosciuto col nome di Advent perché il file system del sistema operativo utilizzato, il TOPS-10, limitava la lunghezza massima dei nomi dei file a 6 caratteri.

Il filone delle avventure testuali – questo è il nome attribuito a questo genere di giochi, dove il giocatore deve risolvere enigmi dando istruzioni al computer tramite un parser testuale – ebbe un’esistenza florida fino alla fine degli anni novanta. Software House come la Infocom e la Magnetc Scrolls diedero vita ad intere saghe la più famosa delle quali è senza dubbio quella dell’impero sotterraneo di Zork. L’avvento della grafica prima, e delle interfaccie punta e clicca poi – introdotte per la prima volta dalla SIERRA con il titolo King Quest e perfezionate poi dalla Lucas con Maniac Mansion – sancirono però, (quasi) definitivamente, la fine di questo filone di giochi. Ma questa è un’altra storia.

Il primo MUD: MUD1

Dicevamo prima che l’aspetto caratterizzante dei MUD è sicuramente quello dell’interazione tra più persone.

Il primo gioco ad implementare questa caratteristica fu programmato in MACRO-10 – il linguaggio macchina del DECsystem-KL10 utilizzato in università – da uno studente, di nome Roy Trubshaw, della Essex University nella primavera del 1979. Il gioco venne chiamato MUD e all’inizio non era altro che una serie di locations (stanze) interconnesse tra loro che potevano essere esplorare per cercare altri utenti con cui dialogare.

Una seconda versione del gioco fu riscritta quasi immediatamente – sempre in MACRO-10 – prevedendo la definizione di tutti gli oggetti del gioco (stanze, armi, comandi) in un file di testo condiviso da tutti gli utenti. In questo modo si poteva consentire a giocatori “particolari” di poter aggiungere di volta in volta le proprie definizioni di nuovi oggetti e di nuovi comandi. Gli utenti con questi particolari poteri furono in seguito chiamati Wizard e sono comparabili con quelli che oggi vengono più comunemente definiti Game Master (GM).

La versione finale del progetto, la terza, fu terminata di essere riscritta per la pasqua dell’anno successivo, adesso il linguaggio utilizzato non era più quello macchina – fu utilizzato infatti il BCPL – e Trubshaw decise di rirprogettare l’intera gestione della memoria per ovviare alle limitazioni imposte dal sistema utilizzato (l’originario MUD occupava solamente 50K di memoria) perfezionando intanto anche il linguaggio di scripting utilizzato per l’interrogazione della rudimentale base dati..

A questo punto Trubshaw decise di abbandonare il progetto, egli infatti era più interessato alla parte di programmazione che non quella di Game design (in particolare l’intero progetto nacque perché voleva testare alcune funzioni di condivisione per l’accesso alla memoria in sistemi multi concorrenziali), e prese quindi in mano il progetto Richard Bartle, amico e compagno di università che lo affiancò fin dall’inizio e che finalmente aggiunse tutte quelle caratteristiche che sono proprie dei MUD di oggi.

Bartle sviluppò un sistema di punteggi, implementò l’utilizzo del mobilio e dei contenitori, fornì agli avventurieri degli enigmi da risolvere e degli obiettivi da raggiungere, perfezionò tutta la “fisica” del mondo simulato (come ad esempio il sistema di luci). Racconta Bartle che il lavoro iniziale di Trubshaw, che era comunque il nucleo dell’intero progetto, a lavori ultimati consisteva nel 25% del codice scritto, mentre il restante 75% fu aggiunto appunto da lui.

Il primo MUD della storia poteva ormai definirsi concluso: MUD1 aveva cominciato a vivere.

Il primo contatto con un giocatore esterno alla rete interna dell’università avvenne nella primavera del 1980, quando l’università del Essex si connetté all’allora ARPANET (l’infrastruttura portante che fece poi nascere Internet) e a JANET (il network accademico Britannico) . Da quel giorno ogni pomeriggio studenti da ogni parte dell’Inghilterra si collegavano al server della Essex University per avventurarsi nei meandri del mondo ricreato dai due novelli Game Designer.

MUD1 girò sul mainframe dell’università per ben 8 anni (1980 – 1988) fu quindi acquistato da CompuServe (il noto provider americano) e lasciato in servizio fino al 1999 quando fu dismesso a causa del famigerato Y2k Bug.

Oggi se puntate il vostro browser all’indirizzo http://www.british-legends.com potrete comunque giocare a MUD1 grazie alla conversione, da parte di un appassionato, di tutto il codice per poter girare su piattaforma Windows NT/2000.

Ma non furono i vichinghi a scoprire per primi l’America?

The scepter of Goth, oltre ad essere il primo MUD ad essere scritto in C per poter funzionare su un sistema IBM XT con un sistema operativo Unix Like chiamato QNX (ed ancor oggi sviluppato, NdR) e oltre ad essere ricordato come uno dei primi, se non il primo in assoluto, MUD commerciale – gestito da una compagnia chiamata “GameBits TimeSharing” fondata dal creatore del gioco Alan Klietz che creò una vera e propria BBS per gestirne tutti gli aspetti organizzativi – è anche l’unico progetto che può contendere a MUD1 la primogenitura dei MUD.

Pare infatti che una primissima versione di The scepter of Goth fu scritta nel 1979 da Alan Klietz che volle creare una variante multiutente di Advent dove i giocatori potessero combattere uno contro l’altro. Il programma fu scritto in Basic (con alcune particolari routine in Assembler) e venne chiamato inizialmente Empire.

Nonostante numerose ed approfondite ricerche non sono ancora riuscito ad avere la certezza “storica” sul primato di nascita dei MUD. L’unica cosa sicura è che Empire e MUD furono due progetti totalmente indipendenti l’uno dall’altro. Fatto sta comunque che se oggi parliamo del genere dei MUD e non di quello degli EMPIRE un motivo ci dovrà pur essere.

MUD2 e i diretti discendenti di MUD1

Come già detto MUD1 aveva un solo Database (un file di testo) per tutti gli oggetti del gioco ed essi potevano essere acceduti tramite il linguaggio di scripting MUDDL (MUD Definition Language) creato appositamente da Trubshaw per l’occasione. Questo sistema tuttavia era alquanto limitativo sia dal punto di vista prestazionale che da quello funzionale (non era altro infatti che una particolare metodo di “glorified table-lookup system” come aveva fatto notare lo stesso programmatore).

Richard Bartle decise perciò di riscrivere una nuova versione di MUD suddividendo tutto il database in file diversi (utilizzando una tecnica denominato Including) ed implementando per l’occasione un nuovo linguaggio di manipolazione dati più potente e flessibile. Pensò quindi di utilizzare MUDDLE, ovvero il linguaggio conosciuto oggi col nome di MDL: una versione modificata del LISP orientata agli oggetti utilizzato all’epoca già dalla INFOCOM per scrivere Zork ed altre numerose avventure testuali..

Nacque così la quarta versione di MUD: chiamata per l’occasione MUD2. Anche MUD2 fu poi utilizzato per scopi commerciali – questa volta fu la British Telecom a comprarne i diritti – ed è giocabile ancor oggi, lo potete trovare (ed eventualmente provare) presso il sito http://www.mud2.com.

Un altro progetto nato a partire da MUD1 è AmberMUD. Esso fu scritto da Alan Cox ,(a partire dal codice sorgente di MUD1) uno studente dell’università di Aberystwyth (da qui il nome del gioco) in Scozia, e assiduo giocatore di MUD1.

Inizialmente il gioco fu sviluppato per girare su Honeywell ma fu poi velocemente portato in ambiente Unix. Nonostante l’architettura generale fosse particolarmente pesante (il core era infatti ancora quello di MUD1 e quindi tutta l’infrastruttura poggiava su un unico immenso file condiviso da tutti) e perciò non particolarmente amata dai sistemisti del tempo, i codici sorgente di AmberMUD ebbero una grossa diffusione fino ad arrivare nelle università degli Stati Uniti e fare così in modo che AmberMUD fosse il primi MUD ad essere giocato nel Nord America e comunque il primo ad essere implementato su più Server diversi tra loro.

Ci numerose altre varianti di MUD in quel periodo tra cui valgono la pena di essere menzionati VAXMUD, scritto in FORTRAN e caratterizzato dal fatto che, a differenza di tutti gli altri MUD del periodo, i giocatori non perdevano gli oggetti dal proprio inventario quando venivano disconnessi … il primo tentativo di mondo persistente; e MUNDI che, pur non essendo mai stato distribuito, è ricordato per essere il primo MUD ad essere espressamente creato cercando di ottimizzare le prestazioni di rete.

Nonostante quindi già da meta degli anni ‘80 i MUD cominciarono ad essere giocati più o meno in ogni parte del mondo la vera esplosione dei MUD la si deve al progetto TinyMUD.

TinyMUD nacque da una stanca settimana di lavoro di James Aspnes, allora studente della Carnegie Mellon University (adesso insegna a Yale). Come base per lo sviluppo di TinyMUD Aspnes decise di utilizzare i sorgenti di Monster – un abbozzo di MUD scritto in Pascal per MVS e con sorgenti di pubblico dominio– con l’intenzione di mantenerne la flessibilità ma di renderlo più snello (TinyMUD infatti prevedeva di mantenere la definizione del database tutto su memoria, a differenza del padre che gestiva tutto su file). TinyMUD fu installato per la prima volta nel 1989 sulla porta 4201 della macchina “lancelot.avalon.cs.cmu.edu”.

Nonostante le ovvie limitazioni del programma – Aspnes infatti decise inizialmente di abbandonare il progetto quando TinyMUD andò in crash superando i 32 megabyte imposti come limite sulla grandezza dei processi – TinyMUD è, insieme ai suoi derivati TinyMUCK e TinyMOO, uno dei sistemi MUD più popolari su Internet. Con i server TinyMUD nacquero così le prime definizioni alternative al genere classico, si cominciò ad utilizzare dei termini come MUSH (Multi User SHared allucinations) e MOO (MUD Object Oriented). TinyMUD infatti si distingueva dai suoi predecessori soprattutto per il fatto che il gameplay era più orientato alla comunicazione e alla creazione di mondi che non al combattimento e alla mera esplorazione di caverne.

Fu Lars Pensjö, un ragazzo svedese, che decise di scrivere un server che unisse i pregi di AmberMUD con quelli di TinyMUD. Prese vita così LPMUD: steso dapprima in C (su piattaforma System V usando IPC) fu poi riscritto interamente in C++ (per poterne sfruttare le caratteristiche Object Oriented). Le ultime versioni di LPMUD si distinguono per il fatto di prevedere un linguaggio di scripting (molto simile al C) che finalmente consentiva di poter aggiungere nuove funzionalità (comandi, magie, oggetti , etc…) al progetto in maniera graduale e scalabile senza andare a mettere mano direttamente sui file di definizione e senza utilizzare astrusi linguaggi di interrogazione.

Grazie a LPMUD i wizards poterono finalmente costruire i propri mondi a proprio piacimento: non erano più limitati ad aggiungere qualche contenitore qua e là, ma adesso erano in grado di costruire case, strade e tutto quanto gli venisse in mente (non tralasciando tuttavia tutti i problemi gestionali che questo doveva comportare, N.d.R.).

Da questo momento in poi è sempre più difficile tracciare in maniera concisa e schematica l’evolversi della nascita di nuovi MUD: la crescita di nuovi sistemi e l’installazione di nuovi server fu esponenziale. Basti pensare che ad oggi la più autorevole risorsa di catalogazione di Server MUD attivi nel mondo (http://www.mudconnector.com/) ne conta più di 1700.

Non possiamo comunque non ricordare anche alcuni progetti commerciali come Meridian59 della 3DO, o il tentativo della Sierra di commercializzare una versione OnLine di Bards Tale (forse il primo vero RPG Grafico OnLine multiutente) fino ad arrivare, come già detto, ad Ultima OnLine: il vero punto di contatto fra i MUD vecchia maniera ed i nuovi MMORPGs dell’ultima generazione.

]]> http://www.mud.it/15-03-2010/analisi-mud/feed/ 0