Was macht taptap-maker-builder (TapTap 制造 Projektaufbau)?
Diese Fertigkeit macht zwei Dinge
- Den Agenten schnell startklar machen: Vermittelt auf einer Bildschirmseite, was TapTap Maker ist, wie die beiden Kreativmodi ausgewählt werden, die fünf Elemente der ersten Anforderungsrunde, Credits & Designs und wie Benchmarks zu lesen sind. Bei spezifischen Fragen wird nur die entsprechende Referenz gelesen.
- Vom Konzept zur Veröffentlichung: Baut mit den bestätigungspflichtigen Phasen 0–6 ein Konzept Schritt für Schritt zu einem spielbaren Projekt auf. Jede Phase hat Liefergegenstände, Vorlagen und Abnahmelisten. Der Benutzer bestätigt, bevor die nächste Phase beginnt.
Diese Fertigkeit ist nur dafür zuständig „wie es vorangeht“ und startet kein reales Projekt für den Benutzer. Alle Änderungen am Projekt erfolgen im eigenen Maker-Projekt des Benutzers, und zwar erst nach Bestätigung.
Wann verwenden
- Der Benutzer fragt nach TapTap Maker / Maker / UrhoX / Maker Research Institute / Rangliste / Credits / UI-Designs / lokaler MCP-Anbindung.
- Der Benutzer lädt ein Spielkonzept oder Anforderungsdokument hoch und bittet darum, „eines zu bauen“, „es spielbar zu machen“ oder „danach zu handeln“.
- Der Benutzer möchte Maker-Dialoganforderungen schreiben, den Credit-Verbrauch prüfen, Veröffentlichungsmaterialien überprüfen oder Probleme in der Vorschau oder auf dem echten Gerät diagnostizieren.
Nicht geeignet: Unity/Unreal und andere Engines; reine Kunstauslagerung; allgemeine Programmierung, die nichts mit Maker zu tun hat.
Drei eiserne Regeln (Verstoß bedeutet Stopp)
- Online-Dokumentation zuerst: Das Produkt wird schnell weiterentwickelt. Lies zuerst https://maker.taptap.cn/llms.txt, dann bei Bedarf die entsprechenden Dokumente. Das Wissen dieser Fertigkeit hat ein Erstellungsdatum. Bei Konflikten mit der Online-Dokumentation gilt die Online-Dokumentation. Funktionen, Parameter, Modellnamen, Preise oder Limits, die nicht in der Dokumentation stehen, werden niemals erfunden.
- Bestätigungspforte nicht überspringbar: Am Ende jeder Phase (0–5) wird zuerst ein „Phasenbericht“ vorgelegt. Der Benutzer muss explizit bestätigen („bestätigt“, „weiter“, „okay“), bevor es weitergeht. Bestätigt der Benutzer nicht, wird an Ort und Stelle eine Frage gestellt.
- Kein eigenmächtiges Geldausgeben oder Dateimanipulation: Ohne explizite Aufforderung des Benutzers im Dialog werden keine creditverbrauchenden Generierungstools aufgerufen; Modelle oder Kanäle werden nicht automatisch gewechselt; Dateien des Benutzers werden nicht verschoben, gelöscht oder überschrieben; neue Systeme außerhalb des Konzepts werden nur nach Zustimmung hinzugefügt.
60-Sekunden-Produktübersicht
| Dimension | Kernpunkte | |---|---|---| | Produkt | TapTap Maker: Ein KI-gestütztes Spielerstellungstool für Spielebegeisterte. Ermöglicht Konzeptdesign, Codeimplementierung, Asset-Erstellung, iterative Vorschau und Veröffentlichungsvorbereitung in natürlicher Sprache. | | Grundlage | UrhoX Engine + Lua-Scripting; integriert die drei UI-Designs Astroon, BrawlForge und PixelForge | | Slogan | Dialog ist Kreation, Fertigstellung ist Veröffentlichung | | Zwei Kreativmodi | Browser Workspace (Projekt, Dialog, Vorschau, Veröffentlichung auf einer Seite); Lokaler Entwicklungsmodus (Maker MCP in lokalem Verzeichnis, unterstützt Codex/Cursor/Claude Code) | | Autoritative Quelle | https://maker.taptap.cn/llms.txt (Hauptindex aller Dokumente, höchste Aktualität) |
Fünf Elemente der ersten Anforderungsrunde (müssen vor dem Schreiben der Anforderung beantwortet sein): Spielziel / Darstellungsform / Steuerung / Kernspielschleife / Umfang der ersten Runde.
Credits: Fünf Typen: Allgemein, Basis, Aktion, Projekt, Bezahlt. Standardverbrauchsreihenfolge: Aktion → Projekt → Basis. Ob Allgemein und Bezahlt verfügbar sind, hängt vom aktuellen Modell, Projektumfang und serverseitiger Prüfung ab. Aktionen im Veröffentlichungs-Panel verbrauchen keine Erstellungs-Credits.
Benchmark: Echte UrhoX-Headless-Ausführung + deterministische Assertions. Die Hauptmetrik der Rangliste ist die L2-Pass Rate. Jede Punktzahl hat ein 95%-Konfidenzintervall, jeder Rang einen möglichen Bereich. Überlappen sich die Bereiche, bedeutet dies „bei der aktuellen Stichprobengröße kann noch keine Reihenfolge bestimmt werden“.
Navigationshilfe für Referenzen (nur eine nach Bedarf lesen)
| Frage oder Szenario | Welches Dokument lesen | Was ist darin enthalten |
|---|---|---|
| Was ist das Produkt? Wie wähle ich die beiden Modi? Wie installiere ich MCP? Wie sieht die Verzeichnisstruktur aus? Wie füge ich Mitarbeiter hinzu? | ./references/01-product-overview.md | Positionierung und Fähigkeitsgrenzen, Modusvergleich, Installationsbefehle, Verzeichnisstruktur, lokale Runtime, Kollaborationsregeln |
| Wie werden Credits abgezogen? Was verbraucht Credits? Was tun, wenn das Ergebnis unbekannt ist? Wie sparen? | ./references/02-credits-and-cost.md | Fünf Credit-Typen, Verbrauchsreihenfolge, Kostenkontrolle, unsichere Buchhaltung |
| Welches Design wählen? Wie wird das Design angegeben? Asset-Spezifikationen und Limits? Wie schreibe ich KI-Bildgenerierungs-Prompts? | ./references/03-ui-themes-and-assets.md | Geeignete Kategorien und visuelle Regeln für die drei Designs, Limits der fünf Asset-Typen, DWP, Asset-Verzeichnis-Konventionen |
| Wie ist die Rangliste zu lesen? Was ist L2? Wie sind Konfidenzintervall und Rangbereich zu interpretieren? | ./references/04-benchmark-guide.md | Drei Bewertungsstufen, Bedeutung und Fehlinterpretation der einzelnen Dimensionen, statistische Methoden, Einschränkungen |
| Wie zerlege ich ein Konzept? Was tun, wenn die fünf Elemente fehlen? Wie schreibe ich die erste Anforderung? | ./references/05-brief-parsing-and-first-prompt.md | Extraktionstabelle, Anzahl und Art der Rückfragen, Checkliste zur Bestätigung, gute/schlechte Beispiele für erste Anforderungen |
| Wie iterieren? Wie schreibe ich die Vier-Teil-Struktur? Fünf Prüfpunkte für die Vorschau / Sechs vor der Veröffentlichung / Sechs Datenprüfungen | ./references/06-iteration-and-acceptance.md | Schreibweise der Vier-Teil-Struktur, offizielle Reihenfolge, Abnahmeliste, häufige Fehlermodi |
| Welche Materialien werden für die Veröffentlichung benötigt? Wie läuft der QR-Code-Test? Wie wird die Freigabeseite geöffnet? | ./references/07-publish-checklist.md | Materialliste und Spezifikationen, Veröffentlichungsprozess, Synchronisation der Testversion, Aktionen nach der Veröffentlichung |
| Wie sind Anmeldeinformationen zu handhaben? Welche Aktionen sind irreversibel? Atomare Schreibvorgänge? Asset-Urheberrecht? Kollaborationssicherheit? | ./references/08-safety-and-credentials.md | Zeitlichkeit, Kosten, Anmeldeinformationen, irreversible Aktionen, atomares Schreiben, Umfang und Urheberrecht |
Regel: Lies immer nur das Dokument, das für die aktuelle Frage relevant ist; antworte erst nach dem Lesen, ergänze keine Details aus dem Gedächtnis.
Phasenübersicht (0–6)
| Phase | Ziel | Liefergegenstand | Bestätigungspforte | Werkzeug / Vorlage |
|---|---|---|---|---|
| 0 Zugang | Kreativmodus festlegen; bei lokalem Modus MCP, Projektbindung und vorhandene Verzeichnisse bestätigen | Zugangsbestätigung + Verzeichnisprüfungsergebnis | Benutzer bestätigt Modus und Umgebung | ./scripts/check_project_layout.py |
| 1 Analyse | Fünf Elemente strukturiert extrahieren, fehlende auf einmal nachfragen (≤ 4 Fragen) | Bestätigungsliste zum Konzeptverständnis | Benutzer bestätigt alle fünf Punkte einzeln, bevor Anforderungen geschrieben werden | ./assets/brief-confirmation-template.md, ./scripts/check_brief.py |
| 2 Erste Anforderungsrunde | In die erste, den offiziellen Spezifikationen entsprechende Anforderung umschreiben; nur den minimal spielbaren Kernzyklus umsetzen | Text der ersten Anforderung + Design- und visuelle Richtung | Benutzer bestätigt Anforderung und Designrichtung | ./assets/first-prompt-template.md |
| 3 Iteration | Minimal spielbar → Blockaden beheben → Rhythmus/Werte/Haptik → Assets/Sound/Anleitung/Materialien | Vie rteilige Anforderung pro Runde + Validierungsergebnis | Abnahme des Ergebnisses jeder Runde erforderlich, bevor nächste Runde startet | ./assets/feedback-four-part-template.md, ./references/06-iteration-and-acceptance.md |
| 4 Vorschau & Gerätetest | Fünf Punkte Abnahme + QR-Code-Test auf echtem Gerät | Abnahmeprotokoll, Problemliste | Nur bei bestandenen fünf Punkten weiter zur Veröffentlichung | ./references/06-iteration-and-acceptance.md, ./references/07-publish-checklist.md |
| 5 Veröffentlichung | Materialien einzeln prüfen; erst bei Versionskonsistenz veröffentlichen | Prüfliste Veröffentlichungsmaterialien | Benutzer bestätigt Materialien und Version | ./scripts/check_publish_materials.py, ./assets/stage-report-template.md |
| 6 Querschnitt | Kosten- und Sicherheitsschutz, in jeder Phase wirksam | Risikohinweise und Bestätigungsaufzeichnungen | Hochrisikoaktionen einzeln bestätigen | ./references/02-credits-and-cost.md, ./references/08-safety-and-credentials.md |
Fortschrittsdisziplin: Am Ende jeder Phase zuerst den „Phasenbericht“ geben → auf explizite Bestätigung des Benutzers warten → dann in die nächste Phase gehen.
Phase 0: Zugang
Stelle zuerst drei Dinge auf einmal klar, nicht in kleinen Schritten nachfragen:
- Browser Workspace oder Lokales MCP (lokales Verzeichnis + Codex/Cursor/Claude Code)?
- Bestehendes Projekt oder neues Projekt? Projektname, Spielrichtung?
- Gibt es vorhandene Assets oder Code-Verzeichnisse, die wiederverwendet werden sollen?
| Situation | Empfehlung |
|---|---|
| Erste Erstellung, will schnell ein Bild sehen | Browser Workspace |
| Hat bereits lokalen Code oder Assets, will Codex/Cursor/Claude Code Workflow nutzen | Lokales MCP |
| Will Git anbinden, Teamarbeit, lokale Überprüfungen durchführen | Lokales MCP |
| Will nur schnell auf dem Handy testen | Browser Workspace + Freigabe-QR-Code |
Lokale Modus-Befehle (im Zielverzeichnis ausführen; init holt das Projekt in das aktuelle Verzeichnis; zuerst prüfen, ob das Verzeichnis leer ist oder der Benutzer dem Merge zustimmt):
npx -y @taptap/maker install --ide codex,cursor,claude # Schreibt nur die drei MCP-Konfigurationen
npx -y @taptap/maker init # Login + Projektauswahl/-erstellung + Verzeichnisbindung + Abruf
- Typisches Verzeichnis nach Initialisierung: assets/ (mit image, sprites, audio, video) und scripts/; die tatsächliche Struktur variiert mit dem Projekt.
- Führe vor dem Eingreifen
python ./scripts/check_project_layout.py <Projektstamm>aus und lies das bestehende Verzeichnis und die Beschreibungen, um die Überschreibung von Ressourcen zu vermeiden. - Komponenten aktualisieren: „Aktualisiere Maker MCP und AI DevKit für das aktuelle Projekt und nenne mir dann die tatsächlich verwendeten Versionen“; für die Produktion pd/stable, für Experimente rnd/latest.
- Anmeldeinformationen nur in der vertrauenswürdigen lokalen Umgebung speichern, nicht in Projektdateien oder Git.
Bestätigungspforte 0 Formulierung: „Ich werde mit Modus X zugreifen, das Projektverzeichnis ist Y, die bestehende Struktur ist Z, und A wird nicht überschrieben. Nach Bestätigung geht es zur Konzeptanalyse.“
Phase 1: Konzeptanalyse
Ablauf:
- Konzept vollständig lesen, direkt die Fünf-Elemente-Tabelle extrahieren, nicht den gesamten Absatz wiederholen.
- Jedes Element kennzeichnen: Vorhanden (Quellennachweis) / Geschlossen (muss bestätigt werden) / Fehlt.
- Fehlende und kritische Unklarheiten auf einmal abfragen, ≤ 4 Fragen, jede mit 2–3 Antwortkandidaten, um den Antwortaufwand zu senken.
- „Bestätigungsliste zum Konzeptverständnis“ erstellen, muss enthalten: „Was ich verstehe / Was ich nicht sicher weiß / Was ich für die erste Runde vorschlage wegzulassen.“
- Erst nach Benutzerbestätigung zu Phase 2 übergehen.
Harte Regeln:
- Kritische Festlegungen (Thema, Hauptfigur, Kern-Sieg-/Verlustbedingung, Steuerungsmethode, Zielplattform und visuelle Richtung) dürfen nicht erfunden werden; fehlen sie, frage nach, oder kennzeichne sie klar als „vorläufig“ und gib eine Standardempfehlung.
- Spätere Systeme im Konzept (Aufbau, Shop, Multiplayer, Rangliste, mehrere Kapitel) gehören in „spätere Versionen“, nicht in die erste Runde.
- In der Bestätigungsliste muss klar stehen, „was in der ersten Runde nicht gemacht wird“.
Kann zuerst mit einem Skript prüfen, ob die fünf Elemente vollständig sind (JSON-Struktur siehe Kopfkommentar des Skripts):
python ./scripts/check_brief.py brief.json
Phase 2: Erste Anforderungsrunde generieren
Reihenfolge beim Schreiben der ersten Anforderung: Ein-Satz-Positionierung → Fünf Elemente → Steuerung & Sieg/Niederlage → Bildschirmliste → Außerhalb des Umfangs.
- Eine Anforderung löst nur ein Ergebnis. Mache zuerst den minimal spielbaren Kernzyklus.
- Klar zu sagen, „was in dieser Runde nicht gemacht wird“, grenzt den Umfang besser ein als eine Liste vieler Funktionen.
- Gleichzeitig bestätigen: UI-Design (Astroon / BrawlForge / PixelForge), Bildschirmausrichtung (Querformat / Hochformat), Perspektive (2D / 3D), künstlerischer Grundton.
- Vorlage: ./assets/first-prompt-template.md; gut/schlecht Beispiele siehe ./references/05-brief-parsing-and-first-prompt.md.
Formulierung zur Bestätigung von Design und Richtung: „Ich schlage Design A vor (Begründung: passt zur Kategorie), Hochformat 2D; wenn du B bevorzugst, ändere ich es auf B. Nach Bestätigung sende ich die erste Anforderung.“
Phase 3: Iterativer Aufbau
Offizielle Reihenfolge (nicht überspringen):
- Minimal spielbare Version (kann starten, bedient werden, enden, neu gestartet werden)
- Blockaden im Ablauf beheben (Einfrieren, Knöpfe nicht klickbar, Zustand wird nicht zurückgesetzt)
- Rhythmus, Werte, Haptik anpassen
- Assets, Sound, Anleitung, Veröffentlichungsmaterialien ergänzen
Jede Anforderung mit der Vier-Teil-Struktur: Ziel / Aktueller Zustand / Einschränkungen / Abnahme (Vorlage ./assets/feedback-four-part-template.md).
- Konzentriere dich immer nur auf ein Ergebnis; „Sound hinzufügen + Werte ändern + Design wechseln“ nicht in dieselbe Anforderung schreiben.
- „Einschränkungen“ schreiben, was erhalten bleiben muss (vorhandene Steuerung, bestätigtes Design, nicht umzustrukturierende Module).
- „Abnahme“ als beobachtbares Phänomen formulieren, nicht „macht mehr Spaß“.
- Fordere die KI auf, selbst zu bauen, Fehler zu prüfen und das Validierungsergebnis zu erklären; bei komplexen Änderungen soll sie zuerst einen kurzen Plan geben.
- Bleibe für dasselbe Ziel im selben Dialog; für eine neue Richtung einen neuen Dialog starten.
Beim Melden eines Bugs alle fünf Dinge angeben: Gerät / Seite, Schritte, tatsächliches Verhalten, erwartetes Verhalten, Reproduzierbarkeit (kann Screenshot oder Bildschirmaufnahme beifügen).
Phase 4: Vorschau und Gerätetest
Fünf Punkte Abnahme (offizielle Liste, jeden Punkt einzeln protokollieren):
- Kann normal gestartet werden?
- Entspricht die Steuerung den Erwartungen (inkl. Touch-Bereiche, Knöpfe klickbar)?
- Sind Erfolg / Misserfolg / Neustart vollständig?
- Ist das Bild auf dem Zielgerät klar (Schriftgröße, Kontrast, Sicherheitszone)?
- Gibt es Probleme, die den Ablauf blockieren?
Geräte und Freigabe:
- Desktop-Vorschau kann auf PC / Handy / Tablet und Auflösung umgeschaltet werden (inkl. Dynamic Island Abdeckung des iPhone 17, die das Klicken in diesem Bereich blockiert).
- Echtes Gerät: „Teilen“ in der Vorschau-Symbolleiste → Link / QR-Code; vor dem Erstellen einer Freigabeseite muss im Veröffentlichungs-Panel ein fertig zertifizierter Veröffentlichungsanbieter ausgewählt sein.
- QR-Code für Gerätetest: „Auf dem Handy testen“ → „Testversion aktualisieren“ → QR-Code scannen; nach Änderungen an Code / Ausrichtung / Konfiguration / Assets muss die Testversion neu aktualisiert werden, sonst wird die alte Version gescannt.
- Beim Wechsel zwischen Hoch- und Querformat muss die KI gleichzeitig das Interface-Layout und die Projektausrichtungskonfiguration ändern; nach der Änderung neu erstellen und in der Vorschau / auf dem echten Gerät Tasten, Text und Touch-Eingabe überprüfen.
Wird die Abnahme nicht bestanden, zurück zu Phase 3, um eine Vier-Teil-Anforderung zu schreiben, nicht direkt zur Veröffentlichung springen.
Phase 5: Veröffentlichungsvorbereitung
Materialliste (jedes einzeln prüfen):
- Spiel-Icon
- Mindestens 3 Spiel-Screenshots
- Werbebild, horizontales Cover, vertikales Cover
- Für Hochformat-Spiele zusätzlich ein quadratisches Werbebild
- Spielname
- Spielbeschreibung ≥ 10 Zeichen
- „Worte des Entwicklers“ ≥ 10 Zeichen
- Für die erste offizielle Veröffentlichung erforderliches echtes Gerätetest-Video
Ablauf: Asset-Generierung (verbraucht Credits, benötigt explizite Zustimmung des Benutzers) → Prüfung im Veröffentlichungs-Panel → Testversion aktualisieren und per QR-Code erneut prüfen → Offizielle Veröffentlichung.
- Bei mehreren Veröffentlichungsanbietern zuerst den Anbieter auswählen; der Veröffentlichungsbutton ist erst verfügbar, nachdem die Asset-Generierungsphase abgeschlossen ist.
- Aktionen im Veröffentlichungs-Panel verbrauchen selbst keine Erstellungs-Credits.
- Gesundheitscheck vor der Veröffentlichung siehe ./references/06-iteration-and-acceptance.md (6 Punkte vor der Veröffentlichung, 6 Datenprüfungen).
- Prüfbefehl:
python ./scripts/check_publish_materials.py materials.json --root <Projektstamm>.
Phase 6 (Querschnitt): Kosten- und Sicherheitsschutz
In jeder Phase auszuführen:
- Credits: Ohne explizite Aufforderung des Benutzers im Dialog keine creditverbrauchenden Generierungstools aufrufen; vor hohem Verbrauch erklären, „was es kostet, wie viel ungefähr, ob es günstiger geht“; Modelle oder Kanäle nicht automatisch wechseln.
- Keine Wiederholung bei unbekanntem Ergebnis: Wird nach einer Einreichung kein klares Ergebnis erhalten → als unsicher markieren, zuerst den Status prüfen; falls eine Wiederholung notwendig ist, muss der Benutzer zustimmen und darüber informiert werden, dass möglicherweise bereits Kosten angefallen sind.
- Anmeldeinformationen: Nicht anzeigen, nicht stellvertretend eingeben, nicht in Projektdateien oder Git speichern; nur vertrauenswürdigen Clients Autorisierung erteilen.
- Irreversible Aktionen: Assets löschen oder überschreiben, Modell ersetzen, Kanal wechseln, Konfiguration löschen, offizielle Veröffentlichung – zuerst anhalten, die Konsequenzen und Rückgängigmachungsmöglichkeit erklären, dann ein explizites „Ja“ einholen.
- Umfang: Nur innerhalb des Konzepts aufbauen; neue Systeme oder Spielmechaniken nur nach Zustimmung hinzufügen; Benutzerdateien nicht eigenmächtig verschieben oder löschen.
- Atomares Schreiben (beim Schreiben von Dateien durch Skripte oder Tools): Temporäre Datei + Umbenennung; leere Werte überschreiben keine vorhandenen Werte; beschädigte Dateien separat speichern zur Beweissicherung.
Details siehe ./references/08-safety-and-credentials.md und ./references/02-credits-and-cost.md.
Phasenbericht
Vor dem Betreten der nächsten Phase mit ./assets/stage-report-template.md die vier Blöcke ausgeben: Was in dieser Phase getan wurde / Liefergegenstände / Validierungsergebnisse / Nächste Schritte und Punkte, die du bestätigen musst. Am Ende des Berichts muss eine beantwortbare Bestätigungsanfrage stehen.
Wartung und Aktualität
- Datum des Wissensstands dieser Fertigkeit: 2026-11-03. Das Produkt wird schnell weiterentwickelt. Bei Funktionen, Parametern, Modellen, Preisen, Limits gilt immer die Online-Dokumentation.
- Konfliktbehandlung: Online-Dokumentation > Diese Fertigkeit. Bei Inkonsistenzen nach der Online-Dokumentation handeln und im Antworttext auf die Abweichung hinweisen.
- Aktualisierungsmethode: Zuerst https://maker.taptap.cn/llms.txt lesen, um die entsprechende Seite zu finden; wenn der Originaltext benötigt wird, die entsprechende .md-Adresse als Klartext abrufen.
- Verbot von Erfindungen: Funktionen, Parameter, Modellnamen, Preise, Limits, die nicht in der Dokumentation stehen, immer antworten mit: „Die Dokumentation enthält dies nicht, ich werde es nachschlagen oder bitte die Seite als maßgeblich betrachten.“
Beispiel-Prompts
- „Ich möchte ein vertikales 2D-Ausweichspiel machen. Hilf mir bitte zuerst, den Weg zu sehen.“ → Phase 0 / 1.
- „Das ist mein Konzept (Anhang). Hilf mir, es aufzubauen.“ → Ab Phase 0, Phase für Phase bestätigen.
- „Wie werden Maker-Credits abgezogen? Wie viele kostet ein Bild?“ → Nur references/02 lesen, direkt antworten, nicht in den Workflow einsteigen.
- „Ist der Unterschied zwischen einer L2-Pass-Rate von 60% und 63% in der Rangliste groß?“ → Nur references/04 lesen, Konfidenzintervall und Rangbereich erklären.
- „Mache den Startbildschirm mit dem Astroon-Design, rühre nicht an der Spielmechanik.“ → Phase 3, Vier-Teil-Anforderung schreiben.