» Blog » Punkty życia - grzech pierworodny
26-07-2013 09:37

Punkty życia - grzech pierworodny

W działach: rpg | Odsłony: 627

Punkty życia - grzech pierworodny

Czytając internety widziałem nieraz erpegowców borykających się z problemami, które są konsekwencją stosowania "Żywotności", "Kondyncji", "Hit Points" (czy innego odpowiednika tychże) a które można bez trudu rozwiązać zwyczajnie rezygnując z kontrolowania stanu życia postaci w oparciu o punkty.


Niektórzy są bardzo przywiązani do takiego rozwiązania, ale są też tacy, którzy po prostu nie pomyśleli, że można inaczej. Właśnie  tym drugim dedykuję ten wpis. Opiszę w nim mechanizm rozstrzygania walk (czy dowolnych innych konfliktów - tzw. conflict resolution) oparty o przewagi, który - mniej lub bardziej boleśnie - można zaimplementować do mechanik obecnych w wielu popularnych systemach.


Rozwiązanie jest mechaniczne, a jednocześnie w naturalny sposób pozostawia miejsce na opisy dowolnie niesamowitych akcji. Postaram się opisać koncepcję na takim poziomie ogólności, żeby uchwycić ideę, zamiast szczegółowych rozwiązań, które mogą być różne, dając nieco odmienne efekty. 
 

Całość wpisu na quodmeturbat.

Komentarze


Agrafka
   
Ocena:
0
Punkty życia w mojej drużynie - jeżeli powinieneś być martwy to jesteś, jeśli nie, to jeszcze żyjesz. Koniec.
26-07-2013 10:42
dzemeuksis
   
Ocena:
+1
No to fajnie, że nie masz z tym żadnych problemów. ;)
26-07-2013 10:51
Nuriel
   
Ocena:
+3
Punkty życia mają za to ten plus, że mogę odwzorowywać dosłownie wszystko.
Przez to, że są tak abstrakcyjnym narzędziem, można zignorować cały "realizm", "konsekwencje" i po prostu bawić się mechaniką.
Drużynowy wojownik stracił 10 hit pointów? Możesz opisać, że został lekko zraniony w rękę, uniknął wszystkich uderzeń wroga, przyjął cios uderzenia na klatę - cokolwiek.
Póki ma się hapeki, póty sie gra. Gameplay and story segregation w pełnej klasie ;)

Twoją propozycję można też uatrakcyjnić wprowadzając dynamiczny system zmiany "celów" pojedynku, np. żeby uzyskać przewagę do zabicia wroga trzeba mieć lepszy "wynik" niż do zranienia do pierwszej krwi,  do wytrącenia broni z ręki lepszy niż do sypnięcia piaskiem w oczy itd. 
26-07-2013 12:08
Aesandill
   
Ocena:
0
Ja też zrezygnowałe z hapeków choć mają swoją ogromną zalete. Tyle że jak wszystko, majaswoje wady. Rozpisze się później
26-07-2013 12:14
oddtail
   
Ocena:
0
Jak napisałem na docelowym blogu - nie używam zwykle mechaniki z HP. Ale tam, gdzie HP już sa i stanowią element szerszej całości, usuwanie HP to wylewanie dziecka z kąpielą (więc jak prowadzę Pathfindera, to HPki są i nic przy nich nie dłubię).

Obszerniejsze wyjaśnienia, o co mi chodzi zamieściłem na docelowym blogu, nie chce mi się chyba ich przeklejać (ani nie ma sensu).
26-07-2013 12:16
dzemeuksis
   
Ocena:
0
@Nuriel
Hej, ale "przewagi" równie dobrze pozwalają różne takie rzeczy opisywać a nawet lepiej, bo dają na to "mechaniczne przyzwolenie". A co drugiego akapitu Twojej wypowiedzi - ja to sobie dokładnie tak wyobrażam. Nie opisałem tego, żeby nie komplikować - chciałem przekazać samą ideę. W każdym razie tym razem. ;)

@Aesandill
Chętnie przeczytam

@oddtail
No i właśnie o to się chyba rozbiliśmy. Skoro sama idea poprawiania mechaniki jest Ci krzywa, to cokolwiek megawypaśnego w tym temacie bym nie zaproponował, to znajdziesz w tym głównie wady.
26-07-2013 12:30
oddtail
   
