Die fünf Belege, die dein Spiel vor einer Clowdr-Veröffentlichung braucht

Bevor du einen Release Candidate einreichst, sollte eine andere Person prüfen können, warum das Spiel bereit ist. Verlinke den Build, die Beobachtungen und die Entscheidungen hinter jedem der Five Proofs of Release von Clowdr.

Ein Project ist Done, wenn seine genehmigten Tickets abgeschlossen, seine Release Blockers behoben und die Veröffentlichungsanforderungen im integrierten Spiel erfüllt sind. Anschließend reicht der Project Lead den Release Candidate ein. Clowdr entscheidet über die Veröffentlichung.

Die folgenden Anforderungen stammen aus How We Ship und dem genehmigten Clowdr Process. Die Belegsammlung ist ein Vorschlag, wie du sie anwenden kannst. Alle Beispiele zum Obstgarten-Spiel in diesem Leitfaden sind hypothetisch, keine Beobachtungen aus einem Clowdr Project.

Beginne mit einem eindeutig bezeichneten Kandidaten

Gib dem eingereichten Build eine Kennung, etwa einen Release-Tag mit Commit. Halte die genehmigte Player Promise, den Feature Scope und die Quality Baseline daneben bereit. Jeder Beleg sollte auf den tatsächlich geprüften Build oder das geprüfte Artefakt verweisen, mit Datum, Bedingungen, verantwortlicher Person, Ergebnis und Grenzen der Prüfung.

Wenn du nach einem Test einen Blocker behebst, halte die Änderung fest und wiederhole die betroffenen Prüfungen. Eine Beobachtung zu einem älteren Build braucht eine nachvollziehbare Begründung, damit sie für den eingereichten Kandidaten relevant bleibt.

1. Promise Proof: erfülle das genehmigte Spielerlebnis

Promise Proof prüft, ob das vollständige Spiel die genehmigte Player Promise erfüllt. Verbinde dieses Versprechen mit Playtest-Beobachtungen zum vorgesehenen Erlebnis, einschließlich seines Endes. Eine funktionierende Mechanik deckt nur einen Teil dieses Belegs ab.

Playtesting ist Pflicht. Clowdr schreibt keine universelle Zahl an Testern und keine allgemeingültige Abdeckungsformel vor. Halte fest, wer gespielt hat, was die Person ausprobiert hat, wo du geholfen hast und was sie tun konnte oder nicht konnte. Erkläre, was ungewiss bleibt.

Hypothetisches Beispiel: Ein Obstgarten-Puzzlespiel verspricht ein kurzes, ruhiges Erlebnis, bei dem Spieler entscheiden, wie sie Wasser leiten. Ein hilfreicher Playtest-Bericht würde zeigen, ob eine Person die Entscheidungen verstand, das Ende erreichte und das vorgesehene Tempo erlebte. Hat der Lead jedes Rätsel mündlich erklärt, gehört dieser Eingriff in den Bericht. Er begrenzt die Aussagekraft der Sitzung über die Anleitungen im Spiel.

2. Build Proof: prüfe den kritischen Pfad auf jeder genannten Plattform

Build Proof prüft, ob der kritische Pfad auf jeder Plattform funktioniert, die du als unterstützt angibst. Halte Plattform und Testumgebung bei jedem Ergebnis fest. Prüfe den ausgelieferten Build anhand der Aktionen, die nötig sind, um das Spiel abzuschließen.

Beim hypothetischen Obstgarten-Spiel könnte dieser Pfad so aussehen: starten, ein Spiel beginnen, die Steuerung lernen, die Rätsel lösen, das Ende erreichen und ins Menü zurückkehren. Beziehe Speichern oder Laden ein, wenn diese Aktionen zum genehmigten Scope gehören. Eine erfolgreiche Sitzung im Editor belegt nicht, dass ein heruntergeladener Build funktioniert.

Hypothetisches Beispiel: Eine Desktop-Prüfung würde keine Browser-Kompatibilität belegen. Wenn beide als unterstützte Plattformen genannt sind, brauchst du Belege für beide. Ein defektes Spielende bleibt ein Release Blocker, selbst wenn alle Implementierungstickets geschlossen sind.

3. Craft Proof: vergleiche das ganze Spiel mit der Quality Baseline

Craft Proof prüft, ob das vollständige Spiel die genehmigte Quality Baseline erreicht oder übertrifft, ohne Platzhalter oder Unowned Output. Nutze den genehmigten Vertical Slice als Referenz und prüfe den Rest des integrierten Spiels auf denselben Standard an Stimmigkeit und Ausarbeitung.

Prüfe die Grafik in der Größe, in der sie beim Spielen erscheint: Können Spieler einen Wasserweg, ein Hindernis und ein dekoratives Objekt unterscheiden? Prüfe Audio während des Spielens: Setzen Signale korrekt ein, laufen Schleifen sauber und stoppen sie zum richtigen Zeitpunkt? Ist notwendiges Feedback hörbar? Prüfe Design und Texte gemeinsam: Stimmen Anleitungen mit den Regeln und den tatsächlich verfügbaren Entscheidungen überein?

Hypothetisches Beispiel: Eine angenehme Musik, die Rätsel-Feedback überdeckt, braucht eine Prüfung des Mixes im Spiel und eine dokumentierte Korrektur. Ein einzelner Audioexport zeigt nicht, ob die Musik den Spieler in dieser Szene unterstützt.

