Anleitungen / Bauen & Ressourcen
Bedrock hat kein eigenständiges Cape-Paket — ein Cape wird nur zusammen mit einem Skin ausgeliefert
Es gibt kein reines Cape-.mcpack-Format. Jedes Cape muss mit einem Skin-Eintrag kombiniert werden, der es benennt. Deshalb ist ein Cape-Paket in Wahrheit ein Skin-Paket mit einer zusätzlichen PNG pro Eintrag.
In Java ist ein Cape etwas Getrenntes von einem Skin. In Bedrock ist das nicht so: es gibt kein Cape-Paket-Format. Ein Cape ist ein Feld eines Skin-Eintrags, wer also ein Cape verteilen will, verteilt einen Skin, der es trägt.
Was das erzwingt
Ein Cape-Paket ist ein Skin-Paket, dessen Einträge jeweils eine Cape-Textur benennen. Das Manifest, die skins.json und die Lang-Datei sind identisch mit denen jedes anderen Skin-Pakets — der einzige Unterschied ist ein zusätzlicher Schlüssel pro Eintrag und eine zusätzliche PNG in der Zip-Datei.
Die Folgen sind struktureller, nicht kosmetischer Natur:
- Man kann ein Cape nicht allein ausliefern. Jedes Cape braucht einen Skin, an dem es hängt, selbst wenn dieser Skin einen nicht interessiert.
- Ein Cape ist im Spiel nicht unabhängig auswählbar. Wer das Cape auswählt, wählt den Skin-Eintrag, zu dem es gehört. Zwei Capes auf einem Skin lässt sich schlicht nicht ausdrücken.
- N Skins × M Capes ergibt N × M Einträge, nicht N + M. Drei Capes auf vier Skins bedeutet zwölf Einträge im Paket, jeder mit eigenem Schlüssel, eigenem Namen in der Lang-Datei und eigenem PNG-Paar.
Der letzte Punkt ist der, der bei wachsenden Paketen wehtut. Cape-Pakete werden schnell groß, und die Größe wächst multiplikativ statt additiv.
Die beiden Texturen haben unterschiedliche Größen
Ein Skin ist 64 × 64 (oder legacy 64 × 32). Ein Cape ist immer 64 × 32. Sie sind nicht austauschbar. Der Builder lehnt einen 64 × 64 großen Skin ab, der in den Cape-Slot geworfen wird, aber umgekehrt rutscht es durch: Ein 64 × 32 großes Cape im Skin-Slot wird als Legacy-Skin gelesen — also halte die beiden selbst auseinander.
Innerhalb dieser 64 × 32 großen Cape-Datei ist die sichtbare Fläche der 10 × 16 große Block bei (1, 1) — alles andere ist Rückseite, Kanten und Padding. Die Vorschau hier schneidet genau auf dieses Rechteck zu, wenn sie zeigt, welches Cape welches ist, denn in Vorschaugröße macht das umgebende Padding den Großteil des Bildes aus und sagt einem nichts.
Slim und Classic gelten weiterhin
Jeder Eintrag trägt sein eigenes Modell, das genauso erraten wird wie bei einem gewöhnlichen Skin-Paket — anhand der zwei Spalten, die ein Slim-Arm leer lässt (x 54–55, y 20–31) — und jeder Eintrag hat einen Classic/Slim-Umschalter für die Skins, bei denen diese Schätzung danebengeht, etwa bei einem Classic-Skin, der diese Spalten kaum bemalt. Ein Cape-Paket muss also auch pro Eintrag die Slim/Classic-Entscheidung richtig treffen — das Cape ändert nichts daran, wie die Arme gelesen werden, und ein falsches Modell zeigt sich hier genau wie überall sonst: ein Alex-Skin mit Steves Armen, der das richtige Cape trägt.
Praktische Form
Wenn das Ziel wirklich lautet „gebt den Leuten dieses Cape", dann ist das Paket eher ein Liefermechanismus als das Produkt. Kombiniere es mit dem schlichtesten Skin, der Sinn ergibt, benenne den Eintrag nach dem Cape statt nach dem Skin, und akzeptiere, dass ein Spieler, der es auswählt, beides wählt.
Wenn das Ziel eine Reihe aufeinander abgestimmter Looks ist — ein Skin und ein Cape, die zusammen entworfen wurden — dann ist Bedrocks Modell tatsächlich das richtige, und die Paarung, die wie eine Einschränkung wirkt, ist das Feature.