PYTANIA • PROCES • PRODUKT
Najpierw odpowiadamy o pracy zespołu. Potem o samej grze.
FAQ porządkujemy tak samo jak resztę strony: zaczynamy od sposobu pracy Kertanzip, odpowiedzialności zespołu i procesu decyzji. Dopiero druga część przechodzi do Blasty Bubs, power‑upów, bloków, danych sklepu i wsparcia.
STUDIO I PRACA
Jak pracujemy nad produktem.
Poniższe odpowiedzi opisują nasz model pracy bez wymyślania personalnych biografii, narzędzi czy fikcyjnej chronologii.
Jak zaczynamy nowe zadanie?
Od problemu i oczekiwanego player-visible result. Dopiero potem wybieramy mechanikę, layout, feedback albo zmianę parametru.
Kto odpowiada za decyzję?
Pracujemy wielodyscyplinarnie. Odpowiedzialność zależy od problemu, ale review celowo łączy projekt, implementację, art i QA.
Jak wygląda prototypowanie?
Budujemy najmniejszą wersję, która pozwala sprawdzić hipotezę w ruchu. Nie dopracowujemy rozwiązania wizualnie, zanim nie wiemy, że ma sens systemowo.
Co sprawdzamy na review?
Czytelność, kontrolę, wpływ na istniejące systemy, zachowanie w sytuacjach granicznych i zgodność z obietnicą doświadczenia.
Czy QA jest osobnym końcowym etapem?
Nie. Testy wracają do procesu wielokrotnie, szczególnie przy mechanikach, które łączą fizykę, power‑upy i zmienne stany bloków.
Jak traktujemy feedback?
Jako sygnał do sprawdzenia problemu, nie automatyczny nakaz konkretnego rozwiązania. Najpierw rozumiemy źródło trudności, potem wybieramy zmianę.
Jak decydujecie, co trafi do kolejnej wersji?
Priorytet mają problemy wpływające na czytelność, sprawczość i spójność rdzenia. Nowa funkcja musi uzasadnić własny koszt złożoności.
Czy każda sugestia trafia do backlogu?
Sugestia jest sygnałem. Najpierw identyfikujemy problem, który stoi za nią, a dopiero potem decydujemy, czy właściwym rozwiązaniem jest dokładnie proponowana funkcja.
Jak odróżniacie bug od problemu designu?
Bug łamie oczekiwane zachowanie systemu. Problem designu może działać technicznie poprawnie, ale prowadzić do nieczytelnej lub mało wartościowej decyzji.
Co oznacza dla was balans?
Nie równą siłę wszystkich elementów, lecz taki zakres, w którym różne narzędzia mają własne zastosowania i żadne nie usuwa potrzeby planowania.
Jak dokumentujecie decyzje?
Zapisujemy przede wszystkim problem, wybrane kryterium jakości i powód decyzji. Nie tworzymy dokumentacji tylko po to, by mieć dokument.
Czy projektant i QA patrzą na tę samą rzecz tak samo?
Nie muszą. Projekt koncentruje się na wartości decyzji, QA na przewidywalności i edge case. Wartość review polega właśnie na połączeniu tych perspektyw.
Co robicie, gdy nowa funkcja wygląda dobrze, ale osłabia rdzeń?
Ograniczamy ją, upraszczamy albo usuwamy. Widowiskowość nie jest dla nas wystarczającym powodem, by zostawić system.
Jak pracujecie z trudnością?
Trudność oceniamy przez jakość decyzji i możliwość nauczenia się po porażce, a nie tylko przez liczbę przeszkód.
Czy każda funkcja musi pojawić się na wielu poziomach?
Nie. Niektóre elementy mogą mieć lokalną rolę, jeśli wzmacniają rytm progresji. Ważniejsze jest uzasadnienie niż liczba użyć.
Kiedy kończy się tuning?
Kiedy dalsza zmiana nie daje proporcjonalnej poprawy jakości lub zaczyna szkodzić innej warstwie doświadczenia.
Czy oprawa wizualna wpływa na design?
Tak. Kolor, kontrast, timing i kolejność efektów decydują o tym, czy gracz może prawidłowo odczytać stan systemu.
Dlaczego na stronie jest tak dużo o procesie?
Bo Kertanzip przedstawia Blasty Bubs jako produkt studia. Chcemy pokazać nie tylko co jest w grze, ale też jak myślimy o pracy, jakości i odpowiedzialności.
DLACZEGO TAK PRACUJEMY
Proces ma chronić prostotę produktu.
Fizyczna gra mobilna bardzo łatwo obrasta kolejnymi efektami. Bez jasnego procesu każdy nowy system może zwiększać widowiskowość, a jednocześnie obniżać czytelność. Dlatego nasze review jest celowo konserwatywne wobec funkcji, które nie potrafią uzasadnić swojej roli.
Z punktu widzenia gracza powinno to oznaczać coś prostego: gra może być bogata w interakcje, ale jej zasady pozostają możliwe do nauczenia, a wynik kolejnej próby zależy od lepszego rozumienia, nie od zgadywania.
GRA I SYSTEMY
Co warto wiedzieć o Blasty Bubs.
Ta część dotyczy publicznie dostępnych cech gry i tego, jak wynikają z naszego kierunku produktowego.
Na czym polega podstawowa rozgrywka?
Celujesz piłkami od dołu, planujesz kąt i wykorzystujesz odbicia oraz grawitację, by niszczyć bloki i budować wynik.
Do czego służą bumpers?
Mogą zmienić trajektorię i dać piłce drugą szansę, dzięki czemu układ pozostaje dynamiczny po pierwszym kontakcie.
Jakie power‑upy są w grze?
Google Play wymienia Splitter, Ghost i Explosive. Można je również łączyć, by zwiększać skalę efektu.
Czy bloki różnią się właściwościami?
Tak. Mogą mieć różne kształty, poruszać się lub znikać, a część korzysta z tarcz i pancerza.
Czy są odblokowywane piłki?
Tak. Gra pozwala odblokowywać nowe Bubs, które mają różne statystyki i właściwości.
Czy gra zawiera reklamy i zakupy w aplikacji?
Tak — taką informację pokazuje aktualna karta Google Play.
Gdzie zgłosić problem techniczny z aplikacją?
Skorzystaj z oficjalnego kanału wsparcia wskazanego w Google Play: [email protected].
Czy gra działa offline?
Google Play klasyfikuje ją m.in. jako grę offline. Bieżące wymagania najlepiej sprawdzić bezpośrednio w sklepie.
PRODUKCJA I JAKOŚĆ
Dodatkowe pytania o decyzje, review i odpowiedzialność zespołu.
Ta grupa zbiera pytania, które pojawiają się wtedy, gdy ktoś chce zrozumieć nie funkcję w grze, ale sposób, w jaki studio ocenia jakość.
Co jest ważniejsze: nowa funkcja czy polish?
Zależy od problemu. Jeśli rdzeń jest nieczytelny, polish nie wystarczy. Jeśli system działa dobrze, lepszy feedback może dać większą wartość niż kolejna funkcja.
Czy usuwacie gotowe rzeczy?
Tak, jeśli po review nie bronią się w kontekście całego produktu. Koszt wykonania nie jest wystarczającym powodem, by pozostawić słabe rozwiązanie.
Jak pilnujecie spójności po wielu zmianach?
Przez wspólne kryteria, regresyjne testy kluczowych zachowań i review w kontekście pełnej pętli rozgrywki.
Co oznacza dla was „player-visible result”?
To rezultat, który gracz realnie odczuwa: lepsza czytelność, bardziej interesująca decyzja, stabilniejsze zachowanie lub sensowniejszy rytm.
Czy każda iteracja poprawia grę?
Nie. Iteracja jest eksperymentem. Czasem pokazuje, że wcześniejsze rozwiązanie było lepsze albo że problem leży gdzie indziej.
Jak podchodzicie do nowych pomysłów?
Najpierw sprawdzamy, jaki problem rozwiązują i gdzie pasują do istniejącej pętli. Pomysł bez roli pozostaje pomysłem, nie zadaniem.
Jak oceniacie gotowość do release?
Sprawdzamy spójność kluczowych reguł, czytelność feedbacku, brak blokujących regresji i to, czy bieżący zestaw funkcji tworzy kompletną pętlę doświadczenia.
Czy proces wygląda tak samo dla każdej zmiany?
Nie. Mały tuning parametru może potrzebować krótszej ścieżki niż nowa interakcja systemowa, ale oba nadal powinny mieć jasno określony problem i sposób weryfikacji.
Co robicie, gdy dyscypliny mają różne zdanie?
Wracamy do kryterium produktu: co ma się zmienić dla gracza i jaki wariant najlepiej to realizuje. Spór rozstrzygamy przez rezultat, nie przez hierarchię opinii.
Czy proces zmienia się wraz z produktem?
Tak. Im więcej zależności ma system, tym bardziej formalizujemy review i regresję, ale staramy się nie dodawać procedur, które nie pomagają podjąć lepszej decyzji.
NIE ZNALAZŁEŚ ODPOWIEDZI?
Skontaktuj się z nami.
W sprawach strony, marki i prezentacji produktu użyj kontaktu Kertanzip. W przypadku stricte technicznych problemów aplikacji możesz skorzystać z kanału wsparcia podanego w Google Play.