Jak przygotować dokumentację projektową do pierwszej gry indie krok po kroku

Po co w ogóle dokumentacja przy pierwszej grze indie

Mit „genialnej wizji w głowie” kontra rzeczywistość produkcji

Wizja w głowie działa do momentu, w którym trzeba podjąć pierwszą trudną decyzję: usunąć funkcję, przesunąć premierę, zmienić mechanikę. Bez spisanych założeń nie ma punktu odniesienia. Dziś wydaje się oczywiste, że gra ma być „prosta, ale głęboka”, za trzy miesiące pamięć dopisze szczegóły i powstanie inna wersja „prawdy”. Dokumentacja projektowa gry indie porządkuje to, co jest kluczowe, a co tylko „fajnym pomysłem”.

W praktyce dokumentacja nie jest po to, żeby imponować złożonością, tylko żeby zabezpieczyć decyzje. Zamiast wracać do tego samego tematu piąty raz, odwołujesz się do notatki sprzed tygodni: „usunęliśmy system handlu, bo rozwadniał pętlę rozgrywki i zabierał 40% budżetu na interfejs”. Nie chodzi o formalność, tylko o pamięć projektu. To szczególnie ważne, gdy pracujesz po godzinach, z długimi przerwami.

Przewrotne jest to, że im bardziej jesteś początkujący, tym bardziej spisane minimum pomaga. Doświadczeni twórcy mają w głowie dziesiątki wzorców, ty musisz dopiero zbudować kilka pierwszych. Dokumentacja gry indie pełni tu rolę zewnętrznej pamięci – łapie myśli, zanim utoną w nowych, „jeszcze lepszych” pomysłach.

Jeśli po kilku tygodniach nie pamiętasz, dlaczego dana funkcja jest dla ciebie kluczowa i nie masz tego zapisanego, to sygnał ostrzegawczy: wizja istnieje wyłącznie w emocjach, nie w decyzjach projektowych. Tam rodzą się projekty, które nigdy nie wychodzą poza fazę wiecznego „rewritu”.

Jeśli każda zmiana mechaniki wymaga godzin zastanawiania się „co my właściwie robimy?”, to oznacza, że minimum dokumentacji nie zostało jeszcze osiągnięte i pora je nadrobić, zanim projekt zje własny ogon.

Dokumentacja korporacyjna kontra lekkie podejście indie

W dużych studiach dokumentacja bywa rozbudowana, bo musi służyć setkom osób: programistom, QA, marketingowi, wydawcy. Pierwsza gra indie nie potrzebuje 120-stronicowego Game Design Document. Taki plik w jednoosobowym lub 3-osobowym zespole zwykle prowadzi do jednego efektu: paraliżu decyzyjnego i odkładania faktycznej pracy nad buildem.

Minimalna dokumentacja dla twórcy indie przypomina bardziej zestaw narzędzi niż księgę. Zamiast jednego „świętego PDF-a”, masz kilka krótkich dokumentów, z których każdy pełni jedną funkcję: opis wizji, opis mechanik, mapa produkcji, szkic wymagań technicznych. Każdy z nich da się zaktualizować w kilkanaście minut, a nie w kilka dni.

Różnica kluczowa: w podejściu korporacyjnym dokumentacja bywa kontraktowa – służy też do rozliczeń i odpowiedzialności. W podejściu indie dokumentacja jest operacyjna – ma ci pomóc szybciej ustalić priorytety, a nie wygrywać dyskusje w Excelu. Dlatego każdą sekcję trzeba oceniać pytaniem: „czy to realnie pomoże mi jutro przy pracy nad grą?”

Jeśli łapiesz się na tym, że przepisujesz ten sam opis postaci do trzech miejsc, żeby „wszystko było kompletne”, to znak, że kopiujesz nawyki korporacyjne do środowiska, które ich nie potrzebuje. Minimum to jedno źródło prawdy na dany temat, możliwie krótkie.

Jeżeli dokument projektu gry nie mieści się w kilku powiązanych ze sobą plikach, a jego aktualizacja wymaga dłuższej sesji niż odpalenie engine’u, to jest sygnał ostrzegawczy, że dokumentacja przejęła rolę projektu.

Dokument jako narzędzie podejmowania decyzji

Dobra dokumentacja projektowa odpowiada na dwa pytania: „co dalej?” i „po co to robimy?”. Jeśli ich nie dotyka, jest zbiorem luźnych notatek. Dlatego przy przygotowywaniu dokumentów do pierwszej gry indie chodzi przede wszystkim o nadanie priorytetów: które funkcje są obowiązkowe na premierę, które mogą poczekać na patch, a które są tylko eksperymentem.

Mechanika, która nie jest powiązana z główną pętlą rozgrywki lub fantasy gracza, powinna wywołać czerwone światło. W dokumentacji trzeba zaznaczać nie tylko „co robimy”, ale też „czego nie robimy w tej grze”. Przykład: „Brak systemu skakania – poziomy projektowane bez pionowej mobilności, żeby ograniczyć zakres animacji i komplikację level designu”. Takie zapisy chronią cię przed późniejszymi pomysłami typu „a może jednak dodamy podwójny skok, bo w tej scenie wyglądałby super”.

Dokument jest też narzędziem do oceny wpływu zmian. Zanim dopiszesz nową mechanikę, sięgnij do rozdziału z priorytetami: czy ta funkcja wspiera rdzeń rozgrywki, czy jest odgałęzieniem? Jeśli jest odgałęzieniem, czy masz na nie budżet czasowy i techniczny? Bez tej kartki przed oczami bardzo łatwo przesunąć projekt w stronę „jeszcze jednej rzeczy”.

Jeśli większość decyzji projektowych zapada „na czuja”, bez sprawdzenia ich w kontekście spisanych celów gry, to sygnał ostrzegawczy, że dokumentacja nie pełni roli kompasu, tylko dekoracji.

Dokument jako wspólny język z innymi współtwórcami

Nawet jeśli dziś jesteś solo devem, jutro możesz szukać grafika, kompozytora, testera albo wydawcy. Wtedy dokumentacja staje się twoją wizytówką i instrukcją obsługi projektu. Zamiast godzinnej opowieści „z głowy”, wysyłasz krótki wyciąg: opis fantasy gracza, zarys mechaniki, kilka referencji stylistycznych i informacje techniczne.

