Per la terza puntata della nostra serie "People of HTML5", l'intervista di oggi è a Rob Hawkes, autore di Rawkets, un gioco multiplayer che sfrutta canvas e websockets.
Rob era presente al Game On 2010 di Londra dove ha presentato il suo gioco: le slide e il video della sua presentazione sono disponibili sul Mozilla Games Blog. Al momento lavora alacremente ad un libro su Canvas ed è presente su Twitter come @robhawkes.

La cosa più apprezzabile di questa conversazione con Rob è che non ci sono problemi ad usare la tecnologia che desideri, ed è un grosso beneficio lasciare che gli altri possano "giocare" con il tuo codice – anche se serve e rompere il sistema…

1) Rob, tu hai smanettato con Canvas e giochi un bel po' – come mai questa passione? Hai scritto altri giochi per altri ambienti prima di questo?

Certamente. Tutta la mia vita degli ultimi anni ha riguardato scrivere giochi in un modo o l'altro. Mi piace l'idea di creare giochi per esplorare tutte le possibilità di un linguaggio di programmazione ed impararlo a fondo. E' un'ottima maniera di sperimentare tutte le funzionalità grafiche e visuali, particolarmente in relazione a concetti complessi come la fisica, di cui ancora non sono proprio un esperto. In realtà la mia passione con i giochi è nata da un'esigenza concreta: durante il mio secondo anno di università dovevo scrivere un gioco e così ho collaborato alla creazione di un gioco di Realtà Aumentata utilizzando Papervision3D e ActionScript. Da lì ho collaborato alla stesura di un altro gioco similare in Adobe Flex dove i player giocavano uno contro l'altro usando la webcam, piuttosto divertente. E adesso faccio giochi con canvas: un po' perchè mi diverte, un po' per imparare tutto quello che posso su questo argomento. Mi esalta molto l'interattività e la fluidità tipica dei giochi, cosa che probabilmente si collega alla mia passione per la programmazione visuale in generale.

2) La cosa bella delle tecnologie aperte è che è molto facile vedere che cosa c'è "dietro". Visualizza sorgente, ed è tutto lì. Per i giochi, non è un problema? Per "fregare" un gioco in Flash devi quantomeno fare un po' di HTTP sniffing – con canvas è ancora più facile. Come ti proteggi da questa eventualità?

Il fatto che canvas sia così aperto è una delle caratteristiche che mi interessa di più. Io sono di solito abbastanza "open" in merito alla programmazione e sono contento se le persone possono imparare dal mio codice, quindi poter vedere direttamente il sorgente dal browser è fantastico. Però, l'altro lato della medaglia è che la sicurezza è un grosso problema. E hai ragione, questo è particolarmente vero per i giochi. Non penso però ci sia molto da fare: tant'è che poco dopo che ho presentato il mio Rawkets le persone hanno iniziato a "giocare" con il codice e a truccare. Ad essere sincero lo vedo però come una cosa positiva: mi ha mostrato i punti deboli del codice e ha evidenziato le parti che dovevo "mettere in sicurezza". Poi minimizzare e offuscare il tuo codice quanto vuoi, ma tutti avranno comunque accesso, è il funzionamento stesso di JavaScript. Però ci sono alcuni metodi per ridurre il problema, spostando ad esempio la logica di base ad un server remoto e implementando una serie di API calls in maniera sicura e protetta. Questo è un buon metodo per un gioco multiplayer dove i dati ricevuti dal server sono "fidati" mentre quelli dal client no. Oppure si può mettere il codice sensibile in closures e sfruttare local variables per nascondere dati che non si vuole rendere facilmente visibili. Un'altra strada e fregarsene del tutto: purchè non si permetta agli hacker di rovinare il gioco agli altri, che problema c'è se lo scassano nel loro browser?

3) Sempre a proposito di "open", non è forse vero che il Canvas alla fine è una specie di applet Java con una serie di API predefinite e senza la necessità di una Java Virtual Machine? Alla fine è sempre un rettangolo sulla pagina da manipolare…

