18.6.12

Niektóre błędy mechanik (nie tylko) autorskich

Nikt nie jest nieomylny. Miałem okazję niejednokrotnie się o tym przekonać między innymi przy okazji czytania systemów autorskich. Większość z nich zawiera jakieś mniejsze lub większe błędy. Niektóre z nich powtarzają się częściej, inne są zupełnie wyjątkowe. Kilka z nich chciałbym przytoczyć przy okazji marudząc na temat niejednoznaczności, sprzeczności i niejasności jakie pojawiają się w mechanikach autorskich.
Najlepiej odwoływać się do przykładu, który jest czytelnikowi dobrze znany. Korzystając z okazji jaka nadarzyła się po publikacji w poprzednim numerze Wieży Snów artykułu pt. System 10 pozwolę sobie na tym przykładzie wskazać, niektóre z błędów popełnianych przez twórców.

System 10 jest mechaniką ciekawą, choćby ze względu na eleganckie powiązanie w testach umiejętności i cech. Zgodnie z podstawowymi założeniami (dwie pierwsze tabele) im wyższa wartość cechy lub umiejętności, tym większe możliwości naszej postaci. Łatwość każdego testu w tej mechanice jest sumą dwóch współczynników. Zależnie od sytuacji są to odpowiednio umiejętności lub cechy.

Do tego fragmentu zapoznając się z mechaniką nie miałem zastrzeżeń, merytorycznych. Dopiero informacja odnośnie modyfikatorów łatwości wywołała u mnie niepokój. Modyfikatory te mają być ujemne, gdy coś nam sprzyja, a dodatnie, gdy przeszkadza. Oznaczałoby to, że łatwość maleje w sprzyjających warunkach! Wczytując się niezwykle uważnie w ten fragment mechaniki, dostrzegłem jednak możliwą przyczynę nieścisłości. Modyfikator ma dotyczyć "wyniku". Nie jest co prawda wprost napisane, że chodzi o wynik rzutu, ale taka właśnie interpretacja reguł byłaby zgodna z logiką.

W osłupienie wprawił mnie jeden z kolejnych akapitów, mówiący o tym, że zerowa wartość łatwości oznacza 100% szansę powodzenia. Tym samym upadł mój wcześniejszy wniosek, że im wyższa łatwość, tym większe prawdopodobieństwo sukcesu. Skąd więc u licha taka nazwa, na ten parametr?

Kolejna dezorientacja przyszła po podczas czytania przykładu. Tu okazuje się, że ciemność daje w teście modyfikator "-2" do łatwości, choć wcześniej czytaliśmy, że utrudnienia (a tak chyba należy traktować ciemność) dają modyfikatory dodatnie.

Kolejną ciekawostką jest informacja, że aby uzyskać sukces w teście należy wyrzucić na kości k20 więcej niż wynosi łatwość. W praktyce oznacza to, że im większa jest łatwość testu tym mniejsze szanse powodzenia (to już druga taka przesłanka). Lepiej widać to na przykładzie. Załóżmy, że MG ustalił stopień łatwości testu na 15. Do zdania testu wystarcza więc, że wyrzucimy 16, 17, 18, 19 lub 20. Mamy więc 25% szans na powodzenie. Dla łatwości testu wynoszącej 5, szansa powodzenia wynosiłaby 75%. Jest to o tyle niezrozumiałe, że łatwość rośnie wraz ze wzrostem umiejętności i cech. Wyraźnie widać, że coś tu jest nie tak.

Kolejnym mankamentem (to już opinia czysto subiektywna) Systemu 10 jest zaproponowany sposób rozsądzania tzw. konfrontacji (test sporny / przeciwstawny). Autor wyraźnie stara się doprowadzić do sytuacji, gdy powodzenie akcji rozstrzygane jest pojedynczym rzutem testowym gracza. Niestety przyjęte w drugim sposobie założenia wymagają i tak dwóch rzutów, a na dodatek konieczne jest użycie niestandardowej (innej niż normalnie w tym systemie, bo trudno k10 uznać za niezwykłą w RPG) kości. Osobiście za lepsze rozwiązanie uważam równoczesne rzuty testowe przeciwników przeciwko odpowiednim łatwościom i porównanie tzw. marginesów sukcesu.

