BASIC Computer Games

 

Esplorando i meandri di internet, a volte capita di riesumare veri e propri reperti archeologici, e se parliamo di retrogaming e retrocomputing, è un dovere, almeno per me, sottrarli all'oblio e riportarli alla luce del sole. Così avvenne per caso di trovare la scansione in PDF dello storico libro di David H. Ahl, editor della rivista "Creative Computing", dal semplice ma avvincente titolo "BASIC Computer Games". Il libro risale al 1978 ed è l'edizione aggiornata ed arricchita di "101 BASIC Computer Games" del 1973, sempre opera di David H. Ahl.

La mia fortuna si è però spinta oltre ed ho trovato persino qualcuno che ha trascritto i listati dei giochi, stampati nel libro, rendendoli disponibili a chiunque voglia riassaporare le gioie (e i dolori) del BASIC e del gaming dell'epoca. Vi invito, dunque, a scoprire "Lunar Lander", "Hamurabi", "Super Star Trek", "Hurkle", "Mugwump" ed altri storici titoli sviluppati o convertiti nel nostro caro, vecchio, onesto BASIC.

Nota: nell'edizione del 1978 di "BASIC Computer Games" i giochi sono stati tutti convertiti nel Microsoft BASIC, mentre in origine erano scritti in sei diversi tipi di BASIC. David H. Ahl decise allora di uniformare i codici sorgente dei giochi al dialetto BASIC più popolare nel 1978, per l'appunto, il Microsoft BASIC.

 

Qui trovate le scansioni del volume di Ahl.

Cliccate qui per i giochi e qui per l'interprete BASIC necessario ad avviarli (ma ne potete usare uno qualsiasi).

 

Ed ora... buon retrogaming!

Old Programming Games - Parte I
Da Crobots (1985) a Jrobots (1995)

Programming Game... che roba è?
No, non avete letto male. Il titolo di questo articolo cita proprio i “programming games” e non il “game programming”.

Immaginate un'area di un chilometro quadrato su cui scorrazzano, a folle velocità, robot cingolati che si individuano mediante impulsi radar e si sparano potenti cannonate. Da ciò che vi siete figurati mentalmente, togliete la moderna grafica tridimensionale di una PS4, sostituitela con una vista planimetrica a caratteri, magari visualizzata da un bel monitor a fosfori verdi, e avrete Crobots, il primo “programming game” a girare su DOS.

A questo punto molti si chiederanno che cos'è un “programming game”?
Si tratta di un gioco, come dice il nome, ma molto particolare. Un gioco per programmatori. Nel caso di Crobots, i giocatori dovevano scrivere, in un linguaggio molto simile al C, gli algoritmi che gestivano il comportamento di questi “robot” stilizzati, cercando di realizzare la miglior strategia per sopravvivere nell'arena, in cui vigeva la logica del “ne rimarrà soltanto uno”.
Un gioco, quindi, in cui non si agisce in prima persona: si crea un'intelligenza artificiale e si osserva il suo comportamento contro altre “intelligenze” programmate da altri giocatori.
Descritto in questo modo, sembra un gioco astratto e poco coinvolgente, tuttavia chi avesse provato sa che ci si affeziona alle proprie creature, si gioisce quando sopravvivono e si soffre quando soccombono, ma il dolore passa presto e si comincia subito a escogitare migliorie da apportare al codice per ottenere azioni difensive e offensive più efficaci.

Di giochi di questo genere, pur non essendo molto popolari, è piena la rete. Crobots è stato uno degli antesignani e ha generato una quantità incredibile di cloni, alcuni dei quali estinti da anni. A sua volta, però, era una sorta di clone di RobotWar, un gioco per il PLATO computer system degli anni '70 (che consisteva in migliaia di terminali grafici connessi a una dozzina di mainframe), culminato in una versione per Apple II del 1981.

2. Crobots... a programming game for programmers, or aspiring ones
Crobots vide la luce nel dicembre del 1985 grazie a Tom Poindexter che lo distribuì come shareware. In quella lontana epoca ante-internet, quando imperversava la grafica a 16 colori del Commodore 64 e le “avventure testuali” commerciali stavano già andando incontro al loro inesorabile declino, non passò del tutto inosservato.
I punti di forza di Crobots consistevano nel linguaggio ad alto livello, simile al C, e nella VM (virtual machine) che eseguiva il codice macchina ottenuto nella compilazione. Il semplice insieme di funzioni con le quali il giocatore poteva leggere i dati dei sensori (lo “scanner”) e inviare comandi al robot (per regolare la velocità del robot e indirizzare i colpi del “cannone”) ne facevano un gioco interessante per chi aveva voglia di imparare a programmare divertendosi.

