niezbednikstudenta_docs/Przybylski/unity/dokument-wymagan-proj.md

Dokument wymagań projektowych

Nazwa projektu: Platformowa gra w Unity

Autorzy: Kamil Tyrek, Mateusz Hypś, Jakub Kozubal

Data: 13.12.2020r.

0. Wersje dokumentu

01.11.2020r. – aktualizacja na rozpoczęcie semestru drugiego w oparciu o nowy wzór

15.11.2020r. – aktualizacja funkcjonalności i kamieni milowych

13.12.2020r - aktualizacja dotycząca platformy, na której umieszczona zostanie gra

1. Elementy składowe projektu (produkty projektu)

Przykładami elementów programistycznych są:

• Gra platformowa 2D stworzona na silniku UNITY

Przykładami elementów nieprogramistycznych są choćby:

• Dokument wizji projektu,
• Prototyp UI głównego menu,
• Value Proposition Canvas,
• Business Model Canvas,
• Raporty z wykonanych testów użyteczności menu głównego
• Repozytorium zawierające kod aplikacji - GitHub
• Tablica projektowa - JIRA

2. Granice projektu

• Produkt dostępny na systemy, ze względu na wymagania Unity 2019.1:

  • Windows 7 SP1+
  • macOS 10.12+
  • Ubuntu 16.04+

• Nie jest dostępna na konsolach oraz urządzeniach mobilnych z powodu braku przewidzianej konfiguracji sterowania innego niż klawiaturą i myszką

• Funkcjonalność sterowania padem nie zostanie wdrożona, ponieważ ze względu na typ gry może on przeszkadzać – przykładem mogą być mini-gry, gdzie konieczne jest odpowiednie wybranie danego obiektu, co w przypadku poruszania padem może być uciążliwe

3. Lista wymagań funkcjonalnych

• Gracz może swobodnie i płynnie poruszać się postacią po świecie gry

• Możliwość wczytania gry

• Możliwość ręcznego ustawienia poziomu głośności gry oraz muzyki

• Możliwość ręcznego ustawienia rozdzielczości, v-sync, fullscreen

• Możliwość ręcznej zmiany ustawień sterowania odpowiadających za konkretne czynności

• Zapisywanie się ustawień graficznych, dźwiękowych i sterowania

• Pula podpowiedzi w trakcie rozgrywki określających sterowanie i/lub zadanie gracza

• Gracz dysponuje ekwipunkiem, który będzie posiadał ograniczoną ilość miejsc. W ekwipunku będą znajdować się miecze, eliksiry dodające punkty życia oraz wytrychy, pozwalające na rozpoczęcie mini-gry z otwieraniem skarbu

• Gracz dysponuje możliwością przeczytania opisu przedmiotu znajdującego się w ekwipunku

• Gracz może w dowolnej chwili zatrzymać oraz wznowić grę

• Gracz może przechodzić opcjonalne mini-gry w celu zdobycia doświadczenia – przykładem jest mini-gra przesuwanych puzzli

• Gracz może rozdawać punkty doświadczenia w drzewku umiejętności

• Gracz może cofać rozdane wcześniej punkty doświadczenia określonym wcześniej kosztem

• Gracz może wybrać styl rozgrywki poprzez wybranie konkretnej gałęzi w drzewku umiejętności – podział na umiejętności związane z siłą, poruszaniem się i wytrzymałością

• Gracz może używać nauczonej umiejętności od razu po dodaniu jej w drzewku

• Gracz może likwidować przeciwników zyskując za to punkty doświadczenia

• Możliwość pominięcia przeciwników przeskakując nad nimi

• Gracz musi przejść poziom wprowadzający do gry w celu przejścia dalej

• Przeciwnicy poruszają się po wyznaczonych ścieżkach

• Przeciwnicy poruszają się w kierunku gracza w określonych granicach

• Gracz traci określoną ilość punktów życia po ataku przez przeciwnika

• Gracz po utracie wszystkich punktów życia cofa się na ostatni checkpoint (lub w przypadku całkowitej straty żyć na początek poziomu)

• Istnienie elementów w grze, które zmuszają gracza do szybszego podejmowania decyzji

  • Znikające platformy
  • Ruchome platformy
  • Mini-gra rury

