Wykonane i niewykonane zadania


Tomasz − Fizyka, Logika, Architektura    


Cele

  • Współudział w stworzeniu architektury,
  • Fizyka w grze,
  • Logika wyścigu na serwerze,

Osiągnięte cele

  • Architektura − została wybrana taka, która jest prosta i powinna stworzyć najmniej problemów, ale z założenia wymaga gry po LANie. Projekt został podzielony na oddzielną aplikację serwera i klienta, czemu byłem przeciwny.
  • Fizyka − Została zrobiona w pierwszej wersji i nie rozwinęła się.

Nie osiągnięte cele

  • Logika − z powodu opóźnień i trochę rezygnacji nie zrobiłem jej.

Problemy nietechniczne

  • Tylko małe − po raz pierwszy obsługiwałem Physx'a w projekcie i musiałem zapoznać się dokładniej z nim.

Model fizyczny samolotu


Samolot (tylko 1 model samolotu focke wulf 190) został podzielony na kawałki i ręcznie zaproksymowany boxami, kapsułą i kołami. W tym modelu przyjąłem, że każdy box jest dosyć płaski i tylko siła oddziaływania powietrza na jedną płaszczyznę jest istotny. Wzór na siłę jest postaci:

F = ro * A * <V, n> * |V|,

gdzie ro to gęstość powietrza,
A po pole powierzchni,
V to prędkość wiatru względem powierzchni.


Parametr A nie został wzięty z rzeczywistego pola powierzchni boxa, ale dobrany na oko, ponieważ sam rozmiar boxa był dobrany na oko. Boxy poziome, to skrzydła i stateczniki poziome. Pionowe to statecznik pionowy i kadłub. Każdy box dodatkowo stawia opór o wartości:

R = ro * V * B * (1 + C * |V|),

gdzie współczynniki B i C zostały dobrane na oko.


Interakcja z innymi obiektami − realizuje to już PhysX. Cały ten Framework umożliwił łatwą obsługę wielu rzeczy, np. detekcja kolizji. Gdyby robić samochód, a nie samolot, to Framework ten obsłużyłby wszystko, więc nie trzeba by samemu tworzyć modelu pojazdu. Dzięki temu samolot może wylądować i wystartować. Współczynniki, lub inne elementy miały zostać poprawione, jak interfejs umożliwi dobre testowanie lotu, ale nie wyrobiliśmy się czasowo.

Czas poświęcony: około 50 godzin



Krzysztof − Grafika, GUI, Architektura, IO    


Moimi celami w aplikacji były

  • Współudział w stworzeniu architektury,
  • Konfiguracja środowiska programistycznego,
  • Grafika − model samolotu, terenu,
  • Interfejs użytkownika.

Osiągnięte cele


W trakcie tworzenia aplikacji powstawały kolejne problemy, dlatego chcąc nie chcąc musiałem również zająć się obsługą myszy i klawiatury, ponieważ bez tych dwóch elementów dalsze tworzenie i testowanie aplikacji nie mogłoby się odbyć. Spowolniło to moje prace oraz uniemożliwiło realizację wszystkich postawionych celów.
Engine renderujący jaki użyłem − Ogre 3D. Mając doświadczenie w tworzeniu aplikacji używając tego narzędzia sama obsługa wyświetlania nie sprawiała problemów. Jednym z pierwszych kroków było utworzenie interfejsu graficznego. Do tego użyłem nie znanej mi biblioteki ale wspieranej przez Ogre 3D mianowicie CEGUI. Tworzenie było przyjemnym oraz ciekawym doświadczeniem. Biblioteka posiada dodatkowo narzędzie wspomagające tworzenie interfejsu CELayout Editor. Ponieważ korzystaliśmy z najnowszej dostępnej wersji Ogre 3D pojawiły się problemy z częścią funkcjonalności edytora. Zostały one jednak szybko rozwiązane poprzez kompilację źródeł z najnowszą wersją Ogre 3D.
Kolejnym etapem było stworzenie terenu. Tu z pomocą przyszło narzędzie FreeWorld Editor. Narzędzie dostępne w wersji beta powodowało dużo błędów, co spowalniało pracę. Ponadto menadżer sceny Ogre 3D nie posiadał części funkcjonalności oferowanej przez edytor, dlatego nie można było wykorzystać jego pełnej mocy.
W końcu przyszedł czas na model samolotu. Z pośród jakby się mogło wydawać ogromnej ilości darmowych modeli dostępnych w Internecie jedynie mała części spełniała nasze wymagania (lecz i tak nie w całości). Do podziału samolotu na części zgodnie z ustaleniami Tomka wykorzystałem 3D Studio Max 2008. Mimo znajomości narzędzia (małej bo małej) udało się dokonać podziału samolotu co umożliwiło animację jego lotu. Z braku czas podział nie jest szczegółowy, tzn. nie ma animowanych stateczników, lotek itp. Konwersja modelu z formatu .3ds do formatu Ogre 3D .mesh odbyła się za pomocą narzędzia 3ds2mesh dostępnego na stronie Ogre 3D.
Tworzenie systemu cząstek było ciekawym doświadczeniem. System skryptowy Ogre 3D bardzo ułatwiał testowanie − nie było konieczności rekompilacji kodu za każdą małą zmianą. Z pomocą przyszedł Particle Editor również dostępny na stronie Ogre 3D.
Do tworzenia tekstur wykorzystałem Adobe Photoshop 7.0.