Se vuoi dire che il canvas è una scatola a cui puoi accedere con una serie di API, sì, hai ragione. Però, d'altro canto, le API ti consentono di fare veramente un casino di cose, e si può dire la stessa cosa di Flash e altri metodi "chiusi" di fare grafica?
Immagino che quando dici che il canvas è "aperto" parli principalmente del processo che sta dietro alla sua creazione (cioè la W3C) e del fatto che il codice che serve a disegnare non è nascosto. Canvas non è aperto nel senso che non è possibile estenderlo e fargli fare tutto quello che desideri: finchè segui le API, che va bene il 99% delle volte, non c'è nessun problema.
Come dici, canvas alla fine è un rettangolo nel browser che ti consente di disegnare cose. Una volta che hai disegnato un po' elementi, non puoi più accedervi singolarmente. Ma funziona così. Non è SVG dove invece gli elementi che disegni sono parte del DOM e quindi accessibili e modificabili. Canvas è un sistema bitmap che non ha il concetto di "elementi singoli". E' un sistema distruttivo che sostanzialmente cambia il colore dei pixel del suo rettangolo, basandosi sulle chiamate API che fai. E così, siamo tornati un po' al buon vecchio Microsoft Paint.

4) E l'accessibilità? Possono le tecnologie di accessibilità interagire col contenuto del canvasa? E l'interazione da tastiera?

A dirla tutta, no. O almeno, non ancora.
Canvas ha un contenuto di fallback che viene inserito fra i tag e viene mostrato nel caso in cui il browser non lo supporti, ma non è che questo aiuti molto in termini di accessibilità. La cosa utile del contenuto di fallback è che ci si può mettere codice per accesso con la tastiera. Mi pare che IE9 implementi già questa cosa: puoi mostrare il canvas ma dare comunque accesso alla tastiera così puoi descrivere il contenuto del canvas con del testo – o qualcosa del genere. Il problema di questi metodi è che di fatto duplicano tutto il tuo contenuto: disegni tutto nel canvas, e poi devi riscrivere tutto nel contenuto di fallback per spiegare che cosa hai disegnato.
Una cosa che non si può ancora fare è dare accessibilità ai singoli elementi del canvas per il semplice fatto che il canvas è solo un grosso rettangolo di pixel che non ha la minima idea di quello che c'è disegnato sopra. Questo è il più grosso svantaggio di un sistema come questo e con una serie di API chiuse. Si parla di dare accesso a livello più profondo tramite lo shadow DOM ma non mi pare ci sia nulla di concreto.
E' qualcosa a cui sono molto interessato, e nel frattempo Bruce Lawson ha una serie di proposte molto valide per migliorare l'accessibilità del canvas.

5) Dimmi qualcosa sulle performance: quali sono i trucchi per scrivere un gioco fluido con il canvas?

Questa è una delle cose più fastidiose, attualmente, di canvas: può essere terribilmente lento! In realtà non è un problema del canvas, ma piuttosto legato al fatto che il canvas usa il processo del browser per disegnare tutto, la qual cosa a sua volta usa un sacco di CPU.
Alcuni browser stanno introducendo un metodo chiamato "accelerazione hardware" che passa l'elaborazione del canvas e dei processi grafici alla scheda grafica (GPU). Questa semplice cosa renderebbe il tutto molto più veloce e consentirebbe di fare animazioni e giochi molto più pesanti. In ogni caso, l'accelerazione hardware non è la bacchetta magica e devi comunque scrivere codice ottimizzato ed essere ben conscio delle inefficenze del tuo programma.
I problemi principali di solito sono legati alla creazione di timer e loop non necessari o troppo arzigogolati. Per esempio, le animazioni con canvas di solito richiedono l'utilizzo di timeout JavaScript, che esegue una funzione che disegna tutto quello che c'è sul canvas 30 volte al secondo, abbastanza velocemente da dare l'impressione del movimento. Questo è fantastico, ma che succede se non stai più animando il canvas? Io ad esemoio ho commesso l'errore di non spegnere il timer, succhiando così preziosi cicli di CPU senza ragione.
Un altro esempio e la collision detection o qualsiavoglia altro check da effettuare su un numero elevato di oggetti. Il modo sbagliato di fare questa cosa è scorrere tutti gli oggetti e per ogni oggetto scorrere di nuovo tutti gli oggetti per vedere se si sono scontrati. Il problema è che così facendo controllerai alcuni oggetti due volte o anche più, sprecando risorse. Invece è più efficente ottimizzare i loop per escludere gli oggetti che si sono già controllati.
Ci sono davvero tantissimi modi di ottimizzare il codice e se la singola ottimizzazione, da sola, non farà molto, insieme possono far risparmiare un bel po' di risorse.

6) Il tuo gioco usa Web Sockets per comunicare. Come ti sei trovato? Scala bene? C'è qualcosa che non ti piace di questa tecnologia?

