Cocos Creator Mini-Spiel: Launch-Checkliste vor Veröffentlichung – Performance, Paketgröße, Kompatibilität und Review

Am Tag meiner ersten Review-Einreichung starrte ich auf das Popup „Review abgelehnt“ – mein Kopf summte. Paket zu groß: Das Hauptpaket hatte 6,8 MB, WeChat erlaubt hart 4 MB. Drei Tage lang optimierte ich – Texturkompression, Audio-Transcoding, Engine-Modul-Trimming – bis das Paket auf 3,2 MB sank und durchging.

Diese Erfahrung zeigte mir: Launch-Checks sind kein Glücksspiel. Es gibt konkrete Kennzahlen und klare Testmethoden. Später packte ich alle Stolpersteine in eine Checkliste und hake vor jeder Einreichung Punkt für Punkt ab. Inzwischen ist sie über zehn Iterationen gereift – 15 Checks in vier Modulen: Performance, Paketgröße, Kompatibilität und Review.

In diesem Artikel teile ich diese Checkliste. Jeder Punkt hat Zahlen, Tools und typische Fallstricke. Damit können Sie systematisch prüfen und die Chance auf Freigabe beim ersten Versuch deutlich erhöhen.

1. Performance-Check: Ruckler killen die Erfahrung

Performance ist einer der Hauptgründe für Spieler-Abbrüche. Auf Ihrem Testgerät läuft alles flüssig – aber echte Nutzer nutzen oft drei Jahre alte Smartphones. Zwischen iOS High-End und Low-End liegt ein Faktor von 3–4 – kein Scherz.

1. FPS-Stabilität

Standard: High-End (iPhone X und neuer) Ziel 60 FPS, Low-End (iPhone 6s/7/8) Ziel 30 FPS. Spitzenwerte mindestens 80 % des Ziels – High-End also mindestens 48 FPS, Low-End mindestens 24 FPS.

Methode: Cocos Creator zeigt FPS eingebaut; in cc.macro aktivieren:

// FPS in der Entwicklungsphase anzeigen
cc.macro.SHOW_FPS = true;

Alternativ Stats.js – übersichtlicher. Im Performance-Panel der WeChat-Entwicklertools sehen Sie die FPS-Kurve live.

Kennzahlen:

• High-End stabil 55–60 FPS
• Low-End stabil 28–32 FPS
• Spitzen-Schwankung maximal 20 %

Typische Probleme: Zu viele DrawCalls, ruckelnde Szenenwechsel, viele Partikel gleichzeitig. In einem Projekt explodierten beim Boss-Tod 200 Partikel – Low-End fiel auf 15 FPS. Mit 50 Partikeln plus Easing sah es besser aus.

Selbsttest: iPhone 7, 10 Minuten Echtlauf. Schwankt die Linie um 30 FPS – ok. Häufig unter 20 FPS – nachforschen.

2. Speicherpeak

Standard: iOS begrenzt Speicher hart. Low-End (iPhone 6s/7/8) Obergrenze 1 GB, High-End (iPhone X/XR/11) 1,4 GB. Peak maximal 70 % des Limits – Low-End unter 700 MB, High-End unter 1 GB.

Methode:

• WeChat-Entwicklertools: „Debugger – Memory“, Speicherkurve sichtbar
• Safari Remote Debugging: Gerät am Mac, Gerät im Safari-Entwicklermenü wählen

// Speichernutzung regelmäßig ausgeben
const memoryInfo = cc.sys.getMemoryInfo();
console.log('Aktueller Speicher: ' + memoryInfo.used + 'MB');

Kennzahlen:

• Low-End-Peak ≤700 MB
• High-End-Peak ≤1000 MB
• Absturzrate unter 2 % (ein Projekt: von 15 % auf 2 % nach Optimierung)

Typische Probleme: Doppelte Texturen, Ressourcen nicht freigegeben, zu große Atlanten. Cocos empfiehlt Atlanten idealerweise ≤1024×1024 – größere Atlanten sprengen auf Low-End den Speicher.

Selbsttest: Auf Low-End 20-mal dieselbe Szene betreten und verlassen. Steigt die Kurve dauerhaft – Leck.

3. DrawCall-Anzahl

Standard: DrawCalls treiben die Render-Last. Pro Frame: mehr DrawCalls, mehr GPU-Druck. Startbildschirm maximal 100, im Spiel maximal 200.

Methode: Im Cocos-Panel „Build & Publish“ Render-Statistik aktivieren – DrawCalls zur Laufzeit sichtbar.

