Quest Editor Handbuch¶

Der Quest Editor verwaltet Java- und H5P-Aufgaben, Ziele, Hinweise, Belohnungen und Rich-Content. Er ist damit die wichtigste Autorinnen- und Autorenoberfläche für den eigentlichen Lerninhalt.

Zugriff¶

Editor mit ?editor öffnen
Tab Quest Editor wählen

Quest Editor

Der Screenshot zeigt eine geöffnete Beispielquest. Sichtbar sind:

links der rekursive Questbaum
oben die Aktionsleiste mit Preview, Test und Save
darunter die Quest-Tabs
in der Mitte das Formular mit Rich-HTML-Beschreibung

Organisation im Baum¶

Quests liegen rekursiv in Ordnern. Der Baum unterstützt:

neue Quest anlegen
Ordner anlegen
Verschieben per Drag and Drop
Umbenennen
Löschen
weltspezifische Bearbeitung

Der Dateipfad bestimmt zugleich die logische Gruppierung im Spiel. Saubere Ordnerstrukturen helfen also nicht nur im Editor, sondern später auch bei der Wahrnehmung der Inhalte.

Die wichtigsten Tabs¶

Allgemein¶

Im Allgemein-Tab werden die Kerndaten gepflegt:

id
title
shortDescription
voice
maxAttempts
taskFormat
description als HTML-Inhalt

Hier wird also festgelegt, wie die Aufgabe im Spiel erscheint, wie sie benannt ist und welcher Inhalt im eigentlichen Aufgabentext zu sehen sein soll.

Starter-Code¶

Quest Editor - Starter-Code

Nur bei Java-Quests vorhanden. Hier werden gepflegt:

eine oder mehrere Dateien
readOnly-Dateien
versteckte Hilfsdateien
optionale Zusatzdateien für den Spieler

Der Starter-Code ist didaktisch wichtig: Er kann Lernende gezielt führen, vorbereitete Klassen bereitstellen oder nur genau so viel Struktur vorgeben, wie für die Aufgabe nötig ist.

Lernziele¶

Quest Editor - Lernziele

Hier liegen die eigentlichen Objectives. Unterstützt werden unter anderem:

output
code_regex
structure
method_call
test_cases
variable_value
semantic_check
graphics_assert
java_error
retry_count
h5p_completed
h5p_interaction
h5p_statement

Die Lernziele sind der Kern der Auswertung. Hier wird festgelegt, woran das Spiel erkennt, ob eine Lösung fachlich und technisch korrekt ist.

Grafik-Objectives mit `graphics_assert`¶

graphics_assert ist für grafische Java-Aufgaben gedacht, also insbesondere:

World- und Actor-basierte 2D-Aufgaben
PApplet / Processing
einfache World3d-Szenen

Die Auswertung läuft gegen einen Laufzeit-Snapshot. Dieser wird erzeugt, wenn das Programm endet oder wenn das Grafikfenster manuell geschlossen wird. Dadurch lassen sich sowohl Spielzustände als auch echte Zeichenflächen prüfen.

Unterstützte Bereiche:

Grafikmodus: world2d, processing, world3d
Canvas-Größe
Klassenname und Objektanzahl
Java-Felder eines Runtime-Objekts
Textinhalt von Text-Objekten
Positionen x / y mit Toleranz
Sichtbarkeit, Acting-Status, Destroyed-Status, imageIndex
Pixel- und Farbprüfungen auf der Canvas
Farbregionen mit Mindest- oder Maximalanzahl passender Pixel

Typische Konfiguration für einen Spielzustand:

mode:world2d
class:FlattervogelMain
field:zustand
equals:playing

Typische Konfiguration für ein sichtbares Objekt:

mode:world2d
class:Vogel
count:1
x:100
y:200
tolerance:15
visible:true

Typische Konfiguration für eine reine Processing-Ausgabe:

mode:processing
width:800
height:600
pixelX:10
pixelY:10
pixelColor:#3c3c3c
regionX:40
regionY:240
regionWidth:320
regionHeight:120
containsColor:#ffffff
minMatches:200
colorTolerance:20

Praxisregel: Erst Zustände und Objektstruktur prüfen, dann erst Pixel. Zustandsprüfungen sind deutlich robuster. Pixel- oder Regionsprüfungen eignen sich vor allem für reine Zeichenaufgaben ohne gut auswertbare Java-Felder.

Hinweise¶

Quest Editor - Hinweise

Hinweise können:

ab einer bestimmten Fehlversuchszahl erscheinen
an Trigger-Objectives gebunden werden
HTML enthalten
sich auf bestimmte Dateien oder typische Fehler beziehen

Gute Hinweise lösen die Aufgabe nicht direkt, sondern stützen genau dort, wo typische Denk- oder Syntaxfehler auftreten.

Rewards¶

Quest Editor - Rewards

Hier werden Folgen einer Quest gepflegt, etwa:

onFinish
onFail
Journal-Freischaltungen
Variablen- und Geld-/XP-Belohnungen
Trigger weiterer Interaktionen

