Cel produktu
Co ta funkcja zmienia w spokojnej pętli rozwoju i dlaczego gracz ma do niej wracać?
PROCES
Od „po co?” do „co jeśli?”.
Nie rekonstruujemy niepublicznej chronologii projektu. Zamiast tego pokazujemy proces projektowy, którego wymaga produkt łączący farmę, zwierzęta, łowienie, gotowanie, zadania, rozwój wioski i lekką przygodę.
studioprocessystemyjakośćprodukt
Sześć warstw decyzji.
Każdy krok domyka inny rodzaj ryzyka. Jeśli któryś jest niejasny, późniejsze warstwy zwykle tylko powiększają problem.
Model systemu
Jakie są wejścia, wyjścia, koszty, blokady, stany pośrednie i zależności?
Interakcja
Jak gracz rozpoczyna działanie, widzi postęp, rozumie zakończenie i odzyskuje kontrolę?
Hierarchia informacji
Co musi być na pierwszym planie, a co może być dostępne dopiero po zainteresowaniu?
Balans i rytm
Jak częstotliwość, koszt i nagroda wpływają na tempo całej gry?
QA i release-readiness
Jak zachowuje się funkcja przy przerwaniu, braku zasobów, powrocie, nietypowej kolejności i zmianie kontekstu?
Kryteria przejścia między warstwami.
Checkpoint nie mówi „ładnie wygląda”. Mówi, jaki problem został zamknięty i jaki nowy rodzaj ryzyka można bezpiecznie otworzyć.
EtapPytanie kontrolneSygnał, że trzeba wrócić
CelCzy potrafimy opisać wartość funkcji jednym zdaniem bez wymieniania UI?Jeśli odpowiedź brzmi tylko „bo to standard gatunku”.
SystemCzy każdy stan ma właściciela i czy wiadomo, co go zmienia?Jeśli wyjątki wymagają osobnych reguł bez wpływu na decyzję.
InterakcjaCzy gracz wie, co stanie się po działaniu?Jeśli tekst instrukcji musi ratować podstawowy gest.
BalansCzy aktywność ma własny rytm, ale nie wypycha pozostałych?Jeśli jedna ścieżka staje się obowiązkowa dla całego postępu.
QACzy system przeżywa przerwanie i nietypową kolejność?Jeśli poprawny wynik zależy od idealnej ścieżki.
Nie poprawiamy wszystkiego tym samym narzędziem.
Gdy coś nie działa, najpierw klasyfikujemy problem. Zmiana koloru nie naprawi zależności systemowej, a dodatkowy tutorial nie naprawi złej kolejności interakcji.
Zachowanie
Co gracz rzeczywiście robi?
Przyczyna
Czy problem jest w regule, informacji, balansie czy stanie?
Zmiana
Wybieramy najmniejszą zmianę dotykającą przyczyny.
Regresja
Sprawdzamy, czy poprawka nie psuje innych systemów.
Co przekazujemy między dyscyplinami.
Dobry handoff nie jest plikiem „gotowe”. To zestaw założeń, zależności i kryteriów, dzięki którym kolejna osoba nie musi zgadywać intencji.
Design → Visual
priorytet, stany, ważność informacji
Visual → Implementation
hierarchia, zachowanie, warianty stanów
Implementation → QA
warunki, ograniczenia, znane ryzyka
QA → Product/Design
powtarzalny problem i kontekst, nie tylko screenshot błędu
Jak funkcja przechodzi od opisu do modelu.
Weźmy gotowanie — funkcję potwierdzoną w publicznym opisie gry. Nie znamy niepublicznej implementacji, ale możemy pokazać rodzaj pytań, które taka funkcja musi zamknąć.
Wejście
Jakie składniki są rozpoznawane i kiedy gracz może rozpocząć działanie.
Koszt
Co jest zużywane i czy koszt jest widoczny przed potwierdzeniem.
Czas / stan
Czy działanie jest natychmiastowe, oczekujące albo przerwalne.
Rezultat
Co dokładnie powstaje i gdzie gracz widzi nowy stan.
Zastosowanie
Czy wynik wspiera zadanie, relację, rozwój albo kolejny system.
Błąd
Co dzieje się przy braku miejsca, składnika, połączenia lub przerwaniu akcji.
Poprawka nie kończy się w miejscu, które zmieniliśmy.
Systemy są połączone. Po zmianie sprawdzamy nie tylko nowy flow, lecz także sąsiadujące stany i ścieżki powrotu.
Przed zmianą
- jaki problem obserwujemy
- który stan go wywołuje
- jakie systemy czytają ten stan
Po zmianie
- czy główny przypadek jest prostszy
- czy informacja zgadza się z rezultatem
- czy zapis i odczyt stanu są spójne
Sąsiedzi
- czy nagroda trafia do właściwego miejsca
- czy zadanie rozpoznaje nowy stan
- czy brak zasobu nadal blokuje poprawnie
Powrót
- co widzi gracz po ponownym wejściu
- czy przerwana akcja ma bezpieczny stan
- czy nie ma podwójnego naliczenia
Proces bez fikcyjnej dokumentacji.
Nie podajemy silnika, narzędzi, liczby prototypów, sprintów, wielkości zespołu ani testowych metryk, bo źródło ich nie potwierdza. Zamiast tego wyjaśniamy projektowe zależności wynikające z funkcji gry.
Pokazujemy
- obserwowalne funkcje gry
- ogólna logika projektowa
- spójne kryteria jakości
Nie dopisujemy
- brak fałszywych dat
- brak wymyślonego toolchainu
- brak zmyślonych metryk
Zobacz te zasady na konkretnych systemach.
Systemy strony produktu pokazują, jak rozbijamy uprawę, zwierzęta, łowienie, gotowanie, pomoc i wyprawy na role w całej pętli.