// Aktuelle DrawCall-Anzahl anzeigen
const stats = cc.game._renderStats;
console.log('DrawCall: ' + stats.drawCalls);

Kennzahlen:

• Startbildschirm ≤100
• Im Spiel ≤200
• Peak maximal 350 (Extremszenen etwas lockerer)

Typische Probleme: Kein Atlas, Dynamic Atlas aus, zu viel BMFont. Ein Projekt hatte 350 DrawCalls – nach Atlas-Pack und BMFont→TTF nur noch 120.

Optimierung:

• Statischer Atlas: TexturePacker, weniger Fragmente
• Dynamic Atlas: in Cocos standardmäßig an; Texturgröße unter 2048 halten
• BMFont: wenn möglich TTF – jedes BMFont-Zeichen ist ein DrawCall

4. Ladezeit Startbildschirm

Standard: Lädt der Startbildschirm länger als 3 Sekunden, steigt die Abbruchrate um 7 % – Branchendaten. WeChat Cloud-Test: Bei 3,5 MB Paket oft 4500–9000 ms bis zum Start – in diesem Bereich steigt die Abbruchrate spürbar.

Methode:

• WeChat-Entwicklertools: „Details – Lokaler Code“ zeigt Paketgröße
• WeChat Cloud-Test: echtes Netz, echte Ladezeit

// Ladezeit Startbildschirm messen
const startTime = Date.now();
cc.director.loadScene('game', () => {
  const loadTime = Date.now() - startTime;
  console.log('Startbildschirm: ' + loadTime + 'ms');
});

Kennzahlen:

• Start-Render ≤3000 ms (ideal ≤1500 ms)
• Fortschrittsbalken sichtbar ≥80 % (Nutzer warten geduldiger)

Typische Probleme: Zu viele Assets in der ersten Szene, keine Subpackages, alles aus resources. Bei mir: drei Charaktere, zwei Hintergründe, viel UI – 5 Sekunden. Lösung: ein Loading-Bild plus Subpackage-Laden – 2 Sekunden.

Optimierung:

• Erste Szene: nur Hintergrund plus Fortschrittsbalken
• Erste Szene als Subpackage markieren
• Unnötiges remote laden

2. Paketgröße: Die 4-MB-Hürde

WeChat-Mini-Spiele: Hauptpaket hart 4 MB, Gesamtpaket (inkl. Subpackages) maximal 16 MB. Roter Strich – Überschreitung, sofort abgelehnt. Mein Fall: 6,8 MB Hauptpaket, drei Tage bis 3,2 MB.

5. Hauptpaketgröße

Standard: Hauptpaket ≤3,8 MB. Warum 200 KB Puffer? Beim Build entstehen dynamische Dateien; WeChat misst manchmal leicht abweichend. Reserve schafft Luft.

Methode: Nach dem Build in den WeChat-Entwicklertools „Details – Lokaler Code“ – exakte Größe.

Kennzahlen:

• Hauptpaket ≤3,8 MB (Sicherheitslinie)
• Hauptpaket ≤4,0 MB (rote Linie – muss unterschritten werden)

Typische Probleme:

• Zu viel in resources – alles landet im Hauptpaket
• Engine-Module nicht getrimmt – Cocos packt standardmäßig alles
• Große npm-Abhängigkeiten ungeprüft

Selbsttest: Vor dem Build resources prüfen, Unnötiges verschieben. Unter „Projekteinstellungen – Module“ ungenutzte Module abwählen.

// Beispiel Modul-Trimming (project.json)
{
  "modules": [
    "base",
    "2d",
    "ui",
    "audio"
  ],
  // Nicht benötigte Module nicht aktivieren, z. B.:
  // "physics" – keine Physik-Engine
  // "tween" – kein Tween-System
}

6. Gesamtpaketgröße

Standard: Gesamtpaket (Haupt + Subpackages) maximal 16 MB. Subpackages können remote geladen werden – Geschwindigkeit hängt vom Netz ab; Kerninhalt bleibt in Haupt- und Start-Subpackages.

Methode: Build-Log zeigt Größe pro Subpackage – Summe = Gesamtpaket.

Kennzahlen:

• Gesamtpaket ≤15 MB (Sicherheitslinie)
• Gesamtpaket ≤16 MB (rote Linie)

Subpackage-Strategie:

• Kern (Haupt + Start-Subpackage) <10 MB
• Feature-Pakete (Nebenspielmodi) 20–50 MB
• Szenen-Pakete (remote) 30–100 MB