Ocena:
0
EDIT2: TL;DR - ja nie jestem przeciwny zmianom w regułach. Ja jestem przeciwny zmianom, które nie uwzględniają reguł, nie zastanawiają się nad konsekwencjami zmian i które ignorują design gry jako całości. To różnica.

@dzemeuksis: ja poprawiam i poprawiałem w przeszłości masę mechanik. Ale przebudowa domu to nie jest to samo co zburzenie ściany nośnej. Usunięcie HP w systemie zbudowanym w dużej mierze dookoła HP sprawia, że trzeba dodać reguły, regułki, wyjątki i uściślenia. Co, i tutaj bazuję właśnie na swoich doświadczeniach w house rule'ach, albo nie działa, albo i tak sprowadzi się do "MG zdecyduje" (a wtedy sami przyznajemy, że nie potrzebujemy mechaniki), albo wymaga więcej pracy niż ma sens, i kończy się uzyskaniem de facto własnej, w połowie napisanej mechaniki.

Tak, jak napisałem na Google+, jeszcze nie widziałem powodu, dla którego HP "nie działają". Podałeś jeden przykład, ja z tym przykładem się nie zgodziłem i to obszernie uargumentowałem, a Ty zasłaniasz się semantyką i wycofujesz się z nieprzekonującym mnie i wyglądającym mi na wykręt argumentem, że nie chcesz zajmować się szczegółami.

No więc właśnie w tym problem. Przy zmianach w mechanice diabeł tkwi właśnie w szczegółach. Wiem co mówię, bo house rules już wprowadzałem.

EDIT: a poza tym zamiast kasować HP można wprowadzić o wiele prostszą, i o wiele mniej niszczącą całość mechaniki regułę. HP nie są inherentnie złe. Można zmniejszyć albo zwiększyć ich ilość, można wprowadzić sytuacje, gdzie postać traci przytomność/ginie/otrzymuje karę do określonych działań niezależnie od HP, można wprowadzić dodatkowe akcje dające w walce "przewagę". I większość mechanik już takie opcje ma. Usunięcie HP powoduje konsekwencje we wszystkich innych regułach w najluźniejszy nawet sposób powiązanych z ranami czy innymi efektami, które symulują HP. Dodawanie house rule w taki sposób burzy cały design gry. W imię celów, których - ponownie, jak napisałem na Google+ - dalej nie rozumiem. Bo nie chcesz podać przykładów czy argumentów za wyższością takiej opcji.
26-07-2013 12:35
dzemeuksis
   
Ocena:
0
@oddtail

Ja jestem przeciwny zmianom, które nie uwzględniają reguł, nie zastanawiają się nad konsekwencjami zmian i które ignorują design gry jako całości.
Zgadzam się w całej rozciągłości. Czy ja gdzieś postulowałem coś takiego? Jak to się ma do mojej notki?

Usunięcie HP w systemie zbudowanym w dużej mierze dookoła HP sprawia, że trzeba dodać reguły, regułki, wyjątki i uściślenia
No to, jak pisałem, nie usuwaj. W czym problem?

Tak, jak napisałem na Google+, jeszcze nie widziałem powodu, dla którego HP "nie działają". 
Tak, jak pisałem wielokrotnie (nawet na początku samej notki), najwyraźniej tekst nie jest skierowany do Ciebie.

a Ty zasłaniasz się semantyką i wycofujesz się z nieprzekonującym mnie i wyglądającym mi na wykręt argumentem, że nie chcesz zajmować się szczegółami.
Zupełnie nie kumam o co chodzi. Znaczy się wykręciłem się już w trzecim akapicie notki, gdzie pisałem że to będzie ogólny opis idei? To co Ty robisz, to miotanie zarzutów wobec konkretnego rozwiązania. Tyle że notka nim nie jest i nie miała zamiaru do tego aspirować, co zaznaczyłem na jej początku.

