Założenie
Definiujemy jedno zachowanie, które ma być czytelne dla gracza i wskazujemy, po czym rozpoznamy poprawę.
Wizualizacja koncepcyjna przygotowana dla strony Selvaram; nie jest zrzutem ekranu z gry ani dokumentacją rzeczywistego biura.
Rozwój produktu
Rozwijamy Underground Racing jako połączony system
Rozwój Underground Racing opisujemy przez decyzje projektowe, iterację, współpracę i obserwowalne zachowanie produktu. Nie dopisujemy niepotwierdzonej chronologii, narzędzi, budżetu ani kulis produkcji; skupiamy się na tym, jak zespół porządkuje problem i sprawdza rezultat.
Rozwój zaczyna się od odpowiedzialności za doświadczenie
Dla Selvaram rozwój nie jest linią od funkcji do publikacji. Każda zmiana ma wpływ na kilka warstw naraz: wejście wpływa na sposób prowadzenia, prowadzenie na tempo sceny, a tempo na to, jak użytkownik odczytuje światło i zagrożenia.
Dlatego przed implementacją ważne jest zdefiniowanie efektu, który ma pozostać stabilny niezależnie od urządzenia i sytuacji. To ogranicza przypadkowe rozwiązania, które dobrze wyglądają w jednym ujęciu, ale nie składają się na spójny produkt.
01
Wyzwanie: szybkość bez utraty orientacji
Szybka jazda działa tylko wtedy, gdy gracz nadal rozumie kierunek, zagrożenie i reakcję auta. Kompozycja miasta, kamera i wejście muszą przekazywać tę samą informację. Im mocniejszy efekt ruchu, tym ważniejsza staje się kontrola kontrastu, punktów odniesienia i przewidywalności reakcji.
Wariant
Budujemy kilka sposobów osiągnięcia celu, aby porównać kompromisy zamiast dopracowywać pierwszy pomysł bez alternatywy.
Test
Sprawdzamy reakcję na różne wejścia, tempo sceny, zachowanie na urządzeniach i potencjalne regresje w sąsiednich systemach.
Korekta
Wzmacniamy to, co działa, i usuwamy elementy tworzące hałas, opóźnienie albo dodatkową niepewność dla gracza.
Zmiana przechodzi między dyscyplinami, zanim trafi do produktu
Przy szybkiej jeździe jedna decyzja rzadko ma tylko jednego właściciela. Modyfikacja sterowania może wymagać innej kamery, zmiana oświetlenia może wpłynąć na rozpoznanie krawędzi drogi, a mocniejszy efekt kolizji może zmienić obciążenie i czytelność sceny.
Dlatego przekazanie pracy między projektem, oprawą i QA traktujemy jako część samej decyzji. Każdy etap powinien wiedzieć, czego nie wolno zgubić: celu dla gracza, sposobu reakcji i kryterium, po którym rozpoznamy regresję.
Projekt
definiuje zachowanie i granice decyzji
Oprawa
buduje hierarchię informacji i atmosferę
QA
sprawdza przewidywalność, wydajność i regresję
Sterowanie jako część projektu, nie ustawienie po fakcie
Changelog Google Play wymienia kierownicę, Tilt/Gyro i gamepad. Z punktu widzenia procesu oznacza to kilka charakterystyk wejścia, które trzeba oceniać pod kątem reakcji, przewidywalności, zakresu ruchu i ergonomii. Sama obecność przełącznika nie mówi jeszcze, czy zachowanie jest spójne z pozostałymi metodami prowadzenia.
Miasto buduje sytuacje
Tunele, otwarte arterie, mokra nawierzchnia, billboardy i presja pościgu dają różne punkty odniesienia. Ich wartość projektowa wynika z tego, jak zmieniają czytanie prędkości i przestrzeni. Świat nie jest więc osobnym tłem: staje się częścią informacji potrzebnej do podejmowania decyzji podczas jazdy.
Przegląd łączy projekt z kryteriami QA
Po zbudowaniu wariantu patrzymy nie tylko na to, czy działa technicznie. Oceniamy, czy zachowanie ma wyraźny cel, czy reakcja jest konsekwentna i czy scena pozostaje czytelna przy presji ruchu.
Jeśli odpowiedź jest niejednoznaczna, wracamy do założenia albo wariantu. To ważniejsze niż dokładanie kolejnej warstwy efektu do rozwiązania, którego fundament nadal nie jest stabilny.
cel i kryterium akceptacji
spójność wejścia
czytelność przy prędkości
stabilność sceny
regresja w sąsiednich systemach
Rezultat ma być odczuwalny, ale nie wymagać wyjaśnienia
Dobrze zamknięta decyzja rozwojowa powinna działać w ruchu: gracz czuje różnicę w prowadzeniu lub tempie, widzi drogę mimo efektów i może przewidzieć odpowiedź systemu. To jest bardziej użyteczny rezultat niż sama lista nowych elementów.
Dokumentujemy założenie, żeby kolejna iteracja nie zaczynała od zera
Najbardziej użyteczny zapis nie opisuje wszystkiego. Powinien utrzymać cel, wybrany wariant, znane kompromisy oraz scenariusze, które trzeba ponownie sprawdzić po następnej zmianie. Dzięki temu iteracja zachowuje ciągłość bez tworzenia fikcyjnej historii produkcji.