Pokaż wiadomości
1
Poszukuję, chcę zrobić / Edytor Scenerii
« dnia: 06 Marca 2023, 02:24:06 »
Cześć.
W paru niedawnych wątkach traktujących pobocznie o przyszłości MaSzyny, przewinęło się stwierdzenie że symulatorowi brakuje scenerii, a to głównie przez poziom skomplikowania narzędzi edytorskich. Kilka miesięcy temu, w jakiejś tam rozmowie z synem, uznałem podobnie - nie mieliśmy czym zrobić scenerii, a próg wejścia w obecne narzędzia okazał się zbyt wysoki i temat odpuściłem.
Zakiełkował mi wtedy pomysł zrobienia edytora do MaSzyny, a że proste to nie będzie, i że mam tam jakieś doświadczenie w developerce i różnych projektach, i biorąc pod uwagę dość ograniczony czas na zabawę, to założyłem że twórcy edytora muszą skupić się na mięchu a nie programowaniu kontrolek UI albo 3D. Na to nie ma po prostu czasu i zasobów. Pisanie w C(++) nie kalkuluje się - szczególnie do projektu edytora, bo to nie silnik symulatora który ma być jakoś super optymalny. Założyłem też, że edytor musi być multiplatformowy, co samo w sobie staje się pewnym wyzwaniem.
Ponieważ amatorsko interesuję się gamedevem (ścieżka kariery, którą ostatecznie nie poszedłem bo łatwiej było zarobić na tabelkach dla biznesu), jestem zwolennikiem opensource, lubię MaSzynę ponad inne symulatory (kolega EU40 pisze o jakiejś "magii" i wydaje mi się, że go rozumiem), no i przyszedł w końcu kryzys wieku średniego, to zacząłem kręcić się wokół niespełnionych ambicji młodości, czyli wokół narzędzi do gamedevu (w międzyczasie zbierając złom na pulpit do MaSzyny). Przeszedłem przez Unity, Unreal Engine, przyglądałem się samym silnikom oraz wynalazkom typu Bevy (w Rust), a do poduszki czytałem o OpenGL. W tej podróży przewijał się ciągle, trochę na zasadzie love-hate, wieloplatformowy silnik/edytor opensource - Godot (https://godotengine.org/).
Macałem Godota (!) w różnych kontekstach i z różnymi pomysłami. Zachłysnąłem się możliwościami współczesnego gamedevu, gdzie mogłem skupić się na mięchu a nie mapowaniu rysunków na trójkąty, mając jednocześnie otwarte źródła do ewentualnego spatchowania renderera wg potrzeb. Przemknął mi oczywiście irracjonalny pomysł "przepisania MaSzyny na [wpisz nazwę ulubionego engine]", ale znam trochę exe Symulatora i wiem że w fizyce dzieje się sporo. Wiem, jak czasem niektóre rozwiązania z wielu warstw są od siebie mocno zależne. Zrozumiałem siłę customowego renderera (bo gotowce, mimo cudów na kiju, wbrew pozorom mogą być ograniczone, zbyt generyczne, i bez patchowania niekoniecznie optymalne do tego zadania), jego lekkości, w tym czasu kompilacji. Pomysł "przepisania" MaSzyny, nawet jako wieloosobowy projekt, ostatecznie skreśliłem - nie miałby szans na powodzenie przede wszystkim dlatego, że nie wnosiłby niczego nowego poza PBR (do którego konwersja byłaby raczej czasochłonna), IK, łatwiejszym skryptowaniem, poukładanym kodem (z nowymi chorobami wieku dziecięcego), i może jeszcze jakimiś kilkoma pierdołami.
Siłą MaSzyny jest content, fizyka, swoboda konfiguracji i eksploatacji symulatora, pomieszana ze wspomnianą magią oraz podlana otwartymi źródłami, które tworzą społeczność. A jak wiemy, społeczność ma problem z dostarczaniem contentu. I tym sposobem docieramy do zamysłu projektu, który chciałbym nazwać ogólnie Edytorem MaSzyny, a którego realizację chciałbymzaproponować narzucić z użyciem Godot Engine. Jednym z problemów jest nasz czas, a właściwie jego deficyt - mamy go za mało na projekty poboczne, dlatego gotowiec w wielu aspektach nas wyręczy. A że nie jest to engine dla samego Symulatora, to nie powinno mieć dla nikogo znaczenia czy ma jakąś funkcję czy nie, czy go ktoś lubi czy też nie. Celem jest budowa narzędzia lub wielu narzędzi do Symulatora.
Ale że robić edytor do gry w edytorze gier? Dokładnie. I nie jest to wyjątek (vide Material Maker i inne). Godot ma pewną unikalną cechę w porównaniu do innych silników - ma świetnie zrealizowane, współgrające ze sobą 2D i 3D, gdzie dla 2D jest cały zestaw komponentów dla UI. Zapewnia wieloplatformowość, renderer 3D, rozszerzalność i wygodne mechanizmy tworzenia narzędzi (w tym pluginów samego edytora), wygodny hierarchiczny system scen i węzłów, skryptowy język do szybkiego prototypowania GDScript (czerpiący z Pythona garściami), i szereg pierdół ułatwiających pracę nad narzędziem. Do tego jest opensource, na licencji MIT (żadnego bulenia korporacjom), i odpali się nawet na Androidzie (nie wiem po co, ale sportowali go na Andka - ponoć ktoś tego używa w podróży pociągiem). Niewątpliwą zaletą jest też to, że można zacząć dłubać narzędzie niekoniecznie znając algebrę (do tej pory łamię sobie głowę na kwaternionach, a coś tam mimo tego wychodzi). Czyli próg wejścia jest stosunkowo niski, a system operacyjny programistów i późniejszych użytkowników nie będzie miał znaczenia (można nawet próbować wydać build w WebGL i odpalać edytor w przeglądarce).
Czego nie ma na teraz Godot? Nie czyta plików MaSzyny (E3D, SCN, itd), oraz nie obsługuje DDS-ów w runtime (importer obsługuje, ale nas interesuje runtime). Te pierwsze da się ogarnąć w formie pluginu do Godota, czego jakiś tam prototyp mam i wsysam sobie testowo obiekty z MaSzyny. To drugie (DDS) będzie wkrótce obsługiwane w upstreamie (moje patche czekają na merge, bo dostały względnie niski priorytet). Czyli narzędzie do budowy narzędzia jest niemal gotowe do użycia.
Po co piszę post zamiast robić ten edytor w tym tak wspaniałym narzędziu? Doskonale zdaję sobie sprawę, że sam tego nie pociągnę. A nawet jeśli pociągnę, to zakładając że nie umrę ze zgryzoty lub nie wpadnę pod pociąg, projekt musi spotkać się z zainteresowaniem społeczności MaSzyny. Choćby dlatego, żeby ktoś inny mógł prowadzić rozwój edytora dalej, oraz żeby sami twórcy contentu byli zainteresowani modernizacją swojej narzędziowni. Żeby to wszystko zadziałało, musielibyśmy mieć określoną ogólną wizję przyszłości Symulatora, którą wg mnie przede wszystkim jest content. Dopiero później, kiedy Edytor już coś tam mógłby zmieniać, można byłoby zacząć pochylać się nad usprawnieniami exe/renderera, który mógłby zacząć pozwalać na np. heightmapy, automayczne sianie trawska, splatmapy i inne cuda na kiju, które Edytor Scenerii wspierałby na bieżąco wraz z rozwojem EXE.
Tak sobie wyobrażam rozwój Symulatora. Tyle ode mnie tej nocy. Pozdrawiam.
Marcin
W paru niedawnych wątkach traktujących pobocznie o przyszłości MaSzyny, przewinęło się stwierdzenie że symulatorowi brakuje scenerii, a to głównie przez poziom skomplikowania narzędzi edytorskich. Kilka miesięcy temu, w jakiejś tam rozmowie z synem, uznałem podobnie - nie mieliśmy czym zrobić scenerii, a próg wejścia w obecne narzędzia okazał się zbyt wysoki i temat odpuściłem.
Zakiełkował mi wtedy pomysł zrobienia edytora do MaSzyny, a że proste to nie będzie, i że mam tam jakieś doświadczenie w developerce i różnych projektach, i biorąc pod uwagę dość ograniczony czas na zabawę, to założyłem że twórcy edytora muszą skupić się na mięchu a nie programowaniu kontrolek UI albo 3D. Na to nie ma po prostu czasu i zasobów. Pisanie w C(++) nie kalkuluje się - szczególnie do projektu edytora, bo to nie silnik symulatora który ma być jakoś super optymalny. Założyłem też, że edytor musi być multiplatformowy, co samo w sobie staje się pewnym wyzwaniem.
Ponieważ amatorsko interesuję się gamedevem (ścieżka kariery, którą ostatecznie nie poszedłem bo łatwiej było zarobić na tabelkach dla biznesu), jestem zwolennikiem opensource, lubię MaSzynę ponad inne symulatory (kolega EU40 pisze o jakiejś "magii" i wydaje mi się, że go rozumiem), no i przyszedł w końcu kryzys wieku średniego, to zacząłem kręcić się wokół niespełnionych ambicji młodości, czyli wokół narzędzi do gamedevu (w międzyczasie zbierając złom na pulpit do MaSzyny). Przeszedłem przez Unity, Unreal Engine, przyglądałem się samym silnikom oraz wynalazkom typu Bevy (w Rust), a do poduszki czytałem o OpenGL. W tej podróży przewijał się ciągle, trochę na zasadzie love-hate, wieloplatformowy silnik/edytor opensource - Godot (https://godotengine.org/).
Macałem Godota (!) w różnych kontekstach i z różnymi pomysłami. Zachłysnąłem się możliwościami współczesnego gamedevu, gdzie mogłem skupić się na mięchu a nie mapowaniu rysunków na trójkąty, mając jednocześnie otwarte źródła do ewentualnego spatchowania renderera wg potrzeb. Przemknął mi oczywiście irracjonalny pomysł "przepisania MaSzyny na [wpisz nazwę ulubionego engine]", ale znam trochę exe Symulatora i wiem że w fizyce dzieje się sporo. Wiem, jak czasem niektóre rozwiązania z wielu warstw są od siebie mocno zależne. Zrozumiałem siłę customowego renderera (bo gotowce, mimo cudów na kiju, wbrew pozorom mogą być ograniczone, zbyt generyczne, i bez patchowania niekoniecznie optymalne do tego zadania), jego lekkości, w tym czasu kompilacji. Pomysł "przepisania" MaSzyny, nawet jako wieloosobowy projekt, ostatecznie skreśliłem - nie miałby szans na powodzenie przede wszystkim dlatego, że nie wnosiłby niczego nowego poza PBR (do którego konwersja byłaby raczej czasochłonna), IK, łatwiejszym skryptowaniem, poukładanym kodem (z nowymi chorobami wieku dziecięcego), i może jeszcze jakimiś kilkoma pierdołami.
Siłą MaSzyny jest content, fizyka, swoboda konfiguracji i eksploatacji symulatora, pomieszana ze wspomnianą magią oraz podlana otwartymi źródłami, które tworzą społeczność. A jak wiemy, społeczność ma problem z dostarczaniem contentu. I tym sposobem docieramy do zamysłu projektu, który chciałbym nazwać ogólnie Edytorem MaSzyny, a którego realizację chciałbym
Ale że robić edytor do gry w edytorze gier? Dokładnie. I nie jest to wyjątek (vide Material Maker i inne). Godot ma pewną unikalną cechę w porównaniu do innych silników - ma świetnie zrealizowane, współgrające ze sobą 2D i 3D, gdzie dla 2D jest cały zestaw komponentów dla UI. Zapewnia wieloplatformowość, renderer 3D, rozszerzalność i wygodne mechanizmy tworzenia narzędzi (w tym pluginów samego edytora), wygodny hierarchiczny system scen i węzłów, skryptowy język do szybkiego prototypowania GDScript (czerpiący z Pythona garściami), i szereg pierdół ułatwiających pracę nad narzędziem. Do tego jest opensource, na licencji MIT (żadnego bulenia korporacjom), i odpali się nawet na Androidzie (nie wiem po co, ale sportowali go na Andka - ponoć ktoś tego używa w podróży pociągiem). Niewątpliwą zaletą jest też to, że można zacząć dłubać narzędzie niekoniecznie znając algebrę (do tej pory łamię sobie głowę na kwaternionach, a coś tam mimo tego wychodzi). Czyli próg wejścia jest stosunkowo niski, a system operacyjny programistów i późniejszych użytkowników nie będzie miał znaczenia (można nawet próbować wydać build w WebGL i odpalać edytor w przeglądarce).
Czego nie ma na teraz Godot? Nie czyta plików MaSzyny (E3D, SCN, itd), oraz nie obsługuje DDS-ów w runtime (importer obsługuje, ale nas interesuje runtime). Te pierwsze da się ogarnąć w formie pluginu do Godota, czego jakiś tam prototyp mam i wsysam sobie testowo obiekty z MaSzyny. To drugie (DDS) będzie wkrótce obsługiwane w upstreamie (moje patche czekają na merge, bo dostały względnie niski priorytet). Czyli narzędzie do budowy narzędzia jest niemal gotowe do użycia.
Po co piszę post zamiast robić ten edytor w tym tak wspaniałym narzędziu? Doskonale zdaję sobie sprawę, że sam tego nie pociągnę. A nawet jeśli pociągnę, to zakładając że nie umrę ze zgryzoty lub nie wpadnę pod pociąg, projekt musi spotkać się z zainteresowaniem społeczności MaSzyny. Choćby dlatego, żeby ktoś inny mógł prowadzić rozwój edytora dalej, oraz żeby sami twórcy contentu byli zainteresowani modernizacją swojej narzędziowni. Żeby to wszystko zadziałało, musielibyśmy mieć określoną ogólną wizję przyszłości Symulatora, którą wg mnie przede wszystkim jest content. Dopiero później, kiedy Edytor już coś tam mógłby zmieniać, można byłoby zacząć pochylać się nad usprawnieniami exe/renderera, który mógłby zacząć pozwalać na np. heightmapy, automayczne sianie trawska, splatmapy i inne cuda na kiju, które Edytor Scenerii wspierałby na bieżąco wraz z rozwojem EXE.
Tak sobie wyobrażam rozwój Symulatora. Tyle ode mnie tej nocy. Pozdrawiam.
Marcin
9 Polubienia