Typisches Problem: Start-Subpackage zu groß – alle Charaktermodelle dort, Nutzer warten 8 Sekunden auf Download.

7. Ressourcen-Kompression

Standard: Texturen, Audio und Schriftarten dominieren das Paket. Praxis: Texturen ~45 %, Audio ~25 %, Fonts ~15 %. Gute Kompression halbiert das Paket oft.

Methode: Originalgröße vs. Build-Größe vergleichen.

Kennzahlen:

• PNG → JPG (ohne Alpha): −50–70 %
• WAV → OGG: −65–70 %
• Font-Subsetting (fontmin): −80–90 %

Tools:

• TinyPNG: PNG-Kompression im Browser
• TexturePacker: Atlas plus Kompression
• Audacity: WAV nach OGG
• fontmin: nur genutzte Zeichen

Typische Probleme:

• Hintergrund als PNG ohne Transparenz → JPG
• Audio als WAV → OGG
• Vollfont 10 MB+ → Subset oft ~100 KB

Selbsttest: Eine PNG mit TinyPNG – 500 KB Hintergrund wird oft ~150 KB.

8. Subpackage-Konfiguration

Standard: Subpackage-Strategie darf den Start nicht blockieren. Erste Szene als Subpackage; Unnötiges nicht ins Hauptpaket.

Methode: Ladereihenfolge und Abhängigkeiten der ersten Szene prüfen.

Kennzahlen:

• Erste Szene als Subpackage: ja
• Ladezeit erste Szene: ≤3000 ms
• Unnötige Assets nicht im Hauptpaket: resources checken

Typische Probleme:

• Erste Szene referenziert Assets außerhalb des Hauptpakets – Subpackage-Download vor Start nötig
• Subpackages nicht nach Spiellogik getrennt
• Falscher Ladezeitpunkt – weitere Subpackages schon auf dem Loading-Screen starten

// Subpackage-Laden Beispiel
cc.assetManager.loadBundle('level-pack', (err, bundle) => {
  if (err) {
    console.error('Subpackage-Laden fehlgeschlagen', err);
    return;
  }
  bundle.loadScene('level-1', (err, scene) => {
    cc.director.runScene(scene);
  });
});

Selbsttest: Unter 4G Subpackage-Geschwindigkeit testen. Start-Subpackage >5 Sekunden – Strategie überdenken.

3. Kompatibilität: Kein Fail auf einem Gerät

Kompatibilität wird leicht unterschätzt. Auf Ihrem Testgerät läuft alles – nach Launch Beschwerden: UI verdeckt, hässliche Ränder, falscher Layout nach Rotation. Systematisch testen, nicht nur ein Gerät.

9. Display-Anpassung

Standard: Design-Auflösung, Anpassungsstrategie, Letterboxing. Portrait: 720×1280 (9:16) oder 750×1334; Landscape umgekehrt.

Methode: Mindestens drei Seitenverhältnisse auf Echtgeräten:

• 16:9 (klassisch, viele Android-Geräte)
• 18:9 (moderne Xiaomi/Huawei)
• 19,5:9 (iPhone X-Serie, Notch)

Kennzahlen:

• Design: 720×1280 oder 750×1334
• Strategie: Portrait Höhe fixieren, Landscape Breite fixieren
• Ränder: keine oder gleichmäßig

Schlüsselcode:

// Portrait: Höhe fixieren
cc.view.setDesignResolutionSize(720, 1280, cc.ResolutionPolicy.FIXED_HEIGHT);

// Landscape: Breite fixieren
cc.view.setDesignResolutionSize(1280, 720, cc.ResolutionPolicy.FIXED_WIDTH);

// Sichtbarer Bereich
const visibleSize = cc.view.getVisibleSize();
console.log('Sichtbarer Bereich: ' + visibleSize.width + 'x' + visibleSize.height);

Typische Probleme:

• Falsche Strategie: Portrait mit Breiten-Fix → schwarze Balken oben/unten
• Widget schlecht gesetzt – Knoten folgen nicht dem Rand
• Design zu breit – auf manchen Geräten abgeschnitten

Selbsttest: Widget für kritische UI an den Rand pinnt – z. B. Münzanzeige oben rechts, auf allen Verhältnissen stabil.

10. Notch / Punch-Hole

Standard: Safe Area – kritische UI nicht verdeckt. iPhone-Notch, Android-Tropfen- und Punch-Hole-Displays nehmen oben Platz weg.

Methode: iPhone X/XR/11-Serie; Android-Notch (Huawei Mate, Xiaomi High-End).