• Gra automatycznie się zapisuje informując o tym gracza

• Gracz jest na bieżąco wprowadzany do fabuły gry

• Gracz do dyspozycji będzie mieć 3 poziomy:

  • Poziom samouczka, którego średni czas przejścia trwa 8 minut
  • Poziom pierwszy, którego średni czas przejścia trwa 18 minut
  • Poziom do wyboru poziomów

4. Lista wymagań niefunkcjonalnych

• Niezawodność, dostępność – System powinien być dostępny w każdy dzień tygodnia, ponadto wszystkie błędy gry na bieżąco naprawiane
• Wydajność - System w miarę możliwości powinien być dostępny dla jak największej liczby urządzeń ze względu na wymagania sprzętowe
• Użyteczność - System ma spełniać co najmniej 90% wymagań funkcjonalnych
• Ergonomia - Używanie systemu powinno być intuicyjne i przejrzyste dla użytkownika.
• Zrozumiałość - Konstrukcja gry powinna być zrobiona w taki sposób, że użytkownik jest w stanie zrozumieć w jakim elemencie rozgrywki aktualnie się znajduje
• Dostępność - Aplikacja powinna być dostępna w serwisie z grami (np. Steam, itch.io itp.)
• Postępowość - System jest na bieżąco uaktualniany w celu eliminacji błędów oraz rozwijania o nowe funkcjonalności/poziomy.
• Płynność - Gra powinna działać płynnie jeśli jest uruchomiona na urządzeniu zgodnym z wymaganiami sprzętowymi i systemów

5. Mierzalne wskaźniki wdrożeniowe

• Gra zostanie opublikowana na platformie itch.io pod koniec grudnia

• Produkt będzie regularnie testowany (raz na dwa tygodnie) pod kątem poprawnego działania funkcjonalności przez grono osób wybrane przez zespół deweloperski. Zespół deweloperski będzie również testował produkt co przyrost, czyli co tydzień.

• Na koniec grudnia system zostanie dostarczony do klienta w wersji testowej alpha (rozumianej zgodnie z metodyką Agile). Pod koniec stycznia klient otrzyma system w wersji testowej beta.

6 . Kryteria akceptacji projektu dla I semestru prac

• Kryteria wymagane:
  • Do funkcjonalności wymaganych należało:
    • Stworzenie modeli poziomu pierwszego oraz samouczka
    • Funkcjonalne menu wraz z muzyką
    • Dodanie jednej łamigłówki na jednym z wcześniej wymienionych poziomów
    • Model bohatera wraz z animacjami oraz możliwością poruszania się
    • Bierni wrogowie rozłożeni na poziomie samouczkowym
• Kryteria oczekiwane:
  • Do funkcjonalności oczekiwanych należało:
    • Dodanie kolejnej łamigłówki
    • Rozwój przeciwników o możliwości walki z graczem
    • Zwiększenie rozmiaru poziomu samouczka
    • Możliwość rozwiązywania mini-gier (rury i puzzle)
    • Stworzenie urozmaiceń na poziomie samouczka w postaci ruchomych platform czy interakcji z obiektami środowiska
• Kryteria planowane:
  • Do funkcjonalności planowanych należało:
    • System zapisywania i wczytywania gry
    • System zbierania doświadczenia i wbijania poziomów
    • Możliwość poruszania się po mapie za pomocą skakania po linach

7. Kryteria akceptacji projektu dla II semestru prac

• Kryteria wymagane:
  • Do funkcjonalności wymaganych należą:
    • Skonfigurowanie globalnego zapisu stanu gry oraz możliwości wczytania go z dowolnej instancji gry, a także dodanie systemu autozapisu
    • Rozwinięty system zbierania doświadczenia wraz z drzewkiem umiejętności
    • Dodanie ekwipunku dla bohatera
• Kryteria oczekiwane
  • Wersja beta gry dodana na platformę itch.io
  • Przeprowadzone testy na wersji alfa gry
  • Do funkcjonalności oczekiwanych należą:
    • Dodanie kolejnych mini-gier i łamigłówek również na poziomie 1
    • Rozwinięta fabuła