Czas poświęcony: około 100 − 150 godzin



Piotr − Team Leader, Zarządzenie zespołem, AI, Architektura    


Główne zadania, które miały być rozwiązane w ramach projektu

  • Zorganizowanie zespołu i współpracy wewnątrz niego,
  • Opracowanie i zaprogramowanie funkcjonalności sztucznej inteligencji.

Osiągnięte cele


Co dotyczy organizacji pracy jako zespołu to spełnił on moje najśmielsze oczekiwania.
  • Poza tym, że nie miałem możliwości motywacji zespołu, a i tak każdy potrafił być twórczy i znaleźć rozwiązania w ramach własnej części.
  • Utrudnienia w modułowym podziale całej naszej pracy sprawiał sam język C++ wraz z Ogrem i Physixem. Nie udało się rozdzielić na 5 równych, niezależnych części, głównie z powodów ode mnie niezależnych.
  • Największe problemy pojawiły się z chwilą pozwolenia sobie zapomnieć o harmonogramie. Drobne (tygodniowe) opóźnienie od harmonogramu, od razu po nim zaliczenia z innych przedmiotów wywołały nieuniknione problemy później i jako wynik niektóre końcowe etapy w tworzeniu projektu przestały istnieć.
  • W ramach takiego zespołu jak nasz, podział pracy na maksymalnie niezależne i pozwolenie do kreacji we własnym rozumieniu sprawdziły się bardzo dobrze. Brakowało tylko jeszcze większej niezależności i środków motywacji w trakcie.

Co dotyczy sztucznej inteligencji: oprogramowana; potrzebny czas i narzędzia do przetestowania i sprawdzenia w działaniu.
  • Było znalezione rozwiązanie dla niezależnego obliczenia toru lotu samolotu−komputera uczestniczącego w wyścigach. Rozwiązanie zostało oprogramowane i przetestowane w innym środowisku w wersji 2D z bezpośrednim przeniesieniem jego na 3D.
  • Ze względów niezależności rozwiązania od fizyki i jego odrzucenia po etapie implementacji i przed podpięciem, była podjęta próba implementacji PID−przejęcia kontroli nad samolotem na życzenie użytkowników. Brak czasu (zadanie powstało po implementacji poprzedniego rozwiązania w czasie przeznaczonym na połączenie modułów i poprawę błędów) oraz możliwości do przetestowania rozwiązania (brak komputera obsługującego) nie pozwoliły sprawdzić i ewentualnie poprawić rozwiązanie. W końcowej wersji zostało to ograniczone do sterowania samolotem na minimalnej prędkości z utrzymaniem wysokości.
  • Poza tym, wiedząc, na co każdy jest zdolny postarałem się rozłożyć prace i dać możliwość się wykazać każdemu, sprowadzając kontakt, uzależnienie i oczekiwanie na Coś do minimum. To co powstało jest wynikiem zaangażowania. Kto ile mógł i chciał na to poświęcić – tyle poświęcił i to (w takim stanie) mamy.

Czas poświęcony: około 100 − 150 godzin



Screen'y z pracy



Rys.1. Brak istnienia trasy przelotu.


Rys.2. Trasa przelotu znaleziona.


Rys.3. Wyznaczona gładka trasa przelotu.



Michał − IO, Audio, Architektura    


Cele

  • Moduł obsługi wejścia − wyjścia oraz dźwięku odostępnia funkcje związane z klawiaturą, myszą, joystickiem oraz z dźwiękiem. Do jego implementacji została wykorzystana biblioteka SDL.
  • Opracowanie i zaprogramowanie funkcjonalności sztucznej inteligencji.

Czas poświęcony: około ? godzin



Dawid − Sieć, Audio, Architektura    


Cele


