Powrot do wpisow

web

Jak powstał Vanguard — terminalowa gra ARG w przeglądarce

Kulisy powstania Vanguarda: od niewykorzystanej domeny, przez fabułę i terminal, po statyczną implementację w przeglądarce, testy oraz pracę z AI.

Przez dłuższy czas domena traveler.ovh służyła mi wyłącznie do obsługi poczty. Nie była pod nią opublikowana żadna strona WWW, więc po wejściu na adres nie wyświetlało się nic szczególnego. Sprawiała trochę takie wrażenie, jakby właśnie tam kończył się Internet. Zamiast dodać informację o stronie w budowie postanowiłem potraktować tę pustą przestrzeń jako punkt wejścia do niewielkiej gry narracyjnej.

Tak powstał Vanguard — gra ARG dostępna bezpośrednio w przeglądarce, z interfejsem stylizowanym na terminal. Ten projekt okazał się ciekawym połączeniem frontendu, projektowania zagadek, opowiadania historii i iteracyjnej pracy z Agentem AI.

Ekran wejściowy Vanguarda z polem klucza autoryzacyjnego i ostrzeżeniem stylizowanym na komunikat zamkniętej sieci

Komunikaty ostrzegawcze widoczne na ekranach należą do fikcyjnej narracji i nie opisują telemetrii publicznej wersji gry.

ARG, czyli historia składana z fragmentów informacji

ARG to skrót od Alternate Reality Game. W tego rodzaju grach historia nie musi być opowiedziana wprost ani podzielona na tradycyjne poziomy. Gracz poznaje ją przez rozproszone informacje i sam ustala, które elementy mają znaczenie oraz jak łączą się w większą całość.

Vanguard wykorzystuje przede wszystkim ten sposób prowadzenia narracji. Po wejściu do gry nie otrzymujemy długiego wprowadzenia ani listy zadań do wykonania. Zamiast tego aplikacja pokazuje fragment fikcyjnego systemu, a kolejne informacje trzeba odnaleźć i zinterpretować samodzielnie.

Gra ma konkretną fabułę oraz zaplanowaną ścieżkę odkrywania, lecz nie będę jej tutaj opisywał. Ważnym elementem interfejsu jest widoczny indeks postępu. Pozwala zorientować się, ile istotnych elementów gry zostało już odkrytych.

Dlaczego terminal

Terminal pasował do tego pomysłu z dwóch powodów. Po pierwsze, pozwala prowadzić interakcję za pomocą tekstu, bez rozbudowanego interfejsu graficznego. Po drugie, wynik działania może być jednocześnie odpowiedzią aplikacji i fragmentem narracji. Gracz nie tylko czyta historię, ale aktywnie próbuje wydobyć ją z dostępnego środowiska.

To nadal wyłącznie konwencja. Vanguard nie jest prawdziwym systemem Linux, emulatorem terminala ani zdalną powłoką. Wpisywane polecenia są rozpoznawane i obsługiwane przez JavaScript działający w przeglądarce. Żadne komendy nie są wysyłane do serwera w celu wykonania akcji w systemie operacyjnym.

Takie rozgraniczenie było ważne także podczas projektowania. Interfejs miał wyglądać wiarygodnie, ale nie musiał odwzorowywać pełnego zachowania powłoki. Zbyt duży realizm wprowadziłby funkcje niezwiązane z rozgrywką, a osobom rzadziej korzystającym z terminala utrudniłby odróżnienie istotnych informacji od dekoracji.

Ostatecznie wybrałem kompromis: znane zasady pracy tekstowej, historia poleceń, podpowiadanie składni i odpowiedzi przypominające narzędzia systemowe, ale tylko w zakresie potrzebnym do prowadzenia rozgrywki. Czytelność i prowadzenie gracza były ważniejsze od kompletności symulacji.

Terminal Vanguarda po uruchomieniu fikcyjnego systemu, z komunikatami startowymi i indeksem odkryć

Najpierw fabuła, potem ścieżka gracza

Integralną częścią projektu jest zarówno mechanika gry, jak i fabuła. Projektowanie zaczęło się od szerszego planowania przebiegu historii, którą dzieliłem na mniejsze fragmenty, aby w logiczny sposób zbudować spójną fabułę. Każdy ważny trop ma uzasadnienie w świecie gry i odtwarza fikcyjne wydarzenia. W praktyce fabuła i mechanika pozostają równolegle.

Statyczna aplikacja z logiką w przeglądarce

Warstwa rozgrywki Vanguarda jest statyczną aplikacją zbudowaną w HTML, CSS i JavaScripcie. Aktualna wersja mieści strukturę interfejsu, style i logikę gry w jednym pliku. JavaScript utrzymuje bieżący stan sesji, rozpoznaje działania gracza i aktualizuje stan wirtualnego środowiska.

Aplikacja nie potrzebuje backendu do interpretowania poleceń ani bazy danych do prowadzenia fabuły.

Taka architektura ma konkretne zalety:

  • jest łatwa do opublikowania i utrzymania,
  • nie udostępnia graczowi prawdziwego konta ani powłoki systemowej,
  • większość interakcji odbywa się w przeglądarce,
  • nie wymaga serwera aplikacyjnego ani bazy danych do prowadzenia rozgrywki.

Największe ograniczenie jest konkretne i raczej oczywiste: przeglądarka musi pobrać kod potrzebny do działania gry. Osoba, która otworzy narzędzia deweloperskie i zacznie analizować źródło, może dotrzeć do informacji przeznaczonych do stopniowego odkrywania. Minifikacja lub zaciemnianie kodu mogłyby to utrudnić, ale nie rozwiązałyby problemu. W statycznej aplikacji nie da się skutecznie ukryć przed użytkownikiem danych, które zostały wysłane do jego urządzenia.