• Kryteria planowane
  • Stworzenie planów marketingowych
  • Do funkcjonalności planowanych należą:
    • system wyboru poziomów trudności
    • stworzenie zaawansowanej, wieloczęściowej walki z końcowym przeciwnikiem

8. Organizacja pracy zespołu

• Strona klienta:

a) Jakub Kozubal:

§ Product Owner – odpowiedzialność za dostarczenie produktu na platformę itch.io

• Strona zespołu projektowego:

a) Mateusz Hypś

§ Projektowanie architektury gry

§ Tworzenie dokumentacji

§ Implementacja produktu końcowego

b) Jakub Kozubal

§ Projektowanie architektury gry

§ Tworzenie dokumentacji

§ Implementacja produktu końcowego

§ Nadzorowanie testów

c) Kamil Tyrek

§ Projektowanie architektury gry

§ Tworzenie dokumentacji

§ Tworzenie prototypu opcji

§ Nadzorowanie testów

§ Nadzorowanie przebiegiem sprintów – zakładanie zadań, zarządzanie spotkań cotygodniowych

Jako metodykę pracy przyjęto Scrum. Głównymi powodami tej decyzji jest doświadczenie części zespołu w tej metodyce oraz przejrzystość i rozsądne zarządzanie pracą. Nie rozważano innych metodyk pracy. Przy zarządzaniu pracą wspomaga nas serwis JIRA, który pozwala zarządzać regularne sprinty – w pierwszym semestrze dwutygodniowe, w drugim semestrze tygodniowe. Kod źródłowy zarządzany jest poprzez GitHub. Dla przejrzystości pracy, każdy commit na GitHub oznaczany jest id zadania na Jirze, dzięki czemu wchodząc w zadanie widzimy commit powiązany z jego rozwiązaniem. W momencie rozpoczęcia zadania deweloper, jeśli następuje potrzeba, tworzy podzadania do zadań na Jirze. Dotyczy to większych zadań, których wykonanie polega na tworzeniu większej ilości funkcjonalności. Dzięki temu realizując nowe zadania, o podobnej budowie, można sugerować się podobnym sposobem działania zadania. Po każdym commicie programista wyznacza ile czasu poświęcił na zadanie, poprzez wbudowaną w Jirze funkcjonalność "Log Work". Gdy zadanie zostanie zakończone, programista oznacza je statusem "DONE".

9. Ryzyka projektowe

• Ryzyko ze względu na zasoby
  • Określone ramy czasowe projektu
  • Brak doświadczenia z publikacją gry w serwisie itch.io - trudności w dodaniu gry na serwis. Pierwotnie miała być to platforma Steam, jednak ze względu na koszty wymagane przez tę platformę (100$) oraz ryzyko niedotrzymania zakładanych terminów, zrezygnowano ze Steam.
  • Odejście członka zespołu zajmującego się grafiką - trudności w dokończeniu oprawy wizualnej gry
  • Odejście jednego z członków zajmującego się programowaniem - trudności w implementacji kolejnych funkcjonalności, wynikające z większego nakładu pracy na osobę
• Inne
  • Brak wystarczającego zaangażowania członków zespołu
  • Nieporozumienia w zakresie implementacji skryptów - ryzyko złego użycia kodu przez osobę, która go nie tworzyła, co może prowadzić do błędów aplikacji

10. Kamienie milowe

• Semestr 1
  • Przygotowanie prototypu interfejsu
  • Przygotowanie backlogu dla projektu projektu w systemie JIRA, opracowanie funkcjonalności, user stories
  • Testy użyteczności interfejsu
  • Przygotowanie wersji demonstracyjnej gry z dwoma poziomami
• Semestr 2
  • Rozwinięcie poziomu pierwszego, którego średni czas przejścia będzie trwał 18 minut, licząc walki z ostatecznym przeciwnikiem – koniec listopada
  • Utworzenie systemu rozwoju umiejętności (drzewko umiejętności) – koniec grudnia
  • Wdrożenie aplikacji do platformy z grami – koniec grudnia
  • Ukończenie aplikacji wraz z zapowiedzianymi funkcjonalnościami – koniec stycznia