Plan - soltys/hopnet GitHub Wiki

1) Wygląd:

1.1)

Wymagania: obiekty z 3DsMax (platforma bez gracza, platforma z graczem, ściany).

A) Widok: Scena 3D, kamera zza pleców gracza. W polu działania gracza znajduje się 5 położonych poziomo obok siebie platform. Platforma na której stoi gracz jest: albo wyróżniona (inny kolor, jakieś graficzne bajerki) ALBO pojawia się na niej jakaś prosta postać (sylwetka człowieka jest za trudna, ale może jakiegoś stworka nasi dzielni graficy stworzą. Póki co lepiej wszystko robić na prymitywach). Po bokach obszaru gry znajdują się ‘ścianki’ ograniczające.

B) Gameplay: gracz za pomocą strzałek na klawiaturze może poruszać się w lewo i prawo po platformach. Platforma, na której gracz się aktualnie znajduje, jest zaznaczona w inny sposób, LUB stoi na niej jakiś stworek. Nie można wyjść ‘za ścianę’.

1.2)

Wymagania: ukończono 1.1.

Widok: Wszystkie platformy lecą w kierunku gracza. Łącznie na ekranie znajduje się 5 rzędów platform: 1 w polu działania i 4 zmierzające w kierunku gracza. Rząd platform który będzie już za graczem w następnej turze znika a zamiast tego pojawia się nowy rząd, na samym początku.

Gameplay: Sytuacja wygląda podobnie jak w 1.1, z tą różnicą, że przejście na inną platformę musi być zsynchronizowane z przesuwaniem się rzędów platform w kierunku gracza. Przejść na następną platformę można dopiero wtedy, kiedy jej rząd wejdzie w pole działania gracza. Można ‘wejść’ na platformę której nie ma, wówczas gra powinna to wychwycić (w końcowym zamyśle w tym momencie będzie game over, na tym etapie nie jest to potrzebne). Podobna rzecz zachodzi wtedy, kiedy gracz ‘nie zdąży’ przeskoczyć na żadną platformę i ‘spadnie’.

Implementacja: Klasa Platforms, zawierająca zagnieżdżoną klasę PlatformRow reprezentującą pojedynczy rząd. PlatformRow zawiera tablicę 5-cio elementową typu bool, gdzie 1 oznacza, że na danej pozycji jest platforma, a 0 – że nie ma. Sama klasa Platforms składa się z kolekcji generycznej zawierającej obiekty PlatformRow oraz metody GenerateNextRow(). Póki co metoda ta będzie generowała ‘pełne’ rzędy platform (11111), w 2.1 dodana zostanie obsługa dynamicznego generowania losowej planszy.

1.3)

Wymagania: Ukończono 1.2, ukończono 2.1.

Widok: rzędy zawierają tylko pojedyncze platformy (lub rzędy puste, wymagające przeskoczenia przez nie). Rzędy są generowane dynamicznie przez generator z 2.1.

Gameplay: dalej sterujemy strzałkami. Skok przez pusty rząd można podpiąć pod strzałkę w górę. Gra powinna wychwytywać, że gracz ‘spadł’ z platformy (na razie bez żadnego game over).

1.4)

Wymagania: Ukończono 1.3, ukończono 3.2

Widok: Taki jak w 1.3.

Gameplay: Podpinamy sterowanie pod kinecta, zamiast pod klawiaturę. Tworzymy instancję klasy KinectPlayer i w Update używamy metody UpdatePlayerState () za każdym razem, kiedy nowy obiekt wejdzie w obszar działania gracza.

1.5) Zakończenie

Wymagania: Ukończono 1.4, 2.2, 2.4, 2.5. Ukończono lub niemal ukończono 2.3.

Cel: Zamknięcie wersji alfa gry jako jedna, integralna całość. Wprowadzenie game over, zapisywania i odczytywania wyników oraz powrotu do menu.

2) Mechanika gry

2.1) Dynamiczny generator plansz.

Wymagania: brak

Cel: Rozszerzenie metody GenerateNextRow() klasy Platforms o tworzenie losowych plansz. Generator musi pilnować, żeby nie doszło do tworzenia planszy niemożliwych do przejścia, czyli np. 01000, a od razu potem 00001. Jeżeli następuje rząd pusty, wówczas zarówno platforma z graczem, jak i platforma za pustym rzędem muszą znajdować się w tej samej pozycji w pionie, np. 00100, 00000, 00100. Dobrze by było, gdyby generator mógł mieć różne poziomy trudności, tj. od poziomu łatwego (częściej byłyby generowane rzędy bez konieczności skakania na boki), przez średni, aż po trudny (same skakania na boki i częste przeskakiwania przez puste rzędy).

2.2) Menu

Wymagania: brak.

Cel: Zrobienie ładnego menu. Do wyboru: Start, zmień poziom trudności, najlepsze wyniki.

2.3) Bajery graficzne

Wymagania: skończone 1.3

Cel: dodawanie efektów graficznych, shaderów, świateł, animacje postaci. Ten punkt można robić niezależnie od innych.

2.4) Muzyka

Wymagania: brak

Cel: Skomponowanie szybkiej, skocznej i wpadającej w ucho melodyjki. Potrzebne będą 3 melodie – w trakcie gry, w menu głównym, po game over. Najważniejsza jest melodia w trakcie gry.

2.5) Lista wyników

Wymagania: brak

Cel: wprowadzenie zapisywania i odczytywania najlepszych wyników w pliku.

2.6) Wizualizacja listy wyników

Wymagania: ukończone 2.5

Cel: Graficzne przedstawienie najlepszych wyników.

3) Kinect

3.1) Klasa KinectPlayer

Cel: Klasa zawiera położenie poszczególnych kończyn (jako referencję do obiektu Skeleton generowanego przez Kinecta).

3.2) Wykrywanie statusu gracza

Wymagania: Ukończono 3.1

Cel: Klasa powinna być rozszerzona o property mówiące o stanie, w jakim gracz się znajduje. Stan powinien być aktualizowany publiczna metodą Update().

3.3) Sterowanie kursorem w menu za pomocą Kinecta

Wymagania: ukończone 3.2

Cel: Rozszerzenie klasy KinectPlayer o stany gracza mówiące, czy gra, czy jest w menu. Dodanie sterowania kursorem, jeżeli jest w menu. Dodanie obsługi ‘kliknięcia’.

3.4) Cykanie śmiesznych fotek.

Wymagania: ukończone 1.5.

Cel: Napisanie klasy pamiętającej kilka zdjęć wykonanych przez kamerkę Kinecta w trudnych momentach gry (skok przez pustą platformę, skoki na bok). Po zakończeniu gry należy wyświetlić te obrazki.