Vorrai dire che usava Web Sockets, vero? E' un vero peccato che Firefox e gli altri abbiano deciso di non supportare più, per il momento, questa tecnologia. A parte questo, il gioco si fonda su WebSockets, ed è stata un'esplorazione molto interessante. Io adoro WebSockets e penso che avere un metodo bidirezionale per comunicare all'interno di un browser sia fantastico. Il fatto che i dati passino in tempo reale apre una serie di nuove possibilità per giochi e Web Apps. Non ho trovato particolari problemi con WebSockets in termini di stabilità e scalabilità e la maggior parte dei problemi risiedono piuttosto nel codice sul server che riceve le chiamate. Ho trovato poi che una cosa a cui stare attenti è che la quantità di dati può crescere esponenzialmente se non sei abituato ad ottimizzare le comunicazioni per un ampio numero di utenti.
Devo ammettere, però, che il mio fastidio principale con WebSockets è che manda tutto come plain text, la qual cosa rende scrivere applicazioni molto semplice ma che porta ad uno spreco di banda disponibile, cosa che può essere un problema per applicazioni multiplayer massicce.
L'altra cosa è che non supporta UDP ma solo TCP come protocollo di comunicazione (dovuto al fatto che canvas supporta solo quest'ultimo protocollo) e dunque i dati devono essere mandati in ordine e non, come invece con UDP, quando uno vuole. Questo può essere un problema specialmente nel gaming dove può succedere che alcuni messaggi restino "in coda" e dunque tutti quelli successivi debbano attendere, causando problemi ad esempio di sincronizzazione in giochi FBS.
Ma, come detto, lo standard è in evoluzione e il fatto che Firefox e altri ne abbiano sospeso il supporto lo dimostra. Secondo me è una tecnologia con un futuro radioso, e non vedo l'ora di vederne i progressi.

7) Hai giocato un po' anche con SVG? Se sì, quando usaresti una tecnologia e quando l'altra, e ci può essere una sinergia tra le due?

Devo ammetterlo: non ho giocato con SVG quanto avrei voluto. E' che il mondo del canvas mi ha rapito così tanto negli ultimi mesi. Comunque, SVG è qualcosa che penso fermamente debba essere usato invece di canvas in circostanze particolari, come ad esempio quando si vogliono convertire dati HTML esistenti in un formato grafico (ad esempio creando un grafico di dati tabellari).
SVG poi è molto valido perchè è accessibile tramite DOM, ma non va bene per animazioni e giochi. Non è mai stato costruito pensando a questi utilizzi ed è per questo che esiste canvas. Canvas è perfetto per animazioni veloci e dinamiche, ed è particolarmente indicato per creare giochi.
Fortunatamente, non è sempre un aut aut fra SVG e canvas. E' possibile disegnare forme SVG in un canvas, la qual cosa ha l'ulteriore vantaggio di offrire tutte le funzionalità vettoriali di SVG in un sistema bitmap. Ho sentito di sviluppatori che usano questa tecnica per disegnare sprite su canvas, oppure oggetti che richiedono di essere ridimensionati parecchio.

8) Qual è la prossima barriera che vorresti vedere abbattuta? Quali tecnologie chiuse sono attualmente fuori dalla tua portata che tu vorresti provare?

Sarei veramente contento di vedere la Device API (DAP) supportata dai principali browser. Una cosa che manca agli attuali browser è la possibilità di interfacciarsi con device esterni come il microfono o la webcam. Immagino già come canvas e DAP possano essere usati per applicazioni e visualizzazioni davvero belle. Pensa alla possibilità di usare un avatar per un sito solo con canvas e webcam. Oppure che ne dici di una video chat nel browser grazie a WebSockets e canvas/video HTML5? Sarebbe JavaScript all'ennesima potenza!

9) Stai scrivendo un libro su Canvas. In attesa della sua uscita, dove possono rivolgersi i developer interessati ad approfondire questo argomento?

Non ci sarà da aspettare molto (dovrebbe uscira a maggio) ma nel frattempo suggerisco un giro sul Mozilla Developer Network. E' dove ho imparato ad usare canvas, quindi è ottimo! A parte questo, mancano sul serio delle risorse valide per imparare ad usare canvas, ma penso che la situazione migliorerà quest'anno.

10) Dove può rivolgersi un programmatore per cercare un po' di ispirazione? Che altri utilizzi di canvas ti hanno datto dire "Wow lo voglio anche io!"?

Ci sono alcuni progetti davvero fantastici, la lista sarebbe infinita ma questi sono alcuni dei miei preferiti:

Altre cose davvero impressionati sono progetti dove si sfrutta al massimo la manipolazione dei pixel del canvas, come ad esempio la face dection o il riconoscimento dei nudi. Roba strana, ma davvero esaltante!

L'intervista originale è qui, il video (HTML5, grazie a Vid ly):