Grafik nie potrzebuje wszystkich detali systemu ekwipunku, ale musi wiedzieć, czy gra jest 2D czy 3D, jakie są proporcje postaci, klimat świata, paleta barw. Kompozytor potrzebuje opisu emocji i tempa rozgrywki, nie listy wszystkich questów. Wydawca zapyta o target, platformę, długość gry i USP (unikalną propozycję). Każda z tych osób sięgnie właśnie do dokumentacji, jeśli ma być traktowana poważnie.

Jeśli doraźnie zapisujesz informacje „gdzie popadnie” (Discord, notatnik w telefonie, zeszyt, pliki TXT) i nie jesteś w stanie jedną wiadomością wysłać komuś spójnego opisu projektu, to znak, że twoja dokumentacja nie spełnia podstawowej roli komunikacyjnej.

Kiedy dokumentacji jest za dużo

Przeciążona dokumentacja objawia się na dwa sposoby: albo praca nad nią zabiera większość czasu produkcji, albo nikt jej nie czyta – nawet ty. W obu wypadkach to sygnał ostrzegawczy. Gdy spędzasz kolejną godzinę na dopieszczaniu akapitów o fabule, zamiast poprawiać prototyp, uciekasz w pozorną produktywność.

Dobrym testem jest prosty punkt kontrolny: czy w tym tygodniu aktualizowałeś dokumentację w odpowiedzi na realne zmiany w grze, czy dopisywałeś nowe sekcje bez żadnego feedbacku z builda? Jeśli to drugie – dokumentacja rośnie obok projektu, a nie razem z nim.

W pierwszej grze indie dokumentacja powinna rosnąć skokowo i niechętnie: dopisujesz coś wtedy, gdy napotykasz konkretny problem (sprzeczne decyzje, niejasne priorytety, zaginione informacje). Jeśli rozdział powstał „bo tak się robi w prawdziwym GDD”, najpewniej nie jest ci potrzebny.

Jeżeli dokumentacja nie pomaga szybciej odpowiadać na pytania „co dalej?” i „po co to robimy?”, to sygnał ostrzegawczy, że służy bardziej usprawiedliwianiu odwlekania niż produkcji gry.

Ustalenie ram projektu: wizja, odbiorca, ograniczenia

Krótka karta projektu (Project Brief)

Każdą dokumentację projektową warto zacząć od krótkiej karty projektu. To pojedyncza strona, która definiuje ramy: co robisz, dla kogo i w jakich warunkach. W praktyce jest to filtr na wszystkie późniejsze pomysły – jeśli coś nie mieści się w tych ramach, trafia do listy „na przyszłe projekty”.

Najprostszy, a jednocześnie bardzo skuteczny szablon briefu wygląda tak: „Gra dla [kto], o [czym], z naciskiem na [co].” Przykład: „Gra dla graczy lubiących taktyczne RPG w stylu turowym, o dowodzeniu małym oddziałem w mieście opanowanym przez gangi, z naciskiem na trudne decyzje moralne i zarządzanie zasobami.” To jedno zdanie pozwala już odrzucić pomysły na zręcznościowe sekwencje QTE czy rozbudowany system jazdy samochodem.

W tej karcie warto też jasno wskazać, czego gra nie jest. Przykład: „To nie jest sandbox z otwartym światem – stawiamy na zamknięte, projektowane ręcznie misje.” Takie zapisy ratują projekt, gdy po kilku miesiącach pojawi pokusa: „a może jednak zrobimy otwarte miasto?”. Brief jest wtedy kotwicą.

Jeśli po przeczytaniu briefu znajomy z branży nie potrafi w 2–3 zdaniach wytłumaczyć komuś innemu, „o co chodzi w tej grze”, to znak, że karta projektu jest zbyt ogólna lub przeładowana hasłami marketingowymi.

Pitch w dwóch–trzech zdaniach i test windy

Pitch do znajomego w windzie to brutalny test klarowności wizji. Masz kilkadziesiąt sekund, żeby wytłumaczyć, co robisz, tak, aby druga strona nie zapytała „to coś jak… eee… co właściwie?”. Dobrze przygotowana dokumentacja gry indie zaczyna się od takiego gęstego skrótu.

Dobry pitch zawiera trzy elementy: gatunek/forma (żeby odbiorca miał punkt odniesienia), twist lub USP (co odróżnia grę od innych) oraz obietnicę doświadczenia (jak ma się czuć gracz). Przykład: „Taktyczne RPG turowe, w którym dowodzisz małym gangiem w cyberpunkowym mieście, ale każda misja to jedna noc, a po świcie wszystko się resetuje – razem z lojalnością twoich ludzi.”

Ten skrót trafia potem do GDD, materiałów dla potencjalnych współpracowników i – w dalszej perspektywie – do opisu na platformie dystrybucyjnej. Jeśli już na etapie dokumentacji nie jesteś w stanie go sformułować, trudno będzie później prowadzić spójne działania marketingowe.

Jeżeli nie potrafisz streścić gry w 2–3 zdaniach bez wchodzenia w detale fabuły i listę mechanik, to sygnał ostrzegawczy, że projekt jest zbyt rozlany lub próbujesz zmieścić w nim kilka gier naraz.

Grupa docelowa i jej oczekiwania

„Gra dla wszystkich” to najkrótsza droga do produkcji bez kompasu. W dokumentacji projektowej trzeba jasno wskazać, kto realnie ma w to grać i jakie ma nawyki. Nie chodzi o marketingową personę na pół strony, tylko o konkretne informacje z punktu widzenia designu.

Blog Robię Gry często podkreśla rolę spójnej komunikacji przy tworzeniu gier komputerowych – dokumentacja jest fundamentem takiego wspólnego języka nawet w zespole dwóch znajomych pracujących po godzinach.

Przy opisie odbiorcy odpowiedz sobie na kilka kluczowych pytań:

• Jakie gry ta osoba już zna i lubi? (konkretne tytuły, nie gatunki ogólnie).
• Ile czasu jednorazowo spędza przy grze – 15 minut, godzinę, kilka godzin?
• Jaki poziom trudności akceptuje – relaks, wyzwanie, „git gud”?
• Na jakiej platformie gra najczęściej?

Przykład: jeżeli twoim celem są osoby grające wieczorami na PC w strategie 4X, nie ma sensu budować rozgrywki opartej na 3-minutowych sesjach mobilnych. Zamiast zgadywać, w dokumentacji można wprost zapisać: „target: fani XCOM-a i Into the Breach, przyzwyczajeni do porażki i powtarzania misji”.

Jeśli nie potrafisz wskazać choćby 2–3 istniejących gier, których fani mogliby się zainteresować twoim projektem, to punkt kontrolny: prawdopodobnie kierujesz grę do zbyt abstrakcyjnego, nieokreślonego odbiorcy.

