Zespół Starlight

Mateusz Janeczek, GKM, 201207

Dariusz Jędrzejczak, TGSI, 201208

Krzysztof Kubiak, TGSI, 201216

Geneza pomysłu

Na początku założyliśmy, że projekt, który stworzymy musi tworzyć dopracowaną i zamkniętą całość. Nie było zatem czasu na stworzenie rozległego świata gry. Od razu przedyskutowaliśmy też problem immersji po założeniu Oculusa, którą chcielibyśmy osiągnąć. Konkretnie: jak dostarczyć “mocne wrażenia” bez wzbudzania zawrotów głowy, oraz: jak gracz może poruszać się po świecie gry?

Doszliśmy do wniosku, że najlepiej będzie stworzyć grę symulującą kierowanie jakimś pojazdem wysoko w powietrzu. W ten sposób nie będziemy musieli przygotować zbyt dużej ilości modeli, a widoczny kokpit będzie zawsze punktem odniesienia dla osoby rozglądającej się po wirtualnym świecie. Oprócz tego, poruszanie się będzie najbardziej intuicyjne i naturalne: gracz siedzący fizycznie w fotelu, siedzi również w świecie gry, wewnątrz pojazdu, który się porusza.

Po skonsultowaniu z prowadzącymi zajęcia, zdecydowaliśmy się stworzyć prosty symulator lotu małym statkiem kosmicznym. Ze względu na limit 30 sekund, oraz chęć wprowadzenia definitywnego rozpoczęcia i zakończenia naszej gry, stwierdziliśmy, że statek kosmiczny w naszej grze będzie się poruszał w obrębie pewnej ścieżki, która pozwoli łatwiej kontrolować średni czas rozgrywki.

Jak wygląda rozgrywka

Gracz kieruje statkiem kosmicznym za pomocą joysticka, którego ruchy są odzwierciedlane przez wirtualny odpowiednik. Może swobodnie rozglądać się po kokpicie. Rozpoczyna rozgrywkę w hangarze stacji kosmicznej. Stąd wylatuje do wnętrza tunelu umieszczonego w przestrzeni kosmicznej. Wewnątrz tunelu są rzadko rozmieszczone kosmiczne kamienie -- asteroidy, których gracz ma za zadanie unikać bądź zestrzeliwać. Ściany tunelu składają się z gęstszego obszaru podobnych kamieni.

Autopilot utrzymuje statek wewnątrz tunelu, oddalając go od ścian, gdy się do nich zbliży. Po pokonaniu pewnego dystansu, statek wylatuje z pasa asteroid i wchodzi w prędkość nadświetlną, dzięki czemu w krótkim czasie dolatuje do drugiego obszaru kosmicznych kamieni. Kiedy z niego wylatuje, autopilot nakierowuje go na wahadłowiec, inicjując sekwencję dokowania kończącą naszą grę.

Gra została zaprojektowana tak, żeby dało się ją ukończyć bez względu na umiejętności gracza. Uderzenie w asteroidę skutkuje jedynie odepchnięciem statku i uruchomieniem alarmu w kokpicie. Nie ma możliwości zawrócenia ani zboczenia z ustalonej trasy.

Poniższe zrzuty ekranu przedstawiają rozgrywkę:

Co zostało zrobione

Algorytm generatora tunelu, który za każdym razem tworzy nową ścieżkę na podstawie zadanych parametrów.
Sterowanie za pomocą joysticka oraz mechanika autopilota, który uniemożliwia zawrócenie statku, czy wydostanie się z tunelu.
Mechanika strzelania.
Animacja oraz mechanika dokowania statku.
Interfejs, panele informacyjne w kokpicie.
Modele stworzone na potrzeby tego projektu:

Statek kosmiczny razem z wnętrzem
Stacja kosmiczna, w której zaczyna się rozgrywka
Wahadłowiec
Asteroidy

Modele zaimportowane:

Stacje kosmiczne, które gracz mija po drodze, służące za urozmaicenie

Użyte narzędzia

Oprogramowanie i języki użyte do stworzenia dema:

Silnik Unity 5 + MonoDevelop + C#
Gimp
3ds Max

Oprogramowanie do zarządzania projektem:

GitHub
Google Docs
Skype

Sprzęt:

Oculus
Joystick Logitech WingMan Extreme Digital 3D

Napotkane problemy projektowe i rozwiązania

