Jaki silnik gier do JavaScript?

Jaki jest obecnie najpopularniejszy silnik gier do JavaScript? Słyszałem że Phaser jest dość popularny, oraz PixiJS.
Jest jeszcze Gamemarker, GDevelop, PlayCanvas, Babylon, Three, oraz Godot ale on chyba nie wspiera jakoś wyjątkowo JS.
Dlaczego w dystrybucjach linuksowych najwięcej gier natywnych rozprowadzanych w pakietach jest tworzone w C++?
Mam tu namyśli takie gry typowo linuksowe jak Super Tux, Super Tux Kart itp..
https://github.com/SuperTux/supertux/releases/tag/v0.7.0
Nie ma gier w JavaScript, Pythonie, Vala czy innym dużo prostszym języku?
Czy chodzi o to że Linuksy muszą działać na bardzo słabych laptopach i V8 marnuje za dużo zasobów procesora?
Jest w ogóle sens pisać proste gry 2D w JavaScript. Czy może wybrać inny język do tego? Bardziej wydajny, kompilowany?

themovie napisał(a):

Jaki jest obecnie najpopularniejszy silnik gier do JavaScript? Słyszałem że Phaser jest dość popularny, oraz PixiJS.
Jest jeszcze Gamemarker, GDevelop, PlayCanvas, Babylon, Three, oraz Godot ale on chyba nie wspiera jakoś wyjątkowo JS.

Kiedyś w Unity można było pisać skrypty w Unity Script (język ze składnią JS).
Wywalili go w Unity 2018.2.

Dlaczego w dystrybucjach linuksowych najwięcej gier natywnych rozprowadzanych w pakietach jest tworzone w C++?
Mam tu namyśli takie gry typowo linuksowe jak Super Tux, Super Tux Kart itp..

Historycznie, Super Tux ma już 20 lat...
No i społeczność nerdów sprzyja powstawaniu aplikacji w "jedynym słusznym języku" :)

https://github.com/SuperTux/supertux/releases/tag/v0.7.0
Nie ma gier w JavaScript, Pythonie, Vala czy innym dużo prostszym języku?

Jak ktoś używa Linuksa, to nie dlatego, żeby sobie coś ułatwić :]

Czy chodzi o to że Linuksy muszą działać na bardzo słabych laptopach i V8 marnuje za dużo zasobów procesora?

Chyba woluntariusze tworzący oprogramowanie OpenSource na Linuksa nie mają takich wyśrubowanych wymagań.
Wybierają technologię i sobie w niej rozwijają projekt.

Linuksy chodzą i na bardzo słabych laptopach i na gamingowych PC-tach.
Jak ktoś ma zbyt słabego kompa, to po prostu sobie nie pogra, jak to było od dawna w świecie gier komputerowych.

Jest w ogóle sens pisać proste gry 2D w JavaScript. Czy może wybrać inny język do tego? Bardziej wydajny, kompilowany?

Język nie jest aż tak istotny. Ważny jest ekosystem wokół niego zbudowany.
Np. Java nie doczekała się konkretnego IDE do gier "all-in-one" jak Unity czy Unreal.
Dlatego mało kto kusi się na tworzenie gier w Javie.

Ja nie widzę sensu w tworzeniu gier w JavaScript. Nigdy się nie wciągnąłem w ten język.
Nie wiem czy warto uczyć się JavaScriptowych silników.
Musisz sam sprawdzić, czy warto poświęcić swój czas na dany silnik.
Jak długo silnik był rozwijany? Czy rozwój silnika nie zostanie ubity za jakiś czas? Czy w ogóle jakaś firma go używa? (jak silnik jest w biznesie, to udowodnił swoją wartość)

Nie ma sensu uczyć się czegoś, co już na starcie jest odrzucane przez resztę Świata.

Spine napisał(a):

Język nie jest aż tak istotny. Ważny jest ekosystem wokół niego zbudowany.
Np. Java nie doczekała się konkretnego IDE do gier "all-in-one" jak Unity czy Unreal.
Dlatego mało kto kusi się na tworzenie gier w Javie.

