Subskrybuj newsletter o cyfrowej humanistyce i innowacjach w sektorze kultury

Budujemy muzealną grę tekstową z Twine i zbiorami Muzeum Emigracji (część II)

Okładka lekcji: portret kota w renesansowym stroju / Źródło: AI

Wprowadzenie

W poprzedniej lekcji poświęconej hipertekstowi i Twine przygotowaliśmy pierwsze leksje gry. Udało nam się ustawić kilka zmiennych i testowo uruchomić grę. Pora teraz na rozbudowanie rozgrywki - utworzymy nowe leksje i będziemy programować przetwarzanie zmiennych. Jeśli po skończonej lekcji nasza rozgrywka będzie działać, w ostatniej części cyklu o Twine dopracujemy jej warstwę estetyczną i uzupełnimy obiektami ze zbiorów Muzeum Emigracji w Gdyni.

Cele lekcji

Celem drugiej lekcji z cyklu jest zaprojektowanie mechaniki gry i nauczenie się programowania zmiennych w leksjach Twine.

Efekty

Efektem naszej pracy z Twine ma być prosta przeglądarkowa gra tekstowa. Efektem niniejszej lekcji będzie rozbudowana struktura hipertekstowa - sieć relacji między leksjami, która pozwoli nam już zagrać w grę. W trakcie zaprojektowanej przez nas gry przetwarzane będą zmienne, którymi opiszemy postać bohatera i stan rozgrywki.

Wymagania

Do pracy z Twine wymagana jest jedynie przeglądarka internetowa. Konieczne jest też zapoznanie się z poprzednią lekcją.

Część merytoryczna

Jedną z głównych wad drukowanych gier paragrafowych jest to, że zazwyczaj cała mechanika gry polega na przechodzeniu między leksjami (rozdziałami czy scenami). Stan rozgrywki bazuje na tym, w którym miejscu jest bohater czy bohaterka. Tymczasem w grach komputerowych czy fabularnych RPG (role-playing game) można korzystać z wielu zmiennych, które opisują stan rozgrywki i sytuację osoby grającej. Cechy postaci takie jak siła, żywotność, szybkość czy mana wpływają bezpośrednio na decyzje podejmowane przez graczy.

Gdyby nasza gra polegała tylko na przechodzeniu z jednej leksji do drugiej, rozgrywka mogłaby stać się nużąca - jak długo może bawić błądzenie po labiryncie? Na szczęście Twine pozwala uzupełnić mechanikę gry o przetwarzanie rozmaitych zmiennych. W poprzedniej lekcji zdefiniowaliśmy już takie zmienne i udało się nam nawet zaprogramować ich automatyczne przetwarzanie przy przejściu z leksji startowej do kolejnej leksji. Nasz bohater stracił trochę czasu, pieniędzy i zdrowia po wymuszonej decyzji o noclegu w hotelu robotniczym:

Twine - łączenie leksji / Źródło: Twine

Spróbujmy teraz rozwinąć nasz hipertekst i w bardziej zaawansowany sposób skorzystać z możliwości zarządzania zmiennymi w Twine.

Gra nie musi być odbiciem świata

Scenariusz naszej gry zakłada, że główny bohater mieszkać będzie i pracować w przedwojennej Gdyni, aby dorobić do biletu na transatlantyk. To, co na razie udało nam się przygotować, to początek rozgrywki - nasza postać przybywa do Gdyni i trafia do hotelu robotniczego na Grabówku. Ponieważ głównym celem, jaki ma nasz bohater, jest zarobienie pieniędzy na podróż do Ameryki, powinniśmy w mechanice gry udostępnić jakieś metody zarabiania. Nie możemy jednak pozwolić, żeby gra polegała wyłącznie na gromadzeniu pieniędzy - rozgrywka byłaby za łatwa i nierealistyczna. Nasza postać - Antoni Sulikowski - musi przecież gdzieś mieszkać i co jeść. Praca, którą będzie wykonywał, powinna zapewnić mu realizację tych podstawowych potrzeb oraz gromadzenie oszczędności na bilet. Celem osoby grającej powinno być nie tylko zdobycie niezbędnych funduszy na bilet, ale też utrzymanie Sulikowskiego w Gdyni.

Gra nie musi być odbiciem świata rzeczywistego, możemy w jej mechanice oddać tylko niektóre jego reguły i cechy. Dlatego z powodzeniem odrzucić możemy wątek wyżywienia - można się spodziewać, że przygotowanie mechanizmów utrzymywania zmiennej $zdrowie za pomocą chodzenia do różnych miejsc czy nawet jedzenia różnych potraw będzie nużące, a prowadzenie postaci w taki sposób może być też męczące dla gracza czy graczki.

