cagix
commented
1 year ago Wie heute diskutiert:
Es macht für mich viel Sinn, über ein Mono-Repo nachzudenken, in dem verschiedene (IntelliJ-) Projekte auf Root-Ebene parallel leben:
- PM-Dungeon (Framework)
- DSL-Anbindung (Dungeon/game/dslToGame)
- DSL und Compiler (Dungeon/dsl)
- Vorimplementierte Basisfunktionen, die für die Generierung der Rätsel benötigt werden (Hitbox, ...)
Wenn ich es richtig verstanden habe, müssen für den PM-Dungeon (das Framework) eigentlich keine Änderungen erfolgen - es könnten/sollten aber nicht mehr benötigte Strukturen entfernt werden. Das ECS-Package würde vermutlich nach dem Merge dann direkt in das Framework wandern. Vielleicht gibt es noch weitere Packages im Dungeon, die dann in den PM-Dungeon-Source-Tree wandern (nach dem Merge!)?
Die Ordnerstrukturen müssten vorher in beiden Repos so angepasst werden, dass sie gewissermaßen "übereinandergelegt" werden können. Dann kann man den Master-Tree vom Dungeon nehmen und als neue zusätzliche Wurzel im PM-Dungeon reinziehen und beide mergen. So bleiben sowohl die Historie als auch die Contributors erhalten.
Die Issue und evtl. die Discussions können verschoben werden. PRs sind dann verloren, aber vielleicht ist das auch langfristig unrelevant. Meilensteine müssten neu im PM-Dungeon angelegt werden (geht auch über die API, aber vermutlich ist es schneller manuell gemacht) - am besten vor dem Verschieben der Issues.
Im resultierenden Mono-Repo sollten die Strukturen (Projekte und Packages) so aufgeteilt werden, dass man mit einem git subtree split den Kram ggf. auch wieder einfach trennen kann.
Die GH-Workflows müssen ggf. angepasst werden. Der PM-Dungeon-Tree sollte mind. ein Tag bekommen; vielleicht sollte man sich aber auch von der aktuellen Versionsnummerngeschichte bei der Gelegenheit verabschieden und einfach Semesterweise ein Tag vergeben (tbd[^1]). Dito könnte man bei der Gelegenheit nochmal Maven Central überdenken und ob man nicht auch Github als Provider für das PM-Dungeon-JAR in Gradle nutzen kann.
Für die Studierenden würden wir ein neues Repo anlegen mit einer minimalen Konfiguration (Gradle), die sich ein JAR vom PM-Dungeon-Teil zieht und wo die Studis dann ihre Implementierung erledigen. Wenn sich jemand unser Repo nimmt, passiert das auf eigene Gefahr.
Ein möglicher Nachteil ist, dass die Studierenden im Teil (Projekt? Package?) für die vorimplementierten Basisfunktionen Dinge sehen könnten, die sie eigentlich selbst implementieren sollen. Aber vielleicht kann man das so ummünzen, dass sie hier ein Codestudium machen und so eine bessere Idee bekommen, wie etwas umgesetzt werden kann und auf der Basis ihre eigenen Implementierungen machen.
[^1]: Im Semester sollen die Studis einfach immer die aktuelle Version im master[^2] einsetzen, hier werden ausschließlich Bugs gefixt. Neue Features gibt es im Semester nicht bzw. nur in einem parallelen Branch, der erst nach dem Semester gemergt wird[^3]. So sollten die Studis immer die beste Version haben und keine Probleme mit nicht kompatiblen Änderungen bekommen.[^4]
[^2]: Nach jedem Merge in den master wird das JAR als Artefakt neu gebaut - es ist also egal, ob die Studis mit dem JAR oder dem Source im master arbeiten.
[^3]: Diesen Feature-Branch sollte man dann auch immer regelmäßig auf die Spitze des aktuellen masters rebasen, damit dort dann auch die Bugfixes drin sind.
[^4]: Falls wir doch Versionen brauchen, weil man sonst kein GH-Release hinkriegt, dann wäre das sowas wie S23.1, also "Semester.lfdeNummer".
AMatutat
Im Dungeon haben wir dieses Framework genutzt, um eine ECS basierte Struktur aufzusetzen. Das hat gut Funktioniert und das entwickeln neuer Features im ECS ist deutlich angenehmer. Zusätzlich ist die Lesbarkeit der Strukturen und des Codes deutlich einfacher.
Es wäre denkbar, das Framework vollständig auf dieses ECS System umzubauen. Dafür könnten wir viel des Codes im Dungeon übernehmen. Nach einer erster Einschätzung müsste kein/nur wenig Code neu geschrieben werden, einige Strukturen könnten sogar entfernt werden.
Was mir besonders gut gefällt ist, das wir im Dungeon bereits einiges an Basisfunktionen implementiert haben und dann direkt mit vorgeben könnten. Ich denke da z.B an das Hitbox-System, welches das Spiel stark aufwertet aber einfach doof zu implementieren ist und für Studis auch nicht grade motivieren ist. Die Studis könnten sich also mehr auf "sichtbare" Spielinhalte konzentrieren.
Edit:
Ich erstell mir hier mal eine Checkliste, und wenn wir hier fertig sind tranferiere ich dieses Issue nach drüben und generier mir Issues aus der Checkliste