Lernspiele bauen: Leitfaden und Framework

Warum Spiele in Blogposts

Ein Satz wie „Komplimente sind keine Daten“ liest sich in zwei Sekunden und ist in zehn vergessen. Wenn man aber selbst ein Kundengespräch führt, sich über das „Klingt super!“ freut und dann sieht, dass der Notizblock leer ist, bleibt es hängen. Das Spiel liefert das Erlebnis, der Text danach die Erklärung.

Inzwischen haben wir mehr als ein halbes Dutzend solcher Spiele gebaut:

• Kompliment oder Wahrheit: ein Kundengespräch
• Rocket Surgery: einen Usability-Test moderieren
• Drei Hüte: eine Gründerwoche verteilen
• Traction: Sitze besetzen und Quartalsziele wählen
• Feature-Fabrik: acht Sprints planen
• Belohn den Roboter: Regeln für einen Putzroboter schreiben
• Sechs Kästen: einen Businessplan auf einer Seite bauen
• Blockchain: eine Kette zum Anfassen

Dabei haben sich Regeln herausgebildet. Die schreiben wir hier auf, für uns und für alle, die so etwas selbst bauen wollen.

Acht Prinzipien

1. Eine Pointe

Jedes Spiel beweist genau einen Satz. Nicht das ganze Buch, nicht drei Kapitel. Beim Mom Test ist es „Komplimente sind keine Daten“, beim Alignment-Spiel „Was du misst, ist nicht, was du willst“. Wer die Pointe nicht in einem Satz sagen kann, hat noch kein Spiel, sondern nur Interaktion.

2. Verführerisch falsche Antworten

Die falschen Optionen sind die Fehler, die man selbst machen würde, am besten direkt aus der Quelle. Offensichtlich dumme Antworten wählt niemand, also lernt auch niemand etwas. Ein guter Test: Würde jemand im Team die falsche Antwort im echten Leben geben? Dann gehört sie rein.

3. Zwei Messungen

Unser stärkstes Muster: eine Leiste für das, was sich gut anfühlt, und eine für das, was wirklich stimmt. Komplimente gegen Fakten. Punkte für den Roboter gegen dein eigentliches Ziel. Die Lücke zwischen beiden Leisten ist die Lektion. Optisch ist die gefühlte Leiste gestrichelt und die echte voll.

4. Erst die Folge, dann das Warum

Nach jeder Wahl zeigt das Spiel, was passiert: Mara sagt etwas, der Roboter kippt den Beutel aus, ein Kasten bricht. Danach folgt ein Satz, warum. Kein Richtig-falsch-Stempel ohne Grund, keine Erklärung vor der Erfahrung.

5. Kurz

4 bis 6 Runden, 3 Optionen pro Runde, 2 bis 3 Minuten. Die Reihenfolge der Optionen ist zufällig, damit die richtige nicht immer an derselben Stelle steht. Wer mehr will, drückt „Nochmal“.

6. Die Auswertung zeigt zurück

Am Ende stehen eine große Zahl, ein ehrlicher Satz und drei Lehren, die genau den Abschnitten im Text entsprechen. Das Spiel ist der Einstieg in den Artikel, nicht sein Ersatz.

7. Ehrlich bleiben

Erfundene Figuren und Zahlen sind als erfunden gekennzeichnet, direkt im Spiel und noch einmal in den FAQ. Echte Beispiele wie das CoastRunners-Boot bekommen eine Quelle.

8. Für alle spielbar

Echte <button>-Elemente, also Maus, Touch und Tastatur. Die Tasten 1 bis 3 wählen eine Option. Ergebnisse stehen zusätzlich in einer aria-live-Region. Nach jeder Wahl springt der Fokus auf „Weiter“. Wer reduzierte Bewegung eingestellt hat, bekommt keine Animationen. Auf dem Handy wird aus zwei Spalten eine.

Das Framework

Die Bauteile eines Spiels

Vier Spieltypen

Das Code-Gerüst

Alle Spiele sind Vanilla JavaScript in derselben HTML-Datei wie der Artikel, ohne Bibliothek und ohne Build. Inhalt und Logik sind getrennt: Die Runden stehen als Daten in einem Array, die Logik ist eine kleine Zustandsmaschine mit vier Funktionen.