Stworzyliśmy już leksję hotelu robotniczego na Grabówku. Spróbujmy rozwinąć ten pomysł. Nasza gra jest hipertekstem, a hipertekst to przechodzenie między leksjami. Niech w naszej grze postać porusza się nieustannie między leksjami z dwóch kategorii: NOCLEG i PRACA. Możemy założyć sobie, że leksje noclegowe będą reprezentowały wszystkie aktywności bohatera, które konieczne są do przeżycia, a leksje pracowe - aktywności konieczne do zarobienia pieniędzy. Możemy też od razu zaproponować pewne relacje między tymi kategoriami: leksje NOCLEG konsumować będą środki naszej postaci, a leksje PRACA zwiększać je.

I dalej, przejście gracza czy graczki na leksję z kategorii NOCLEG za każdym razem zmniejszy wartość zmiennej $tydzien - w ten sposób zasymulujemy upływ czasu. Antoni Sulikowski nie może przecież w nieskończoność czekać na wyjazd do Ameryki - jego rodzina zza oceanu może za jakiś czas zarządać zwrotu pieniędzy, które podarowała mu na podróż.

Podstawy mechaniki naszej gry

W trakcie rozgrywki gracz albo graczka przechodzić będzie z leksji z kategorii NOCLEG do leksji z kategorii PRACA i następnie znów do leksji NOCLEG idt. Za każdym przejściem między jedną a drugą kategorią aktualizować się będą zmienne - wejście do leksji PRACA zwiększy wartość zmiennej $portfel, a wejście do lekcji NOCLEG - zwiększy lub zmniejszy wartość zmiennej $zdrowie oraz zmniejszy wartość zmiennej $tydzien.

Dzięki możliwości pracy ze zmiennymi w Twine, możemy też uzależnić dostępność niektórych leksji od poziomu niektórych zmiennych. Np. niska wartość zmiennej $zdrowie uniemożliwi wejście na leksję PRACA W PORCIE, podobnie niska wartość $portfel nie pozwoli umieścić postaci w niektórych leksjach z kategorii NOCLEG.

Mechanikę naszej gry uzupełnijmy jeszcze o leksję w kategorii AKCJA. Niech reprezentuje nagłe zdarzenie, które w jakiś sposób zmodyfikować może $portfel i $zdrowie. W ten sposób wprowadzamy do rozgrywki trochę nieprzewidywalności i ryzyka.

kategoria właściwości mechanika przykład
NOCLEG Reprezentuje aktywności niezbędne do przeżycia w mieście (nocleg, odpoczynek, wyżywienie itp.) Zmniejsza wartość $portfel, modyfikuje wartość $zdrowie hotel robotniczy na Grabówku, nocleg na ulicy, buda na Witominie
PRACA Reprezentuje działania pozwalające pozyskać środki na przeżycie i zgromadzenie oszczędności na wyjazd Zwiększa wartość $portfel sprzątanie ulic, praca w porcie, naprawa budy na Witominie
AKCJA Reprezentuje nagłe i niespodziewane wydarzenia Modyfikuje wartość $portfel i $zdrowie bójka z pijanym marynarzem

Jak widać, mechanika naszej gry bardzo mocno upraszcza historyczne doświadczenie mieszkania i pracy w przedwojennej Gdyni. W pełnej wersji gry moglibyśmy dodać tam więcej elementów rozgrywki, na przykład leksje z kategorii GOSPODARKA, które - reprezentując np. poziom bezrobocia - modyfikowałyby dostępność leksji z kategorii PRACA. Pewne doświadczenie bezrobocia zasymulujemy jednak losowo - praca w niektórych lokalizacjach nie zawsze będzie dostępna.

Praca ze zmiennymi w Twine

Z poprzedniej lekcji wiemy już, jak w Twine definiować zmienne:

(set: $tydzien to 52)
(set: $portfel to 500)
(set: $zdrowie to 100)
(set: $mieszkanie to 0)

Modyfikując je w kolejnych leksjach, możemy albo je nadpisać, ignorując poprzednie wartości:

(set: $mieszkanie to 1)

albo zmodyfikować je relatywnie do aktualnych wartości:

(set: $tydzien to $tydzien - 1)
(set: $portfel to $portfel - 7)
(set: $zdrowie to $zdrowie - 10)

W Twine możemy także definiować zmienne losowo: losowość przyda się nam w określaniu wyniku bójki z marynarzem w leksji AKCJA czy automatycznym modyfikowaniu dostępności leksji PRACA (co ma symulować problem bezrobocia). Zanalizujmy poniższy kod:

(set: $praca_w_porcie to (either: 0, 0, 1))
(if: $praca_w_porcie is 1)

[
    (if: $zdrowie > 50)
    [
        [[Praca w porcie]]
    ] 
    (else:)
    [
        Nie masz siły na pracę w porcie...
    ]
] (else:)
[
    Dziś nie ma dla Ciebie pracy w porcie gdyńskim.
]