Benenne die Person, die einen Beitrag erklären, überarbeiten, integrieren, im Kontext prüfen und sauber übergeben kann. Für AI-gestützte und bewusst ohne AI erstellte Arbeit gilt dieselbe handwerkliche Anforderung.

4. Ownership Proof: erfasse die Arbeit und ihre Herkunft

Ownership Proof umfasst Contributions, Herkunft, Rechte, AI-Disclosures, Attributions und Credits. Verknüpfe diese Aufzeichnungen mit dem, was im Kandidaten tatsächlich enthalten ist. Der Lead pflegt die Credit-Liste. Gleiche sie mit den angenommenen Beiträgen ab, einschließlich Grafik, Audio, Texten, Tests und Produktionsarbeit.

Hypothetisches Beispiel: Für einen finalen Obstgarten-Sprite sollten ein nachvollziehbarer Beitragsnachweis, seine Quelle und die zugehörigen Rechteinformationen, notwendige Attributions oder AI-Disclosures sowie der Credit der mitwirkenden Person vorliegen. Eine ungeklärte Rechtefrage gehört in die Blocker-Liste. Die Annahme, jemand anderes habe sie bereits geprüft, reicht nicht.

Der Release Candidate braucht außerdem eine Final AI Production Note. Überführe die im Pitch geplante AI-Position in das, was tatsächlich passiert ist:

• Tatsächliche AI-Nutzung oder bewusste Nichtnutzung und die Bereiche, in denen diese Entscheidung relevant war.
• Wesentliche menschliche Entscheidungen, einschließlich Änderungen oder verworfener Ergebnisse.
• Durchgeführte Verifikation und die dazugehörigen Belege.
• Herkunft, Rechte, erforderliche Disclosures und Attributions.
• Wesentliche Änderungen gegenüber der Pitch Note.

Bewahre bei Bedarf detaillierte Nachweise auf. Eine kompakte Fassung der Note wird mit jedem Clowdr Release veröffentlicht. Auch die bewusste Entscheidung gegen AI-Nutzung braucht eine ehrliche finale Note.

5. Publication Proof: präsentiere den Kandidaten korrekt

Publication Proof prüft, ob Spiel und Veröffentlichungsmaterialien bereit sind, unter der Clowdr-Marke zu erscheinen. Gleiche Beschreibung, Screenshots, Anleitungen, unterstützte Plattformen, Credits, Disclosures und die öffentliche Production Note mit dem eingereichten Kandidaten ab.

itch.io ist das Standardziel für die Veröffentlichung. Ein Lead kann ein anderes Ziel beantragen, wenn die Kompatibilität nachgewiesen ist. Lege die zielspezifischen Belege zur Einreichung.

Hypothetisches Beispiel: Wenn die Seite des Obstgarten-Spiels eine Browser-Version verspricht, belegt ein reiner Desktop-Download diese Aussage nicht. Halte die Abweichung fest, damit sie vor der Veröffentlichung geklärt wird. Ein Screenshot sollte das tatsächliche Spielerlebnis des Kandidaten zeigen, statt eine Funktion außerhalb des genehmigten Scope anzudeuten.

Bereite fünf Belege für die Publication Review vor

Schreibe für jeden Proof einen kurzen Eintrag nach diesem Muster:

Proof: Welche Anforderung wird geprüft?

Kandidat und Artefakt: Build-Kennung und Links zu den relevanten Aufzeichnungen.

Verantwortung und Prüfung: Wer hat was, wann und unter welchen Bedingungen geprüft?

Ergebnis: Was hat die Prüfung belegt?

Grenzen und offene Arbeit: Was blieb ungeprüft, und sind noch Blocker offen?

Ein Playtest kann mehrere Proofs unterstützen. Erkläre seine Aussagekraft für jeden einzelnen. Füge die Final AI Production Note und die Veröffentlichungsmaterialien bei, damit die prüfende Person die vollständige Einreichung bewerten kann.

Die Publication Review von Clowdr hat drei mögliche Ergebnisse:

• Accepted: Clowdr veröffentlicht das Spiel unter seiner Marke, standardmäßig auf itch.io.
• Revision Required: Clowdr benennt korrigierbare Blocker. Das Project bleibt auf seinem Veröffentlichungsweg.
• Publication Declined: Clowdr entscheidet endgültig, das Spiel nicht unter seiner Marke zu veröffentlichen.

Ein Independent Release erfordert sowohl Publication Declined als auch eine ausdrückliche schriftliche Independent Release Authorization und eine projektspezifische Unterlizenz von Freistil ApS. Schweigen, Verzögerung, Revision Required, Änderungen der Mitgliedschaft oder eine unvollständige Review erteilen keine Independent-Release-Berechtigung. Die Autorisierung schließt die Clowdr-Marke, Accounts, Markenrechte und Storefront-Präsenz aus und bewahrt Credits, Attributions, Disclosures und bestehende Lizenzen.

Beginne die Belegsammlung, bevor das letzte Ticket geschlossen wird. Benenne für jeden fehlenden Proof die Lücke und die nötige Arbeit innerhalb des genehmigten Scope. So erhält der Lead einen konkreten Weg zu einem Release Candidate, den Clowdr bewerten kann.