241009 - Kontrola czasu na sesji pomaga w ochronie akcji graczy #
Spis Treści #
Akcje szybkie i wolne i kontrola czasu chronią działania i możliwości graczy. Do tego pomagają w zarządzaniu spotlightem. Bonus - Tory jako zarządzanie Agendami.
- 1 - Przykład fikcyjny z sesji
- 2 - Odzwierciedlenie w świecie rzeczywistym
- 3 - Modelowanie tego w EZ
- 4 - Podsumowując
1. Przykład fikcyjny z sesji #
- Sytuacja
- Kto: trójka graczy: Ania, Bartek, Celina
- Grają:
- Ania gra doświadczoną programistką. Bartek i Celina grają niedoświadczonymi programistami.
- Dla uproszczenia, załóżmy, że inne umiejętności nie mają znaczenia.
- Zadanie:
- Co: Stworzyć aplikację mającą umożliwić otworzyć drzwi do bunkra
- Kroki: Programowanie, testowanie, programowanie, testowanie.
- Problem:
- Postać Ani jest lepsza we wszystkim od Postaci Bartka i Postaci Celiny.
- Nie ma kontroli niszy, nie ma w sumie niczego co zabezpiecza Anię przed zrobieniem wszystkich konfliktów i przejściu przez sesję sama.
- Jak to się najpewniej potoczy:
- Każdy test będzie wykonywany przez Anię.
- Bartek i Celina są statystami na tej sesji. Może dorzucą Ani jakiś pomysł jako wkład?
- Jak powinno być:
- Każdy gracz ma możliwość wniesienia czegoś wartościowego do sesji.
- Każda postać ma wartość na sesji.
Oczywiście, to powyższe jest bardzo fikcyjne i syntetyczne (gracze to nie automaty); ale nawet w takim wypadku da się to sensownie i łatwo rozwiązać.
2. Odzwierciedlenie w świecie rzeczywistym #
Mamy typowy projekt w firmie informatycznej. Ten projekt ma, załóżmy:
- 3 doświadczonych programistów C#
- 2 niedoświadczonych programistów C#
Czemu w ogóle mieć niedoświadczonych programistów, skoro doświadczeni są "lepsi" i pracują szybciej i lepiej? (jak powyżej, pomijam różnice związane z niszami i specjalizacjami)
Bo programowanie zajmuje czas. Przykład (bardzo uproszczone liczby i koncepty):
Chcemy napisać Discordowego bota, który pozwoli na używanie mechaniki z linii poleceń
- Backend: 160 (jednostki pracy)
- Postawienie serwera, certyfikaty itp: 10
- Napisanie aplikacji która bierze "Tr Z+3" i zwraca "(V) + (5V 3Vz 3Vr 7X Xz)": 150
- Frontend: 50 (jednostki pracy)
- Research 'jak to robić': 10
- Odpowiednia integracja z Discordem: 40
I teraz załóżmy, że doświadczony programista dostarcza 10 jednostek pracy / h a niedoświadczony 2.5 jednostek pracy / h
- 1 Doświadczony Programista potrzebuje: 210/10 = 21 godzin
- 3 Doświadczonych Programistów potrzebuje: 210/30 = 7 godzin
- 1 Niedoświadczony Programista potrzebuje: 210/2.5 = 84 godziny
- 3 Doświadczonych i 2 Niedoświadczonych potrzebuje: 210/35 = 6 godzin
Oczywiście, nie uwzględniłem problemu koordynacji ludzi, różnych specjalizacji, tego że ktoś się na czymś nie zna, nieoznaczoności itp. To duże uproszczenie, ale wystarczy na nasze potrzeby.
Jak widać:
- Dla projektu, w którym nie trzeba nikomu pomagać, każda osoba się może przydać i coś wnieść.
- Nawet osoby, które są mniej przydatne nadal coś wnoszą.
- Kluczem jest niewidoczny element - czas.
3. Modelowanie tego w EZ #
3.1. Wniosek całościowy #
Po raz kolejny odpowiedź na większość pytań z mechaniki i sesji kryje się w analogicznej sytuacji ze świata rzeczywistego.
Inna analogia - gry komputerowe. Np, Heroes of Might and Magic V:
- Każda jednostka się rusza zgodnie ze swoją inicjatywą
- Np. chłopi mają niską inicjatywę, więc ruszają się raz (pozycja 4 na pasku) a łucznicy są szybsi, ruszają się częściej (pozycja 3, pozycja przedostatnia)
Ważne jest to, że tak warto o tym myśleć. Kiedy się rusza gracz jest zależne od tego jak długo zajmuje jego akcja. Jeśli mamy jedną zaawansowaną postać która może "wszystko", ciekawym problemem jest to, na czym się skupi a gdzie pójdą działać inne postacie.
I teraz rozłóżmy to na składowe.
3.2. Istnieje czas #
- Każda akcja trwa określoną ilość czasu.
- Jeśli Ania robi X, to w tym samym czasie Bartek i Celina mogą zrobić coś co trwa tyle samo co X.
- To, że Ania mogłaby "wszystko zrobić sama" nie oznacza, że Ania wszystko zrobi sama.
- Ania, Bartek i Celina wspólnie osiągną więcej niż Ania sama. Mimo, że Ania jest lepsza.
3.3. Akcje dzielimy na szybkie i wolne #
Co ważne, PRĘDKOŚĆ akcji niekoniecznie jest skorelowana z jej stopniem trudności.
- "Jadę z Lublina do Poznania" to akcja wolna. Kilka godzin. Jednocześnie to akcja, która nie wymaga testu - nic nie może tam się popsuć.
- "Wykorzystuję wózek widłowy do przesunięcia drzewa z drogi" to akcja szybka. Poniżej godziny. Jednocześnie to akcja Trudna - tu może sporo rzeczy się nie udać.
Istotne jest też to, że akcje "szybkie" i "wolne" są relatywne do siebie.
- Podczas walki / sytuacji filmu akcji, akcja "szybka" może zająć kilka - kilkanaście sekund a "wolna" może zająć 30 sekund - 1 minutę.
- Podczas sytuacji normalnej, akcja "szybka" może zająć 30-60 min a "wolna" może zająć 1-4 h.
- Podczas sytuacji budowania projektu (np. rozbudowa arkologii), akcja "szybka" może zająć 1-2 dni a "wolna" około tygodnia
Można zawsze powiedzieć "robię to szybciej / wolniej" by dostać Przewagę lub Niedowagę. Niekoniecznie zmieni to "wolną" w "szybką" (i vice versa), ale jest to jeden z mechanizmów by gracze mogli robić więcej jeśli jeden robi więcej akcji szybkich a ktoś inny wolnych.
Tu jest zawsze ogromny problem z balansem [realizmu i dawania wszystkim graczom akcji] kontra [jedna silna postać robi wszystko co ważne]. Więc nie ma twardej reguły "na 3 szybkie akcje jest 1 wolna", bo to przesunie spotlight w świecie rzeczywistym bardzo daleko od jednego gracza, tego, który robi te wolne akcje.
Z drugiej strony tak można modelować coś w stylu: "ok, ja przygotowuję się do wysadzenia tego statku, osłaniajcie mnie". Wszyscy mają swoje miejsce a porażki powiązane z osłanianiem utrudnią test na wysadzanie statku.
3.4. Czas możemy modelować "po prostu" lub przez Tory #
3.4.1. Wariant prosty i oczywisty #
MG może po prostu zrobić tak:
- Na każdą 1 wolną akcję przypadają 2 szybkie. Zwykle.
Lub wykorzystać mechanizm Torów, który pokazałem przy przykładzie z Athamarein:
Można też zadziałać inaczej. Można zrobić taki zbiór heurystyk; jest to mniej więcej podobne do tego jak ja czasem prowadzę:
- Krótka akcja to zwykle '1' czasu
- Długa / wolna akcja to zwykle '3' czasu
- Zmiana lokacji to zwykle '1' czasu
- Gracz nie może być wyłączony z akcji przez 30 minut czasu rzeczywistego
("zwykle", bo np. zmiana pokoju nie powinno kosztować dużo czasu a krótka akcja krótkiej akcji nierówna)
3.4.2. Wariant wolny, precyzyjny i dokładny #
Można też po wprowadzeniu takich heurystyk jak wcześniej, dla czystości zachowania czasu i inicjatywy - można ustawić postacie graczy na Torach (tego nie robię, za dużo czasu i buchalterii):
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | |
---|---|---|---|---|---|---|---|---|---|---|---|
Ania | |||||||||||
Bartek | |||||||||||
Celina | |||||||||||
Inwestorzy | (żądają spotkania) | (żądają prototypu na '9') | |||||||||
Ruina | (coś się dzieje) | (problem z licencją na X) | (...) |
Wtedy jesteście w stanie sobie rozpisać krok po kroku kto jest gdzie. Jest to bardzo precyzyjna metoda i może zadziałać bardzo dobrze, ale zwykle nie ma konieczności robienia tak dokładnego zejścia w głąb każdej sceny i sytuacji. Zostawiam Wam to pro forma, nie dlatego, że to rekomenduję.
Zauważcie, że to jest dokładnie to samo co Heroes of Might and Magic 5
które pokazałem Wam wcześniej. Dokładnie to samo:
Więc... w zależności od tego, czego Wam potrzeba, tak to zamodelujcie.
3.4.3. Co rekomenduję? #
Ta heurystyka co wcześniej:
- Krótka akcja to zwykle '1' czasu
- Długa / wolna akcja to zwykle '3' czasu
- Zmiana lokacji to zwykle '1' czasu
- Gracz nie może być wyłączony z akcji przez 30 minut czasu rzeczywistego
("zwykle", bo np. zmiana pokoju nie powinno kosztować dużo czasu a krótka akcja krótkiej akcji nierówna)
I mniej więcej trzymanie się tego powyżej, bo każdy gracz musi móc COŚ zrobić. Do tego dodam jeszcze rekomendację, by różne osoby robiły czasem wolne czasem szybkie akcje; to się wtedy zrównoważy.
3.5. Agendy też możemy modelować przez Tory #
Tory można też wykorzystać do kontrolowania sesji i flow sesji - co robią różne strony. Wtedy nie patrzymy na to z perspektywy "czasu taktycznego" (która tura jest teraz) a "czasu strategicznego" (co która strona teraz zamierza zrobić). Czyli - zarządzamy ruchami i Agendami używając Torów. A mechanizmem przesuwającym gdzie jesteśmy (mniej więcej) jest wtedy czas rzeczywisty; sprawdza się na konwentach, gdzie jest limit czasowy:
Oczywiście, jeśli coś się wydarzy co zmienia Agendę jednej ze stron, to ta strona zmieni swój cel. Ale warto mieć to na początku sesji by zobaczyć Default Future.
3.6. Nagle ciekawym problemem jest to, kto skupia się na czym. #
Ania gra najlepszą programistką. Weteranką.
- Czy wysłać ją na spotkanie z Inwestorami? Przyniesie pieniądze, ale... wtedy nie programuje.
- Czy wysłać ją na rozwiązanie problemu licencji na bibliotekę? Zrobi to dobrze, ale nie robi innych rzeczy - a jak ktoś inny, może trzeba będzie przerabiać.
- A może niech ona buduje główny produkt, a te "inne" rzeczy zrzucić Bartkowi i Celinie?
Bartek i Celina nadal są w stanie się skupić i dostarczyć inne rzeczy, ale trudniej. Może spróbują zrobić research (poświęcą więcej czasu, ale dostaną Przewagi)? Dostarczą mniej, ale wyższej jakości i mniej trzeba po nich naprawiać? A może trzeba zrobić "coś, co jakkolwiek wygląda i jakkolwiek się trzyma", ale pozwoli na zarobienie pierwszych pieniędzy?
Nagle Zespół ma ciekawe decyzje.
I nie chodzi tylko o projekty programistyczne - np. odbudowa arkologii, walka ze smokiem... wszystkie te tematy wchodzą w tą samą pulę problemów. Jak długo wprowadzimy czas jako ważny czynnik.
4. Podsumowując #
- Czas ma znaczenie i bardzo wzbogaca sesję
- Nawet mniej kompetentne postacie zaczynają się bardzo przydawać, bo mogą robić coś innego niż najsilniejsza postać
- Zespół dostaje ciekawe decyzje - co próbujemy uzyskać, bo przecież nie wszystko zdążymy
- Czasem da się zarządzać na różne sposoby
- Heurystyka wynikająca z zasad, Tory
- Akcje szybkie i wolne
- Chcemy, by wszyscy Gracze "coś" wartościowego robili na sesji, więc musimy równoważyć prędkość akcji ilościem spotlighta na Gracza (nie na postać - na Gracza)