The Games That Designed Themselves

Ciężko jest wyobrazić sobie grę
Ape Out bez małpy.

A jednak dokładnie tak zaczynała.

Według designera Gabe'a Cuzzillo, miała to
być skradanka osadzona w pętli czasowej,

gdzie wykorzystywałbyś mechaniki łapania
i odpychania, by posuwać się wzdłuż ścian.

Jeśli jednak pojawiliby się
strażnicy, mógłbyś wykorzystywać

te same mechaniki na nich,
doprowadzając do łapania strażników

i rzucania nimi o ściany.

Okazało się, że to najciekawsza
część gry. Gabe postanowił zmienić

jej kierunek i zbudować
rozgrywkę wokół tej mechaniki.

Usunął z niej wszystko, co niepotrzebne,
jak skradanie się i pętle czasowe.

Zrobił wszystko w swojej mocy, by
wyeksponować ten pomysł -

głównie zamieniając łysego

bohatera na dzikiego,
stukilogramowego goryla.

Jest to przykład metodologii
tworzenia gry zwanej "Idź za zabawą".

Jest to zwodniczo prosty pomysł, w którym
designerzy powinni porzucić swoje plany

i założenia, a zamiast tego posłuchać
samej gry, żeby odkryć, w którym

kierunku należy ją rozwijać.

Weźmy za przykład taktyczną
perełkę Into the Breach.

Gra zaczęła jako dosyć standardowy klon
Advance Wars, gdzie przeciwnicy atakowali

losowo i nie zdradzali swoich
intencji aż do swojej tury.

Jednak jeden wróg w grze pokazywał ci, co
dokładnie zamierzał zrobić w swojej turze,

podświetlając płytkę,
którą miał zaatakować.

Developerzy w Subset zdali sobie sprawę,
że to najfajniejsza część rozgrywki, więc

postanowili przerobić resztę gry tak, żeby
skupiała się na sygnalizowaniu ataków.

A to pomogło w podjęciu pozostałych
decyzji w sprawach game

designu.

Bo skoro wiesz, co zrobią przeciwnicy,
nie możesz po prostu przesunąć swoich

jednostek ze strefy ataku?

Może w grze chodzi o ochronę
nieruchomych budynków?

A więc teraz chodzi o popychanie
wrogów tak, żeby spudłowali.

Możesz jednak wykorzystać
to, żeby sami się pozabijali.

Zapewne widzisz już, dlaczego
designerzy, którzy korzystają

z tej metody mawiają, że ich gra

do pewnego stopnia
zaprojektowała się sama.

Jak mówi Sam Coster z Butterscotch
Shenanigans, studia

stojącego za Crashlands:

SAM COSTER: "Lubimy myśleć o tym procesie
jako o grze odkrywającej samą siebie.

Naszą rolą jest po prostu
grać w grę, słuchać

jej, poczuć ją, wyczuć, czym ona
chce się stać i po prostu rozwijać

to, co sprawia frajdę".

Pomysł gry projektującej się samej jest
z pewnością ekscytujący dla tych,

którzy chcą zrobić hiciora.

Pomysły na grę nie pojawiają
się jednak z powietrza.

Skąd więc się one biorą?

Spójrzmy na początki rytmicznego
roguelike'a Crypt of the Necrodancer.

Designer Ryan Clark chciał
sprawdzić, czy da się pożenić szybki

gameplay ze Spelunky

z bardziej tradycyjnym
turowym dungeon crawlerem.

Zrobił więc szybki prototyp roguelike'a,
w którym miałeś tylko sekundę

na wykorzystanie swojej tury.

W trakcie grania Ryan zorientował się, że
gra stała się niemal rytmiczna, więc

uznał, że powinna ona
pójść w kierunku muzyki.

Rzućmy może okiem na ikoniczny
system poruszania się w powietrzu

w Rocket League.

Kiedy Psyonix pracowało nad
poprzedniczką gry, Supersonic Acrobatic

Rocket-Powered Battle-Cars,

dużo się nauczyli o marketingu
od tamtego czasu.

Zrobili grę o samochodowych bitwach, ale
chcieli dodać mechanikę speed boost.

Przyłożyli więc siłę do tyłu samochodu.

Podczas testowania gracze wykorzystywali
tę siłę w powietrzu, by przelatywać nad

areną.

Nie taki był plan, ale developerzy uznali,
że dodaje to grze ogromnej głębi

i zupełnie nowego wymiaru,
więc nie usunęli tego.