Ograniczenia: czas, budżet, umiejętności, sprzęt

Jedna z najbardziej niedocenianych części dokumentacji gry indie to otwarte przyznanie się do ograniczeń. Bez tego wizja będzie rosła w próżni. W karcie projektu trzeba wprost zapisać, ile masz godzin tygodniowo, jak długo realnie możesz utrzymać projekt oraz jaki masz budżet finansowy – nawet jeśli to 0 zł.

Do tego dochodzi lista umiejętności: co umiesz robić sam (np. programowanie w Unity, proste UI, podstawowa muzyka), czego musisz się dopiero nauczyć (np. rigowanie 3D) i co wymaga współpracy (np. pełna oprawa muzyczna, zaawansowane animacje 3D). Taki spis bezlitośnie filtruje pomysły. Pomysł na wysoce animowaną bijatykę 2D dla jednej osoby bez doświadczenia w animacji to sygnał ostrzegawczy już na starcie.

Sprzęt i narzędzia to kolejny twardy czynnik. Jeżeli tworzysz na starym laptopie, projekt nastawiony na AAA-owe efekty graficzne i ogromne sceny 3D będzie koszmarem produkcyjnym. Lepiej to zapisać wprost: „Skupiamy się na stylizowanej grafice 2D, ograniczamy rozmiar assetów i liczbę efektów post-processingu ze względu na sprzęt”.

Jeżeli w dokumentacji brak sekcji o ograniczeniach, a jedyne hamulce pochodzą z „zdrowego rozsądku”, to duże ryzyko, że zakres projektu rozjedzie się z rzeczywistością już przy pierwszym poważniejszym kryzysie.

Platforma, engine i sposób dystrybucji jako realne decyzje

Wybór platformy docelowej

Decyzja o platformie to nie kwestia gustu, tylko zestaw konsekwencji dla designu, produkcji i marketingu. W dokumentacji projektowej powinna być jasna odpowiedź: na czym gra ma działać na premierę oraz jakie porty są jedynie „miłym dodatkiem, jeśli wszystko pójdzie dobrze”.

Przy wyborze platformy przejdź przez kilka kryteriów:

• Gdzie realnie jest twoja grupa docelowa? Jeśli opisujesz odbiorców jako fanów klasycznych CRPG, w praktyce będzie to głównie PC. Jeżeli liczy się wygoda krótkich sesji i sterowanie jednym przyciskiem – naturalnym kandydatem będzie mobile lub Switch.
• Jakie są wymagania certyfikacyjne i techniczne? PC (Steam, GOG) zwykle wybacza więcej, konsole wymagają przejścia przez rygorystyczny proces certyfikacji, testów i papierologii. Dla pierwszej gry indie brak doświadczenia w tym obszarze jest istotnym sygnałem ostrzegawczym.
• Jak wygląda sterowanie? Celowanie myszką, dużo precyzyjnych kliknięć i rozbudowane UI lepiej odnajdują się na PC. Proste sterowanie gałką i kilkoma przyciskami sprzyja konsolom i handheldom.
• Jakie masz możliwości testowania? Jeśli nikt w zespole nie ma devkita konsolowego i nie masz kontaktów, które pomogą w procesie certyfikacji, planowanie premiery „od razu na trzy konsole” jest bardzo ryzykowne.

Minimum do zapisania w dokumentacji to jedno proste zdanie: „Platforma premiery: [konkretna], porty: [opcjonalne, po premierze / brak planów]” wraz z jednym akapitem uzasadnienia. Jeżeli czytasz tę część GDD i wciąż widzisz „PC/konsole/mobile” bez priorytetu, to punkt kontrolny: decyzja o platformie jest odsuwana, a projekt stoi w rozkroku.

Jeśli platforma jest jasno wskazana, łatwiej filtrować pomysły na interfejs, sterowanie i funkcje online. Jeżeli ta decyzja pozostaje „otwarta”, zakres gry będzie się rozjeżdżał, a testy i optymalizacja zamienią się w chaos.

Dobór silnika i technologii produkcyjnych

Engine to nie religia ani „najlepszy wybór roku”, tylko narzędzie zgodne z twoimi ograniczeniami i potrzebami projektu. W dokumentacji wystarczy zwięzły, konkretny opis: co wybrałeś, dlaczego i czego świadomie nie będziesz robić, żeby nie wystrzelić zakresu.

Podczas wyboru silnika sprawdź kilka kryteriów:

Jeśli interesują Cię konkrety i przykłady, rzuć okiem na: Jak wybrać styl graficzny dla swojej gry?.

• Twoje doświadczenie i dostępne tutoriale – jeśli już coś potrafisz w Unity lub Godocie, zmiana na zupełnie nowe narzędzie dla „lepszej grafiki” to sygnał ostrzegawczy. Każdy miesiąc nauki engine’u to miesiąc bez postępu w samej grze.
• Dopasowanie do typu gry – prosta gra 2D z widokiem z boku nie potrzebuje zaawansowanego systemu fizyki 3D i fotorealistycznego renderera. Z kolei first-person 3D z bogatym oświetleniem może wymagać silnika z dobrym wsparciem pipeline’u 3D.
• Społeczność i wsparcie – brak aktywnej społeczności, materiałów edukacyjnych i gotowych rozwiązań dla typowych problemów (save’y, input, UI) oznacza, że wiele rzeczy będziesz budować sam od zera.
• Docelowe platformy – jeżeli planujesz premierę na Switchu lub konkretną konsolę, sprawdź oficjalne wsparcie silnika dla tych platform, licencje i potencjalne koszty. „Na pewno się da” bez weryfikacji w dokumentacji to kolejny punkt kontrolny.

W dokumentacji dopisz także techniczne wykluczenia, np. „nie budujemy własnego silnika”, „nie implementujemy sieciowej kooperacji”, „nie tworzymy autorskiego edytora poziomów”. To urealnia zakres. Jeżeli lista technologii wygląda jak katalog wszystkiego, czego chciałbyś się nauczyć, a nie jak narzędzia potrzebne do skończenia gry, projekt wchodzi w strefę wysokiego ryzyka.

Jeśli engine i kluczowe technologie są dobrane pod faktyczne potrzeby gry i twoje umiejętności, dokumentacja stanie się realistycznym planem. Jeśli to lista modnych narzędzi, to raczej manifest życzeń niż baza pod wykonanie.

Strategia dystrybucji i model biznesowy

