Custom-Spiel-Dashboard-Schema
Ein Marketplace-Spiel liefert ein caputchin.json-Manifest, das deklariert, welche Felder jedes Anpassungs-Preset setzen darf. Ein Custom-Spiel hat kein Manifest, also deklarierst du dieses Feld-Schema stattdessen im Dashboard. Du definierst es einmal pro Custom-Spiel, pro Achse, und verfasst dann Presets dagegen; von dort löst es sich auf und wird angewendet genau wie ein Marketplace-Spiel auf denselben Tarifstufen.
Diese Seite ist die Referenz für dieses Schema. Zum Verfassen des Spiels selbst sieh dir ein selbst gehostetes Spiel bauen an; für den kundenseitigen Registrierungs-Flow sieh dir Custom-Spiele an.
Ein Schema pro Achse
Das Schema eines Custom-Spiels wird pro Achse deklariert, und die drei Achsen sind unabhängig:
| Achse | Was es anpasst | Schema |
|---|---|---|
| Locale | Die übersetzten Strings des Spiels. | Implizit: Locale-Felder sind immer reiner Text, also gibt es nichts zu deklarieren; du verfasst String-Presets direkt. |
| Skin | Farben, visuelle Assets und Präsentations-Regler. | Du deklarierst die Farb-, Asset- und Skalar-Felder (Schalter / Zahl / Range / Wahl), die ein Skin-Preset setzen darf. |
| Konfiguration | Gameplay-Optionen (Schwierigkeit, Anzahlen, Schalter). | Du deklarierst die Options-Felder, die ein Konfigurations-Preset setzen darf. |
Du definierst ein Schema nur für die Achsen, die dein Spiel tatsächlich nutzt. Eine Achse ohne Schema hat einfach keine anpassbaren Felder dieser Art.
Feldtypen
Ein Schema ist ein Satz benannter Felder, jedes mit einem Typ. Die Feldtypen sind derselbe Satz, den der Rest der Anpassung nutzt; die Anpassungs-Schema-Referenz ist die maßgebliche Beschreibung jedes Typs und der Werte, die er akzeptiert. Kurz:
| Typ | Wert |
|---|---|
string | Freier Text. |
boolean | true oder false. |
number | Jede endliche Zahl. |
range | Eine Zahl innerhalb eines Min und Max. |
list | Eine aus einem festen Satz Optionen. |
link | Eine http/https-URL. |
color | Eine Hex- oder rgb()-Farbe. |
image | Eine Bild-URL oder ein Upload. |
audio | Eine Audio-URL oder ein Upload. |
video | Eine Video-URL oder ein Upload. |
Locale nutzt nur string (und der Resolver validiert ein Locale-Schema überhaupt nicht). Skin und Konfiguration validieren verfasste Werte gegen das Schema, das du deklarierst, und verwerfen Werte, die nicht zu ihrem Typ passen.
Geltungsbereich: wo ein Schema lebt
Ein Custom-Spiel-Schema wird auf einem Geltungsbereich gesetzt, Team oder Site-Key, dasselbe Geltungsbereich-Modell wie Overrides. Wenn sowohl ein Team als auch einer seiner Site-Keys ein Schema für dasselbe Spiel und dieselbe Achse deklarieren, ersetzt das Schema des Site-Keys das des Teams für diese Achse (eine Ganz-Achsen-Ersetzung, kein Feld-für-Feld-Merge). Das spiegelt, wie der Rest der Anpassung sich am-spezifischsten-gewinnt auflöst.
Assets sind absolut
Weil du das spielbare Spiel selbst hostest, gibt es kein Plattform-Bundle, gegen das ein relativer Asset-Pfad aufgelöst würde. Jeder image-, audio- oder video-Wert in einem Skin-Preset muss eine absolute URL sein. (Ein Marketplace-Spiel kann bundle-relative Pfade nutzen; ein Custom-Spiel kann es nicht.)
Wie ein Preset das Spiel erreicht
Sobald das Schema und die Presets existieren, löst Caputchin ein Preset pro Achse für jeden Besucher auf (am-spezifischsten-gewinnt über Site-Key, Team und deine Standards) und stellt die aufgelösten Werte deinem Spiel durch den Kontext der Spiel-Factory zu: ctx.locale, ctx.skin, ctx.config. Dein Spiel liest seine eigenen Feldnamen von diesen Objekten ab. Das Schema ist es, was den Dashboard-Editor die richtigen Eingaben zeigen lässt und was die Werte validiert, bevor sie je einen Besucher erreichen.
Siehe auch
- Anpassungs-Schema-Referenz: jeder Feldtyp und seine akzeptierten Werte, in voller Länge.
- Custom-Spiele: ein Custom-Spiel registrieren und sein Schema definieren.
- Ein selbst gehostetes Spiel bauen: die aufgelösten Presets aus dem Factory-Kontext lesen.
- Team-Overrides: das Geltungsbereich-Modell, dem das Schema folgt.