Być może kiedyś opublikuję kompleksowe, szczegółowe rozwiązanie i wtedy Twoje uwagi będą bardzo na miejscu. Na razie dyskusja wygląda tak:
ja: Samochód to dobry sposób na przemieszczanie się.
oddtail: Nie jest dobry, bo pali dużo benzyny i mieści tylko 5 osób.

EDIT: a poza tym zamiast kasować HP (...) akcje dające w walce "przewagę".
No właśnie większość tak podchodzi do tego, tylko takie gmeranie zazwyczaj rodzi inne problemy, co widać śledząc dyskusje pod tego typu propozycjami. Mało się widzi takich koherentnych i dostarczających fun rozwiązań tego typu, jak zaproponowane gdzieś tam u Pafnucego przez SMG.

Usunięcie HP powoduje konsekwencje we wszystkich innych regułach w najluźniejszy nawet sposób powiązanych z ranami czy innymi efektami, które symulują HP. Dodawanie house rule w taki sposób burzy cały design gry.
Jeśli design gry rzeczywiście opiera się właśnie o HP, to tak, niech będzie że burzy. Tylko co z tego, jeśli będziemy zadowoleni z efektu?

W imię celów, których - ponownie, jak napisałem na Google+ - dalej nie rozumiem.
Jak pisałem, najwyraźniej tekst nie jest skierowany do Ciebie.

Bo nie chcesz podać przykładów czy argumentów za wyższością takiej opcji.
Nie rozumiem, nie kojarzę w którym momencie prosiłeś o przykłady, czy argumenty na wyższość takiej opcji. Zwłaszcza, że ja nigdzie o żadnej "wyższości" nie pisałem. Pisałem o alternatywie.
 
26-07-2013 13:16
oddtail
   
Ocena:
0
@dzemeuksis: czyli umieszczasz publicznie pomysł, a kiedy piszę że ten pomysł się nie sprawdza, bo A, B i C, piszesz że widocznie notka jest nie dla mnie? I że to ogólny opis, więc jest odporny (najwyraźniej) na wskazywanie zasadniczych problemów, jakie stwarza?

OK, przyjąłem komunikat. Z mojej strony EOT =)
26-07-2013 13:21
dzemeuksis
   
Ocena:
0
@oddtail

umieszczasz publicznie pomysł, a kiedy piszę że ten pomysł się nie sprawdza
Nie. Umieszczam publicznie ideę, która może być zaimplementowana na wiele sposobów. Ty zaś schodzisz na poziom konkretu, hipotetycznej, wyobrażonej sobie przez Ciebie implementacji (w mechanice, dodajmy, której nie znam) i mówisz, że to się tam nie sprawdza, czyli nigdzie się nie sprawdzi. Co ja mogę na to powiedzieć innego niż to, że ten problem najwyraźniej Cię nie dotyczy?

jest odporny (najwyraźniej) na wskazywanie zasadniczych problemów, jakie stwarza
W którym miejscu wskazałeś jakikolwiek zasadniczy problem, jaki proponowana idea stwarza, a ja się do tego nie odniosłem? Większość Twoich uwag jest na poziomie implementacji, wszędzie indziej starałem się odnieść.
26-07-2013 13:44
oddtail
   
Ocena:
0
Zasadniczym problemem jest zastąpienie jednego z mechanizmów mechanicznych zupełnie innym. Co w sposób w zasadzie nieunikniony wymagać będzie dodania wielu innych reguł i już na etapie koncepcji zaczyna z niewygodnego, niepraktycznego założenia.

Tak więc zasadniczy problem jest bardzo prosty: wprowadzenie tej koncepcji inherentnie prowadzi do zmian w mechanice większych, niż uzasadnia motywacja stojąca za zmianami. Albo innymi słowy - pomysł jest niepraktyczny, bo sprawienie by działał jest trudniejsze i mniej skuteczne niż inne decyzje (zmiana mechaniki na bardziej dla nas odpowiednią, całowita rezygnacja z mechaniki w określonych sytuacjach, wprowadzenie house rule do konkretnej sytuacji zamiast całej mechaniki).

I pisałem o tym tu i na G+ w sumie pewnie z 10 razy.

