Game Design im Unterricht: Ein praktischer Leitfaden fur Lehrkrafte (2026)

Wer nach "Game Design im Unterricht" sucht, findet meist entweder glanzende Werbung fur bezahlte Plattformen oder abstrakte Listen mit Kompetenzen des 21. Jahrhunderts. Beides beantwortet nicht, was man wirklich wissen muss: Wie setzt man das mit dreissig Schulern um, mit einem festen Stundenplan, gemischten Kenntnisständen und Technik, uber die man keine Kontrolle hat.

Dieser Leitfaden ist die praktische Version. Warum Game Design seinen Platz in einem echten Unterricht verdient, was man in welcher Reihenfolge unterrichtet, ein Unterrichtsplan zum Anpassen, faire Bewertungsansatze und ein ehrlicher Blick auf die Tools, einschliesslich der Frage, wo KI-native Engines passen und wo nicht. Er ist fur Lehrkrafte geschrieben, die das am Montag umsetzen mussen, nicht fur einen Konferenzvortrag.

{/* IMAGE: Hero. A classroom whiteboard with a hand-drawn game loop diagram (player action, rule, feedback, goal) next to a laptop showing a simple platformer running. 1200x630, warm and real, no stock-photo gloss. */}

Warum Game Design in den Unterricht gehort

Game Design ist eines der wenigen Facher, in denen Schuler viele Fahigkeiten gleichzeitig auf ein selbst gewahltes Ziel anwenden. Um auch nur ein winziges Spiel zum Funktionieren zu bringen, muss ein Schuler ein klares Ziel formulieren, eindeutige Regeln schreiben, vorhersagen, wie sich ein Spieler verhalt, Annahmen testen und reparieren, was nicht funktioniert. Das ist Systemdenken, Logik, Schreiben und iteratives Arbeiten in einer einzigen Aufgabe, und das geschieht, weil der Schuler will, dass das Spiel Spass macht, nicht weil ein Arbeitsblatt es verlangt.

Die Motivation ist das eigentliche Argument. Ein Programmierarbeitsblatt fordert einen Schuler auf, das Problem eines anderen zu losen. Ein Spiel fordert ihn auf, sein eigenes zu losen. Wenn der Spieler das Level nicht schafft, ist das keine Note, sondern ein Problem, das der Schuler spurt und beheben will. Dieses Gefuhl von Eigenverantwortung lasst sich in den meisten Fachern kaum kunstlich erzeugen, und Game Design liefert es von selbst.

Es passt auch in mehr Lehrplane, als man erwartet. Der Core Loop ist Logik und Ursache-Wirkungs-Denken. Schwierigkeitsgrade zu balancieren ist echte Mathematik: Raten, Wahrscheinlichkeiten, Zahlen anpassen, bis sich ein System richtig anfuhlt. Die Texte und Ziele des Spiels sind Aufsatz, das Erscheinungsbild ist bildende Kunst. Eine Game-Design-Einheit ist keine Pause vom akademischen Lernen. Sie ist ein Ort, an dem mehrere akademische Fahigkeiten gleichzeitig und mit echtem Einsatz angewendet werden.

Was "Game Design" hier bedeutet und was nicht

Eine Unterscheidung verhindert viel Verwirrung. Game Design bedeutet zu entscheiden, was das Spiel ist: das Ziel, die Kernaction, die ein Spieler wiederholt, die Regeln, wie das Spiel mit dem Spieler kommuniziert, und die Schwierigkeitskurve. Das alles lasst sich mit Papier und Stift erledigen, und manche der besten Lernmomente entstehen, bevor jemand einen Computer anruhrt. Game Programming bedeutet, dieses Design in Software umzusetzen, was die technische Einstiegshurde ist, vor der Lehrkrafte oft zuruckschrecken, obwohl diese Hurde 2026 erheblich gesunken ist. Spiele spielen ist Recherche, in kleinen Dosen nutzlich, wenn Schuler analysieren, warum ein Spiel, das sie lieben, funktioniert, aber eine Klasse, die nur spielt, lernt kein Design.

Halt man diese drei auseinander, wird die Einheit viel einfacher zu planen. Man unterrichtet zuerst Design, auf Papier, geht dann zum Bauen uber, und das gewahlte Tool entscheidet, wie viel Programmieraufwand die Schuler bewaltigen mussen.

