[Thesis] HUD Konzept überarbeiten

[AMatutat]

Das Dungeon HUD-Konstrukt ist ... schrecklich (?). Wir verwenden unterschiedliche Konzepte für die Quizfragen-Dialoge, HUD-Elemente wie Lebensbalken, usw. und Inventar/Crafting GUI. Es wäre wirklich schön, das Ganze in einem Konzept vereinen zu können. Da @fwatermann bereits die Inventar/Crafting GUI umgesetzt hat (und dabei libGDX zum Teil ausgeklammert hat), könnte er hier ein Konzept erarbeiten, über das wir dann mal sprechen können.

[fwatermann]

GUI-Konzept

Hierachischer Aufbau

• Root-Element (GUIWindow) beinhält n-beliebige GUI-Elemente
• Layout-System (ähnlich zu Java-Swing?):
  • GUI-Elemente werden nach Regeln in einem GUIContainer skaliert und platziert
  • Layouts lassen sich durch implementieren vom IGUILayout Interface erstellen
  • Elemente können einen oder mehrere GUILayoutHints haben
    • Beispiel (Grid Layout): Zeilen/Spalten angabe, in welcher das GUI-Element angezeigt wird
• Events laufen den GUI-Baum in Form eines Breitendurchlaufs durch.
• Layouts:
  • EntityLayout: Ein Layout, welches ein GUI-Element relativ zu einem Entity in der Welt auf den Bildschirm platziert. Gut für z.B. Lebensanzeigen
  • GridLayout: Ein klassisches Layout in form eines Grids. Z.B. 5 Zeilen, 5 Spalten
  • BorderLayout: Ein zentrales Element mit 4 weiteren Elementen drumeherum.
  • AbsolutLayout: Platziere ein GUIElementen basierend auf auf X-,Y-Pixelangaben
  • (Weitere, eventuell benötigte lassen sich recht schnell durch das Implementieren des IGUILayout Interfaces ergänzen.)
• Elemente:
  • Text
  • Button
  • Checkbox
  • Radiobuttons (& Groups)
  • Text-Input
  • Number-Input
  • Images
  • Weitere Elemente lassen sich schnell durch das Implementieren der abstrakten Klasse GUIElement ergänzen.

Abstraktions-Ebene (Rendering & Events)

• Backend Interfaces
  • Rendering Backends (für z.B. OpenGL oder libGDX) werden durch die Implementation vom IGUIRenderBackend Interface geschaffen, welches die nötigen Methoden fürs Rendering zur Verfügung stellt.
  • Event Backends (für z.B. GLFW oder glut) werden durch die Implementation vom IGUIEventBackend Interface geschaffen, welches die nötigen Methoden zum registrieren von Listenern für z.B. Keyboard-Events oder Mouse-Events zur Verfügung stellt.

[fwatermann]

Am liebsten würde ich das ganze komplett ohne libGDX implementieren, daher direkt auf OpenGL/GLFW (ist via LWJGL in libGDX soweit ich weiß alles enthalten)

[AMatutat]

Am liebsten würde ich das ganze komplett ohne libGDX implementieren, daher direkt auf OpenGL/GLFW (ist via LWJGL in libGDX soweit ich weiß alles enthalten)

Ich finde das prinzipiell nicht doof, aber es klingt für mich auch sehr schwer in der Wartung (also wenn du dann mal weg bist) + wie können die Studierenden damit umgehen? Da braucht es dann eine gute Schnittstelle.

[fwatermann]

Ich denke tatsächlich, dass durch diese Abstraktionsebene die Wartung einfacher wird, weil im "inneren Code", also z.B. in GUIElement nur simple Funktionen des Backends aufgerufen werden, wie z.B. drawRectangle etc.

[AMatutat]

@fwatermann grade im meeting besprochen: Für diesen Monat leg deinen Fokus mal auf diesen Task.
Wir reden im nächsten SHK Meeting dann nochmal detaillierter darüber.

Für mich ist die große Frage: Wie sieht eine Schnittstelle zum Anwender aus? Ich will nämlich nicht "manuell" irgendwelche Vierecke zeichnen.

[fwatermann]

Mein Ziel ist es für den Anwender so simpel wie möglich zu machen, sodass er sich seine GUI aus existierenden Elementen zusammenwürfeln kann bzw. auch eigene neue Elemente aus bestehenden Elementen basteln kann.

[AMatutat]

Mein Ziel ist es für den Anwender so simpel wie möglich zu machen, sodass er sich seine GUI aus existierenden Elementen zusammenwürfeln kann bzw. auch eigene neue Elemente aus bestehenden Elementen basteln kann.

Gut, das war irgendwie ... klar (hoffentlich) :D
Kannst du mir dazu mal eine Art Ablauf Skizzieren?

Ich stell mir das ganze wie eine Art Baukasten mit unterschiedlichen Ebene vor:

• Die unterste Eben ist openGL (oders so) also das zeichnen der Vierecke etc.
• Eine ebene Höher sind Hud-Elemente die ich dann anordnen kann. Also sowas wie Text-Feld, Button etc. Wie könnte da die API aussehen?
• Ganz oben ist dann die Anwender-Ebene, da geb ich nurnoch sowas wie `zeigFenster.("Hier steht ein roman. War toll oder?,"ja","nein"). Und daraus wird mir ein schönes HUD-Fenster erstellt.

Ich als Dungeon-Master will später nicht tiefer als Ebene zwei gehen (ich will keine Vierecke malen) um neue Fenster-Elemente/Tpyen hinzuzufügen. Daher muss die unterste Ebene gescheite Schnittstellen liefern.
Malte als DSL-Master will nur die oberste Ebene bedienen.

Und dann ist da noch das Theme "Dynamische Skalierung", das hatte uns beim alten System ja echt Schwierigkeiten gemacht.

[cagix]

Am liebsten würde ich das ganze komplett ohne libGDX implementieren, daher direkt auf OpenGL/GLFW (ist via LWJGL in libGDX soweit ich weiß alles enthalten)

@fwatermann @AMatutat Wieviel Kram nutzen wir tatsächlich von den Möglichkeiten von libJGDX? Wenn @fwatermann tatsächlich das HUD abkoppelt und mit LWJGL implementiert, könnte man den Rest dann auch direkt auf dieser Lib (selbst) implementieren? Oder ist das vermessen?

Wenn das klappen würde, fände ich das HUD direkt in LWJGL nicht schlecht. Wenn wir aber nachher Konzepte aus libGDX und parallel dann noch direkt aus LWJGL nutzen, senkt das für mich die Wartbarkeit. LWJGL ist zwar bereits als Abhängigkeit dabei, aber wir nutzen das bisher ja nur indirekt.

[cagix]

Mein Ziel ist es für den Anwender so simpel wie möglich zu machen, sodass er sich seine GUI aus existierenden Elementen zusammenwürfeln kann bzw. auch eigene neue Elemente aus bestehenden Elementen basteln kann.

@fwatermann Gibt es bereits Projekte, die sowas machen (vermutlich)? Welche Strukturen haben die gewählt? Das sollten wir einfließen lassen ... Wir müssen das Rad ja nicht immer neu erfinden :)

[AMatutat]

Wenn das klappen würde, fände ich das HUD direkt in LWJGL nicht schlecht. Wenn wir aber nachher Konzepte aus libGDX und parallel dann noch direkt aus LWJGL nutzen, senkt das für mich die Wartbarkeit. LWJGL ist zwar bereits als Abhängigkeit dabei, aber wir nutzen das bisher ja nur indirekt.

Zielsetzung sollte schon sein: libGDX komplett aus den HUD zu entfernen und @Lena241 zieht an den anderen stellen den Stecker von libGDX. Und dann ist das Ding raus.

[fwatermann]

Ich stell mir das ganze wie eine Art Baukasten mit unterschiedlichen Ebene vor:

Die unterste Eben ist openGL (oders so) also das zeichnen der Vierecke etc.
Eine ebene Höher sind Hud-Elemente die ich dann anordnen kann. Also sowas wie Text-Feld, Button etc. Wie könnte da die API > aussehen?
Ganz oben ist dann die Anwender-Ebene, da geb ich nurnoch sowas wie `zeigFenster.("Hier steht ein roman. War toll oder?,"ja","nein"). Und daraus wird mir ein schönes HUD-Fenster erstellt.

@AMatutat genau das ist der Plan. Wie genau die API da aussieht, kann ich dir jetzt gerade noch nicht sagen, muss mir da in der Birne erst was ausdenken, und das passiert beim ausprobieren hier gerade.

Und dann ist da noch das Theme "Dynamische Skalierung", das hatte uns beim alten System ja echt Schwierigkeiten gemacht.

Das habe ich mit auf dem Schirm, daher ja das oben erwähnte Layout gedöns, was das ganze dann übernimmt.

[cagix]

Wenn das klappen würde, fände ich das HUD direkt in LWJGL nicht schlecht. Wenn wir aber nachher Konzepte aus libGDX und parallel dann noch direkt aus LWJGL nutzen, senkt das für mich die Wartbarkeit. LWJGL ist zwar bereits als Abhängigkeit dabei, aber wir nutzen das bisher ja nur indirekt.

Zielsetzung sollte schon sein: libGDX komplett aus den HUD zu entfernen und @Lena241 zieht an den anderen stellen den Stecker von libGDX. Und dann ist das Ding raus.

Genau. Aber ich hätte vorher gern eine grobe Abschätzung, was davon alles betroffen ist und wie das ungefähr mit LWJGL aussehen könnte bzw. ob es prinzipiell umsetzbar erscheint.

Edit: Ergänze noch "grob" und "ungefähr" und "umsetzbar erscheint" ... Es soll ja jetzt noch kein fertiges Umsetzungskonzept gemacht werden, nur eine Abschätzung :)

[AMatutat]

Genau. Aber ich hätte vorher gern eine Abschätzung, was davon alles betroffen ist und wie das mit LWJGL aussehen könnte.

Klar. Wenn wir nach 2/3 merken das wir andere Sachen nicht ersetzt kriegen, dann ist die Übung zwecklos.