Kategoria: Devlog

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.

Najdroższa rzecz, jaką zrobiłem w tym projekcie, działała poprawnie za każdym razem. Test przechodził, zrzuty wyglądały dobrze, liczby się zgadzały. A efekt był zły i nie umiałem powiedzieć dlaczego. Sześcioma podejściami zapłaciłem za jeden błąd, którego nie widać w żadnym logu.

Co miało być

Gra dzieje się w cyklu dnia i nocy. W dzień budujesz osadę, w nocy przychodzą po ciebie. Żeby noc była straszna, a nie po prostu ciemniejsza, potrzebowałem mgły. Takiej, która zakrywa horyzont, zbiera się w dolinach i sprawia, że widzisz dokładnie tyle, ile sobie oświetlisz.

Rozwiązanie techniczne było oczywiste: mgła objętościowa liczona w programie karty graficznej, metodą krokowego marszu promienia przez przestrzeń. Napisałem to. Zadziałało. I tu się zaczyna właściwa historia.

Test, który sam siebie potwierdzał

Żeby nie oceniać mgły na oko, zrobiłem sondę. Program liczy na procesorze dokładnie ten sam marsz promienia, który wykonuje karta graficzna, i porównuje przezroczystość w ustalonych punktach sceny. To dobre narzędzie i korzystam z niego do dziś.

Problem polegał na czymś innym. Sonda mierzyła widoczność struktury kłębów mgły, a ja przez trzy podejścia poprawiałem właśnie widoczność struktury kłębów. Świeciła na zielono za każdym razem, bo mierzyła dokładnie to, co optymalizowałem.

Optymalizowanie złej metryki potrafi samo siebie potwierdzać. Im lepszy masz pomiar, tym pewniej idziesz w złą stronę.

A chodziło o coś zupełnie innego. Nie o strukturę mgły. O to, żeby było czuć noc. Tego zdania nie da się zmierzyć, więc nigdy nie zostało zapisane jako kryterium. I dlatego przez sześć podejść zgadywałem, gdzie ono leży.

To była moja wina i to konkretna. Nie usiadłem na początku i nie powiedziałem, na którym obrazku mgła jest już dobra. Uznałem, że będę wiedział, jak zobaczę. Nie wiedziałem.

Podejście	Jak zawiodło
1	za słaba
2	jedzie z kamerą
3	płaska z bliska
4	brązowa plama
5	znika przy zbliżeniu
6	odrzucona

Techniczne dno tej historii

Tu robi się bardziej szczegółowo, ale to jest część, którą warto znać, jeśli sam robisz coś podobnego. Jeśli nie, przeskocz do następnego nagłówka, nic nie stracisz.

Trzy przyczyny udające jedną

Objaw brzmiał: „mgła jest płaska przy zbliżeniu”. Miał trzy niezależne przyczyny jednocześnie. Każda z osobna wyglądała jak zbyt słaby szum. Poprawienie jednej nie dawało żadnej widocznej zmiany, więc za każdym razem wyciągałem wniosek, że cały kierunek jest zły, i zaczynałem od zera.

To pułapka, która działa nie tylko w grafice. Kiedy poprawka nie daje efektu, pierwsza myśl brzmi „źle zdiagnozowałem”. Często prawidłowa jest „zdiagnozowałem jedną z trzech”.

Błąd, którego żaden zrzut nie mógł pokazać

Mgła dostała strefę czystą wokół kamery, żeby gracz widział własną osadę. Strefa liczona była od kamery, więc jechała razem z nią. Przy przybliżeniu obejmowała cały kadr i mgła po prostu znikała.

Zrobiłem kilkadziesiąt zrzutów weryfikacyjnych. Żaden tego nie pokazał, bo zrzut to stopklatka, a to był problem ruchu. Widać go dopiero, kiedy siedzisz przy grze i kręcisz kamerą.

Stopklatka nie ocenia ruchu. Zrzut nie pokaże paralaksy, dryfu z kamerą ani migotania. Trzy najczęstsze sposoby, w jakie efekt potrafi być zły.

Czym to się skończyło

Mgła objętościowa została odrzucona. Działa, jest w kodzie i nie jest używana. Zastąpiłem ją prostszą mgłą wysokościową plus mechaniką światła. Bo okazało się, że ciemność jest groźna nie dlatego, że jest gęsta, tylko dlatego, że coś w niej jest.

I to jest chyba najważniejsza rzecz, którą wyniosłem z tamtego tygodnia. Przez sześć podejść próbowałem rozwiązać problem graficzny. Rozwiązanie okazało się projektowe: zamiast robić ciemność ładniejszą, dałem jej znaczenie w rozgrywce.

