Die Methode:

https://github.com/Programmiermethoden/PM-Dungeon/blob/c4ba96c4bcb1c56d1fe0bfae268d24005712910c/code/core/src/level/elements/ILevel.java#L71

fragt solange nach einem zufälligen Tile, bis ein Tile vom gewünschten Element gefunden wurde. Theoretisch könnte es hier zu einer Endlosschleife bzw. langen Wartezeiten kommen.

#Time:1

Prinzipiell möchte ich die Toolchain (Spotless, Checkstyle, Spotbugs) aber auch auf den Dungeon angewendet sehen. Was kommt denn dort raus, also welche Regeln werden wie oft verletzt und ließe sich das leicht reparieren oder sollte man die Limits etwas nach oben ziehen?

Das muss ich mal nachsehen... Ich vermute, ein Anpassen der Limits wäre einfacherer. Aber das sollte vielleicht nicht mehr in diesen pr geschehen...

ja, schaue bitte nach. sobald ich da einen überblick habe, kann ich eine entscheidung treffen.

edit: wir sollten in diesem pr eine möglichst finale version dieser aufgabe und der zugehörigen artefakte einkippen. für alles andere läuft dieser pr einfach zu lang. d.h. mach dir gern ein anderes ticket an geeigneter stelle auf, lasse checkstyle laufen und analysieren die ergebnisse (welche fehler in welcher kategorie wie oft, und würden sich diese fehler relativ leicht beheben lassen oder würde das beispielsweise das auslagern von dutzenden kleinen hilfsklassen erzwingen). dann können wir dort eine entscheidung treffen und hier die sachen entsprechend anpassen vor dem mergen.

Eine andere Möglichkeit wäre, den verletzen Regeln eine niedrige "Prio" zu geben oder später bei Deploy-to-Abgabe nicht zu bewerten.

wäre denkbar. aber ich schätze, die auswertung wird eh schon hakelig genug, und da will ich nicht noch mehr gefrickel mit reinziehen.

ich wäre für ein Anpassen der Checkstyle-Regeln:
Stern-Importe erlauben,
Klasse darf 15 Methoden haben,
Methode darf 100 Zeilen lang sein

ich hab aber keine wirkliche Begründung dafür... aber dass Methoden vertikal nicht zu viele Zeilen enthalten sollten, ist doch schon eine sehr alte Regel.

nur weil sie alt ist, ist sie nicht veraltet. das hat letztlich alles kognitionswissenschaftliche hintergründe - die aufmerksamkeitsspanne von menschen ist im gegensatz zu monitoren nicht größer geworden. und es geht um sw-design.

und hier kommt dazu:

• stern-importe verbergen sehr hübsch, was genau man alles zieht. jaja, ich weiss - in zeiten von npm und node.js ziehe ich mir lieber schnell ne bibliothek als ne for-schleife selbst zu programmieren.
• 15 methoden/100 zeilen: hier geht es einerseits um aufmerksamkeit und wieviele dinge man im kopf behalten kann. andererseits aber auch um design - zu große dinge deuten auf schlechtes design hin (beispielsweise macht eine klasse oder methode vermutlich eben mehr als eine sache).

aber wie ich schon sagte: die regeln von "uncle bob" sind unrealistisch eng, und unsere aufgeweichten aktuellen zahlen sind etwas aus der luft gegriffen. deshalb würde mir eine untersuchung unseres dungeon-codes mit unseren checkstyle-regeln ein besseres gefühl verschaffen.

Originally posted by @cagix in https://github.com/Programmiermethoden/Homework-Solutions/issues/52#issuecomment-1209490672

Im Dungeon ist es schwer richtig zu Debuggen.

Spielinhalte laufen in der GameLoop und diese läuft (per Default) 30-mal pro Sekunde. Hier mit klassischen Debuggen durchzugehen, ist sehr nervig. Außerdem müssen vorher erst bestimmte Situationen ausgelöst werden (teilweise sind diese ja auch zufällig).

Ideen, die mal in den Raum geworfen wurde:

• Verhaltensbasiertes Debuggen
• Eigenes Debugger-Tool als IntelliJ Plugin (verschmelzen mit dem IntelliJ Debugger)
• Debug Menü
• Live Level Editor zum erzeugen bestimmter Spielsituationen.

Monster mit AI: Zusammenarbeit, Lernfähigkeit => Beispiele, Systemdesign, Interfaces

Unsere mangelnde Testabdeckung fällt uns langsam auf die Füße.
Jede Klasse sollte nochmal genau analysiert und getestet werten.

1. Klassen Sammeln (@Lena241)
2. Teststrategie Diskutieren (@AMatutat , @cagix)

• ClassName1
• ClassName2
• ...

Wir sollten ein übergreifendes neues Project Board anlegen, was nicht nur hier im Repo selbst verankert ist. Bitte unterhalb der Organisation ein passendes neues Project anlegen (am besten eines der "neuen Sorte").

Früher haben wir Maven Central verwendet, um das Framework an die Studierenden zu verteilen.
Vorteil: Die Studierenden mussten sich nicht das Projekt-Repository forken, sondern konnten auf einem eigenen (sauberen) Repository arbeiten.
Auch konnten sie keine Änderungen an den Vorgaben vornehmen. Das war in der Praxis sowohl ein Vorteil, da man so einfacher Bugfixes ausliefern konnte, und die Ergebnisse der Studierenden einfacher in das Framework zu integrieren waren. Allerdings war es für einige Studierende auch eine Hürde, da sie gerne an den Vorgaben herumgeschraubt hätten.

Können wir GitHub Packages verwenden und Maven Central dafür ausschließen?
Welche Vor- und Nachteile haben die beiden Varianten?

Aktuell haben wir folgende Bewertungskriterien bestimmt

• JUnit
• Format (Checkstyle)
• Metriken (Spotbugs)
• Test ala Nelson
• JPlag

Gibt es weitere? Welche Aspekte der Programmierung decken diese ab? Wie integrieren wir diese in unsere bestehende Toolchain?

Dieses Issue ist als Sammelbecken für Ideen zu verstehen.

Da wir mit den üblichen Testtools (z.B. Juni) nicht alle Funktionalitäten des Dungeons vollständig testen können, müssen einige Funktionen manuell geprüft werden. Zum Beispiel, ob der Feuerball ordnungsgemäß fliegt oder die Grafik korrekt angezeigt wird.

Der ursprüngliche Gedanke war, eine Checkliste zu erstellen, die vor dem Merge abgearbeitet werden muss. Allerdings ist dies kein zuverlässiges System und eher als temporäre Lösung anzusehen.

In Issue #540 haben wir ein Textkonzept basierend auf Logging diskutiert. Möglicherweise können wir dies als Grundlage nutzen, um auch komplexe Textszenarien abzubilden.

Die Lösungen für die Konzeptblätter werden per PR/MR hochgeladen/abgegeben und werden durch die CI-Pipeline "bewertet". Wir schauen die Ergebnisse der Pipeline manuell an und übersetzen die Ergebnisse (JUnit, Checkstyle, ...) manuell in Punkte. Dazu brauchen wir eine Art Checkliste, wie aus den verschiedenen Ergebnissen dann die Punkte konkret zu berechnen sind.

Unsere Codebasis soll nach den Spotbugs Kriterien verfeinert werden.

Checkstyle und spotless sind eigentlich nur dann relevant, wenn wir uns an die Tools halten würden. Das funktioniert in der Praxis leider nicht. Was die Frage aufwirft, warum wir es noch haben.

Das finde ich grad deutlich zu kurz gedacht (zumal, wenn es von einem wiss. MA kommt).

Die Sachen stelle ich im Unterricht vor. Die Studis bekommen diese Richtlinien, grad bzgl. Checkstyle, als Vorgabe. Da finde ich es etwas kurz gesprungen, wenn wir das mit unserem eigenen Code, den wir den Studis ebenfalls als Vorgabe geben, nicht mal versuchen einzuhalten und einfach sagen "geht irgendwie nicht".

