RPG Design #2 – Przygoda w October Rust

Kontynuuję dalej cykl tekstów o projektowaniu erpegów. To kolejny tekst, w którym przedstawiam to, jak powstawał Najgorszy Erpeg Roku 2021 (czyli October Rust). Tym razem tematem jest struktura przygody. Dlaczego? Testy, testy, jeszcze raz testy – oto, dlaczego sama gra ulegała przeobrażeniom Praktycznie wszystkie pozostałe zmiany – w tym działanie Rdzy – podlegało właśnie zmianom wprowadzanym w wyniku playtestów…

To była rzecz, która zabijała we mnie pewność siebie. Powątpiewałem, czy w ogóle jest sens pracować nad tą grą. Obecny model rozgrywki okazał się być tym trzecim!

Założenia przygody

Od początku chciałem, aby rozgrywka w „October Rust” wyglądała następująco:

• Jest to jednostrzał.
• Gra ma wymagać pewnego zaangażowania się we wspólną przygodę („buy-in”).
• Gra ma sama prowadzić do konkluzji („gra naciska na etapy i na zakończenie”)
• Trójaktowa struktura opowieści (budowanie napięcia, finał/kulminacja, epilog do rozegrania)
• Postacie mają zużyć wszystkie lub co najmniej większość swoich zasobów; mają poświęcać rzeczy (lub siebie), mają „zardzewieć”.
• Przygoda ma od razu wprowadzać postacie do akcji.

Teraz mógłbym rzec, że od początku interesowała mnie intensywna, dość krótka (2-3 h) sesja w akcję, wyskok, jakby heist. Prawdą jest to, że nie byłem tego świadom przez dłuższy czas. To jest, nie byłem świadom, że to musi być heist…

Początki „Październikowej Rdzy”

Wersje 0.1a i 0.2a

Pierwotny koncept na grę zakładał, że prowadzący przygotuje przed sesją przygodę według ściśłej instrukcji. Podział sesji/scenarusza na trzy etapy (Development, Final, Epilogue), a wynikało z niego prawie wszystko, w tym:

• Trudności testów (inny model matematyczny konfliktów) – I etap miał najłatwiejsze, II etap miał najtrudniejsze, III etap był „pośrodku” z trudnością.
  • Inna kostkologia: o ile koncept „porównaj Theme + bonusy vs Obstacle” już wtedy zaistniał, to jeśli brakowało ci punktów, to brałeś d12 i patrzyłeś w tabelkę, ile musisz rzucić „równo lub poniżej”. Progi 1/2/4/6/9, jak ktoś jest ciekaw. I tak, był suwak!
• Trochę ta gra prowadziła po sznurku, oprócz rozgrywania ostatniego etapu.
• Do tej gry nie można było przysiąść i z marszu zaimprowizować przygodę (jak jest obecnie).

Ten model chciałem wykorzystać choćby z tego powodu, że już podczas jedynego jego playtestu odpowiednio mocno zużywał zasoby postaci. Ten jeden element rozgrywki działał dobrze. Plus „October Rust Alfa” miał potencjał wydawniczy: można by było wypuszczać kolejne przygody na 3-5 stron A4u. Jak już o tym wspominam, to na tym modelu dałoby się zrobić przygodę o „Reducie Ordona”. Tak, tym wierszu Adama Mickiewicza…

Dlaczego obecnie gra jest inna?

Krótka odpowiedź: „October Rust” był wtedy parodią Jesiennej Gawędy, ale przede wszystkim był parodią samego siebie.

Długa odpowiedź: O ile kwestie matematyczne (tzw. „balans”) dałoby się poprawić, problemy były jeszcze inne. Po pierwsze, gra robiła „coś”, ale niekoniecznie to, co ta gra obiecywała. Przede wszystkim, zaistniały model czynił postacie graczy niekompetentnymi, obracając to w znaną ponurą komedię rodem z Warhammera. Mniej „na papierze”, bardziej jak to czuli testerzy.