Dieser Tab verbindet die Aufgabe mit dem Rest des Spiels. Eine Quest ist dadurch nicht nur eine isolierte Programmierübung, sondern Teil von Fortschritt, Story und Weltlogik.

Java- und H5P-Quests¶

Java¶

Der Standardmodus für Programmieraufgaben mit IDE, Starter-Code und Objectives gegen Java-Code.

H5P¶

Im H5P-Modus wird statt Starter-Code ein H5P-Inhalt referenziert. Zusätzlich kann angegeben werden:

contentPath
optionale Bibliotheks-Override-Angabe

Die passenden Inhalte werden über den H5P Importer vorbereitet.

Quest Editor - H5P-Konfiguration

Im Allgemein-Tab erscheint für H5P-Quests ein zusätzlicher Konfigurationsblock. Dort wird festgelegt:

welches importierte H5P-Paket verwendet werden soll
unter welchem contentPath der Inhalt liegt
ob die Hauptbibliothek ausdrücklich überschrieben werden soll

H5P-Workflow Schritt für Schritt¶

H5P-Paket über den H5P Importer importieren.
Im Quest Editor das Quest Format auf H5P Content stellen.
Im Feld H5P Content Path den importierten Inhalt auswählen.
Nur bei Bedarf eine Bibliothek im Feld Main Library Override eintragen.
Danach die Objectives auf H5P-kompatible Typen prüfen.

Rich-Content in Questbeschreibungen¶

Die description unterstützt:

HTML
Codeblöcke mit Syntax-Highlighting
Tabellen
Mermaid-Diagramme
Mermaid-Objektdiagramme mit object-diagram
NSD-Struktogramme mit <nsd>

Beispiel: Mermaid in der Vorschau¶

Quest Preview mit Mermaid

Diese Vorschau zeigt:

ein Mermaid-Klassendiagramm
ein Mermaid-Objektdiagramm mit gerundeter Schulnotation
die gleiche Darstellung, die später auch im Spiel im Questtext erscheint

Beispiel: NSD in der Vorschau¶

Quest Preview mit NSD

Diese Vorschau zeigt:

eine echte Verzweigung im Struktogramm
eine Schleife
die Laufzeitdarstellung für Aufgaben- und Lerntexte

Mermaid und NSD sinnvoll einsetzen¶

Mermaid eignet sich besonders für:

Klassendiagramme
Objektdiagramme
einfache Beziehungsübersichten

NSD eignet sich besonders für:

lineare Abläufe
Verzweigungen
Schleifen
die Vorbereitung von Methodenlogik vor dem eigentlichen Java-Code

Gerade im Schulkontext ist die Kombination stark: Das Diagramm erklärt die Aufgabe, der Code setzt sie um.

NSD-Grundbausteine¶

Für Struktogramme stehen eigene Tags zur Verfügung:

<befehl> für einfache Anweisungsblöcke
<wenn> für Verzweigungen
<sonst> für den Else-Zweig einer Verzweigung
<schleife> für Wiederholungen

Ein einfaches Beispiel:

<nsd>
  <wenn bedingung="akku &lt; 20">
    <befehl>return "warnung";</befehl>
  </wenn>
  <sonst>
    <befehl>return "ok";</befehl>
  </sonst>
</nsd>

So lassen sich Aufgaben formulieren, bei denen Lernende erst den Algorithmus lesen und danach dieselbe Logik in Java umsetzen.

Weitere Syntaxbeispiele für Schleifen, verschachtelte NSD, Assoziationen in Klassendiagrammen, Programmablaufpläne und ER-Diagramme stehen in den Quest-Design-Konzepten.

Preview und Test¶

Zwei Buttons sind im Alltag besonders wichtig:

Preview: rendert die Beschreibung inklusive Mermaid und NSD so, wie sie später im Spiel erscheint
Test: führt die Questprüfungen direkt aus

Gerade bei Rich-Content sollte der Button Preview immer Teil des normalen Arbeitsablaufs sein.

Häufige Fehler¶

Das Questformat wird auf H5P Content gestellt, aber contentPath bleibt leer.
Es werden weiterhin Java-spezifische Lernziele erwartet, obwohl die Quest als H5P-Aufgabe gedacht ist.
Hinweise und Beschreibung werden nicht in der Vorschau geprüft und enthalten deshalb fehlerhafte HTML- oder Diagrammblöcke.
Der Starter-Code ist didaktisch zu umfangreich oder zu leer und führt die Lernenden dadurch entweder zu stark oder gar nicht.

Wo Quests gespeichert werden¶

Quests liegen unter:

public/data/worlds/<world>/quests/**/*.json

Empfehlung für Autorinnen und Autoren¶

Ein guter Quest-Workflow ist:

Titel, Kurztext und Voice setzen
Aufgabenbeschreibung schreiben
Starter-Code oder H5P-Inhalt festlegen
Objectives und Hints definieren
Rewards und onFinish setzen
Preview und Test durchlaufen

Gerade bei Grafikquests lohnt sich ein zusätzlicher Testlauf mit echter Ausführung: Fenster öffnen, Aufgabe bis zum relevanten Zustand bringen und erst dann schließen. Genau dieser Moment ist später auch die Basis für graphics_assert.