Clean Break: Ein 3D-Rätselspiel mit OpenGame entwickeln

Clean Break spielen: Das Browser-Rätselspiel mit sechs Levels wurde in OpenGame Studio entwickelt. Ziele auf den Mechanismus, verändere die Bewegung seiner Teile und befördere die markierte Kiste in die Bergungszone, ohne die blaue Maschine zu beschädigen. Pro Versuch stehen drei Schüsse zur Verfügung. Die Spieloberfläche ist auf Englisch.

Der Trainingshof der veröffentlichten V16. Der Screenshot stammt aus dem spielbaren Spiel.

Bis dahin waren 16 Generierungsaufträge, mehrere Testdurchläufe im Browser und Korrekturen am Spiel sowie an der Plattform nötig. Hier erklären wir, wie aus einem kleinen ersten Rätsel durch Beobachtung und gezielte Änderungsaufträge ein vollständigeres Spiel wurde.

Mit einer verständlichen Entscheidung beginnen

Vor Clean Break versuchten wir uns an einem Lieferspiel. Routen und Aufgaben funktionierten, doch der Auftraggeber empfand die Straßen als zu eng und das Fahrgefühl als wenig überzeugend. Zusätzliche Kulissen lösten das Problem nicht. Wir beendeten diesen Ansatz und wählten eine andere Interaktion.

Bei Clean Break betrachtet der Spieler einen Mechanismus aus einer festen Perspektive, wählt einen Schusspunkt und beobachtet die Folgen. Ohne frei bewegliche Spielfigur und Kamerasteuerung konnten wir uns auf weniger Eingaben konzentrieren.

Der erste Entwurf war trotzdem zu einfach: Ein einzelner getroffener Bolzen hätte sofort den Sieg ausgelöst. In der Studio-Diskussion machten wir daraus ein Balanceproblem mit zwei Schritten: zunächst das Gleichgewicht des Balkens verändern, dann die Kiste freigeben. Die falsche Reihenfolge musste eine andere, nachvollziehbare Folge haben.

Auch die Simulation begrenzten wir ausdrücklich auf geführte Bewegungen, Scharniere, Stützen und Schwerkraft. Eine universelle Starrkörper-Engine für Zerstörung war nicht als verfügbare Fähigkeit bestätigt. Diese Grenze bestimmte die Rätselgestaltung.

Erst die SPEC besprechen, dann generieren

Wir besprachen das Design im echten Studio-Chat und bestätigten die SPEC vor dem ersten Build. Zu den Anforderungen gehörten:

• Eine feste schräge Perspektive auf Mechanismus und Ziel.
• Freies Zielen mit der Maus und höchstens drei Schüsse.
• Eine markierte Kiste, eine Bergungszone und eine geschützte blaue Maschine.
• Unterschiedliche Ergebnisse für sinnvolle Schusspositionen und Reihenfolgen.
• Sofortiger Neustart, auch während sich Teile bewegen.
• Ein herunterladbares Spielpaket.

Dieser englische Startprompt fasst das Design zusammen. Er ist eine wiederverwendbare Vorlage, kein wörtliches Protokoll des ersten Prompts und keine Garantie, V16 mit einer einzigen Generierung zu erhalten.

Discuss a small English-language 3D puzzle game before generating code.

The player inspects a mechanism from a fixed oblique camera, aims,
and fires up to three shots. The goal is to move a marked crate into
salvage without hitting a protected blue machine.

Start with one puzzle requiring two consequential actions.
A wrong order must have a visible, understandable consequence.
Success must follow the crate's position and contact with objects.

Explain which support, hinge, gravity, and collision behavior the
available runtime can reliably support. Keep the simulation bounded.

Define the controls, win and loss conditions, last-shot resolution,
reset behavior, and downloadable output. Return a SPEC for review
before generating the game.

Entscheidend sind die Abnahmekriterien. Sie ermöglichen mehr als die bloße Feststellung, dass eine Szene angezeigt wird.

Das erste Rätsel auf verschiedene Arten spielen

Nach dem ersten Build spielten wir auf der Website mit Maus und Tastatur: richtige Reihenfolge, falsche Reihenfolge und ein absichtlicher Fehlschuss vor den zwei wirksamen Schüssen.

Der letzte Fall ist wichtig. Nach dem letzten Schuss darf das Spiel nicht sofort eine Niederlage auslösen, während die Kiste noch zum Ziel unterwegs ist.

Wir setzten das Spiel außerdem während einer Bewegung zurück und klickten schnell hintereinander. So prüften wir, ob während einer laufenden Auswertung weitere Munition verbraucht wurde.