Io scoprii Crobots, come altri ragazzi italiani, grazie agli articoli di Corrado Giustozzi sull'ormai mitica rivista MC Microcomputer (non più pubblicata da tempo e disponibile per la consultazione online).
La rivista si è occupata del gioco dal 1990 al 1998 (qui potete leggere il primo articolo sull'argomento). Il redattore che se ne occupava organizzò in tutto otto tornei a cadenza annuale.
Ma la storia di Crobots non si è esaurita con MC Microcomputer. Gli appassionati, soprattutto italiani, hanno continuato a occuparsi del gioco, a produrne versioni che potessero essere eseguite da computer molto più veloci e potenti di quelli del 1985 e su http://crobots.deepthought.it si possono tuttora leggere i risultati dei tornei periodici che vengono organizzati.

E si può addirittura provare l'ebbrezza di vedere Crobots eseguito sui fosfori verdi di un emulatore DOS scritto in JavaScript.

Crobots, quindi, è un gioco di nicchia che ha una storia antica (relativamente ai tempi dell'industria videoludica) giunta fino ai giorni nostri grazie ad autentici appassionati e alla felice intuizione di Tom Poindexter che nel 2013, a 28 anni dalla pubblicazione, ha deciso di rendere pubblici i sorgenti (disponibili qui: http://github.com/tpoindex/crobots/) un tempo disponibili solo per posta, previo pagamento di 20$.

A questo punto, per soddisfare la curiosità del lettore, sarebbe interessante illustrare le dinamiche del gioco, le principali tattiche, citare i campioni.
Per quanto riguarda Crobots, potete fare riferimento ai link che ho riportato sopra. Io, invece, approfondirò questi aspetti relativamente a Jrobots, uno dei tanti cloni che sono comparsi sulla scena e che conosco bene perché... l'ho sviluppato io (per un elenco nutrito di cloni più o meno fedeli si può visitare http://programminggames.org/).

3. Jrobots... a multitasking multiplayer time-sharing programming game
L'ispirazione che ha portato a Jrobots è sicuramente nata da Crobots, ma c'è voluta anche l'esplosione del World Wide Web e la comparsa del linguaggio Java per portare a compimento l'opera. Infatti, anche se l'idea era nell'aria fin dal 1995, ho dovuto aspettare il 1999 perché la tecnologia diventasse matura per ciò che avevo in mente: robot programmati in Java, ciascuno eseguito in un suo thread all'interno di un browser.

Jrobots possiede alcune caratteristiche che lo distinguono da altri cloni.
Innanzitutto, i tornei (che si sono svolti con cadenza mensile per un decennio, dal 1999 al 2009) avvenivano letteralmente online. Come ho già detto, i giocatori programmavano il loro robot in Java, utilizzando gli strumenti di sviluppo originali della SUN, gli stessi con cui si realizzavano le prime applet Java, e ne provavano l'efficacia in un'arena offline. Una volta soddisfatti del risultato, si eseguiva l'upload del codice (una normale classe Java) nell'arena online, dopodiché il robot si poteva cimentare contro avversari creati da altri programmatori per un intero mese.
Questo spiega il “multiplayer”, ma perché nel titolo si cita il “multitasking”? Perché il codice di ogni robot era eseguito, come ho già accennato, in un thread separato. Su alcuni sistemi operativi erano thread simulati, mentre su altri erano thread nativi, a seconda dell'implementazione della Java Virtual Machine su ciascun sistema.
Resta da spiegare il “time-sharing”. L'idea che ha consentito di implementare in modo semplice il gioco, senza aver bisogno di costosi servizi di hosting, è stata quella di far eseguire i tornei dai PC dei giocatori che si collegavano al sito per vedere le classifiche parziali del torneo mensile. Gli incontri, infatti, non venivano eseguiti dal server (e neppure eseguiti sul computer di casa dell'organizzatore, cioè io), ma dai client, cioè nei browser dei visitatori del sito, i quali, per sicurezza, non avevano modo di sapere quali incontri consentivano di disputare col loro “tempo macchina”: vedevano solo le classifiche che, man mano, venivano aggiornate.
In un mese si disputavano migliaia di incontri, senza contare i pareggi, nelle tre diverse categorie: singolo (1 vs 1), doppio (2 vs 2) e a squadre (4 squadre composte da 8 robot ciascuna, cioè 32 robots presenti contemporaneamente nella stessa arena).
Naturalmente una simile realizzazione ha comportato l'adozione di numerosi accorgimenti tecnici sviluppati nel corso degli anni, grazie anche all'aiuto dei migliori giocatori.

Un problema era costituito dalla sicurezza delle applet Java. In Crobots il codice di un robot era visibile a tutti e non avrebbe potuto in ogni caso contenere codice “malizioso”. In Jrobots il codice era compilato nel bytecode Java e quindi illeggibile, perciò l'autore avrebbe potuto aprire dei popup nel browser del giocatore o reindirizzarlo verso pagine esterne. L'unica soluzione praticabile è consistita nel proibire l'uso di determinate classi Java, che potevano essere facilmente individuate in modo automatico dallo script sul server che accettava i robots in upload.

Un altro problema consisteva nel determinare quale fosse il miglior algoritmo di selezione dei robot per i vari incontri. A causa del “time-sharing”, che poteva essere interrotto dal visitatore senza portare a termine determinate partite, si è dovuta ideare una tecnica di selezione pesata.
Un po' come avviene nei tornei di scacchi, dopo una serie di incontri casuali, si procedeva a far scontrare robot di punteggio simile per spareggiarli e ottenere una classifica di merito il più possibile corretta.

Ma il problema principale, che poteva minare alle fondamenta il gioco, era costituito dall'ampio spettro di situazioni in cui il codice dei robot girava. Le classi Java erano eseguite in diversi browser, su differenti implementazioni della virtual machine, su diversi sistemi operativi e su macchine con processori più o meno potenti. Un robot forte in un contesto avrebbe potuto rivelarsi inefficace in un altro (un problema che in Crobots non si poteva verificare per la virtual machine indipendente dal sistema che la eseguiva).
La soluzione venne individuata realizzando un clock virtuale. In pratica, un ulteriore thread, oltre a quelli dei robot, eseguiva del codice di riferimento che scandiva il tempo delle simulazioni. Ciò ha reso più omogeneo il comportamento dei robot su macchine differenti.

Restava solo un ultimo possibile problema: codice “malizioso” avrebbe potuto eseguire cicli che non richiamavano alcuna funzione del gioco o allocare array su array accaparrandosi tutta la memoria (per entrambe le tecniche, l'effetto era quello di “congelare” il browser e l'esecuzione dell'incontro).
Alla fine conclusi che un tale comportamento antisportivo veniva evidenziato dalle classifiche (i robot “dannosi” mostravano un basso numero di incontri disputati) e da un semplice controllo nell'arena offline. Perciò, individuato il colpevole, lo si poteva tranquillamente bannare. Comportamenti di questo tipo si sono verificati, ma molto meno di quanto temessi.

4. Il gioco nel dettaglio
Dopo questa lunga parentesi estremamente tecnica e per molti di certo noiosa, torniamo al gioco vero e proprio. Su YouTube è disponibile un video introduttivo sull'argomento: http://youtu.be/IyqGTuWovrY. Qui di seguito, invece, entro nei dettagli tecnici del gioco.

Il campo di battaglia di Jrobots è costituito da un quadrato di 1 Km di lato. Quando un robot ne urta le pareti, subisce 2 punti di danno su un totale di 100 e il motore si arresta. Non è la cosa peggiore che possa capitare, ma non è neppure la migliore, perché quando un robot raggiunge i 100 punti di danno, viene disabilitato e perciò è meglio evitare gli urti con le pareti (è possibile farlo mediante una specie di semplice GPS).

I robot hanno un motore e possono muoversi in ogni direzione. La velocità massima dei robot è 30 m/s, cioè 100 Km/h, e l'accelerazione è di 5 m/s^2. Questo significa che un robot necessita di sei secondi per raggiungere la velocità massima.
Quando il motore ha lo 0% di potenza, il robot si ferma con una decelerazione di 5 m/s^2, mentre il 100% di potenza fornisce gradualmente la velocità massima. Quando un robot urta le pareti, il motore scende allo 0% di potenza e la velocità si riduce a zero immediatamente.

I robot hanno un cannone che spara missili. Il robot può puntare il cannone in qualsiasi direzione e può sparare tutti i missili che vuole. C'è solo il limite del tempo di ricaricamento di un secondo.
I missili possono raggiungere una distanza massima di 700 metri e hanno una velocità di 300 m/s, così ci vogliono 2,33 secondi per raggiungere la distanza limite. La velocità del missile non dipende da quella del robot. Quando un missile esplode, danneggia tutti i robot nelle vicinanze. I punti di danno dipendono dalla distanza dell'esplosione: 5 metri per 10 punti, 20 metri per 5 punti e 40 metri per 3 punti. Perciò, se un robot spara un missile ad una distanza inferiore ai 5 metri, si procura da solo 10 punti di danno e quindi è meglio evitarlo.

Il robot ha uno scanner che gli permette di trovare gli altri robot. Perlustra il campo di battaglia con un'apertura da 1 a 20 gradi. Più piccolo è l'angolo, migliore è la risoluzione. Con la scansione dell'arena, lo scanner determina la distanza del robot più vicino (che può essere amico o nemico) o un valore nullo se nessun robot viene individuato nel raggio d'azione.

5. L'evoluzione delle tattiche
Con una struttura così semplice non sembra che sia possibile un'ampia varietà di tattiche. Invece, nel corso degli anni, si è potuto assistere a una notevole evoluzione. Da KillerBees di Walter Nisticò (il primo robot a vincere tornei in tutte e tre le categorie) a IonStorm di Alan Lund (che ha primeggiato per anni), le tecniche sono state le più disparate.

Nelle tre modalità di gioco (singolo, doppio e a squadre), la più difficile è quella a squadre: bisogna colpire i nemici evitando il fuoco amico. Inutile dire che nei primi tornei, dove i giocatori si concentravano sui più semplici singoli, si assisteva spesso a una sparatoria indiscriminata, dove le squadre più accorte prevalevano facilmente.

All'inizio i robot sparavano la loro cannonata dove rilevavano il nemico (o, nel peggiore dei casi, un amico che non riconoscevano come tale), ma il missile impiegava un certo tempo per giungere a destinazione e, nel frattempo, il nemico si era spostato. Una prima innovazione è stato l'algoritmo di calcolo che prediceva la posizione in cui si sarebbe trovato il nemico all'arrivo del missile, per correggere preventivamente il tiro. Occorrevano due letture consecutive della posizione per determinare la velocità del nemico e prevedere le posizioni successive.
Una volta ideato l'algoritmo, la contromisura consistette nel cambiare spesso direzione di marcia e comparvero robot che, attraverso tecniche di analisi dei segnali, cercavano di prevedere i pattern irregolari. Insomma, un'escalation della competizione che non avrei creduto possibile in un gioco con così poche variabili.

Lo stesso si è osservato nelle tattiche di squadra. Come ho già detto, all'inizio tutti sparavano a tutti, amici e nemici. Poi si è capito come comunicare la posizione ai compagni di squadra.
A quel punto, si è visto un po' di tutto: c'erano squadre che si radunavano negli angoli più vicini per bersagliare da varie direzioni i malcapitati rimasti al centro; c'erano robot che, individuato un nemico, ne comunicavano la posizione ai compagni e, quindi, lo sfortunato di turno finiva per essere bersagliato a ripetizione e terminato rapidamente; c'erano squadre che percorrevano i lati dell'arena avanzando in fila indiana come una falange ben organizzata e così via (per una sintesi delle tattiche, è disponibile un gameplay su YouTube relativo ai robots più avanzati).

Insomma, ho visto cose che voi umani non potete nemmeno immaginare: per un decennio, centinaia di robots si sono affrontati nello spazio di un chilometro quadrato con un impegno e un accanimento degno di migliori cause.
Ne potete leggere la storia nella “Hall of Fame” di Jrobots sul sito e da lì potete scaricare l'arena offline per provare voi stessi l'ebbrezza della sfida.

Ma la storia dei miei “programming games” non termina con Jrobots. Intorno al 2005, vent'anni dopo il Crobots di Tom Poindexter, è comparso Gun-Tactyx, “a Crobots-like game, with Quake3-style graphics”... ma questa è un'altra storia.

Nel prossimo articolo:
Old Programming Games (Parte II)
Da Jrobots (1995) a Gun-Tactyx (2005)
 

6. Link utili
Su YouTube:
Jrobots 01 – Gameplay (robot di base)
Jrobots 02 – Gameplay (robot avanzati)

Il sito ufficiale di Jrobots è http://jrobots.sf.net (gli scontri online non funzionano per mancanza di manutenzione, però è ancora possibile scaricare l'arena offline)

Il sito italiano (ma oserei dire mondiale) di riferimento per Crobots è http://crobots.deepthought.it/ gestito da Maurizio Camangi.

L'attuale sito ufficiale del Crobots di Tom Poindexter è http://github.com/tpoindex/crobots/

Discutiamone insieme sul forum di OldGamesItalia!