Tak, zilustrowałem problem na konkretnym przykładzie. Ale problem jest uniwersalny, co również wyjaśniałem najlepiej, jak byłem w stanie. Trudno mi bazować argumenty na platońskiej idei, dlatego odniosłem się do konkretnych problemów. I to też nie wszystkich, a jedynie przykładowych. I moja teza jest taka, że Twoją koncepcję da się wprowadzić albo przy negatywnych konsekwencjach niewartych zysków, albo wysiłkiem zupełnie niewspółmiernym do korzyści.

Żeby lepiej zilustrować: zdarzały mi się rozmowy o tym, że komunizm jest dobrym na papierze systemem, problemy są tylko z jego praktyczną realizacją. Moja argumentacja, że komunizm jest (wedle mojej wiedzy) systemem inherentnie niesprawiedliwym, niepraktycznym i niewartym poniesionych kosztów. Zamiast kontrargumentów większość takich rozmów kończyła się zarzutem, że ja mówię o detalach, a mój rozmówca o Idei.

Cóż, dla mnie w sytuacji, w której Idea rozbija się niemal natychmiast o konkrety, problem jest natury zasadniczej, a nie tylko leży w sferze realizacji. Jestem w stanie dyskutować z argumentami, nie jestem w stanie dyskutować z "komunizm jest super ogólnie, nie interesują mnie w tej chwili szczegóły". Komunizm jest nie-super jako zasadnicza idea właśnie dlatego, że nijak nie da się (moim zdaniem) wpasować w te pesky, annoying szczegóły realnej implementacji.
26-07-2013 13:54
dzemeuksis
   
Ocena:
0
I pisałem o tym tu i na G+ w sumie pewnie z 10 razy.
I ja na to z 10 razy odpisywałem, że w przypadku, kiedy taka sytuacja zachodzi nie warto stosować tego rozwiązania. I ja ci na to wiele razy odpisywałem, że osobiście, podobnie jak Ty, zamiast przerabiać mechanikę wolałbym zmienić całkiem. Mimo tego z uporem lepszej sprawy zdajesz się wmawiać, że rozwiązanie jest do bani w ogólności. Ok, Twoje prawo. Ale do tej pory nie padł bodaj żaden argument, który by na to wskazywał.

Cóż, dla mnie w sytuacji, w której Idea rozbija się niemal natychmiast o konkrety, problem jest natury zasadniczej, a nie tylko leży w sferze realizacji.
Rozumiem to. Dlaczego zatem nie wstrzymasz się z krytyką do czasu, gdy opublikuję jakąś konkretną implementację, o czym już gdzieś w początkach dyskusji wspominałem? Wtedy Twoje uwagi będą bardzo cenne i będziemy mogli pospierać się o konkrety. Cała para, która poszła w tę dyskusję, to para w gwizdek.

Słuchaj, oddtail. Znam Cię "dobrze" z Poltera i bardzo cenię Twoje uwagi. Dlatego głupio trochę, że mając tak ciekawe i tak rozbudowane przemyślenia w zakresie dostosowywania mechaniki uwzględniającej HP do systemu przewag, nie wstrzymałeś się po prostu z nimi do czasu, gdy powstanie konkret, na którym można je omówić. Albo nie spróbowałeś przenieść ich na poziom idei. Może by nam łatwiej poszło, gdybyśmy obaj znali mechanikę, której omawianie zaproponowałeś. A tak to mimo najszczerszych chęci nie mam jak się odnosić do sygnalizowanych problemów.

Jestem w stanie dyskutować z argumentami, nie jestem w stanie dyskutować z "komunizm jest super ogólnie, nie interesują mnie w tej chwili szczegóły"
Ja też. Nie dyskutuję w sposób, który sugerujesz. Przykro mi, jeśli tak to odebrałeś.
 
26-07-2013 14:07
oddtail
   
Ocena:
0
Padł niejeden argument za tym, że rozwiązanie jest do bani w ogólności. Argumenty oparte były o konkretne problemy z samą ideą. KAŻDA implementacja wyrzucenia HPków będzie wymagać wprowadzenia zmian wszystkich reguł związanych z HPkami albo ignorowania tych reguł. Z definicji.

I oczywiście, że odpowiednio dużo kombinując, uda się jakoś z tym problemem poradzić. Ale problem rodzi się na samym starcie, i to jest argument by albo od razu wskazać jakieś argumenty za dalszym analizowaniem idei, albo ją zarzucić.