silniki do gier aaa (a także aa czy nawet indie, jeśli autorzy są nastawieni na jak największy zysk) ogólnie muszą działać na konsolach, żeby miały sens komercyjny. po co jakieś studio miałoby inwestować w grę, której nie można łatwo wydać na rynki konsolowe? to pozbawienie się dużej potencjalnej części przychodu. poniżej mój tok rozumowania.
(uwaga: poniżej są moje domysły, nie weryfikowałem tego, piszę z głowy na szybko)
java standardowo jest oparta o kompilację jit, która jest zablokowana na konsolach. stąd nie działa ani java, ani inne języki oparte o jity (c# w trybie jit, javascript kompilowany jitem, itp td). co najwyżej są te różne skrypty odpalane interpreterem i osandboksowane. c# w unity jest kompilowany w trybie aot, a takie coś można upchnąć na konsoli. ogólnie na konsolach (i w silnikach wieloplatformowych) liczy się obecnie jedynie c++ (jako język w którym stworzony jest silnik) oraz oskryptowanie do implementacji prostych kawałków logiki specyficznych dla danej gry.
(@themovie możesz wrzucić to w czata gpt i poprosić o zweryfikowanie, heh)

Jest w ogóle sens pisać proste gry 2D w JavaScript. Czy może wybrać inny język do tego? Bardziej wydajny, kompilowany?

Moim zdaniem, zdecydowanie jest sens. Powodem tego jest "raz piszesz, uruchamiasz wszędzie", na komputerach, tabletach, na smartfonach, a nawet na telewizorach z przeglądarką, a użytkownik końcowy nie musi nic instalować, tylko uruchamia link. Jednak lepiej zastosować WebAssembly za pomocą Rust lub ewentualnie C++ do implementacji logiki obliczeniowej (fizyka i mechanika gry), wydajność będzie wyraźnie lepsza niż sam JavaScript.

Co więcej, przy odpowiednim rozplanowaniu architektury, większość plików z kodem źródłowym będzie kopiowalna 1:1 w tym sensie, że z tych samych źródeł można zrobić zarówno zwykłą apkę, jak i WebAssembly do przeglądarki.

@Spine Java ma podobną wydajność do C#, więc w zasadzie gry 2D i 2.5D będą na niej chodzić bardzo dobrze. Przykład Minecraft.
Jest kilka silników gier do Javy jMOnkeyEngine, LibGDX
https://libgdx.com/
https://jmonkeyengine.org/
Ewentualnie do Kotlina, który teraz dominuje na Androidzie. Kotlin Game Engine (KGE), Korge,
https://korge.org/
https://github.com/staticsanches/kGE
Do C# to już są bardzo profesjonalne.
https://www.stride3d.net/
https://monogame.net/

@Wibowit chatGPT nieraz wypisuje dziwne rzeczy, wiele razy przyłapałem go na kłamstwie.
Zmyślał sobie jakieś swoje niestworzone rzeczy, gdy pokazałem mu informacje na Wikipedii to się poprawił i przeprosił.

@andrzejlisek No właśnie, mowa jest cały czas o prostych grach 2D, nie 3D. Więc wydajność JS powinna być wystarczająca.
Gdy ktoś chce pisać wydajne gry AA lub AAA i mieć prostą czytelną składnię może wybrać język D, który miał być następca języka C++.
Opcjonalnie można wyłączyć GC, w najbardziej obciążających grę zadaniach. Ten koleś dodał tak do swojego silnika.
https://www.reddit.com/r/d_language/comments/1pbldga/my_game_written_in_d_in_a_custom_engine_is_now/
https://store.steampowered.com/app/2290770/The_Art_of_Reflection/

https://github.com/gecko0307/dagon
https://dlang.org/blog/category/game-development/
https://github.com/ZILtoid1991/pixelperfectengine?tab=readme-ov-file
https://github.com/MrcSnm/HipremeEngine

themovie napisał(a):

@Spine Java ma podobną wydajność do C#, więc w zasadzie gry 2D i 2.5D będą na niej chodzić bardzo dobrze. Przykład Minecraft.

Nie mówię, że nie ;)
Sam zagrywałem się w gry napisane w Javie z użyciem LWJGL autorstwa Puppy Games ;)
Np. https://store.steampowered.com/app/93200/Revenge_of_the_Titans/

Jeśli jesteś solo koderem, to nikt nie narzuca Ci technologii i możesz robić grę w czym chcesz.

Problem może pojawić się gdy będziesz szukał współpracowników - wtedy lepiej robić w technologiach, które zna więcej osób.
Albo jak będziesz szukał pomocy "jak osiągnąć dany efekt, w technologii, którą sobie wybrałem".
Dla powszechnie stosowanych technologii znajdziesz tutoriale na YouTube, pomoc na forach, grupach itd.

