VL/Übung: Entferne den Dungeon aus den Vorlesungen und Übungsblättern #1046
Description
Der Dungeon bzw. der DevDungeon sollte eigentlich das Narrativ für diese Veranstaltung bilden. Es stellt sich leider immer stärker heraus, dass dies nicht wirklich realistisch ist:
- Abhängigkeit zu libGDX und Hardware/Betriebssystem: Im Prinzip sollte alles über Gradle aufgelöst werden - aber in der Praxis hakelt es immer wieder, vor allem unter Windows. Da es bei den Übungen um eine Prüfungsleistung geht, muss nur ein Student mit Problemen kommen und das Ding hat sich erledigt. Dazu kommt, dass ich keinen Support für Linux und/oder Windows leisten kann.
- Komplexität der API: Von ferne betrachtet ist es entspannt: Gameloop, Systems, Components. Je näher man aber kommt, um so verschachtelter und komplexer und leider auch wirrer wird es. Wenn man selbst was umsetzen möchte, kopiert man entweder existierende Dinge oder steht (als Zweitsemestler) auf dem Schlauch. Eine schöne Illustration zu John Ousterhout's Anti-Pattern "breite Interfaces, flache Klassen" (und das noch hübsch verschachtelt).
- Dokumentation: Dort wo vorhanden, wird häufig nur das über den Code bereits offensichtliche wiedergegeben. Es fehlen Erklärungen zum Kontext, zu den Designentscheidungen, zum Einsatz, ...
- Die Aufgaben im DevDungeon sind schön und interessant. Die Studis werden gezwungen, den Code zu lesen und zum Lösen der Aufgabe müssen sie gar nicht mal so viel Code schreiben. Dennoch ist das Feedback nicht sooo gut: Die Studis müssen einen relativ großen Aufwand treiben, um am Ende einen Heiltrank oder so zu haben. Passt zum späteren Leben, aber zum Üben bestimmter Konzepte ist das Overhead. Eigentlich wäre der nächste Schritt, dass die Studis selbst ein Level bzw. Rätsel definieren, aber angesichts der API und der Dokumentation ist das im zweiten Semester eher aussichtslos. Die Erfahrung im Projekt zeigt, dass man mehrere Wochen bis Monate angeleitet arbeiten muss, bis man selbst Dinge hinbekommt. Da ist das Semester aber schon rum. Zudem waren die Erfahrungen im ersten Lauf ernüchternd, da die wenigsten genug Phantasie für konkrete Spielideen entwickeln und so immer nur das gleiche Monster eben anders angepinselt wurde.
- Code-Qualität: Die Architektur und die API sind über weite Strecken implementierungsgetrieben und ohne erkennbare Recherche zum Stand der Technik entstanden. Es gibt immer wieder richtig gute Bausteine, aber insgesamt ist das Projekt taktisch entwickelt worden. Nach dem Ende der Projekte wird niemand freiwillig die Maintenance oder sogar Weiterentwicklung übernehmen.
Dennoch eignet sich das Dungeon-Projekt an vielen Stellen als Studienobjekt (Commit-Messages, Dokumentation, API-Gestaltung, Tests, ...). Das sollte ausgebaut werden.
ToDo:
- Entferne alle Dungeon-Lectures (Intro, Framework-Lib: Ordner
lecture/misc/) (clean-up: remove frameworks vs. library from lecture #1048, clean-up: remove dungeon-intro from lecture #1049) - Entferne alle DevDungeon-Aufgaben aus den Übungsblättern (clean-up: remove dungeon from homework #1047)
- Baue Aufgaben zur Analyse und Diskussion von Dungeon-Elementen in die Vorlesung und/oder Übung ein (Commit-Messages, Dokumentation, Test, Clean-Code, API, Umgang mit Streams und Optional, ...) #1050
Perspektivisch wird eine Klammer um die Veranstaltung benötigt, wo Git, Testen, FP, Clean Code, Generics, FP, API vorkommen. Demo-Compiler? DevDungeon-Clone mit pure Java? Shattered Pixel Dungeon (aber da ist wieder libGDX drin, also eher nicht). Wenn Spiel, dann deutlich schlanker und freundlicher (Java-Version von #919?!).