Nota bene: l'articolo proposto in questa pagina è proprietà degli autori e non può essere distribuito o riutilizzato in alcun modo o forma senza il loro consenso scritto.
Le informazioni qui riportate risalgono alla data di pubblicazione dell'articolo e non è detto che siano ancora valide o che rispecchino lo stato attuale dei programmi, le posizioni delle persone interpellate o degli autori stessi.

Introduzione

Internet ha indubbiamente mutato l'utilizzo del computer sia nel campo lavorativo, sia in quello hobbistico. Proprio in questo settore si è assistito alla nascita e rapidissima espansione del gioco via rete.
Oggi, infatti, è possibile sfidare al gioco preferito, sia esso un gioco da tavolo, un simulatore o uno spara e fuggi, non solo l'amico seduto accanto, ma anche qualcuno che si trova dall'altra parte del pianeta e che magari incontriamo per la prima volta proprio in quel momento, come avveniva, ai tempi dell'infanzia, nelle ludoteche cittadine.
In queste pagine ci occupiamo sia della realtà Amiga, presentando alcuni dei "Net Games" per la nostra piattaforma, sia degli aspetti più generali che comunque riguardano direttamente chi vuole sperimentare il gioco via rete. Non mancano infatti un vademecum per gli utenti di giochi 3D come Quake ed approfondimenti per i programmatori. A chi ama il buon vecchio testo senza tanti fronzoli è invece dedicata la parte relativa ai MUD.
Iniziamo dunque analizzando alcuni dei titoli più significativi realizzati nel corso degli ultimi anni per Amiga.

Programmi

AmiSlate

AmiSlate (distribuito come "DonationWare") non è propriamente un gioco, anche se il suo fine è comunque ludico. Lo si può definire "il Deluxe Paint dei poveri", trattandosi di un "painter", dotato delle funzioni basilari tipiche di tali software: tracciamento linee, quadrati, cerchi, riempimento, ecc.


Immagine Il castello della principessina Natascia del ducato di Torino (AmiSlate).

Ciò che lo rende speciale, oltre al funzionamento in rete (cosa che consente a due persone anche lontanissime di disegnare sulla stessa tela virtuale), sono alcune funzionalità extra. Innanzitutto la possibilità di vedere il movimento del mouse dell'altro utente e disegnare realmente "a due mani" (ma anche di giocare agli inseguimenti...). Vero punto di forza è però l'interfaccia ARexx, tanto potente da avere valicato la natura stessa del programma, permettendo la creazione di script esterni per giocare a Dama, Othello, Scacchi, Tris, ecc. Non mancano, poi, la possibilità di memorizzare script contenenti le azioni effettuate (ad esempio per riprodurre rapidamente un disegno) o di caricare un brush IFF. Per brevi messaggi il programma supporta anche una chat.
AmiSlate, che ricordiamo essere "DonationWare", è indubbiamente ben congegnato: la velocità di disegno e interazione con l'altro utente sono ottime anche in caso di linee intasate. Neppure le risoluzioni sono un ostacolo poiché il programma, tramite vari accorgimenti (si veda l'intervista con il programmatore), permette a persone con modalità di schermo differenti di disegnare (quasi) in piena libertà. Esistono comunque dei problemi, dovuti soprattutto all'età del prodotto e al fatto che, causa crash di un HD, i sorgenti delle nuove versioni sono andati persi ed il progetto è stato abbandonato. AmiSlate è scarsamente compatibile con l'RTG: lo si può utilizzare su schermi non nativi, ma sempre entro gli 8bit di profondità. Un numero maggiore di colori comporta, infatti, il vistoso rallentamento di tutte le funzioni di disegno. Altro baco è l'impossibilità di salvare un'immagine: scegliendo la relativa opzione otterremo il blocco dell'Amiga. Si tratta comunque di noie minori, facilmente aggirabili, che non pregiudicano l'uso del programma.

Netris

Tetris, il puzzle per computer forse più famoso al mondo, vede in questo titolo freeware l'ennesima trasposizione, resa però speciale dal gioco in rete. Fino a quattro persone possono partecipare contemporaneamente ad una "non stop" di partite, sempre più veloci e frenetiche. L'interazione fra i giocatori è costituita da una chat e dal fatto che, quando qualcuno distrugge due o più file di mattoncini in una volta, la mole di mattoni degli altri giocatori aumenta proporzionalmente. Il gioco prevede anche la condivisione dei punteggi ed eventualmente dei suoni (ma quelli di base sono più che adeguati). L'azione è coinvolgente, come sempre con Tetris, ed il gioco fra più persone crea situazioni spesso incontrollabili ma sempre fonte di divertimento.