Margines sukcesu to nic innego jak różnica pomiędzy uzyskanym wynikiem, a granicznym wynikiem dającym sukces. W teście spornym zwycięża ten, kto uzyska wyższy margines sukcesu lub w przypadku remisu, ma wyższe współczynniki bazowe.

Najwyższy czas, żebym wskazał popełnione błędy i zaproponował środki zaradcze.

1.) Odwrócenie szans

Problem:
Im wyższe mamy współczynniki tym mniejsze szanse na uzyskanie sukcesu.

Rozwiązanie:
Warunkiem sukcesu powinno być wyrzucenie na k20 wartości mniejszej od łatwości

2.) Odwrócone i nie doprecyzowane modyfikatory

Problem:
Zapis dotyczący modyfikatorów nie mówi wystarczająco jednoznacznie, czy modyfikowana jest łatwość, czy wynik rzutu. Ponadto odwrócono znak przy modyfikatorach - modyfikator ułatwiający zmniejsza łatwość testu, a tym samym szanse jego powodzenia.

Rozwiązanie:
Zapis precyzuje, że modyfikacja dotyczy łatwości, a wynik rzutu uzyskany na kości nie jest w żaden sposób zmieniany. Ułatwienia zwiększają łatwość (modyfikator dodatni), a utrudnienia ją zmniejszają (modyfikator ujemny).

3.) Nie jednoznaczne przykłady

Problem:
Zasady mówią, że utrudnienie zwiększa łatwość, a z przykładów wynika, że jest odwrotnie.

Rozwiązanie:
Pod warunkiem zastosowania rozwiązań opisanych powyżej, przykładów nie musimy zmieniać.

System 10 nie ustrzegł się błędów i nie jest to sytuacja wyjątkowa. Jako ciekawostkę przedstawię teraz zauważony przeze mnie mankament wczesnej, testowej wersji mechaniki pewnego komercyjnego systemu. Na początek stosowny fragment, który miał znaleźć się w podręczniku.

Testowanie umiejętności polega na wykonaniu rzutu na zmodyfikowaną (przez premię z cech i modyfikator trudności) wielkość odpowiedniej umiejętności. W przypadku wyrzucenia na k20 tej samej lub mniejszej liczby, czynność uznaje się za pomyślnie wykonaną. W przypadku, gdy czynność dotyczy innej postaci i ma ona szansę się w jakiś sposób przeciwstawić (np. test spostrzegawczości przy próbie kradzieży), należy wykonać dodatkowy test dla odpowiedniej kontrumiejętności zmodyfikowanej o różnicę pomiędzy "atakującym" a "broniącym się".

Przykład

Władek chce okraść na targu kupca. Jego umiejętność (z uwzględnieniem odpowiednich modyfikatorów) kradzieży wynosi 8. Na kości wypada 7, a więc test się powiódł. Następnie sprawdzamy, czy sprzedawca coś zauważył. Ponieważ jest on bardzo spostrzegawczy (spostrzegawczość 12) otrzymuje on premię równą co do wielkości:

7-12=-5

A zatem modyfikujemy spostrzegawczość sprzedawcy według poniższej formuły:

12-(-5)=17

Wniosek jest bardzo prosty. Postaci, która nie jest jeszcze zbyt dobra w fachu złodziejskim będzie bardzo ciężko okraść doświadczonego kupca. Jeśli jednak kradzież byłaby dobrze zaplanowana (i opisana przez gracza!), Pan Losu mógłby zastosować ujemny modyfikator do spostrzegawczości sprzedawcy, co zwiększyłoby szansę powodzenia kradzieży.

Z pozoru nic nadzwyczajnego w powyższym fragmencie nie drzemie. Wykonujemy rzut k20 i jeśli wynik znalazł się poniżej pewnej wartości odnosimy sukces. Pułapka drzemie w dalszej części opisanej procedury. Konieczny jest jeszcze test umiejętności dla drugiej postaci. To często spotykana sytuacja, ale w tym wypadku ze względu na zaproponowany modyfikator w zależności od cech obu bohaterów absolutnie nie do przyjęcia. Pokaże to następująca analiza.

Zgodnie z prezentowanym przykładem prawdopodobieństwo wykrycia "poprawnie wykonanej" kradzieży przez kupca wynosi 17/20 (85%). A co jeśli jednak odwrócimy sytuację i to kupiec jest "atakującym" (wypatruje złodzieja), a nie "broniącym"? Ile wyniesie prawdopodobieństwo ukrycia kradzieży przed kupieckimi oczyma pilnie obserwującymi? Niech kupiec również wyrzuci 7.

