Erste Aufgabe

[AMatutat]

Idee

Wir wollen eine konkrete Übungsaufgaben nehmen und in das Dungeon integrieren. Nach Besprechung haben wir uns für eine Graphensuch Aufgabe entschieden.

Referenzaufgabe

Die Aufgabe ohne Dungeonkontext würde in etwa so aussehen.

Graph in DOT-Form (falls benötigt) 
digraph G {
edge [dir=none]
G->T
T->Q
Q->D
Q->F
T->X
X->S
G->W
W->E
W->C
C->U
C->N
}

Aufgabe: Führen Sie im oben dargestellten Baum eine Pre-Order Suche durch. Geben Sie die Werte in der Reihenfolge an, in der die Knoten besucht werden.

Bewertung: Korrekte Reihenfolgen, ggf. Teilpunkte für Dreher.

Systemablaufskizze

Die Lehrperson gibt mithilfe der DSL die Quest-Konfiguration (Typ der Aufgabe, Aufgabentext, Bewertung, ...?) und den Graphen vor.
Die Eingabe wird geparsed (richtiger Begriff?) und dann an die API übergeben. Hier meint API die Schnittstelle zwischen DSL und Dungeon. Die API "erzeugt" aus der Eingabe zu einem ein QuestConfigurationObjekt und ein Graph Objekt und übergibt diese an das Dungeon.
Das Dungeon baut aus dem Graphen ein entsprechendes Level und erstellt aus der Quest-Konfiguration die eigentliche Quest. Das Dungeon selbst liefert dann auch noch die ganzen Gameplay Elemente (Spieler, Monster, Waffen etc.).
Das System "Spiel" gibt es so eigentlich nicht und hilft nur bei der Darstellung.

[AlexJ2017]

Konkretes Aufgabenbeispiel

Zu Beginn der Aufgabe befindet sich der Spieler in einem Raum mit einer Schatztruhe und zwei Türen. Es ist immer nur der Raum sichtbar, in dem sich der Spieler befindet.
Der Spieler erhält den folgenden Questtext:

"Öffne die Schatztruhe mit dem korrekten Passwort! Das Passwort setzt sich aus einzelnen Buchstaben zusammen, die in den Räumen des Dungeons zu finden sind. Die Räume sind in einer Baumstruktur angeordnet. Der Raum mit der Schatztruhe stellt die Wurzel des Baumes dar. Um diese Truhe zu öffnen muss das Passwort in Pre-Order Reihenfolge angegeben werden."

In dem Spielfenster gibt es eine Mini-Map, auf der die Räume des Dungeons angezeigt sind.
Der aktuelle Raum, in dem sich der Spieler befindet ist farblich umrandet. Räume die bereits einmal betreten wurden haben einen farbigen Hintergrund.
Die Map sieht zu Beginn so aus:

Im Startraum befindet sich neben der Schatztruhe noch das erste Passwortfragment als sammelbares Item auf einem Bodenfeld.
Der Spieler bewegt den Helden mit der Tastatur zu dem Item und nimmt das Passwortfragment durch die Berührung auf.
Im HUD ist für 5 Sekunden folgender Text zu lesen:

"Ein Passwortfragment wurde aufgesammelt: G"

Die Mini-Map aktualisiert sich wie folgt:

Der Spieler bewegt den Helden zu der Schatztruhe und betätigt die Taste zum interagieren.
Im HUD wird folgender Text angezeigt:

"Held: Ich habe noch nicht alle Passwortfragmente gefunden. Ich sollte zunächst den Dungeon weiter erkunden."

Der Spieler bewegt den Helden zu der linken Tür und verlässt so den Raum.
Jetzt befindet sich der Spieler in einem neuen Raum, was auf der Mini-Map sichtbar ist:

In dem Raum befinden sich 2 Gegner und ein Passwortfragment.
Der Spieler bekämpft die Gegner und besiegt sie. Einer der Gegner lässt einen Heiltrank fallen, den der Spieler mitnimmt.

Dann sammelt er das Passwortfragment auf.
Es wird erneut der Infotext im HUD ausgegeben und die Karte passt sich an:

Der Spieler verlässt den Raum durch die rechte Tür und betritt den nächsten Raum:

In dem Raum sind erneut 3 Gegner und ein Passwortfragment.
Der Spieler bewegt den Helden direkt in den nächsten Raum, ohne die Gegner zu bekämpfen und das Passwortfragment aufzusammeln:

In diesem Raum gibt es neben der Tür, durch die der Spieler gekommen ist, nur ein Passwortfragment.
Der Spieler sammelt dieses mit dem Helden ein:

Danach verlässt der Spieler den Raum durch die Tür oben.

Der Spieler erkundet auf diese Weise mit seinem Helden den gesamten Dungeon und kehrt anschließend zum Anfangsraum zurück.
Die vollständige Mini-Map zeigt alle Passwortfragmente an:

Der Spieler bewegt den Helden erneut zu der Schatztruhe und interagiert damit.
Ein Eingabefenster öffnet sich:

