DE
Nur die Brotfigur aus dem CRUMB-Logo: eine lächelnde Toastscheibe mit einem Biss aus der oberen rechten Ecke
Zurück zum Saal

CRUMB

Generative Game Studio · Demo

Von einem einzeiligen Spiel-Pitch zu einem spielbaren Entwurf, mit der Arbeit der Agenten im Blick und offen für Eingriffe.

CRUMB ist ein Multi-Agent-Studio-Harness für das Prototyping von Casual Games.

Design und Entwicklung · mit KI-Coding-Agenten gebaut

  • CLILokale Demo
  • Web-StudioLokale Demo

Die Agenten, die ein Spiel bauen, getrennt von den Belegen, die es beurteilen.

Eine lokale Studio-Demo, die einen einzeiligen Spiel-Pitch durch Spezifikation, Build und Ausführungsprüfungen führt. Jeder Schritt landet in einem JSONL-Transkript, ein reiner Reducer bestimmt die nächsten Effekte, und nur der Dispatcher führt Seiteneffekte aus. Ausführungs-QA und das Urteil des Modells bleiben getrennt, um zwischen Bestehen, Neuentwurf, Nachbesserung und menschlicher Steuerung zu entscheiden.

Wird ein Spiel in einer Zeile vorgeschlagen, arbeiten Agenten von Claude Code, Codex und Gemini CLI über Planner → Builder → deterministische QA → Verifier zusammen, während CRUMB Studio Ereignisse, Fortschritt und Artefakte zeigt und Eingriffe in natürlicher Sprache annimmt.

Eine Demo, die aus dem öffentlichen Repository geklont und lokal ausgeführt wird.

Systemkarte · gezeichnet nach den Codepfaden im öffentlichen Commit f5e17c0
CRUMB-StudiosystemEin Mensch schlägt in Studio ein Spiel vor und steuert es, und Studio schreibt Befehle in eine Inbox. Der Coordinator gibt neue Ereignisse aus Inbox und Transkript der Reihe nach an den Reducer; der reine Reducer bestimmt Zustand und nächste Effekte, und nur der Dispatcher führt Seiteneffekte aus. Die Spezifikation des Planners, Build und Artefakte des Builders, das Ergebnis der Ausführungs-QA und das Urteil des Verifiers werden alle zu Transkript-Ereignissen. Der Verifier erhält nur projizierte Belege, und der Reducer prüft und korrigiert seinen Score anhand des QA-Ergebnisses: PASS beendet die Session, PARTIAL wartet auf einen Menschen, alles andere geht zurück zu Neuentwurf oder Nachbesserung.Spiel-Pitch · SteuerungEin Mensch, lokalpackages/studioAnsicht Ereignisse · ArtefakteInbox-Befehle schreibensrc/transcripttranscript.jsonl · append-onlysrc/loop/coordinator.tsEvent-Loop · Replay · tailsrc/reducerZustand → nächste EffekteUrteils-Routingsession doneFertig · PASS oder Stoppgrundsrc/dispatcher/live.tsEffekte ausführen · Actors startenProjektion der Bewertungseingabemodel-config · presetActor → Harness · Modellagent actor · CLIPlanner Lead · SpezifikationBuilder · schreibt das Spielartifacts/Spieldateiendispatcher/qa-runner.tsAusführungs-QA · PrüfungenVerifier actorVerifier · Modellurteilsrc/validatorAnti-Deception · Score-KorrekturMenschen · StudioEreignissteuerungTranskript ist die Quelle des ZustandsArbeitende Agenten · ArtefakteVerifikation · Entscheidung1Pitch · Steuerung2user-Ereignisse3der Reihe nach reduzieren4Effekte5Actor-Konfiguration6Planner ausführen7spec8Builder ausführen9 Dateien · Builder · schreibt das Spiel → Spieldateien910Build-Aufzeichnung11qa_check12was läuft13qa.result1qa.result2nur Belege3Bewertungseingabe4judge.score5Score · QA-Belege6korrigiertes Urteil7beendet1korrigiertes Urteil2PARTIAL-Prüfung3Neuentwurf · Nachbesserung4beendet5Pitch · Steuerung1neue Ereignisse · Replay2der Reihe nach reduzieren3Lesen · SSE

