Studio Selvaram

Selvaram buduje Underground Racing przez współpracę

Studio Selvaram przedstawiamy przez sposób podejmowania decyzji, współpracę między dyscyplinami i odpowiedzialność za produkt. Nie potrzebujemy fikcyjnej historii firmy, aby pokazać, jak organizujemy pracę wokół Underground Racing.

Koncepcyjna sesja współpracy przy moodboardzie nocnego miasta, materiałach i szkicach
Wizualizacja koncepcyjna przygotowana dla strony Selvaram; nie jest zrzutem ekranu z gry ani dokumentacją rzeczywistego biura.
01

Czytelność przed efektem

Najpierw sprawdzamy, czy decyzja pomaga prowadzić, orientować się i rozumieć sytuację; dopiero potem wzmacniamy spektakl wizualny lub dźwiękowy.

02

System przed detalem

Patrzymy na zależności między sterowaniem, przestrzenią, kamerą, tempem, dźwiękiem i obciążeniem zamiast optymalizować każdy element w izolacji.

03

Iteracja przed przywiązaniem

Pierwsza atrakcyjna wersja nie ma specjalnego statusu. Porównujemy warianty i zostawiamy ten, który lepiej służy całemu doświadczeniu.

04

QA jako część projektu

Testowanie wpływa na dalsze decyzje projektowe. Jeśli QA pokazuje problem w czytelności lub przewidywalności, wracamy do projektu zamiast traktować go jako wyłącznie techniczną usterkę.

Współpraca zaczyna się od wspólnego pytania

Dyscypliny mogą mieć różne narzędzia, ale powinny rozwiązywać ten sam problem. Projekt pyta o zachowanie, art direction o czytelność i atmosferę, a QA o przewidywalność i granice działania.

Takie ustawienie ogranicza sytuacje, w których jedna warstwa jest dopracowana kosztem innej. W praktyce ważniejszy jest wspólny rezultat niż to, do którego działu formalnie należy pojedyncza zmiana.

  • co ma odczuć gracz
  • co musi pozostać czytelne
  • jakie wejścia zmiana dotyka
  • gdzie może pojawić się regresja

Sesja robocza ma zamienić opinię w decyzję

Kiedy kilka dyscyplin patrzy na ten sam problem, łatwo zatrzymać się na zdaniach typu „wygląda lepiej” albo „prowadzi się gorzej”. Staramy się zamieniać takie wrażenia na pytania, które można sprawdzić: gdzie gracz traci orientację, kiedy reakcja staje się zbyt nerwowa, który kontrast znika w ruchu i co dzieje się na innym wejściu.

Taki sposób rozmowy pomaga rozdzielić gust od funkcji. Nie eliminuje artystycznej oceny, ale osadza ją w celu produktu i pozwala wrócić do konkretnego wariantu zamiast prowadzić dyskusję wyłącznie na poziomie preferencji.

  • obserwacja
  • hipoteza
  • wariant
  • test
  • decyzja

Praca rozkłada się na role, ale efekt musi być wspólny

Projekt produktu, mechanika, kierunek wizualny, dźwięk, wydajność i testy spotykają się przy wspólnych punktach kontrolnych. Opisujemy te odpowiedzialności na poziomie funkcji, bez publikowania nazwisk, liczebności zespołu, stanowisk czy biografii, których nie otrzymaliśmy jako potwierdzone dane. Dzięki temu strona pokazuje model współpracy bez budowania sztucznego korporacyjnego życiorysu.

Jak porządkujemy decyzję

Każda większa zmiana przechodzi przez cztery warstwy oceny.

Cel

Jaki problem produktu lub doświadczenia ma rozwiązać zmiana?

Zachowanie

Jak wpływa na sterowanie, tempo, orientację lub odbiór sceny?

Koszt uboczny

Czy poprawa jednego obszaru osłabia inny, np. czytelność albo wydajność?

Dowód

Jak sprawdzimy w QA, że rezultat działa poza idealnym scenariuszem?

Selvaram i Underground Racing

Na tej stronie Underground Racing jest produktem Selvaram zgodnie z relacją przekazaną przez właściciela projektu. Karta sklepu pozostaje osobnym źródłem informacji o funkcjach, wersji i dystrybucji, gdzie produkt widnieje pod kontem KALIKO. Nie używamy tego wpisu jako dowodu własności Selvaram; zachowujemy oba fakty oddzielnie.

Studio nie kończy pracy w chwili publikacji zmiany

Nowa wersja produktu tworzy nowy punkt odniesienia dla kolejnych decyzji. Dlatego poprawki wejścia, głośności, misji czy sposobu prezentacji scen warto traktować także jako materiał do regresji.

Nie opisujemy niepotwierdzonej roadmapy ani terminów. Pokazujemy natomiast zasadę ciągłości: zmiana jest częścią systemu i po wdrożeniu nadal musi współpracować z pozostałymi elementami produktu.

Zobacz proces w ruchu

Rozwój pokazuje, jak przechodzimy od problemu i wariantu do testowalnego doświadczenia, bez dopisywania niepotwierdzonej chronologii produkcji.