MUD & GRAFICA (parte 1/2)

Programmazione MUD.it Nessun tags

A mo’ di riflessione ho pensato di scrivere un breve articolo relativo alla possibilità di inserire elementi grafici nel proprio MUD premettendo però che probabilmente sono un po’ un purista e, come tale, non mi trovo ad essere granchè favorevole a questa pratica in un gioco che intrinsecamente nasce testuale: preferisco immaginarmi un ambiente a partire dalla descrizione piuttosto che non vederlo.

Chi ha giocato in un mud per un po’ sono certo che nella propria testa avrà quasi per ogni luogo, creatura, oggetto un pensiero associato più o meno definito. Potrebbe essere un peccato cancellare quel pensiero fornendo all’utente l’immagine spicciola. E, al di là di questo aspetto “romantico”, ho la convinzione che la sostanza del gioco sia da cercare ben altrove e non tanto su questa o quella icona, col rischio tra l’altro di fornire un prodotto parziale o incoerente se non si hanno le risorse necessarie (grafici ad es) per affrontare il tutto in maniera globale.

Tra le due potrebbe essere meno pericoloso l’inserimento dell’audio associabile ad incantesimi, combattimenti, etc… ricordando comunque di offrire sempre all’utente la possibilità di attivare o disattivare questo genere di features che, magari alla lunga, potrebbero risultare ripetitive.

Tuttavia, effettivamente, tornando all’argomento di partenza, disporre della grafica può fare comodo ed usata come complemento non indispensabile allo svolgimento del gioco dal mio personale punto di vista non ha controindicazioni.

Quale sia il metodo migliore per implementare queste features non saprei dirlo, posso però dire come viene fatto di solito…

I PROTOCOLLI.

La connessione ad un mud avviene normalmente sfruttando un solo canale di comunicazione; detta alla buona: “A” dice una cosa, “B” ascolta e risponde, e cosi’ via. In un mud tradizionale per inserire elementi multimediali occorrerà fare in modo che parallelamente a tale comunicazione possano passare da “A” a “B” e viceversa altre informazioni senza che queste creino confusione con quanto “A” e “B” si stanno apertamente dicendo.

Esistono diversi protocolli che permettono questo sub-dialogo a vari livelli: ATCP, MXP, MSP, MSDP, GMCP, etc. La documentazione relativa non sempre è semplicissima da reperire e alle volte non aggiornata per cui un po’ da tribolare nell’implementazione sicuramente c’è: senza dubbio però sono strumenti che adempiono al compito.

Scelto quindi il protocollo occorrerà:

1. implementarlo nel codice del MUD
2. indicare all’utente finale uno o più client in grado di interpretare il “sub-dialogo” di cui sopra e permettere(*) tuttavia il dialogo standard nel caso in cui il client usato dall’utente non supporti il protocollo speciale scelto.

   (*) Alcuni preferiscono non permettere la connessione nel caso il client non supporti il protocollo speciale: ciò capita in particolare in quei mud dove si fornisce un client proprietario realizzato ad hoc.

La parte più antipatica è sicuramente la prima. Si tratterà infatti, in generale, di andare in giro per il sorgente del mud ad incapsulare all’interno di particolari TAG le informazioni extra che intendiamo fornire al client parallelamente al dialogo standard in un dato punto di esecuzione del codice.

Ad esempio: nel momento in cui un giocatore passa da una stanza ad un’altra nel 90% dei mud viene invocata una funzione adibita a tal scopo (…move_char in diversi sorgenti…). Ecco: lì probabilmente vorremo andare ad inserire uno dei nostri TAG contenente le informazioni speciali che in quel preciso momento vogliamo inviare al client per mostrare una certa immagine associata al luogo in cui siamo giunti (…una mappa ad esempio).

Non è difficile ma può diventare abbastanza capillare ed invasivo come intervento. Vero è che con qualche MACRO ben studiata o direttiva di compilazione condizionale si può per lo meno rendere tutto reversibile con un click, ma resta una modifica abbastanza impattante sul codice base a seconda di quanto si vuole estendere poi le funzionalità del client.

Un vantaggio che si ha scegliendo un protocollo diffusamente supportato, ed il giusto client, è che si potrà poi attingere anche a script rilasciati magari da altri MUD in ragione della condivisione del protocollo. E siamo cosi’ arrivati al punto (2): il client.

Qui posso dirvi poco… personalmente sto fermo a zMUD 3.62a (gratuito) da decenni ed un computer in cui l’HD gira coi criceti sulla ruota e che non mi permette di installare praticamente nulla delle cose recenti. Comunque tra i più generosi in fatto di supporto ai protocolli extra che ho trovato menziono: MUSHClient, TinTin, MUDLet e CMUD.

A MODO MIO.

Non avendo grande interesse per la grafica e avendo sempre in mente l’idea che un domani potrei volerla togliere con un click e non semplicemente disattivarla, ho preferito in qualche modo disassociarla dal codice del MUD anche per avere eventualmente due fronti di manutenzione ben distinti (…fronte che vantaggiosamente potrebbe pure essere gestito da terzi essendo indipendente). E’ un esperimento: magari non funziona nemmeno bene, però vi dico come ho fatto.

I MUD sono nel 90% dei casi un grande LOOP (ciclo) che periodicamente svolge determinate funzioni. Io banalmente ho inserito una unica funzione del tutto isolata dal resto del codice che raccoglie e fornisce i dati extra per il client. La funzione in sè può essere tranquillamente manutenuta altrove, ed il formato nel quale le informazioni extra sono raccolte (protocollo) può essere di un qualunque tipo (anche uno di quelli sopra menzionati in modo da permettere la compatibilità coi client più diffusi). In sostanza viene fornito solo un punto di attivazione.