Die Fragen müssten sein:

• Warum funktionieren der Google-Style und/oder die Checkstyle-Richtlinien in der Praxis (bei uns) nicht? Was genau ist die Ursache?
• Wenn es nur "unbequem" ist: Was sollten wir ändern an unseren Strukturen und Arbeitsweisen? Die Sachen sollen ja auch bei der Verbesserung der Codequalität helfen.
• Wenn es tatsächlich "hart" nicht funktioniert: Warum muss der Code so sein, wie er ist und damit die Styles verletzen? Wie müsste man die Style adaptieren?
• Wie sollte der Style aussehen, den wir von den Studis einfordern?

(aus #332)

Der TextureHandler durchsucht nicht nur den asset Folder nach passend benannten Dateien sondern das gesamte Projektverzeichnis.

Mit:

TextureHandler.getInstance().getTexturePaths("Hero");

versucht der TextureHandler also auch meine Hero.java einzulesen.

Der TextureHandler soll auf den asset Folder begrenzt werden.

#Time:2

Da spotless uns im PM-Dungeon bereits einen Fehler wirft, sollte vielleicht nochmal alle libs die wir nutzen stärker eingeschränkt werden, damit nicht solche Fehler kommen, sobald mal ein Update von diesen im Semester kommen und alle in Panik gehen. Bzw. wenn die Auswertung gemacht wird.

Aktuell wurden folgende Plugins wie folgt beschränkt:
id "com.diffplug.spotless" version "6.+"
id "com.github.spotbugs" version "5.+"
Und libs wie folgt:
// https://mvnrepository.com/artifact/org.jetbrains/annotations
implementation "org.jetbrains:annotations:23.0.0"
// https://mvnrepository.com/artifact/junit/junit
testImplementation "junit:junit:4.13.2"

    // https://mvnrepository.com/artifact/org.powermock/powermock-module-junit4
    testImplementation "org.powermock:powermock-module-junit4:2.+"
    // https://mvnrepository.com/artifact/org.powermock/powermock-api-mockito2
    testImplementation "org.powermock:powermock-api-mockito2:2.+"

spotless hat zwei Abhängigkeiten, und zwar spotless-lib und spotless-lib-extra. for spotless 6.11 werden die libs in Version 2.30 benötigt, welches aktuell nicht existiert. Darum muss einmal zurückgegangen werden zu 6.10.+, damit keine Abhängigkeitsfehler existieren.

Edit: Im aktuellen Build-Skript steht

    id "com.github.spotbugs" version "5.0.+"
    id "com.diffplug.spotless" version "6.5.+"

Um hier zu zu machen, einmal die neusten Versionen von Spotbugs und Spotless raussuchen, inclusive. der letzten Versionsnummer Eintragen und Testen (denkt daran temporäre Files zu löschen).

#Time:1

Für Kollisionserkennung wäre ein richtiges Hitbox-System wünschenswert.

Hitboxen sollten jedem Objekt zugewiesen werden können, eine einstellbare Größe haben und miteinander auf Kollision geprüft werden können. Sollte es zu einer Kollision kommen, muss klar sein, aus welcher Richtung diese Kollision kommt.
Auch sollte das Hitbox-System verhindern, dass man in eine Wand hineinlaufen kann.

Ich habe bereits ein paar Grundlagen dafür implementiert, vielleicht kann man darauf aufbauen, vielleicht ist das auch Murks.

Klassischer Weise haben wir für jedes Component auch ein eigenes System. Daher kommt natürlich der Gedanke auf, auch ein System für #232 anzufertigen.
Ich hab nur keine Ahnung was das machen soll.

@Lena241 @AHeinisch bitte denkt beide einmal über mögliche Funktionalitäten eines Stats-Systems nach und wenn euch was einfällt, können wir darüber sprechen. Ansonsten machen wir hier zu.

#Time:1

Es soll ein System für #231 geschrieben werden.
Das System soll

1. Die Erfahrungspunkte für das besiegen von Entitäten an den Bezwinger verteilen (denkt daran, vielleicht greifen Monster auch andere Monster an)
2. Prüfen ob die Entität ein Level-Up bekommen hat, und wenn ja, die onLevelUp Methode triggern + das aktuelle Level erhöhen
3. Kleine Animaton (Shader wären eigentlich besser) um das Level Up zu visualisieren.

Zu 2: Wie viel XP man für einen Levelaufstieg braucht, soll eine Mathematische-Funktion bestimmen (sucht mal was passendes). Dabei soll gelten, je höher mein Level ist, desto länger brauche ich zum nächsten Levelaufsftieg.
Also erst brauch ich nur 50, dann 100, dann 500, dann 2000 usw.

#Time:4

Wir sollten die Erstellung der Tests und das Aufbauen des Deploy-to-Abgabe gleich für eine Restrukturierung der Aufgaben nutzen.

Am Beispiel Observer: Wir haben derzeit diese Struktur:

.
|____vorgabe/
| |____test/
| | |____EinzelhandelTest.java
| | |____GrosshandelTest.java
| | |____AuftragTest.java
| |____src/
| | |____WarenTyp.java
| | |____Grosshandel.java
| | |____Einzelhandel.java
| | |____Main.java
| | |____Auftrag.java
|____loesung/
| |____test/
| | |____EinzelhandelTest.java
| | |____GrosshandelTest.java
| | |____AuftragTest.java
| |____src/
| | |____WarenTyp.java
| | |____Grosshandel.java
| | |____Einzelhandel.java
| | |____IObserver.java
| | |____Main.java
| | |____IObserveable.java
| | |____Auftrag.java
|____aufgabe.md

Dabei ist problematisch, dass aus dem Ordner vorgabe/ mindestens die Tests und Teile des Vorgabecodes nach loesung/ kopiert werden. Zusätzlich ist problematisch, dass direkt im Vorgabecode editiert wird.

Besser wäre eine Trennung in test/, vorgabe/ und loesung/. Dabei wären die Tests und die Vorgaben quasi schreibgeschützt, d.h. hier dürfen die Studis keine Änderungen machen. Die Implementierung der Studis erfolgt dann im Lösungsordner. Für Gradle müsste man dann sowohl vorgabe/ als auch loesung/ als Source-Ordner und test/ als Test-Ordner deklarieren und kann alles gemeinsam kompilieren.

Das würde bedeuten, dass man die Vorgaben einem Refactoring unterziehen müsste und diese als Schnittstellen oder abstrakte Klassen bereit stellt, auf die sich die Lösung dann bezieht.

Ggf. dann noch mit einem src/-Unterordner oder der typischen Maven-Struktur.

Ein Abstrakter Skill für den Fernkampf soll erstellt werden.
Der Skill erstellt eine neue Entity auf einer Flugbahn, die bei Collision Schaden macht.

Anmerkung: Im branch am/demoWithAI hab ich sowas schonmal dirty gecoded, evtl kann man daraus was klauen

Da dieser Skill als erster richtiger Skill umgesetzt wird, ist hier Zeit für Konzept und Experimente einzuberechnen.
Nachfolgende Skills sollten schneller bearbeitet werden können.

#Time:4

Im CI läuft Spotless, Checkstyle, SpotBugs und JUnit. Alle erzeugen Reports. Für Deploy-to-Abgabe wäre es hilfreich, wenn wir diese Reports per Skript o.ä. zu einem einzigen übersichtlichen Report automatisiert zusammenfassen lassen könnten.

https://github.com/PM-Dungeon/dungeon-starter/pull/99#issuecomment-1114486477

Für die Dungeon-Aufgaben sollte es eine Art Lösungsskizze geben: Was muss gemacht werden, wie könnte man das angehen, worauf muss man achten?

Wir hatten darüber gesprochen, die Struktur und alles nötige Wissen einmal hier zu sammeln.
Informationen, die hier im Wiki sinnvoll wären.

• Umgang mit unserer Gradle
  • grundsätzlicher Umgang
    • Was müssen Tutoren machen
    • Was müssen Studis machen
    • Was muss D2A machen
• Die Startparameter von Gradlew
  • was macht -p
  • was mach -P
  • Warum muss Spotless extra behandelt werden? https://github.com/Programmiermethoden/Homework-Solutions/pull/55#issuecomment-1194335357
• Repositories
  • Das Zusammenspiel der Repositories
    • Skizze von dem Verteilungsdiagramm welche Daten wie nach
    • Wie sieht der Workflow aus. Bearbeiten und das Übertragen ins Studi-vorgabe
  • Welche Daten liegen in welchen Repository
    • Wie sieht die Struktur für Homework-Solutions aus? #414
    • Wie sieht die interne Struktur für D2A aus? Programmiermethoden-CampusMinden/Deploy-to-Grading#15

Für den Anfang brauchen wir ein Dungeon mit dem grundlegenden Inhalten:

• Hero
• Monster

Der ScreenInput hat ein Problem mit dem Fokus. Und zwar behält es den Fokus so lange, bis ein anderer ScreenInput angeklickt wurde. Dies schränkt keinen Button oder Ähnliches ein, sondern sorgt nur dafür, dass in dem ScreenInput immer weiter geschrieben wird. Drücken eines Buttons, Labels oder Image nimmt den Fokus nicht weg.

Lösung dafür (die ich finden konnte, welche problematisch sein kann) ist einen riesigen Button auf der tiefsten Ebene anzulegen.
Mir sind dabei aber bereits mögliche Probleme aufgefallen:

• eigener Button liegt vor dem Fokus Button und somit wird der Fokus nicht gelöscht
• Ein Image liegt vor dem Fokus Button und somit kann es sein, dass das Event nicht ausgelöst wird
• Text ähnlich wie beim Image

#Time:4

Das InventoryComponent erlabt es Entitäten Items zu sammeln.

Bitte auch an Tests denken.

Edit: Ein Item sollte auch noch ein String name und ein String description haben

#Time:1

libgdx is starting to piss me off. the configuration is weird and the visualisation isn't that nice and in the end we don't have that much of the library. is there a way to implement the essential functionalities on our own?

edit: (aus #576)

gurkenlabs/litiengine ist ein 2d-java-framework auf der basis von java und awt(!) und ohne weitere abhängigkeiten. zusätzlich integriert es bereits ecs, level-/tile-funktionalitäten u.v.m. ...

damit könnten wir die etwas undurchsichtigen abhängigkeiten in libgdx (insb. die plattformabhängigen teile des frameworks, die beim nächsten update evtl. wieder für bauchschmerzen sorgen) ablösen mit einem reinen java-basierten ansatz.

vermutlich könnten wir auch unser eigenes framework deutlich verschlanken und uns auf die eigentlichen spielelemente fokussieren.

Es schwebt schon länger die Idee (und einige Studis haben es schonmal gemacht) das Dungeon in die dritte Dimension zu holen.
Besonders das "pseudo-3D" der früheren Zeiten (vgl. Doom) gefällt mir persönlich sehr.

Wichtig für eine Erfolgreiche Bearbeitung ist es, dass das Komplexitätslevel des Frameworks (in der Benutzung) für Studierenden im 2. Semester nicht zu groß wird. Aktuell kapselt das Framework die Funktionen zum Zeichnen recht gut ab, das sollte so bleiben.

Wünschenswert wäre es, eine Option für 2D oder 3D. zu haben. as bedeutet aber auch, die interne Logik des Dungeons muss für beide Szenarien funktionieren (ich denke da an Collision checking).

Außerdem müssten Assets zur Verfügung gestellt werden. Die Einstiegshürde nur Assets anzufertigen, sollte so gering wie möglich sein.

Es soll eine konkrete Implementierung des IFight Interfaces geschrieben werden.

Beim MeeleAI bekommt die Entiät einen Skill übergeben und eine float attackRange.
Befindet sich der Spieler in der attackRange soll der Skill ausgeführt werden (die Implementierung des Skills ist NICHT Teil dieses Issues). Sollte der Spieler zu weit entfernt sein, bewegt sich die Entiät auf den Helden hinzu, bis es wieder in Reichweite ist.

Portieren des Java-Hamster-Framesworks in unseren Dungeon

Für die beiden Beispiel Tasks gibt es noch keine Tests.

• Programmiermethoden/Homework-Solutions#49
• Programmiermethoden/Homework-Solutions#50

Wir sollten:

• "-verwenden, wo möglich
• id "com.diffplug.spotless" version "6.+" verwenden
• NotNull-Annotationen hinzufügen
• gradle.properties richtig formatieren
• sourceSets vereinfachen

Neben den klassischen JUnit Tests, könnten sich auch alternative Testmethoden als nützlich erweisen.

Die Nelson-Methode

Die Idee dieser Methode ist es, nicht die konkrete Implementierung zu prüfen, sondern die Ergebnisse zu testen. Dafür wird ein (für die Studierenden unbekannter?) Input-Datensatz durch die definierte Schnittstelle (die Aufgaben müssen entsprechend gestellt sein) eingelesen und von der Studierenden-Lösung verarbeite. Das Ergebnis wird vom Studierenden-Programm ebenfalls exportiert. Das ausgespuckte Ergebnis wird nun mit der Musterlösung verglichen.

Das Visitor-Pattern könnte eine gute erste Experiment-Aufgabe sein. Der Input ist die Reihenfolge der Spielkarten die in den Baum geladen werden. Die beiden Outputs wären die Ausgabe Inorder und Postorder.

JGrade

A library for grading Java assignments

https://github.com/espertus/jgrade

@cagix Ich hatte in Compilerbau schonmal ein Dummy dafür gebaut, existiert das Repository noch? Habe keinen Zugriff mehr auf die Organisation,

@cagix wir haben doch mal darüber gesprochen, das Homework-Solutions Repo entschlacken zu wollen und den ganzen doppelten Code in vorgabe und loesung loszuwerden.

Mit Programmiermethoden/Homework-Solutions#55 haben wir jetzt ja den POC eines Systems, welches mit verteilten Ordnern ein Java-Projekt bilden kann.
Das könnten wir doch auch hier anwenden.

Das richtige Vorgabe Repo binden wir als Subtree ein, das erlaubt ein schnelles Updaten, wenn die Vorgaben sich ändern. Und anders als die Studis würden wir unsere Lösungen nicht in vorgabe/$task/loesung speichern, sondern in $task/loesung parallel zum Vorgabe-Subtree.
Dem "Master"-Buildskript können wir dann dieses Repo als Quelle für die Lösungen übergeben.

Erzeugen verschiedener TileLevel die von ihrer Optik an Räume erinnern.
Dem Raum müssen Türen hinzugefügt werden können.

Siehe auch #19 (comment)

Auf https://itch.io/ finden regelmäßig verschiedene GameJams statt.
Das sind Hackathons nur für Spiele.

Für die meisten GameJams ist es Voraussetzung, dass diese dann auch auf itch.io gespielt werden können.
Es gibt wohl auch support für Java applets: https://itch.io/updates/support-for-java-applets-added

Wenn wir unser Framework kompatibel damit machen, könnten die Studis mit dem Framework/ ihrem Dungeon an solchen GameJams Teilnehmen und müssten nicht erst eine andere Engine lernen.

Als erstes müssen wir herausfinden, welche Änderungen am Framework nötig wären.
Dann müssen wir abwägen, ob sich der Aufwand lohnt bzw. es zu nicht tolerierbaren Einschränkungen kommen würde (ich denke an das libGDX HTML target zurück).

Edit: Es gibt zumindest "native" libGDX Spiele https://itch.io/games/made-with-libgdx

Damit beim git subtree alle relevanten Dokumente mit zur Studi-Vorgabe transferiert werden, müssen diese in den vorgabe Ordner kopiert werden. Nicht verschoben, da beim Verschieben sie nicht mehr für dieses Repo greifen.

• .gitignore
• .gitattributes
• .editorconfig
• license
• README.md <- Studi Repo Beschreibung

Ausgelöst durch eine Aktion des Spielers oder Questfortschritt
Schaden an Spielern (oder und zusätzlich an Gegnern)
Rollender Fels:
Fällt von oben in den Dungeon und rollt in eine festgelegte Anfangsrichtung
Ändert bei Kontakt mit Wänden die Richtung
Zerfällt nach Anzahl zurückgelegter Tiles und oder Anzahl der Wandkontakte
Pfeilschuss Anlage:
Schießt einen oder mehrere Pfeile in eine festgelegte Himmelsrichtung
Stachelfalle:
Fährt Stacheln aus dem Boden aus
Variante A: regelmäßiges ein- und ausfahren
Variante B: ausgelöst durch eine Aktion oder Quest (vorher unsichtbar)

Alle PRs in den Master sollten für Spotbugs formatiert sein.
Sollte sich aus dem PM-Dungeon copy pasten lassen.

Aktuell ist sowohl Name als auch Pfad zum Target-Repo (das wo die Lösungen liegen) hardcoded.
Für die Action ist das kein Problem, da wir hier unsere eigene Orderstruktur erstellen können, auch für Programmiermethoden-CampusMinden/Deploy-to-Grading#25 ist das okay.
Aber für Programmiermethoden-CampusMinden/Deploy-to-Grading#26 nicht, damit wollen die Studierenden ihr Repo "testen" und dafür sollten sie nicht gezwungen sein den Namen ihres Workingdirs zu ändern.

tldr: Das Python-Skript soll um ein Command-Line-Argument für den Pfad zum Target-Repo ergänzt werden.

Umsetzten des graphenbasierten Level nach dem Single-Room Ansatz.

Knoten = Raum
Kanten = Tür zwischen zwei Räumen
Raum = ein TileLevel
Doors = Verbindung zwischen zwei Tiles in zwei unterschiedlichen TileLevel
TreeLevel = Liste von TileLevel und Doors

Siehe auch: #19 (comment)

Mal wieder eine Kleinigkeit, die etwas komisch ist, und zwar hat das setScale bei allen auf Text basierenden Elementen keinen Einfluss, da dort nur die Größe betrachtet wird. Das ist dann besonders lustig beim Button, wo der Listener Events empfängt, welche nicht auf der Fläche des Buttons sind.

Dies ist mir besonders aufgefallen als ich dem QS den Teil für das UI anfügen wollte.

• Button scale sperren bzw. so umleiten das nur die Size verändert wird.
• ScreenText scale vielleicht umleiten auf setFontScale welches den Font nachträglich vergrößert.
• ScreenInput ähnliches Verhalten wie Button?

Unsere Codebasis soll nach den Checkstyle Kriterien verfeinert werden.

Checkstyle und spotless sind eigentlich nur dann relevant, wenn wir uns an die Tools halten würden. Das funktioniert in der Praxis leider nicht. Was die Frage aufwirft, warum wir es noch haben.

Das finde ich grad deutlich zu kurz gedacht (zumal, wenn es von einem wiss. MA kommt).

Die Sachen stelle ich im Unterricht vor. Die Studis bekommen diese Richtlinien, grad bzgl. Checkstyle, als Vorgabe. Da finde ich es etwas kurz gesprungen, wenn wir das mit unserem eigenen Code, den wir den Studis ebenfalls als Vorgabe geben, nicht mal versuchen einzuhalten und einfach sagen "geht irgendwie nicht".

Die Fragen müssten sein:

• Warum funktionieren der Google-Style und/oder die Checkstyle-Richtlinien in der Praxis (bei uns) nicht? Was genau ist die Ursache?
• Wenn es nur "unbequem" ist: Was sollten wir ändern an unseren Strukturen und Arbeitsweisen? Die Sachen sollen ja auch bei der Verbesserung der Codequalität helfen.
• Wenn es tatsächlich "hart" nicht funktioniert: Warum muss der Code so sein, wie er ist und damit die Styles verletzen? Wie müsste man die Style adaptieren?
• Wie sollte der Style aussehen, den wir von den Studis einfordern?

(aus #332)

Can we make some kind of MMORPG out of this?

Unsere mangelnde Testabdeckung fällt uns langsam auf die Füße.
Jede Klasse sollte nochmal genau analysiert und getestet werten.

1. Klassen Sammeln (@Lena241)
2. Teststrategie Diskutieren (@AMatutat , @cagix)

• ClassName1
• ClassName2
• ...

Folgende Ergebnisse sollen in der Action nach ablau des Skriptes ausgegeben werden.

• Studi-Punkte: Eine Tabelle mit Mail des Studis, Task, Erreichte Punkte, Gesamt Punkte
• Für jeden Task die erzeugten .xml -Files
  • JUnit
  • Spotbugs
  • Checkstyle
  • Spotless

Das Framework ist auf dem aktuellen Raspberry Pi Geräten nicht lauffähig. Ursache hierfür, wird vermutlich libGDX selbst sein.

PIs erlauben uns mehr Flexibilität in der Strukturierung des Praktikums und sind zeitgleich eine gute Fallback-Ebene, falls andere Betriebssysteme streiken sollten.

Vielleicht wäre es gut bei den einzelnen Aufgaben immer eine kurze Checkliste dabei zu haben, die die wichtigsten Punkte wiedergibt. Damit würde man die Studenten (und die Tutoren ebenso) auch noch mal an die wiederkehrenden Aufgaben erinnern. Zum Beispiel könnte man sagen "Tasks: Pattern implementieren, JavaDoc, JUnit Test, Logging". Was haltet ihr davon?

Edit: Wird eventuell obsolet durch https://github.com/PM-Dungeon/PM-Lecture/issues/465

Es soll eine konkrete Implementierung des IIdle Interfaces geschrieben werden.
Beim RadiusWalk soll sich die (von der AI) gesteuerte Entität ein betretbares Tile im vorher definierten Radius suchen (Mittelpunkt ist dabei die aktuelle Position der Entiät), dann dort hin gehen, dort kurz warten und sich dann ein neues Ziel suchen.

Fragen, die beim Einlesen im Abgabe Skript entstanden sind.

Welche Art vom Mapping der Ergebnisse der Tools werden benötigt?

• Schwellwert oder Linear
• Alle Punkte an einem Tool verlieren oder nur bis zu bestimmten Punkten
• Für alle Task identisch oder pro Task ein eigenes Mapping oder ein überschreibbares Mapping
• Wie soll die Struktur für diese Konfiguration aussehen

Durch die neue Tabelle von https://github.com/Programmiermethoden/Homework-Solutions/pull/65#issuecomment-1225279752 muss noch geguckt werden, wie die User, die an einem Task beteiligt waren am Ende beim Export zur Verfügung gestellt werden.

Vermutlich ist es Sinnvoll erst #17 umzusetzen.

Wenn Held und Monster aufeinander treffen kommt es zum kampf.

Ein simples System wäre es, einfach auf Kollision zu prüfen.
Alternativ könnte auch eine Kampfaktion ausgeführt werden (auf Knopfdruck nach vorne schlagen).

Wenn ein Charakter getroffen wurde, dann soll dieser Schaden bekommen und etwas zurückgestoßt werden.
Wenn ein Monster keine Lebenspunkte mehr hat, soll es sterben und aus dem Spiel entfernt werden.
Wenn der Held stirbt, soll das Spiel neu gestartet werden.

Für mavencentral muss der Key alle2 Jahre geupdated werden. Kann man das automatisieren? Kann man ein geplantes Issue anlegen, was früh genug bescheid sagt?

@Tobias321 kannst du nochmal spezifizieren welcher Key genau das war? Hab mir das natürlich nicht notiert.