Studio mówi: "opracowaliśmy tę
mechanikę niemal przez przypadek".

W rzeczywistości istnieje wiele gier,
których bugi, glitche oraz wypadki

podczas tworzenia
przekształcono w mechaniki.

Hideki Kamiya znalazł buga w Onimusha:
Warlords, który umożliwiał żonglowanie

przeciwnikami w powietrzu,
uderzając ich wiele razy.

Było to fajne, więc Kamiya rozwinął to
i przekształcił w jedną z głównych

mechanik w Devil May Cry.

Chodzi o to, że ten proces wymaga wzięcia
jakiegoś pomysłu, choćby luźnego, ogólnego

czy nieoryginalnego, i zbudowania
działającego prototypu.

To tutaj, podczas kodowania i grania,
mogą pojawić się nowe pomysły.

To designer musi być otwarty
i słuchać tego, co mówi gra.

Zaobserwować to, co jest ciekawe oraz
chcieć rozwinąć te aspekty, nawet jeśli

nie do końca zbiegają się z tym,
co początkowo miał na myśli.

W ten sposób Gunpoint przekształcił się
z robota zrzucającego lodówki na ludzi

w grę logiczną o szpiegu bawiącym się
instalacjami elektrycznymi w budynkach.

Ta mechanika była ledwie jednym
pomysłem na minigierkę z hakowaniem

w sidescrollerze inspirowanym Deus Ex.

Kiedy jednak Tom Francis zaczął robić
jej prototyp, powoli wyłaniała się gra,

która stanie się Gunpointem.

Jak mówi Tom:

TOM FRANCIS: "Stało się oczywiste,
że to powinna być gra logiczna.

To była tylko mechanika.

Gunpoint powiedział mi, czym chce być.

Po prostu grą logiczną.

Przystałem na to i rozwinąłem mechanikę
hakowania do szalonych rozmiarów.

Dorobiłem do niej całą grę".

Ten proces zazwyczaj wywołuje
największe zmiany w kierunku

tworzenia gry. Na tym etapie
Sam Coster określa grę jako białą

kulę gorącej, plastycznej magmy.

Można ją jednak wykorzystać w procesie
tworzenia, w trakcie którego gra

uformuje się i stanie się skałą.

Jonathan Blow powiedział, że
zagadki w Braid były po prostu

pokazem nieoczekiwanych konsekwencji
związanych z silnikiem gry.

Blow mówi: "miałem rolę kuratora;
poprawiałem odpowiedzi

i prezentowałem je w taki
sposób, żeby cieszyły graczy.

Więcej o tym w tym filmie.

Można to również wykorzystać,
słuchając feedbacku graczy.

Kiedy Chris Hecker stworzył SpyParty,
gracze znaleźli mnóstwo exploitów

i niezamierzonych sposobów grania.

Zamiast naprawić te "bugi",
Chris zrobił z nich oficjalną

część gry, tworząc
doświadczenie raczej z gatunku

gier umysłowych i sztuczek
psychologicznych.

Można to wykorzystać też po prostu podczas
kierowania ogólnym rozwojem gry.

Jak mówi designer
Subnautiki Charlie Cleveland:

CHARLIE CLEVELAND: "Mniej
więcej wiesz, dokąd zmierzasz.

Widzisz jakieś miejsce na horyzoncie.

Istnieje wiele ścieżek, by tam dotrzeć.

Jeśli jednak posłuchasz gry,
powie ci ona, dokąd chce iść".

W ten sposób studio stworzyło
horror, co nie było zamierzone

na starcie projektu.

Oczywiście tego typu proces tworzenia
może bardzo utrudnić przewidzenie

daty zakończenia projektu.

M.in. z tego powodu ta metodologia jest
popularniejsza w świecie indyków, a nie

blockbusterów.

Kiedy Tom Francis tworzył
swoją drugą grę, Heat Signature,

liczył na to, że mglisty pomysł

wchodzenia do statków kosmicznych
magicznie pokieruje się w stronę

dobrych rzeczy, tak jak
było przy Gunpoint.

Tyle że... Tak się nie stało.
Przynajmniej przez bardzo długi czas.

Tom zdał sobie sprawę, że musi zrobić
pierdylion rzeczy, żeby sprawdzić,

co będzie fajne. Wydłużyło
to proces powstawania gry,

w trakcie którego zrobił on

system generowania statku, sztuczną
inteligencję, system walki,

mapę całej galaktyki
z jej ekonomią i tak dalej.

Tomowi zajęło lata, by dojść do wniosku,
że walka na statku była najciekawsza.

