Nintendo znane jest z tego, że o ich produkcjach można powiedzieć wiele, ale na pewno nie to, że są niedorobione, wypychane na rynek pospiesznie i bez zawartości. No to mamy tu pierwszy od bardzo dawna przypadek gry, czy raczej eksperymentu, który moim zdaniem zawodzi na całej linii. A mowa o Game Builder Garage, czy garaż, w zależności od tego z której części świata jesteście, zapowiedzianej niespodziewanie niedługo przed swoją premierą aplikacji do pisania własnych gier na Switcha. Brzmi fajnie, prawda? No właśnie. Na pierwszy rzut oka wszystko jest fajnie. Do portu USB doku Switcha wpiąć można myszkę dla wygodnego sterowania kursorem, ale oczywiście bawić się można też kontrolerem. Zabawka składa się z dwóch części, samouczka, wyjaśniającego zasady obsługi programu oraz trybu programowania, gdzie piszemy swoje produkcje. Ten pierwszy zbudowany jest z szeregu przykładowych gier różnych gatunków i instrukcji krok po kroku tego jakich narzędzi użyć, żeby je skonstruować. Towarzyszą nam w tym celu kursorowe wróżki, które w typowy dla Nintendo sposób żartobliwie opisują kolejne etapy produkcji gry. Często wręcz zbyt kwieciście powtarzając i wbijając do głowy dane rzeczy po kilka razy, żeby na pewno nic nam nie umknęło. No ale już na tym etapie zauważyłem, że coś tu nie gra, bo jedna z pierwszych rzeczy jaka rzuciła mi się w oczy to… rażący błąd w tekście. Ktoś zjadł słówko i korekta tekstu tego nie wyłapała. Dziwne, jak na grę Nintendo. No ale lecimy dalej. Pierwszy, obowiązkowy tutorial pokazuje graczowi jak skonstruować prostą dwuosobową grę w ganianego. Tworzymy małą arenę, stawiamy ludziki i dodajemy przeszkody. Proces ten trwa około 30 minut, bo większość czasu pochłaniają oczywiście tutoriale. Potem odblokowany zostaje nareszcie tryb dowolny i teraz zdecydować możemy czy chcemy programować sami czy wrócić do samouczków i dowiedzieć się więcej na temat pisania gier w Game Builder Garage. Pisanie gier różni się trochę od tego czego oczekiwać możecie po silniku do gier. Nie wstukujemy linijek kodu to zresztą byłoby niewygodne na systemie bez klawiatury, więc zamiast tego wykorzystywane są tak zwane węzły, tu określane mianem nodonów. Cała mechanika gry opiera się na łączeniu ze sobą takich węzłów w łańcuchy akcji. Na przykład spinając nodon wciskania przycisku B z haczykiem skoku nodonu ludzika powimy grze, że ludzik ma skakać przy wciśnięciu przycisku B. Proste. Nie jest to wymysł dziwny, z podobnych systemów łatwego programowania korzystają silniki takie jak Unreal Engine. Jest to też program skierowany wyraźnie do młodszych użytkowników, więc takie podejście do kodowania jest jak najbardziej trafne, bo spełnia swoje główne zadanie, buduje w młodych użytkownikach zrozumienie mechanizmów działających za kulisami ich ulubionych gier. Nie to jest więc problemem Game Builder Garage. Jego największą wadą jest paradoksalnie jego surowość i przesadna wręcz prostota.

