Quest-Design Konzepte¶

Quests sind die eigentlichen Lern- und Programmieraufgaben des Spiels. Sie können als Java-Quest oder als H5P-Quest angelegt werden.

Für die konkrete Bedienung des Editors ergänzt diese Konzeptseite das Quest Editor Handbuch. Für Trigger, Belohnungen und Folgeaktionen ist zusätzlich die Interaktionstypen-Referenz wichtig.

Grundaufbau einer Quest¶

Eine Quest besteht typischerweise aus:

Metadaten wie id, title, shortDescription
description mit Rich-Content
optionalem voice
starterCode oder h5pConfig
objectives
hints
onFinish und onFail

Zwei Aufgabenformate¶

Java¶

Der klassische Pfad mit Java-Editor, Startercode und Verifikation gegen Quelltext, Struktur oder Laufzeit.

H5P¶

Der alternative Pfad für eingebettete interaktive Inhalte. Hier wird statt Java-Code ein H5P-Paket referenziert und über H5P-spezifische Objectives ausgewertet.

Rich-Content in Beschreibungen¶

Questbeschreibungen unterstützen denselben Rich-Content-Stack wie Journale.

1. Normales HTML¶

Überschriften, Listen, Code, Tabellen und strukturierte Hinweise sind möglich.

2. Mermaid¶

Für Diagramme wie Klassendiagramme:

<div class="mermaid">
classDiagram
class Drohne {
  - name : String
  - energie : int
  + status() : String
}
</div>

Assoziationen in Klassendiagrammen¶

<div class="mermaid">
classDiagram
class Lehrkraft {
  - name : String
}
class Kurs {
  - fach : String
}
class Lernende {
  - name : String
}

Lehrkraft "1" --> "0..*" Kurs : unterrichtet
Kurs "1" --> "0..*" Lernende : enthält
</div>

Damit lassen sich gerichtete Beziehungen, Rollen und Multiplizitäten direkt im Klassendiagramm ausdrücken.

Programmablaufplan mit Mermaid¶

Für einen Programmablaufplan wird in Mermaid der Typ flowchart verwendet:

<div class="mermaid">
flowchart TD
  A([Start]) --> B[/Eingabe: temperatur/]
  B --> C{temperatur < 0?}
  C -- ja --> D[Ausgabe: "Frost"]
  C -- nein --> E{temperatur < 20?}
  E -- ja --> F[Ausgabe: "Kühl"]
  E -- nein --> G[Ausgabe: "Warm"]
  D --> H([Ende])
  F --> H
  G --> H
</div>

ER-Diagramm in Chen-Notation mit Kardinalitäten¶

Auch ein ER-Diagramm in Chen-Notation lässt sich mit Mermaid über flowchart annähern. Rechtecke stehen für Entitäten, Rauten für Beziehungen und Kreise für Attribute. Kardinalitäten werden als Kantenbeschriftungen notiert.

<div class="mermaid">
flowchart LR
  STUDENT[Student]
  KURS[Kurs]
  BELEGT{belegt}
  MATRIKELNUMMER((Matrikelnummer))
  STUDENTENNAME((Name))
  KURSTITEL((Titel))

  STUDENT -- "(1,1)" --> BELEGT
  BELEGT -- "(0,n)" --> KURS
  STUDENT --- MATRIKELNUMMER
  STUDENT --- STUDENTENNAME
  KURS --- KURSTITEL
</div>

Das ist keine perfekte native Chen-Engine, aber für Unterrichtsmaterial und erklärende Diagramme im Spiel meist ausreichend.

3. Mermaid-Objektdiagramm¶

Für Schulnotation mit abgerundetem Außenrahmen:

<div class="mermaid object-diagram">
classDiagram
class `ultra5k : Drohne` {
  name = "Ultra 5k"
  energie = 90
}
</div>

4. NSD¶

Für Struktogramme:

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

Schleife im Struktogramm¶

<nsd>
  <schleife text="solange akku &lt; 100">
    <befehl>akku = akku + 10;</befehl>
  </schleife>