L’immediatezza dell’informazione al client può o meno essere preservata a seconda del tipo di implementazione (sincrona o asincrona) ma nella maggior parte degli utilizzi cambia poco. Intendo dire: se voglio una maschera che tenga d’occhio gli “incantesimi attivi”, mi cambia molto se ottengo l’informazione 200 o 300ms dopo? E poi molto dipende dalla macchina in uso: il mio server ad esempio impiega piu’ di 10 minuti (cronometrati) a compilare il mud, ovvero è una macchina ridicolmente vecchia. Ciononostante al momento mi pare non dia problemi. Però, ripeto ancora una volta, tutto è molto in fase di test, ovvero già anche solo domani potrei dire “esperimento fallito”.

Quando occorre un’informazione realmente immediata utilizzo invece da anni con successo un altro sistema come descritto in un precedente articolo, ovvero – riassumendo – inserisco delle sequenze colori ansi non valide (due in particolare) che i client standard semplicemente ignorano considerandole probabilmente errori (e passano oltre) cosi’ come vengono ignorate dal MUD-server, ma che invece il WEB-server del “MUD.it client” interpreta andando ad insere gli elementi extra del caso.

La cosa bella è che anche in questo caso, a meno di necessità particolari, non occorre intervenire sul codice del MUD. Faccio un esempio: vogliamo che quando il pg entra in una stanza (o guarda, etc) compaia il disegno della stanza? Bene, io non faccio nulla ed invece il builder inserirà nella descrizione della stanza il codice speciale ansi che punterà ad uno script dove potrà esserci di tutto e di più. Esempio:

La bottega del fabbro. (…nome della stanza)
E’ una bottega piena di incudini etc…. (…descrizione della stanza)

…diventerà:

/033[70;numeroLa bottega del fabbro.
E’ una bottega piena di incudini etc….

Dove compare “numero” io potrò inserire il rimando numerico ad un file in cui ci potrà essere il codice (html nel caso del MUD.it) che il client utilizzerà per caricare effetti multimediali di qualsivoglia genere. La sequenza impiegata come potete notare ha la forma della classica sequenza escape per i colori ANSI.

E’ possibile anche creare visualizzazioni condizionali(*) in modo che ad esempio non compaiano contemporaneamente un eventuale disegno ascii di un oggetto (pensato per gli utenti tradizionali) e l’immagine vera file.jpg relativa allo stesso oggetto destinata però agli utenti del webclient. Per il dettaglio rimando però all’articolo menzionato. E’ uno strumento piuttosto potente se uno ci pensa in mano al builder. Può infatti essere utilizzato anche all’interno dei “MUDprog” (gli addetti ai lavori sanno di che parlo) e realizzare cose anche molto particolari.

(*) Tempo fa, a proposito di visualizzazioni condizionali, feci un esperimento di traduzione simultanea delle descrizioni appoggiandomi a google translator. Funzionava! Abbandonai poi la cosa ma ora non riesco proprio a ricordare per quale motivo, però è stato un esperimento interessante.

L’ultimo anello della catena è il web-server che si pone da medio nella comunicazione tra client e mud-server e che si occupa appunto di smistare le comunicazioni facendo inoltre da interprete. Questa operazione, nell’uso standard dei protocolli menzionati all’inizio, viene di consueto svolta tanto dal MUD-server quanto dal client se idoneo. L’idea è quindi di fare…

Come si può vedere il mud-server nel secondo caso non muta il proprio modo di comunicare: in altri termini per il MUD-server il WEB-server diventa come un qualunque client connesso ed è il WEB-server a fare il lavoro sporco. In realtà nemmeno il WEB-server utilizzerà protocolli particolari non essendo per esso prevista una connessione con clients differenti da quello dedicato: il dialogo col client potrà infatti avvenire apertamente senza necessità di un sub-dialogo.

Per chi fosse interessato non ho nascosto nulla del codice usato nel MUD.it client (minimizzandolo ad esempio) in uso su RdA, per cui potete facilmente vedere come funziona. E’ stato fatto tutto molto alla buona senza ottimizzare assolutamente nulla anche perchè stando lato client mi interessava ben poco, tralasciando poi il fatto che di JS, CSS, e compagnia bella ne capisco molto poco. Magari un giorno con calma ci rimetterò mano facendo ordine e pulizia (improbabile). Se vi va però potete farlo voi 🙂

Anzi, butto li’ una proposta: anni fa, quando resi disponibile il sorgente del server-client modificato da me per la connessione ai MUD, ci fu un ragazzo (Riccardo, alias Eclipse, ora di istanza in inghilterra che saluto) che fornì un server grazie a cui per un annetto fu possibile giocare ai MUD italiani registrati su MUD.it (LeU, Clessidra, TS2, etc). Già in quella prima versione qualunque mud poteva inserire gli elementi grafici col sistema del codice ansi fasullo a costo zero (senza toccare il proprio codice intendo).

Visto che a breve, questione di giorni proprio, MUD.it cambierà gestione (io mi “ritiro”) ed il portale sarà lasciato in dono ai vari gestori di MUD in base ad un accordo siglato con una associazione, potrebbe essere una occasione buona per far rivivere il webclient se il futuro host offrirà le risorse necessarie. Dopotutto cosa c’è di piu’ bello di poter scrivere sull’indirizzo del browser l’indirizzo del MUD e giocare senza dover installare nulla e, a mio parere, con una qualità paragonabile ad un vero client? E non avendo legami particolari col codice potrebbe essere manutenuto un po’ da chi vuole. Chissà!

In ogni caso, per un esempio applicativo di quanto descritto in questo articolo, rimando alla seconda parte che però è strettamente relativa a RdA.

Ciao e buone feste!
Matteo