Luke J. Li

Więc tak, pisałem sobie ten silnik 3D i cóż, okazało się, że im bardziej się rozrastał, tym więcej miałem problemów z długiem technicznym (zrobiłem coś, co wyglądało fajnie w teorii, ale w praktyce, żeby coś dodać, musiałem trochę pohakować silnik) oraz też zacząłem odczuwać problemy z wydajnością. I tutaj na tym etapie zacząłem eksperymentować z użyciem WebAssembly - ponieważ w profilerze zobaczyłem, że dużo czasu CPU schodzi na liczenie macierzy, postanowiłem liczyć macierze w WebAssembly, używając Rust-a i biblioteki do macierzy pisanej w Rust. I co się okazało? Moja "optymalizacja" nie przyniosła oczekiwanych rezultatów. Być może dlatego, że i tak w JS musiałem iterować po obiektach i masę rzeczy innych robić, a w Wasm tylko liczyłem macierze. Zbyt duża część silnika polegała na (z konieczności) kiepsko napisanym JS, że Więc pomyślałem, że może trzeba jeszcze więcej obliczeń wrzucić do Wasm, najlepiej całe drzewko sceny tam zapisywać i robić tam wszystko, w JS tylko...

Ostatnio (od stycznia) mocno wszedłem w temat Three.js. Masę rzeczy się nauczyłem. No i zrobiłem taki edytor . chociaż on jeszcze nie skończony jest. Tylko, że w międzyczasie inne pomysły mnie naszły, więc z jednego projektu w Three.js zrobiłem kilka projektów. Wydzieliłem "silnik" oraz rzeczy specyficzne dla projektu i jakby robię kilka apek na jednym silniku (nawet w jednym repo wszystko jest, tak wygodniej). Poza tym: nauczyłem się operować na wierzchołkach, tworzyć własną geometrię. W ten sposób tworzę teren: https://github.com/hex13/tileterrain/ . Jest on inspirowany terenem, jaki miały gry izometryczne z lat 90 stworzyłem własny shader. I dzięki temu mam inny kolor terenu na różnych wysokościach (na górze śnieg, niżej skały, niżej trawa, a najniżej piasek). A przedtem to shaderów się bałem. poznałem wiele dziwactw Three.js. Niestety jest to biblioteka, która ma wiele rzeczy nieintuicyjnych i trzeba naprawdę uważnie czytać dokumentację + uczyć się na własnych błęda...

Nie lubię gotowców. Sprawiają, że człowiek ma 5 razy więcej roboty. Mimo, że obiecują co innego. Mnóstwo czasu zajmuje często: szukanie gotowca rozgryzanie jak on działa (dużo gotowców jest trudnych w obsłudze) ewentualna modyfikacja, kiedy okazuje się, że nie jest to, czego oczekujemy i trzeba czasem duuużo się nakodzić i dużo bardziej okrężną drogą niż by się to robiło samemu. a często natrafiamy na ścianę i okazuje się, że coś trzeba robić od nowa, i że dany gotowiec się okazuje być słaby (często się to okazuje po fakcie, kiedy już włożyliśmy w to masę pracy) Dlatego zwykle staram się najpierw rozwiązać jakiś problem samemu, a szukanie gotowców uważam za ostateczność. Nie zrozumcie mnie źle. Często korzystam z frameworków czy przydatnych bibliotek. Przez gotowce mam na myśli raczej: gotowe kawałki kodu, które bardzo łatwo jest napisać samemu , i w zasadzie można je napisać samemu, i należałoby chyba, o ile nie ma szczególnych powodów, żeby użyć gotowca. ...

Postanowiłem zamiast używać Phasera, skorzystać z Pixi, biblioteki graficznej na której Phaser się w duuużej mierze opiera. Czym jest Pixi ? To po prostu szybki silnik renderujący grafikę 2D w przeglądarce, korzystający z WebGL (jeśli jest dostępny), w ostateczności ze zwykłego Canvasa. Wokół tej biblioteki Phaser dodaje swoje dodatkowe funkcje. Tylko tak - "silnik renderujący" - wydaje się, że to coś strasznie niskopoziomowego? No właśnie nie. API jest może jeszcze prostsze od Phasera. W zasadzie super proste, jeśli miałeś do czynienia kiedyś z programowaniem pod Flasha - bo w Pixi większość funkcji i obiektów opiera się na klasach z ActionScriptu - mamy obiekt Stage, Sprite etc. Mamy hierarchię obiektów na scenie, filtry, zdarzenia myszy/dotyku etc. Pomyślałem więc, że jeśli i tak mi Phaser nie do końca odpowiada (i czuję, że pisząc w Phaserze po prostu musiałbym jednak dodatkowy metaframework zrobić do niego), to może wyjmę z niego samą bibliotekę, na której się on ...

Powracam do Phasera, próbuję zrobić w nim teraz grę. Ale tak - API niby proste, ale i tak trzeba napisać trochę kodu inicjalizującego, zanim cokolwiek się pokaże na ekranie, co jest upierdliwe. Niby jest to prosty kod i ogranicza się do wywoływania metod w stylu game.load.image(...), game.add.sprite(....) etc. ale i tak, jeśli muszę ładować ileś sprajtów, to ten kod staje się brzydki i w stylu copy-pastego. Trochę bez sensu, prawda (a tak jest w tutorialach, więc tak się chyba tam robi)? Dlatego więc zrobiłem sobie własny loader do sprajtów: i zamiast kodować ręcznie game.add.sprite, to piszę sobie JSONa, który zawiera wszystkie sprajty i definicje: Prawda, że wygląda dość prosto? ;) No więc tym sposobem mam w zasadzie całą planszę w postaci struktury danych w pliku JSON. Strukturę tę później ładuję do skryptu i w pętli przechodzę przez wszystkie obiekty i obrazki i robię automatyczne ich ładowanie. Co mi to daje? mniej bezsensownego pisania. Jak chcę, żeby jednost...

Kolejny JavaScriptowy framework, tym razem Phaser. Zaczynam się go uczyć. Z tego co widziałem, to API urzeka prostotą, chociaż jeszcze wciąż się zmienia niestety (rozwojowy framework :( Przykłady: http://examples.phaser.io/ Dokumentacja: http://docs.phaser.io/ Kod źródłowy: https://github.com/photonstorm/phaser Ogólne linki: http://gametest.mobi/phaser/docs/Phaser.html

Z powodu braku czasu musiałem zrobić przerwę w prowadzeniu bloga, ale mam nadzieję, że niedługo uda mi się napisać kolejną część tutoriala. Ponadto może się tu pojawić też niedługo coś związanego z Cocos2D, wieloplatformowym* frameworkiem do gier, w którym jest możliwość pisania kodu w JavaScript - taka gra później odpali się zarówo w przeglądarce, jak i po skompilowaniu na telefonie komórkowym czy innym mobilnym urządzeniu. W przeciwieństwie do innych podobnych technologii, Cocos2d-x (z iksem na końcu, patrz gwiazdka pod tekstem) nie osadza kodu HTML5 w aplikacji, ani nie tworzy webowych rozwiązań typu Canvas, tylko raczej tłumaczy kod JavaScript na wywołania natywnych funkcji zaimplementowanych we frameworku. Więc ma to potencjał do bycia bardziej wydajnym niż webowo-htmlowe rozwiązania (ale czy tak jest w istocie, nie wiem, postaram się dotrzeć do jakichś benchmarków i tu wrzucić jak coś znajdę). W Cocos2D masz do dyspozycji dwa silniki fizyki - Box2D oraz Chipmunk . W tej...