Jeśli zaproponuję "wprowadźmy 99%-owy podatek dochodowy, bo jest dziura budżetowa", to spodziewać się należy krytyki tego rozwiązania już na samym starcie. I oczywiście, że mogę powiedzieć "poczekajcie, aż powstanie konkret, który będzie można omówić", ale już na starcie widać problem. Więc jeśli postuluję 99%-owy podatek bez argumentu, dlaczego to jest albo dobre, albo konieczne, to wygląda to słabo.

Oczywiście Twój pomysł nie jest aż tak jednoznacznie problematyczny jak 99%-owe podatki, ale problemy natury zasadniczej pojawiają się z nim już na starcie. Nie najmniejszym z nich jest to, że taki pomysł już wprowadzono w innych mechanikach niż te, które mają obecnie HP. Użyłeś, nie pamiętam czy na Polterze, czy na G+, analogii że Ty piszesz o tym że samochody są fajne, a ja na to że zużywają za dużo benzyny. Moja analogia jest raczej taka, że Ty proponujesz przerobienie motocykla na samochód. Nawet jeśli teoretycznie możliwe, to jest to nie dość że wyczyn inżynieryjny niebagatelnej skali, to jeszcze samochody już istnieją. Mozna jeździć motocyklem albo można jeździć samochodem. Ale lepiej zacząć korzystać z samochodu, niż przerobić swój motocykl na samochód. I czytanie "poczekaj tylko, aż zobaczysz mój projekt motocyklosamochodu" mnie nie przekonuje, bo taka przeróbka kosztuje, zapewne będzie miała wady konstrukcyjne, i jest droższa niż kupno nowego lub używanego samochodu. Mam dobre poowdy przypuszczać, że to słaby pomysł i istnieją lepsze rozwiązania.

Dlatego krytykuję pomysł, zanim zobaczyłem obiecywane konkretne implementacje.
26-07-2013 14:16
dzemeuksis
   
Ocena:
+1
KAŻDA implementacja wyrzucenia HPków będzie wymagać wprowadzenia zmian wszystkich reguł związanych z HPkami albo ignorowania tych reguł. Z definicji.

I to jest ten argument, że rozwiązanie jest do bani? Dla mnie to jest raczej powód, dla którego Tobie się nie podoba. Powód, który szanuję i rozumiem. To jest też wskazanie potencjalnych trudności, ryzyk. Bardzo cenne zresztą. Ale to nie argument, do którego mogę się odnieść inaczej, niż to robiłem, czyli "w pewnym przypadkach pewnie tak, w innych nie".

A co do motocykli/samochodów, proponowania przerabiania, etc. Podrzuciłem pomysł na takie zastosowanie tej idei przewag, bo wiele osób bardzo chętnie "łata" swoje mechaniki. O wiele mniej zdaje się być takich, którzy kochając jakiś system, realia, bez żalu odrzucą dedykowaną im mechanikę i sięgną po inną. Stąd podrzuciłem pomysł pójścia w tym kierunku w swoich "house rulesach". Sam jednak należę do tych, którzy wolą wywalić całkiem i użyć czegoś innego.
26-07-2013 14:25
oddtail
   
Ocena:
0
Tak, to jest argument że rozwiązanie jest słabe i problematyczne (to Ty użyłeś określenia "do bani"). Bo oznacza, że bardzo wiele reguł będzie trzeba zmienić. Wprowadzanie zmian w jakimkolwiek złożonym systemie powinno dokonywane być tak, by z jednej strony ingerencja była jak najmniejsza, z drugiej by zmiany były łatwe do przewidzenia i ogarnięcia. Tak się robi w przypadku programowania, inżynierii, również designu gier. Zmienia się jedną rzecz na raz. Nigdy nie zmienia się czegoś, co pociągnie za sobą trzy albo pięć albo dwadzieścia innych zmian. Bo każda z tych zmian będzie wymagała uwagi, i dalszych zmian. Tak to już działa przy zmienianiu stworzonych w określonym celu systemów. To jest, wedle mojej wiedzy, uniwersalna prawda w projektowaniu czegokolwiek, nieważne czy chodzi o szkic anatomiczny, geny muszki owocówki czy silnik samolotu.