Co zostało warte zachowania

Sześć podejść nie poszło całkiem na marne. Zostały dwie rzeczy.

Po pierwsze, sam pomysł sondy liczbowej. Zła metryka to nie jest argument przeciwko mierzeniu. To argument przeciwko mierzeniu bez ustalenia, co ma być mierzone.

Po drugie, i to okazało się cenniejsze, zapisanie powodu odrzucenia. Odrzucony pomysł leży w projekcie razem z opisem, co konkretnie zawiodło i czego nie próbować ponownie. Bez tego za dwa miesiące zrobiłbym mgłę objętościową siódmy raz, bo przecież brzmi świetnie.

Liczba	Co znaczy
6	podejść do mgły objętościowej
40+	zrzutów weryfikacyjnych
0	z nich pokazało prawdziwy błąd

Co bym powiedział sobie sprzed tygodnia. Ustal kryterium na konkretnym obrazku referencyjnym, zanim napiszesz pierwszą linijkę. Test, który mierzy nie to, o co chodzi, jest gorszy niż brak testu, bo daje fałszywą pewność.

---

W następnym wpisie: gra była skończona, działała od początku do końca, i usłyszałem zdanie, które skasowało połowę moich planów. Powiedziałem je sobie sam.

Od lat robię filmy o tym, jak używać AI do pracy. W pewnym momencie zorientowałem się, że mówię ludziom, co da się zbudować, ale sam nie zbudowałem niczego, co byłoby naprawdę trudne. Więc postanowiłem zrobić grę. Nie prototyp na weekend, tylko coś, w co dałoby się grać.

Nie programuję w Rust. Nie robiłem wcześniej gry 3D. Miałem pomysł, który towarzyszy mi od dawna: osada, którą budujesz w dzień, i noc, która przychodzi po ciebie. Coś w klimacie Kingdoms and Castles, tylko ciemniejsze i słowiańskie.

To jest pierwsze, co zobaczyłem na ekranie.

Pamiętam, że siedziałem przed tym dłuższą chwilę i miałem dwie sprzeczne myśli naraz. Pierwsza: to wygląda żałośnie. Druga: to się rusza i to ja to zrobiłem. Druga wygrała i dlatego jest ten wpis.

Zanim cokolwiek, jedna decyzja, która mogła zabić projekt

Trzeba było wybrać silnik. Naturalny wybór dla kogoś, kto robi rzeczy w przeglądarce, to three.js: JavaScript, natychmiastowy podgląd, ogromna społeczność, wszystko znajome. Alternatywą było Bevy, czyli silnik w języku Rust, którego nie znałem, przed wersją 1.0, z API zmieniającym się między wydaniami.

Mogłem o tym poczytać na Reddicie i wybrać to, co pisze większość. Zamiast tego zrobiłem test. Ta sama scena w obu silnikach, pomiar bez synchronizacji pionowej, czyli realna liczba klatek, a nie zaokrąglone sześćdziesiąt.

Scena	Obiekty	Klatki na sekundę
Pusta mapa 48×48 + 11 budynków	~2 300	~480
Miasteczko z tłumem	15 000	~130
Skrajny stress test	75 000	~38

To przypadek, który w prawdziwej grze nigdy nie wystąpi.

Wybrałem Bevy. Nie dlatego, że jest modny, tylko dlatego, że city-builder z ambicją rośnięcia to dokładnie ten przypadek, w którym architektura ECS w natywnym Rust bije jednowątkowy JavaScript. Doszedł drugi argument, o którym wtedy myślałem jako o odległej mrzonce: jeśli gra kiedykolwiek trafi na Steama, Bevy daje natywny plik .exe, a three.js wymaga opakowania w Electron ważące ponad sto megabajtów.

Zapłaciłem za to cenę, której wtedy nie widziałem. Bevy jest przed wersją 1.0 i część czasu poszła na walkę z API, które zmienia się między wydaniami. Ale to temat na osobny wpis, bo ma swoje własne, całkiem zabawne dno.

Pierwsza rzecz, która mnie ośmieszyła

Modele 3D generowałem sztuczną inteligencją, bo nie umiem modelować. Poprosiłem generator o osiem tysięcy trójkątów, czyli o coś lekkiego, co gra uniesie w setkach kopii.

Dostałem sześćset dziewięćdziesiąt trzy tysiące.