Immagine Mattoncini in caduta libera... (Netris).

Netris è stata una delle prime applicazioni basate su AMarquee, la libreria pensata proprio come base per giochi e chat multiutente (si veda l'intervista con l'autore, in queste pagine). Il programma utilizza il meccanismo client/server: una persona decide di fare da server e le altre vi si collegano in qualità di client. Il tutto funziona bene, ma risulta un po' scomodo per i meno esperti poiché tutte le opzioni, compreso l'indirizzo IP del server, si devono impostare tramite i tooltype dell'icona associata al programma.
Difetti veri e propri non ve ne sono. La GUI, pur se decisamente spartana, fa il suo dovere ed il gioco non richiede molte risorse e può quindi essere utilizzato, sia come client che come server, anche con processori non eccessivamente potenti. L'unico problema che abbiamo rilevato riguarda i rallentamenti: a differenza di AmiSlate, infatti, Netris sembra risentire maggiormente di eventuali intasamenti della linea. Nel peggiore dei casi il collegamento andrà in time-out, senza tuttavia che l'utente ne venga informato. In quest'evenienza non resterà che rinunciare ad altre partite poiché, rilanciando il client, si otterrebbe soltanto un blocco dello stesso. Si tratta comunque di problema di rara occorrenza.

Battle Duel

Traendo ispirazione da un vecchio gioco per Commodore 64, Artillery Duel, il tedesco Jochen Terstiege ha realizzato BattleDuel, un rifacimento shareware, poco esigente in termini di requisiti (OS2.04 e 1 MB di Chip RAM) ma estremamente divertente.
Lo schema di gioco vede contrapposte due (quattro nella modalità di doppio) postazioni missilistiche, in pieno stile "cannoni di navarone", armate di tutto punto e pronte battagliare, fino alla distruzione della torretta nemica, sullo sfondo di rilassanti panorami bucoloci generati da VistaPro e Scenary Animator.
Il programma, fornito con uno script di installazione a corredo, supporta ECS, AGA, schede grafiche (in tutte le risoluzioni video) e, dall'ultimissima versione rilasciata, il sistema di risorse audio AHI.


Immagine Minacciose cannonate riecheggiano nella valle... (Battle Duel).

Le opzioni, oltre ad offrire una vasta gamma di scelte che definiscono, ad esempio, difficoltà ambientali (influenza del vento sulla traiettoria del colpo), tipo di gioco (conquista, allenamento o torneo) o numero di partecipanti, contemplano la possibilità di effettuare avvincenti partite con un giocatore "remoto" via Internet. Il tutto è configurabile facilmente tramite GUI (pannello "Network"), immettendo l'IP dello sfidante a cui collegarsi o ponendo "in attesa" la macchina impostata come server. In quest'ultimo caso andrà inserita nel proprio stack TCP, esattamente in db/services, la stringa "BattleDuel 3000/tcp" affinché vengano accettate nuove connessioni. Per inframezzare le sfide via rete, poi, è prevista la facoltà di comunicare con l'avversario tramite una comoda finestra di chat "in tempo reale" suddivisa in due sezioni.
Nonostante possa apparire scarsamente longevo e non esente da pecche (i colpi tendono spesso a confondersi con i fondali), BattleDuel può essere considerato a pieno merito un buon titolo, grazie anche alla completezza delle sue opzioni, all'intuitività della sua interfaccia e ad un'inappuntabile gestione della funzione di "netplay".

Freeciv

Dietro il nome Freeciv si cela l'ambizioso progetto di realizzare un clone freeware e multipiattaforma di "Civilization", il capolavoro di Sid Meier, ponendo però maggior attenzione sulle funzionalità di rete e sulla configurabilità dal lato utente.
Dal titolo Microprose Freeciv ha attinto i peculiari elementi strategici, le metodiche di gioco, lo stile grafico e le finalità: condurre la propria civilizzazione dagli albori fino alla conquista degli spazi siderali, imponendo la propria egemonia sulle altre civiltà.
La versione Amiga, ferma a un port preliminare del 1997, ha ripreso di recente lo sviluppo grazie al tedesco Sebastian Bauer, che ha allineato il programma al recentissimo rilascio (1.10) del sorgente Linux. Nonostante i requisiti, almeno sulla carta, possano apparire minimi (020, OS 3.0, MUI e le librerie render e guigfx), è consigliabile la presenza di 040 e, soprattutto, di scheda grafica.