Moim głównym zadaniem w projekcie było zbudowanie architektury sieci i jej implementacja. Posłużyłem się w tym celu darmową biblioteką OpenTNL do obsługi sieci. Z uwagi na architekturę projektu uniemożliwiającą uruchomienia gry bez wcześniejszego uruchomienia serwera, sieć pełni bardzo ważną rolę łączącą silnik fizyczny i grafikę(nawet gdy jest tylko jeden gracz). Oprócz spełnienia oczywistych wymagań funkcjonalnych starałem się zaimplementować ją jak najbardziej wydajnie wykorzystując wszystkie możliwe narzędzia udostępnione przez bibliotekę OpenTNL. Wydaje mi się, że stworzyłem architekturę umożliwiającą łatwe modyfikacje a jednocześnie będącą czytelną i prostą w wykorzystaniu przez obie strony (grafikę i fizykę). Dzięki wybranej przez nas architektury gry, właściwie nie istnieje problem synchronizacji (na klientach nie jest obliczana fizyka), jednak stało się to kosztem zwiększenia ilości wysyłanych danych przez sieć. Najważniejszą funkcjonalnością optymalizacyjną, którą wykorzystałem było maksymalne zminimalizowanie wysyłanych danych odnośnie stanu samolotów, tzn nie wysyłam informacji które się nie zmieniły bądź w

Podstawowe funkcjonalności sieci

  • Wyszukiwanie, łączenie, rozłączanie się od dostępnych serwerów,
  • Decyzja o rozpoczęciu(odliczaniu) i zakończeniu gry,
  • Aktualizacja zmienianych danych we wszystkich kierunkach (klient−>serwer−>pozostali klienci),
  • Przesyłanie wiadomości, eventów(wybuch, dotknięcie, checkpoint), zmiany typów player'ów itd.


Problemy

  • zrozumienie działania biblioteki, i jej możliwości które należy wykorzystać w naszym projekcie(w tym celu na początku stworzyłem i testowałem małą grę poruszających się kwadracików),
  • problemy związane z językiem C++ (zawodowo programuję w C#), bibliotekami, ustawieniami projektów itd.,
  • najbardziej czasochłonny problem: musiałem zmienić bibliotekę OpenTNL w celu trzymania się mojej architektury sieci.


Zrealizowane cele

  • Wydaje mi się, że w kontekście sieci udało się zaimplementować wszystko, co było potrzeba i co zaplanowałem sobie od początku,
  • Niestety z uwagi na braku testów na obciążenie, ogólnego rzetelnego sprawdzenia działania gry, gdy podłączy się więcej klientów nie jestem w stanie powiedzieć czy jestem do końca usatysfakcjonowany z tego co udało się napisać..


Czas poświęcony: około ? godzin



Opinia Team Leader'a o zespole


Tomek


Mimo zwlekania i niechęci zrobił fizykę − dokładnie to, co trzeba w terminie dla pokazania. Logika nie rozpoczęta. Nie rozumiem, dlaczego we własnym, osobnym projekcie trzeba się starać nie robić nawet prostych rzeczy, albo czekać, żeby ktoś je robił. Mimo trudu z dogadywaniem się wniósł bardzo wiele w każde spotkanie i projekt w całości. Osobne podziękowanie za poprawienie błędów i umożliwienie pracy Joysticka.

Krzysztof


Zła organizacja własnej pracy − przy takim nakładzie, robienie dla i zamiast kogoś jest niedozwolone, co odbiło się na tak dużym opóźnieniu z powstaniem końcowej wersji grafiki. Takie sprawy i problemy powinny być zgłaszane o wiele wcześniej i rozstrzygane bardziej restrykcyjnie wobec innych członków zespołu. Ale to nie zmienia faktu, że grafika jest przykładem kreatywnego podejścia i zaangażowania w pracę. Szczególne znaczenie ma rozwiązywanie wielu problemów w trakcie tworzenia projektu dla wszystkich oraz wypożyczenie komputera dla zrobienia części Piotrka. Największy i najwidoczniejszy wkład.

Piotrek


Brak tygodniowych indywidualnych rozmów z członkami po pewnym czasie doprowadził do straty kontroli nad częściami projektu, problemami niezgłoszonymi, zaniedbaniami. Najwięcej czasu stracono na to, co tak naprawdę nie było wymagane i nie zostało użyte i pozostawienie obowiązkowej części na dorobienie. Wymyślone ciekawe rozwiązanie − algorytm. Dokończenie obowiązkowej części sztucznej inteligencji mimo braku własnego komputera. Jedyne słuszne rozwiązanie organizacji dla zupełnie losowego składu zespołu.

Michał


Zwlekanie z koniecznymi na początkowym etapie rozwiązaniami i ze zrobieniem minimum. Wymuszenie do poprawiania własnych błędów innych osób. Brak koniecznej w przypadku wejścia-wyjścia konstruktywnej współpracy z członkami zespołu oraz zaangażowania w spotkaniach. Dźwięki są w stanie najsurowszym. Są widoczne efekty pracy, ale wszystko do poprawienia i zazwyczaj przez innych.

Dawid


Problemy są by ich rozwiązywać, a nie przejmować się. Współpraca i zaangażowanie się na najwyższym poziomie. Zrobione zostało chyba wszystko żeby sieć działała jak najlepiej i mimo największych obaw − bez żadnych zastrzeżeń.