Jest kilka silników gier do Javy jMOnkeyEngine, LibGDX
https://libgdx.com/
https://jmonkeyengine.org/

No, tak. Ale ten jMOnkeyEngine nie jest silnikiem z prawdziwego zdarzenia.
Nie ma wizualnego edytora, a to bardzo przyspiesza pracę i debugowanie.

Do C# to już są bardzo profesjonalne.
https://www.stride3d.net/
https://monogame.net/

Stride prezentuje się nieźle, kiedyś może obczaję go bliżej ;)
Na razie siedzę głęboko w C# + Unity 3D. Nie widzę potrzeby przesiadania się na coś innego.
Obsługuje wiele platform, wszystko co trzeba do tworzenia gier w Unity już całkiem dobrze opanowałem.

No właśnie, mowa jest cały czas o prostych grach 2D, nie 3D. Więc wydajność JS powinna być wystarczająca.

Nie wiem, jak to jest w przypadku gier (wypadłem z obiegu ponad 10 lat temu, już nie gram w gry poza "retro" na konsolce Anbernic RG35ZZ H będącym bardzo dobrym zabijaczem nudy i czasu), ale wydaje mi się, że cała branża powoli odchodzi od "zwykłych" programów (plik EXE lub odpowiednik w innych OS) na rzecz właśnie "aplikacji" uruchamianych w przeglądarce, czyli właśnie JavaScript/WASM. Rozwijają się hybrydy (Tauri, Electron), które taką aplikację JavaScript/WASM oprawiają w plik EXE. Jak dla mnie, jeden jeden powód, żeby zainteresować się tworzeniem gier 2D i innych prosty w JavaScript zamiast w postaci zwykłych programów. Albo w WebAssembly, jak kto lubi.

Gdy ktoś chce pisać wydajne gry AA lub AAA i mieć prostą czytelną składnię może wybrać język D, który miał być następca języka C++.

O ile się nie mylę, kilka gigantycznych projektów, jak AutoCAD, Office 365, Photoshop, Minecraft, już zostało przerobionych na wersję przeglądarkową właśnie z wykorzystaniem WebAssembly. Silnik Unity lub Unreal też już chyba ktoś przerobił na WebAssembly, więc wydaje mi się, ze grę AAA można zrobić w postaci programu przeglądarkowego. JavaScript to nie da rady, bo to za wolne, ale WebAssembly i WebGL to chyba już powinno dać radę. A jak jest robione w C++ czy w D, to można robić "podwójnie", czyli z jednego kodu źródłowego kompilować na WebAssembly i na wszystkie liczące się konsole, skoro "obecność" na konsolach jest podstawą sukcesu komercyjnego danej gry.

andrzejlisek napisał(a):

wydaje mi się, że cała branża powoli odchodzi od "zwykłych" programów (plik EXE lub odpowiednik w innych OS) na rzecz właśnie "aplikacji" uruchamianych w przeglądarce, czyli właśnie JavaScript/WASM.

Branża ciągle szła w WEB. Oferty pracy dla programistów to w większości WEB...
Dawno temu we Flashu powstało mnóstwo gier działających w przeglądarce.
Dla odpowiedniego rodzaju gier i sposobu ich monetyzacji ma to sens.
Było pełno "darmowych" gier online, z mikrotransakcjami.

Ale tradycyjna branża gier mocno się trzyma plików wykonywalnych uruchamianych na komputerze użytkownika.
Nawet jeśli wydajność w przeglądarce nie jest problemem, bo komputery są już dość mocne, to jest to pewna warstwa pośrednia, która niesie ograniczenia niepozwalające na pełne wykorzystanie sprzętu gracza.
I pewnie gra będzie zużywać trochę więcej prądu bo jakiś narzut jest ;)

Google Stadia upadło, izolowanie plików wykonywalnych dużych gier się nie powiodło w tym przypadku ;)

andrzejlisek napisał(a):

A jak jest robione w C++ czy w D, to można robić "podwójnie", czyli z jednego kodu źródłowego kompilować na WebAssembly i na wszystkie liczące się konsole, skoro "obecność" na konsolach jest podstawą sukcesu komercyjnego danej gry.

W Unity możemy sobie zbudować apkę z kodem w C# na dowolną platformę.
Jak chcemy, żeby kod w buildzie został skonwertowany do C++, to wybieramy odpowiednią opcję:

Info: https://docs.unity3d.com/6000.3/Documentation/Manual/il2cpp-introduction.html

andrzejlisek napisał(a):