const ROUNDS = [
  { intro: "Situation in einem Satz", opts: [
    { q: "Option", good: true,  tag: "Etikett",
      a: "Was passiert", why: "Ein Satz warum",
      feel: 1, real: 2, note: "Lehre für das Protokoll" },
    // zwei verführerisch falsche Optionen
  ]},
];

let r = 0, feel = 0, real = 0;

function show() {            // Runde aufbauen
  // Intro setzen, Optionen mischen, Buttons mit <kbd>1–3</kbd>
}
function pick(o) {           // Folge zeigen
  // feel/real addieren, Etikett + a + why in aria-live,
  // Leisten und Protokoll aktualisieren, Fokus auf „Weiter“
}
function end() {             // Auswertung
  // große Zahl, Urteil, drei Lehren, „Nochmal“
}
function reset() { r = feel = real = 0; show(); }

// Tasten 1–3 nur, wenn das Spiel im Bild ist
document.addEventListener("keydown", e => { /* … */ });
show();

Ein paar Regeln im Code, die sich bewährt haben:

• Texte mit textContent setzen, nicht mit innerHTML. Dann kann kein Text das Layout zerschießen.
• Animationen abbrechbar machen. Jede Animation bekommt eine Lauf-Nummer. Startet ein neuer Lauf, hört der alte auf.
• Bewegung aus, wenn gewünscht: matchMedia('(prefers-reduced-motion: reduce)') setzt die Schrittzeit auf 0.
• CSS-Spezifität beachten. Ein allgemeiner Button-Stil wie .g-q button überschreibt sonst den „Weiter“-Button. Gebaut haben wir den Fehler auch schon.
• Stil teilen, nicht kopieren. Alle Spiele nutzen dieselben Tokens: Schwarz, Weiß, gestrichelt für Gefühl, voll für Wahrheit.

Leitfaden: von der Idee bis online

1. Pointe in einem Satz aufschreiben. Wenn das nicht geht: erst das Buch weiterlesen.
2. Spieltyp wählen aus der Tabelle oben.
3. Fehler sammeln. Aus der Quelle die drei bis sechs typischen Fehler herausschreiben. Das sind die falschen Antworten.
4. Messungen festlegen. Was fühlt sich gut an? Was stimmt wirklich? Beides als Zahl von 0 bis 2 pro Option.
5. Runden als Daten schreiben, zuerst in einem Textdokument. Jede Option braucht Folge, Etikett und einen Satz Warum.
6. Gerüst einsetzen und die Daten einfügen. Stil aus einem bestehenden Post übernehmen.
7. Titelbild zeichnen: eine cover.svg mit weißen Linien auf Schwarz, die die Pointe zeigt. Daraus das Vorschaubild rendern:

   google-chrome --headless=new --hide-scrollbars \
     --window-size=1200,630 \
     --screenshot=og.png cover.svg

8. Artikel schreiben: Warum gelesen, was der Autor sagt, was wir daraus machen, wie das Spiel funktioniert, FAQ, englische Kurzfassung.
9. Registrieren: Eintrag in der News-Liste, in der Sitemap und in llms.txt.
10. Testen mit der Checkliste unten, dann veröffentlichen.

Checkliste vor dem Veröffentlichen

• Einmal mit nur richtigen und einmal mit nur falschen Antworten durchgespielt
• Ganz ohne Maus spielbar: Tab, Enter, Tasten 1 bis 3
• Auf 390 px Breite kein seitliches Scrollen
• Mit reduzierter Bewegung getestet
• Erfundene Figuren und Zahlen sind gekennzeichnet
• Jede Lehre in der Auswertung hat einen Abschnitt im Text
• Vorschaubild 1200 × 630, Titel, Beschreibung und strukturierte Daten gesetzt
• News-Liste, Sitemap und llms.txt ergänzt

Ein Spiel, das man nicht in einem Satz zusammenfassen kann, ist Deko.

Du willst so etwas für dein Thema, deine Schulung oder deine Website? Schreib uns. Wir bauen Lernspiele, interaktive Erklärseiten und Installationen.

Building learning games, in short

Most of our book posts start with a small game: experience first, explanation second. Our rules: one point per game, tempting wrong answers taken from the source, two meters (what feels good vs. what is actually true), consequence before explanation, 4–6 rounds, an ending that points back into the article, honest labelling of fictional content, and full keyboard and screen reader support. Technically each game is plain JavaScript with rounds as data and a small state machine (show, pick, end, reset). This post includes the code skeleton, a step-by-step guide and a pre-publish checklist.