Wszystko działało. Budujesz osadę, zbierasz drewno i kamień, stawiasz mur, przeżywasz noce, wygrywasz albo przegrywasz. Pętla domknięta od początku do końca. Usiadłem, zagrałem pełną rozgrywkę i musiałem powiedzieć sobie coś, czego nie chciałem powiedzieć.
Nie mam z tego frajdy. Brakuje tu strategii. Wystarczy postawić zamek na wzgórzu, naspamować budynków, zrobić pełny mur na szczycie i na przejściu. Wyzwanie się kończy.
To był chyba najgorszy dzień tego projektu i jednocześnie najbardziej potrzebny. Dwa tygodnie pracy, dziesiątki modeli, mgła, światło, ekonomia. I wszystko to złożyło się w coś, w co nie chce się grać.
Pierwszy odruch był zły
Pierwsza myśl przy takim zdaniu brzmi: za łatwo, trzeba dodać wrogów. Warto wiedzieć, dlaczego to jest zły odruch, bo jest bardzo naturalny.
Problem nie polegał na tym, że gra była za łatwa. Polegał na tym, że gra zadawała graczowi jedno pytanie, a to pytanie miało jedną odpowiedź. Całe zagrożenie zbiegało się w jeden punkt na mapie, którego teren i tak już bronił. Poza murem nic nie było zagrożone, więc nic poza murem nie wymagało decyzji.
Podkręcenie liczby wrogów zmieniłoby liczbę, a nie pytanie. Odpowiedź dalej brzmiałaby „postaw mur w tym samym miejscu, tylko grubszy”.
Ile decyzji podejmuje gracz w trakcie partii? Jedną: gdzie postawić mur. I to koniec. Każdy pozostały „wybór” (który budynek, ilu chłopów, kiedy) miał jedną oczywiście najlepszą odpowiedź, więc nie był wyborem.
Winowajca siedział tam, gdzie nie szukałem
Źródłem problemu okazał się generator mapy.
Mapa miała pierścień gór otaczający osadę, z jednym przejściem. Brzmi jak świetna mapa obronna. W praktyce była mapą, która rozwiązuje się sama. Skoro jest jedno przejście, to jedyna sensowna rzecz to zamknąć jedno przejście. Zbudowałem grę, która odrabiała za gracza jego własną pracę.
Poprawka nie polegała na dodaniu wrogów, tylko na zmianie geografii. Bariera obronna przestała być jednym pierścieniem i stała się pięcioma do ośmiu osobnymi masywami na różnych odległościach od centrum. Między nimi są doliny. Nikt ich nie wycina, one po prostu są, i jest ich kilka.
Ten sam błąd co przy mgle, tylko w innym przebraniu
Miałem sondę sprawdzającą teren. Pokazywała, że jest dobrze. Pokazywała to również dla mapy, którą sam nazwałem symetrycznym okręgiem, bo mierzyła wyłącznie koszt domknięcia obrony, czyli ile kafli muru trzeba postawić. Okrąg i pięć masywów mogą mieć ten sam koszt domknięcia i zupełnie inną grę.
Sonda dostała dwie nowe miary: odchylenie promienia bariery (okrąg ma około zera, próg to sześć) oraz liczbę osobnych masywów (ciągły wał to jeden masyw, czyli porażka).
| Miara | Wynik na pięciu mapach |
|---|---|
| koszt domknięcia | 52-97 kafli |
| odchylenie promienia | 9,0-10,8 przy progu 6,0 |
| osobne masywy | 5-7 zamiast jednego |
Fala, która przestała iść w jedno miejsce
Druga zmiana dotyczyła wrogów. Wcześniej cała nocna fala szła na rdzeń osady. Teraz dzieli się według wartości celu i tego, jak bardzo cel jest niebroniony, z losowym rozrzutem plus minus trzydzieści procent.
Doszły dwa ograniczenia, które wyglądają na drobiazg, a robią całą robotę: sufit dwudziestu dwóch procent sił na jeden cel poboczny, żeby przystań nie była równana z ziemią co noc, oraz karencja dla celu bitego poprzedniej nocy.
I rzecz, która okazała się ważniejsza od samego rozkładu sił: zapowiedź liczona w dzień jest tym samym, co wykona się w nocy. To, co interfejs pokazuje o zmierzchu, jest dokładnie tym, co się stanie. Bez tego rozkład sił byłby losowością, a nie decyzją. Różnica między „nie wiem, co się stanie” a „wiem i muszę wybrać” to cała gra.
Przy okazji: wrogowie rodzili się wewnątrz bazy
Testowa fala pojawiała się w odległości trzydziestu sześciu jednostek od centrum, co po zmianie terenu wypadało w środku pierścienia masywów. A kiedy trafiała na zablokowane pole, kod dosuwał wroga ku centrum. Czyli prosto do wioski.
To ten typ błędu, który nie jest błędem w kodzie. Kod robił dokładnie to, co napisano. Tylko założenie, że trzydzieści sześć to „na zewnątrz”, przestało być prawdziwe dwa tygodnie wcześniej, kiedy zmieniła się mapa. I nikt tego nie zauważył, bo nikt nie zapisał, że takie założenie w ogóle istnieje.
Gdzie jestem dzisiaj
| Miara | Wartość |
|---|---|
| zapisów historii | 170 |
| linii kodu | 31 435 |
| plików modeli | 361 |
| testów | 30 |
| klatek na sekundę | 160+ |
Liczby, które wyglądają dobrze i nie odpowiadają na pytanie, czy w to się chce grać.
I to jest właściwie sedno tego wpisu. Wszystkie powyższe liczby były prawdziwe dokładnie tego dnia, w którym stwierdziłem, że nie mam z tego frajdy. Żaden z tych wskaźników nie mierzy gry. Mierzą projekt.
Bardzo łatwo pomylić jedno z drugim, zwłaszcza gdy pracujesz sam i codziennie widzisz, jak przybywa. Przybywanie jest przyjemne. Przybywanie nie jest tym samym co posuwanie się do przodu.
Co bym powiedział sobie sprzed tygodnia. Kiedy gra jest nudna, nie dodawaj trudności. Policz, ile różnych pytań zadaje graczowi i ile z nich ma więcej niż jedną sensowną odpowiedź. Jeśli odpowiedź brzmi „jedno”, trudność niczego nie naprawi.
W następnym wpisie: jak wygląda praca nad grą, kiedy kod pisze agent AI. Łącznie z tym, co się dzieje, gdy po trzech tygodniach masz dwadzieścia jeden dokumentów, z których każdy twierdzi, że to on jest tym właściwym.