Der Spieler tippt zunächst das Codewort GTWQXECDFSUN ein und bestätigt seine Eingabe.
Auf dem HUD wird folgender Text angezeigt:

"Held: Das war das falsche Passwort. Wie war das nochmal mit der Reihenfolge?"

Der Spieler interagiert erneut mit der Truhe und gibt in dem Eingabefenster den Code GTQDFXSWECUN ein und bestätigt die Eingabe. Die Truhe öffnet sich. In einem Fenster kann der Spieler den Truheninhalt einsehen und in sein Inventar aufnehmen. Im HUD wird die Quest als erfüllt abgehakt. Der Held erhält Erfahrungspunkte für den Abschluss der Quest.
Zusätzlich wird im HUD der folgende Infotext angezeigt:

"Quest erfüllt! Es wurden 2 Versuche benötigt um die Truhe zu öffnen."
In dem Raum wird ein Loch im Boden mit einer Leiter sichtbar.

Der Spieler bewegt den Helden zu dem Loch, interagiert per Tastendruck damit und beendet so das Level.

[malt-r]

Requirements für DSL

Definition von Graph/Baum im .dot format:

• Rendering als jpg muss nicht von DSL-Interpreter geleistet werden, kann an dot deligiert
  werden
• erlauben von graph / digraph Definition auf oberstem DSL-Level (digraph / graph
  dot-Umgebung) -> wird dann von DSL als Baum/Graph-Datentyp behandelt

  digraph / graph G {
    <embedded dot code>
  }
  

• Graphen/Baum-basierte Generierung & Password-Extraktion erfordert Parsing von Baum-Definition

Definition mit Reihenfolge

• linker & rechter Knoten müssen klar definiert werden, da dies für Bewertung
  wichtig ist
  • über '[ordering="out"]' Attribut für dot-Knoten kann festgelegt werden,
    dass die Kanten eines Knoten in der Definitionsreihenfolge von links nach
    rechts angeordnet werden (mit "in" anders rum)

Beispiel

digraph G {
  node[ordering="out" shape="box"]
  C -> E
  C -> D 
  A -> C
  A -> B
}

Wird gerendert zu:

• User sollte in der Lage sein, mehrere Alternativen anzugeben, von denen eine
  ausgewählt wird, Randomisierung der Aufgaben

Questdesign

Idee: Baumtraversierung soll als Suche nach einem Passwort für eine Schatztruhe
verpackt werden

• Questtexte müssen definiert werden
• Game-Objects müssen definiert werden
• Funktion für OnInteract-Handler für Truhe -> Texteingabe -> Validierung -> Reaktion (falsch / richtig)
  • kann schlecht durch Game-Framework festgelegt werden, das setzt zu starkes
    Hardcoden voraus -> vmtl. aber erstmal hardcoden & nachher in DSL ermöglichen
  • Idee: Um zu späterem Zeitpunkt (wenn DSL ausgereifter) zu signalisieren, dass Aufgabe beendet ist, könnte eine globale DSL-Funktion definiert werden, die in DSL-Runtime einen Ausgang im Level erscheinen lässt

Wahl von Aufgabentyp & Auswahl des Suchverfahrens

• Wie soll das durch DSL abgebildet werden?
• bfs (breadth-first-search), dfs (depth-first-search), pre-, in-, post-order
  • das hat allerdings nur Auswirkungen auf das erwartete Passwort, Raum-Layout
    bleibt unbeeinflusst
• Angabe von Quest-Configuration-Block
  • hier muss dann allerdings ein Mechanismus vorgesehen werden, der überprüft, ob es sich beim übergebenen Graph auch tatsächlich um einen Baum handelt

quest_config {
  type: tree_traverse
  style: dfs_preorder
  tree: <embedded_dot_graph>
}

[malt-r]

DSL Design Überlegungen

• Unsicherhiet, ob das in dieser Aufgabe angepeilte Abstraktionslevel eine gute Entscheidung ist, da der Aufgabentyp & das
  Suchverfahren direkt in unser Framework (nicht auf DSL-Ebene) reingebacken wird; das lässt auf lange Sicht viel Arbeit in Verbindung von API & Dungeon entstehen
• Die DSL sollte auf lange Sicht so flexibel angelegt sein, dass die genannten Aspekte
  komplett durch die DSL abgebildet werden können, um den Lehrpersonen möglichst
  große Flexibilität zu lassen (ansonsten sind wir in der Pflicht, die Interna
  unseres Frameworks zu erweitern, um neue Aufgabentypen zuzulassen - was dem ursprünglichen
  Gedanken genau widerspricht)
• Im Kontext von dieser Aufgabe könnte das so aussehen, dass eine DSL-Funktion
  definiert wird, die den Baum in der gewünschten Form traversiert und dabei
  das Passwort extrahiert
  • Dafür könnte der DSL-Datentyp 'graph/digraph' Helfer-Funktionen (z.B. pre-, in-,
    post-order Iterator) zur Verfügung stellen, die über Knoten iterieren und Zugriff
    auf die Informationen des dot-Knotens (Name, Label, etc.) zulassen