Gdy ktoś chce pisać wydajne gry AA lub AAA i mieć prostą czytelną składnię może wybrać język D, który miał być następca języka C++.

O ile się nie mylę, kilka gigantycznych projektów, jak AutoCAD, Office 365, Photoshop, Minecraft, już zostało przerobionych na wersję przeglądarkową właśnie z wykorzystaniem WebAssembly. Silnik Unity lub Unreal też już chyba ktoś przerobił na WebAssembly, więc wydaje mi się, ze grę AAA można zrobić w postaci programu przeglądarkowego. JavaScript to nie da rady, bo to za wolne, ale WebAssembly i WebGL to chyba już powinno dać radę. A jak jest robione w C++ czy w D, to można robić "podwójnie", czyli z jednego kodu źródłowego kompilować na WebAssembly i na wszystkie liczące się konsole, skoro "obecność" na konsolach jest podstawą sukcesu komercyjnego danej gry.

webowy photoshop to marna podróbka oryginału. jest ubogi w opcje i wszystko się dzieje w jednym oknie. widać ograniczenia typowe dla webowych frameworków.
webowy office 365 to też całkowicie osobna wersja, a nie desktopowy oryginał z innymi opcjami kompilacji.
reszta wersji webowych też ma szereg ograniczeń względem wersji desktopowych.

jeśli chodzi o kompilację z jednego kodu źródłowego na więcej niż jedną docelową platformę programistyczną to jest już taki biznes od dobrych paru lat i są to przeróżne frameworki do produkowania aplikacji na smartfony. obiecują, że z jednego kodu źródłowego zrobisz wersje na androida i apple ios, ale działa to słabo i programiści i tak wolą robić osobne projekty.

jeśli chodzi o zastępowanie c++ jakimś 'lepszym' (w cudzysłowie, bo to jest dość subiektywne jednak) odpowiednikiem to kibicuję rustowi :) rust powinien równie dobrze nadawać się do pisania gier aaa, ale branża gier jest raczej konserwatywna, więc sporo z przesiadką poczekają. ogólnie do tworzenia gier aaa pasowałoby użyć języka stworzonego typowo pod kompilację aot. są takie języki, ale jakoś nie zdobywają popularności. krótka lista i moje opinie:

• rust - temu kibicuję (jak już napisałem)
• pascal i pascalopodobne - nigdy nie były zagrożeniem dla dominacji c/c++ i w zasadzie pewnie też nie oferują jakichś znaczących ulepszeń względem nowoczesnego c++a
• golang - prawdopodobnie znacznie wygodniejszy niż c/c++ (bo inaczej nie zdobyłby tak dużej popularności, no nie?) ale i tak jakoś nie słyszałem, żeby ktoś tworzył w nim gry. dziwne, bo to język stworzony pod kompilację aot, a do tego oparty o non-moving tracing gc z niskimi pauzami. dzięki temu, że jest non-moving to można łatwo i efektywnie korzystać ze wskaźników do wszelkich obiektów na stercie, a więc powinno się dać efektywnie integrować z kodem niezarządzanym (tak zgaduję).
• swift - kolejny niby mocny kandydat, ale i tak nic o nim nie słychać w kontekście gamedevu, ani nawet w czymkolwiek poza ekosystemem apple'a.

@andrzejlisek Branża może odchodzi od plików exe, ale od gier multiplayer raczej nie odejdzie. Mam tu na myśli takie kultowe tytuły na których zarabiają miliardy. Delta Force, Marathon, Battlefield, Call od Duty, Valorant, Fortnite, GTA Online.
Więc jak działają takie gry? Ich backend nie jest napisany w czystym C++ lub silniku gier stworzonym w C++?
W takich dużych grach FPS gdzie opóźnienia są ważne stosują Jave, JavaScript/Node? Chyba nie.
Nawet w takim Unity wszystko napisane jest w języku C++.
C++ jest znacznie szybszy, ponieważ kompiluje się do kodu maszynowego (lub pośredniego punktu w asemblerze). To naturalny język dla sprzętu, więc działa on instynktownie.
C# nie kompiluje się w ten sposób. „Kompiluje” się do kodu bajtowego, który wymaga translatora. Komputer nie może więc działać instynktownie, lecz musi słuchać, co powinien zrobić.
Np. Python jest w całości interpretowany, tzn. najpierw odczytuje to, co zostało powiedziane, a następnie musi sprawdzić to przy pomocy tłumacza, zanim będzie mógł sprawdzić, co powinien zrobić.
Jednak w Unity C# kompiluje się do tego samego C++, które kompiluje się do kodu maszynowego. Dzięki temu Unity C# jest o wiele szybszy niż zwykły C#.
Nie tak szybki, jak byłby natywny, ale niewiele mu brakuje.
Poza tym, chociaż UE5 to język C++, jego znajomość nie jest zbyt dobrze przyswajalna. UE5 ma własne wskaźniki zastępujące inteligentne wskaźniki. Wszędzie jest mnóstwo makr, z których trzeba korzystać. Poza tym UE5 jest w dużej mierze oparty na programowaniu obiektowym (OOP) i własnej strukturze. Wszystko trzeba robić w sposób typowy dla UE, nie ma tu żadnej swobody. Jeśli jednak skorzystasz z jakiejkolwiek swobody, prawdopodobnie spowoduje to problemy w przyszłości.
Reasumując C# w Unity jest szybszy od zwykłego C# na CLR.