Zmiana, którą proponujesz nie pozwala zmienić jednej rzeczy na raz. Zmienia całą masę niepowiązanych ze sobą reguł. Więc już na etapie idei robisz coś, co - wedle doświadczenia ludzi jako takich - jest kłopotliwe. I, powtórzę, kiedy chce się coś zmienić, warto powiedzieć, DLACZEGO chce się zmienić właśnie to, a nie coś zupełnie innego. Jeśli chcę coś poprawić w mechanice, mam jakiś powód. Ty jak dotąd nie podałeś konkretnego powodu. Jeśli nie definiujesz jednoznacznie problemu, to jak rozpoznasz, że (hipotetycznie) problem rozwiązałeś?

Ty skupiasz się na swoim pomyśle, a ja wskazuję, że powinieneś się najpierw skupić na problemie i szukaniu wydajnego rozwiązania problemu. Dlaczego Twoje rozwiązanie jest pożądane? Czytam Twoje komentarze i widzę odpowiedzi na moje zarzuty, ale konkretnego powodu, dla którego Twoje rozwiązanie jest pożądane nie widzę. A skoro nie ma takiego powodu, jak mam przyjąć, że warto aż tak ingerować w bardzo skomplikowany sposób w cały, rozbudowany system?
26-07-2013 14:30
dzemeuksis
   
Ocena:
0
@oddail

Ok, ok. Ale odnośnie
Wprowadzanie zmian w jakimkolwiek złożonym systemie
nie każda mechanika jest złożona. Mechanik WFRP, czy BRP bym tak nie określił. Spróbuję w przyszłości zaproponować implementację przewag w jednej z nich.

Odnośnie powodu, problemów, pisałem kilkukrotnie. Widziałem cuda-wianki, haki, łaty, przecudaczne interpretacje, wymuszone mechaniką fabularne absurdy w internecie i na żywo na sesjach wielokrotnie. Po prostu nie chce mi się przetrząsać internetu (ani zakamarków mózgu - spałem jakieś 4h dzisiaj) w poszukiwaniu tychże, bo po prostu ten, kogo to dotyczy, będzie wiedział. Zauważ, że jak rzuciłem tę ideę w wątku "Syndrom nagiego krasnoluda" u Pafnucego, to nikt się nie zdziwił. Nikt nie pytał, jak to się ma do tematu wątku. Nie wiem, może z grzeczności. Na pewno nie dlatego, że nikogo to nie obeszło, bo padło parę pytań.

Twój upór w tym względzie skłonił mnie jednak do refleksji, że może byłoby nie od rzeczy odgrzebać te przykładowe problemy i zrobić z tego osobną notkę. Mogłoby to być nawet ciekawe nie tylko jako uzasadnienie dla przewag, ale tak generalnie. Tylko wiesz, lista tych notek "na później" się robi coraz dłuższa... ;) 
26-07-2013 14:42
oddtail
   
Ocena:
0
Prosta mechanika to jest RISUS ;). Mówiąc "złożony", nie mam na myśli super skomplikowanego, tylko po prostu składający się z więcej niż 4-5 elementów, z licznymi powiązaniami między tymi elementami.

Nie pamiętam mechaniki WH, ale składa się ona z wielu reguł (na pewno więcej niż kilku), a między tymi regułami istnieje sieć powiązań. To wystarczy, by można ją było nazwać złożoną na potrzeby modyfikacji. Zresztą widziałem już modyfikacje reguł do WFRP (często pozornie zupełnie "niewinne", na pewno mniejsze niż całkowita rezygnacja z HP), które u niedoświadczonych zmieniających powodowały zupełnie nie przewidziane przez pomysłodawcę konsekwencje. Często nawet po zmianach te konsekwencje, mimo że wpływały na grę, w ogóle nie były zauwazone! Gracze zmieniali kolejne rzeczy, potem następne, potem dochodzili do wniosku, że z mechaniką jest coś nie tak. A czasem to był efekt zmiany czy rezygnacji z pewnej reguły bez świadomości, co to za sobą pociąga. Sam popełniłem taki błąd przy Deadlands Classic, i o mało nie popełniłem takiego błędu przy D&D - mimo, że zmiany wydawały mi się bez znaczenia. W pierwszym przypadku to, co psuła moja zmiana zauważyłem dosłownie po latach grania - choć przez te lata był problem z mechaniką, nie uświadamiałem sobie, że jest konsekwencją mojego głupiego house rule. W drugim na szczęście gracze wskazali konsekwencje zmiany, na które ja bym w życiu nie wpadł, a które były drastyczne - i okazało się, że proponowana zmiana jest BARDZO słabym pomysłem.

