TheReader
Období: Týden 12/2026 (od 22.03.) Skupina: tria URL: https://github.com/thereadero/TheReader.git
1. Splnění základních podmínek
| Podmínka | Status |
|---|---|
| Alespoň 3 commity v daném týdnu | ✅ SPLNĚNO |
| Rozestup alespoň 12h mezi 3 commity | ✅ SPLNĚNO |
| Projektová dokumentace (README, projekt.md) | ✅ SPLNĚNO |
2. Přehled commitů
- 2026-03-23 20:49: added a semi functional build menu to gd.py and added the function to jump, eliminated the duplicate in ffmpeg_conv.py
- 2026-03-24 18:38: added a grid to gd.py also added the option to name the maps and save them, and other things
- 2026-03-24 18:50: fixed the opening save and creating save crash, made the jump more bigger
- 2026-03-24 19:15: added spawn and fixed other issues in GD.py
- 2026-03-26 18:24: added customizeable character, block menu, integrated better building capability
- 2026-03-26 18:48: fixed some errors
- 2026-03-28 16:37: added double and triple spikes
3. Výsledky AI analýzy kódu
| Metrika | Hodnota |
|---|---|
| Celkové body (AI) | 18 / 20 b. (90%) |
| Náročnost projektu (Index) | 3 |
| Počet commitů | 7 |
| Změněné soubory | 4 |
| Počet přid./odeb. řádků kódu | 1422 |
Komentář a zpětná vazba od AI
Jako tvůj pedagogický asistent jsem prošel tvůj repozitář a pokroky v projektu Geometry Dash (GD.py) a dalších částech. Zde je tvé hodnocení za uplynulý týden:
1. Smysluplnost popisů u commitů [3 body]:
Tvé commity jsou příkladné. Jsou psány v angličtině, jsou konkrétní a věcně popisují, co se v daném kroku změnilo (např. „added a grid to gd.py“, „fixed the opening save and creating save crash“). To velmi usnadňuje orientaci v historii projektu.
2. Smysluplnost komentářů v kódu [5 bodů]:
V kódu se orientuješ pomocí komentářů, které oddělují logické bloky (kolize, vykreslování, UI). Oceňuji poznámku # menu_data moved up, která vysvětluje změnu v organizaci kódu. Body strhávám za to, že u komplexnější matematiky (výpočet bodů polygonu pro více hrotů v cyklu for i in range(n)) by se hodilo krátké vysvětlení, jak funguje offsetování (px).
3. Kvalita a srozumitelnost dokumentace a struktura repozitáře [2 body]:
Struktura je v naprostém pořádku – každý projekt má svou složku a v rootu je pouze přehledné README. Dokumentace k jednotlivým projektům jsou detailní a obsahují i návody na instalaci a ovládání.
* Pozor: V dokumentaci GD_projekt.md uvádíš u ovládání: T: Select Triangle. Nicméně v kódu GD.py na řádku 652 (v bloku check_col) obsluhuješ klávesu K_t nastavením selected_type = 'spawn'. To je v rozporu s dokumentací i s logikou "Triangle".
4. Logika řešení a přemýšlení studenta v Pythonu [8 bodů]:
Tento týden jsi udělal obrovský kus práce na editoru úrovní.
* Kladně hodnotím: Implementaci systému pro vícečetné hroty (spike_2, spike_3) pomocí jednoho typu objektu a dynamického výpočtu šířky a vykreslování. Refaktorizace menu do datové struktury menu_data je také velmi elegantní řešení, které snižuje duplicitu kódu.
* Výtky k logice:
1. Architektura: Podle diffu se zdá, že jsi obsluhu kláves a logiku výběru objektů pro stavění vložil do funkce def check_col(test_x, test_y):. Tato funkce by se měla starat výhradně o kolize, nikoliv o UI a vstupy. Tímto se kód stává nepřehledným (tzv. "spaghetti code").
2. Výkon: V části detekce kolizí hrotů vytváříš v každém průchodu cyklem nový pygame.Surface a novou masku: spike_mask = pygame.mask.from_surface(spike_surf). Při větším množství hrotů na obrazovce to drasticky sníží FPS. Masky bys měl mít předgenerované.
Celkem získáno bodů: [18 / 90%] ze 20 možných
STUPNICE NÁROČNOSTI (Index 1-5): DIFFICULTY_INDEX: [3]
Kontrolní otázka k obhajobě
V části pro vykreslování menu používáš pro šířku hrotu vzorec
sw = 30 / (1 + (n - 1) * 0.5)– mohl bys mi vysvětlit logiku tohoto výpočtu a proč jsi tam jednoduše nepoužil stejné fixní hodnoty jako při vykreslování hrotů přímo v herní ploše?