GamesFanatic.pl Gry planszowe, karciane, recenzje, felietony, nowości ze świata.
Ten rozdział dedykuję szczególnie sobie, mam spore problemy z robieniem dokumentacji, ale po kolei.
Rozdział 7
Zapiski znalezione w wannie czyli po co komu dokumentacja?
Czytelnicy Świata Gier Planszowych mogli zapoznać się z wywiadem jaki udało mi się przeprowadzić w ubiegłym roku z Wolfgangiem Kramerem. Właśnie u tego genialnego autora mogłem zapoznać się z profesjonalnie prowadzoną dokumentacją. Każda testowa rozgrywka miała swój opis, czasami na kilka stron. Wszystkie one wydrukowane i zapakowane do skoroszytu, a tych jak można się domyśleć nie było mało. Można zadać sobie pytanie, po co on to robi? Odpowiedź jest prosta.
Wyobraźmy sobie pracę nad jedną grą, powstaje prototyp, zaczęliśmy pierwsze rozgrywki, pierwsze testy. Okazuje się że gra zaczyna działać, ale ma pewne problemy, niedociągnięcia które trzeba naprawić. Z testów wynika że rozwiązaniem może być zmiana zasobów, albo liczby pól na planszy, albo licytacji. Wiemy (prawdopodobnie) jaki jest problem, zaczynamy naprawę. Pierwsza, druga rozgrywka, wydaje się że problem jest gdzieś pośrodku. Prowadzimy kolejne partie, kolejne zmiany, w pewnym momencie wydaje nam się że lepiej było powrócić do jednej z wcześniejszych wersji. Jedna gra, to nie problem, w końcu jeszcze nie atakuje nas ten Niemiec… jak mu było… Alzheimer?
A co gdy gier przez nas projektowanych jest więcej i przy każdej coś zmieniamy? U mnie to normalna sytuacja, nie lubię pracować nad jednym tytułem, obecnie mam 3 na wysokim poziomie pracy i kilka lekko traktowanych. Muszę pamiętać co gdzie zmienić, jakie w danym tytule pojawiają się problemy. Z tymi nad którymi pracuję częściej nie mam jeszcze problemów, ale z odkładanymi… jest nie najlepiej. Niestety ciężko mi robić dokumentację do prototypów, brakuje mi czasu i chęci. To źle, wiem o tym bo często pojawia mi się jakiś pomysł na rozwiązanie problemu, nie mam czasu go sprawdzić, potem zapominam i pozostaje tylko irytacja. W pewnym momencie zacząłem prowadzić zapiski, ale z czasem…
Projekt gry Sojuz
W bieżącym roku rozegrałem przeszło 90 partii w gry niepublikowane. Z tego kilka nie było moich. To sporo, nie prowadzę ich dokładnej dokumentacji, ale mam pewne zapiski… pytanie czego pełne powinny dotyczyć…
Jest kilka informacji które pomogą nam w dobrym przetestowaniu gry, poniżej ich krótki opis:
Numer testu – informacja istotna dla nas, czasami dobrze wiedzieć że 10 rozgrywka doprowadziła do pozbycia się wszystkich problemów… a czasami można się zirytować że po 30 partiach problem jest dalej ten sam.
Data i miejsce – dane mało istotne, miejsce czasami może dać nam informację, że gra rozegrana np. na Pionku musi być liczona bardziej ulgowo, bo była zbyt zabawna atmosfera itp.
Uczestnicy – kto brał udział w testach jest bardzo istotne. To informacja o grupie docelowej, o tym kto jak się bawi.
Cel gry – wydawało by się że takie pole jest bez sensu, a jednak. Cel może się zmienić, czasami jest to związane ze zmianą w grze, a czasami ze znalezieniem rozwiązania problemu.
Uwagi i problemy – najlepiej uwagi swoje i innych graczy. Oni mają często bardziej świeży wgląd na daną sprawę.
Proponowane rozwiązanie problemu – to zapiski, przemyślenia, czasami nie istotne, a czasami to perełki które kiedyś w przyszłości mogą się przydać. Czasami wpadnie nam coś do głowy, a po jakimś czasie wyleci… warto to zapisać.
Kto wygrał i jak – bardzo ważna informacja. Raz – informuje czy dany gracz, znający lepiej grę ma przewagę, dwa – o ile wygrał gracz, jaką ilością punktów. Te statystyki mogą zmienić warunki punktacji, zmienić cel gry…
Czas gry – gra nie powinna być za długa ani za krótka… oczywiście dla grupy docelowej :-)
Tyle pokrótce o prowadzeniu dokumentacji. To lekcja którą ciągle przerabiam, zadanie które jest przede mną, jeśli chcę projektować gry profesjonalnie.
Prowadzenie dokumentacji jest nudne, ale warto traktować je poważnie – przydaje się bardzo.
No i znowu fajny opis co i jak. I bardzo trafny.
Dzięki – czekam na kolejne… i dłuższe ;)
Testowanie gry można podzielić na dwa podstawowe etapy:
1. Testowanie mechaniki
2. Testowanie instrukcji
Jak rozumiem, autor skupił się tu raczej na pierwszym etapie. Dobór uczestników testu nie tylko służy do sprawdzenia kto jak się bawi. Najlepiej do testów dobierać osoby kreatywne, a może wręcz destruktywne, które przez swoje nieszablonowe podejście do rozgrywki potrafią ujawnić ewentualne dziury w mechanice
Masz racje Michale, następny odcinek będzie poświęcony instrukcjom… myślałem że dam radę publikować oba… ale niestety pobyt w Warszawie mnie wykończył ;-)
No to szkoda wielka, że o instrukcjach dopiero za tydzień, bo ja się właśnie od tygodnia męczę nad jedną;) Ale cóż, będę mógł porównać swoje błędy z poradnikowym wzorcem.
A tak w ogóle to wielkie dzieki Adamie za ten cykl. Czytając go cieszę się że pewne rzeczy o projektowaniu gier już wiem bo sam do nich doszedłem metodą prób i błędów i uczę się sporo nowych, zaczynam myśleć o pewnych elementach projektowania inaczej. Dzięki. Wiem już że następną grę będę robił nieco inaczej.
Dzięki Michale za radę. Swoją grę właśnie chciałem rzucić na jeszcze jeden etap testów z nieplanszówkowiczami. Teraz widzę że przydałyby sie jeszcze testy z destruktorami;)
Tylko Filip nie przesadzaj z tymi destruktorami, bo brutalna prawda jest taka, że każdą, nawet najlepszą mechanikę, da się totalnie zepsuć graniem irracjonalnym, nazwijmy to „niezgodnie z duchem gry”. Takie np. Puerto Rico – perełka balansu – i gracz, który ciągle bierze jedną rolę – Craftsmana – demoluje i niszczy wszystko – a gra jest bez sensu.
To samo z graczem, który wybierze sobie w osadnikach miejsca tak, produkują mu się tylko owce na jednym polu i kamień na drugim – bo brzeg morza lub pustynia.
Można i tak testować, tylko wartość poznawcza takich ćwiczeń jest dość marna.
Święta racja baronie. Każdą grę da się zepsuć przy złych intencjach. Myślę jednak że bardziej chodzi tu o testowanie z graczami którzy bywają nieobliczalni i mogą próbować szalonych na pozór strategii, lub zagrań, a nie o takich którzy chcą zepsuć grę.
@BloodyBaron – ja przy takich okazjach zawsze przytaczam przykład Blue Moon City. W tej grze gracze zbierają kryształki i budują z nich wielki obelisk. Kryształki otrzymuje się na dwa sposoby – za odbudowę miasta i za zebrane smocze łuski (otrzymywane gdy wezwie się do pomocy smoka). Kryształki za smocze łuski otrzymuje się po wyczerpaniu przez graczy pewnej ich puli, która jest w grze.
Otóż grając w dwie osoby postanowiłem zepsuć tę grę. W ogóle ignorowałem smoki, radziłem sobie bez nich. Za wszelką cenę unikałem zbierania smoczych łusek, żeby nie doprowadzić do ich punktowania albo to punktowanie opóźnić jak najbardziej. Wobec tego miasto zostało całkowicie odbudowane, ale nie uzyskano warunku zwycięstwa – żaden z graczy nie zbudował sześciu segmentów obelisku.
Myślałem, że udało się zepsuć grę. Mój szalony pomysł żeby całkowicie zignorować potężne źródło punktów w Blue Moon City spowodował że nie da się wyłonić zwycięzcy. Jednak gdy dokładniej przyjrzałem się instrukcji okazało się, że Herr Doktor przewidział taką sytuację i umieścił w instrukcji akapit mówiący co się dzieje w takiej sytuacji. Jak widać, jeśli do testowania podchodzi się skrupulatnie, można (przynajmniej w niektórych grach) przewidzieć niemal wszystko. Muszę powiedzieć, że ten epizod bardzo zwiększył mój szacunek dla BMC i dla gier Knizii w ogóle. Dodam jeszcze, że ten akapit nie załapał się do żadnych skrótów zasad czy tłumaczeń reguł jakie widziałem na BGG, widocznie osoby tłumaczące uznały go za zbędny lub mało istotny.
:)
a właśnie – bo to Herr Doktor – facet, który ma kilka grup testerów, przepuszcza swe gry setki razy przez gęste sito, a będąc matematykiem z praktyką w bankowości zawodowo specjalizował się w budowaniu scenariuszy testowych i dokumentowaniu wyników stress testów.
Czy ktoś jeszcze zbudował sobie podobną maszynkę do ćwiczenia prototypów? :)
Jeszcze nie, ale pracuję nad tym :)))))
@ja_n: świetny przykład. Właśnie o coś takiego mi chodziło. Gra powinna być „odporna” na takie destrukcyjne strategie. Niestety, nie wszyscy autorzy zdają sobie z tego sprawę i nie zawsze potrafią przewidzieć, jakie pomysły mogą mieć gracze.
Pewnie jeszcze to przypomnę… dla mnie projektowanie gier jest bardzo podobne do projektowania aplikacji… tym bardziej że zajmuję się jednym i drugim ;-)
W przypadku programów często próbuje się stworzyć takie… idiotoodporne… ale jest to zadanie nie dla normalnego człowieka ;-)
Z grami jest chyba podobnie, do pewnego stopnia na pewno da się to zrobić, ale czasami gdy gracz nie chce grać w grę i będzie robił wszystko żeby ją zepsuć… to raczej mu się uda. Nie zawsze, ale czasami… a jak nie uda mu się zepsuć samej gry, to zepsuje zabawę innym :(