Płótno, czy nie płótno, podczas tworzenia gier opartych na przeglądarce?

Tło: Mam rozległe doświadczenie programistyczne, ale ostatni raz kodowałem grę wiele lat temu. Moje umiejętności Javascript są dość ograniczone i zamierzam je ulepszyć, budując prostą grę - Tetris, Pac-man lub coś w tym stopniu złożoności.

Pytanie: Wydaje mi się, że podstawowym wyborem, którego muszę dokonać, jest to, czy powinienem wykonać <canvas>element, czy nie.

W obszarze roboczym mam podstawowe narzędzia do renderowania punktów, linii i bardziej złożonych rzeczy. Przypuszczalnie istnieją lub będą różne ramy, które mogą w tym pomóc.

Bez płótna mogłem przechowywać moje obiekty w drzewie DOM, jak zwykłą stronę internetową, tylko dość złożoną, z wieloma nakładającymi się elementami.

Czy jedno podejście jest lepsze od drugiego? Czy się wykluczają? Skąd mam wiedzieć, który wybrać?

Płótno i DOM nie wykluczają się wzajemnie, chociaż są dość osobne. Jednym dobrym podejściem byłoby renderowanie głównego obszaru gry (np. Spadające elementy w Tetris) za pomocą Canvas i wykonanie całego interfejsu użytkownika (np. Wyświetlanie wyników) z elementami DOM, które nachodzą na element Canvas.

To powiedziawszy, takie podejście nie jest tak naprawdę konieczne w prymitywnej grze, takiej jak Tetris. Płótno przydaje się w przypadku bardziej zaawansowanych efektów graficznych, ale jeśli nie są one wymagane, trzymanie się DOM zapewni szerszą kompatybilność; nie wszystkie przeglądarki obsługują HTML5 Canvas.

Informacje o DOM
DOM działa całkiem dobrze w oldschoolowych 2D, co oznacza brak obrotu i skalowania obrazu. W rzeczywistości istnieją narzędzia do obu tych zadań, ale nie można liczyć na ich dobre wyniki.

W grze powinieneś polegać na silniku układu przeglądarki w jak najmniejszym stopniu, co oznacza użycie position:absolutedo umieszczania obiektów. Staraj się w miarę możliwości nie tworzyć i nie niszczyć obiektów DOM przez cały czas, jeśli potrzebujesz bardzo zmiennej liczby obiektów, możesz chcieć ustawić pulę bezczynnych elementów DOM display:none, gotową do wskrzeszenia w razie potrzeby.

DOM a płótno
Z udziałem IE8 w rynku kurczenie się płótna staje się coraz bardziej atrakcyjną opcją, dla większości gier jest to prawdopodobnie dobry wybór. Ale w przypadku niektórych zadań DOM jest łatwiejszym w użyciu narzędziem, w razie potrzeby możesz użyć przepływu dokumentów, możesz wychwycić kliknięcia bezpośrednio przez renderowany obiekt, łatwo zintegrować paski przewijania.

Trudno jest pokryć różnicę wydajności, zależy to od zadania i będzie się różnić w różnych przeglądarkach.

Całkowicie zależy od rodzaju gry, chociaż płótno pasuje do „większości” z nich.

Zarządzanie DOMem staje się okropne w pewnym momencie, im więcej elementów dostajesz wolniej, tym więcej elementów poruszasz się po NIEZWYKLE SPOWOLNIENIU.

Zarządzanie kolejnością ładowania zasobów za pomocą elementów IMG jest ... niebanalne (przechwytywanie błędów celowo uszkodzonych protokołów w znacznikach obrazu: D).

Chociaż w przypadku gier z głównie statycznymi obrazami i niską liczbą efektów nadal wybrałbym DOM. Wszystko inne, płótno jest pierwszym wyborem (wskaż i kliknij, chociaż hitmapy to inna historia).

Obecnie płótno jest tak szybkie (nawet na iPhonie), że nie ma powodu, aby go nie używać.

Jeśli tworzysz grę HTML5, płótno jest zdecydowanie lepsze. Dlatego:

