Den Skin eines Spiels anpassen

Ein Spiel wird mit einem Standard-Look ausgeliefert. Auf dem Skin-Tab des Spiel-Editors kannst du seine Farben überschreiben, seine visuellen Assets tauschen (Bilder, und wo das Spiel sie nutzt, Audio und Video) und alle Nicht-Farb-Regler setzen, die der Autor bereitgestellt hat (einen Schalter, eine Zahl, eine Wahl), sodass die Aufgabe zu deiner Marke passt, und die Änderung wird auf das gerenderte Spiel angewendet.

Skin-Anpassung ist ab dem Alpha-Tarif verfügbar (Alpha, Troop, Apex).

Farben, Assets und andere Regler setzen

Öffne das Spiel auf der Spiele-Seite eines Site-Keys (oder des Teams), dann den Skin-Tab. Der Tab zeigt die Slots, die der Autor des Spiels bereitgestellt hat. Die meisten sind Farben und Assets, aber ein Autor kann auch einen Schalter (an/aus), eine Zahl (oft mit einem Minimum und Maximum) oder eine Wahl aus einer festen Liste bereitstellen. Setz eine Farbe mit einem Hex- oder rgb()-Wert; setz ein Asset, indem du eine Datei hochlädst oder eine URL einfügst (siehe unten); setz die anderen Slots mit der gezeigten Steuerung. Lass einen Slot unberührt, und er behält den mitgelieferten Wert des Spiels.

Wie ein Skin zur Laufzeit gewählt wird

Jedes Preset deklariert den Modus, in dem es funktioniert: hell, dunkel oder any (es liest sich gut auf beiden Hintergründen). Es gibt einen Standard pro Modus, sodass das Spiel richtig aussieht, welchen Modus das Gerät des Besuchers auch bevorzugt. Ein als any markiertes Preset ist berechtigt, der Standard für hell, dunkel oder beides zu sein. Eines zu wählen passiert in zwei Stufen.

Zuerst entscheidet das Widget, welchen Skin es anfragt:

Das skin-Attribut des Widgets, wenn die Seite eines gesetzt hat: ein exakter Preset-Name (zum Beispiel midnight) oder die Abkürzung light / dark.
Sonst die Systempräferenz des Besuchers (prefers-color-scheme), die sich zu light oder dark auflöst.

Dann matcht der Server das gegen die Presets, nach dem Mergen deiner Overrides (Site-Key über Team über den mitgelieferten Satz des Spiels). Ein exakter Preset-Name im Attribut gewinnt rundheraus. Sonst nimmt der Server für den gewählten Modus das erste Preset, in Deklarationsreihenfolge, das für diesen Modus berechtigt und als Standard markiert ist (ein Preset ist berechtigt, wenn sein Modus dieser Modus oder any ist); ist keines als Standard markiert, nimmt er das erste berechtigte Preset.

Weil ein any-Preset für beide Modi berechtigt ist, kannst du einen Skin überall zum Standard machen, oder einem Modus einen dedizierten Skin geben und einen any-Skin den anderen abdecken lassen. Auf dem Skin-Tab erscheint ein any-Skin sowohl unter der Hell- als auch der Dunkel-Gruppe, und du setzt ihn als Standard für eine oder beide.

Auf dem <caputchin-game>-Element kannst du auch ein Inline-skin-Objekt übergeben: ein JSON-Objekt, geschrieben als Attributwert, zum Beispiel skin='{"primary":"#7c3aed"}'. Das Widget sendet es als Skin-Signal dieses Mounts an den Server, und der Server parst es und legt es über die aufgelösten Presets, sodass deine Inline-Farben und -Assets über allem oben gewinnen (einschließlich deiner Team- und Site-Key-Overrides). Es ist eine Eigenschaft deines eigenen Markups, also funktioniert es in jedem Tarif. Das Checkbox-<caputchin-widget> akzeptiert keinen Inline-Skin; sein skin-Attribut nimmt nur light / dark oder einen Preset-Namen. Sieh dir unsere Philosophie an, warum dieses Verfassen pro Einbettung kostenlos ist.

Assets: hochladen oder verlinken

Ein Asset-Slot (Bild, Audio oder Video) nimmt entweder eine hochgeladene Datei oder eine URL, die du einfügst:

Hochladen: Caputchin speichert einen Snapshot der Datei. Er ist eingefroren, also ändert er sich nicht, außer du lädst erneut hoch.
Verlinken: du fügst eine https-URL zu einer Datei ein, die du hostest. Sie ist live, also aktualisiert das Ersetzen der Datei unter dieser URL das Spiel beim nächsten Laden.

Weil das Spiel in einem gesandboxten Frame läuft, lädt ein verlinktes Asset nur, wenn sein Origin erlaubt ist. Caputchin erledigt das für dich: es erlaubt genau die Origins, auf die deine Skin-Presets zeigen, und nichts sonst. Du änderst keine Policy selbst.

Jeder Asset-Typ akzeptiert einen festen Satz Formate (zum Beispiel PNG, JPEG, WebP, SVG und GIF für Bilder). Die genauen Formate und die Farbregeln sind in der Schema-Referenz.

Was gilt und wo

Skin-Overrides lösen sich auf dem Server auf, am-spezifischsten-gewinnt: ein Site-Key-Preset schlägt das Team-Preset, das den mitgelieferten Skin des Spiels schlägt. Du kannst ein mitgeliefertes Preset erweitern und nur die Slots überschreiben, die du willst, und den Rest erben.

Wie ein Skin-Wert das Spiel erreicht

Der Server löst deinen Skin auf (deine Overrides über den mitgelieferten Satz gemerget) und reicht das Ergebnis an den eigenen Code des Spiels, der sich damit selbst zeichnet. Farben und Asset-URLs kommen als Text an; ein Schalter kommt als echtes true / false an, eine Zahl als echte Zahl, eine Wahl als der gewählte String. Der Autor des Spiels entscheidet, wie jeder Wert genutzt wird, also ist es dem Spiel überlassen, was ein Slot tatsächlich ändert. Du schreibst kein CSS fürs Spiel: es läuft in einem gesandboxten Frame, den du von deiner Seite nicht stylen kannst.

Die Widget-Hülle (die Caputchin-Chrome um das Spiel und die eigenständige Checkbox) ist anders: ihr aufgelöster Skin wird auch deiner Seite als CSS-Custom-Properties namens --cpt-skin-<token> bereitgestellt, die du aus deinem eigenen Stylesheet lesen oder überschreiben kannst. Diese Fläche, und wie man die Hülle per White-Label anpasst, ist in Das Widget mit CSS stylen behandelt. Diese Variablen gehören nur der Hülle; sie tragen nicht den Skin eines Spiels.

Siehe auch

Überblick zur Spiel-Anpassung: ein Spiel registrieren und verwalten.
Konfigurationen und Sprache: die anderen zwei Achsen.
Schema-Referenz: Farbregeln, Asset-Formate und das Preset-Modell.
Das Widget mit CSS stylen: die --cpt-skin-*-Variablen und Shadow-Parts der Hülle.