Po drugie, w tym frameworku (silniczek + struktura) było pełno elementów tylko po to, aby były. Choćby ten suwak, dla odwołania się do suwaka z Neuroshimy. Już wtedy suwak działał lepiej niż w Neuroshimie (podbijał w górę próg z tabelki), ale co z tego? Ta tabelka z progami sukcesów, przypominała rozwiązania sprzed 20-30 lat. Gra miała wielki potencjał straszyć, gdyby używała d20 lub d100…

To, plus parę innych drobiazgów (np.: złożone zasady Burzy: jak wpływa na testy) sprawiało, że lepsza opcją byłoby po prostu wyrzucić tamten framework gry i napisać nowy. Tak też uczyniłem.

Zmieniłem też jedno założenie co do gry. Od tamtego momentu chciałem, aby gra miała jak najmniejszy próg wejścia. Prowadzący sesję nie musiał robić nic oprócz przejrzenia podręcznika. Gracze w sumie też.

Drugi framework

Wersje 0.3b, 0.4b i 0.5b

Drugi pomysł na przygodę zawiera w sobie obecny silniczek gry, który ulegał poprawkom. Odchudzenie crunchu, poprawa „zużycia zasobów”, itp. Ten framework polegał na tym, aby improwizować jednostrzał, „Prep” robimy na początku spotkania z „October Rust”. Mechanizmy takie jak Storm Clock czy Rust Clock pochodzą właśnie stąd.

Drugi framework zakładał, że uczestnicy najpierw wymyślają Final Question (o czym chcą grać). Później wymyślają tyle „Pytań” (Adventure Questions) do odpowiedzi przed FQ, ilu jest graczy, a potem prowadzący dodaje własne. Cała gra polegała najpierw na odpowiedzi na te 3-6 AQ (zależnie od liczby graczy), a później na FQ, a na koniec dwa Epilogue Questions.

Koncept „przygody-gotowca” poszedł w kąt.

Dla tych pierwszych prób, łatwiej jest napisać, co było w porządku. Dzięki zmienionemu silnikowi gry, gra przestała parodiować siebie. Sama nowa formuła improwizowania przygód sprawdzała się, gracze doceniali to, a mi jakoś przyjemniej podchodziło się do testów. Gra faktycznie miała mniejszy próg do poprowadzenia jej.

Jednak ta struktura przygody miała nieustanny problem z tempem zużywania zasobów: następowało to za wolno. Podejmowałem poprawki, działało to trochę lepiej. Dalej tamta struktura była na to bardzo wrażliwa. Im więcej graczy, tym bardziej było to widoczne…

Co więcej, nie było ograniczeń co do tego, o czym mają być te Adventure Questions. W rezultacie, jedna z sesji testowych stała się śledztwem. „October Rust” okazał się nie działać jako przygoda w śledztwo. Wtedy bowiem albo odpowiedź na dane AQ mogło nastąpić przypadkiem bez konfliktu (rzutu), albo można było toczyć wiele konfliktów metoda prób i błędów, aby mieć jak odpowiedzieć na to jedno z Pytań.

Innymi słowy, gra okazała się działać tylko jako heist. Musiałem wprowadzić zmiany, mające na celu ograniczyć przygodę wyłącznie do skoków, wyczynów, zwięzłych intensywnych akcji. Swoją drogą, „October Rust” słabo zaznaczał sam gatunek settingowy (low/gothic early modern fantasy). Na to też zwrócono mi uwagę.

Jak to wygląda obecnie?

Wersja 0.6b + te od oficjalnej publikacji

Wywaliłem koncepcję samodzielnego wymyślania Adventure Questions. Zamiast tego pojawiło się Adventure List wraz z pięcioma pytaniami, które tworzą nam zręby settingu oraz elementy przygody. Aby dojść do Final Question, trzeba przejść przez tzw. forces of evil, czyli grupy przeciwne postaciom. Opcje są ograniczone, aby na coś się zdecydować i wokół tego wykazać się kreatywnością.