Jeden dom ważył dwadzieścia siedem megabajtów i nie zdążał się załadować w cztery sekundy, więc gra pokazywała puste miejsce tam, gdzie miał stać budynek. Przez dobre pół godziny byłem przekonany, że mam błąd w kodzie stawiania budynków. Czytałem tę samą funkcję czwarty raz.

Nie miałem błędu w kodzie. Miałem błąd w założeniu, że generator zrobi to, o co go poproszę. AI robi coś, co wygląda dokładnie tak, jak prosiłeś, i jest kompletnie bezużyteczne z powodu, o którym nie pomyślałeś.

Liczba	Co znaczy
693k	trójkątów zamiast zamówionych 8 tysięcy
27 MB	waga jednego domu przed obróbką
4,8 MB	po uproszczeniu siatki

Trzy dni później: 9429 linii w jednym pliku

Tempo było wysokie. Za wysokie. Kod pisał się tak szybko, że wszystko lądowało w jednym pliku: kamera, gospodarka, fale wrogów, walka, budowanie, teren i interfejs. Po trzech dniach ten plik miał 9429 linii.

Wyglądało to na sukces. Przecież działa. Problem w tym, że każda kolejna zmiana kosztowała więcej niż poprzednia, bo żeby cokolwiek znaleźć, trzeba było przewinąć przez wszystko inne.

To jest moment, w którym po cichu umiera większość hobbystycznych projektów. Nie dlatego, że coś przestaje działać. Dlatego, że przestaje się chcieć.

Rozbicie głównego pliku, 7 lipca: 9429 linii w jednym pliku, podejście pierwsze: 8 modułów, podejście drugie: 15 modułów tematycznych. Dwa przebiegi tego samego dnia. Dla gracza nie zmieniło się nic. Dla tempa pracy zmieniło się wszystko.

Zrobiłem to w dniu, w którym pierwszy raz pomyślałem „nie chce mi się tego szukać”. Ten próg okazał się zaskakująco dobrym sygnałem i korzystam z niego do dziś. Kiedy szukanie zaczyna męczyć bardziej niż pisanie, to nie jest zmęczenie. To jest informacja o strukturze.

Gdzie jestem po trzech tygodniach

Historia projektu ma 286 zapisów. Trzy pierwsze dni lipca to praca przed startem: wybór silnika i testy. Reszta miesiąca to dni, w których realnie coś powstawało.

Co bym powiedział sobie sprzed trzech tygodni. Nie wybieraj narzędzia na podstawie opinii w internecie, tylko na podstawie pomiaru na własnym przypadku. Ten test zajął mi jeden dzień i zdjął wątpliwość, która inaczej wracałaby przez cały projekt.

---

W następnym wpisie: sześć podejść do jednego efektu, test, który za każdym razem pokazywał zielone światło, i dlaczego to było gorsze niż brak testu.

Odkąd pamiętam, uwielbiałem gry komputerowe. Najpierw były to pierwsze konsole podłączane do telewizora, których nawet nie pamiętam z nazwy. Potem przyszedł komputer i już został.

Gry były miejscem, gdzie mogłem uciec od codziennych problemów, odpocząć, przeżyć przygodę i spotkać się ze znajomymi w wirtualnym świecie. Na każdym etapie życia były dla mnie ważne, a ten świat zawsze mnie fascynował.

Pierwsze podejście: kurs programowania

Po studiach, kiedy szukałem pracy, pomyślałem, że zacznę uczyć się programowania, bo to była, jak wtedy mówiono, praca przyszłości.

Zapisałem się na kurs JavaScriptu. Podejmowałem pierwsze próby robienia odbijających się kulek w 3D, próbowałem zrobić slidery, a nawet prostą grę typu tower defense. Tak naprawdę jedyne, co potrafiłem, to skopiować gotowy kod i podmienić w nim kolory.

Na zajęciach czułem ogromny smutek. Było mi bardzo trudno i wracały do mnie chwile ze szkoły, kiedy pani od matematyki zapraszała mnie do tablicy, a ja nie wiedziałem, co napisać. Na programowaniu było tak samo.

Ukończyłem kurs w wielkich bólach. Warto, żebyś wiedział, że mam dysortografię. A w programowaniu wystarczy jeden błąd, jedna dodatkowa spacja, której nie widać, albo przecinek, i wszystko się wywala. W tamtych czasach nie było sztucznej inteligencji, która poprawiłaby kod za ciebie i powiedziała, dlaczego coś nie działa. To była udręka.

Tak skończyło się moje pierwsze podejście do gry. Wizja była duża, ale pokonała mnie rzeczywistość.

Drugie podejście: skoro nie gra, to chociaż świat