Der erste Ablauf funktionierte, aber die Szene war dunkel und die Kanone teilweise abgeschnitten. Darauf folgte eine gezielte Verbesserung der Lesbarkeit. Ein Test in einem hohen Fenster zeigte später, dass eine Begrenzung des Kameraabstands die Bergungszone aus dem Bild schob. Dafür gab es eine separate Kamerakorrektur.

Unser Rhythmus blieb gleich: spielen, den Fehler beschreiben, eine zusammenhängende Änderung anfordern und die neue Version erneut spielen.

Erst einen funktionierenden Ablauf schaffen, dann erweitern

Wir erweiterten von einem auf drei und schließlich sechs Rätsel. Eine erfolgreiche Generierung bedeutete nicht, dass jedes neue Level lösbar war.

Im zweiten Hof rutschte die Kiste nicht wie vorgesehen. Eine schreibgeschützte Prüfung des heruntergeladenen Quellcodes erklärte die Beobachtung: Die Steigung reichte bei der eingestellten Reibung nicht aus. Ein fallender Bolzen konnte außerdem die geschützte Maschine treffen, und die Brücke benötigte mehr Abstand.

Diese Beobachtungen gingen zurück an Studio. Die Website erzeugte die nächste Spielversion; wir luden kein lokal repariertes Spiel hoch, um es als Studio-Ergebnis auszugeben.

Der fünfte Hof brauchte später zwei Reparaturversuche. Der Winkel einer Kopplung und die Ausgangslage der zweiten Kiste waren falsch. Dadurch scheiterte die richtige Lösung, während ein vorgesehener falscher Weg anders funktionierte als geplant. Erst V11 konnten wir vollständig durchspielen.

„Repariere die Physik“ war als Auftrag zu allgemein. Ein brauchbarer Fehlerbericht nennt das Level, die Eingaben, das sichtbare Ergebnis und die Prüfung, die nach der Korrektur erfolgreich sein soll.

Änderungen aus Beobachtungen ableiten

Ein späterer visueller Ausbau erzeugte einen Fehler beim Levelwechsel: Nach Continue blieben lose Teile des vorherigen Hofs sichtbar. Wer jeden Hof einzeln testet, kann das übersehen.

Dieser Ausschnitt stammt aus dem tatsächlichen Auftrag für V14:

After clearing L1 and pressing Continue, its fallen counterweight and latch remain visible in L2. More detached pins/latches accumulate in L3-L6. This is not intentional salvage dressing.

Der Auftrag verlangte anschließend, die losen Teile beim Verlassen ihres Levels zu entfernen und den Mechanismus beim Zurückkehren wiederherzustellen. Während das betreffende Level aktiv ist, müssen seine beweglichen Teile hingegen erhalten bleiben.

Eine praktische englische Vorlage für Änderungen:

Baseline: identify the saved version you just played.

Observed problem: name the scene and visible symptom.
Reproduction: give the actions that produce it.
Expected result: explain what should happen instead.
Scope: identify the related changes for this revision.
Acceptance: list the routes, retries, and transitions to replay.

Return the revised SPEC for confirmation before generating.

Ein enger Auftrag macht eine Iteration nachvollziehbar. Er garantiert bei einer generativen Änderung jedoch nicht, dass jede andere Codezeile unverändert bleibt. Bereits funktionierendes Verhalten muss erneut geprüft werden.

Die Mechanik trotz Dekoration lesbar halten

V13 enthielt bereits alle sechs Höfe. Die letzte Überarbeitung änderte die Darstellung bei gleicher beabsichtigter Rätselstruktur.

Details können auch stören: Im sechsten Hof verdeckte ein dekorativer Querbalken wichtige Teile, und Beschriftungen überlappten. Wir baten um einen offeneren Vordergrund und eine Anordnung der Beschriftungen anhand ihrer tatsächlichen Größe, mit eindeutigen Verbindungslinien.

Erst nach einem funktionierenden Gesamtdurchlauf versuchten wir den Spielzeugwerkstatt-Stil von V16: hellere Farben, Kisten mit Gesicht und kleine Werkstattgegenstände. Die Modelle bestehen weiterhin aus einfacher Geometrie. Wir akzeptierten die Verbesserung und beendeten die großen Grafikänderungen. Beide Szenenbilder stammen aus echten Spielsitzungen, nicht aus Konzeptdarstellungen.

Spielfehler von Plattformfehlern unterscheiden

Manche Probleme erforderten eine neue Spielversion, andere eine Reparatur an OpenGame. Wir korrigierten ein Timeout beim Warten auf Antwortheader des Modellanbieters sowie einen Fehler bei der Komprimierung langer Gesprächsverläufe. Auf der Website verbesserten wir die Behandlung unterbrochener Ergebnisdownloads und ergänzten eine Prüfung auf bereits gespeicherte Ergebnisse nach einem fehlgeschlagenen Auftrag.

