Problem
co dokładnie nie działa lub może działać lepiej
TASK • PROTOTYP • ITERACJA • QA
Nasza praca nie jest linią produkcyjną. To system krótkich decyzji i powrotów.
Przy Blasty Bubs każda zmiana przechodzi przez kilka perspektyw: problem projektowy, implementację, obserwację zachowania w grze, review oraz test sytuacji granicznych. Nie opowiadamy fikcyjnego kalendarza produkcji — pokazujemy model pracy, którym prowadzimy produkt.
MODEL PRACY
Sześć stanów jednego zadania.
Zadanie zaczynamy od problemu, nie od gotowej funkcji. To ważne, bo pozwala szukać kilku rozwiązań zamiast bronić pierwszego pomysłu. Jeśli problem dotyczy np. słabej czytelności odbicia, odpowiedzią może być zmiana geometrii, feedbacku, prędkości albo samego układu poziomu.
Dopiero po zbudowaniu wariantu weryfikujemy, czy zmiana faktycznie poprawia to, co chcieliśmy poprawić.
Hipoteza
jaka zmiana może wpłynąć na zachowanie
Prototype
wersja wystarczająca do sprawdzenia
Review
ocena przez kilka dyscyplin
QA
sytuacje graniczne i regresje
Release
decyzja czy rozwiązanie jest gotowe
WARSZTAT
Najwięcej pracy dzieje się pomiędzy wersjami.
Przegląd prototypu jest dla nas miejscem, w którym łączą się dyscypliny. Projekt może chcieć mocniejszego napięcia, art większej czytelności, a QA wskazać, że nowy wariant prowadzi do trudnego do przewidzenia stanu. Żadna z tych perspektyw nie jest dodatkiem — razem definiują jakość.
Właśnie dlatego team review jest częścią procesu, a nie spotkaniem po zakończeniu pracy.
decyzja nie znika przy przekazaniu
kilka perspektyw nad jednym rezultatem
zmieniamy to, co ma największy wpływ
REVIEW
Cztery pytania przed pozostawieniem zmiany.
Każdy element może wyglądać dobrze w izolacji. Nas interesuje to, czy działa jako część całego systemu. Dlatego review jest celowo niewygodne: szukamy miejsca, w którym rozwiązanie może rozbić rytm, czytelność albo balans.
Dzięki temu kolejne iteracje nie są kosmetyczne. Mają konkretne kryterium, które można ponownie ocenić.
Czytelność
Czy gracz rozumie stan przed decyzją i po niej?
Kontrola
Czy wynik nadal wynika z jakości decyzji?
Interakcje
Czy system współpracuje z power‑upami, bumperami i typami bloków?
Regresja
Czy poprawka nie psuje innego fragmentu doświadczenia?
QA
Test nie zaczyna się po developmencie.
QA wchodzi w pracę wcześniej, bo sytuacje graniczne są częścią designu. Testujemy słabe kąty, serię odbić, nałożenie efektów, przypadki z tarczami i pancerzem, sytuacje z ruchomymi blokami oraz zachowanie po kombinacji power‑upów.
Celem nie jest tylko znalezienie błędu. Celem jest zauważenie miejsca, w którym gracz może stracić zaufanie do reguł gry.
TASK DESIGN
Dobre zadanie ma jasne kryterium jakości.
Zadanie typu „popraw power‑up” jest zbyt szerokie, by dało się je uczciwie zamknąć. Rozbijamy je na konkretniejsze problemy: czy aktywacja jest czytelna, czy interakcja z tarczą zachowuje spójność, czy efekt kończy się w przewidywalnym momencie, czy dodatkowe piłki po Splitterze nadal pozwalają śledzić sytuację.
Taka struktura nie tylko ułatwia implementację. Pozwala zespołowi reviewować wynik w oparciu o wspólny cel zamiast subiektywnego „wydaje się lepiej”.
ITERACJA
Powrót do poprzedniej wersji nie jest porażką.
Iteracja ma sens tylko wtedy, gdy dopuszczamy możliwość odrzucenia własnego rozwiązania. Czasem nowy wariant zwiększa dynamikę, ale obniża kontrolę; czasem ułatwia odczyt, ale spłaszcza decyzję; czasem naprawia jeden typ poziomu i szkodzi innemu. W takich sytuacjach wracamy do prostszego wariantu i szukamy innego kierunku.
Dzięki temu historia wersji jest dla nas narzędziem myślenia, a nie linią, która zawsze musi prowadzić do coraz bardziej rozbudowanej funkcji.
HANDOFF
Przekazanie pracy nie kończy odpowiedzialności.
Wiele problemów powstaje na granicy dyscyplin. Mechanika może być dobrze opisana, ale wizualnie nieczytelna; art może być atrakcyjny, ale zmieniać punkt skupienia; implementacja może być stabilna, ale nie zachowywać dokładnie założonego timing. Dlatego handoff traktujemy jak wspólny checkpoint, a nie formalne oddanie zadania.
Każdy checkpoint ma własne pytanie, które pomaga wychwycić problem zanim przejdzie dalej.
Design → Engineering
czy zachowanie i edge cases są zrozumiałe
Engineering → Art
czy feedback ma stabilny stan do pokazania
Art → QA
czy priorytet wizualny jest jednoznaczny
QA → Team
czy regresja wraca do właściwej warstwy
RELEASE READINESS
Gotowość oznacza spójność, nie brak zmian.
Wersja może nadal mieć przestrzeń na dalszy rozwój, a jednocześnie być gotowa do wydania. Dla nas kluczowe jest to, by bieżący zestaw systemów był zrozumiały, stabilny i nie wymagał od gracza domyślania się reguł. Nowe pomysły mogą poczekać, jeśli nie są potrzebne do obrony obecnego doświadczenia.
Tak rozumiemy release readiness: nie jako perfekcję, ale jako świadomą granicę, po której kolejna zmiana musi mieć nowy uzasadniony cel.
PRODUCTION DEEP DIVE
Proces jest sposobem zarządzania ryzykiem, nie dekoracją do strony „o nas”.
Każda zmiana w grze niesie kilka rodzajów ryzyka naraz. Może być technicznie niestabilna, designowo zbyt silna, wizualnie nieczytelna albo trudna do przetestowania. Jeżeli te ryzyka pojawiają się dopiero na końcu, koszt poprawki rośnie. Dlatego proces rozkładamy tak, by część problemów zobaczyć jeszcze wtedy, gdy rozwiązanie jest małe i łatwe do zmiany.
Pierwsza warstwa to definicja. Opisujemy problem językiem zachowania gracza, a nie nazwy przyszłej funkcji. Druga to hipoteza: co może spowodować zmianę tego zachowania. Trzecia to minimalna implementacja. Dopiero czwarta warstwa pokazuje prawdę — gra zaczyna reagować i można zobaczyć, czy pomysł rzeczywiście działa.
Review jest miejscem, w którym różne perspektywy spotykają się w jednym rezultacie. Projekt patrzy na decyzję, engineering na stabilność zachowania, art na komunikację stanu, QA na edge cases. Zamiast tworzyć cztery osobne listy uwag, szukamy wspólnej diagnozy: gdzie produkt traci czytelność, kontrolę albo spójność.
Iteracja po review jest celowa. Nie poprawiamy wszystkiego jednocześnie. Wybieramy jedną lub dwie rzeczy, które mają największy wpływ na doświadczenie, i sprawdzamy je ponownie. To ułatwia zrozumienie, która zmiana naprawdę pomogła, a która tylko przesunęła problem w inne miejsce.
Dopiero po takim cyklu rozmawiamy o release. Wydanie nie jest momentem, w którym produkt przestaje się zmieniać. Jest momentem, w którym bieżący zestaw decyzji tworzy spójne doświadczenie, a ryzyko znanych problemów zostało sprowadzone do poziomu, który potrafimy świadomie zaakceptować.
W PRODUKCIE
Jak proces wraca do gry.
W Blasty Bubs widać go w strukturze systemów. Bumper nie jest tylko odbijaczem, Ghost nie jest tylko efektem przechodzenia przez blok, a Explosive nie jest tylko większą eksplozją. Każdy element ma zmienić sposób planowania kolejnego ruchu.
Kiedy kilka takich elementów łączy się w jednej planszy, jakość procesu staje się szczególnie ważna, bo drobna niespójność może szybko zmienić kontrolowany chaos w nieczytelność.
CO UZNAJEMY ZA POSTĘP
Więcej kodu nie zawsze oznacza lepszy produkt.
Postęp mierzymy zmianą jakości, a nie liczbą ukończonych ticketów. Zadanie może zostać technicznie zamknięte, ale jeśli nie poprawiło zachowania gracza albo wprowadziło nową nieczytelność, produktowo nie jest skończone. To wymaga odwagi do ponownego otwierania pracy, która wyglądała na gotową.
Z drugiej strony czasem najlepszym wynikiem iteracji jest potwierdzenie, że obecny wariant działa wystarczająco dobrze. Nie musimy zmieniać systemu tylko dlatego, że jesteśmy w stanie wygenerować kolejną wersję. Stabilność i spójność też są wartością.
W pracy zespołowej ważne jest również tempo uczenia się. Mały prototyp, który szybko obala hipotezę, jest cenniejszy niż rozbudowana funkcja, która przez długi czas ukrywała błędne założenie. Dlatego staramy się możliwie wcześnie przechodzić od dyskusji do czegoś, co można zobaczyć i zagrać.
Proces musi być wystarczająco szybki, by uczyć, i wystarczająco spokojny, by nie gubić jakości.
Zbyt długi cykl między hipotezą a testem spowalnia uczenie się. Zbyt szybki release bez review przerzuca koszt na później. Szukamy środka: małe eksperymenty, częste sprawdzenie zachowania i świadome momenty zatrzymania, kiedy decyzja wpływa na kilka warstw produktu.
Ta równowaga pozwala nam utrzymywać tempo bez zamiany produkcji w serię przypadkowych zmian. Szybkość ma wartość tylko wtedy, gdy przyspiesza zdobywanie informacji, a nie samo przesuwanie ticketów.
W praktyce największą wartość ma dla nas informacja, którą można wykorzystać w następnym kroku. Jeżeli test nie prowadzi do konkretnej decyzji, traktujemy go jako zbyt ogólny i zawężamy pytanie. To pozwala ograniczać jałowe poprawki oraz zachować związek między pracą zespołu a jakością produktu.
Podobnie podchodzimy do dokumentowania. Zapisujemy powód zmiany, warunek sukcesu i ryzyko, które chcemy kontrolować. Dzięki temu kolejny review ma punkt odniesienia i nie zaczyna rozmowy od zera.
Ważna jest też odporność procesu na zmianę priorytetu. Jeżeli nowe informacje pokazują, że problem ma mniejszy wpływ niż zakładaliśmy, potrafimy zatrzymać pracę i przesunąć uwagę tam, gdzie efekt dla gracza będzie większy. Dzięki temu roadmapa pozostaje narzędziem decyzji, a nie listą zobowiązań wobec własnych wcześniejszych założeń.
DALEJ
Zobacz, jak ten proces rozkładamy na mechaniki i poziomy.
Proces jest wspólną warstwą, ale konkretne dyscypliny mają inne kryteria jakości. Na stronie projektu gry pokazujemy myślenie systemowe, a na stronie poziomów — sposób budowania sytuacji, w których te systemy naprawdę mają znaczenie.