Poza tym proszę ponownie - zdefiniuj problem. Bo na razie to brzmi, jakbyś chciał usuwać HP, bo HP są złe. I to jest powód moich zastrzeżeń niemal od początku. Jeśli nie zdefiniujesz problemu oraz satysfakcjonującego Cię efektu końcowego, to wprowadzanie jakiejkolwiek zmiany zawsze będzie na zasadzie "bo poprzedni system jest zły". Problem z krasnoludem, który wskazałeś jako przykład da się rozwiązać (jeśli w ogóle potraktować go jako problem) na co najmniej pięć sposobów, które w minimalny tylko sposób zaingerują w inne zasady. Więc po co zmieniać cały, ważny element gry? Już na etapie "gramy bez HP" jestem w stanie wskazać na poczekaniu pięć sposobów, w jaki zasadniczo zmieni się walka. A każdy z tych sposobów coś zmieni w grze. Nawet GDYBY żadna reguła nie odnosiła się do HP. A co dopiero, jeśli są reguły które się odnoszą.
26-07-2013 14:49
dzemeuksis
   
Ocena:
0
Odnośnie pierwszego i drugiego akapitu. Będziesz miał być może w przyszłości okazję bezlitośnie wytknąć mi ewentualne niekonsekwencje, czy dziury, które powstaną na skutek implementacji przewag w wybranej przeze mnie mechanice. I wtedy powiesz: "A nie mówiłem!". A ja powiem: "No, mówiłeś...".

Poza tym proszę ponownie - zdefiniuj problem. Bo na razie to brzmi, jakbyś chciał usuwać HP, bo HP są złe.(..)Więc po co zmieniać cały, ważny element gry?

No to dopóki nie uda mi się skrobnąć notki na ten temat, to przyjmijmy właśnie takie założenie. HP są złe, bo są złe i dlatego je wywalam.

Można też nieco inaczej. Nie spotkałem jeszcze dotąd (ani mimo usilnych prób nie udało mi się wypracować) rozwiązania opartego ściśle na task resolution, które w satysfakcjonujący dla mnie sposób łączy przy rozstrzyganiu walki fun, prostotę i pseudo-realizm (tylko, błagam, nie rozwijajmy tego wątku), pozostawiając jednocześnie duże pole do popisu w kwestiach fabularnych. W moim przekonaniu jest to możliwe dopiero na poziomie conflict resolution. Stąd przewagi i stąd rezygnacja z HP, które stają się w tym momencie, IMHO, piątym kołem u wozu.

Ale zaprawdę, powody nie są istotne dla oceny efektów, ani korzyści jakie dają przewagi. Powody są istotne dla oszacowania stosunku kosztów do korzyści, dla oceny sensowności wprowadzenia przewag w danej sytuacji. Tyle że to już nawet nie jest tylko poziom implementacji, ale jeszcze dodatkowo poziom implementacji w konkretnej drużynie, mającej konkretne problemy.
26-07-2013 15:09
oddtail
   
Ocena:
0
"Ale zaprawdę, powody nie są istotne dla oceny efektów, ani korzyści jakie dają przewagi."

To właśnie jest problem. Wszyscy bez wyjątku designerzy udanych gier komputerowych, gier planszowych, modów do gier komputerowych, RPGów etc., których opinie i uwagi miałem okazję czytać lub słyszeć, zwracali uwagę, że przy tworzeniu dowolnej gry należy przede wszystkim stworzyć całość, która działa, bez niepotrzebnych elementów. Bazując na tym, że coś się "na czuja" podoba albo nie podoba ma się w zasadzie gwarancję, że efekt będzie niefajny.

