Kursvorlage

Frogger komplett: Von Szene bis Polish

Lerne frameCraft mit Frogger: Bewegung, Kollisionen, HUD, Neustartlogik und grafischer Gestaltung – Schritt für Schritt als vollständige Unterrichtsvorlage.

Kategorie: frameCraft Sprache: Python 2 Bausteine: 12 Thema: pygame / Game-DSL

Vorlage kostenfrei testen Fertiges Spiel ansehen Mehr zu frameCraft Spiel-Zwischenstand herunterladen (ZIP)

Begleitmaterial inklusive: Unterrichtsfolien als PowerPoint und Handout für Lehrkräfte.

Vom einfachen Spiel zur modellierten, datengetriebenen Anwendung

Frogger eignet sich hervorragend, um im Informatikunterricht den Schritt von einfachen Bewegungsregeln hin zu einer strukturierten, datengetriebenen Anwendung zu vollziehen. frameCraft sorgt dafür, dass zentrale Spielmechaniken schnell sichtbar werden, während die eigentliche Logik weiterhin in normalem Python formuliert wird. Schülerinnen und Schüler arbeiten damit nicht an isolierten Syntaxübungen, sondern an einem System, dessen Verhalten sie unmittelbar beobachten können. Jede Änderung an Variablen, Schleifen, Bedingungen oder Datenstrukturen hat eine erkennbare Wirkung im Spiel und bietet damit eine gute Grundlage für hypothesengeleitetes Experimentieren und Debugging.

if Zugriff.aktion_neu(ctx, "hoch"):
    frog_ent.y -= schritt
elif Zugriff.aktion_neu(ctx, "runter"):
    frog_ent.y += schritt
elif Zugriff.aktion_neu(ctx, "links"):
    frog_ent.x -= schritt
elif Zugriff.aktion_neu(ctx, "rechts"):
    frog_ent.x += schritt

Die Bewegung des Frosches ist bewusst rasterbasiert aufgebaut. Statt einer kontinuierlichen Geschwindigkeit verändert jeder neue Tastendruck die Position um einen definierten Schritt. Dadurch werden Koordinatensystem, Zustandsänderungen und bedingte Verzweigungen sehr übersichtlich sichtbar. Gleichzeitig lernen die Schülerinnen und Schüler die wichtige Unterscheidung zwischen einer dauerhaft gedrückten Taste und einem neu ausgelösten Eingabeereignis kennen: aktion_neu führt genau einen Schritt aus. Gerade für den Einstieg ist das didaktisch günstig, weil Ursache und Wirkung klar voneinander abgegrenzt bleiben.

lane_data = [
    (160, 88,  (200, 45, 45)),
    (130, -75, (210, 140, 25)),
    (68,  105, (40, 100, 210)),
    (35,  -65, (155, 40, 195)),
]

for lane_index, (lane_y, vel_x, body_color) in enumerate(lane_data):
    create_cars_for_lane(
        ctx,
        lane_index,
        lane_y,
        vel_x,
        body_color,
        window_width
    )

Besonders interessant für den Informatikunterricht ist die datengetriebene Erzeugung der Fahrspuren. Position, Geschwindigkeit und Farbe einer Spur werden nicht mehrfach in fast identischem Code festgeschrieben, sondern als Daten beschrieben. Eine Schleife interpretiert diese Daten anschließend und erzeugt daraus die Spielobjekte. Damit wird ein grundlegendes Prinzip moderner Softwareentwicklung sichtbar: Daten und Verarbeitung können voneinander getrennt werden. Änderungen am Level erfolgen dadurch an einer kompakten Datenstruktur, ohne die eigentliche Erzeugungslogik umzuschreiben. Für weiterführende Aufgaben lassen sich zusätzliche Spuren, unterschiedliche Fahrzeugzahlen oder weitere Eigenschaften ergänzen.

for lane_index in range(4):
    for index in range(NUM_AUTOS):
        car_ent = Zugriff.figur(
            ctx,
            "auto_" + str(lane_index) + "_" + str(index)
        )

        car_ent.x += car_ent.vx * ctx.dt

Die Autos verbinden verschachtelte Schleifen mit zeitbasierter Bewegung. Während die beiden Indizes die Fahrzeuggruppen systematisch adressieren, sorgt ctx.dt dafür, dass Geschwindigkeit tatsächlich als Strecke pro Zeit verstanden werden kann und nicht als willkürliche Anzahl von Pixeln pro Bild. So entsteht eine natürliche Brücke zwischen Informatik und mathematisch-physikalischer Modellierung. Lernende können beispielsweise Geschwindigkeiten vergleichen, unterschiedliche Fahrtrichtungen untersuchen oder erklären, warum dieselbe Bewegung auch bei veränderter Bildrate stabil bleiben soll.