V14 zeigte den Unterschied besonders deutlich: Der Auftrag war fehlgeschlagen und erstattet worden, obwohl brauchbare Spieldateien existierten. Wir stellten sie später über die Website wieder bereit und prüften Vorschau sowie ZIP-Download. Der ursprüngliche Fehlerstatus und die Erstattung blieben erhalten.

Uns unterlief auch ein vermeidbarer Fehler: Vor dieser Wiederherstellung forderten wir eine weitere Version an. V15 lieferte unveränderte Inhalte und scheiterte. Trotz Erstattung kostete das weitere 13 Minuten Wartezeit.

Deshalb lohnt sich vor einem erneuten Versuch die Diagnose. Ein nicht zugängliches gespeichertes Ergebnis, ein Generierungsfehler und ein unspielbares Level brauchen unterschiedliche Lösungen.

Was die Iterationen kosteten

Diese Zahlen betreffen nur Clean Break, ohne das frühere Lieferspiel.

| Kennzahl | Ergebnis | | --- | --- | | Generierungsaufträge | 16 | | Zunächst erfolgreich abgeschlossen | 11 | | Zunächst fehlgeschlagen | 5 | | Gesamtdauer aller Aufträge | 2 Stunden, 43 Minuten, 54 Sekunden | | Davon fehlgeschlagene Aufträge | 50 Minuten, 53 Sekunden | | Credits belastet / erstattet / netto | 160 / 50 / 110 | | Veröffentlichte Version | V16 |

Die Auftragsdauer reicht von der Erstellung bis zum Abschluss oder Fehler und umfasst Modellaufrufe, Werkzeuge, Prüfung und Speicherung. Diskussionen, Spieltests, Diagnose und Plattformreparaturen sind nicht enthalten. Die Zahl ist daher keine Schätzung der gesamten Produktionsarbeit.

V14 zählt weiterhin als ursprünglich fehlgeschlagener Auftrag. Credits sind OpenGame-Nutzungseinheiten, keine Berechnung der Kosten beim Modellanbieter.

Auch kleine Änderungen konnten lange dauern, weil der Ablauf eine vollständige Spieldatei schrieb. Präzise Aufträge und zielgerichtete Tests halfen, unnötige Iterationen zu vermeiden.

Mit Kampagnentest und Export abschließen

Abschlussbildschirm nach den sechs richtigen Lösungswegen in V16.

Vor dem Abschluss spielten wir alle sechs Lösungen in V16, luden die originale ZIP-Datei herunter, veröffentlichten das Spiel über Studio und prüften, dass es auf der öffentlichen Seite startet.

V14 hatte zusätzliche Prüfungen für falsche Reihenfolgen, Siege mit dem letzten Schuss, Zurücksetzen während der Bewegung, Levelwechsel und verschiedene Fenstergrößen erhalten. Nicht jeder dieser Grenzfälle wurde für V16 erneut geprüft. Auch die Spieldauer neuer Spieler und das Beibehalten des Fortschritts nach einem Neuladen wurden nicht abschließend verifiziert.

Clean Break ist ein veröffentlichtes, spielbares Beispiel mit herunterladbarem Entwicklungspaket. Grafik und Testabdeckung können weiter verbessert werden.

Den Ablauf für ein eigenes Spiel nutzen

1. Eine Entscheidung und ihre sichtbare Folge definieren.
2. Vor der Generierung die SPEC bestätigen.
3. Einen erfolgreichen Weg, einen Fehlversuch und einen Neustart spielen.
4. Fehler mit reproduzierbaren Eingaben beschreiben.
5. Eine zusammenhängende Änderung anfordern und betroffene Abläufe erneut prüfen.
6. Erst nach funktionierender Kerninteraktion mehr Inhalt hinzufügen.
7. Das fertige Spiel und seinen Export vor dem Abschluss überprüfen.

Spiele Clean Break und öffne OpenGame Studio, um ein eigenes Rätsel zu besprechen. Weitere spielbare Browsergames zeigen unterschiedliche vollständige Spielabläufe. Der Prompt hilft beim Einstieg; das fertige Spiel entstand durch die anschließenden Iterationen.

Produktionshinweis: Grundlage sind Studio-Sitzungen vom 26.–27. September 2026, gespeicherte Prompts, Auftragsdaten, heruntergeladene Versionen und Browser-Spieltests. Screenshots sind nach Version gekennzeichnet. Das Spiel wurde über Studio erstellt und geändert; Plattformreparaturen waren separate Entwicklungsarbeiten.