HP istnieją nie bez powodu, i nie bez powodu są jednym z najpowszechniejszych mechanizmów w grach. Pojawiają się w zasadzie w każdym rodzaju gier - karcianych, planszowych, komputerowych niezależnie od gatunku, RPGach. Ich nieużycie w nowotworzonej grze to jedno, ale ich usuwanie z istniejącej gry musi być czymś podyktowane. Podobnie wprowadzenie nowego mechanizmu.

Argument, że chcesz by walka była oparta o rozstrzygnięcie konfliktu jest dobry, ale użyte przez Ciebie rozwiązanie tego nie zapewnia. Co więcej, walka oparta o conflict resolution nie jest w żadnym sensie niekompatybilna z HP. Jeśli zależy Ci, żeby walka zależała od przebiegu konfliktu, i chcesz pozostać w obrębie mechaniki konkretnego systemu, powinieneś raczej budować na tym, co system proponuje.

Ot, pierwszy z brzegu pomysł - ataki nie są wykonywane automatycznie, ale w zależności od przebiegu starcia, określone sytuacje pozwalają WYKONAĆ atak. Presto, mechanika jako taka jest zmieniona tylko w jednym punkcie (liczba ataków na rundę), i wszystkie konsekwencje zmiany (takie jak rzadsze zadawanie ataków, które przekłada się na dłuższą walkę) da się potencjalnie zrekompensować. Jednocześnie bezpośredniej potrzeby zmiany innych reguł z przyczyn innych niż balans nie ma.

Zmiana HPków na inny system nie daje po prostu takiego luksusu. Zmienić trzeba bardzo dużo. A to może mieć konsekwencje wykraczające nawet poza samą mechanikę walki. I co najważniejsze, na żadnym etapie nie ma gwarancji, że efekt końcowy będzie działał. Nie ma możliwości "testowania" pojedynczych zmian, bo od razu trzeba zmienić całkiem sporo.
26-07-2013 15:16
dzemeuksis
   
Ocena:
+1
przy tworzeniu dowolnej gry należy przede wszystkim stworzyć całość, która działa, bez niepotrzebnych elementów

Ależ ja się z tym zgadzam. Dlatego, jak pisałem, preferuję stworzenie własnej mechaniki, niż łatanie. Ale nie wszyscy tak mają. Niektórzy lubią łatać. I mają do tego pełne prawo.

HP istnieją nie bez powodu, i nie bez powodu są jednym z najpowszechniejszych mechanizmów w grach.

Po prawdzie to są spuścizną po bitewniakach. Niczym mniej, niczym więcej. Dla jednych coś ważnego, dla innych niepotrzebny balast.

Argument, że chcesz by walka była oparta o rozstrzygnięcie konfliktu jest dobry, ale użyte przez Ciebie rozwiązanie tego nie zapewnia.

Dlaczego? To może być ciekawa dziura w idei przewag, więc uzasadnij, proszę.

Co więcej, walka oparta o conflict resolution nie jest w żadnym sensie niekompatybilna z HP.

Może i nie jest. Ale też nie widzę potrzeby utrzymywania niepotrzebnego bytu. Jedną z najważniejszych reguł designerskich jest prostota, nie mnożenie bytów ponad potrzebę, wywalanie tego, co zbędne. Sam o tym pośrednio wspomniałeś.

Jeśli zależy Ci, żeby walka zależała od przebiegu konfliktu, i chcesz pozostać w obrębie mechaniki konkretnego systemu, powinieneś raczej budować na tym, co system proponuje.

Dlaczego powinienem?

Co do reszty. W przypadku takiej mechaniki, jak WFRP I ed., która wygląda, jakby została zaadoptowana z WFB bez głowy i bez testów, nie potrzeba testować pojedynczych zmian - ciężko zrobić większy burdel, niż ten który jest z jednej strony, z drugiej jest naprawdę mało złożona i nie ma aż tak wielu zależności, które naruszone mogłyby wywrócić system. Wystarczy potestować samą walkę, reszta się dotrze w konsekwencji. To nie projekt informatyczny, tu specyfika jest nieco inna.
26-07-2013 15:39

Komentowanie dostępne jest po zalogowaniu.