W rezultacie, rozwiązało to problemy:

• Tempo zużywania zasobów zaczęło działać z grubsza jak powinno (w tym dzięki zmianie zasad rozdawania months). Dwa następne playtesty, gra zaczęła działać, potrzebna była tylko lepiej napisana instrukcja…
• Dzięki temu, że jest to sesja w heist, nie będzie rozwalać się na dywagacje „co by tu teraz zrobić”. Uczestnicy wiedzą, co mają zrobić: uporać się z otoczeniem i przeciwnościami.
• Gra jest jeszcze bardziej przystępna. Gracze nie muszą wymyślać kilku pytań, tylko wspólnie wybierają opcje. Prowadzący od razu ma elementy settingu do wprowadzenia.
• Przy okazji, ta gra zaadresowała problem zbyt słabego osadzenia w pożądanym settingu.

Jednocześnie zachowana jest wciąż struktura trójaktowa opowieści. W sumie jest mocniej uwydatniona niż przy drugim modelu: robimy build-up zmagając się z forces of evil. Rzekłbym, że OR w końcu robi to, co miał robić od początku. Bez żonglowania sztywnymi trudnościami według tekstu scenariusza oraz specjalnej instrukcji tworzenia przygody na dzień lub więcej przed sesją…

Obecne rozwiązanie w „October Rust” jest dalekie od ideału. Choćby dalej samo osadzenie „w epoce wczesnonowożytnej” jest głównie przyjętą konwencją. Ta gra nie ma mechanik symulacji fizyki toru lotu 17,8 mm ołowianej kuli wystrzelonej z Brown Bess; nie potrzebuje tego. Nie zamierzałem też pisać rozbudowanych opisów przyrodniczych czy wypracowań z epoki.

Ograniczyłem liczbę uczestników do 2-4 graczy + prowadzący. Odrzucenie możliwości dla „piątego gracza” wiązało się z dwoma powodami:

• Im więcej graczy, tym gra dalej jest trochę łatwiejsza. Moim zdaniem, dla zestawu 5+1 gra mogłaby okazać się „zbyt łatwa” dla zasobów postaci, nawet gdyby dodać piąty force of evil.
• Mam wrażenie, że przechodzenie przez pięć „sił zła” mogłoby być odczuwalne jak jakiś grind albo syndrom przebrnięcia do „tego ciekawszego momentu sesji”. Mogłoby to nudzić.

Plus, podczas tworzenia dodatku „Vials of Mercury”, trochę czułem, że te „dwanaście sił zła” do wyboru to trochę mało…

Posłowie

Postawiłem sobie wysoko poprzeczkę, robiąc grę, która ma zużywać zasoby w dość ścisłym tempie, jednocześnie ze sztywną strukturą przygody. To były dwie „prędkości”, które musiałem ze sobą zrównać. Jednocześnie, żadne z nich nie mogło być za wolne.

Cały mój wywód pokazuje siłę testów. Najpierw testy pomogły mi obnażyć framework, który zniweczyłby grę na jej starcie. Przy okazji skompromitowałby mnie jako początkującego twórcę. Później, testy dawały mi znać, że ta gra przez całe wakacje nie nadawała się do publikacji, bo „działała za delikatnie i za luźno”. Dopiero dwa ostatnie testy (wersja 0.6b) utwierdziły mnie w przekonaniu, że „robię coś dobrze”.

To wszystko skutkowało u mnie utratą pewności siebie co do całego projektu gry „October Rust”. To rzutowało na promocję tej gry, a właściwie jej brak. Aż do września 2021 – czyli miesiąca przed wydaniem – nie byłem pewien, czy w ogóle dam radę z tej gry zrobić coś grywalnego…

Możecie sami spróbować „October Rust” na Itch.io lub DriveThruRPG.

Ten tekst powstał dzięki wsparciu: Jędrzej Śmietański, Michał Laskowski, Aleksandra Sontowska, Jakub Kucharzewski i Erpegowemu Piekiełku. Dziękuję!