Nawet w małej grze indie trzeba jasno określić, jak ma ona trafić do ludzi i w jakiej formie finansowej. Brak tej sekcji w dokumentacji zwykle oznacza, że decyzje będą podejmowane chaotycznie na ostatniej prostej, gdy nie ma już czasu na korekty designu.

Podstawowe decyzje, które warto zapisać:

• Model płatności – płatna gra premium, free-to-play z mikropłatnościami, „name your price” na itch.io? Dla pierwszej gry indie model premium z uczciwą ceną i bez agresywnego live-opsu jest zwykle najmniej obciążający produkcyjnie.
• Skala i kanały dystrybucji – Steam, GOG, itch.io, mobile store’y, własna strona? Każda platforma to osobny zestaw wymagań, materiałów marketingowych i procesów certyfikacji.
• Planowane promocje i bundlowanie – czy gra ma być od razu przeceniana na launchu, czy zaczynasz od stałej ceny i ostrożnie wchodzisz w promocje? Tę decyzję da się opisać z wyprzedzeniem, zamiast improwizować.

Dobrą praktyką jest jedno zdanie podsumowujące: „Gra jako płatne premium na Steam/itch.io, bez mikropłatności, z ewentualnym darmowym prologiem/demo przed premierą.” Taki zapis potem filtruje pomysły na ekonomię czy „battle passy”. Jeśli w dokumentacji brak jakiejkolwiek wzmianki o modelu biznesowym, łatwo wprowadzić do gry mechaniki oderwane od tego, jak faktycznie będzie dystrybuowana.

Jeżeli sposób dystrybucji jest spójny z typem gry i zasobami zespołu, kolejne decyzje projektowe stają się logiczne. Jeśli sekcja o dystrybucji nie istnieje lub jest ogólnikowa („wydamy gdzieś w internecie”), to sygnał ostrzegawczy, że ten obszar został odłożony „na później”.

Opis fantazji gracza i rdzenia rozgrywki

Fantazja gracza jako punkt wyjścia

Fantazja gracza to odpowiedź na pytanie: kim gracz ma się czuć i co ma robić w tej roli. To prosty opis, który później przenika mechanikę, UI, narrację i oprawę. W dokumentacji wystarczy jeden, dwa akapity, ale muszą być konkretne.

Przy spisywaniu fantazji gracza sprawdź kilka aspektów:

• Tożsamość – „dowódca małego oddziału”, „właściciel upadającej tawerny”, „samotny kurier w niebezpiecznym mieście”. Nie „bohater w fajnym świecie”, bo to nic nie mówi o roli.
• Główne działania – „podejmowanie trudnych decyzji taktycznych”, „optymalizacja układu lokalu i obsługi gości”, „planowanie trasy i zarządzanie ryzykiem”. To później staje się punktem odniesienia do projektowania mechanik.
• Kluczowe emocje – „napięcie i satysfakcja z przetrwania”, „spokój i przyjemne planowanie”, „ciągłe balansowanie na granicy porażki”. Bez emocji fantazja staje się suchą funkcją.

Minimum to 3–4 zdania, po których osoba spoza projektu jest w stanie powiedzieć: „w tej grze chodzi o to, żeby czuć się jak…”. Jeżeli opis fantazji gracza w twojej dokumentacji brzmi jak ogólny pitch marketingowy („epicka przygoda w niesamowitym świecie”), to punkt kontrolny: brakuje konkretu i design nie ma jasnego celu emocjonalnego.

Jeśli fantazja jest precyzyjna, łatwiej ocenić każdy nowy pomysł: czy pomaga graczowi bardziej wczuć się w tę rolę, czy tylko rozprasza? Jeżeli opis jest zamglony, każda mechanika „może pasować”, więc dokumentacja szybko pęcznieje.

Definicja rdzenia rozgrywki (core loop)

Rdzeń rozgrywki to powtarzalny cykl, który gracz wykonuje setki razy podczas gry. Bez jego jasnego opisu dokumentacja zamienia się w listę oderwanych funkcji. W części dotyczącej core loop powinien znaleźć się prosty schemat: 3–5 kroków, najlepiej opisanych zwykłym językiem.

Przykładowy zapis rdzenia:

• „Wybierasz misję z mapy miasta.
• Przygotowujesz skład i ekwipunek.
• Rozgrywasz turową potyczkę.
• Wracasz do kryjówki, zarządzasz zasobami i relacjami.
• Na podstawie efektów decydujesz o kolejnej misji.”

Taki opis można dodatkowo uzupełnić krótką notką, co ma być w tym cyklu przyjemne (planowanie, ryzyko, rozwój). Rozbudowane systemy (crafting, reputacja, ekonomia) powinny być powiązane z core loopem – jeśli da się je wyciąć bez uszkodzenia rdzenia, istnieje duża szansa, że są zbędne w pierwszej wersji gry.

Dobrym punktem kontrolnym jest pytanie: czy potrafisz narysować core loop na kartce w mniej niż 30 sekund i wytłumaczyć ją komuś w minutę? Jeśli nie, najpewniej loop jest przeładowany lub nie jest jeszcze naprawdę zdefiniowany, a dokumentacja jedynie to maskuje.

Jeżeli rdzeń rozgrywki jest prosty i opisany, reszta dokumentacji może rosnąć wokół niego. Jeśli nie istnieje lub jest opisany na kilku stronach, projekt będzie dryfował od funkcji do funkcji bez wspólnego mianownika.

Projektowanie głównych systemów wokół rdzenia

Po ustaleniu core loop kolejnym krokiem w dokumentacji jest zmapowanie głównych systemów: tych, które są niezbędne, aby rdzeń działał. Chodzi o 3–5 bloków, bez których gra przestaje istnieć w obecnej formie, a nie o pełną listę „fajnych dodatków”.

Przykład dla taktycznego RPG:

• System tur i inicjatywy.
• Ruch i osłony.
• System obrażeń i stanów (ranny, wyłączony, śmiertelne rany).
• Prosty system progresji postaci (perk co kilka misji).
• Ekonomia zasobów między misjami (amunicja, medkity, gotówka).

Każdy system powinien mieć w dokumentacji krótki opis celu („po co istnieje?”) oraz minimalny zakres na wersję 1.0. Bez tego łatwo przejść z prostego systemu progresji do rozbudowanego drzewka skilli z synergiami i kilkudziesięcioma umiejętnościami – bo „tak jest w dużych grach”.

Minimum opisu jednego systemu w GDD to:

• Cel projektowy (jaką decyzję daje graczowi, jakie emocje wzmacnia).
• Minimalny zakres wersji 1.0 (np. „3 typy skilli na klasę, brak prestiży i specjalizacji”).
• Granice (czego ten system nie będzie robić w pierwszej grze, np. „brak losowości w levelowaniu, brak respeca”).