Die funf Konzepte, die eine Game-Design-Einheit vermitteln sollte

Dem Drang widerstehen, mit Kunst- und Storytheorie zu beginnen. Das lernen Schuler am schnellsten, sobald sie ein funktionierendes Spiel haben, das genau das benotigt. Diese funf Konzepte unterrichtet man in dieser Reihenfolge, jeweils verankert an einem Projekt, das Schuler ausprobieren und testen konnen.

1. Der Core Loop. Was macht der Spieler immer wieder? Springen und sammeln. Zielen und schiessen. Pflanzen und ernten. Wenn ein Schuler seinen Core Loop nicht in einem Satz nennen kann, existiert das Spiel noch nicht. Das ist das wichtigste einzelne Konzept, und die meisten Anfanger uberspringen es.

2. Ziele und Gewinn- oder Verlustbedingungen. Was versucht der Spieler zu tun, und wie gewinnt oder verliert er? Ein Spiel ohne klares Ziel ist ein Spielzeug, kein Spiel. Schuler sollen die Gewinnbedingung und die Verlustbedingung als explizite Regeln aufschreiben.

3. Feedback. Wie teilt das Spiel dem Spieler mit, was passiert? Ein Munzton, eine steigende Punktzahl, ein Aufleuchten beim Treffer. Anfanger bauen Spiele, bei denen der Spieler nicht erkennt, ob er etwas richtig gemacht hat. Feedback zu unterrichten behebt den haufigsten Grund, warum sich ein Schulerspiel kaputt anfuhlt.

4. Balance und Schwierigkeitsgrad. Ist es zu leicht, zu schwer, oder steigt die Schwierigkeit im richtigen Tempo? Hier wird Mathematik zum Design. Schuler passen Zahlen an (Gegnergeschwindigkeit, Spawnrate, Sprunghone) und spuren die Wirkung sofort. Das ist die naturlichste Mathestunde der Einheit.

5. Iteration durch Playtesting. Jemandem zusehen, wie er das eigene Spiel spielt, ohne einzugreifen. Notieren, wo er verwirrt ist oder steckt. Eine Sache andern. Erneut testen. Das ist der Motor echten Designs, und es ist auch die wertvollste Gewohnheit, die Schuler mitnehmen, weil sie weit uber Spiele hinaus gilt.

Auffallend: Kunst und Story stehen hier nicht als eigene Lektionen. Sie tauchen innerhalb dieser funf Konzepte auf, wenn ein Schuler ein klareres Ziel, besseres Feedback oder einen Grund braucht, warum das Gewinnen wichtig ist. Man unterrichtet sie auf Anfrage, nicht als vorab geladene Theorie.

Ein Unterrichtsplan zum Anpassen

Hier ist eine Drei-bis-Sechs-Wochen-Struktur. Auf eine einzige Woche komprimieren lasst sie sich, indem man ein Projekt pro Schuler anpeilt und die zweite Iteration weglasst. Die wichtigste Regel: In Woche eins ein spielbares Spiel erreichen, damit Schuler den Grossteil der Einheit damit verbringen, etwas Echtes zu verbessern, anstatt ein Spiel zu planen, das sie nie bauen.

Woche 1: Design auf Papier, dann ein erster kleiner Build. Mit Computern beginnt man nicht. Jeder Schuler entwirft ein einseitiges Spiel: den Core Loop, das Ziel, die Gewinn- und Verlustbedingungen, in normaler Sprache. Dann fuhrt man einen Papier-Playtest durch, bei dem Schuler gegenseitig die Spiele mit Spielsteinen und Wurfeln spielen. In der zweiten Sitzung wechselt man zu einem Tool und jeder Schuler baut die kleinstmogliche spielbare Version. Das Ziel: ein laufendes Spiel bis Ende der ersten Woche, egal wie roh.

Woche 2: Feedback und Verstandlichkeit. Schuler fugen ihren Spielen die fehlende Kommunikation hinzu: Sounds, Punkte, sichtbare Gesundheit, ein klares Signal, wenn der Spieler gewinnt oder verliert. Die Lektion: Ein Spiel ist nicht fertig, wenn es funktioniert, sondern wenn ein neuer Spieler es ohne Erklarung verstehen kann.

Woche 3: Balance. Schuler playtesten mit einem Klassenkameraden, der das Spiel noch nie gesehen hat, und passen dann die Zahlen an. Das ist die mathematikintensive Woche. Schwierigkeitskurven, Spawnraten und Geschwindigkeiten werden zu Stellschrauben, die der Schuler dreht und misst.

