Il Dinosaur Game, o T-Rex Game, Chrome Dino, No Internet Game, o anche Dino Runner, è un piccolo videogioco da browser a cui Google Chrome dà la possibilità di giocare nella pagina di errore quando la connessione internet non viene rilevata.
Ci si può giocare anche quando si è normalmente collegati, scrivendo chrome://dino oppure chrome://network-error/-106 nella barra degli indirizzi di Chrome, oppure, da qualsiasi browser, andando su vari siti che ne propongono dei cloni (tipo questo).
Il gioco
Introdotto nel 2014, è stato pensato per giocare offline e passare il tempo in attesa che la connessione si ripigli, mentre l’idea del dinosauro è associata al fatto che, senza internet, ci sentiamo come in piena preistoria.
Per scelta stilistica, è molto semplice, sia come meccaniche di gioco sia come grafica, che è tutta a pixel con forme semplici e pochissimi colori in scala di grigi.
C’è un T-Rex che corre solitario nel deserto e deve evitare, saltandoli, i cactus che si presentano sulla sua strada. Il giocatore può premere la barra spazio o la freccia in su per far saltare il dinosauro che, se invece si scontra con un ostacolo, muore (o per lo meno si fa male e si ferma) e la partita finisce. Essendo io una pippa a questo gioco, non ero mai arrivata abbastanza avanti per scoprire che, a un certo punto, cominciano ad apparire anche degli pteranodonti in volo a diverse altezze, che vanno evitati saltando oppure abbassandosi, premendo la freccia in giù. In più, dopo i 700 punti, lo scenario cambia colori (li inverte) a rappresentare la fine del giorno e l’inizio della notte.
Pteranodonti e pterosauri
Fun fact: lo Pteranodon o pteranodonte non è lo Pterodactylus o pterodattilo, il cui nome è più noto. Sono due generi diversi, entrambi appartenenti all’ordine degli pterosauri, rettili volanti estinti. Lo pterodattilo è più antico, più piccolo, e possedeva un becco con circa 90 denti, a differenza dello pteranodonte che non aveva denti (il suo nome significa “ala senza denti”).
Altro fun fact: gli pterosauri non sono dinosauri. Sono due gruppi diversi. E, mentre i primi sono del tutto estinti, i secondi esistono ancora oggi: e sono gli uccelli.
Ma non divaghiamo.
La programmazione
L’anno scorso, dopo aver studiato sviluppo web front-end ed essermi impratichita con JavaScript, ho pensato bene di ampliare i miei orizzonti e avvicinarmi alla programmazione di videogiochi scrivendo da zero un clone del Dino Runner, sempre per browser e in JavaScript.
Che poi il gioco originale, così come parte di Chrome, è open source (si trova qui). Ma volevo divertirmi.
Lo spritesheet
Come spesso accade nei videogiochi, le immagini dei vari elementi si trovano insieme in uno spritesheet, un’unica immagine che va vista come una griglia dove ogni disegno occupa uno spazio entro determinate coordinate, che vengono passate al codice per ‘dirgli’ dove andarsi a prendere cosa. Dino che salta? Cactus piccolo? Nuvoletta? Li trovi a queste coordinate sull’asse X, a queste altre sull’asse Y. Si fa così perché, in termini di memoria e di potenza di calcolo necessarie, un’unica immagine (cioè uno spritesheet) è più efficiente di più immagini separate.
Fun fact: il termine sprite, con questo significato, sembra essersi diffuso negli anni ’70 in ambito informatico con riferimento al fatto che si tratta di figure che si muovono e ‘fluttuano’, sopra allo sfondo e senza alterarlo, come fantasmi o folletti. Sprite infatti deriva dal latino spiritus, attraverso il francese esprit, ed è traducibile come folletto.
Il movimento
La corsa di Dino è un’illusione: è posizionato fisso sempre nello stesso punto e si limita ad alternare immagini diverse che compongono un’animazione in cui sgambetta.
Quello che si muove è lo sfondo alle sue spalle, il terreno e gli ostacoli. Il terreno è un’immagine che, ad ogni frame e in modo costante, viene spostata un pochino verso sinistra. Quando l’immagine finisce, viene ripetuta, in un ciclo infinito e uniforme, senza interruzioni.
Il cielo sullo sfondo scorre più lentamente rispetto alle cose in primo piano: è l’effetto di parallasse, molto usato nei videogiochi 2D, e che vediamo nella realtà ad esempio dal finestrino di un’auto o di un treno in movimento. L’ambiente di Dino è tutto bidimensionale, ma variando la velocità di scorrimento dei vari elementi, si ottiene un’illusione di profondità tridimensionale piuttosto convincente.
La generazione degli ostacoli
Dino incontra vari ostacoli lungo il percorso: il tipo di oggetto e la sua posizione sembrano... casuali. Ma le cose causuali che vediamo nei videogiochi non sono mai davvero random (e neanche pseudo-random!), o almeno non fino in fondo. Sono governate da regole precise, studiate per apparire irregolari, ma soprattutto per essere belle da giocare: abbastanza difficili da non annoiare, non impossibili per non frustrare, con una certa varietà per non apparire ripetitive, ma non troppa da spiazzare.
Nel caso di un endless runner come questo, può essere necessario stabilire un insieme di regole che governino l’apparizione degli ostacoli: quali oggetti, in che posizione, quanto spesso, ecc.
Ecco com’è andato il mio primo tentativo di generazione degli ostacoli:
La soluzione che, alla fine, ho trovato è piuttosto semplice e consiste nello stabilire una distanza minima tra gli ostacoli e una distanza massima (senza una distanza minima, potrebbero apparire numerosi ostacoli tutti attaccati - senza una distanza massima, potrebbero passare minuti e minuti senza niente all’orizzonte). Avendo una distanza minima e una massima, posso generare un numero pseudo-random compreso in questo intervallo, che rappresenta la distanza dall’ultimo ostacolo sullo schermo, e trovare così il punto in cui devo far apparire un nuovo ostacolo.
Il salto
Il salto è un’altra di quelle cose che sembrano una stupidata, e invece no.
Se sposto il personaggio prima in su e poi in giù, a velocità costante, non è un salto: sembra un astronauta in assenza di gravità. Nella realtà, ogni cosa che sale verso l’alto viene frenata dalla forza di gravità, e ogni cosa che cade verso il basso viene accelerata dalla forza di gravità. Per cui serve un parametro, una costante di qualche tipo, che, fotogramma dopo fotogramma, smorzi la velocità del salto durante la salita, e la incrementi durante la discesa.
Questa è la fisica di base di un salto realistico: ma i salti realistici sono noiosi. Super Mario - il cui soprannome originale è “Jumpman” (ジャンプマン) - è un idraulico alto 1,55m che salta circa 5 volte la propria altezza (più di sette metri e mezzo!), è sottoposto a una forza di gravità 8-10 volte quella terrestre e scende con un’accelerazione sproporzionata rispetto alla salita (l’impatto col terreno sarebbe letale per chiunque!). Il suo salto non è realistico, ma è veloce e dinamico, e permette al giocatore di controllare il movimento con precisione.
In generale, i salti dei videogiochi devono essere divertenti, dare una bella sensazione al giocatore, e risultare coerenti con il design del gioco. Non è un’impresa facile: spesso richiede mesi di lavoro, di prove e di esperimenti.
Scrivendo questo articolo sono caduta nella tana del Bianconiglio della simulazione della fisica dei salti, e ho costruito un Dino che non corre - salta e basta, e ci si può “giocare” smanettando con le forze applicate al salto (Dino salta con un click oppure premendo la barra spazio o la freccia in su. Dovrebbe funzionare anche da cellulare, con un tap):
Le collisioni
Lo spazio sullo schermo va pensato come su due assi cartesiani, e tutte le cose hanno coordinate X e Y. I due assi si incrociano nell’angolo in alto a sinistra dello schermo: quello è il punto 0. Una cosa sulla sinistra dello schermo avrà un valore di X piuttosto basso, che diventerà sempre più alto se la spostiamo verso destra, e viceversa.
Uno dei metodi più semplici per rilevare le collisioni, cioè verificare se due elementi si stanno scontrando, è Axis-Aligned Bounding Box (AABB). Si usa in uno spazio bidimensionale per capire se due forme rettangolari allineate agli assi si stanno sovrapponendo, confrontando le loro posizioni (determinate da una coordinata orizzontale X e da una verticale Y) e l’ingombro che occupano (e che si ricava dalla loro larghezza e altezza).
Ho fatto un disegnino:
Il mio Dino Runner
Lo sconsiglio vivamente, ma se qualcuno volesse provarlo, il mio Dino runner è giocabile qui. È uguale al gioco originale ma molto più brutto. Tuttavia, mi ha insegnato tanto: ho programmato per la prima volta robe che si muovono nello spazio e nel tempo e che reagiscono agli input del giocatore, ho creato un ciclo di update e una piccola macchina a stati,... È stato divertente.
Fonti
- Dinosaur Game, Wikipedia
- As the Chrome dino runs, we caught up with the Googlers who built it, The Keyword
Sul salto di Super Mario e, in generale, il movimento nei videogiochi:
- Mario, Wikipedia
- The real-life physics of Super Mario, Techradar
- Recreating Super Mario's Jump, Pontypants (video)
- Why Does Celeste Feel So Good to Play?, Game Maker's Toolkit (video)
Per un’introduzione alla programmazione dei videogiochi, c’è una bella playlist di lezioni dell’Università di Harvard: ogni video (in inglese) dura un paio d’ore e spiega come ricreare un gioco, a cominciare da Pong e Flappy Bird.
Il mio codice si trova su GitHub: qui il Dino che corre e qui il Dino che salta.
L’immagine in alto è di Hannah Pemberton da Unsplash.
Disclaimer & copyright
Leggi tutto su copyright, attendibilità dei contenuti, e quant’altro,
cliccando qui.
Please read our legal disclaimer and copyright
notice here.
Cosa ne pensi? Commenta!