Okazało się, że nie ma możliwości stworzenia ściany tunelu z asteroid, która uniemożliwiałaby przedostanie się przez nią i jednocześnie wyglądała naturalnie. Zostaliśmy zmuszeni stworzyć mniej zwartą ścianę oraz autopilota, który będzie uniemożliwiał jej przekroczenie.

Kamienie tworzące tunel, którego pokonanie zajęłoby 30 sekund były zbyt liczne, żeby można je było generować i wyświetlać jednocześnie zachowując przy tym odpowiednią płynność działania aplikacji. W związku z tym podzieliliśmy tunel na dwie części i pomiędzy nimi wstawiliśmy sekwencję prędkości nadświetlnej, żeby skrócić czas przelotu pomiędzy nimi. Wprowadziło to dodatkowo urozmaicenie rozgrywki.

Autopilot okazał się dobrym rozwiązaniem problemu, ale nie był zbyt intuicyjny dla gracza, więc zaimplementowaliśmy interfejs wewnątrz kokpitu. Jego dwa główne składniki to panel wyświetlający aktualny cel lub stan statku oraz duży, niebieski napis “AUTOPILOT” wyświetlający się za każdym razem, gdy sterowanie jest graczowi z jakiegokolwiek powodu odbierane.

Elementy, które okazały się sukcesem

Zdefiniowany od początku design, wymagający minimalnej liczby assetów.
Joystick jako kontroler -- pasował do świata gry, był intuicyjny dla użytkowników.
Interakcja -- strzelanie do kamieni -- zwiększyła pozytywne wrażenia.
Dopracowanie szczegółów -- efekty dźwiękowe i wizualne, wstrząsy kamery, realistyczne sterowanie -- wszystko skomponowało się w spójną całość przyjemną do odbioru dla użytkowników.
Użyte narzędzia i języki programowania pozwoliły na bezproblemowe i szybkie stworzenie aplikacji.
Dobra komunikacja w zespole.
Współpraca z prowadzącymi i organizatorami konkursu.
Udało się osiągnąć wysoki poziom satysfakcji użytkowników.
Cały projekt należy zaliczyć do udanych, o czym świadczy zajęcie II miejsca w konkursie.

Elementy wymagające usprawnień lub zmian

Autopilot -- użytkownicy byli często sfrustrowani lub skonfundowani tym, że czasami odbierane im było sterowanie. Pomimo napisu informującego o jego działaniu mechanizm okazał się zbyt mało intuicyjny i podczas finału konkursu wiele osób nie wiedziało, dlaczego statek sam skręca.
Autopilot okazał się niepotrzebnym ograniczeniem. Usprawnieniem byłoby tu zastąpienie go swobodnym poruszaniem się po losowo wygenerowanym świecie z odpowiednimi checkpointami. Gdybyśmy robili ten projekt od nowa, rozważylibyśmy zaniechanie pomysłu ze ścieżką po której gracz musi się poruszać na rzecz otwartej przestrzeni z grupami rzadkich kamieni, którą gracz może swobodnie przemierzać.
Interfejs -- mimo, że czytelny, minimalistyczny i zanurzony w świecie gry, to okazał się niewystarczająco dopasowany do dynamizmu rozgrywki i część informacji umykała użytkownikom. Potencjalnym usprawnieniem jest wprowadzenie informacji w formie dźwiękowej uzupełniającej wizualną.
Uważamy, że głos dodatkowo instruujący, co robić w grze byłby bardzo pomocny w orientacji. Na dodatek, taki głos mógłby pogłębić immersję, jeśli wydobywałby się z wirtualnego głośnika w kokpicie jako głos autopilota.
Brak modelu gracza w świecie gry ujmował wrażeniu immersji. Decyzja nieumieszczenia modelu była spowodowana jednak brakiem czasu i środków na stworzenie satysfakcjonującego modelu i animacji.
Ogólnie rzecz biorąc, należałoby uwydatnić wszelkie cechy powodujące wrażenie swobody interakcji u użytkowników i zredukować postrzegane ograniczenia.
Powinniśmy usprawnić śledzenie czasu (początkowe oszacowania vs. rzeczywistość) i innych statystyk projektu. Część początkowych oszacowań okazała się nieadekwatna. Szczególnie końcowa część projektu zajęła więcej niż przewidywano.
W planowaniu powinniśmy wziąć pod uwagę wymagania wydajnościowe (co pozwala zredukować konieczność optymalizacji).

Źródła

https://en.wikipedia.org/wiki/Postmortem_documentation
http://www2a.cdc.gov/cdcup/library/pmg/implementation/ll_description.htm
Raporty z projektu stworzone w ramach zajęć