clean-up: remove dungeon-intro from lecture (#1049)

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.


closes  #1046

Author: cagix