Vom Pitch zum Spiel

Ein Pitch wird zu einer Spezifikation, einem Build und einem Lauf der Ausführungs-QA. Jeder Schritt geht durch das Transkript; Actors rufen einander nicht auf.

  1. Spiel-Pitch · SteuerungPitch · SteuerungInbox-Befehle schreibenpackages/studio

    Ein einzeiliger Spiel-Pitch und Steuerung in natürlicher Sprache werden in Studio eingegeben, das Befehle in die Inbox schreibt. Studio bearbeitet das Transkript nie direkt.

  2. Inbox-Befehle schreibenpackages/studiouser-EreignisseEvent-Loop · Replay · tailsrc/loop/coordinator.ts

    Der Coordinator liest Inbox-Befehle und hält sie im Transkript als user-Ereignisse fest.

  3. Event-Loop · Replay · tailsrc/loop/coordinator.tsder Reihe nach reduzierenZustand → nächste Effektesrc/reducer

    Live-Ereignisse werden einzeln aus einer Queue reduziert, wobei die Effekte jedes Ereignisses in Reihenfolge bleiben; der Dispatch selbst läuft asynchron.

  4. Zustand → nächste Effektesrc/reducerEffekteEffekte ausführen · Actors startensrc/dispatcher/live.ts

    Der Reducer ist eine reine Funktion, die nur Zustand und nächste Effekte bestimmt: Ein goal wählt den Planner, eine spec den Builder, ein build einen qa_check.

  5. Actor → Harness · Modellmodel-config · presetActor-Konfigurationsrc/dispatcher/live.ts

    Mit welchem Harness, Anbieter und Modell ein Actor läuft, wird in der Reihenfolge CLI-Flag > Konfiguration > Preset > Ambient > Fallback bestimmt. Ein Actor ist kein fester Anbieter.

  6. Effekte ausführen · Actors startensrc/dispatcher/live.tsPlanner ausführenPlanner Lead · Spezifikationagent actor · CLI

    Der Dispatcher führt den Planner mit projizierter Eingabe aus. Bedingte Recherche läuft über den Rechercheplan des Planners und die Übergabe von Belegen weiter, auf dieser Karte eingeklappt.

  7. Planner Lead · Spezifikationagent actor · CLIspectranscript.jsonl · append-onlysrc/transcript

    Die Spezifikation des Planners wird zu einem Transkript-Ereignis, und der Reducer wählt daraus den Builder. Actors rufen einander nicht auf.

  8. Effekte ausführen · Actors startensrc/dispatcher/live.tsBuilder ausführenBuilder · schreibt das Spielagent actor · CLI

    Der Dispatcher führt den Builder aus. Scheitert derselbe Actor wiederholt, öffnet sich ein Circuit und tauscht den Adapter; gehen die Fehlschläge weiter, wird gestoppt.

  9. Builder · schreibt das Spielagent actor · CLIDateienSpieldateienartifacts/

    Der Builder schreibt Einstiegsdatei, Quellen und Assets als Artefakte.

  10. Builder · schreibt das Spielagent actor · CLIBuild-Aufzeichnungtranscript.jsonl · append-onlysrc/transcript

    Das build-Ereignis und artifact.created werden mit der Identität des Artefakts im Transkript aufgezeichnet.

  11. Effekte ausführen · Actors startensrc/dispatcher/live.tsqa_checkAusführungs-QA · Prüfungendispatcher/qa-runner.ts

    Nach einem build-Ereignis gibt der Reducer einen qa_check-Effekt mit Artefakt- und Build-Identität sowie den Abnahmebedingungen aus, und der Dispatcher führt ihn aus.

  12. Spieldateienartifacts/was läuftAusführungs-QA · Prüfungendispatcher/qa-runner.ts

    Die Ausführungs-QA führt das tatsächliche Artefakt mit Code- und Browserprüfungen aus. Das Standard-Timeout von 120 Sekunden ist ein Konfigurationswert.

  13. Ausführungs-QA · Prüfungendispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    Ob Erfolg oder Fehlschlag, das Ergebnis wird als system-Ereignis qa.result aufgezeichnet. Selbst wenn die Prüfung eine Ausnahme wirft, wird ein Ergebnis mit den fehlgeschlagenen Feldern aufgezeichnet.