Kennzahlen:

• Kritische UI Abstand oben ≥50 px
• Kritische UI Abstand unten ≥50 px (virtuelle Home-Taste)
• Safe Area: SafeArea-API nutzen

Anpassung:

// iOS Safe Area
const safeArea = cc.sys.getSafeArea();
const topPadding = safeArea.top;
const bottomPadding = safeArea.bottom;

// Knoten anpassen
this.topNode.y = -topPadding;
this.bottomNode.y = bottomPadding;

Oder Widget mit dynamisch aus Safe Area gelesenen Abständen.

Typische Probleme:

• Titel unter dem Notch
• Unten Button unter Home-Indikator – Klick überlappt
• Android-Punch-Hole pro Hersteller anders positioniert

Selbsttest: WeChat-Simulator „iPhone X“, dann Android-Notch-Echtgerät.

11. Gerätekompatibilität

Standard: Gängige Geräte abdecken; Low-End-Performance im grünen Bereich. Cloud-Tests ersparen viele Hardware-Käufe.

Methode:

• WeChat Cloud-Test: kostenlos, gängige Mini-Spiel-Geräte
• Testin Cloud: kostenpflichtig, breitere Abdeckung

Empfohlene Geräte:

• iPhone 6s/7/8: Low-End-Baseline
• iPhone X/XR/11: Mid/High plus Notch
• Huawei/Xiaomi/OPPO/vivo: Android-Streuung

Kennzahlen:

• Low-End FPS ≥30
• Low-End Speicher ≤70 % des Limits
• Absturzrate ≤2 %
• Installationserfolg ≥99 %

Typische Probleme:

• Nur iPhone getestet – Android Low-End schwächer als iPhone 6s
• Alte Geräte ignoriert – 2024 noch iPhone-7-Nutzer
• WebGL nicht geprüft – alte Versionen, Effekte fehlen

Selbsttest: Drei Klassen – Ihr Dev-Gerät (High-End), iPhone 7 (iOS Low-End), Android-Mitte ~2019.

12. Orientierungswechsel

Standard: Layout bei Rotation; manche Spiele wechseln Portrait/Landscape – UI muss neu sortieren.

Methode: Echtgerät drehen; erzwungenes Landscape/Portrait testen.

Kennzahlen:

• Wechsel ≤500 ms
• UI ohne Verschiebung
• Szene rendert nach Wechsel normal

Typische Probleme:

• Knoten springen – Widget nicht aktualisiert
• Schwarzer Bildschirm – Szenen-Reload scheitert
• Ruckeln – zu große Szene neu gerendert

// Bildschirmrotation abhören
cc.view.on('resize', () => {
  const isLandscape = cc.view.getFrameSize().width > cc.view.getFrameSize().height;
  this.updateUILayout(isLandscape);
});

// UI-Neuordnung
updateUILayout(isLandscape: boolean) {
  if (isLandscape) {
    this.scoreLabel.x = -200;
    this.scoreLabel.y = 300;
  } else {
    this.scoreLabel.x = 0;
    this.scoreLabel.y = 600;
  }
}

Selbsttest: Nur Portrait oder nur Landscape? In den Projekteinstellungen fixieren – sonst Chaos bei Nutzer-Rotation.

4. Review: Qualifikationen, Datenschutz, Inhalt

Review frustiert oft. Technik testen Sie selbst – Richtlinien-Details erfahren Sie erst bei Ablehnung. WeChat dokumentiert ausführlich; in der Praxis zählen Nuancen. Seit 2026 unterstützt WeChat KI bei Reviews – Updates in 2–4 Stunden; Erstveröffentlichung weiter 1–2 Werktage.

13. Qualifikationen vollständig

Standard: Softwarerecht, ICP-Registrierung, Spielelizenz (bei In-App-Käufen). Fehlt eines – Ablehnung.

Methode: Offizielle Liste; Name und Rechtsträger Zeichen für Zeichen gleich.

Kennzahlen:

• Softwarerecht: Name und Konto exakt identisch
• ICP: Freigabe (7–20 Werktage)
• Spielelizenz: bei IAP Pflicht; reine Werbung oft entbehrlich

Typische Probleme:

• Softwarerecht „Spiel X“, App „Spiel X Mini“ – abgelehnt
• ICP noch nicht freigegeben eingereicht – 7–20 Tage Wartezeit
• Lizenz Firma A, Konto Firma B – nein

Selbsttest: Zertifikate nebeneinander legen, Namen und Träger vergleichen – kein Zeichen Toleranz.