To system o wielkim potencjale rujnowany moim zdaniem przez absolutny niedobór nawet najbardziej podstawowych narzędzi. W Game Builder Garage tworzyć można na dobrą sprawę tylko dwa typy gier, bardzo proste platformówki i bardzo proste gry 3D. Na siłę, obchodząc kreatywnie sztuczne ograniczenia można zrobić więcej… ale no właśnie. Wszystko opiera się o obchodzenie idiotycznych granic wyznaczonych przez autorów programu. Bo koncept “możesz nauczyć się pisać gry, ale tylko takie jakie chcemy” jest bardzo idiotyczny. Programowi brakuje najbardziej podstawowych nodonów, które w znaczący sposób ułatwiłyby pisanie gier. W Game Builder Garage wszystko jest niepotrzebnie trudne, bo nawet istniejące funkcje programu są sztucznie ograniczone. Zauważyliście może, że żadna z pokazywanych do tej pory gier nie ma na ekranie interfejsu? No bo w GBG nie da się tworzyć tak zwanych HUD-ów, czyli tych dynksów, które wyświetlają statsy i paski na ekranie. Ba, na dobrą sprawę nie da się nawet wyświetlać normalnie napisów, liczyć żyć czy punktacji i trzeba do tego celu wykorzystywać klocki z umieszczonymi na nich napisami. W edytorze kodu brakuje obsługi prostych warunków, możemy sprawdzić czy jakaś wartość równa się innej wartości, ale brakuje funkcji “else” która odpalałaby się w przypadku, gdy wartości nie są równe. Coś absolutnie oczywistego, a co powoduje niepotrzebną komplikację kodu, zerknięcie do źródła nawet prostej gry zdradza absolutny koszmar pomieszanych nodonów. Czy naprawdę tak chcemy uczyć dzieciaki programowania? A to tylko wierzchołek góry lodowej, nie możemy na przykład tworzyć własnych obiektów. Wszystkie przedmioty w grze pochodzą ze z góry predefiniowanej listy. Więc postać grywalna musi być robocikiem, UFO albo autkiem reprezentując tak trzy rodzaje ruchu. Dobrze chociaż tyle, że model podmienić można na swoją własną, dwuwymiarową teksturę. Można też stworzyć prosty model piłki, sześcianu i tak dalej, ale te nie mogą być kontrolowane w taki sam sposób, istnieje co prawda wariant ruchomych obiektów, ale te posiadają dużo mniej konfigurowalnych cech niż wspomniane wcześniej ludziki. Wszystko zrobione jest pokrętnie i programując w GBG ma się wrażenie, że trzeba wręcz hakować system żeby osiągnąć zamierzony efekt. Zrobienie prostej wersji Gruniożercy na streamie, najprostszej z prostych gier zajęło mi trzy godziny, bo co rusz trafialiśmy na idiotyczne ograniczenia programu. Istnieje na przykład detektor, który sprawdza czy dany obiekt został zniszczony. Ale nie potrafi sprawdzić on co zniszczyło obiekt. Więc nie znalazłem prostej metody żeby wykryć czy marchewkę zjadł Grunio czy rozbiła się ona o ziemię.

Raz stworzone obiekty tak jak wspomniane wcześniej marchewki nie są kontrolowane w kodzie, więc w ogóle stworzenie przedmiotu, który by je wystrzeliwał znad ekranu wymagało kombinowania z niewidocznymi portalami. W grze istnieją co prawda emitery czyli klocki, które mogą wystrzeliwać inne obiekty… ale z jakiegoś powodu te mogą strzelać jedynie trzema podstawowymi modelami 3D bez możliwości podpięcia do nich stworzonego przez siebie obiektu… czy obiektów zaawansowanych, więc ich użycie nie wchodziło w grę. Nie można też zmieniać pozycji obiektów. GBG pozwala jedynie na zmianę prędkości postaci grywalnej w danej osi… ale nie jej koordynatów X i Y. Więc jeśli chcielibyśmy na przykład stworzyć system żyć i teleportować gracza do ostatniego czekpointa po śmierci… no to tak się domyślnie nie da, chyba, że wymyślimy jakiś sposób na obejście braku obsługi tak podstawowych elementów. Wiem, że ostro jeżdżę w tym momencie po programie, który stworzony jest z myślą o dzieciakach. I jest w nim dużo fajnych funkcji, które mi się podobały i dający spore pole do manewru, ale jednocześnie uważam, że dawanie im narzędzi tak niedopracowanych tylko szkodzi ich kreatywności. Co mi po tym, że mogę ruszać ludzikiem na ekranie, jeśli interakcje z otoczeniem są praktycznie poza moją kontrolą, a cechy na jakie mam wpływ są w zasadzie nieistniejące. Wielu nodonom brakuje oczywistych funkcji jak wspomniane wcześniej “if/else”. Nie ma pętli, nie ma zmiennych choć te zasymulować można prostymi licznikami. Nie można grupować nodonów w funkcje, by łatwiej wykorzystywać ich grupy. Wiele nodonów wyjściowych nie raportuje swojego stanu innym nodonom co pozwoliłoby na większą kontrolę stanu gry. Nie ma prostego sposobu na sprawdzenie czy dany obiekt jest na ekranie, na liczenie obiektów, na dowolne tworzenie obiektów, niszczenie obiektów, kontrolę efektów dźwiękowych… mógłbym tak długo. Nic nie obnaża braków oprogramowania tak bardzo jak samouczek robienia shoot ‘em upa. Shoot ‘em up, który pokazuje wynik tylko na końcu planszy, bo nie ma interfejsów, shoot ‘em up, w którym statek trzeba scrollować ręcznie, bo inaczej wypada poza ekran, w którym żaden z przeciwników się nie rusza, bo nie da się kontrolować ich pozycji, no i w którym boss schodzi na jednego strzała, bo nie da się odróżnić go od innych przeciwników i dać mu punktów zdrowia. No ale dobrze, bo skupiłem się ostro na roastowaniu silnika, bo jest tu co roastować. Ale to nie jedyny zarzut jaki mam do tego systemu. Pamiętacie przykład dobrego edytora od Nintendo Super Mario Maker 2? Miał świetną kampanię, bogaty, ładny edytor, dziesiątki jeśli nie setki postaci ze świata Mario i skórek dla samego Mariana i fantastyczną przeglądarkę plansz użytkowników, gdzie można sobie przeglądać stworzone przez innych kreacje, oceniać je, zapisywać do ulubionych. W Game Builder Garage mamy tylko ten ekran.

