Zacząłem robić gry w Unity, mając trzynaście czy czternaście lat, w gimnazjum, razem z kuzynem Sebą. Każdy projekt, który zaczynaliśmy, kończył się w tym samym miejscu: teren, podstawowe AI idące w twoją stronę, ekwipunek, broń. I koniec. Nie kłótnia, nie znudzenie, nie lepszy pomysł. Po prostu folder, którego przestawało się otwierać.
Przez lata wrzucałem to do szufladki „za mało dyscypliny". To była zła diagnoza i wiem to dzisiaj, bo zrobiłem to jeszcze około dwunastu razy jako dorosły — te same cztery funkcje, lepszy kod, ten sam folder — zanim cokolwiek skończyłem.
Powód, dla którego te cztery funkcje zawsze są tymi czterema, nie jest psychologiczny. Jest strukturalny i jest wręcz wstydliwie prosty, gdy się go zobaczy.
Co łączy te cztery
Teren. AI idące w twoją stronę. Ekwipunek. Broń. Ustaw je obok siebie, a wspólna cecha jest oczywista: każdą z nich da się skończyć bez decydowania, czym jest gra.
| Funkcja | Kiedy jest skończona? | Co zakłada o grze |
|---|---|---|
| Teren | Gdy wygląda jak ziemia. | Nic. Każda gra ma gdzie stać. |
| AI chodzące za tobą | Gdy dochodzi do ciebie i nie wpada pod podłogę. | Nic. Nie musi niczego chcieć. |
| Ekwipunek | Gdy przedmioty wchodzą, wychodzą i zostają. | Nic. Nigdy nie pyta, po co te przedmioty. |
| Broń | Gdy strzela i coś reaguje. | Nic. Nie potrzebuje powodu, żeby wystrzelić. |
Każda ma jasne kryterium ukończenia, które mieści się w całości wewnątrz niej samej. Widzisz, kiedy działa. Dostajesz małą, prawdziwą satysfakcję z rzeczy, która funkcjonuje. I w żadnym momencie żadna z nich nie wymaga odpowiedzi na jedyne pytanie, które ma znaczenie, czyli co gracz robi i dlaczego miałby zrobić to drugi raz.
Praca jest więc naprawdę przyjemna i naprawdę produktywna — dokładnie do momentu, w którym kończy się kolejka zadań wolnych od decyzji. Wtedy następne zadanie przestaje brzmieć „zbuduj to", a zaczyna „rozstrzygnij to, potem zbuduj", a to jest inna robota, o której nikt cię nie uprzedził.
Urwisko, które nie wygląda jak urwisko
Nic się nie psuje. Nie ma błędu, nie ma ściany, nie ma momentu porażki. Projekt po prostu przestaje dawać to uczucie, które dawał wczoraj, a tydzień później otwierasz coś innego.
To jest sygnał, że rzecz jest strukturalna, a nie motywacyjna: porzucone projekty nie stają w losowych miejscach, stają w tym samym miejscu. Problem z dyscypliną rozrzuca porażki po osi czasu. Problem strukturalny daje urwisko, w tym samym punkcie, za każdym razem.
Rzecz, której unikałeś, to pętla
Pętla to najmniejsza rzecz, którą gracz robi w kółko: trzydzieści sekund powtarzających się przez sześć godzin. Postaw kafelek, zobacz wynik, postaw następny. Weź kontrakt, oblej go, weź lepszy.
W odróżnieniu od tamtych czterech pętli nie da się zbudować bez zdecydowania, czym jest gra, bo pętla jest tą decyzją wyrażoną w kodzie. Właśnie dlatego się ją odkłada, a odkładanie jej to jedyny mechanizm stojący za każdym martwym folderem, jaki mam.
Odwrócenie, które działa, jest nieprzyjemne w przyjęciu i proste w opisie:
- Zbuduj pętlę najpierw, brzydko. Szare klocki, zero grafiki, zero terenu, wszystko zastępcze. Jedyny wymóg: ma być grywalne i ma się powtarzać.
- Najpierw niech będzie nudna, potem dobra. Nudną pętlę da się poprawić. Pięknego terenu bez pętli nie da się poprawić w grę; da się na nim tylko postawić więcej rzeczy.
- System dodawaj dopiero wtedy, gdy pętla jest bez niego gorsza. To zdanie jest całą kontrolą zakresu. Ekwipunek dodany, bo pętla go potrzebuje, jest funkcją. Ekwipunek dodany, bo był następny w kolejce, jest częścią.
W moim przypadku gra, którą faktycznie wydałem, otwiera się decyzją, a nie krajobrazem: wybierasz, co zbudować, świat odpowiada, i trzydzieści sekund się powtarza. Teren przyszedł osiemnaście miesięcy później i tylko dlatego, że pętla na niego zapracowała.
Wersja z Sebą i dlaczego ma znaczenie, że mieliśmy trzynaście lat
Byłoby schludniej twierdzić, że projekty z dzieciństwa to inny problem niż te dorosłe. Nie są, i to jest ta użyteczna część.
Mając trzynaście lat, z Sebą, nie mieliśmy terminu, klienta, kosztu porażki ani niczego do stracenia, za to mieliśmy nieskończone popołudnia — czyli każdy warunek, o którym poradniki o motywacji mówią, że jest potrzebny. I dalej stawaliśmy na terenie, AI chodzącym za graczem, ekwipunku i broni. Usuń wszystkie czynniki motywacyjne, a te same cztery funkcje i tak się pojawiają, w tej samej kolejności, i projekt i tak umiera. To jest tak blisko eksperymentu kontrolowanego, jak ten temat pozwala, i dlatego nie wierzę już w wyjaśnienie przez dyscyplinę.
Czego nie mieliśmy, to jakiegokolwiek pojęcia o pętli. Nikt w gimnazjum na początku lat dziesiątych nie miał nam tego powiedzieć, a tutoriale, za którymi szliśmy, były zbudowane dokładnie jak nasze projekty: tu masz, jak zrobić teren, tu jak sprawić, żeby przeciwnik chodził za graczem, tu masz system ekwipunku. Tutoriale uczyły części, bo części da się nauczyć. Decyzji nie nauczy cię nikt.
Co naprawdę przerwało ten wzorzec
Kilkanaście projektów później zmieniła się nie siła woli. Zmieniły się trzy rzeczy i tylko jedna z nich dotyczy gier.
Wydałem coś małego, co nie było grą. Aplikację monitorującą Windows, w Microsoft Store od lipca 2026. To mniejsza i nudniejsza rzecz niż którakolwiek z porzuconych gier, a skończenie jej nauczyło mnie tego, czego gry nigdy nie nauczyły: z czego naprawdę składa się ostatnie dwadzieścia procent. Odrzucenia ze Store, instalator, polityka prywatności, adres do kontaktu, changelog. Nic z tego nie widać ze środka prototypu i to właśnie dlatego prototypy zostają prototypami.
Zacząłem od rzeczy, której nie dało się zbudować bez decyzji. Symulacja przed ekranami, ekrany przed grafiką. Nie z cnoty — po prostu skończyły mi się sposoby, żeby się w tej sprawie mylić.
Kazałem grze automatycznie udowadniać, że jest grą. Jest teraz test, w którym skryptowany bot rozgrywa pełne cztery lata gry, a asercje sprawdzają, że zwyczajny gracz przeżywa i nie dominuje. Ten test jest pętlą zapisaną w formie, która oblewa, gdy pętla przestaje nią być. Opisałem, jak działa; tutaj liczy się to, że odpowiada na pytanie, którego moje nastoletnie projekty nigdy nie zadały na głos.
Ta niewygodna
Projekt, który skończyłem jako pierwszy, nie był projektem, na którym najbardziej mi zależało. Był tym, który był dostatecznie mały, żeby go skończyć. Latami wierzyłem w odwrotną kolejność — że skończenie ambitnej rzeczy udowodni, że umiem kończyć rzeczy — i jest to dokładnie na opak.
Kończenie jest umiejętnością z własnym programem nauczania i nie da się jej nauczyć na projekcie dość dużym, żeby ukryć lekcję.
Sprawdzian, czy twój obecny projekt zaraz umrze
Trzy pytania, w kolejności, w jakiej bym je zadał. Zajmują dwie minuty i są niewygodne celowo.
| Pytanie | Co oznacza zła odpowiedź |
|---|---|
| Czy rzecz, którą buduję jako następną, dałoby się bez zmian wrzucić do innej gry? | Jeśli tak — i jeśli tak jest od kilku zadań z rzędu — zbierasz części, nie budujesz gry. To najwcześniejszy sygnał i najłatwiejszy do zignorowania, bo praca nadal daje dobre samopoczucie. |
| Czy ktoś może zagrać w to sześćdziesiąt sekund i chcieć drugi raz? | Jeśli nie ma czego mu podać, pętla jeszcze nie istnieje, cokolwiek sugeruje rozmiar folderu. Sześćdziesiąt sekund, nie demo. |
| Jaka jest najmniejsza wersja tego, którą mógłbym pokazać obcej osobie w tym miesiącu? | Jeśli nie ma odpowiedzi, zakres nie jest planem, tylko życzeniem. Jeśli odpowiedź istnieje, ale nie chcesz tego pokazać, to mówi prawdziwy projekt i warto go posłuchać. |
Pierwsze pytanie to to, które chciałbym usłyszeć, mając trzynaście lat. Teren, AI chodzące za graczem, ekwipunek, broń — wszystkie cztery to „tak". Zbudowaliśmy cztery rzeczy, które pasowałyby do czyjejkolwiek gry, czyli inaczej mówiąc nie zaczęliśmy swojej.
Czego to nie rozwiązuje
Budowanie pętli najpierw nie czyni projektu łatwym i zrobiłbym rzecz, której nie znoszę, gdybym sugerował inaczej.
- Pętla może być po prostu zła, a dowiedzenie się tego wcześnie jest sensem metody, a nie jej porażką. Nadal jest nieprzyjemne.
- Niektóre gatunki ukrywają swoją pętlę. Pętla gry narracyjnej to czytaj, wybierz, zobacz konsekwencję, a to trudniej zrobić na szarych klockach niż postaw, zobacz, postaw.
- Skończenie i tak zajmuje tyle, ile zajmuje. Mnie zajęło osiemnaście miesięcy wieczorów po zmianach i żadna sztuczka z kolejnością tego nie skraca.
Kupujesz za to tyle, że projekt umiera — jeśli ma umrzeć — w drugim tygodniu, a nie w ósmym miesiącu, i z jasnym powodem zamiast folderu, którego przestałeś otwierać. Przy dwunastu projektach ta różnica byłaby warta lata.
Pytania, które ludzie zadają
Dlaczego solowe projekty gier zawsze stają w tym samym miejscu?
Bo teren, AI chodzące za graczem, ekwipunek i broń mają jedną wspólną cechę: każdą z nich da się skończyć bez decydowania, czym jest gra. Są samodzielne, mają jasne kryterium ukończenia, dają poczucie postępu i niczego od ciebie nie żądają. Gdy następne zadanie wreszcie wymaga decyzji o tym, co gracz właściwie robi, nie zostaje żadna praca do zbudowania, której wcześniej nie trzeba rozstrzygnąć, i projekt staje. To strukturalne, nie motywacyjne.
Jak naprawdę skończyć grę jako solowy twórca?
Zbuduj pętlę przed systemami. Pętla to najmniejsza rzecz, którą gracz powtarza, i w odróżnieniu od terenu czy ekwipunku nie istnieje bez decyzji o grze — dlatego właśnie jest odkładana. Najpierw grywalna i nudna, wszystko zastępcze, a system dodajesz dopiero, gdy pętla jest bez niego gorsza. Potem wydaj coś małego i prawdziwego prawdziwym ludziom, zanim uwierzysz, że skończysz coś dużego.
Czy to kwestia dyscypliny, jeśli nigdy nie kończę swoich gier?
Prawie na pewno nie. Dowodem jest to, że porzucone projekty stają w tym samym miejscu, a nie w losowych punktach: problem z dyscypliną rozrzuca porażki po osi czasu, problem strukturalny daje urwisko. Mając trzynaście lat, nie miałem terminu, kosztu porażki ani niczego do stracenia, a projekty umierały dokładnie w tym samym miejscu co te, które budowałem jako dorosły po zmianie w pracy.
Jak sprawdzić, czy projekt zaraz zostanie porzucony?
Zapytaj, czy rzecz, którą planujesz zbudować jako następną, dałoby się bez zmian wrzucić do innej gry. Jeśli tak jest od kilku zadań z rzędu, zbierasz części, a nie budujesz grę, mimo że wszystko nadal wydaje się produktywne. Pytanie dodatkowe: czy ktokolwiek mógłby zagrać w to sześćdziesiąt sekund i chcieć drugi raz.
Czy warto uczyć się gamedevu z serii tutoriali?
Części tak i są w tym dobre. Miej tylko świadomość, czego strukturalnie nie dadzą: tutorial uczy terenu, przeciwnika chodzącego za graczem, systemu ekwipunku, bo tego da się nauczyć w oderwaniu. Nikt nie nauczy cię, czym jest twoja gra, więc program nauczania zbudowany z tutoriali produkuje dokładnie te cztery funkcje z tego artykułu i staje. To nie jest wada tutoriali. To luka, o której trzeba wiedzieć, że istnieje.
Kim jest Marcin Firmuga?
Solowy programista z Radomia. Zacząłem tworzyć gry w Unity w wieku trzynastu, czternastu lat razem z kuzynem Sebą, a te projekty zawsze kończyły się na tych samych czterech funkcjach: terenie, podstawowym AI chodzącym za graczem, ekwipunku i broni. Porzuciłem około dwunastu projektów, zanim cokolwiek skończyłem. Dziś buduję PC Workman, aplikację monitorującą Windows obecną w Microsoft Store od lipca 2026, oraz Scaling Laws, symulację menedżerską z 1624 testami automatycznymi — obie publicznie, łącznie z tym, co nie działa.