Nie dawałem za wygraną i postanowiłem podejść do tego z innej strony. Skoro nie mogę zrobić gry, to przynajmniej stworzę wirtualny świat, czyli scenę. Uczyłem się Blendera przez kilka miesięcy, przesuwałem różne elementy.

Miałem wtedy już dwójkę małych dzieci, więc czasu nie było za dużo. Ale zrobiłem jedną scenę, kilka brył, nauczyłem się podstawowych funkcji. I powstał ten obraz.

Z perspektywy lat widzę, że nie było to arcydzieło, ale byłem zadowolony z efektu. Przez kolejne dziesięć lat gry były dla mnie już tylko rozrywką. Zostałem konsumentem.

Przełom, który przyszedł z zewnątrz

Kolejny przełom nastąpił, kiedy pojawił się ChatGPT. Zaczął nie tylko pisać teksty i wpisy na media społecznościowe, ale również kod. Całkiem nieźle radził sobie z prostymi rzeczami, potrafił zrobić stronę internetową, a nawet prostą grę.

Kiedy trzeba było iść dalej, zupełnie się gubił. Zrobiłem wtedy prostą grę typu tower defense i na tym skończyły się jego możliwości oraz moje zasoby czasu. Ale to był pierwszy promyk nadziei: może kiedyś da się zrobić grę samodzielnie, bez lat nauki programowania i grafiki 3D.

Co jakiś czas sprawdzałem, co potrafią kolejne modele. Zrobiłem klona gry typu Vampire Survivors w 2D, który działał naprawdę dobrze i dawał mi frajdę. Szybko go porzuciłem, bo to był jednak klon i nie miałem pomysłu, jak zrobić z niego coś własnego. Poza tym nie chciałem budować gry opartej na mechanizmach, które uzależniają.

I wtedy pojawił się Fable 5, model od Anthropic, który był dużym skokiem jakościowym względem wcześniejszych. Zrobiłem prostą grę 3D, zobaczyłem, co robią inni, i okazało się, że przeskok naprawdę jest duży. Marzenie o własnej grze może być bliżej, niż mi się wydawało. Przynajmniej wtedy tak myślałem.

Było to dokładnie 4 lipca. Film, który wtedy nagrałem.

Zderzenie z rzeczywistością, zanim cokolwiek powstało

Wtedy zrodziła się koncepcja: zrobić grę, ale nie taką, którą da się wyklikać jednym poleceniem. Taką, która dobrze wygląda i sprawia mi frajdę. Być może kiedyś możliwą do sprzedania na Steamie, bez wielkich oczekiwań.

Moja wizja bardzo szybko zderzyła się z rzeczywistością, bo mój analityczny umysł kazał mi szukać. Jak zwykle zaczął od problemów. Okazało się, że na Steamie powstaje co roku kilkanaście tysięcy gier, a przez AI to tempo jeszcze wzrosło. Większość nie ma nawet śladowej sprzedaży. Jak w większości branż, sensowne pieniądze zarabia garstka.

Samo to rozważanie odebrało mi trochę energii i było chyba tylko szukaniem usprawiedliwienia dla tego, czego naprawdę chciałem: po prostu spędzić dobry czas i cieszyć się procesem. Doświadczyć czegoś, czego ostatnio bardzo brakowało mi w życiu.

Postanowiłem, że zrobię to dla siebie. Dla własnej satysfakcji z rozwoju, dla eksperymentu. A być może komuś spodoba się to, co stworzyłem, albo przynajmniej ta historia zainspiruje go do zrobienia czegoś własnego.

I to jest właściwy cel tego projektu

Zobaczyć, co jest możliwe dzięki własnej pracy, własnej kreatywności i pomocy sztucznej inteligencji. Zobaczyć, gdzie jest granica, która ciągle się przesuwa.

W tym cyklu chcę podzielić się tą drogą. Tymi fajnymi i mniej fajnymi chwilami. Naturalnym cyklem, który spotyka każdy projekt: entuzjazmem, wzlotami i upadkami.

Nie wiem, jak daleko zajdę. Prowadzę działalność, mam rodzinę i dzieci, więc czasu nie ma za dużo. Ale mam nadzieję, że znajdę go tyle, żeby tę historię opowiedzieć.

Część bloga będzie pisana przez mojego agenta, który nie musi spać ani jeść. A czasami wrzucę bardziej osobisty wpis, który jest czymś więcej niż liczeniem linii kodu i błędów.

---

W następnym wpisie: pierwszy dzień pracy, zielona szachownica na ekranie i test wydajności, który zdecydował o wyborze silnika.