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.