Wochen 4 bis 6 (optional): Iterieren oder ein zweites Spiel bauen. Mit dem Grundwissen konnen Schuler entweder ihr erstes Spiel um eine neue Mechanik vertiefen oder ein zweites, ambitionierteres bauen. Wer die Zeit hat, lernt hier durch ein kleines Zweier-Teamprojekt Zusammenarbeit und Umfangplanung, was eine eigene wichtige Lektion ist: Schuler wollen immer zu viel bauen.

Der rote Faden durch die gesamte Einheit ist das Playtesting. Jede Sitzung endet damit, dass jemand das Spiel eines anderen spielt und der Designer still Notizen macht. Allein diese Gewohnheit verbessert die Qualitat der Schulerarbeiten mehr als jede Vorlesung.

Die Tools, ehrlich verglichen fur den Klassenraum

Das richtige Tool hangt vom Alter der Schuler, der verfugbaren Zeit und der verlasslichen Ausstattung ab. Hier ist die ehrliche Version.

Papier und Stift. Kostenlos, fur jedes Alter geeignet, kein Equipment notig, und wirklich der beste Weg, die Kernkonzepte zu vermitteln. Unterschatzt. Jede Einheit sollte hier beginnen, auch mit alteren Schulern. Die Grenze ist offensichtlich: Schuler wollen ihr Spiel irgendwann auf einem Bildschirm sehen.

Scratch. Kostenlos, browserbasiert, keine Installation, und fur Kinder von etwa 8 bis 14 Jahren entwickelt. Drag-and-Drop-Blocke bedeuten keine Syntaxkampfe. Das ist aus gutem Grund der Standard. Die Decke liegt darin, dass Scratch eine Lernsandbox ist, keine echte Engine, weshalb motivierte oder altere Schuler schnell herauswachsen und die Spiele klein und Scratch-typisch bleiben. Mehr dazu, wo Lerntools an ihre Grenzen stossen, findet man im Leitfaden zu Programmierspielen fur Schuler.

Traditionelle Game Engines (Godot, Unity, Unreal). Das sind die echten Werkzeuge, mit denen Schuler ein vollstandiges Spiel liefern konnen, aber bei einem festen Stundenplan konnen Setup, Installation und Syntaxkurve die ersten Wochen auffressen, bevor ein Schuler uberhaupt etwas Spielbares sieht. Leistungsfahig und das richtige Ziel fur eine ernsthafte altere Klasse, aber schwer fur eine kurze Einheit.

KI-native Engines. Das ist die neueste Option, und sie verandert die Kalkulation fur einen Klassenraum. Mit Summer Engine beschreibt ein Schuler das Spiel in normaler Sprache, zum Beispiel "Erstelle ein Plattformspiel, bei dem der Spieler Munzen sammelt und Stacheln ausweicht", und die KI schreibt echten Code in einer echten Engine, platziert die Objekte und fuhrt das Spiel in Sekunden aus. Da es mit Godot 4, einer professionellen Open-Source-Engine, kompatibel ist, ist das keine Spielzeugsandbox. Der Mehrwert fur den Klassenraum ist konkret: Die Setup- und Syntaxhurde, die den ersten spielbaren Build normalerweise verzogert, entfallt, sodass Schuler schneller zur Iteration kommen. Sie konnen den echten Code lesen und verandern, den die KI schreibt, was es nicht zur Black Box macht. Das Designdenken bleibt bestehen. Der Schuler muss immer noch entscheiden, was das Spiel ist, und genau das bewertet man.

Eine praktische Entscheidungshilfe: Man wahlt das Tool mit der geringsten Reibung, das Schulern dennoch ermoglicht, in der verfugbaren Zeit ein spielbares Ergebnis zu erreichen. Fur die jungsten Schuler oder eine Einwochenwoche sind das Papier plus Scratch. Fur altere Schuler, die wirklich etwas fertigstellen wollen, ist eine KI-native oder eine traditionelle Engine das richtige Ziel, wobei die KI-native Option deutlich schneller zu einem laufenden Spiel fuhrt.

