“Czekając na Godota”

Byłoby miło móc napisać reportaż traktujący o sztuce “Czekając na Godota” pióra Samuela Becketta, niemniej przyjemnie pisze się także o udanych projektach Open Source, jakie nie są już alternatywą wartą rozwagi, lecz posiadają jakościowe przewagi nad analogicznym oprogramowaniem własnościowym. Wieloplatformowy silnik gier Godot w istocie jest programem, jaki w osobliwy sposób przedstawia sobą pożądane przez twórców funkcje, jednoczesną stabilność wraz z częstością wydań, wizję rozwoju i przewodnictwo jego oryginalnych autorów, zwieńczona iglicą szerokiego zainteresowania ze strony użytkowników, porównywalną z językiem programowania Rust czy nową technologią ze stajni którejś z korporacji. Toteż wzięcie nazwy dla narzędzia jakim jest silnik gier, ze sztuki teatralnej uchodzącej za klasykę, w tym przypadku nie jest pretensjonalnym działaniem na wyrost i nie przynosi ujmy którejkolwiek ze stron. Juan “reduz” Linietsky i Ariel “punto” Manzur, oryginalni deweloperzy Godota i aktualni opiekunowie kodu po jego uwolnieniu. motywowali “chrzciny” pragnieniem niekończącego dodawania kolejnych funkcji, co nie okazuje się wyczerpujące.

Zobacz też: Żegnamy Visual Basic. Język przestanie być rozwijany wraz z premierą .NET 5.0

Prace nad Godotem rozpoczęły się w 2007 roku i były odpowiedzią na wewnętrzne potrzeby przedsiębiorstwa, jednakże na pewnym etapie rozwoju uznano, że nie jest rozsądnym już, zważywszy na osiągniętą złożoność kodu, kontynuować prace w oparciu o dotychczasowy kapitał, zatem uwolniono kod źródłowy Godota na licencji MIT w lutym 2014 roku. Tym samym licząc, że w ciągu roku pojawią się programiści którzy zaznajomią się z całością źródeł i dokumentacji, po czym rozpoczną nadsyłanie patchy. Przewidywanie znalazło swój odzew w rzeczywistości, mimo że z początku projekt był wiadomy zaledwie linuksowym hobbystom i nie brakowało “oskarżeń o odkrywanie koła na nowo”, to na wzór toczącej się kuli śniegowej osiągnął on obecny rozmach. Było to możliwe dzięki przemyślanej architekturze.

Godot równoważy w sobie szereg funkcji jakie bywają odrębnymi narzędziami. Okno programu odpowiada zintegrowanemu środowisku programistycznemu, z kolorowaniem składni i autouzupełnianiem kodu dla GDScript (Z syntaktyką wzorowaną na Pythonie, dynamicznie typowany, autorski język skryptowy, przeznaczony do prototypowania i programowania niekrytycznych wydajnościowo partii kodu), C++ i C# (Mono). Ponadto zawiera w sobie debugger i profiler kodu, oprócz tego zestaw narzędzi eksportujących 32 i 64-bitowe binaria przeznaczone do wykonania kodu na platformach: Windowsa, Linuksa, macOSa, Androida, iOSa i od niedawna wspiera też wstępnie Haiku. Na wyposażeniu Godota znajduję się też renderery OpenGL ES 2.0 (utrzymywany w celach kompatybilności, przede wszystkim z całą gamą kart graficznych i SoC posiadających niezgodne ze specyfikacją sterowniki OpenGL) i OpenGL ES 3.0 (zostanie zastąpiony Vulkanem w wersji Godota 4.0). Przy czym silnik graficzny 2D jest perfekcyjny co do piksela (bez powodowania rozmyć i sytuacji, gdy część pikseli staje się prostokątna zamiast zachować kształt kwadratu), a shadery można także “wyklikać” w wizualnym edytorze, za pomocą węzłów (nodes) i połączeń, a nie tylko je napisać. Jakość cieniowania jest na poziomie renderingu bazującego na fizyce (PBR - Physically Based Rendering). Wartymi wzmianki funkcjami pozostają także szukanie ścieżek bazujące na navmeshach, silnik fizyki Bullet, moduł Blender Collada (służy do wygodnego eksportowania i importowania, pomiędzy różnymi aplikacjami, plików .dae, co zawierają trójwymiarowe zasoby cyfrowe) i autorski podsystem animacji zdolny do wprawiania w ruch kości i obiektów, rozszerzony o możliwość wywołania funkcji, ze wsparciem dla szkieletów i odwrotnej kinematyki w 2D, czyni też użytek z automatu stanów. Spakowany zipem Godot 64-bit w wersji dla Windowsa waży zaledwie 27 MiB, natomiast archiwum zawierające “Export Templates” już 437 MiB (Obejmuje ono zestaw binariów służących do budowania plików wykonywalnych gier i pakietów z zasobami cyfrowymi dla poszczególnych platform).

