forked from bikol/DPRI_doc_20-21
Merge pull request 'Platformowa gra w Unity: Dodanie dokumentu wymagań projektowych i wizji projektu' (#35) from s434797/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#35
This commit is contained in:
commit
7732d7229c
203
Przybylski/unity/dokument-wymagan-proj.md
Normal file
203
Przybylski/unity/dokument-wymagan-proj.md
Normal file
@ -0,0 +1,203 @@
|
|||||||
|
# **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
|
||||||
110
Przybylski/unity/wizja-proj.md
Normal file
110
Przybylski/unity/wizja-proj.md
Normal file
@ -0,0 +1,110 @@
|
|||||||
|
# **Dokument wizji projektu**
|
||||||
|
|
||||||
|
**Nazwa projektu: Platformowa gra w Unity**
|
||||||
|
|
||||||
|
**Autorzy: Kamil Tyrek, Mateusz Hypś, Jakub Kozubal**
|
||||||
|
|
||||||
|
**Data: 15.11.2020 r.**
|
||||||
|
|
||||||
|
**1. Executive summary (max. 150 słów)**
|
||||||
|
|
||||||
|
Projekt ma na celu stworzenie gry platformowej, której celem będzie zapewnienie graczom rozrywki. Przechodzenie kolejnych etapów gry wymaga zręczności i szybkiego podejmowanie decyzji, dzięki czemu rozgrywka jest ciekawsza i może zaciekawić użytkownika. Grupą docelową jest każda osoba, która chce dobrze spędzić czas. Nie jest wymagana umiejętność czy doświadczenie gracza, gdyż gra wprowadza użytkownika do świata rozgrywki poprzez poziom samouczka. Zyski z gry będą wynikać z korzystania z platformy itch.io, która pozwoli na sprzedaż gry oraz jej aktualizowanie. Portal pozwala na darmowe udostępnienie gry. Ryzykiem jest brak zainteresowania produktem, czego skutkiem będzie brak zysku. Podczas rozgrywki użytkownik będzie walczył z wrogami, wchodził w interakcje z obiektami, rozwiązywał łamigłówki oraz mini-gry.
|
||||||
|
|
||||||
|
**2. Cel i grupa docelowa (min. 150 słów)**
|
||||||
|
|
||||||
|
Celem produktu jest zapewnienie rozrywki dla klienta. Klient, korzystając z naszego produktu, zostanie wprowadzony w świat gry, zostanie mu przedstawiona mechanika gry poprzez samouczek, który będzie przedstawiał kolejne funkcjonalności produktu. Użytkownik w czasie przechodzenia kolejnych etapów będzie musiał wykazywać się zręcznością oraz szybkim podejmowaniem decyzji. W czasie rozgrywki będzie musiał pokonywać między innymi zapadające się pod nim platformy, poruszające się platformy, rozwiązywać łamigłówki, czy też pokonywać mini-gry, których wykonanie nie zawsze będzie obowiązkowe. Wszystkie te aspekty zapewniają, że gra nie polega na prostym przechodzeniu kolejnych etapów i pokonywania wrogów, przez co rozgrywka bardziej wciąga i jest ciekawsza. Grupy docelowe można podzielić na dwie podgrupy: doświadczonych graczy i niedoświadczonych. Pierwsza grupa nie będzie miała problemów z początkową rozgrywką. Nasz produkt, jeśli chodzi o mechanikę, nie wyróżnia się znacznie od innych tego typu gier. Różnice polegają na dodaniu nietypowych elementów, które pojawiają się w czasie przechodzenia etapów, takie jak mini-gry. Drugą grupą są osoby niedoświadczone. Dla takich osób przygotowane jest wprowadzenie – poziom 0. Podczas poziomu dla użytkownika przekazywane są informacje o mechanikach i możliwościach gry. Pozwala to na zaznajomienie się z produktem. Komunikaty są jasne i przedstawione w sposób zrozumiały.
|
||||||
|
|
||||||
|
Chcemy dotrzeć do klientów umieszczając go na platformie itch.io. Jest to platforma z grami typu indie. Umieszczenie tej gry na tej platformie pozwoli na łatwiejszy dostęp do niej oraz możliwość aktualizacji gry przez zespół deweloperski w dowolnym momencie. Ułatwi też kontakt z klientem, który będzie mógł zgłaszać błędy, które wyniknęłyby w trakcie rozgrywki.
|
||||||
|
|
||||||
|
**3. Rynek (min. 3 konkurencyjne produkty)**
|
||||||
|
|
||||||
|
Hollow Knight – Dwuwymiarowa przygodowa gra akcji. Została wyprodukowana przez Team Cherry i wydana w 2017 roku. Gra ta również polega na ratowaniu świata, w tym wypadku przed infekcją bestii. Gra wyróżnia się głównie ręcznie malowanymi sceneriami, które bardzo dobrze trzymają w klimacie. Nasza gra nie posiada wielu ręcznie rysowanych elementów, za to wyróżnia się elementami logicznymi, na które napotyka się użytkownik w trakcie przechodzenia gry.
|
||||||
|
|
||||||
|
Super Meat Boy – Dwuwymiarowa gra zręcznościowa wydana w 2011 roku przez Team Meat. Gra opiera się głównie na elementach zręcznościowych i szybkiej rozgrywce gdyż każdy poziom ma określony czas w którym należy go przejść. Nasza gra wyróżnia się fabułą, która w Super Meat Boy jest dużo bardziej uboga. Super Meat Boy poza elementami zręcznościowymi i mapami tematycznymi do danego etapu gry nie ma za dużo elementów pobocznych w rozgrywce.
|
||||||
|
|
||||||
|
Ori and the blind forest – Dwuwymiarowa gra przygodowa wydana przez studio Microsoft Games. Gra wyróżnia się bardzo starannie ręcznie rysowanymi elementami, fabułą jak i bardzo rozbudowaną rozgrywką. W grze występują również elementy logiczne, dużo pobocznych zadań i zdobywanie nowych umiejętności.
|
||||||
|
|
||||||
|
**4. Opis produktu (min. 3 moduły/epiki)**
|
||||||
|
|
||||||
|
- Moduł głównego menu:
|
||||||
|
- Rozpoczęcie nowej gry
|
||||||
|
- Wczytanie gry z ostatniego zapisu
|
||||||
|
- Dostosowanie:
|
||||||
|
- rozdzielczości
|
||||||
|
- poziomu jasności gry
|
||||||
|
- głośności muzyki i efektów
|
||||||
|
- Włączenie opcji synchronizacji pionowej
|
||||||
|
- Przełączanie między trybem pełnego ekranu z okienkowym
|
||||||
|
- Możliwość zmiany domyślnie przypisanych klawiszy sterownia
|
||||||
|
- Wyjście z gry do pulpitu
|
||||||
|
- Animowane tło
|
||||||
|
- Obszar: Konfiguracja ustawień, Przetwarzanie danych,
|
||||||
|
- Rodzaj: Użytkownicy
|
||||||
|
- Moduł mini-gier:
|
||||||
|
- Obszar: puzzle, rury, otwieranie skarbu
|
||||||
|
- Wyjście z mini-gry
|
||||||
|
- Możliwość restartu puzzli
|
||||||
|
- Rodzaj: Użytkownicy
|
||||||
|
- Moduł poziomów:
|
||||||
|
- Obszar: poziom samouczkowy, poziom 1, poziom do wyborów poziomów:
|
||||||
|
- Możliwość przejścia do następnego poziomu
|
||||||
|
- Odpalenie łamigłówek z interakcją kamery
|
||||||
|
- Walka z wrogami
|
||||||
|
- Rodzaj: Użytkownicy
|
||||||
|
|
||||||
|
**5. Zakres i ograniczenia**
|
||||||
|
|
||||||
|
- **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
|
||||||
|
- Zespół:
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
**Harmonogram na semestr II:**
|
||||||
|
|
||||||
|
- **Listopad**
|
||||||
|
- Poziom do wyboru poziomów
|
||||||
|
- Ekwipunek postaci
|
||||||
|
- Otwieranie skrzyń – mini-gra
|
||||||
|
- Rozwój poziomu 1 o nowe funkcjonalności, rozszerzenie mapy
|
||||||
|
- Stworzenie przeciwnika o rozwiniętych mechanikach, typu boss
|
||||||
|
- **Grudzień**
|
||||||
|
- Stworzenie drzewka umiejętności opartego o trzy gałęzie
|
||||||
|
- **Styczeń**
|
||||||
|
- Stworzenie poziomu do walki z wrogami – fale wrogów, z biegiem czasu przychodzi więcej przeciwników
|
||||||
Loading…
Reference in New Issue
Block a user