Jeżeli chcemy dodać własną muzykę do gry to musi ona być w formacie wav oraz mieć 16bit/sample. Jeżeli uruchamiamy aplikację z widoku okienkowego, to powinna się ona znaleźć w folderze o nazwie music, który z kolei powinien znajdować się w folderze home użytkownika (~ na linuxie). Natomiast jak uruchamiamy z terminala, to musimy podać mu ścieżkę do ~, albo umieścić własne utwory w folderze music równoległym do pliku .jar.
Dystrybucja pracy była równomierna. Każdy z nas wykonał 1/3 projektu. Dodatkowo podzieliliśmy się zadaniami w następujący sposób:
- Jędrzej Kula
- Kwestie techniczne związane z przetwarzaniem muzyki (np. klasa BMPcalc)
- Kwestie techniczne związane z mechaniką 'dozwolony ruch' (np. klasa BPMhud)
- Pomysłodawca aplikacji i logiki stojącej za problemem zależności 'ruch-muzyka' w grze
- Artur Zubilewicz
- Kwestie związane z GUI (np. ustawienia, przyciski, itp.)
- Maszyna stanów (klasy w folderach State i ApplicationStates, wykorzystane do implementacji różnych etapów pętli gry oraz pozwalająca na implementację transparentnych stanów gry gracza). Pozwala na łatwe dodawanie nowych stanów dzięki poliformicznej hierarchi klas stanów)
- Dbanie nad całokształtem struktury kodu (odpowiednie klasy w odpowiednich miejscach i relacji między sobą)
- Przygotowanie linków do dokumentacji i wybór relewantnych stron na Wiki projektu
- Patryk Chełmecki
- Implementacja pętli gry oraz struktury kodu gracza i mapy (np. klasy Player i Map, umożliwiające łatwe dodawanie mapy za pomocą plików .json)
- Kwestie związane z renderowaniem aktorów na scenie (gracz, mapa, cele gry, itp.)
- Wiązanie klas pojawiających się w PlayingState (logika gry 'real-time')
Naszym pierwszym frameworkiem było JavaFX, które po pewnym czasie okazało się nieodpowiednim dla naszej aplikacji, ponieważ mocno ograniczało dostępne rozszerzenia dla plików muzycznych, graficznych i video.
Następnie wybraliśmy nasz docelowy framework jako libGDX. Framework ten jest dedykowany do pisania gier w Javie, lecz niestety jego dokumentacja jest bardzo okrojona i często funkcje są opisane zaledwie kilkoma niewiele tłumaczącymi słowami. Z tego powodu wielokrotnie musieliśmy szukać gotowych aplikacji w tym frameworku i na nich się wzorować oraz dedukować działanie konkretnych funkcji.
Nasza gra jest grą w czasie rzeczywistym, dlatego wymaga innego podejścia do samej implementacji aplikacji. W kodzie powinna się znaleźć pętla gry, a już sam wybór odpowiedniej pętli gry pod konkretną aplikację wymaga nabycia wcześniejszego doświadczenia. Poświęciliśmy dużo czasu na czytanie książek i artykułów o pętli gry i specyfikacji event-driven architecture, wykorzystywanej przez framework libGDX.
Nauczyliśmy się w ten sposób, że dobrze przygotowana gra (a dokładniej jej silnik) korzysta z finite state machine albo pushdown automata do realizacji stanów aplikacji i aktorów w grze. Finite state machine jest przydatne jedynie wtedy, gdy dany aktor (lub np. aplikacja) może w danym momencie być tylko w jednym stanie. Oznacza to, że nadaje się ona do użycia w przypadku aktorów o prostym zachowaniu. Ponadto nie udostępnia ona 'pamiętania' więcej niż jednego poprzedniego stanu, więc nie przydaje się do implementacji wielopoziomowego menu, albo postaci, która mogła wcześniej np. 'trzymać przedmiot', potem 'podskoczyć' i w czasie skoku wykonać jeszcze inną operację. Do tego właśnie celu jest pushdown automata czyli inaczej mówiąc stos stanów.
Kolejnym problemem było ustalenie kiedy gracz może wykonać ruch. Po przeszukaniu materiałów na temat innych gier o podobnej specyfikacji zdecydowaliśmy się na wykorzystanie wartości BPM (bits per minute), co dodatkowo niosło za sobą dwa kolejne problemy: jak dostarczyć BPM do aplikacji oraz jak podzielić czas na interwały odpowiednio stwierdzające czy ruch jest dozwolony czy nie.
Pierwszy z nich rozwiązaliśmy przez hardkodowanie części utworów oraz implementacja algorytmu liczącego BPM w oparciu o znalezione w internecie materiały.
Drugi natomiast rozwiązaliśmy poprzez utworzenie osobnego wątku zmieniającego informację o dostępności ruchu co ustalony fragment czasu. Powodowało to problem związany z równoległą synchronizacją wątków utworzonych przez nas i wątków kontrolowanych przez framework libGDX. Ograniczenie narzucone na nas przez ten framework oraz implementacja algorytmu wymagają od nas dostarczania utworów o bardzo zawężonej specyfikacji, tj. utwór musi mieć 16 bits per sample, powinien mieć częstotliwość 44100 Hz oraz mieć ścieżkę stereo.
Kwestie techniczne wymagały od nas odpowiedniego przygotowania, które pierwotnie wydawało się o wiele mniejsze niż faktycznie okazało się w trakcie realizacji projektu. Musieliśmy poznać ogromną ilość zagadnień, własnoręcznie dochodzić do tego jak działają niektóre funkcjonalności frameworku libGDX i wielokrotnie rozwiązywać problemy związane z kompatybilnością między wersjami tego frameworka (niektóre funkcje okazywały się być przedawnione lub o zupełnie innej sygnaturze niż sugeruje dokumentacja). Wyjątkowa specyfikacja gry, w której muzyka stanowi nie tylko tło, ale również element rozgrywki okazało się wyjątkowo problematyczne, a samo dojscie do natury problemów wymagało od nas poznania innych tematów, np. przetwarzania plików muzycznych przez Javę, czy samego sposobu ich zapisu.
Dostrzegamy, że postawione przez nas cele nie zostały zrealizowane w stopniu jaki byśmy chcieli. Z perspektywy czasu projekt okazał się być jedynie wierzchołkiem góry lodowej i ogromnej pracy, którą trzeba w niego włożyć aby doprowadzić go do końca. Praca nad tym projektem była bardzo rozwijająca i nauczyła nas tego samodzielnie szukać rozwiązań do wszelakich problemów oraz pozwoliła nam zaznajomić się z realiami realizacji projektów, gdzie często rzeczywistość odbiega od oczekiwań.
Wierzymy, że wyniesiona wiedza pozwoli nam lepiej radzić sobie w przyszłej pracy zespołowej nad większymi projektami.
Team Cheap-Cleaning-And-Cleaning