jeśli chodzi o kompilację z jednego kodu źródłowego na więcej niż jedną docelową platformę programistyczną to jest już taki biznes od dobrych paru lat i są to przeróżne frameworki do produkowania aplikacji na smartfony. obiecują, że z jednego kodu źródłowego zrobisz wersje na androida i apple ios, ale działa to słabo i programiści i tak wolą robić osobne projekty.

Czy mówimy o tym samym sposobie pracy, czy o dwóch różnych sposobach pracy? Posłużę się przykładem: Chciałbym zbudować program "RPaint" o funkcjonalności podobnej do Paint.NET, albo nawet zwykły Paint z Windows plus kilka dodatków. Program byłby w wersji EXE z GTK+ i w wersji HTML+JS+WebAssembly. Robię dwa projekty w Rust, pierwszy to RPaintApp, drugi to RPaintWeb. W pierwszym "na dzień dobry" otrzymuję plik main.rs, w drugim otrzymuję lib.rs. W projekcie RPaintApp tworzę logikę biznesową w plikach core.rs (styk GUI z logiką biznesową, która ma "funkcje publiczne") picture.rs (struktura obrazu z funkcjami rysowania), layer.rs (struktura stosu warstw z atrybutami), transform.js (przekształcenia graficzne, jak rozciąganie, obracanie) filter.rs (proste filtry graficzne, jak rozmycie, wyostrzanie, kontrast, jasność). Aby zachować porządek, tworzę plik gui.rs, w którym tworzę i obsługuję interfejs w GTK+.

Podczas pracy, w plikach picture.rs, layer.rs, transform.js, filter.rs unikam elementów charakterystycznych dla zwykłych programów (pliki, wywołania GTK+). Jeżeli zachodzi potrzeba wykonania "tej samej czynnośći", ale realizowanej w inny sposób, to robię wywołanie funkcji main.rs. Funkcja "zapisz" wywołuje funkcję save_pictue() z core.js, a ona sama wywołuje save_data(name: String, data: Vec<u8>) będąca w main.rs lub w lib.rs.

Mam działającą wersję EXE z GTK+. Teraz czas na wersję HTML+JS+WebAssembly, czyli RPaintWeb. Interfejs GUI robię w HTML+CSS+JavaScript, w pliku lib.rs również jest funkcja save_data(name: String, data: Vec<u8>), ale ona nie zapisuje pliku, tylko wywołuje funkcję JavaScript, która zachowuje do LocalStorage. Obydwa projekty robię tak, że pliki picture.rs, layer.rs, transform.js, filter.rs są identyczne i obydwa programy działają poprawnie. To, co jest charakterystyczne dla danej technologii (pliki, GTK+, canvas, LocalStorage) jest poza tymi plikami i tworzę osobno. A jeżeli robię logikę biznesową (pliki picture.rs, layer.rs, transform.js, filter.rs), to modyfikuję i testuję w RPaintApp, a potem odpalam skrypt bash, który kopiuje te konkretne pliki do RPaintWeb z nadpisaniem bez pytania i uruchamia kompilację do WebAssembly. Dla formalności testuje w przeglądarce, funkcje rysowania, rozciągania, jasność i kontrast działają identycznie, bo są z tego samego kodu źródłowego.