Dlatego warto pamiętać, że proces ten
to w rzeczywistości trochę więcej

niż zwykłe "podążaj za zabawą".

Szukając, skąd wzięło się to powiedzenie,
znalazłem Marca LeBlanca.

Designera, który pracował przy Thief
i System Shocku oraz nauczyciela,

który pomógł opracować
pomysły takie jak framework MDA.

Tworząc to powiedzenie, zaczął
on od znanego idiomu ze świata

designu i biznesu:
"popełniaj błędy szybko".

Jest to proces składania wszystkiego
jak najszybciej, żeby zobaczyć, co

działa, a co nie.

Nieważne, jeśli ci się nie uda, gdyż nie
zmarnowałeś wiele czasu. Ta tak zwana

"porażka" powie ci bardzo dużo na temat
kierunku, w którym powinieneś pójść.

Być może istnieją techniki
przyspieszające proces iteracji?

Jedną jest coś, co znają wszyscy
widzowie GMTK: Game Jamy.

Paniczne maratony tworzenia gier,
w których musisz spróbować

zrobić grę, na przykład, w jeden weekend.

Arvi Teikari, który wymyślił udaną grę
logiczną Baba is You na Game Jamie,

tak mówi o mocy tych wydarzeń:

ARVI TEIKARI: "Całą ideą jest
zrobienie prototypu czegoś,

co masz w głowie.

Jeśli nie działa, nie szkodzi.

Możesz go wywalić po Game Jamie. Jesteś
za niego odpowiedzialny tylko w trakcie

Game Jamu".

Inną techniką jest korzystanie z narzędzi
sprzyjających szybkim prototypom,

jak Game Maker czy Godot.

Albo z papierowych prototypów, LEGO, czy
gry, w której tworzymy gry - Dreams.

Jeśli zrobiłeś już większość gry i chcesz
tylko generować zawartość, możesz stworzyć

narzędzia do tworzenia poziomów,
by przyspieszyć ten proces

i znaleźć więcej ludzi do pomocy.

W Mario Galaxy 2 Nintendo stworzyło proste
narzędzia do tworzenia poziomów, żeby

każdy w zespole mógł
wymyślać unikalne mechaniki.

Żeby skupić się na designie i mechanikach,
można wykorzystać placeholderowe

grafiki, muzykę oraz fabułę.

Kiedy Klei stworzyło pierwszy
prototyp Don't Starve, bohatera gry

reprezentował...

Link z Zeldy.

I wreszcie, może się okazać pomocne coś,

co absolutnie nie może się zmienić w grze.

Sunni Pavolic z thatgamecompany
mówi, że studio wykorzystało bardzo

iteratywną metodologię podczas

tworzenia Podróży, lecz zawsze z ideą, że
gra będzie poruszała temat miłości.

Dało to każdemu w zespole jeden
kierunek i pozwoliło zawęzić

szeroki zakres możliwych pomysłów,
które mogli wymyślić i opracować.

Jeśli miałbyś wyciągnąć z tego filmu jedną
rzecz, niech to będzie to: przestań

czekać, aż przyjdzie do ciebie
pomysł na grę idealną.

Łatwo spojrzeć na coś typu Ape Out,
Crypt of the Necrodancer

czy Crashlands i uznać, że te gry
powstały w przebłysku geniuszu,

który od razu przerodził
się w produkt finalny.

Więc jeśli nie możesz wymyślić czegoś
równie dobrego, po co próbować?

Jak pokazałem w tym filmie, jest
to bardzo dalekie od prawdy.

W rzeczywistości wszystkich tych
developerów łączy to, że coś zaczęli

i zbudowali.

Dopiero wtedy, gdy designerzy
próbowali nowych pomysłów, grali

w ich prototypy oraz

tworzyli bugi, zaczęły się formować
gry, które znamy dzisiaj.

To świetni designerzy nie dlatego, że
wpadli na genialne pomysły,

lecz dlatego, że

potrafili posłuchać gry, wiedzieli,
którymi alejkami podążać, umieli

popełniać błędy szybko

i często i wiedzieli, jak połączyć te
różne pomysły w coś spójnego.

Jeśli oglądasz Game Maker's Toolkit
i chciałbyś stworzyć grę, nie

czekaj na idealny pomysł.

Zbuduj coś.

Potem będziesz mógł posłuchać gry
i podążyć za zabawą. Może odkryjesz, że

gra w pewien sposób projektuje się sama.

Tłumaczenie: Przemyslav