1. Szybkość - Pomyśl o płótnie jako obrazie. Rysujesz na obrazie, a następnie zapomina o tym, co narysowałeś. To znacznie zwiększa wydajność w porównaniu do DOM lub SVG. Aplikacje DOM i SVG śledzą każdy obiekt umieszczony na ekranie. Oznacza to, że jeśli masz duży poziom z wieloma obiektami na ekranie, zwłaszcza ukrytymi lub ukrytymi, są one i tak rysowane i śledzone.
2. Funkcje rysowania - Podczas gdy elementy DOM mają potężne transformacje CSS3, to nic w porównaniu z funkcjami obszaru roboczego. Płótno może narysować dowolny obiekt, mieć potężną obsługę gradientów, wtyczki do wyświetlania obiektów w 3D, filtry itp.
3. Wsparcie - Podczas korzystania z DOM, gdy chcesz korzystać z eksperymentalnych funkcji, takich jak transformacje lub animacje, musisz używać prefiksów -moz-, -webkit-, -o- i -ms- w CSS. W płótnie nie musisz się tym martwić. Wystarczy narysować za pomocą jednej funkcji i gotowe. Kolejną zaletą płótna związaną z obsługą jest sposób wyświetlania aplikacji. Jako programista strony internetowej brak standaryzacji DOM między przeglądarkami doprowadza mnie do szału. Tła, gradienty, transformacje itp. Wyświetlają się inaczej w różnych przeglądarkach, pomimo szczegółowych specyfikacji W3C. Na płótnie natknąłem się tylko na jedną rzecz, która może być inna - tła. Podczas wyświetlania tła z kafelkami niektóre przeglądarki przyjmują „kafelek x” jako środek kafelka w punkcie 0px na osi x, a inne przyjmują go jako kafelek w dół.
4. Biblioteki i dokumentacja - W dokumentacji znajduje się mnóstwo wspaniałych bibliotek do tworzenia gier na płótnie. Niektóre biblioteki: CreateJS, paper.js, fabric.js, KineticJS, libCanvas, Processing.js, PlotKit, Rekapi, PhiloGL, InfoViz Toolkit, Frame-Engine, CAKE, Raphaeljs, Tweenjs itp. Mogę wymienić więcej, ale nie ma sensu.

Wada - Animacja - Chociaż istnieje wiele świetnych bibliotek do animacji, uwielbiam animacje CSS3. Są tak łatwe do tworzenia, manipulowania i uruchamiania. Istnieją różne hacki, aby animacje CSS3 działały z obiektami z płótnem, ale podejrzewam, że większość ludzi woli nie używać tej metody.

Życzę powodzenia w grze i mam nadzieję zobaczyć, co stworzysz!

Jeśli rozważasz kierowanie na przeglądarki mobilne, w szczególności na Androida, a gra zawiera ruchomą grafikę, unikaj animacji DOM. Przeglądarka zapasowa w Androidzie jest bezużyteczna, mimo że jest to webkit. Zanim zaczniesz, zapoznaj się z tym tematem dotyczącym Androida: „Straszne renderowanie animacji CSS3 i JavaScript w przeglądarce i WebView” .

Płótno samo w sobie może nie być szybsze, ale istnieją ramy wywołujące przyspieszenie sprzętowe dla animacji płótna, na przykład CocoonJS . Na stronie znajduje się link do filmu wideo, pokazujący wzrost wydajności, który można osiągnąć za pomocą frameworka (z jakiegoś powodu nie mogę publikować więcej niż dwóch linków).

Prosta odpowiedź: WebGL z rezerwowym płótnem.

Zróżnicowana odpowiedź: jeśli gra zawiera dużo tekstu, nałóż warstwę tekstową HTML. Pixi.js to zahartowana w bitwie platforma wyświetlania z kilkoma przydatnymi dodatkami, które działają dobrze w tym celu.

Pamiętaj, że DOM oznacza model obiektu dokumentu . Będziesz chciał go używać do tworzenia gier tylko w bardzo rzadkich sytuacjach, a w większości przypadków wolisz płótno.

Nawet jeśli twoja gra ma małe wymagania graficzne, wykonanie jej w DOM będzie miało słabą wydajność; cokolwiek więcej niż Tetris prawdopodobnie będzie źle działać.

Mam przykład z realnego świata: kiedy stworzyłem implementację gry Conwaya Game of Life, zacząłem od stołu 500 x 500, zmieniając kolor tła komórek. W tej wersji Szybowiec nie działał z prędkością większą niż 30 klatek na sekundę, większe wzory dawały prawie nie więcej niż 1. W mojej wersji na płótnie tej gry można teraz płynnie uruchamiać znacznie większe wzorce (liczba ludności 1000 i więcej) przy ~ 30 fps.

Tak też powinno być w przypadku SVG (Scalable Vector Graphics), chociaż nigdy nie próbowałem tego w praktyce.

Edycja : Muszę przyznać, że mój przykład nie jest zbyt dobry (ponieważ tabele = złe). Ale główny punkt jest nadal prawdą: manipulacja DOM dotyczy dokumentów. Przeglądarka musi wyszukać CSS i przydzielić więcej pamięci podczas pracy na elementach. Nie ma sensu być szybszym niż płótno.