Luke J. Li

Projekt, o którym pisałem ostatnio, musi trochę poczekać, bo w międzyczasie wpadłem na pomysł zrobienia gry w Three.js . Wzięło się to z tego, że ostatnio prowadzę rozmowy w sprawie współpracy z firmą, która robi projekt w WebGL i chciałem sobie przypomnieć temat robienia grafiki 3D w JavaScript. I z rozpędu zacząłem grę robić. O grze napiszę później, jednak teraz trochę o samej bibliotece. Ale nie będzie to tutorial, tylko rzut okiem z lotu ptaka. Jaki problem rozwiązuje ta biblioteka? Czy jeśli jest natywne api do robienia 3D w przeglądarce (WebGL), to czy warto w ogóle osobnej biblioteki używać? Czy to taki kaprys, podobny do używania jQuery w 2019 roku? Przecież można pisać w WebGL. Wyrzućmy biblioteki w kosmos! Cóż, z używaniem suchego WebGLa jest taki problem, że tam proste rzeczy robi się w złożony niskopoziomowy sposób. Zróbcie sobie jakiś tutorial, to zobaczycie, że nawet, żeby wyrenderować obracającą się kostkę, trzeba się namęczyć. Więc o ile warto poznać suchego We...

Zmieniło się trochę. Nie tylko robię edytor, ale i cały silnik do gier w JavaScript (nastawiam się na 2D). Dlaczego? Cóż, zacząłem robić ten edytor na frameworku Phaser, co początkowo dało mi kopa. Phaser ma bardzo dobre wsparcie, dużo przykładów i świetne community. Na każdy problem mogłem znaleźć szybko odpowiedź w necie. Phaser posiada również dużo przydatnych ficzerów do obsługi sprajtów (częściowo wziętych z biblioteki Pixi). Więc mogłem zrobić szybko mój prototyp edytora . Problem jednak w tym, że Phaser to framework, więc tak jak każdy framework - ogranicza . Ciężko zrobić coś większego, dopasować to pod swoje potrzeby. Dlatego postanowiłem zrobić własny silnik, dopasowany do moich potrzeb. Czy to nie jest porywanie się z motyką na słońce i niepotrzebne odkrywanie Ameryki? Nie. Zrobienie pewnych rzeczy samemu jest często o wiele prostsze niż walka z frameworkiem-kobyłą. Robiąc własny silnik mogę również wszystko kontrolować, wprowadzać tam taką architekturę oraz wz...

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. ...