Semestrální práce

• Herní engine
• Simulace
• Arimaa

Je možné pracovat samostatně nebo ve dvojicích. Semestrální práce v tomto případě bude rozsáhlejší, například se vyžaduje implementace síťové verze hry nebo distribuovaná simulace. Členové týmu nemusí být ze stejného cvičení.

Práce je vyvíjena za pomoci verzovacího systému GIT na http://gitlab.fel.cvut.cz v předem připravených projektech pojmenovaných podle schématu https://gitlab.fel.cvut.cz/B232_B0B36PJV/id_studenta. Dokumentace se píše na stránce Wiki projektu.

Odevzdání semestrálních prací probíhá ve třech “Checkpointech”, a to vždy v GitLab projektu založeném ve skupině https://gitlab.fel.cvut.cz/B232_B0B36PJV (ne jinde!) - tedy např. https://gitlab.fel.cvut.cz/B232_B0B36PJV/novakjan:

• CP1 - Vize projektu (do 3. týdne - 10. 03., 23:59)
  • na Wiki GitLab projektu nebo dle instrukcí cvičícícho do BRUTE dokument, max. ~2x A4, popisující semestrální práci
  • zvolené téma, očekávané funkce a vize celého projektu
  • z dokumentu by mělo být možné si představit, jak práce bude vypadat
• CP2 - Objektový návrh (do 8. týdne - 12. 04., 23:59)
  • na Wiki projektu rozpracovaná dokumentace z pohledu uživatele (např. manuál)
  • na Wiki projektu přidaná dokumentace z pohledu programátora (popisy tříd, stavů aplikace, použité technologie, knihovny, apod.); případné dělba práce
  • v repozitáři projektu zdrojové soubory - kostry hlavních tříd a rozhraní, tak aby byla patrná navržená architektura
• CP3 - Finální prezentace (do 14. týdne - 24. 05., 23:59)
  • prezentace celé práce a architektury aplikace cvičícímu
  • dokončena dokumentace z pohledu uživatele

• Dokumentace je umístěna na Wiki stránkách Vašeho projektu v GitLab ČVUT (například: https://gitlab.fel.cvut.cz/seredlad/java-examples/-/wikis/home a je snadno dostupná ze stránky projektu: https://gitlab.fel.cvut.cz/seredlad/java-examples)
• V dokumentaci je popsáno kompletní fungování aplikace z hlediska uživatele. Popis může být formou uživatelského manuálu, nebo jako návrh projektu k realizaci pro potenciálního investora. Musí být dostatečně konkrétní, tedy například nikoliv „hráč bude hledat určité předměty“ ale „hráč bude hledat krystal, lektvar a meč…“ a ne „uživatel ovládá raketu“ ale „uživatel pomocí kláves WASD ovládá raketu“, a zahrnout všechny podstatné aspekty aplikace, jako:
  • cíl hry
  • popis všech prvků hry
  • ovládání
  • ukládání a načtení hry
  • způsob vytváření nových levelů případně popis editoru úrovní
  • pro lepší pochopení lze přidat obrázky jako drátěné modely (wireframes) obrazovek, náčrty herního pole nebo herních map, vizuální návrhy prvků aplikace, atd.
• Objektový návrh předpokládaných tříd ve formě diagramu UML:
  • vygenerované z už napsaných zdrojových kódů v Java. Ideálně se jedná o kostru programu (balíčky, soubory .java). Kód a tedy i diagram by měl obsahovat definované třídy včetně vztahu dědičnosti mezi nimi, atributy tříd, hlavní metody všech tříd (bez privátních a jiných pomocných metod) pomocí kterých mezi sebou budou objekty komunikovat a také metody, které budou sloužit k interakcí s objekty GUI. Metody nemusí obsahovat tělo, ale je doporučeno, aby byl už připraven stručný Javadoc, který obsahuje textovou informaci, k čemu daná metoda nebo objekt slouží
  • nebo náčrtu (ve vhodném nástroji, např. draw.io nebo fotografii ručně nakresleného grafu) s popisem, vysvětlující účel jednotlivých tříd, jejich vztahy a jejich vzájemnou komunikaci
• Pokud bude použita komunikace po síti, doporučuje se specifikovat komunikační protokol - tedy jaká data a v jakém formátu se budou mezi serverem a klientem posílat. Tento protokol je zásadní a proto by se v průběhu další práce už ideálně neměl měnit.

Po dohodě s cvičícím je možné konzultovat materiál i v jiné formě, ale musí z něj být patrné všechny informace, které jsou uvedeny výše.

Student/ka (případně oba členové týmu) se musí zúčastnit konzultace k odevzdání dokumentace v termínech, které oznámí cvičící (obvykle krátce po termínu odevzdání dokumentace do GitLab - viz. výše).

1. Bude dokladovatelný progres projektu na GitLab. Průběžně (každou hotovou funkcionalitu s popisem) commitují všichni členové týmu. Pozor: neadekvátně málo commitů (velmi orientačně: méně než 10) obvykle vzbudí u cvičících (oprávněné) podezření na plagiát!
2. Projekt bude v Mavenu.
3. Oba účastníci projektu musí podílet na tvorbě GUI. Alespoň jedno netriviální okno bude vytvořeno bez požití Designeru v Netbeans nebo jiném “klikacím” nástroji.
4. V projektu student předvede schopnost správně použít vlákna (za to se nepovažuje použití např. třídy Timer). Například vytvořením hodin reálného času, které interagují s průběhem hry.
5. Několik netriviálních tříd bude pokryto unittesty nebo komplexnějším funkčním testem. Bude použit libovolný testovací framework.
6. Budou použity loggery. Logovací zprávy bude možno zapnout nebo vypnout parametrem při spuštění.
7. Veškeré netriviální public prvky v programu musí mít smysluplný Javadoc. Za triviální se považují například jednoduché gettery a settery bez vedlejších efektů, ty Javadoc nepotřebují.
8. Všechny netriviální části kódu budou vhodně okomentovány.
9. Ve Wiki projektu musí být aktuální a použitelný uživatelský manuál a technická dokumentace programu - jeho vlastností, struktura projektu, použité technologie podle výše popsaných podmínek. Pozor, nejedná se o Javadoc!
10. Všechno kromě dokumentace na GitLabu musí být v angličtině. Anglicky musí být i Javadoc.