Wer Schuler moglichst schnell echte digitale Spiele bauen lassen will, findet in einfachen Genres mit klarem Core Loop einen guten Ausgangspunkt. Das 2D-Platformer-Template und das Puzzle-Template haben beide ein Ziel und einen Loop, uber den Schuler nachdenken konnen, ohne sich zu verlieren, was sie zu guten Erstprojekten macht.

Wie man ein Game-Design-Projekt bewertet

Der Fehler ist, den Schliff zu bewerten, was Schuler mit weniger Kunst- oder Programmierhintergrund benachteiligt und diejenigen belohnt, die bereits Vorkenntnisse mitbrachten. Man bewertet stattdessen das Denken. Das Bewertungsraster baut auf vier Punkten auf:

• Designentscheidungen. Gibt es einen klaren Core Loop, ein Ziel und Gewinn- oder Verlustbedingungen? Kann der Schuler diese jeweils in einem Satz formulieren?
• Iteration. Was hat der Schuler nach dem Playtesting verandert, und warum? Das ist der Kern der Bewertung. Ein raueres Spiel mit klarer, begrundeter Iteration schlagt ein poliertes Spiel, das der Schuler nicht erklaren kann.
• Verstandlichkeit und Feedback. Kann ein neuer Spieler das Spiel aufnehmen und ohne Hilfe verstehen? Das belohnt die Kommunikationsfahigkeiten, die am meisten zahlen.
• Reflexion. Kann der Schuler seine Entscheidungen erklaren und sagen, was er als Nachstes tun wurde?

Der beste Beweis ist nicht das fertige Spiel allein. Man bittet um ein kurzes Designdokument (der einseitige Plan aus Woche eins, aktualisiert) und einen aufgezeichneten oder beobachteten Playtest. Die zeigen den Prozess, den man eigentlich unterrichtet, und machen die Bewertung bei sehr unterschiedlichen fertigen Spielen fair.

Ehrliche Kosten: Was eine Einheit tatsachlich bezahlt werden muss

Eine vollstandige Game-Design-Einheit kann mit kostenlosen Tools laufen. Papier kostet nichts. Scratch, der Hour of Code und Blockly Games sind kostenlos. Fur das Bauen echter digitaler Spiele ist Summer Engine kostenlos nutzbar, und der kostenlose Tarif deckt das Erstellen und Exportieren eines kleinen Spiels einschliesslich des KI-generierten Codes ab, was fur ein Klassenprojekt ausreicht und sogar ermoglicht, das Ergebnis zu teilen.

Die bezahlten Plane bieten mehr KI-Nutzung und Zugang zu leistungsstarkeren Modellen. Das beginnt relevant zu werden, wenn Schuler fast taglich bauen oder eine Nachmittags-AG mehrmals wochentlich mit denselben Accounts arbeitet, nicht fur eine wochentliche Unterrichtseinheit. Nichts davon ist erforderlich, um die Kernfahigkeiten zu vermitteln oder jeden Schuler zu einem fertigen ersten Spiel zu bringen. Entscheidend ist, wie oft Schuler tatsachlich bauen werden, nicht eine Featureliste.

Wo man diese Woche anfangt

Wenn man eine einzige Erkenntnis aus diesem Leitfaden mitnimmt: In der ersten Sitzung ein spielbares Spiel vor die Schuler bringen, dann den Rest der Einheit damit verbringen, es durch Playtesting zu verbessern. Mit Papier beginnen, um Core Loop, Ziel und Feedback ohne technische Reibung zu vermitteln. Dann das Tool mit der geringsten Reibung wahlen, das noch zu einem echten Ergebnis fuhrt.

Fur die Bauphase mit alteren Schulern verringert eine KI-native Engine den Setup-Aufwand, der diesen ersten spielbaren Moment normalerweise verzogert. Man kann Summer Engine kostenlos ausprobieren und in einer einzigen Unterrichtsstunde ein echtes Spiel aus einer schlichten Beschreibung bauen lassen, um dann gemeinsam den echten Code als das Designgespräch zu lesen, das es ist. Fur jungere Schuler oder eine Einwochenversion tragt Papier plus Scratch die gesamte Einheit.

Welche Tools auch immer man nutzt: Die Lektion ist die, nach der ein professioneller Designer lebt. Ein Spiel ist nie beim ersten Mal richtig, und die Arbeit besteht darin, jemandem beim Spielen zuzuschauen, zu sehen, was ihn verwirrt hat, eine Sache zu andern und es erneut zu versuchen.