Krótko mówiąc, nie jest to jeden projekt z różnymi opcjami kompilacji, tylko formalnie są to dwa projekty, ale kod źródłowy z logiką biznesową jest identyczny i to jest "kompilacja z jednego kodu źródłowego" w moim rozumieniu. Jeden projekt w tym przypadku to więcej kłopotów niż pożytku, bo zasada działania i możliwości "kontaktu z systemem i użytkownikiem" w HTML+JavaScript są fundamentalnie inne niż w EXE. A najważniejsza jest logika biznesowa, którą jest 80% całego programu (pliki z tym kodem są kopiowane). A 20% to sama obsługa interfejsu, kody klejowe, żeby to ze sobą współpracowało (ten kod nie jest kopiowany, tylko tworzony niezależnie).

A jak mi się kiedyś tam odwidzi i wymyślę, że chcę mieć trzecią wersję w Cocoa na MacOS, to tworzę jeszcze jeden projekt RPaintMac, skrypt kopiujący logikę biznesową i tworzę tylko obsługę interfejsu i kod klejowy (glue code) dopasowany do zastanej logiki biznesowej.

themovie napisał(a):

Poza tym, chociaż UE5 to język C++, jego znajomość nie jest zbyt dobrze przyswajalna. UE5 ma własne wskaźniki zastępujące inteligentne wskaźniki. Wszędzie jest mnóstwo makr, z których trzeba korzystać. Poza tym UE5 jest w dużej mierze oparty na programowaniu obiektowym (OOP) i własnej strukturze. Wszystko trzeba robić w sposób typowy dla UE, nie ma tu żadnej swobody. Jeśli jednak skorzystasz z jakiejkolwiek swobody, prawdopodobnie spowoduje to problemy w przyszłości.

W UE ile się da najbezpieczniej robić Blueprintami ;)
Wtedy znikają pułapki czekające na programistów, którzy gorzej znają C++.

Dlaczego język D nie zdobył takiej popularności jak C++? Jego składnia jest dość czytelna i język wydaje się spójny i prosty.
Czego konkretnie obecnie brakuje w języku C że ludzie przechodzą do C++.?
Czy jakby w nowych standardach języka C dodać klasy to one mogą uratować ten język? Przed migracją programistów do C++ i Rust?

Obawiam się że C++ robi się za bardzo skomplikowany i korporacje mają rację odradzając go do nauki w 2026.
Za Rustem też jakoś specjalnie programiści nie przepadają. Więc gdyby dało się uratować język C nowymi funkcjami.

themovie napisał(a):

Dlaczego język D nie zdobył takiej popularności jak C++? Jego składnia jest dość czytelna i język wydaje się spójny i prosty.
Czego konkretnie obecnie brakuje w języku C że ludzie przechodzą do C++.?

Ty serio zadajesz takie pytania, czy tylko zarzucasz tematy do dyskusji?

C++ ma lata przewagi. Wbił się do branży w odpowiednim czasie i zdążył zapuścić korzenie.
Wiele wynalazków ma podobną historię. Wyrwać "rynek" produktom, które go zdominowały nie jest łatwo i tanio.
Nawet jeśli naprawdę powstanie coś lepszego i logicznym krokiem byłaby migracja na dane rozwiązanie, to ludzkość stawia opór...

themovie napisał(a):

Jaki jest obecnie najpopularniejszy silnik gier do JavaScript? Słyszałem że Phaser jest dość popularny, oraz PixiJS.

Three.js, Phaser, Pixi.js to bardziej silniki grafiki z pewnymi elementami silnika gier. I to nie jest złe, masz grafikę, a za część grową jesteś odpowiedzialny sam (polecam oddzielać logikę gry od prezentacji, a nie mieszać wszystkiego razem. Wtedy jesteś niezależny od danej biblioteki. Chociaż Phaser chyba promuje się jako framework, do którego należy wszystko wrzucać, ale do mnie nie przemawia takie podejście).

Three.js to solidna biblioteka do 3D. Polecanko. Nie wszystko jest tam super fajne, ale czy Babylon lepszy? Nie sądzę, patrzyłem na przykłady kodu w Babylonie i ta sama bieda. Nawet Three.js wydaje mi się bardziej intuicyjne.

Do grafiki 2D faktycznie Phaser i PixiJS są popularne, ale zastanowiłbym się najpierw, jak ma dokładnie twoja grafika wyglądać. Jeśli będzie w niej dużo elementów wektorowych, to może lepiej oprzeć grafikę o SVG. Jeśli będzie się opierał w dużej mierze o GUI z lekką ilością animacji, to może zrobić to na DOM. Czystym albo np. w React. Wybieranie Pixi czy Phaser tylko dlatego, że będzie tam kolorowa grafika 2D z animacjami, to częsty błąd.