[malt-r]

Beispielhafte Implementierung (DSL)

graph g {
  G--T
  T--Q
  Q--D
  Q--F
  T--X
  X--S
  G--W
  W--E
  W--C
  C--U
  C--N
}

quest_config conf {
  style: tree_traversal,
  type: dfs_pre_order,
  tree: g,
  points: 3,
  task_desc: "Öffne die Schatztruhe mit dem korrekten Passwort! Das Passwort setzt 
  sich aus einzelnen Buchstaben zusammen, die in den Räumen des Dungeons zu 
  finden sind. Die Räume sind in einer Baumstruktur angeordnet. Der Raum mit der
  Schatztruhe stellt die Wurzel des Baumes dar. Um diese Truhe zu öffnen muss 
  das Passwort in **Pre-Order** Reihenfolge angegeben werden.",
}

set_quest(conf)

[malt-r]

Überlegungen bzgl. Umsetzung dieser Aufgabe per DSL

Komponenten, die für die Realisierung des Graph-Search Prototypen verwendet werden (Stand: 83db37b)

• QuestFactory
  • erstellt aus QuestConfig eine Quest
  • ruft den Level-Generator auf
    • also platziert effektiv Räume
  • platziert Quest-Objects
    • LetterChests
    • PasswordChest
  • erstellt UI-Elements
    • die sollten im Übrigen das ganze Spiel anhalten
  • Definition von UserPerformance Evaluierung
• Allgemeine Game-Objekts etc.
  • Truhen (allgemeiner Interactables)
    • onInteract
  • Monster
    • vielleicht onAttack-Methode in DSL überschreibbar machen?
• Binding von Enum-Varianten?
  • bspw. von dem QuestType
  • könnte quasi als AliasType in der Standard-Bibliothek ge-remappt werden

Was soll die DSL davon können?

• Räume definieren
  • Game-Objects in Raum platzieren
  • Nebenräume festlegen
  • Note: ersetzt nicht den bestehenden Raumgenerator, sondern gibt nur
    bestimmte Bedingungen für Räume (welche Objects sind enthalten, was sind die
    Neighbors?) vor
    • könnte auch mit Graph-Ansatz verbunden werden, sodass es für einen Knoten einfach
      schon eine Raumdefinition gibt, die nicht extra vom Framework generiert werden
      muss
• Password-Truhe und Letter-Item definieren
• Handler-Methoden (bspw. onInteract von Interactable Objekten) durch Scripting überschreiben/ergänzen
• popUp-Textfeld aufploppen lassen (einfach als Funktionsaufruf) -> Rückgabewert
  ist dann der Eingabestring
  • was passiert, wenn gecancelt wird?
    • leerer String?
    • zwei Execution-Branches für solche Fälle vorsehen?

Zugriff auf Objekte in DSL

• Erfordert Methoden (Instanz-Funktion mit self-Parameter)
• Bsp: Graph-Objekt
  • Zugriff auf Knoten und Kanten erlauben
  • Zugriff auf Attribute der Knoten und Kanten erlauben
  • Erfordert auch "Klassen" für die Knoten und Kanten, die eine Methode haben,
    die Property-Bags zurück gibt, welche die Attribute enthalten -> Überlegungen
    an Sicherheit: was passiert, wenn es das genannte Attribut nicht gibt?

Architektonische Überlegungen

"Komponentenbasierte Architektur" zur Definition von eigenen Gameobjekten:

• Game-Objekte können aus mehreren Komponenten zusammengesetzt werden (dabei ist diese Definition erstmal ein DSL-Datentyp, aus dem Instanzen im Spiel erstellt werden können)
• Komponenten geben dabei bestimmtes Verhalten vor:
  • Monster-Komponente -> Wegfindung zum Spieler und Angriff (evtl. mit verschiedenen Verhaltensweisen - konfigurierbar)
  • Container-Komponente -> Hat ein "Inventar", kann also Dinge speichern
  • Interactable-Komponente -> Player kann damit interagieren
• Raum kann definiert werden, mit enthaltenen Game-Objects
• Jede Komponente stellt über die DSL verschiedene Funktionen, Properties und
  Callback-Methoden zur Verfügung, über die die Komponente konfiguriert / manipuliert
  werden kann
• In DSL sollte es möglich sein, von der EventHandler-Methode einer Komponente eine
  Methode einer anderen Komponente aufzurufen
• Realisierung als EC-Framework

Mögliche Komponenten für Prototyp-Aufgabe

• Inventory
• AnimatedObject
• PasswordChecker
• Interactable
• "Letter"

Fragen / offene Punkte

• in welcher Reihenfolge werden Komponenten geupdated?
• ist die Kommunikation zwischen den Komponenten nötig und wenn ja, wie soll das
  realisiert werden? (gameObject.getComponent()?)
• Frage: Wie Questablauf realisieren?
  • Bewertung? -> Logging von allem?
  • Wie Quest-Statemachine realisieren bei Quests, die mehrere Stufen bis zur Vollendung haben?