Jeżeli główne systemy są opisane hasłowo („questy”, „crafting”, „relacje”) bez celów i granic, to sygnał ostrzegawczy: projekt przygotowuje grunt pod niekończącą się rozbudowę, zamiast pod skończoną, wydawalną grę.

Jeśli systemy mają jasno określone minimum i granice, łatwiej podejmować decyzje, co odpuścić, gdy zabraknie czasu. Jeżeli ta sekcja to zbiór życzeń, crunch i cięcie funkcji w panice są niemal gwarantowane.

Zakres treści i kontrola „content creep”

Nawet prosta mechanicznie gra może utonąć w nadmiarze treści: poziomów, dialogów, przedmiotów. W dokumentacji trzeba wprost określić docelową skalę kontentu oraz ustawić limity, które będą później bronią przeciwko „jeszcze jednemu poziomowi”.

Kilka kluczowych punktów do spisania:

• Liczba i typy poziomów / lokacji – np. „10 misji głównych, 3 lokacje typu hub, brak losowo generowanych map w 1.0”.
• Zakres dialogów i tekstu – „interakcje głównie w formie krótkich opisów, brak pełnych dialogów z wyborem opcji, brak dubbingu”.
• Typy i liczba przeciwników / jednostek – „6 podstawowych typów wroga, każdy z 1 twistem mechanicznym, brak bossów wielofazowych w premierowej wersji”.
• Przedmioty i ekwipunek – „maksymalnie 20 unikalnych przedmiotów z realnym wpływem na rozgrywkę, brak losowego generowania statystyk”.

Użyteczny punkt kontrolny: spisz liczby docelowe (np. poziomów, typów przedmiotów) i zapytaj: „czy jestem w stanie zrobić to w obecnym tempie w X miesięcy?”. Jeśli odpowiedź wymaga cudów lub drastycznego przyspieszenia, zakres jest zbyt duży.

Jeżeli zakres treści jest policzalny i ograniczony, postęp projektu można mierzyć w procentach, a dokumentacja staje się realnym planem. Jeśli w tej sekcji pojawiają się głównie hasła „dużo”, „sporo”, „bogaty wybór”, to sygnał ostrzegawczy: zapraszasz do projektu niekontrolowany „content creep”.

Struktura dokumentacji: moduły, wersje, hierarchia

Podział dokumentacji na moduły

Chaos w dokumentacji zaczyna się wtedy, gdy wszystko ląduje w jednym pliku „GDD_v12_final_final”. Czytanie i aktualizowanie takiego potwora jest tak uciążliwe, że nikt tego nie robi. Zamiast jednego dokumentu encyklopedycznego lepiej przygotować zestaw powiązanych modułów.

Praktyczny podział dla małej gry indie może wyglądać tak:

• Karta projektu i pitch – 1–2 strony z wizją, platformą, ograniczeniami.

Szkic dokumentu: karta projektu i pitch

Karta projektu to najkrótszy, ale najczęściej używany dokument. Służy jako filtr: jeśli coś się w nim nie mieści, prawdopodobnie nie pasuje do gry. Minimum zawartości to:

• Jednozdaniowy opis gry – „taktyczne RPG o małym oddziale najemników, którzy utrzymują się na powierzchni, handlując ryzykiem”.
• Gatunek + perspektywa – „taktyczne RPG, widok izometryczny, single player”.
• Platforma i model biznesowy – „PC (Steam, GOG), płatna gra premium”.
• Docelowy czas rozgrywki – „8–12 godzin do przejścia kampanii, brak endgame’u po napisach końcowych”.
• 1–3 wyróżniki – „brak save scummingu, trwałe rany postaci, ekonomia oparta na długach”.
• Główne ograniczenia – „zespół 2-osobowy, brak dedykowanego animatora 3D, budżet audio minimalny”.

Ten dokument powinien mieścić się na jednej stronie A4 i być aktualizowany przy każdej istotnej zmianie. Jeśli karta projektu ma kilka stron lub zawiera szczegóły systemów, sygnał ostrzegawczy: mieszasz funkcję szybkiego pitchu z encyklopedią.

Jeżeli karta jest krótka i konkretna, pomaga w codziennych decyzjach („czy to pasuje do gry, którą tu opisaliśmy?”). Jeżeli tonie w ogólnikach i marketingowych frazach, nikt nie będzie z niej korzystał jako narzędzia projektowego.

Dokument mechanik i systemów

Mechaniki powinny żyć w osobnym module, który skupia się wyłącznie na decyzjach i konsekwencjach, a nie na fabule czy sztuce. Dobrą praktyką jest rozbicie go na sekcje odpowiadające rdzeniowi rozgrywki:

• Opis core loop – prosty schemat krok po kroku, bez szczegółów UI.
• Główne systemy – osobne podsekcje dla walki, progresji, ekonomii, eksploracji.
• Powiązania między systemami – krótki opis, jak wpływają na siebie (np. „rany z walki ograniczają dostępne akcje w kolejnych misjach”).
• Zakres V1.0 – wypunktowane elementy, które muszą być gotowe, aby gra była grywalna od początku do końca.

W tym dokumencie krytyczne jest rozdzielenie „teraz” i „kiedyś”. Dobrym narzędziem jest prosta tabela z trzema kolumnami: Minimum, Opcjonalne, Na później / DLC. Każdy system powinien mieć taką tabelę, aby w momencie kryzysu nie negocjować od zera.

Jeśli dokument mechanik jest zwięzły i oparty na decyzjach gracza, deweloper szybko znajdzie odpowiedź „jak to ma działać”. Jeśli zamienia się w opowieść o świecie, lore i inspiracjach, punkt kontrolny: przenieś te treści do innych modułów.

Jeśli chcesz pójść krok dalej, pomocny może być też wpis: Pipeline produkcyjny – jak zorganizować pracę w zespole?.

Specyfikacja świata, narracji i klimatu

Świat i historia łatwo dominują dokumentację, zwłaszcza gdy twórca lubi pisać. Zamiast rozdziału powieści, potrzebny jest moduł, który wspiera projekt, a nie go przesłania. Minimum to:

• Krótki opis settingu – 1–2 akapity: gdzie, kiedy, jaki konflikt napędza świat.
• Ton i klimat – 5–10 haseł opisujących nastrój (np. „brudny, przyziemny, cyniczny, bez bohaterskich przemówień”).
• Rola gracza w świecie – jak świat reaguje na działania gracza, a nie lista frakcji.
• Lista elementów nienegocjowalnych – co musi pozostać spójne (np. „brak magii jako rozwiązania problemów, technologia zawsze ma koszt”).
• Zakres treści narracyjnej – ile scen, ile kluczowych dialogów, jakie formy (np. „logi tekstowe, brak cut-scenek prerenderowanych”).

Rozwinięte lore, jeśli musi istnieć, lepiej przenieść do osobnego aneksu, który nie jest wymagany do codziennych decyzji projektowych. Główna specyfikacja świata powinna pomagać przy projektowaniu zadań, lokacji i UI, a nie przy opowiadaniu historii dla samej historii.

Jeżeli moduł narracyjny jasno określa granice (np. „brak wyborów wpływających na zakończenie w 1.0”), pozwala uniknąć niekontrolowanego rozrostu questów. Jeśli zawiera dziesiątki stron fabuły bez śladu o implementacji, sygnał ostrzegawczy: wizja literacka oderwała się od możliwości produkcyjnych.

Dokument referencji wizualnych i audio

Osobny moduł warto poświęcić na kierunek artystyczny i dźwiękowy. Nie musi być rozbudowany, ale powinien być precyzyjny. Przydatne elementy to:

• Punkt wyjścia estetyczny – kilka zdań i 3–5 konkretnych gier / filmów / ilustracji jako odniesienia (z komentarzem, co dokładnie z nich bierzesz).
• Typ grafiki – 2D/3D, pixel art, low poly, realizm stylizowany; plus ograniczenia (np. „brak skomplikowanych animacji szkieletowych, stawiamy na proste stany”).
• Paleta i czytelność – ogólne zasady kolorystyczne, kontrast kluczowych informacji, rozróżnianie wrogów i interaktywnych obiektów.
• Minimalny pakiet assetów – lista kategorii: ile tilesetów, ile zestawów animacji, ile motywów muzycznych.
• Kierunek audio – rodzaj muzyki, użycie ambientu vs. motywy przewodnie, priorytety SFX (np. „czytelność informacji o zagrożeniu ponad realizm dźwięków broni”).

Dobrym punktem kontrolnym jest pytanie: „czy artysta z zewnątrz, który widzi tylko ten dokument, jest w stanie przygotować 2–3 assety pasujące do gry?”. Jeśli nie – opis jest zbyt ogólny. Jeśli dokument zamienia się w moodboard z dziesiątkami linków bez komentarza, sygnał ostrzegawczy: kierunek artystyczny nie jest jeszcze decyzją, tylko zbiorem inspiracji.

Gdy moduł wizualno-audio jest konkretny i oszczędny, przyspiesza produkcję assetów i cięcia. Jeśli jest przeładowany inspiracjami, utrudnia spójność stylu i utrwala chaos estetyczny.

Moduł techniczny i narzędziowy

Nawet w małym projekcie indie przydaje się spis minimalnych decyzji technicznych. Nie chodzi o pełną dokumentację inżynieryjną, ale o zestaw ograniczeń, które wpływają na design. Minimum obejmuje:

• Silnik i wersja – np. „Unity 2022 LTS”, plus informacja, czy planujesz aktualizacje w trakcie produkcji.
• Docelowe platformy i rozdzielczości – np. „PC, minimum 1080p, brak wsparcia dla ultrawide przy premierze”.
• Podstawowe ograniczenia wydajnościowe – prosty opis: liczba jednoczesnych jednostek, maksymalna wielkość sceny, docelowe FPS.
• Narzędzia do tworzenia kontentu – edytory poziomów, sposób wprowadzania dialogów, format danych (np. JSON, ScriptableObjects).
• System buildów – jak i jak często tworzysz wersje gry do testów (np. build tygodniowy, automatyczny numer wersji).

Ten moduł nie musi rozwiązywać wszystkich problemów technicznych, ale powinien jasno zaznaczać granice, które wpływają na projekt (np. „brak pełnej fizyki ragdoll, tylko proste animacje śmierci”). Bez tego projektanci lub sami twórcy mechanik będą nieświadomie planować funkcje nierealne w danym setupie.

Jeżeli dokument techniczny jest krótki i twardo określa ograniczenia, staje się tarczą przeciw „a może dorzućmy jeszcze…”. Jeżeli jest pusty lub bardzo ogólny („optymalizacja później”), sygnał ostrzegawczy: problemy techniczne zostaną odkryte dopiero w fazie kryzysu.

Wersjonowanie dokumentacji i zasady aktualizacji

Nawet najlepszy podział na moduły nie zadziała, jeśli każdy dokument będzie miał kilka sprzecznych wersji. Niezbędne jest minimalne, ale konsekwentne podejście do wersjonowania. Sprawdza się prosty schemat:

• Jasny system numeracji – np. Major.Minor.Patch (1.2.0), gdzie:
  • Major – duża zmiana w wizji lub zakresie,
  • Minor – zmiany funkcjonalne, ale w obrębie tej samej wizji,
  • Patch – korekty, doprecyzowania, poprawki błędów.
• Log zmian – na początku każdego dokumentu krótka lista punktowa: co i kiedy zmieniono.
• Jedno źródło prawdy – informacja, gdzie przechowywana jest aktualna wersja (np. konkretna przestrzeń w Notion, katalog w repozytorium).
• Zasada „bez komentarzy w starych wersjach” – dyskusja i notatki tylko na aktualnej rewizji dokumentu.

Dobrym punktem kontrolnym jest pytanie: „czy po tygodniu przerwy jestem w stanie w 5 minut ustalić, co się zmieniło w projekcie?”. Jeśli odpowiedź brzmi „nie”, wersjonowanie jest niewystarczające. Jeśli w folderze dokumentacji znajdują się pliki typu „GDD_final_v3_ostateczne_poprawki”, sygnał ostrzegawczy: proces jest iluzoryczny.

Gdy wersjonowanie jest proste i respektowane, spory o to „która wersja obowiązuje” znikają, a decyzje da się odtworzyć z historii zmian. Gdy wersjonowanie jest chaotyczne, ogrom czasu idzie na ustalanie, co jest aktualne, zamiast na samo projektowanie.

Hierarchia decyzji i priorytetów

Dokumentacja projektowa powinna jasno pokazywać, które decyzje są nadrzędne, a które można relatywnie łatwo zmienić. Bez tego każda dyskusja staje się sporem na równych prawach, nawet jeśli dotyczy rzeczy marginalnych. Praktycznym narzędziem jest prosta hierarchia:

1. Wizja i fantazja gracza – najwyższy poziom; zmiana wymaga przemyślenia całego projektu.
2. Core loop i główne systemy – zmiany możliwe, ale wpływają na większość modułów.
3. Zakres kontentu i struktura kampanii – zmiany wpływają na czas produkcji i budżet.
4. Detale systemów, liczby, balans – relatywnie tanie do modyfikacji, często aktualizowane.
5. Warstwa prezentacyjna i UX – zmiany częste, ale nie powinny naruszać powyższych poziomów.

Dobrym zwyczajem jest oznaczanie w dokumentach, do którego poziomu należy dana decyzja (np. [L1] wizja, [L3] kontent). Dzięki temu przy każdej propozycji zmiany od razu wiadomo, jak bardzo jest ona „kosztowna” i które moduły trzeba przeglądnąć.

Jeśli hierarchia jest spisana, łatwiej odróżnić dyskusję o kolorze przycisku od dyskusji o samej fantazji gracza. Jeżeli tego porządku brakuje, sygnał ostrzegawczy: projekt będzie się cofał w kółko do podstawowych pytań przy każdej mniejszej poprawce.

Plan iteracji i przeglądów dokumentacji

Dokumentacja, która powstaje raz i nigdy nie jest przeglądana, szybko się dezaktualizuje. Z drugiej strony ciągłe poprawianie dokumentów zamiast gry jest równie groźne. Potrzebny jest prosty rytm przeglądów. Przykład dla małego projektu:

• Przegląd miesięczny – 1–2 godziny, aktualizacja karty projektu, core loop i listy głównych systemów.
• Przegląd kwartalny – głębszy przegląd modułów: zakres kontentu, plan wydania, moduł techniczny.
• Mini-przegląd po każdym prototypie – krótkie dopisanie wniosków do dokumentu mechanik (co działa, co do cięcia).

Każdy przegląd powinien kończyć się prostą listą zmian wprowadzonych do dokumentów i decyzjami, które zostały odrzucone (z krótkim uzasadnieniem). Ta druga lista jest ważna – zapobiega powracaniu tych samych pomysłów co kilka miesięcy.

Jeżeli przeglądy są krótkie, cykliczne i zakończone konkretnymi aktualizacjami, dokumentacja pozostaje narzędziem, a nie reliktem przeszłej wizji. Jeśli przeglądów się unika, sygnał ostrzegawczy: projekt prawdopodobnie dawno odjechał od tego, co jest na papierze.

Dokumentacja a prototypy i wersje grywalne

Skuteczna dokumentacja projektowa nie istnieje w próżni – powinna być ściśle powiązana z kolejnymi prototypami. Dobrym podejściem jest traktowanie każdego prototypu jako testu konkretnego fragmentu dokumentu. Praktyczna procedura może wyglądać tak:

• Dla każdego prototypu – zdefiniuj, które punkty z dokumentu mechanik / core loop mają zostać zweryfikowane.
• Po testach – zapisz w osobnej podsekcji „Wnioski z prototypu X”, z wyraźnym oznaczeniem:
  • co potwierdzono,
  • co wymaga zmiany w dokumentach,
  • co trafia do kosza.
• Ustal czas na aktualizację – krótkie okno (np. 1 dzień po testach), w którym dokumenty muszą zostać zaktualizowane.

Najczęściej zadawane pytania (FAQ)

Po co mi w ogóle dokumentacja przy pierwszej grze indie, skoro wszystko mam w głowie?

Dokumentacja jest zewnętrzną pamięcią projektu. Chroni przed sytuacją, w której po kilku tygodniach nie pamiętasz, dlaczego dana funkcja była „kluczowa” i zaczynasz podważać własne decyzje. Zapisane założenia pozwalają porównać pomysł z wczoraj z pomysłem z dziś, zamiast ufać jedynie emocjom i mglistym wspomnieniom.

Przydatny punkt kontrolny: jeśli każda poważniejsza zmiana mechaniki wywołuje pytanie „co my właściwie robimy?” i wymaga godzin rozmów lub rozmyślań, to dokumentacja jest zbyt szczątkowa. Jeśli natomiast większość sporów rozwiązujesz, otwierając krótki plik z założeniami, to masz minimum, które realnie pracuje na projekt.

Jak napisać dokumentację gry indie, żeby nie skończyło się na 100-stronicowym GDD?

Zamiast jednego ogromnego GDD stwórz kilka krótkich, wyspecjalizowanych dokumentów: kartę projektu (wizja i odbiorca), dokument mechanik (rdzeń rozgrywki), mapę produkcji (co, kiedy, w jakiej kolejności) i prosty szkic wymagań technicznych. Każdy z nich powinien być do zaktualizowania w kilkanaście minut, a nie po całym dniu przepisywania.

Sygnał ostrzegawczy: jeśli aktualizacja dokumentu zabiera więcej czasu niż odpalenie engine’u i zrobienie małego prototypu, to znaczy, że masz za dużo papieru w stosunku do realnej produkcji. Minimum to kilka powiązanych plików, które regularnie otwierasz, zamiast jednego „świętego PDF-a”, do którego nikt nie zagląda.

Jakie elementy powinna zawierać minimalna dokumentacja do pierwszej gry indie?

Wariant minimum to cztery bloki: krótka karta projektu („gra dla kogo, o czym, z naciskiem na co”), opis głównej pętli rozgrywki i kluczowych mechanik, lista priorytetów funkcji (na premierę / po premierze / eksperymenty) oraz notatka technologiczna (platforma, silnik, główne ograniczenia). To wystarczy, żeby filtrować nowe pomysły i nie gubić kierunku.

Punkty kontrolne: jeśli nie jesteś w stanie w jednym pliku odpowiedzieć na pytanie „dla kogo jest ta gra i co jest w niej najważniejsze?”, to brakuje karty projektu. Jeśli nie wiesz, które funkcje można bezboleśnie wyciąć, gdy zabraknie czasu, brakuje listy priorytetów. Bez tych dwóch elementów projekt łatwo wpada w wieczny „rewrite”.

Jak odróżnić potrzebną dokumentację od przerostu formy nad treścią?

Potrzebna dokumentacja powstaje w odpowiedzi na realne problemy: sprzeczne decyzje w zespole, chaotyczne priorytety, zaginione informacje przy dłuższej przerwie w pracy. Przerost zaczyna się wtedy, gdy dopisujesz sekcje „bo tak się robi w prawdziwym GDD”, bez żadnego feedbacku z działającego builda. Jeśli tekst rośnie obok gry, a nie razem z nią, to sygnał ostrzegawczy.