Immagine Il client Freeciv Amiga all'opera.

Per esaltare gli aspetti relativi al divertimento in rete, il programma è stato suddiviso in due parti: un server, adibito alla gestione delle informazioni (intelligenza artificiale) e all'impostazione di tutte le variabili di gioco (dimensioni della mappa, numero unità, città ecc.), e un client, una "finestra sul mondo" che permette al giocatore di controllare la propria civiltà e di comunicare con gli avversari tramite un sistema di "chat" vagamente somigliante a IRC.
Dai test fatti, benché Freeciv offra allettanti caratteristiche (lunghe sfide in immensi planisferi sino a 14 participanti, intelligenza artificiale evoluta per la gestione dei giocatori e via dicendo), il port Amiga, nella fattispecie il server, risulta talvolta instabile. L'interfaccia MUI del client, completamente riscritto per adattare le classi grafiche, appare pratica e intuitiva, quantunque ancora lacunosa rispetto alla controparte Linux. Nulla da dire sulla gestione di rete che non soffre mai di "intasamenti" di linea, se non inizialmente (quando il server invia ai client le sostanziose coordinate di gioco).

HBMonopoly



Immagine 1 ai dadi? Tutto è possibile ai redattori di Amiga Life! (Fratricide sfide redazionali in una tavola "particolare" di HBMonopoly).

Chi non si è mai cimentato, magari durante un'uggiosa giornata invernale in un'estenuante partita a Monopoly, il famosissimo gioco di società Parker Brothers, sognando di diventare il più abbietto tra i capitalisti?
Tra i vari tentativi di riproporre su Amiga in chiave elettronica lo storico passatempo da tavola, quello ad aver riscosso maggior seguito e successo è stato il freeware HBMonopoly del tedesco Holger Beer.
Giunto alla versione 2.4 (ad esser recensita su Amiga Life 110, rubrica giochi, era stata la 2.2), HBMonopoly offre l'apoteosi del divertimento proprio grazie alle funzionalità di rete basate sul sistema client/server, che permettono ad un massimo di otto giocatori di organizzare lunghi e appassionanti tornei via Internet.
Da segnalare, inoltre, le interessanti opzioni di contorno che prevedono la possibilità di personalizzare il gioco fin nei minimi dettagli: nuove pedine, tabelloni alternativi e alcune norme regolamentari non presenti nell'originale (ad esempio una slot machine nella casella di parcheggio).

Approfondimenti

Quake & C.:
problemi reali dei mondi virtuali in Rete

Anche Quake, celebre titolo del genere "squarta orripilanti mostri in un mondo 3D in soggettiva", supporta il gioco via rete e, anzi, tale funzionalità aggiunge una nuova dimensione al gioco: se già una partita da soli trae in inganno la percezione della realtà, tanto da far memorizzare alcuni paessaggi come se si fossero visitati realmente, figurarsi cosa significa condividere questa esperienza con altre persone, magari gente lontanissima! Il successo è stato tale che in rete sono nati server che danno accesso a piccoli mondi virtuali dove a qualsiasi ora è possibile incontrare altri giocatori e partecipare a scontri all'ultimo sangue oppure collaborare per portare a termine un livello tutti assieme.
A seguito del rilascio da parte di ID Software dei sorgenti del motore grafico di Quake e QuakeWorld (attenzione perché i datafile contenenti il gioco restano commerciali), anche gli utenti Amiga possono giocare degnamente a questo titolo grazie ai port PPC. Ne esistono sia per WarpOS che per la "ppc.library" di Phase5 ed è disponibile anche una versione "OpenGL" che sfrutta le schede 3D per offrire maggior velocità e qualità dell'immagine.
Oltre al Quake originale è possibile installare le varie conversioni totali, fra le quali spicca "Team Fortress", una sorta di "ruba la bandiera e fai a pezzi l'avversario", giocabile anch'essa via rete.
Fin qui la teoria. La realtà a volte può riservare brutte sorprese, ad esempio l'impossibilità di movimento o morte per una fucilata da qualcuno che sembra spuntare dal nulla. Tutto questo accade perchè simulare un mondo 3D complesso, con giocatori umani che interagiscono fra di loro e con gli elementi del gioco, implica molti problemi in più rispetto a giochi ove la mole di dati da scambiare è minore e magari gli utenti giocano a turno. come nel caso di HBMonopoly.
Ma analizziamo il problema dalle sue origini. Doom, il capostipite di questo genere, utilizzava un sistema di comunicazione punto-punto come molti vecchi giochi che consentivano il collegamento di due computer via null-modem. Ogni giocatore si muoveva in una simulazione completa del mondo 3D ed i programmi si limitavano a scambiarsi informazioni sulle azioni dei rispettivi utenti e qualche verifica di coerenza interna. Il meccanismo richiedeva poca banda e funzionava bene con due giocatori e fintanto che la connessione restava stabile. Con più giocatori ognuno era costretto a comunicare con tutti gli altri, con risultati facilmente prevedibili in fatto di velocità. Se poi la connessione diventava instabile si andava incontro a blocchi e
timeout.