Stworzone gry można wysyłać na serwer Nintendo, ale nie da się ich w żaden sposób zobaczyć. Dzielimy się nimi dając znajomym unikatowy kod. Co więcej, jeśli przez rok nikt naszej gry nie pobierze, zostanie ona z serwera usunięta. Jedynym sposobem więc, żeby zobaczyć co fajnego potworzyli internauci jest wskoczyć na Reddita i… cóż. Tu też nie ma cudów. Jest kilka słodkich prób naciągnięcia silnika do granic możliwości, np. Prosta, gliczująca się gra w której podgrzewamy kostkę na patelni. Ale prócz tego są to koślawe puste światy z poustawianymi na nich predefiniowanymi modelami… no bo nic innego nie da się w tej grze zrobić bez niepotrzebnie dużego wkładu pracy dla bardzo prymitywnego efektu. A i ten problem dało się przecież bardzo prosto rozwiązać, chociażby wrzucając do gry kilkadziesiąt modeli z popularnych gier Nintendo. Czemu grywalny nie może być Mario? Link? Albo Samus? Jasne, nadal te gry byłyby cienkie jak rosół z Grunia, ale chociaż dałoby się ukręcić coś ciekawszego niż Generyczny Robot 1 biegający po płaskiej trawie. A tak aplikacji brakuje nie tylko funkcji, ale i podstawowej zawartości. No bo co tu jest? Prymitywny i pozbawiony treści edytor i zestaw samouczków w których sami musimy zbudować sobie najprostsze gry. Gdzie chociażby zestaw 50 minigier stworzonych przez Nintendo żeby móc sobie zajrzeć do tego co wymyśliły mózgi profesjonalistów? Albo przynajmniej prosta kampania z robocikiem, maskotką gry, żeby pokazać najprostsze cechy silnika w zestawie dwu- i trój- wymiarowych plansz. Dawno nie widziałem produktu Nintendo, który byłby wypchnięty przez firmę tak… bez serca. W Game Builder Garage nie ma nic co mogłoby przyciągnąć gracza do zabawy. Porównując to do bardzo podobnego w koncepcie, i kosztującego tyle samo Dreams od Media Molecule na PlayStation 4 GBG jest wręcz pośmiewiskiem. Dreams, wykorzystując bardzo podobny system skryptowy oferowało fantastyczną, pełną stylu kampanię w stylu filmu “Co w duszy gra” Disneya, nieporównywalnie więcej możliwości i olbrzymi hub na projekty użytkowników. Wyjątkowo nie polecam nikomu prócz może graczom w okolicach 10 roku życia, którzy bardzo chcieliby zobaczyć jak to jest zostać programistą, pod warunkiem, że poradzą sobie z barierą językową, bo w przeciwieństwie do Dreams, Game Builder Garage dostępny jest wyłącznie w językach obcych. Narzędzie jest na tyle proste, że nawet maluch powinien być w stanie poruszyć ludzika i jest szansa, że nie natknie się za szybko na ograniczenia gry. Ale mam wrażenie, że nawet jemu robić się będzie w ten sposób niedźwiedzią przysługę. Istnieje sporo alternatyw, w tym darmowych, jak popularny i równie prosty Scratch, które spełnią się lepiej jako narzędzie edukacyjne. A i łatwiej potem w taką gotową grę zagrać innym graczom.