14. Datenschutz und Jugendschutz

Standard: Datenschutz-Einstieg, Echtname-Verifizierung, Anti-Addiction. Pflicht für Minderjährigen-Schutz; 2026 verschärfte Prüfung.

Methode: Flow als Minderjähriger simulieren; Anti-Addiction-Logik prüfen.

Kennzahlen:

• Datenschutz: sichtbar auf Start (Popup oder Button)
• Anti-Addiction: Minderjährige max. 1 h/Tag; 22:00–8:00 gesperrt
• Alters-Hinweis: Gesund-spielen-Hinweis auf Start

Typische Probleme:

• Kein Datenschutz-Popup – direkt ins Spiel
• Keine Echtname-Verifizierung oder Anti-Addiction danach inaktiv
• Gesund-spielen-Hinweis fehlt

Selbsttest: Test mit Minderjährigen-ID; nach 22:00 Login – Sperrhinweis?

15. Inhalts-Compliance

Standard: Name regelkonform; Werbung blockiert keine Kernfunktion; keine roten Linien (Gewalt, Pornografie, Glücksspiel, Politik).

Methode: Richtlinien-Selbstcheck für Name, Werbung, Inhalt.

Kennzahlen:

• Name: ohne unerlaubte Marken/Englisch wo verboten; mit Qualifikation konsistent
• Werbeanteil ≤50 %; Kern-UI frei
• Inhalt ohne verbotene Themen

Typische Probleme:

• „Software“ im Namen – abgelehnt
• Werbung über „Spiel starten“
• „An Freunde teilen für Level“ – Ablehnung
• Englischer Name wie „CocosGame“ – auf Chinesisch anpassen (WeChat-CN-Kontext im Original)

Top-5-Ablehnungsgründe:

1. Paket zu groß (Hauptpaket >4 MB)
2. Name ≠ Softwarerecht
3. Datenschutz-Popup fehlt
4. Erzwungenes Teilen/Folgen
5. Werbung blockiert Kernfunktion

Selbsttest: Diese Top 5 abhaken – ~80 % der Ablehnungen; meiden Sie diese, steigt die Erstfreigabe-Chance stark.

Schnell-Checkliste: 15 Punkte vor dem Launch

Zum Ausdrucken und Abhaken vor der Einreichung:

Modul	Prüfpunkt	Standard	OK
Performance	FPS-Stabilität	High-End ≥55, Low-End ≥28	□
Performance	Speicherpeak	Low-End ≤700 MB, High-End ≤1000 MB	□
Performance	DrawCall	Start ≤100, Spiel ≤200	□
Performance	Ladezeit Start	≤3000 ms	□
Paket	Hauptpaket	≤3,8 MB	□
Paket	Gesamtpaket	≤15 MB	□
Paket	Kompression	PNG −50 %+, Audio −65 %+	□
Paket	Subpackages	Erste Szene als Subpackage	□
Kompatibilität	Display	Keine Ränder, nichts verdeckt	□
Kompatibilität	Notch	UI ≥50 px vom Rand	□
Kompatibilität	Geräte	Low-End FPS ≥28	□
Kompatibilität	Rotation	≤500 ms, kein Versatz (falls unterstützt)	□
Review	Qualifikationen	Softwarerecht + ICP + Lizenz (IAP)	□
Review	Datenschutz/Jugendschutz	Policy + Anti-Addiction	□
Review	Inhalt	Name/Werbung/Inhalt regelkonform	□

Erst wenn alle 15 Häkchen gesetzt sind, einreichen. Ein offener Punkt kann Ablehnung und Tage Nacharbeit bedeuten.

Fazit

Launch-Checks sind kein Formalismus – sie bestimmen Freigaberate und Nutzererlebnis. Performance treibt Abbrüche weg, zu großes Paket wird sofort abgelehnt, schlechte Kompatibilität erzeugt Support-Tickets, Review-Fehler kosten eine Woche.

Der Wert dieser Liste: konkrete Zahlen statt Raten; klare Testmethoden statt Bauchgefühl; dokumentierte Fallstricke statt eigener Fehler.

Drucken Sie die Liste aus und hängen Sie sie neben den Monitor. Ja, es kostet Minuten – gegen drei Tage Ablehnung und Nachbessern lohnt sich jede Minute.

Die erste Einreichung ist nervös – normal. Mit dieser Checkliste gehen Sie systematisch vor. Viel Erfolg: Freigabe beim ersten Versuch und reibungsloser Launch.