Immagine Prove tecniche di assalto (Quake).

L'approccio necessario per ottenere risultati migliori è basato sul concetto di client e server. I client trasmettono le direttive dell'utente ad un server centrale che provvede ad aggiornare lo stato del mondo 3D e ad informarne i client dei giocatori. In questo modo però si viene a creare un altro problema: ogni volta che l'utente effettua un'azione, sin anche un singolo passo in avanti, per vederne l'effetto deve attendere che il server processi l'evento e invii le direttive. In caso di rallentamenti si ottiene la sgradevole sensazione di scarsa reattività da parte del gioco. Questo fenomeno è denominato "Roundtrip latency" ed è il principale problema dei giochi Internet.
Esistono varie strade per affrontare o attenuare i rallentamenti nella comunicazione client-server-client. Nell'ambito delle simulazioni militari viene utilizzata una tecnica detta "Dead Reckoning" che, in caso di mancata risposta dal server, si basa sullo stato corrente del mondo 3D per cercare di prevedere cosa avverrà in seguito. E' chiaro che questo può funzionare con gli elementi gestiti dal computer, non per i giocatori umani. Inoltre un tale approccio può portare ad un certo disorientamento qualora, a collegamento ripristinato, si scopra che le previsioni del client non corrispondono a quanto realmente avvenuto durante l'interruzione. Tale soluzione, insomma, pone una pezza probabilistica all'aggiornamento dell'ambiente circostante, senza per altro risolvere il problema della reattività.
A questo è dedicata una tecnica detta "POV Latency Compensation" di cui Quake fa uso. Sostanzialmente il client arroga a sé la gestione degli eventi che non mutano lo stato del mondo 3D. In caso di interruzione del collegamento col server l'utente potrà ancora guardarsi attorno, ma non sarà in grado di muoversi o sparare. Non è molto, ma riduce un po’ la sensazione di immobilità. Gestire in locale movimento e spari creerebbe seri problemi di coerenza fra client e server. Cosa accadrebbe, infatti, se l'utente di un client temporaneamente isolato sparasse ad un avversario che in realtà (ovvero nel contesto del server) non si trova più lì?
Come si può vedere il problema non è di facile soluzione, e le tecniche esistenti possono solo ridurne gli effetti più immediati. L'unica vera soluzione è disporre di una buona connessione. Una linea a 33,6 kb va bene, a patto di non fare altro e che il provider metta a disposizione sufficiente banda. E' poi opportuno usare un server abbastanza vicino. Non conviene giocare con un'altra persona direttamente: il client sarebbe penalizzato, a meno che chi fa da server non usi almeno ISDN. Un avviso infine a chi paga Internet a traffico: una partita di qualche ora a Quake genera parecchi megabyte di dati sia in entrata che in uscita!

Da programmatore a programmatore

Se leggendo il dossier vi è venuta voglia di scrivere un gioco, oppure se siete attratti dagli aspetti puramente tecnici dell'argomento, consigliamo la lettura di questo riquadro.

Jeremy Friesner è l'autore di AmiSlate, Netris e della "AMarquee.library", un versatile strumento di sviluppo per questo tipo di software. In questa breve intervista Jeremy descrive le problematiche affrontate durante lo sviluppo dei suoi titoli.

D: Abbiamo visto che con libreria e server AMarquee hai tentato di consolidare una base di partenza per la relizzazione e l'utilizzo di applicazioni, ludiche e non, fruibili in rete. Quali sono state le difficoltà incontrate durante lo sviluppo? Che tipo di vantaggi offre, in sintesi, all'utente e al programmatore?

