Godot 4.0 żegna się z VisualScript
Kilka dni temu udostępniliśmy tutaj na blogu wiadomość o wydaniu wersji 3.5 Godota, wersji, w której wprowadzono różne ulepszenia i nowe funkcje.
A teraz pojawiła się wiadomość o wydaniu w wersji beta Godota 4.0 nastąpiła znacząca zmiana, ta zmiana jest taka skrypt wizualny, wizualny język skryptowy Godota, który został wprowadzony od wersji 3.0 prawie pięć lat temu, nie będzie częścią wersji beta, a tym bardziej ostatecznej wersji Godota 4.0.
Od Godota 4.0, nie trzeba już polegać na VisualScript jako wbudowanej funkcji bezpośrednio w głównej wersji silnika.
Aby lepiej zrozumieć powody tej decyzji, musimy cofnąć się do historii VisualScript. W rzeczywistości, według zespołu Godota, skrypty wizualne były jedną z najbardziej pożądanych funkcji w czasach Godota 2.1. Aby lepiej sprostać temu zapotrzebowaniu, opiekunowie projektu przeprowadzili ankietę, aby określić, jakiego rodzaju skryptów wizualnych życzyliby sobie użytkownicy.
W wyniku ankiety najczęściej wymieniano styl Blueprint. Dzięki tym informacjom stworzono i wydano VisualScript dla Godota 3.0. Został zaimplementowany jako GDscript, ale w graficznym, opartym na węzłach stylu.
Jednak chociaż ta funkcja była bardzo pożądana w tamtym czasie nie oznaczało to, że było to konieczne w przypadku prawdziwych projektów silnika i że wielu użytkowników faktycznie go przyjęło. I tej rzeczywistości zespół Godota nauczył się na własnej skórze. Po prawie pięciu latach od dodania Godota 3, VisualScript nie odniósł oczekiwanego sukcesu. Próbując zrozumieć przyczyny tego niepowodzenia, zespół Godota wymyślił dwie główne odpowiedzi:
Dla wielu potencjalnych użytkowników, którzy chcieli tej funkcji, uznali GDScript za idealne dopasowanie i ostatecznie woleli go od VisualScript. Nie spodziewali się, że GDScript będzie tak łatwy w nauce i obsłudze (chociaż nie mieli wcześniejszej wiedzy programistycznej), ponieważ żaden z popularnych wówczas silników nie oferował tego rodzaju skryptów wysokiego poziomu. Dla wielu z tych użytkowników Godot stał się narzędziem do nauki programowania.
Mimo że istniała podstawowa funkcjonalność, skrypty wizualne, Godotowi brakowało komponentów wysokiego poziomu, aby z niej korzystać. Silniki takie jak Unreal, Game Maker czy Construct oferują funkcje gier na wysokim poziomie w połączeniu z wizualnym rozwiązaniem skryptowym. Właśnie dlatego jest użyteczny. Godot to niezwykle wszechstronny silnik gier, w którym łatwo jest samodzielnie stworzyć te funkcje, ale nie są one wyjęte z pudełka. W związku z tym sam VisualScript był mało przydatny, przyznaje zespół Gotdot.
Na te dwie odpowiedzi, Zespół Godota dodał jedną trzecią osobistych obserwacji. Według opiekunów silnika gry, dokumentacja nie została zrealizowana. W rzeczywistości oficjalna dokumentacja Godota zawiera przykłady w GDScript i C#, ale twórcom projektu nigdy nie udało się zamieścić przykładów VisualScript ze względów technicznych.
Podany powód jest taki, że musiałbym zrobić zrzuty ekranu grafiki VisualScript dla każdego przykładu i utrzymanie ich byłoby bardzo trudne. Ponadto, gdy rozważano niektóre projekty demonstracyjne, użytkownikom nie wystarczyło opanowanie nawet języka wizualnego, a aby nauczyć się API Godota, musieli znać GDScript lub C#, aby zrozumieć przykłady, mówi zespół.
Wszystkie te trudności sprawiły, że VisualScript nigdy się nie przyjął, a jak go ulepszyć, nigdy nie było jasne. Według niedawnej ankiety przeprowadzonej przez zespół programistów projektu, najnowsza (ponad 5000 respondentów) tylko 0,5% bazy użytkowników używała języka VisualScript jako podstawowego języka silnika.
Nieuniknionym wnioskiem było to, że podejście do skryptów wizualnych po prostu nie było właściwe. Wygląda na to, że ta funkcja była oczekiwana przez ludzi, którzy tak naprawdę jej nie potrzebowali. Kilku użytkowników Godota jest zadowolonych z tej decyzji, ponieważ dla nich VisualScript nigdy nie był zbyt dobry i nawet dla zupełnego początkującego nie jest tak łatwy w obsłudze jak GDScript.
Nie mylić z wizualnymi shaderami. Shadery wizualne działają dobrze i są doceniane przez wielu użytkowników, nadal są rozwijane w silniku. Dla użytkowników, którzy chcą nadal używać VisualScript w silniku gry, są dwie opcje. O pozostań w 3.x lub skompiluj kod do użycia w 4.x wyższy, zwłaszcza, że zostanie przeniesiony do dedykowanego repozytorium. Ostatnią opcją byłoby znalezienie wolontariuszy zainteresowanych tym projektem, aby uczynić go oficjalnym rozszerzeniem, co ułatwiłoby jego utrzymanie.
Na koniec, jeśli chcesz dowiedzieć się więcej na ten temat, możesz zapoznać się ze szczegółami W poniższym linku.