Category: Game Design

Napęd!

Game jamy obserwuję nie tylko dla interesujących pomysłów. Zdarza się, że ich organizatorzy dzielą się statystykami dotyczącymi wykorzystania poszczególnych silników. Dla mnie jest to ciekawa forma sprawdzenia z czego obecnie korzystają ludzie. Warto pamiętać, że game jamy rządzą się własnymi prawami. W dużej mierze polegają na protypowaniu mechanik, testowaniu tego, jak będą je odbierali użytkownicy. Profesjonalny gamedev, ten poza gamejamowy, zdecydowanie częściej wyróżnia się uporządkowanym procesem produkcyjnym.

Tym razem trafiłem na statystyki dotyczące silników wykorzystywanych w trakcie Game Maker’s Toolkit Game Jam. Jego cechą charakterystyczną jest to, że trwa jedynie 24 godziny! Dlatego nie ma tutaj mowy o klepaniu setek tysięcy linijek kodu lub długotrwałym zastanawianiu się nad tą, lub inną mechaniką. Na dodatek, w trakcie zabawy, nie powinno się korzystać z wcześniej stworzonych rzeczy. Wyjątkiem są assety. Te zasady sprawiają, żę GMTK Game Jam stanowi świetne środowisko, które silniki wybierane są do szybkiego prototypowania. Gdybym to ja miał się podjąć tego wyzwania, sądzę, że na pewno nie bawiłbym się w naukę nowej technologii i wybrał coś, co już mniej więcej znam. I najlepiej, aby było pełno różnych tutoriali, a sama dokumentacja była przystępna. Wszystko wskazuje na to, że mój wybór padłby na Unity3D.

Co pokrywa się z wynikami sondażu przeprowadzonego wśród 5 400 twórców, którzy wzięli udział w GMTK Game Jam. Unity3D zdecydowanie zdominowało stawkę. Na drugim miejscu był GODOT, a na trzecim Game Maker. Na wykresie jest jeszcze widoczna spora grupa nazwana “Others”. Skupia ona wiele różnych silników, w tym Unreal Engine 4, a także różne frameworki lub biblioteki, w których można tworzyć gry. Nie będę ukrywał, że sporym zaskoczeniem jest dla mnie GODOT. Na łamach DailyWeb kilkukrotnie wspominałem o tym silniku, szczególnie podkreślałem to, że jest rozwiązaniem z otwartym źródłem oraz jest niezwykle lekki i nie jest zbyt łakomy na zasoby komputera. A jakie ma wady? Przede wszystkim korzysta z własnego języka skryptowego. GDScript przypomina Pythona, ale nim nie jest. GODOT obsługuje także C#. Być może od wersji 3.0 programowanie w tym języku stało się przyjemniejsze? Ja napisałem kilka niewielkich gier zarówno w GDScript jak i w C#. Zdecydowanie lepiej pisało mi się w pierwszym języku, drugi niezbyt ze mną współpracował.

Mimo to skupiam się ostatnio na Unity3D. Dlatego nie dziwi mnie tak duża przewaga tego silnika nad innymi. Tutoriale i społeczność jednak robią swoje. W przypadku GMTK Game Jam istotne znaczenie ma czas. 48 godzin to niewiele na stworzenie ciekawego prototypu, więc trzeba korzystać z tego, co szybko uda się znaleźć i opracować. Unity3D doskonale nadaje się do takiego szybkiego tworzenia gier. Oczywiście, wcześniej należy poświęcić czas na naukę edytora oraz opanowanie przynajmniej podstawowych elementów związanych z pisaniem skryptów w tym silniku.

Próby ze światłem

W wolnym czasie dalej eksperymentuję z tworzeniem gier. Najczęściej szukam jakiegoś gamejamu z ciekawym tematem i próbuję coś zbudować. Czasem się udaje, a innym razem nie. Jeśli nie interesują Cię kwestie związane z tworzeniem małych cyfrowych światów, to ten tekst może Cię znużyć. Ostrzeżenie zostało wydane, teraz, bez żadnych skrupułów, mogę przejść do charakterystyki mojego niewielkiego projektu. Główne założenia? Zbudowanie gry, w której odbiorca lawiruje między przeszkodami i musi dotrzeć do oznaczonego punktu.