Niezależnie od posiadanych funkcji, Godot jest również rozszerzalny wtyczkami pochodzącymi ze społeczności lub firm trzecich. Jego niemoc jest ściśle związana z efektami sieciowymi i skali, w kontekście repozytorium, płatnych i darmowych, zasobów cyfrowych, skryptów i plików audio. Godot Asset Library składa się z pluginów i zestawów narzędzi rozbudowujących silnik o “ułatwienia” we wdrażaniu specyficznych funkcji gier. Mimo wszystko istnieją strony internetowe oferujące modele i tekstury na liberalnych licencjach, choćby OpenGameArt. Reszta przyjdzie z czasem, szczególnie że Godot obsługuje następujące formaty scen 3D: glTF 2.0, DAE, OBJ, ESCN, FBX. Toteż bywa kompatybilny z zestawami grafik dla innych silników gier.

Zobacz też: Nowości w IntelliJ: w planach m.in. tryb edytora tekstu ogólnego przeznaczenia

Godny wspomnienia jest framework Escoria, pierwotnie zaimplementowany jako zbiór skryptów, szablonów scen i języka skryptowego dialogów, dla gry przygodowej The Interactive Adventures of Dog Mendonça & Pizzaboy®, jaki następnie został wyabstrahowany w celu szerszego użycia. Escoria dystrybuowana jest na licencji MIT, z przeznaczeniem do wygodniejszego tworzenia gier przygodowych kierowanych wskaźnikiem myszy (point-and-click adventure), na silniku Godot.

Wydanie poprawione 3.2.1

Przed kilkoma dniami ukazała się wersja poprawkowa otwartoźródłowego silnika gier Godot o numerze 3.2.1 i składa się na nią ok. 200 zmian w kodzie względem głównego wydania 3.2 jakie miało miejsce pod koniec stycznia bieżącego roku. Są to wyłącznie łatki poprawiające regresje i drobne błędy stanowiące typowy miszmasz pomniejszego wydania; problemy związane z nagłym zakończeniem aplikacji, kiedy za pomocą wbudowanego debuggera sprawdzano zwolnione w pamięci obiekty czy ustawieniem odwróconej kamery w widoku 2D, albo niedogodność wynikająca z rozłączenia podpiętego gamepada w systemie macOS Catalina. Ponadto współpracownicy zaktualizowano dokumentację i nie są wiadome jakiejkolwiek niekompatybilności pomiędzy wzmiankowanymi wydaniami. Zespół programistów skupionych wokół projektu Godot pragnie jak najczęściej wypuszczać wydania poprawione.

Gałąź kodu 3.2

Godot 3.2 (wydanie miało miejsce w styczniu bieżącego roku) będzie posiadał długie wsparcie techniczne ze strony deweloperów projektu, analogicznie jak miało to miejsce w przypadku linii 2.1 (lata 2016-2019). Renderer OpenGL ES 2.0 zostanie przeportowany do wersji 4.0, aby zachować kompatybilność ze starszym sprzętem, lecz renderer OpenGL ES 3.0 zostanie porzucony w miejsce Vulkana bowiem wsparcie w sterownikach, ze strony producentów dla tego API, jest eufemistycznie pisząc problematyczne.

Kolejne wydania poprawkowe mogą zawierać, wbrew praktyce, nowe funkcje, jeśli pozostaną one bez wpływu dla stabilności i kompatybilności linii wydań 3.2.x. Na przestrzeni ostatnich sześciu miesięcy zaimplementowano użyteczne programistom podprogramy i dyspozycje, takie jak wsparcie C# dla platformy iOS lub metodę kompilacji Ahead-of-time (AOT).

Zobacz również: Deno - młodszy brat Node.js

Wybrane funkcje wdrożone w Godocie 3.2:

1. Zaktualizowano dokumentację, w tym poszerzono tutoriale i wzorce klas o nowej informacje. Dotąd część dokumentów była pozbawiona możliwie wyczerpujących objaśnień. Dokumentacja API klas w wersji 3.1 była ukończona na poziomie 73%, w wersji 3.2 wynosi już 90%. Lokalne wersje językowe dokumentacji uległy poszerzeniu dzięki pracy wolontariuszy ze społeczności.
2. Teraźniejszy Godot implementuje C# 8.0 za pomocą Mono 6.6. Wsparcie C# w Godocie przebiegało stopniowo. W wersji 3.0 pojawiła się wstępna obsługa. 3.1 umożliwiło eksport projektów na platformy desktopowe, a 3.2 wprowadziło możliwość implementacji projektu w C# dla Androida i WebAssembly. Metoda kompilacji Ahead-of-time (AOT) dla WebAssembly została połączona z główną linią kodu źródłowego, jednakże wymaga dalszych testów i obecnie kod jest interpretowany, ze stratą dla wydajności. Poza tym Godot obsługuje Visual Studio i Jetbrains Rider jako zewnętrzne edytory programistyczne i przepisano z C++ na C# moduł edytoria związanego z Mono. Powyższe prace były możliwe dzięki grantowi przyznanemu przez Microsoft.
3. Połączono z kodem źródłowym kolejne funkcje wymagane przez gry AR i VR, mimo tego dalsze prace są wciąż wymagane, aby móc nazwać to pełnoprawnym wykorzystaniem. W pierwszym rzędzie należy wymienić implementację ARKIT w wersji 1.0 i niektórych funkcji z 2.0. ARKiT to API Apple pomyślane o rzeczywistości rozszerzonej. Sprzęt VR typu Oculus Go lub Oculus Quest jest wspierany przez pluginy dostępne na Asset Library.
4. Język skryptowy shaderów został wzbogacony o kolejne konstrukcje programistyczne, tj. stałe, tablice i zmienne. Część cech właściwych dla backendu GLES3 została przeportowana do GLES2, lecz nie jest możliwe przeportowanie całości funkcji ze względu na ograniczenia w starszej specyfikacji GLSL. Wizualny edytor shaderów uległ znaczącemu usprawnieniu, za sprawą dodania kolejnych węzłów (nodes), co pozwoli “wyklikać” bardziej zaawansowane shadery bez pisania kodu. Jednym z nich jest węzeł Expression, który umożliwia wprowadzenie “ekspresji”, jako tekstowego parametru, wewnątrz wizualnego shadera, po czym dzięki portom wejścia-wyjścia przekazać polecenie do materiału, w sposób natychmiastowy, a wszelkie błędy kompilacji lub informacje związane z parsowaniem zostaną zwrócone w karcie “Output”. Węzeł Expression nie posiada ograniczeń i można w nim wykorzystać całość dostępnych technik przynależnych ręcznemu programowaniu shaderów, choćby słowa kluczowe, typy rozszerzone i pętle.
   
5. Pomimo intensywnych prac nad wsparciem dla API Vulkana, to nie zapomniano o “starych” rendererach. Udoskonalono potok PBR, aby zbliżył się on w zachowaniu do pozostałych rendererów PBR jak Blender's Eevee czy Substance Designer. W efekcie sceny mocno wykorzystujące PBR powinny, w zauważalny sposób, upodobnić się do widoku znanego z innych edytorów 3D.

   Ponadto backend GLES2 wspiera od tej pory metodę antyaliasingu MSAA i rozmaite efekty postprodukcji, takie jak glow, DOF czy blur. Zwyczajowo pracowano także nad zwiększeniem jakości generowanego obrazu i jego wydajności.

6. Dodano wsparcie dla glTF 2.0 - zdefiniowany przez Khronos Group format pliku przechowujący informacje o zasobach 3D. Wsparcie dla plików FBX jest aktualnie ograniczone do podglądu i to plików wyeksportowanych w Blenderze. FBX znane z programów Maya lub 3ds Max nie jest obecnie wspierane przez Godota.

Pozostałe zmiany to wsparcie dla perspektywy 2,5D, wprowadzenie atlasów tekstur, AStar2D (odnajdywanie najkrótszej ścieżki według algorytmu A*), refaktoryzacja kodu, a dalej dodanie kotwic i marginesów do GUI. Wdrożono także dodatkowe efekty dla kontrolki RichTextLabel, w tym czasu rzeczywistego, w tym możność zdefiniowania przez użytkownika własnych komend BBCode. Natomiast za pośrednictwem biblioteki V-HACD rozkład siatki 3D meshy na uproszczone, poszczególne, elementy. Narzędzia związane z programowanie rozszerzono m.in. o podgląd minimapy czy ustanawianie zakładek wewnątrz skryptów.