R: AMarquee offre parecchi vantaggi agli sviluppatori. Il principale è che consente ai loro programmi di comunicare in maniera efficiente con molti computer alla volta. Il metodo di comunicazione standard su Internet è uno stream TCP, che è abbastanza simile ad una chiamata telefonica: un computer ne chiama un altro e i due possono interagire fra di loro. Ma nel caso di giochi multiutente o di chat, è necessario entrare in contatto con decine o centinaia di altre macchine contemporaneamente e la gestione di così tante connessioni TCP è complessa da realizzare. E c'è anche il problema di individuare gli altri sistemi. A meno di non conoscere in partenza il loro indirizzo IP, non c'è modo di sapere chi altro è online e pronto ad accettare la connessione
Con AMarquee, comunque, un programma deve effettuare una singola connessione al server. Il server AMarquee lo informa di quali altri client sono collegati e può trasmettere loro dei messaggi (nella più ampia accezione del termine, NdA) qualora il programma lo richieda. Poiché tutti i messaggi giungono al server principale, prima di essere reindirizzati ai client destinatari, diventa semplice sviluppare tecniche di "broadcast" o "multicast": è sufficiente inviare una sola copia del proprio messaggio al server, aggiungendo un'espressione regolare che specifica a chi è diretto, e sarà il server ad occuparsi materialmente dell'invio a ogni client che corrisponde all'espressione.
Inoltre, il server AMarquee permette ai programmi di salvare messaggi in una memoria interna accessibile agli altri client. Questo può rivelarsi utile poiché i sistemi che si collegheranno successivamente non avranno bisogno di contattare il client per richiederli, trovandoli già a loro disposizione. Essi potranno inoltre "sottoscrivere" i messaggi di un client in modo che, qualora dovesse essere inserita una nuova versione degli stessi, il server possa provvedere all'invio automatico. Sostanzialmente, il server AMarquee è un database multiutente dinamico e centralizzato, che è esattamente ciò che serve quando si vogliono far operare molti computer all'interno di un ambiente virtuale condiviso.
Molte delle difficoltà che ho incontrato durante lo sviluppo di AMarquee derivano dalla natura multithread del codice. Differentemente dal codice singlethread, che effettua le stesse cose ogni volta che lo si usa (e con le stesse condizioni iniziali), il codice multithread è molto, come dire, "viscido". Ci sono un numero infinito di combinazioni nelle quali i vari thread possono venire eseguiti ogni volta che si usa il programma, e se non si è estremamente cauti nel farli coesistere tramite semafori e simili, ci si ritroverà con un programma che funziona la maggior parte delle volte, ma che in certi casi salta per cause apparentemente misteriose, oppure ruba memoria in particolari situazioni. E poiché il server AMarquee è progettato per operare anche intere settimane sotto un OS privo di memoria protetta, era molto importante che non si piantasse mai e che non rubasse memoria.
L'altro interessante problema con AMarquee riguardava la necessità di evitare che le persone cercassero di sabotare il server. Ovviamente nessuno lancerebbe un server AMarquee se ciò significasse consentire a chiunque di collegarsi al proprio Amiga e renderlo inutilizzabile. Per controllare questo problema ho realizzato un intero sistema di tracciamento delle risorse, in modo che il possessore del server possa definire regole del tipo "nessun singolo utente può allocare più di 100k di RAM sul mio sistema", oppure "nessun utente da questo domain può collegarsi", o ancora "i client di questo tipo non sono ammessi sul server".

D: Uno dei tuoi programmi più spettacolari è Amislate. Nonostante risenta degli anni, offre una caratteristica molto interessante: permette a due persone di disegnare insieme pur utilizzando risoluzioni (e pixel ratio) completamente diverse. Che difficoltà ha comportato l'implementazione di questo meccanismo?