Nie jest to duża rzecz, rzekłbym nawet, że wręcz podstawowa. Opracowałem prosty mechanizm tworzenia planszy, wybrałem elementy, z których ma się składać. Dodałem gracza, w międzyczasie zdecydowałem, że tym razem mój niewielki tytuł będzie w trzech wymiarach. Wszystko szło całkiem sprawnie, chociaż przy budowaniu planszy złapałem kilka potknięć. Wymyślałem koło na nowo, zamiast wybrać jakiś algorytm i na jego podstawie wygenerować labirynt. Nie twierdzę, że był to czas zmarnowany, ale sądzę, że mogłem sobie trochę przyspieszyć prace. Po przetestowaniu ukończonego prototypu zauważyłem, że czegoś mi brakuje. Chciałem dodać jakiś drobny element, który uatrakcyjni zabawę. Próbowałem różnych rzeczy. Teleportów, dodatkowych przeszkód, a nawet przeciwników goniących gracza. Okazało się, że najciekawszym rozwiązaniem jest modyfikacja światła znajdującego się na scenie.

Najpierw zaprezentuję efekt z pełnym oświetleniem. Tak wyglądała pierwsza wersja.

Niewielka plansza, trochę przeszkód. Żadnego wyzwania. Drogę do zielonego punkt można znaleźć z łatwością, nie trzeba się nawet specjalnie wysilać. Po dotarciu do celu losowany jest kolejny, ale poziom trudności pozostaje na tym samym poziomie. Tutaj zacząłem kombinować z różnymi elementami.

Tak prezentuje się scena ze znacznie mniejszą ilością światła.

Plansza zyskuje inny charakter, głównie ze względu na to, że gracz nie widzi całości. Opiera się tylko na tym, co dostrzega wokół prowadzonego pionka. Ciekawe jest także to, że, ze względu na brak charakterystycznych punktów, przemieszczanie się po planszy jest dość specyficzne. Można się jej nauczyć, ale za pierwszym razem sporym problemem jest orientacja w przestrzeni. Wszystkie przeszkody są do siebie podobne, na dodatek nie wiadomo, czy wybrane przejście będzie ślepą uliczką. Tę wiedzę dopiero się nabywa, trzeba tam po prostu wleźć. Tutaj doszedłem do wniosku, że warto dodać wagę do pionka, a także siłę, która będzie na niego działała i umożliwiała poruszanie. Jeszcze przydałaby się jakaś kara… Stwierdziłem, że każde zderzenie ze ścianą będzie prowadziło do utraty punktu życia. Co w połączeniu z dodawaną siłą oraz odbiciami, sprawiło, że rozgrywka stała się trochę ciekawsza.

Pojawiło się kilka elementów, które gracz musi rozważyć w trakcie zabawy. Przede wszystkim zarządza punktami życia, które otrzymuje za dotarcie do zielonego kafelka. Pojawia się pytanie, ile zdrowia straci, zanim tam dotrze? Na dodatek sterowanie postacią wcale nie jest łatwe, ze względu na ciągłe dodawanie siły, która coraz bardziej rozpędza pionek. Jak go wyhamować? Najlepiej zderzyć się z przeszkodą, ale to powoduje utratę punktów życia i zbliża do przegranej. Co ciekawe jestem zadowolony z tego prostego projektu. Zrozumiałem, że zabawa percepcją odbiorcy może mieć duży wypływ na pozostałe mechaniki. Przy pełnym oświetleniu, zaplanowanie ścieżki jest banalne, natomiast przy niedoborze światła już trzeba trochę kombinować. Ryzykować i zastanawiać się, jaką drogę wybrać.

Powered by WordPress & Theme by Anders Norén