7-8=-1,

8-(-1)=9.

Złodziej ma 45% szans na ukrycie kradzieży.

Gdyby kupiec wyrzucił 10 (nadal zdaje test), wtedy szanse złodziej zmalałyby do 30%. Minimalna wartość szansy przy udanym rzucie kupca (k20=12) wynosi 20%, a maksymalna 75%. Przy podejściu prezentowanym w oryginalnym przykładzie odpowiednie wartości wynosiłyby 0% i 20%. Widać tu wyraźnie, że opłaca się "bronić", a nie "atakować". Na dodatek im niższą liczbę oczek wyrzucimy na kości we własnym teście, tym większą premię uzyska przeciwnik!

Na szczęście nie zawsze do mechaniki wkradają się tak poważne błędy. O wiele częściej są to drobne niedociągnięcia, które mogą nieco utrudniać życie. Tym razem jako przykład posłużą Kryształy Czasu.

W zasadach dotyczących walki mamy do czynienia z tzw. Rzeczywistą Szansą Trafienia (RTR). Jest to różnica Szansy Trafienia (TR) atakującego i Obrony (OB) przeciwnika. Atak uważa się za udany jeśli wynik rzutu k100 jest mniejszy, bądź równy RTR. Jak widać do obliczenia tego współczynnika potrzebna jest znajomość po jednym z parametrów dwóch postaci. W praktyce oznacza to, że gdy MG poda graczowi jego RTR dla konkretnego przeciwnika, to ten bez trudu obliczy jeden z parametrów swojego wroga i będzie znał swoje szanse w walce już w jej pierwszych sekundach. Nie jest to jednak, wbrew pozorom, błąd mechaniki, a jedynie jej opisu. Wystarczy zastosować metodę już dano wymyśloną przez miłośników tego systemu, aby bez zmieniania głównych reguł uniknąć takiej sytuacji. Do zagadnienie podejdźmy na początek matematycznie. Warunkiem udanego ataku jest:

TR - OB >= k100

Teraz wystarczy zwykłe przekształcenie i otrzymujemy:

TR - k100 >= OB

Te same reguły możemy więc zapisać w inny sposób:

Testując powodzenie ataku wykonujemy rzut k100 i wynik odejmujemy od naszego współczynnika Szansa Trafienia, uzyskując maksymalną wartość Obrony przeciwnika dla jakiej nasz cios dosięgnął celu.

Ogólne reguły nie uległy zmianie, ale przy takim ich sformułowaniu to gracz po wykonaniu rzutu informuje MG "trafiłem w 35" (np. TR = 78, k100 = 43), a ten jedynie określa, czy oznacza to udany atak, czy nie. W naszym przykładzie dla broniącego się bohatera o Obronie równej 35 lub mniej wynik rzutu oznaczałby kłopoty.

Posłużyłem się zaledwie trzema przykładami w celu pokazania najczęstszych typów błędów w mechanikach. W pierwszym wypadku (System 10) była to niejednoznaczność zasad i wewnętrzne sprzeczności wynikające ze złego sformułowania ich opisu, w drugim (wczesna wersja mechaniki pewnego komercyjnego systemu) błędy merytoryczne skutkujące różną interpretacją tych samych reguł w zależności od sytuacji, a w trzecim (Kryształy Czasu) takie sformułowanie reguł, że umożliwiały graczom poznanie informacji poufnych, choć można było tego w prosty sposób uniknąć.

Większość tego typu błędów można łatwo wychwycić i wyeliminować podczas playtestów przeprowadzanych przez graczy (koniecznie) nie uczestniczących w tworzeniu systemu. Jest to o tyle ważne, że osoba, która wcześniej nie zetknęła się z daną mechaniką bez trudu wyłapie wszelkie niespójności w jej opisie. Później wystarczy jedynie poważnie potraktować i odpowiednio uwzględnić w ostatecznej wersji mechaniki zgłoszone przez nich uwagi.

Pozostaje mi życzyć wszystkim twórcom aby ich mechaniki były bezbłędne, oraz miłej i owocnej pracy.

Brak komentarzy:

Prześlij komentarz

Uwaga: tylko uczestnik tego bloga może przesyłać komentarze.