Vertrauensgrenze der Verifikation

Die Ausführungs-QA liefert Belege aus der tatsächlichen Ausführung des Artefakts; der Verifier ist ein Modell, das projizierte Belege beurteilt. Der Reducer gleicht beides ab, bevor er den nächsten Pfad wählt.

  1. Ausführungs-QA · Prüfungendispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    Ob Erfolg oder Fehlschlag, das Ergebnis wird als system-Ereignis qa.result aufgezeichnet. Selbst wenn die Prüfung eine Ausnahme wirft, wird ein Ergebnis mit den fehlgeschlagenen Feldern aufgezeichnet.

  2. transcript.jsonl · append-onlysrc/transcriptnur BelegeProjektion der Bewertungseingabesrc/dispatcher/live.ts

    Die Eingabe des Verifiers wird aus dem neuesten goal, spec, build, qa.result und artifact.created sowie ausgewählten Recherchebelegen projiziert. Sie verengt den Kontext; Isolation oder das Fehlen von Lecks beweist sie nicht.

  3. Projektion der Bewertungseingabesrc/dispatcher/live.tsBewertungseingabeVerifier · ModellurteilVerifier actor

    Der Dispatcher führt den Verifier mit der projizierten Eingabe aus.

  4. Verifier · ModellurteilVerifier actorjudge.scoretranscript.jsonl · append-onlysrc/transcript

    Das Urteil des Verifiers wird als judge.score-Ereignis aufgezeichnet. Es ist die Einschätzung eines Modells, keine Tatsache über die Ausführung.

  5. Zustand → nächste Effektesrc/reducerScore · QA-BelegeAnti-Deception · Score-Korrektursrc/validator

    Bei judge.score übergibt der Reducer es zusammen mit dem QA-Ergebnis, dem Anbieter des Builders sowie Rechercheplan und Belegen an die Anti-Deception-Prüfung.

  6. Anti-Deception · Score-Korrektursrc/validatorkorrigiertes UrteilUrteils-Routingsrc/reducer

    Ein PASS ohne erfolgreiche Ausführung wird zu FAIL, und der ausführungsbezogene Score wird aus der deterministischen QA korrigiert. Die übrigen Regeln sind bedingte Korrekturen, kein allgemeiner Beweis von Wahrhaftigkeit.

  7. Urteils-Routingsrc/reducerbeendetFertig · PASS oder Stoppgrundsession done

    PASS beendet die Session als done. Auch Budget- und Circuit-Stopps enden als done, behalten aber ihren Stoppgrund, daher ist done nicht immer PASS.

Fehlschlag und menschliche Steuerung

PARTIAL geht an einen Menschen, Critical zum Neuentwurf, Important oder Minor zur Nachbesserung, und Budget- oder Circuit-Stopps hinterlassen einen Stoppgrund.

  1. Anti-Deception · Score-Korrektursrc/validatorkorrigiertes UrteilUrteils-Routingsrc/reducer

    Ein PASS ohne erfolgreiche Ausführung wird zu FAIL, und der ausführungsbezogene Score wird aus der deterministischen QA korrigiert. Die übrigen Regeln sind bedingte Korrekturen, kein allgemeiner Beweis von Wahrhaftigkeit.

  2. Urteils-Routingsrc/reducerPARTIAL-PrüfungSpiel-Pitch · Steuerung

    PARTIAL wartet auf die Prüfung durch einen Menschen.

  3. Urteils-Routingsrc/reducerNeuentwurf · Nachbesserungsrc/dispatcher/live.ts

    Unter FAIL und REJECT geht Critical zum Neuentwurf an den Planner zurück und Important oder Minor als Korrektur-Feedback an den Builder, alles als Dispatcher-Effekte ausgeführt.

  4. Urteils-Routingsrc/reducerbeendetFertig · PASS oder Stoppgrundsession done

    PASS beendet die Session als done. Auch Budget- und Circuit-Stopps enden als done, behalten aber ihren Stoppgrund, daher ist done nicht immer PASS.

  5. Spiel-Pitch · SteuerungPitch · SteuerungInbox-Befehle schreibenpackages/studio

    Ein einzeiliger Spiel-Pitch und Steuerung in natürlicher Sprache werden in Studio eingegeben, das Befehle in die Inbox schreibt. Studio bearbeitet das Transkript nie direkt.