R: AmiSlate è stato il mio primo programma di rete su Amiga, e quindi molta delle difficoltà consistevano semplicemente nell'apprendere la API dei socket sufficientemente bene da poter realizzare ciò che volevo. Uno dei traguardi che mi ero prefisso per AmiSlate era che il traffico della rete non avrebbe mai dovuto interferire con il disegno (cioè l'utente deve essere in grado di disegnare in qualsiasi momento, indipendentemente da cosa sta facendo il modem). E' emerso che con la API dei socket ciò può essere più complesso di quanto sembri, perché, se l'utente disegna molto in fretta ed il buffer di output si riempie, la funzione "send()" blocca il programma fino a quando non ci sarà spazio per nuovi dati da inviare. Per cose come l'FTP può andare bene, ma l'utente non gradirebbe dover smettere di disegnare sino alla ripresa della trasmissione dei dati via modem. Alla fine, per risolvere il problema, ho optato per una gestione non bloccante dell'I/O e ho realizzato un mio sistema di gestione delle code (lo stesso problema l'ho dovuto affrontare con AMarquee).
L'altro grosso problema, come hai evidenziato sopra, è gestire l'evenienza in cui i due utenti utilizzano modalità di schermo differenti. Per esempio, uno dei due può essere in 640*480 a 8 colori, quando l'altro è in 1280*1024 a 256 colori. AmiSlate tenta di individuare i colori più vicini a quelli scelti, se non sono disponibili (una tecnica utilizzata anche dai browser, NdA), ma non lo fa nel migliore dei modi. Un altro problema era la sincronizzazione della dimensione delle finestre. Ho stabilito che entrambe devono essere della stessa dimensione in qualsiasi circostanza, il che significa che quando un utente ridimensiona la propria, il suo AmiSlate invia un messaggio al computer remoto indicandogli di fare altrettanto. La soluzione funzionava, tranne quando entrambi ridimensionavano nello stesso momento... in quel caso si otteneva il simpatico effetto per cui ogni programma ridimensionava la propria finestra, inviava all'altro l'ordine di fare la medesima cosa, riceveva il messaggio da remoto, ridimensionava nuovamente e reinviava... e le finestre continuavano a ridimensionarsi in eterno. Alla fine ho introdotto un po' di controlli per aggirare il problema, ma era una situazione che non mi sarei mai aspettato.
Una parte con cui mi sono veramente divertito è stata l'aggiunta del supporto ARexx. Questo perché, con ARexx, AmiSlate è diventato più di un programma di disegno; lo si può usare per giocare a scacchi, tris o backgammon, o qualsiasi altro gioco si possa scrivere in ARexx. Probabilmente il tempo che ho dedicato a programmare gli script è lo stesso di quello che ho usato per scrivere AmiSlate stesso!

Per approfondire alcune problematiche legate al traffico generato dalle applicazioni di rete e alla sicurezza ad esse legata, abbiamo poi interpellato il tedesco Holger Beer, il programmatore dell'ottimo HBMonopoly.

D: Spesso, utilizzando servizi interattivi quali IRC, vengono alla luce problemi di ritardo (in gergo lag), tra client e server, con conseguente perdita di sincronia. Il tuo programma sembra non soffrirne, neppure quando la banda è impiegata, nella quasi totalità, in altri trasferimenti. Quali sono, secondo te, le ragioni? Dipende da approcci diversi nella gestione del trasferimento dei dati?

R: HBMonopoly comunica attraverso normali socket TCP e questo è ciò che probabilmente fanno anche molti altri programmi. Forse reagisce abbastanza rapidamente in quanto, durante il gioco, è necessario trasferire solo pochi byte. Il ritardo su IRC è maggiore poiché i propri interlocutori possono essere collegati su server diversi e quindi vi sono più punti di passaggio tra loro.

D: Recentemente ci è capitato di vedere una versione modificata di HBMonopoly (vedi foto a fianco, NdA) che consente di scegliere il risultato dei dadi. Fortunatamente si trattava solo di uno scherzo di un programmatore e non verrà diffuso. Tuttavia ci ha fatto riflettere: hai mai pensato all'opportunità di implementare un controllo di sicurezza sui dati di una partita in rete? Quali problematiche implicherebbe realizzare un simile meccanismo?

R: Un tale trucco ha senso solo per dati come il risultato dei dadi che viene trasferito via rete, ma non può essere inserito direttamente dall'utente.Una soluzione per evitare eventuali imbrogli sarebbe centralizzare la generazione dei numeri casuali sul server (in questo caso solo il server può barare). Ho scelto questo sistema, al momento, per le carte degli imprevisti e delle probabilità.
Un'altra strada potrebbe essere l'uso di numeri pseudo casuali con lo stesso seme (il valore di partenza richiesto dalla funzione che genera i numeri) su server e client. In tal modo tutti i programmi conoscerebbero in anticipo il risultato di ogni tiro, eliminando la necessità di effettuare trasferimenti e la possibilità di imbroglio.

I MUD

L'articolo dedicato ai "MUD" è stato scritto da Gabriele Greco.

Vocabolarietto termini essenziali

Indirizzi utili

Gli indirizzi sono stati verificati e aggiornati a maggio 2019.