Dobre kryterium audytowe: w tym tygodniu aktualizowałeś dokumentację dlatego, że coś zmieniło się w grze, czy dlatego, że „ładnie będzie to mieć opisane”? Jeśli często poprawiasz stylistykę i formatowanie, a rzadko dopisujesz twarde decyzje („rezygnujemy z systemu skakania z powodów X i Y”), to dokumentacja zaczyna służyć odwlekaniu pracy zamiast produkcji.

Jak dokumentacja pomaga w podejmowaniu decyzji o funkcjach i mechanikach?

Dobry dokument projektowy odpowiada na dwa pytania: „co dalej robimy?” oraz „po co to robimy?”. Lista funkcji z priorytetami i opis głównej pętli rozgrywki pozwalają szybko ocenić, czy nowy pomysł wzmacnia rdzeń gry, czy jest boczną gałęzią. Zanim dopiszesz mechanikę, konfrontujesz ją z tym, co już jest zapisane jako cel i „fantasy gracza”.

Punkt kontrolny: każda mechanika powinna mieć w dokumentacji krótkie uzasadnienie („po co istnieje w tej grze?”) oraz ewentualną listę konsekwencji. Jeśli nie jesteś w stanie napisać dwóch sensownych zdań o wpływie funkcji na rdzeń rozgrywki, to albo koncept jest zbyt mglisty, albo po prostu zbędny na ten projekt.

Jak używać dokumentacji, kiedy do projektu dołącza grafik, kompozytor albo wydawca?

Dokumentacja pełni wtedy rolę wspólnego języka. Grafik potrzebuje kompaktnych informacji o proporcjach postaci, klimacie świata i kluczowych referencjach wizualnych, kompozytor – o emocjach i tempie rozgrywki, a wydawca – o grupie docelowej, platformie, długości gry i unikalnej propozycji. Zamiast improwizowanej godziny na Discordzie, wysyłasz spójny wyciąg z dokumentów.

Sygnał ostrzegawczy: jeśli za każdym razem tłumaczysz wizję „od zera” i nie potrafisz jednym linkiem lub jednym plikiem pokazać zwięzłego opisu projektu, twoja dokumentacja nie spełnia funkcji komunikacyjnej. Minimum to taki zestaw plików, który nowej osobie w zespole odpowie na 80% podstawowych pytań bez dodatkowych rozmów.

Gdzie najlepiej trzymać dokumentację do gry indie, żeby się nie rozjechała?

Najważniejsze kryterium to jedno źródło prawdy na dany temat. Niezależnie, czy używasz Notion, Google Docs, wikipedii projektowej czy prostych plików tekstowych w repozytorium – kluczowe decyzje nie mogą być porozrzucane po Discordzie, notatniku w telefonie i przypadkowych plikach. Zadbaj o jasną strukturę: osobne miejsce na wizję, mechaniki, produkcję i kwestie techniczne.

Punkt kontrolny: jeśli potrzebujesz więcej niż kilku minut, żeby odnaleźć decyzję sprzed miesiąca (np. „dlaczego zrezygnowaliśmy z systemu handlu?”), to obecny system przechowywania nie działa. Jeśli za to większość istotnych ustaleń jesteś w stanie szybko zlokalizować i zaktualizować w jednym miejscu, masz działające minimum operacyjne.

Co warto zapamiętać

• Minimalna dokumentacja jest „pamięcią projektu” – zabezpiecza decyzje (co usuwasz, co odkładasz, co zmieniasz) i chroni przed wiecznym przepisywaniem gry od nowa pod wpływem emocji i nowych „genialnych” pomysłów.
• Podejście korporacyjne (setki stron, duplikowanie treści) jest sygnałem ostrzegawczym dla twórcy indie – minimum to kilka krótkich, aktualizowalnych plików pełniących konkretne funkcje: wizja, mechaniki, plan produkcji, wymagania techniczne.
• Dokumentacja ma być narzędziem podejmowania decyzji: jasno wyznacza priorytety (co jest obowiązkowe na premierę, co na patch, co jest eksperymentem) oraz wskazuje, czego w tej grze celowo nie robisz, żeby ograniczyć zakres i koszty.
• Każda nowa mechanika powinna przejść przez punkt kontrolny: czy wspiera główną pętlę rozgrywki i fantasy gracza, czy jest tylko boczną gałęzią; jeśli to odgałęzienie, sprawdzasz budżet czasowy i techniczny zanim ją dopiszesz do projektu.
• Brak jasnych wpisów „dlaczego coś jest ważne” oraz częste, intuicyjne zmiany bez odniesienia do dokumentu to sygnał ostrzegawczy, że wizja istnieje tylko w głowie, a dokumentacja nie pełni roli kompasu, lecz dekoracji.
• Dokumentacja pełni funkcję wspólnego języka z innymi współtwórcami – grafik potrzebuje parametrów świata i stylu, kompozytor tempa i emocji rozgrywki, wydawca targetu i USP; każdy z nich powinien otrzymać zwięzły, konkretny wyciąg zamiast chaotycznej opowieści „z głowy”.

Źródła

• The Art of Game Design: A Book of Lenses. CRC Press (2019) – podstawy projektowania gier, rola wizji i dokumentacji
• Game Design Workshop: A Playcentric Approach to Creating Innovative Games. A K Peters (2014) – proces projektowy, iteracja, dokumentacja jako narzędzie decyzji
• Rules of Play: Game Design Fundamentals. MIT Press (2003) – fundamenty projektowania, pętla rozgrywki i priorytety mechanik
• Level Up! The Guide to Great Video Game Design. Wiley (2010) – praktyczne wskazówki dot. GDD, zakresu funkcji i cięcia feature’ów
• Agile Game Development: Build, Play, Repeat. Addison-Wesley (2020) – zwinne podejście, lekkie dokumenty zamiast ciężkich GDD
• Scrum Guide. Scrum.org (2020) – zasady minimalnej dokumentacji i iteracyjnego podejmowania decyzji
• A Project Guide to UX Design. New Riders (2013) – dokumentacja jako narzędzie komunikacji w małych zespołach kreatywnych
• Blood, Sweat, and Pixels. HarperCollins (2017) – studia przypadków gier, wpływ decyzji projektowych i zmian zakresu
• Game Development Essentials: Game Project Management. Delmar Cengage Learning (2010) – zarządzanie projektem, priorytety funkcji, komunikacja w zespole
• Game Design Documents: What They Are and Why You Need Them. Gamasutra – omówienie roli GDD, różnice między dużymi studiami a indie