To wychodzi z symulacji zarządzania z rdzeniem działającym bez sceny, kampanią na cztery do pięciu lat i 1624 testami automatycznymi. Piętnaście z nich robi coś, czego pozostałe 1609 nie potrafi: gra w tę grę.
Lukę, którą zamykają, przeoczyłem. Miałem komplet zielonych testów, podczas gdy gra była po cichu niegrywalna, i nic w tych testach nie było błędne. Każda reguła robiła to, co deklarowała. Reguły razem nie składały się na grę.
MonoBehaviour.Update, ten artykuł jest
najpierw argumentem za jej wydzieleniem, a dopiero potem za testowaniem.
Dlaczego test jednostkowy nie widzi balansu
Test jednostkowy pyta, czy reguła zachowuje się poprawnie. Balans nie jest właściwością żadnej reguły. Jest właściwością wszystkich naraz, działających przez cztery lata, czyli mieszka w miejscu, w które żaden test jednostkowy nie zagląda.
Komentarz na górze mojego pliku z testami grywalności to najkrótsza wersja tego problemu, jaką udało mi się napisać:
Więc ten plik w nią gra. Nie próbkowane przybliżenie rozgrywki, nie model statystyczny rozgrywki — prawdziwa kampania, wewnątrz testu, jeden symulowany dzień po drugim, ze skryptowanym graczem podejmującym decyzje, które podejmowałby człowiek.
Bot jest podłogą, nie sufitem
Pierwszy odruch to zrobić bota dobrym. Ten odruch jest błędny i marnuje całe ćwiczenie, bo bot, który gra dobrze, mówi ci wyłącznie, że ekspert umie wygrać. Nikt o to nie pytał.
Mój jest celowo przeciętny i tak jest napisane:
Cała jego pętla decyzyjna to dziesięć prostych kroków w stałej kolejności, powtarzanych każdego symulowanego dnia. Żadnego przeszukiwania, żadnej funkcji oceny, nic, czego gracz grający pierwszy raz nie zrobiłby, czytając ekran przed sobą:
Ta zwyczajność jest tym, co nadaje asercji znaczenie. Gdy ten gracz bankrutuje, zły jest balans, a nie gracz, i nie ma o czym dyskutować w kwestii tego, czy istniała lepsza strategia. Test podłogi czyta się wtedy dokładnie tak, jak brzmi:
Sprawdzaj przedział, a nie liczbę
Tu jest błąd, którego szukałem najdłużej, i ten, który naprawiłbym pierwszy w cudzym projekcie: test balansu z samą dolną granicą gnije po cichu.
Każda łatka czyni grę odrobinę hojniejszą. Nowy węzeł badań, przeliczona cena, poprawka błędu, która przy okazji usunęła koszt. Każda zmiana z osobna jest do obrony, test podłogi przechodzi coraz wygodniej, nic nigdy nie zapala się na czerwono. Kończysz z grą, której nikt nie umie przegrać, i z zestawem testów, który jest z tego dumny.
Lekarstwem jest zapisanie również sufitu. Komentarz przy moim opisuje tryb awarii w obie strony i to jest fragment wart skopiowania, nawet jeśli nie weźmiesz z tego artykułu nic innego:
W praktyce to cztery górne granice stojące obok dolnych:
Czytaj asercje jak decyzje projektowe, bo nimi są
„Cztery lata nie mogą wystarczyć na skończenie drzewa technologii” nie jest stwierdzeniem technicznym. To decyzja o tym, czym jest gra, zapisana w miejscu, w którym będzie egzekwowana — a to więcej, niż osiąga większość dokumentów projektowych.
To okazuje się cichą korzyścią z całego podejścia. Testy balansu stały się jedynym miejscem, gdzie moje intencje co do trudności są zapisane w formie, która potrafi się odszczeknąć.
Przypadek kontrolny: dowód, że granie ma znaczenie
Każdy dotychczasowy test może przejść w grze, w której twoje decyzje są dekoracją. Gra, która gra się sama, też jest wypłacalna, też coś wydaje, też jest zielona. Żeby to wyłapać, potrzebujesz eksperymentu, którego uczą na każdej lekcji przyrody i którego prawie żaden zestaw testów nie zawiera: kontroli.
Dwie kampanie, to samo ziarno. W jednej bot gra porządnie. W drugiej ktoś wydaje jedną rzecz i przez cztery lata nie robi zupełnie nic:
To + 10.0 waży więcej niż sam kierunek. „Lepiej niż nic nie robić”
to poprzeczka, którą przechodzi gra idle. Duży zapas to twierdzenie, że uwaga jest
nagradzana, i to jest różnica między symulacją a zabawką.
Ten sam kształt się uogólnia, a gdy raz go zobaczysz, napiszesz cztery kolejne. Czy
zbieranie kapitału faktycznie ma znaczenie? Porównaj przebieg z finansowaniem i bez. Czy
architektura odblokowana w trzecim roku jest naprawdę lepsza od tej, z której powstała?
Uruchom obie i sprawdź, że nowa wygrywa. Mam jeden nazwany
AHouseFamilyBeatsTheDenseBaselineItWasBuiltFrom, czyli zdanie o projektowaniu
przebrane za test.
Pytanie, które zadaje każdy oblany test balansu
Teraz część niewygodna i powód, dla którego chciałem napisać ten artykuł, a nie jego uładzoną wersję.
Gdy test balansu zapala się na czerwono, masz dwa ruchy. Możesz zmienić grę albo zrobić bota mądrzejszym. Oba dają zielony zestaw i oba wyglądają w diffie mniej więcej tak samo, a uczciwy jest tylko jeden — z tym że nie zawsze ten sam, i to czyni rzecz naprawdę trudną, a nie tylko kuszącą.
Trafiłem na to, gdy strona usługowa mojej symulacji zaczęła się przewracać. Naprawą było pozwolenie botowi ruszyć suwak, który dotąd ignorował. Oto, co napisałem obok, bo nie ufałem sobie, że zapamiętam, dlaczego było to dozwolone:
To ostatnie zdanie jest regułą, którą teraz stosuję, i da się ją odpalić na sobie: czy gracz patrzący pierwszy raz na ten ekran zrobiłby to? Jeśli tak, douczanie bota jest modelowaniem rzeczywistości i test robi się uczciwszy, a nie mniej uczciwy. Jeśli kontrolka istnieje tylko w teście, jeśli bot dostaje informacje niedostępne graczowi albo jeśli liczby są podkręcane, aż przejdzie — już nie testujesz gry, tylko z nią negocjujesz.
Dwa szczegóły z tego komentarza warte zabrania
„Klaster wykonywał sto siedemdziesiąt procent własnej pracy.” To jest prawdziwy błąd i żaden test jednostkowy nie mógł go zobaczyć: każdy przydział z osobna był poprawny, po prostu połowy nie musiały się sumować. Do wyjścia na wierzch potrzeba było bota grającego przez pięć lat.
„Co ten operator robił przez pięć lat, nie zauważając.” Po naprawieniu błędu stała się osiągalna nowa, uprawniona awaria: firma może teraz zagłodzić własnych klientów. Naprawa błędu w symulacji nie zmniejsza powierzchni do testowania. Zwykle ją poszerza.
Oblany test balansu ma opisywać grę, a nie liczbę
Oblany test jednostkowy mówi ci, że funkcja jest zła, i idziesz przeczytać funkcję. Oblany test balansu mówi, że firma zbankrutowała w trzecim roku, a to samo w sobie jest prawie bezużyteczne, bo przyczyna leży gdzieś w 1095 symulowanych dniach.
Dlatego każda asercja w tych testach niesie ze sobą migawkę świata:
Różnica jest taka jak między półgodziną bisekcji a przeczytaniem jednej linijki. Awaria, która mówi share 94%, research 31/31, gotówka ogromna, to gra, która zrobiła się za łatwa. Awaria, która mówi models 1, gotówka ujemna, rounds 0, to gracz, który nigdy nie wystartował. Ten sam czerwony test, odwrotne problemy, a napis mówi ci który, zanim cokolwiek otworzysz.
Najtańsza poprawka w całym tym artykule
Jeśli masz już testy balansu i chcesz jednej poprawy dziś wieczorem, to jest właśnie ta. Wstaw pięć czy sześć liczb opisujących stan gry do każdego komunikatu asercji w tym pliku. Kosztuje cztery linijki i zmienia to, co znaczy czerwony build.
Bot musi być bezstanowy, a to nie jest oczywiste
Jedno ograniczenie łapie każdego raz, mnie też, i pojawia się dopiero, gdy połączysz testy balansu z testami zapisu — a powinieneś, bo zapis, który po cichu zmienia kampanię, jest błędem balansu, który podróżuje.
Test brzmi: zagraj cztery lata, zapisz, wczytaj, zagraj piąty rok i sprawdź, czy wczytany przebieg zgadza się z tym, który nigdy nie zapisywał. W chwili, gdy to napiszesz, bot dostaje regułę, której wcześniej nie miał. Cokolwiek bot pamięta we własnym polu, jest stanem, którego nie ma w pliku zapisu, więc wczytany przebieg się rozjedzie — a test obwini symulację za różnicę, którą stworzył sam plik testowy.
Reguła brzmi więc: każda decyzja bota ma wynikać ze stanu symulacji, nigdy z czegoś, co bot nosi ze sobą. To ta sama dyscyplina, która w ogóle czyni kampanię powtarzalną, czyli temat siostrzanego artykułu o deterministycznym losowaniu — i warto zauważyć, że to ograniczenie przychodzi ze strony, z której nikt nie ostrzega.
Ile to kosztuje, uczciwie
To nie są tanie testy i udawanie czegoś innego byłoby dokładnie tym rodzajem porady, przed którym ta strona ma bronić.
| Koszt | Jak to wygląda naprawdę |
|---|---|
| Czas wykonania | Każdy z nich rozgrywa od 1460 do 1826 symulowanych dni, kilka z nich dwukrotnie dla porównania. To zdecydowanie najwolniejsze testy w całym zestawie. |
| Utrzymanie | Realne. Według mojego własnego licznika w kodzie ten plik musiał być uczony korzystania z kontrolki, którą wyhodowała gra, trzy osobne razy — sufit parametrów, linia produktowa i biurko obsługi. Każdy nowy system widoczny dla gracza to możliwe nowe zachowanie bota. |
| Osąd | Ten się nie zmniejsza. Każdy czerwony test pyta, czy naprawiasz grę, czy douczasz bota, i żadne narzędzie nie odpowie za ciebie. |
Po drugiej stronie: piętnaście testów pokrywa pytanie „czy to nadal jest gra”, chodzą przy każdej zmianie i znalazły klaster wykonujący sto siedemdziesiąt procent własnej pracy. Zapłaciłbym za ten czas wykonania drugi raz.
Od czego zacząć, jeśli nie masz nic z tego
W kolejności, w której napisałbym je ponownie:
- Podłoga. Zwyczajny bot rozgrywa pełną kampanię i nie bankrutuje. Jeden test, i obleje za pierwszym uruchomieniem.
- Kontrola. To samo ziarno rozegrane biernie, z asercją, że aktywny przebieg wygrywa z dużym zapasem. To ten, który dowodzi, że twoja gra jest grą.
- Sufit. Dodawaj górne granice do testu podłogi, aż opisze przedział. Zapisz decyzję projektową w komunikacie asercji.
- Zapis. Graj, zapisz, wczytaj, graj dalej, sprawdź, czy oba przebiegi się zgadzają. Licz się z tym, że bot będzie musiał stać się bezstanowy.
- Napisy kontekstowe. Cztery linijki, i każda przyszła awaria tłumaczy się sama.
Dwa pierwsze to jeden wieczór i w nich siedzi prawie cała wartość. Reszta to doszlifowanie.
Pytania, które ludzie zadają
Czy da się testować balans gry testami jednostkowymi?
Zwykłymi nie. Test jednostkowy pyta, czy reguła zachowuje się poprawnie, a balans nie jest właściwością żadnej pojedynczej reguły — jest właściwością wszystkich naraz, działających przez długi czas. Działa skryptowany gracz z celowo przeciętną strategią, który rozgrywa pełną kampanię wewnątrz testu, po czym sprawdzasz stan, do którego doszedł. Symulacja może być idealnie spójna na poziomie każdej reguły i zupełnie niegrywalna jako gra.
Jak dobry powinien być bot?
Celowo przeciętny. Istnieje po to, żeby wyznaczyć podłogę, a nie sufit: bez patrzenia w przód, bez sprytnego wyczucia czasu, bez informacji, których nie miałby gracz grający pierwszy raz. Wtedy asercja czyta się jako jeśli ten gracz nie przeżyje, to zły jest balans, a nie gracz. Bot nastrojony na grę optymalną mówi tylko, że ekspert umie wygrać, a o to nikt nie pytał.
Co powinien sprawdzać test balansu?
Przedział, obustronny. Jedna strona mówi, że grę da się przeżyć; druga, że nie jest trywialna — gracz nie powinien być wygodnie przed stawką, nie powinien mieć trzech czwartych rynku, nie powinien skończyć drzewa technologii. Test z samą dolną granicą po cichu zielenieje, gdy gra dryfuje w stronę łatwiejszej, i to najczęstszy sposób, w jaki balans gnije niezauważony.
Gdy test balansu oblewa, naprawiasz grę czy bota?
To prawdziwe pytanie, a diff wygląda tak samo w obu przypadkach. Douczenie bota jest uprawnione, gdy gra wyhodowała kontrolkę, której człowiek oczywiście by użył: modelujesz gracza, który widzi suwak. Jest nieuczciwe, gdy kontrolka istnieje tylko w teście, gdy bot dostaje informacje niedostępne graczowi albo gdy stroisz go, aż liczba przejdzie. Użyteczny sprawdzian: czy gracz patrzący pierwszy raz na ten ekran zrobiłby to samo?
Jak udowodnić, że dobra gra ma znaczenie?
Przypadkiem kontrolnym, którego większość projektów nie ma. Dwie kampanie z tego samego ziarna: jedna rozegrana porządnie, druga wydaje jedną rzecz i przez cztery lata nie robi nic. Sprawdź, że aktywna wygrywa z dużym zapasem. Bez tego wszystkie pozostałe asercje mogą przechodzić w grze, w której decyzje są dekoracją.
Czy to zastępuje playtesty z ludźmi?
Nie i nie ma takiego zamiaru. Pokrywa dokładnie jedno pytanie — czy liczby składają się na grę, którą da się wygrać i da się przegrać — i pokrywa je przy każdej zmianie, czego nie zrobi żaden człowiek. Wszystko o tym, czy gra jest ciekawa, czy ekrany mają sens i czy decyzja czuje się jak decyzja, wymaga ludzi. Kupujesz to, że ludzie przestają zużywać swoją sesję na odkrywanie, że trzeci rok jest niemożliwy.
PlayabilityTests.cs, podlinkowanym w źródłach tego artykułu. Cytowane tu
komentarze są prawdziwe, nie wygładzone na potrzeby tekstu.