</nsd>

Komplexeres, verschachteltes NSD¶

<nsd>
  <schleife text="solange index &lt; werte.length">
    <wenn bedingung="werte[index] % 2 == 0">
      <befehl>summe = summe + werte[index];</befehl>
    </wenn>
    <sonst>
      <wenn bedingung="werte[index] &gt; 100">
        <befehl>break;</befehl>
      </wenn>
      <sonst>
        <befehl>index = index + 1;</befehl>
      </sonst>
    </sonst>
    <befehl>index = index + 1;</befehl>
  </schleife>
</nsd>

Damit lassen sich auch anspruchsvollere Abläufe mit Schleifen, Verzweigungen und Abbruchbedingungen vor dem eigentlichen Java-Code visualisieren.

Objectives¶

Objectives bilden die eigentliche Auswertung einer Quest. Typische Muster:

Konsolenausgabe prüfen
Quelltext auf Muster prüfen
Klassen, Attribute und Methoden prüfen
Methoden mit Testwerten aufrufen
mehrere Testfälle definieren
grafische Laufzeitzustände prüfen
Canvas-Pixel oder Farbregionen prüfen
H5P-Abschlüsse oder Einzelaktionen prüfen

Grafikaufgaben gestalten¶

Für grafische Aufgaben ist graphics_assert der passende Objective-Typ. Er deckt zwei Ebenen ab:

Zustandsebene: Welche Objekte existieren, welche Felder haben welche Werte, welche Positionen sind erreicht?
Zeichenebene: Welche Farben oder Pixel sind wirklich auf der Canvas sichtbar?

Die sinnvolle Reihenfolge ist fast immer:

erst Klassen, Felder, Objektanzahl und Positionen prüfen
Pixel oder Farbregionen nur ergänzend einsetzen

Das ist robuster und didaktisch sauberer. Ein Feld wie zustand:playing ist stabiler als eine einzelne Pixelprobe. Pixelprüfungen braucht man vor allem bei reinen Zeichenaufgaben, in denen das sichtbare Ergebnis selbst bewertet werden soll.

Gute Muster für World-/Actor-Aufgaben¶

Hauptzustand des Controllers prüfen, zum Beispiel field:zustand equals:playing
zentrale Objekte zählen, zum Beispiel class:Vogel count:1
Position und Sichtbarkeit prüfen
Punktestand oder Spielphase über Felder absichern

Gute Muster für Processing-Aufgaben¶

zuerst mode, width und height festlegen
Hintergrundfarbe über einzelne Pixel prüfen
sichtbare Elemente über Regionen mit containsColor und minMatches prüfen
colorTolerance einplanen, damit leichte Renderabweichungen nicht sofort scheitern

Ein solides Processing-Beispiel prüft nicht nur einen einzelnen weißen Pixel für Text, sondern eine ganze Region, in der genügend helle Pixel auftauchen müssen.

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

Gute Spielerführung bei Grafikquests¶

sichtbare Objective-Beschreibung menschlich formulieren
technische Details in graphics_assert verstecken
Hinweise an typische Fehlbilder koppeln
klar sagen, dass das Grafikfenster im Zielzustand geschlossen werden soll, damit genau dieser Zustand geprüft wird

Hints¶

Hints sind ein wichtiges didaktisches Werkzeug. Gute Hints:

greifen einen typischen Fehler auf
werden nicht zu früh freigeschaltet
verweisen konkret auf Struktur oder Idee, nicht auf komplette Lösungen

Belohnungen und Folgen¶

Eine Quest kann beim Abschluss:

Journal-Einträge freischalten
Variablen oder Geld/XP verändern
Switches setzen
weitere Interaktionen anstoßen
Erfolge vergeben

Gute Questgestaltung¶

Für das Projekt funktioniert besonders gut:

kurze, klare Einleitung
visuelle Unterstützung über Diagramm oder NSD
klare Ziele
einzelne, gut gestufte Hints
realistische Belohnungen oder Story-Fortschritte

Speicherort¶

Quests liegen pro Welt unter:

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