if car_ent.vx > 0 and car_ent.x > window_width + AUTO_WIDTH:
    car_ent.x = -AUTO_WIDTH

elif car_ent.vx < 0 and car_ent.x < -AUTO_WIDTH:
    car_ent.x = window_width + AUTO_WIDTH

Das sogenannte Wrap-around der Fahrzeuge bietet zusätzlich ein gut überschaubares algorithmisches Problem. Die Bewegungsrichtung entscheidet darüber, welche Bildschirmgrenze relevant ist und an welcher Position das Auto anschließend wieder eingesetzt werden muss. Bedingungen, Vorzeichen und Koordinaten greifen hier direkt ineinander. Gleichzeitig entsteht der Eindruck eines kontinuierlichen Verkehrs, obwohl nur eine begrenzte Zahl von Objekten verwendet wird. Damit lässt sich sehr anschaulich über Objektwiederverwendung und effiziente Modellierung sprechen.

def kollision_auto(ctx, frosch_e, auto_e):
    if ctx.vars["tot"] or ctx.vars["gewonnen"]:
        return

    ctx.vars["leben"] -= 1

    if ctx.vars["leben"] <= 0:
        ctx.vars["tot"] = True
    else:
        frog_ent.x = FROG_START_X
        frog_ent.y = FROG_START_Y

BEI_KOLLISION("frosch", "auto", kollision_auto)

Die Kollisionsbehandlung macht besonders deutlich, wie Ereignisse und Programmzustände zusammenwirken. frameCraft erkennt die Berührung zweier Objektgruppen, während der Python-Code festlegt, welche fachliche Bedeutung dieses Ereignis besitzt. Ein Leben wird abgezogen, anschließend entscheidet eine Bedingung zwischen Respawn und Game Over. Damit wird ein zentraler Gedanke ereignisorientierter Systeme greifbar: Nicht die technische Kollision selbst ist die Spielregel, sondern die Reaktion, die das Programm daran knüpft.

if frog_ent.y <= 14:
    ctx.vars["gewonnen"] = True
    ctx.vars["punkte"] += 100

Auch die Zielzone ist bewusst einfach modelliert. Statt eine besondere Grafik mit eigener komplexer Logik zu benötigen, genügt eine Bedingung auf der y-Koordinate. Dadurch lässt sich im Unterricht sehr gut zeigen, dass ein Modell nicht komplizierter sein muss als erforderlich. Der Zustand gewonnen beeinflusst anschließend andere Teile des Programms: Bewegung wird beendet, Endtexte werden relevant und ein Neustart kann angeboten werden. So entsteht aus wenigen booleschen Variablen bereits ein verständliches Zustandsmodell des Spiels.

if ctx.vars["ende_gezeigt"]:
    return

if not (ctx.vars["tot"] or ctx.vars["gewonnen"]):
    return

ctx.vars["ende_gezeigt"] = True

Mit ende_gezeigt und neu_sperre begegnen die Lernenden darüber hinaus einem wichtigen Muster robuster interaktiver Software: Bestimmte Aktionen sollen trotz wiederholter Programmausführung nur einmal pro Zustandswechsel stattfinden. Solche Sperr- oder Latch-Variablen sind ein sehr guter Anlass, über Unterschiede zwischen dauerhaftem Zustand und einmaligem Ereignis zu sprechen. Das Konzept lässt sich später auf Benutzeroberflächen, Sensorereignisse oder andere interaktive Anwendungen übertragen.

def create_cars_for_lane(ctx, lane_index, lane_y,
                         vel_x, body_color, window_width):
    car_spacing = window_width // NUM_AUTOS

    for index in range(NUM_AUTOS):
        # Auto erzeugen und konfigurieren
        ...

Ein weiterer pädagogischer Vorteil dieses Frogger-Projekts liegt in der zunehmenden Strukturierung des Codes durch Funktionen. Wiederkehrende Aufgaben wie das Erzeugen einer Fahrspur, das Zeichnen von Markierungen oder das Erstellen einer Grafik werden ausgelagert und mit Parametern versehen. Schülerinnen und Schüler erleben damit Refactoring nicht als nachträgliche kosmetische Maßnahme, sondern als notwendige Reaktion darauf, dass ein Programm wächst. Aus wiederholtem Code entstehen allgemeine Funktionen; aussagekräftige Namen und klar definierte Parameter machen deren Verantwortung sichtbar.

Gerade dadurch eignet sich Frogger gut für eine längere Unterrichtsreihe: Der Kurs beginnt mit leicht verständlicher Bewegung und sichtbaren Spielobjekten und entwickelt sich schrittweise hin zu Schleifen, Datenstrukturen, zeitbasierter Simulation, Ereignissen, Zuständen, Wiederverwendung und Refactoring. frameCraft reduziert dabei technische Einstiegshürden, ohne diese informatischen Konzepte zu ersetzen. Für Informatiklehrkräfte entsteht so ein Projekt, das schnelle Erfolgserlebnisse mit einem belastbaren fachlichen Kompetenzaufbau verbindet und zugleich zahlreiche Möglichkeiten für Differenzierung, eigene Levelvarianten und weiterführende Programmieraufgaben bietet.

