Strona SoInteractive to efekt wielu burzliwych dyskusji i cieżkiej pracy ludzi biorących udział w projekcie, czyli:

Michał Sycz aka. Majkel
Piotrek Rachtan aka. Piter
Bartek Mikołajczyk aka. Bart
Paweł Jaruga aka. Levus
Maksymilian Chmiel

Dzięki! Great Job! :)

Wstępny projekt strony zakładał podział na dwie części. Cześć zawierająca treści miała zostać wykonana w technologii 2D, natomiast gra miała używać 3D.

Wpierwszej kolejności przygotowaliśmy koncept graficzny (Michał Sycz), Modele 3D (Paweł Jaruga) oraz bazowe elementy engine’u strony (Piotrek Rachtan), odpowiedzialne za komunikacje z serwerem, menu uwzględniające nawigację za pomocą adresów url (swfaddress), obsługę wersji językowych itp.

Boss

Prawa ręka bossa

Designer

Programista

Project manager

Szkice

Szkice / rysunki / bazgroły

Kiedy projekt graficzny był gotowy przystapiliśmy do kolejnego etapu - gra.

Projekt gry (Photoshop only)

Na potrzeby gry wykorzystaliśmy szybki i wydajny silnik 3D stanowiący kluczowy element gry.  Po wykonaniu kilku testów, spośród kilku dostępnych, postanowiliśmy wybrać papervision3D v2.0 Mimo braku niektórych funkcjonalności wydawał się być wystarczająco wydajny do naszego projektu. Istotne znaczenia miał również fakt, iż silnik ten z powodzeniem używany był już wcześniej przez naszych programistów. Silnik niestety nie posiada parsera plików formatu OBJ używanego do zapisu naszych modeli 3D. Konieczne więc okazało się zaadoptowanie parsera dostępnego w innych silnikach na potrzeby pv3D. Skonstruowana w ten sposób scena wyglądała bardzo dobrze, a wybrany silnik pracował wystarczająco wydajnie - dodaje Piotrek.

Drugim istonym elementem gry było użycie silnika fizyki. To na nim spoczywa odpowiedzialność za symulowanie sił działających na elementy gry oraz wykrywanie i generowanie odpowiedzi na kolizję obiektów. Stanowi bardzo istotny element wpływający na “grywalność”.

W pierwszej kolejności postanowilismy sprawdzić dostępne w sieci dla pv3D, gotowe silniki takie jak JiglibFlash, lub WOW Physic Engine. Niestety okazało się, że w naszym zastosowaniu silniki te się nie sprawdzają. Nasza scena zawiera wiele nieregularnych kształtów a aproksymowanie ich prostokątami (box’ami) dostępnymi w silnikach jest niewystarczające. Kulki-pociski przenikają przez postacie lub odbijają się od pustych przestrzeni je otaczających. Drugim poważnym problemem było przenikanie pocisków. Wykrywanie kolizji prowadzone było tylko na początku i końcu kroku symulacji co okazało się niewystarczające przy dużych prędkościach pocisków. Zaś zmniejszenie kroku symulacji odbijało się drastycznie na wydajności. Problemy te wymusiły konieczność napisania własnego, prostego silnika fizycznego, dostosowanego do naszych potrzeb.

Stworzony silnik zapewniał prawidłową detekcję kolizji rozwiązując problem przenikania oraz  umożliwił wykrywanie jej pomiędzy sferą a siatką modelu 3D, umożliwiając dokładne wykrywanie zderzeń z nieregularnymi kształtami naszych postaci. Dodatkowo, zastosowane optymalizacje zapewniły wysoką wydajność silnika. W czasie testów, mimo użycia ponad 100 pocisków gra działała z akceptowalną płynnością, w wersji końcowej zdecydowałem się jednak zredukować liczbę widocznych na scenie pocisków do 20 aby zapewnić poprawną płynność na starszych komputerach - dodaje Piotrek.

W celu uatrakcyjnienia gry postanowiliśmy dodać możliwość oddawania strzałów przy użyciu mikrofonu. Technika ta sprawdziła się całkiem dobrze, a po uruchomieniu strony była skutecznie i kreatywnie testowana przez resztę zespołu np.: poprzez przykładanie mikrofonu do głośników radia lub stukaniem nim o biurko.

Wstępny modeling 3D

Siatka gry 3D

Mapowanie tekstur postaci

Gra - screenshot #1

Gra - screenshot #2

Gra - screenshot #3

Po zamknięciu prac nad grą uznaliśmy, że wybrany silnik 3D sprawdza się bardzo dobrze i można go użyć w części zawierających treść. Przygotowane wcześniej elementy 2D które miały stanowić pozostałą cześć stron, zostały odtworzone w 3D przy użyciu gotowych już modeli. W trakcie tworzenia efektów przełączania podstron pomocne okazały się dostępne biblioteki TweenMax oraz As3Mod.

Ostatnim etapem było przygotowanie części video, czyli wielogodzinne nagrania z wykorzystaniem między innymi greenbox’a oraz postprodukcja video z użyciem zaawansowanego systemu kluczowania, czyli wielogodzinne Barta klikanie :)

Produkcja wideo w studio greenscreen

Na koniec zostało już tylko jedno wyzwanie - interfejs odtwarzacza video, który należało zaprogramować w przestrzeni 3D, a w szczególności interakcji z elementami kontrolnymi (play, pause, timeline itp.) za co odpowiedzialny był nasz czołowy flash developer - Piotrek :)

Na koniec kilka statystyk, całkowity kod strony zawiera 12 579 linii kodu i został podzielony na 65 plików.

Dla zainteresowanych publikujemy pełny kod gry ;)