To był świadomy kompromis. Vanguard nie próbuje chronić rozwiązania jak sekretu po stronie serwera - po prostu zakłada, że gracz chce przejść zagadkę i się dobrze bawić, a nie odczytywać sekwencji kroków ze źródła strony.

Telemetria: od ciekawości do świadomej rezygnacji

Na etapie prac deweloperskich chciałem sprawdzić coś, czego nie dało się łatwo z góry ocenić, znając wszystkie kroki rozwiązywania zagadek: gdzie gracz się zatrzymuje i czy dociera do końca. Z tej ciekawości powstała pierwsza wersja telemetrii, która pozwalała mi analizować próby logowania oraz postępy pojedynczej sesji. Telemetrię uruchomiłem podczas krótkich, zamkniętych testów. W tym okresie system działał i rejestrował zdarzenia zgodnie z ówczesną implementacją.

Telemetria działała podczas zamkniętych testów, ale ostatecznie usunąłem ją z aplikacji i nie włączyłem jej do wersji udostępnionej publicznie.

Pierwsze rozwiązanie szybko przestało wyglądać jak niewielki dodatek. Podczas przeglądu zacząłem się zastanawiać, czy jego zakres jest proporcjonalny do celu - czy rzeczywiście ograniczam dane do niezbędnego minimum, jak długo powinienem je przechowywać i w jaki sposób użytkownik miałby świadomie wyrazić zgodę. Dochodził do tego całkiem przyziemny koszt utrzymywania osobnego Workera, bazy D1 oraz panelu analitycznego. Każdy z tych elementów wymagał konfiguracji, zabezpieczenia i późniejszej kontroli.

W kolejnym etapie testów zmieniłem założenia projektu. Telemetria miała być dobrowolna i uruchamiać się dopiero po zgodzie gracza. Nie przewidywała stałego identyfikatora użytkownika ani zapisywania treści komend, a szczegółowe zdarzenia miały być usuwane z aktywnej bazy po 45 dniach. Taki model był rozsądniejszy od pierwszej wersji, jednak wciąż oznaczał dodatkowy mechanizm zgody. Technicznie mechanizm był już gotowy: Worker, baza D1, retencja i panel analityczny działały. Ostatecznie uznałem jednak, że w tak małym projekcie korzyść z telemetrii nie uzasadnia dodatkowej warstwy technicznej i formalnej.

W pewnym momencie ważniejsze od tego, jak obsłużyć telemetrię stała się odpowiedź na pytanie, „czy ten projekt w ogóle jej potrzebuje?”. Vanguard jest małym, eksperymentalnym ARG, a liczba informacji, które realnie mogłem wykorzystać do ulepszania gry, nie uzasadniała narzutu związanego z telemetrią.

Dlatego przed publicznym udostępnieniem gry całkowicie usunąłem z niej mechanizm telemetrii. Nie zdecydowałem się pozostawić go na etapie publikacji i publicznego udostępniania. Publiczna wersja gry nie tworzy identyfikatora telemetrycznego, nie wysyła zdarzeń rozgrywki i nie używa cookies ani Web Storage do śledzenia postępu. Cloudflare jako dostawca hostingu i zabezpieczeń nadal technicznie obsługuje zwykłe żądania sieciowe potrzebne do wyświetlenia strony, ale aplikacja nie prowadzi własnej telemetrii rozgrywki.

Agent AI w projektowaniu, implementacji i testach

Agent AI uczestniczył w projekcie na kilku etapach - pomagał w opisywaniu założeń, implementacji, testach jednostkowych i w nanoszeniu poprawek. Wykorzystywałem AI do porządkowania własnych pomysłów, analizy kolejności tropów, pracy nad komunikatami, modyfikowania kodu oraz szukania niespójności. Agent przyspieszał pracę, ale wymagał precyzyjnych założeń, weryfikowania zmian i cofania rozwiązań, które technicznie działały, lecz nie pasowały do gry.

Jak testować grę narracyjną

Testy techniczne obejmowały obsługę wejścia, przejścia między stanami, obsługę błędnych danych, aktualizację postępu oraz zachowanie interfejsu. To jednak tylko część pracy - w grze narracyjnej trzeba także testować przepływ informacji. Sprawdzałem, czy początek daje wystarczający punkt zaczepienia, czy kolejne tropy nie są zbyt trudne do odnalezienia.

Wnioski

Chociaż stos techniczny jest niewielki — HTML, CSS i JavaScript — projekt wymagał zaprojektowania spójnej ścieżki gracza, testowania wielu stanów aplikacji oraz podjęcia decyzji o całkowitym usunięciu gotowej już telemetrii.

Terminal okazał się dobrym interfejsem nie dlatego, że idealnie symuluje system operacyjny, lecz dlatego, że naturalnie łączy działanie z tekstem, jak również skutecznie buduje klimat dobrze znany administratorom systemów. Statyczna forma uprościła publikację i ograniczyła zaplecze potrzebne do utrzymania i obsługi gry, a jednocześnie wymusiła akceptację tego, że rozwiązania nie da się skutecznie ukryć w samym kodzie HTML.

Jeśli chcesz zobaczyć efekt mojego projektu, uruchom Vanguard na traveler.ovh. Najlepiej zacząć bez zaglądania do źródła strony, ponieważ część wskazówek znajduje się poza samym kodem aplikacji.