W linii 1 definiujemy losowo zmienną $praca_w_porcie - może przyjąć wartość 0, 0 lub 1, przy czym szansa, że wartością będzie 1 wynosi tylko 33 proc. W linii drugiej sprawdzamy, czy zmienna $praca_w_porcie wynosi 1 i jeśli (linia 4) zmienna $zdrowie jest większa niż 50, pozwalamy graczowi przejść na leksję Praca w porcie. Jeśli $zdrowie to mniej niż 50, informujemy gracza, że nasza postać nie ma siły na pracę w tym miejscu.

Poziom zdrowia naszej postaci nie jest w ogóle sprawdzany, jeśli zmienna $praca_w_porcie wynosi 0. Jak widać Twine pozwala nam skorzystać z pewnych struktur programowania (instrukcje warunkowe, porównywanie zmiennych), co pozwala rozbudować mechanikę gry. Hipertekst w Twine nie musi oznaczać prostego przemieszczania się między leksjami 🔥.

Podstawowa struktura rozgrywki

Przygotowałem podstawową strukturę rozgrywki naszej gry: gotowy kod można podejrzeć na GitHub, można też pobrać plik importu i samemu modyfikować leksje już bezpośrednio w Twine.

Twine - sieć relacji między leksjami / Źródło: Twine

Panel roboczy Twine ułatwia planowanie rozgrywki - możemy swobodnie układać leksje i obserwować na bieżąco połączenia między nimi. Połączenia generowane są automatycznie, jeśli w treści leksji odwołamy się do innej leksji, podając jej tytuł w podwójnych nawiasach kwadratowych, np:

[[Praca w porcie]]

Modyfikacje leksji w Twine zapisywane są na bieżąco w pamięci przeglądarki. Warto co jakiś czas eksportować plik zawierający strukturę i treść naszego hipertekstu, korzystając z menu Build i opcji Export as Twee.

Żeby zagrać w testową wersję naszej gry, z GitHub ściągamy plik gdynia_1934_czesc_2.html i otwieramy go w przeglądarce.

Podsumowanie

Twine pozwala budować zaawansowane systemy hipertekstowe, w których korzystać możemy nie tylko z połączeń między leksjami, ale też ze zmiennych. Zmienne możemy definiować, modyfikować i porównywać, dostępne są też funkcje losowania, które można użyć do zwiększenia nieprzewidywalności rozgrywki.

Kluczem do zaprojektowania gry hipertekstowej jest jednak odpowiednie przygotowanie mechaniki. Z konieczności będzie to zawsze pewne uproszczenie relacji i procesów znanych ze świata rzeczywistego. Warto zastanowić się jednak nad tym, czy nasi odbiorcy szukają symuacji historycznej rzeczywistości i skomplikowanej rozgrywki, czy raczej pewnych doświadczeń, które możemy im zaproponować nawet ograniczonym światem przedstawionym i prostą mechaniką gry.

Warto przywołać tutaj grę ICBM, której fabuła polega na… czekaniu:

Doświadczenie nudy nie może być podstawą mainstreamowych gier wojennych. W niszowej i nieco prześmiewczej gierce ICBM nuda została jednak podniesiona do rangi fabuły. Jest rok 1983, gracz wciela się w amerykańskiego oficera, jednego z trzech kontrolujących guzik uwalniający wymierzone w Związek Radziecki atomowe rakiety balistyczne. Celem gry jest symultaniczne naciśnięcie atomowego guzika przez wszystkich oficerów, a więc gracz musi wykazać się czujnością i refleksem. Problem w tym, że w grze nic się nie dzieje, a czas spędza się, klikając w dziwne przyciski na konsoli i oczekując na Ważny Telefon z Waszyngtonu.

ICBM / Źródło: web.archive.org/web/20150411124807/http://icbm-game.com/

Co to za gra wojenna, w której nic się nie dzieje? ICBM humorystycznie symuluje jednak pewne doświadczenie (niedostępne dla zwykłego śmiertelnika), podważa też oczekiwania co do rozgrywki, sprawia, że w nieco inny sposób spoglądamy na zimną wojnę. Gra nie musi być odbiciem świata, ale odbiciem pewnych doświadczeń 🤓.

Wykorzystanie metod

Możliwości, jakie w pracy ze zmiennymi daje nam Twine, wykorzystać można nie tylko do budowy gier tekstowych. Twine to dobry system do przygotowania interaktywnego podręcznika, w którym kolejne rozdziały stają się dostępne dopiero po zaliczeniu poprzedających, niezbędnych części. Także interaktywne hipertekstowe przewodniki mogą wykorzystywać elementy gamifikacji dzięki zastosowaniu zmiennych. W Twine można również tworzyć testy i quizy.

Pomysł na warsztat

Wykorzystaj Twine do budowania i testowania instrukcji warunkowych i porównywania zmiennych. Możesz przygotować proste gry (rzucanie kostką czy losowanie kart) albo proste prezentacje, korzystające ze zmiennych losowych (np. system losowania cytatów). Oczywiście wszystkie publikowane tu lekcje o Twine możesz wykorzystać podczas warsztatów z tworzenia gier tekstowych lub interaktywnych fikcji.