Skip to content

1hubert/scoundrel

Repository files navigation

Scoundrel

wymagania odnośnie implementacji

W projekcie oceniane będą następujące elementy:

  • użycie GitHuba - szczegółowe informacje w sekcji poniżej (niezbędne, by otrzymać ocenę pozytywną >= 50%)
  • podział na pliki cpp i h (niezbędny, by otrzymać ocenę pozytywną >= 50%))
  • zastosowanie dziedziczenia (niezbędne, by otrzymać ocenę pozytywną >= 50%))
  • zastosowanie polimorfizmu (niezbędne, by otrzymać ocenę pozytywną >= 50%)
  • przechowywanie wszystkich obiektów gry w jednym kontenerze (niezbędne, by otrzymać >= 70%)
  • komentarze (niezbędne, by otrzymać >= 80%)
  • zastosowanie animacji
  • wykorzystanie wskaźników
  • podział klasy na pola public/protected/private
  • wykorzystanie prędkości liniowej w pikselach/sekundę i rotacji w stopniach/sekundę do modelowania ruchu obiektów
  • wykorzystanie unique_ptr/shared_ptr i dynamic casting
  • zapis i wczytanie stanu gry
  • zapis i odczyt tablicy wyników
  • wprowadzenie losowości do działania programu (np. przeciwnicy pojawiający się w losowych miejscach)
  • parametryzacja gry (np. zmiana ilości pojawiających się przeciwników jedną zmienną)
  • spełnienie założeń z konceptu (mnoży uzyskaną liczbę punktów razy % spełnionych założeń)
  • skala skomplikowania (mnoży maksymalną możliwą do uzyskania liczbę punktów, jest ustalana przy złożeniu konceptu)
  • punkty dodatkowe za kreatywne rozwiązania programistyczne

wymagania odnośnie GitHub'a

  • Cały kod/media powinny się znajdować na repozytorium na githubie, nie na eKursach. Będę go uruchamiać tylko na podstawie tego repozytorium. Jeśli nie będzie działać na SFML 2.x (2.5.x) na Qt, projekt NIE BĘDZIE ZALICZONY. Znaczy to, że np jak najbardziej możecie pracować na np Visual Studio, ale kod powinien być sprawdzony na QT+SFML.
  • Do repozytorium dodajecie: pliki źródłowe (cpp, h), pliki z mediami (obrazy/tekstury/audio/video), pliki potrzebne do zbudowania projektu na Qt (CMakeLists.txt, pro), pliki informacyjne z opisem (txt, pdf, md, itd), pliki specjalne github, i nic więcej. Pliki potrzebne do zbudowania projektu są obowiązkowe, bez nich projekt NIE BĘDZIE ZALICZONY.
  • Do repozytorium NIE dodajecie: plików powstałych w wyniku kompilacji (exe, dll, a, so, obj, itd), plików z zewnętrznych bibliotek w postaci binarnej (np. SFML). Przypadki dodania w ten sposób np całej biblioteki będą skutkowały obniżeniem oceny nawet o 20%.
  • Dopuszczalne jest dodanie plików źródłowych/mediów innych bibliotek (3rd party), ale trzeba zapewnić możliwość ich automatycznego zbudowania i zlinkowania z głównym programem.
  • Każdy dodany fragment kodu/mediów 3rd party powinien być opisany, razem z miejscem pochodzenia. Należy to zrobić bezpośrednio w kodzie źródłowym z komentarzem 3rd party: <source>, gdzie jest miejscem skąd został pobrany.
  • Milestone'y: Repozytorium powinno zawierać minimalnie 5 commitów (2 osoby w grupie), które będziemy traktować jako mileston'y. Każdy milestone powinny się kompilować i powinien być otagowany z odpowiednim opisem. Finalny milestone jest waszą ostateczną wersją projektu. Proszę go odpowiednio oznaczyć. Nie ma górnego ograniczenia jeśli chodzi o liczbę commitów i milestonów, który z commitów potraktujecie jako milestone, jak również nie każdy commit musi się kompilować (milestone musi).
  • Milestone'y - punkty: Milestone'ny powinny być równomiernie rozłożone (w sensie czasu pracy) i powinny odzwierciedlać realną pracę nad projektem. Za każdy milestone-commit mniej od wymaganego obniżam ocenę o 10%. Nie będę akceptować commitów skumulowanych jeden obok drugiego, np na końcu albo na początku projektu.
  • Gałęzie/branch. Nie wprowadzam ograniczeń jeśli chodzi o prace na innych gałęziach niż "main". Natomiast powyższe milestony powinny znaleźć się na gałęzi "main", także w trakcie pracy jest wymagane by wszystkie gałęzie połączyć na "main".

lista funkcjonalności

  1. Inicjalizacja gry [Mieszko Ratowski, Hubert Rozmarynowski]
    • Spytanie użytkownika o poziom trudności
    • Stworzenie talii kart i ustawienie początkowego zdrowia
    • Stworzenie talii kart i ustawienie początkowego zdrowia stosownie do poziomu trudności
    • Przetasowanie stworzonej talii kart
  2. Zarządzanie kartami [Mieszko Ratowski, Hubert Rozmarynowski]
    • Odkrywanie 4 kart na pokój
    • Przenoszenie kart między stosami (loch, pokój, odrzucone)
    • Obsługa końca talii
  3. System walki, zarządzanie bronią [Hubert Rozmarynowski]
    • Obliczanie obrażeń przy walce gołymi rękoma
    • Obliczanie obrażeń przy walce bronią
    • Śledzenie aktualnie założonej broni i jej stanu zużycia
    • Zakładanie i zdejmowanie bronii
  4. Zarządzanie zdrowiem [Hubert Rozmarynowski]
    • Odejmowanie obrażeń od zdrowia gracza
    • Dodawanie zdrowia z mikstur (bez przekraczania MAX HP)
    • ograniczenie możliwości użycia mikstur do jednej na turę
    • Sprawdzanie warunków końca gry
  5. Interfejs użytkownika [Mieszko Ratowski]
    • Wyświetlanie aktualnego stanu gry
    • Obsługa kliknięć na karty
    • Ekran końcowy z wynikem gry
    • Grafiki i animacje
  6. System omijania pokoi [Mieszko Ratowski]
    • Śledzenie czy gracz może ominąć pokój
    • Przenoszenie ominiętych kart na spód talii
  7. System punktacji [Mieszko Ratowski]
    • Obliczanie wyniku przy wygranej (pozostałe zdrowie)
    • Obliczanie wyniku przy przegranej (pozostałe zdrowie odjąć suma zdrowia pozostałych potworów)

About

A simple roguelike card game implemented in C++ /w SFML

Resources

Stars

Watchers

Forks

Contributors