Replay und Beobachtung

Der Neuaufbau des Zustands aus dem Transkript führt keine Effekte aus, und Studio liest dieselbe Aufzeichnung, um ihn zu zeigen.

  1. transcript.jsonl · append-onlysrc/transcriptneue Ereignisse · ReplayEvent-Loop · Replay · tailsrc/loop/coordinator.ts

    Der Writer validiert das Schema, vergibt eine ULID und einen Zeitstempel und hängt an. Beim Replay werden vergangene Ereignisse nur reduziert; ihre Effekte laufen nicht erneut.

  2. Event-Loop · Replay · tailsrc/loop/coordinator.tsder Reihe nach reduzierenZustand → nächste Effektesrc/reducer

    Live-Ereignisse werden einzeln aus einer Queue reduziert, wobei die Effekte jedes Ereignisses in Reihenfolge bleiben; der Dispatch selbst läuft asynchron.

  3. transcript.jsonl · append-onlysrc/transcriptLesen · SSEAnsicht Ereignisse · Artefaktepackages/studio

    Studio liest Transkript und Artefakte und zeigt Fortschritt, Metriken und Artefakte über SSE. Es ist keine Telemetrie, die an einen entfernten Dienst gesendet wird.

Alle Verbindungen in gleicher Stärke. Wird ein Ablauf gewählt, ist nur sein Pfad hervorgehoben, mit nummerierten Schritten.

  • Durchgezogen · Richtung von Eingaben, Ergebnissen und Aufzeichnungen
  • Gestrichelt · Ausführen, Urteil, Anfrage
  • Lang gepunktet · Beobachtung und Berichte, getrennt vom Urteil
  • Dicke schwarze Linie · der gewählte Ablauf; Nummern geben die Reihenfolge an
  • Kasten · Code- oder Zustandsgrenze, benannt in der Kopfzeile
  • Innerer Chip · eine Komponente dieser Grenze
  • Gepunkteter Kasten · außerhalb dieser Grenze
  • Orange Umrandung · wo ein Modell entscheidet
  • Event-Loop · reducer · dispatcher
  • Aufzeichnungen · Konfiguration · Artefakte
  • Deterministische Prüfungen · Korrektur
  • Studio · Actors

Gezeichnet nach den Codepfaden im öffentlichen Commit f5e17c0. Actors sind Laufzeitrollen, nicht die Coding-Agenten, mit denen dieses Repository gebaut wurde.

Quelle des Zustands
Das Transkript ist die Quelle des Zustands, der Reducer eine reine Funktion. Nur der Dispatcher führt Seiteneffekte aus (Actors starten, QA, Dateien schreiben), daher baut ein Replay den Zustand ohne Effekte neu auf.
Was das Replay abdeckt
Ein Replay ergibt denselben Zustand; LLM-Generierungen oder Browser- und Netzwerkverhalten macht es nicht deterministisch.
Was ein Urteil abdeckt
Die Ausführungs-QA prüft nur die konfigurierten Prüfungen, und der Score des Verifiers ist ein Strang der Belege. Keines von beiden misst das gesamte Spielverhalten, den Spielspaß oder die Zufriedenheit der Nutzer.