Kompetenzaufbau

Vom ersten Objekt bis zum Spielzustand

Die Vorlage zeigt nicht nur, dass ein Spiel funktioniert. Sie macht sichtbar, wie interaktive Systeme aufgebaut werden: über Szenen, wiederkehrende Regeln, Ereignisse, Objekt-Tags und Zustandsvariablen.

• Grundlagen der Game-Struktur mit Szene, Build-Phase und Regeln
• Bewegungslogik und Eingabeverarbeitung über Aktionen
• Rasterbasierte Spielfigursteuerung mit Bildschirmgrenzen
• Zeitbasierte Gegnerbewegung mit Delta-Time
• Kollisionsbehandlung, Leben, Punkte und Game-State
• HUD, grafische Formen und saubere Codeorganisation

Struktur der Bausteine

Zwölf Schritte von der Szene bis zum Polish

Die Bausteine sind so angelegt, dass Lernende das Spiel kontinuierlich erweitern. Jede Einheit ergänzt eine klar erkennbare Funktion und stärkt ein konkretes informatisches Konzept.

Szene & Regel: Frosch automatisch bewegen

Einführung in die grundlegende Struktur eines frameCraft-Spiels mit Szene, Objekt und automatisch ausgeführter Regel.

⏱️ 20 min🧩 1 Aufgabe

Frogger: Rastersteuerung und Bildschirmgrenzen

Umsetzung einer rasterbasierten Steuerung über Aktionen sowie Begrenzung der Spielfigur auf den sichtbaren Spielbereich.

⏱️ 20 min🧩 1 Aufgabe

Touch-Buttons: gleiche Frog-Steuerung per VKNOPF

Alternative Eingabemöglichkeiten über virtuelle Buttons, die dieselben Aktionen wie die Tastatursteuerung auslösen.

⏱️ 20 min🧩 1 Aufgabe

Levelaufbau: Straßenstreifen und Markierungen

Aufbau der Spiellandschaft mithilfe von Hilfsfunktionen und Schleifen für wiederkehrende Levelstrukturen.

⏱️ 25 min🧩 1 Aufgabe

Frogger: Autos mit dt & Wrap-around

Zeitbasierte Bewegung für Gegnerobjekte und kontinuierliche Bewegung über Bildschirmgrenzen hinweg.

⏱️ 25 min🧩 1 Aufgabe

Frogger: Autos datengetrieben erzeugen

Automatisierte Erstellung mehrerer Gegner durch datengetriebene Strukturen und systematische Namenskonventionen.

⏱️ 35 min🧩 1 Aufgabe

Kollisionen & Leben: Frogger-Logik

Implementierung von Kollisionsereignissen und Verwaltung des Spielzustands über Leben, Respawn und Game-Over.

⏱️ 20 min🧩 1 Aufgabe

Frogger: Siegbedingung, Punkte & Game-State

Erweiterung um Punktevergabe, Siegbedingung und klare Spielzustände für den Ablauf eines Levels.

⏱️ 25 min🧩 1 Aufgabe

HUD & Endtexte mit frameCraftUI

Entwicklung einer Benutzeroberfläche zur Anzeige von Leben, Punkten und Endzuständen des Spiels.

⏱️ 20 min🧩 1 Aufgabe

Robuster Neustart mit Sperre und Button

Stabile Reset-Logik mit Sperrmechanismus sowie eingeblendetem Neustart-Button nach Spielende.

⏱️ 25 min🧩 1 Aufgabe

Frogger: GFX-Formen & Koordinaten

Gestaltung von Spielfiguren und Gegnern durch programmierte Grafikformen im lokalen Koordinatensystem.

⏱️ 35 min🧩 1 Aufgabe

Frogger-Refactoring: Struktur & Benennung

Überarbeitung der Codebasis durch klare Strukturierung, konsistente Benennung und erklärende Kommentare.

⏱️ 35 min🧩 1 Aufgabe

def kollision_auto(ctx, frosch_e, auto_e):
    if ctx.vars.get("tot"):
        return
    ctx.vars["leben"] -= 1
    frog_ent = ctx.E("frosch")
    if ctx.vars["leben"] <= 0:
        ctx.vars["tot"] = True
        if frog_ent is not None:
            frog_ent.alive = False
    else:
        if frog_ent is not None:
            frog_ent.x = FROG_START_X
            frog_ent.y = FROG_START_Y
BEI_KOLLISION(“frosch”, “auto”, kollision_auto)