Tag: GODOT game engine

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.

Zbędne komplikacje

W czternastym odcinku WWWłaśnie podcastu wspomniałem o tym, co sprawia mi najwięcej trudności w trakcie projektowania rozrywki. W zeszłym roku wziąłem udział w kilku game jamach, dla sprawdzenia swoich umiejętności designera. Nie tyle programowałem gry, co próbowałem tworzyć interesujące prototypy. W wyniku podcastowej rozmowy z Łukaszem postanowiłem podzielić się kilkoma wrażeniami z moich game jamowych przygód. Od razu zaznaczę, że zawsze brakuje mi odwagi, aby zgłosić gotowy projekt.

Moją największą bolączką jest grafika. Brakuje mi elementarnego poczucia estetyki, dlatego moje zrealizowane projekty najczęściej przypominają gry, w których kwadrat goni koło i okazjonalnie strzela trójkątami. Zawsze najbardziej zależy mi na przetestowaniu prototypu, więc niespecjalnie interesuję się wyglądem. Jednak zdaję sobie sprawę, że dla ewentualnych odbiorców i jurorów moje kwadraty z napisami wykonane w Paincie mogą być przeszkodą nie do przeskoczenia. W duchu obiecałem sobie, że w tym roku zmienię swoje nastawienie. I miałem już pierwszą okazję. Nie wyszło. Dlaczego? Bo przekombinowałem grę. Dosłownie.

Godot Wild Jam” to comiesięczny game jam dla osób tworzących gry w Godocie. Jest to otwartoźródłowy silnik, często wskazywany jako istotna konkurencja dla takich molochów jak Unreal Engine 4 oraz Unity3D. W styczniu temat game jamu brzmiał – druga szansa. Rozpisałem sobie projekt na grę w gatunku time managment, czyli polegającą na zarządzaniu czasem i ograniczonymi zasobami. Odbiorca wcielałby się we właściciela kancelarii prawnej, której zadaniem byłoby oczyszczanie więźniów z różnych zarzutów. Aby podkręcić temperaturę, postanowiłem, że gra będzie rozgrywała się w świecie fantasty, w którym nawet za najmniejsze przewinienie grozi kara śmierci. Gracz miał mieć ograniczony czas na wyciągnięcie skazańca i tylko czterech pracowników, których mógł przydzielić do konkretnej sprawy. Ich zadaniem byłoby usuwanie dowodów, po wykluczeniu wszystkich, przestępca wychodził na wolność i dostawał drugą szansę. To, co opisałem, stanowiło fundament rozgrywki i przy dobrym układzie mogło być nawet zabawne. Dołożyłem dwa zasoby – złoto oraz reputację. Oba zdobywało się za oczyszczonych z zarzutów skazanych, ale jeżeli reputacja spadła poniżej zera, to kancelaria upadała. Każdy ścięty przestępca oznaczał przydzielenie ujemnych punktów.

Zrobiłem prototyp. Ustawiłem różnego rodzaju timery i stwierdziłem, że czegoś brakuje. W zasadzie cała moja gra opiera się na przeciąganiu zasobów w odpowiednie miejsca, a złoto leżało odłogiem. Stwierdziłem, że wykorzystam je w sklepie z bonusami pozwalającymi na przyspieszenie pracy prawników lub nawet na przekupienie strażników i wypuszczenie skazańca. Było mi mało! Niech bonusy lecą z ocalonych więźniów! Razem ze złotem! I może jeszcze jakaś minigra, żeby urozmaicić zabawę! MAŁO! Dodałem losowanie szansy na oczyszczenie z zarzutów, a tym samym moi pracownicy dorobili się statystyk. Jeden był lepszy w usuwaniu niewygodnych świadków, inny w niszczeniu fizycznych dowodów. Teraz zarzuty było pokazywane w formie listy i gracz mógł przydzielić pracownika do określonego miejsca lub wykorzystać złoto lub użyć specjalnego bonus lub wziąć udział w minigrze. Ale nawet usunięcie wszystkich dowodów nie gwarantowało powodzenia! Bo było jeszcze losowanie, w formie rzutu dwiema kośćmi sześciościennymi. Te wszystkie dodatki zabiły mój pomysł. Traciłem czas na dodawanie kolejnych warstw w designie i już widzę, że nie usunę pojawiających się błędów i nie poprawię na czas wydajności.

Jednak najgorsze okazało się to, że sam nie wiedziałem, o co chodzi w moim projekcie. Dodatkowe warstwy wcale nie sprawiły, że gra stała się ciekawsza. Wprost przeciwnie! Jej wytłumaczenie wymagało napisania dość skomplikowanego samouczka, a różnego rodzaju zależności pomiędzy elementami wprowadzały jedynie chaos. Warto upraszczać swoje pomysły. Obawiam się, że wielu graczy niekoniecznie ma ochotę na przeszukiwanie Sieci w celu znalezienia skrzętnego opisu mechaniki gry. Raczej szukają zabawy.

Literat przegląda Internet #112

Tydzień z powolnym wdrażaniem się do rytmu. Można już coraz więcej, więc trzeba to wykorzystywać. Szkoda, że siedzenie w domu w dalszym ciągu jest obowiązkowe. Na szczęście mam co czytać i oglądać!

Jeżeli jakimś cudem przegapiliście najnowszy zwiastun Death Stranding, to musicie to koniecznie nadrobić.

O co chodzi z tym całym RODO?

Czy do Battlefronta wrócą lootboksy?

Wywiad z legendą NASA – Christopherem C. Kraftem!

GODOT, może jednak warto było czekać?

Powered by WordPress & Theme by Anders Norén