A canvas, o non a canvas, quando si creano giochi basati su browser?

Background: ho un ampio background di sviluppo, ma l'ultima volta che ho codificato un gioco è stato molti anni fa. Le mie abilità Javascript sono piuttosto limitate e ho intenzione di migliorarle costruendo un semplice gioco: Tetris, Pac-man o qualcosa di quel livello di complessità.

Domanda: mi sembra che una scelta fondamentale che devo fare sia se devo renderizzare su un <canvas>elemento o no.

Con una tela, ho strumenti di base per il rendering di punti, linee e cose più complesse. Presumibilmente ci sono, o saranno, anche vari framework per aiutare in questo.

Senza una tela, potrei mantenere i miei oggetti nell'albero DOM, come una normale pagina web, solo piuttosto complessa, con molti elementi sovrapposti.

Un approccio è migliore dell'altro? Si escludono a vicenda? Come faccio a sapere quale scegliere?

Canvas e DOM non si escludono a vicenda, sebbene siano abbastanza separati. Un buon approccio sarebbe quello di rendere l'area di gioco principale (ad es. I pezzi che cadono in Tetris) usando Canvas, e fare tutta l'interfaccia utente (ad es. Visualizzazione del punteggio) con elementi DOM che si sovrappongono all'elemento di tela.

Detto questo, un tale approccio non è davvero necessario per un gioco primitivo come Tetris. Canvas è utile per effetti grafici più avanzati, ma se questi non sono necessari, attenersi al DOM ti darà una maggiore compatibilità; non tutti i browser supportano HTML5 Canvas.

Informazioni su DOM
DOM funziona abbastanza bene per i 2D di vecchia scuola, ciò significa che non è necessario utilizzare la rotazione o il ridimensionamento delle immagini. In realtà ci sono strumenti per entrambi questi lavori, ma non puoi contare sul loro buon rendimento.

Per un gioco devi fare affidamento sul motore di layout del browser il meno possibile, questo significa usare position:absoluteper posizionare oggetti. Cerca, per quanto possibile, di non creare e distruggere oggetti DOM continuamente, se hai bisogno di un numero molto variabile di oggetti potresti voler impostare un pool di elementi DOM inattivi display:none, pronti per essere rianimati quando necessario.

DOM vs canvas
Con la quota di mercato di IE8, la riduzione della tela sta diventando un'opzione sempre più attraente, per la maggior parte dei giochi è probabilmente una buona scelta. Ma per alcuni lavori DOM è lo strumento più semplice da utilizzare, è possibile utilizzare un certo flusso di documenti se necessario, è possibile catturare i clic direttamente dall'oggetto renderizzato, è facile integrare le barre di scorrimento.

È difficile coprire la differenza di prestazioni, dipende dal lavoro e varia in modo selvaggio da browser a browser.

Dipende completamente dal tipo di gioco, sebbene la tela si adatti alla "maggior parte" di essi.

La gestione del DOM diventa orribile a un certo punto, più elementi si ottiene più lentamente, più elementi si sposta in THE EXTREMELY SLOWER.

La gestione dell'ordine di caricamento delle risorse con elementi IMG è ... non trival (intercettare errori su protocolli volutamente rotti sui tag immagine: D).

Anche se, per i giochi con immagini prevalentemente statiche e con un basso numero di effetti, continuerei comunque con DOM. Tutto il resto, la tela è la prima scelta (punta e clicca roba, sebbene le hitmap siano una storia diversa).

La tela è così veloce in questi giorni (anche su iPhone), non c'è quasi alcun motivo per non usarla.

Se stai realizzando un gioco HTML5, la tela è di gran lunga migliore. Ecco perché:

1. Velocità: pensa alla tela come a un'immagine. Disegni sull'immagine e poi dimentica ciò che hai disegnato. Ciò aumenta notevolmente le prestazioni, rispetto a DOM o SVG. Ciò che fanno le applicazioni DOM e SVG è che tengono traccia di ogni oggetto posizionato sullo schermo. Ciò significa che se hai un grande livello con molti oggetti sullo schermo, specialmente fuori dallo schermo o nascosti, quelli vengono disegnati e tenuti traccia comunque.
2. Funzionalità di disegno - Mentre gli elementi DOM hanno potenti trasformazioni CSS3, questo non è nulla in confronto alle caratteristiche della tela. La tela può disegnare qualsiasi oggetto, avere un potente supporto del gradiente, plugin per visualizzare oggetti in 3D, filtri, ecc.
3. Supporto: quando si utilizza il DOM, quando si desidera utilizzare funzionalità sperimentali come trasformazioni o animazioni, è necessario utilizzare i prefissi -moz-, -webkit-, -o- e -ms- nei CSS. Nella tela, non devi preoccuparti di questo. Disegna con una sola funzione e il gioco è fatto. Un altro vantaggio legato al supporto dell'area di disegno è la modalità di visualizzazione dell'applicazione. Come sviluppatore di siti Web, la mancanza di standardizzazione DOM tra i browser mi fa impazzire. Gli sfondi, i gradienti, le trasformazioni, ecc. Vengono visualizzati in modo diverso tra i browser, nonostante le specifiche dettagliate del W3C. Nella tela, ho incontrato solo una cosa che potrebbe essere diversa: gli sfondi. Quando si visualizza uno sfondo affiancato, alcuni browser prenderanno "tile-x" come centrare il riquadro su 0px sull'asse x, e altri lo prenderanno come solo affiancare il riquadro verso il basso.
4. Librerie e documentazione - Ci sono tonnellate di grandi librerie sulle documentazioni per creare giochi con la tela. Alcune librerie: CreateJS, paper.js, fabric.js, KineticJS, libCanvas, Processing.js, PlotKit, Rekapi, PhiloGL, InfoViz Toolkit, Frame-Engine, CAKE, Raphaeljs, Tweenjs, ecc. Potrei elencare un sacco di più, ma non ha senso.

Lato negativo - Animazione - Mentre ci sono molte ottime librerie per l'animazione, adoro le animazioni CSS3. Sono così facili da creare, manipolare e attivare. Esistono vari hack per far funzionare le animazioni CSS3 con oggetti con la tela, ma sospetto che la maggior parte delle persone preferisca non usare quel metodo.

Buona fortuna con il tuo gioco e spero di vedere cosa fai!

Se prendi in considerazione il targeting per browser mobili, in particolare Android, e il gioco contiene elementi grafici in movimento, evita l'animazione DOM. Il browser stock in Android è inutile, anche se è webkit. Dai un'occhiata a questo thread di problemi di Android prima di iniziare: "Rendering terribile di animazioni CSS3 e Javascript in Browser e WebView" .

Il canvas in sé potrebbe non essere più veloce, ma ci sono framework per invocare l'accelerazione hardware per le animazioni del canvas, ad esempio CocoonJS . C'è un link a un video sul sito, che mostra i miglioramenti delle prestazioni che puoi ottenere usando il framework (ma per qualche motivo non sono autorizzato a pubblicare più di due link).

Risposta semplice: WebGL con fallback di tela.

Risposta sfumata: se il tuo gioco ha molto testo, sovrapponi un livello di testo HTML. Pixi.js è un framework di visualizzazione temprato dalla battaglia con alcuni extra utili che funzionano bene per questo.

Ricorda che DOM sta per modello a oggetti del documento . Ti consigliamo di utilizzarlo per creare giochi solo in situazioni molto rare e preferisci il canvas nella maggior parte dei casi.

Anche se il tuo gioco ha piccoli requisiti grafici, farlo in DOM avrà una prestazione negativa; qualcosa di più di Tetris probabilmente funzionerà male.

Ho un esempio del mondo reale: quando ho creato un'implementazione di Conway's Game of Life, ho iniziato con una tabella 500x500, cambiando il colore di sfondo delle celle. In questa versione, un aliante non funzionava a più di 30 fps, i modelli più grandi non davano quasi più di 1. Nella mia versione su tela di questo gioco, ora è possibile eseguire modelli molto più grandi (popolazione di 1000 e più) senza problemi ~ 30 fps.

Inoltre, questo dovrebbe valere anche per SVG (Scalable Vector Graphics), anche se in pratica non l'ho mai provato.

Modifica : devo ammettere che il mio esempio non è molto buono (perché tables = bad). Ma il punto principale è ancora vero: la manipolazione del DOM è per i documenti. Il browser deve cercare CSS e allocare più memoria quando si lavora su elementi. Non ha davvero senso essere più veloce della tela.