Lista de verificación previa al lanzamiento de mini juegos Cocos Creator: rendimiento, tamaño del paquete, adaptación y revisión

El día que envié la auditoría por primera vez, me quedé mirando el aviso de «rechazado» y se me nubló la cabeza. Paquete demasiado grande: el principal pesaba 6.8 MB y WeChat impone un límite estricto de 4 MB. Tres días de ajustes — compresión de texturas, transcodificación de audio y recorte de módulos del motor — hasta dejarlo en 3.2 MB y pasar.

Esa experiencia me dejó claro que la revisión previa al lanzamiento no es cuestión de suerte: hay métricas concretas y métodos de comprobación claros. Después organicé los errores que cometí en una lista y la repaso antes de cada envío. Ya la he iterado más de diez veces; cubre rendimiento, tamaño del paquete, adaptación y auditoría en 15 puntos.

En este artículo comparto esa lista. Cada punto incluye métricas, herramientas de comprobación y las trampas más frecuentes. Al terminar podrás revisarla punto por punto y aumentar mucho las probabilidades de pasar a la primera.

1. Revisión de rendimiento: que el lag no arruine la experiencia

El rendimiento es una de las principales causas de abandono. Puede que en tu móvil vaya fluido, pero olvida que tu dispositivo de prueba suele ser reciente y muchos usuarios llevan tres años con el mismo teléfono. La brecha entre iOS gama alta y baja puede ser de 3-4 veces; no es broma.

1. FPS estable

Estándar: gama alta (iPhone X en adelante) objetivo 60 FPS; gama baja (iPhone 6s/7/8) objetivo 30 FPS. El pico no debe bajar del 80 % del objetivo: mínimo 48 FPS en gama alta y 24 FPS en gama baja.

Cómo comprobarlo: Cocos Creator muestra FPS integrado; actívalo en cc.macro:

// Mostrar FPS en desarrollo
cc.macro.SHOW_FPS = true;

También puedes usar Stats.js, más visual. El «panel de rendimiento» de las herramientas de desarrollo de WeChat muestra la curva de FPS en tiempo real.

Métricas:

• Gama alta estable 55-60 FPS
• Gama baja estable 28-32 FPS
• Variación de picos ≤20 %

Problemas frecuentes: demasiados DrawCall, tirones al cambiar escenas complejas, muchas partículas a la vez. En un proyecto mío, la muerte del jefe lanzaba 200 partículas y en gama baja caía a 15 FPS; lo reduje a 50 partículas con animación suave y el resultado fue mejor.

Truco de autoprueba: usa un iPhone 7 real durante 10 minutos. Si la línea de FPS se mantiene alrededor de 30, bien; si cae a menudo por debajo de 20, hay que investigar.

2. Pico de memoria

Estándar: iOS impone límites estrictos. Gama baja (iPhone 6s/7/8) tope 1 GB; gama alta (iPhone X/XR/11) tope 1.4 GB. El pico no debe superar el 70 % del límite: ≤700 MB en gama baja y ≤1 GB en gama alta.

Cómo comprobarlo:

• Herramientas de desarrollo de WeChat: panel «Depurador-Memory» con curva de memoria
• Depuración remota Safari: conecta el dispositivo al Mac y elige el dispositivo en el menú Desarrollador de Safari

// Imprimir uso de memoria periódicamente
const memoryInfo = cc.sys.getMemoryInfo();
console.log('Memoria actual: ' + memoryInfo.used + 'MB');

Métricas:

• Pico gama baja ≤700 MB
• Pico gama alta ≤1000 MB
• Tasa de cierre inesperado ≤2 % (un proyecto pasó del 15 % al 2 % tras optimizar)

Problemas frecuentes: texturas duplicadas (mismo recurso cargado dos veces), recursos sin liberar, atlas demasiado grandes. La documentación oficial de Cocos recomienda atlas ≤1024x1024; en gama baja los más grandes suelen reventar memoria.

Truco de autoprueba: en gama baja, entra y sale de la misma escena 20 veces. Si la curva sigue subiendo sin bajar, hay fuga de recursos.

3. Cantidad de DrawCall

Estándar: DrawCall afecta directamente al renderizado. Cuantos más DrawCall en un frame, más presión sobre la GPU. Primera pantalla (al entrar al juego) ≤100; durante el juego ≤200.

Cómo comprobarlo: en el panel «Compilar y publicar» de Cocos Creator activa estadísticas de renderizado para ver DrawCall en tiempo de ejecución.

// Ver DrawCall actual
const stats = cc.game._renderStats;
console.log('DrawCall: ' + stats.drawCalls);

Métricas:

• Primera pantalla ≤100
• En juego ≤200
• Pico ≤350 (escenas extremas pueden relajarse)

Problemas frecuentes: sin atlas, dynamic atlas desactivado, demasiado BMFont. Un proyecto mío tenía 350 DrawCall; empaqueté sprites sueltos en atlas grande y cambié BMFont por TTF, quedando en 120.

Consejos de optimización:

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

• Atlas estático: TexturePacker, menos sprites sueltos
• Atlas dinámico: activado por defecto en Cocos Creator; texturas <2048
• BMFont: usa TTF cuando puedas; cada carácter BMFont es un DrawCall

4. Tiempo de carga de la primera pantalla

Estándar: si la primera pantalla tarda más de 3 segundos, la tasa de abandono sube un 7 %. No lo invento: son datos del sector. La plataforma de pruebas en la nube de WeChat indica que juegos de ~3.5 MB tardan 4500-9000 ms en la primera pantalla, con abandono notable en ese rango.

Cómo comprobarlo:

• Herramientas de desarrollo de WeChat: «Detalles-Código local» muestra tamaño del paquete
• Plataforma de pruebas en la nube de WeChat: simula red real en dispositivo

// Registrar tiempo de carga de la primera pantalla
const startTime = Date.now();
cc.director.loadScene('game', () => {
  const loadTime = Date.now() - startTime;
  console.log('Tiempo primera pantalla: ' + loadTime + 'ms');
});

Métricas:

• Primera pantalla ≤3000 ms (ideal ≤1500 ms)
• Barra de progreso visible ≥80 % (el usuario espera mejor si ve avance)

Problemas frecuentes: demasiados recursos en la escena inicial, escena inicial sin subpaquete, todo el directorio resources cargado de golpe. Yo tenía 3 personajes, 2 fondos y montones de UI en la primera escena: 5 segundos; pasé a una imagen de loading + carga por subpaquetes y bajé a 2 segundos.

Consejos de optimización:

• Primera escena: solo fondo + barra de progreso
• Marca la escena inicial como subpaquete
• Recursos no esenciales en carga remota

2. Revisión del paquete: hay que cruzar el límite de 4 MB

El paquete principal de mini juegos de WeChat tiene un límite estricto de 4 MB; el paquete completo (con subpaquetes) no puede superar 16 MB. Es línea roja: superarlo implica rechazo directo, sin negociación. Yo caí ahí — 6.8 MB en el principal — y tardé tres días en bajar a 3.2 MB.

5. Tamaño del paquete principal

Estándar: paquete principal ≤3.8 MB. ¿Por qué 200 KB de margen? Porque la compilación puede generar archivos dinámicos y la medición de WeChat a veces varía ligeramente. Mejor dejar aire.

Cómo comprobarlo: tras compilar, en las herramientas de desarrollo de WeChat pulsa «Detalles-Código local» para ver el tamaño exacto.

Métricas:

• Principal ≤3.8 MB (línea segura)
• Principal ≤4.0 MB (línea roja, hay que comprimir)

Problemas frecuentes:

• Demasiados recursos en resources: todo ese directorio va al paquete principal
• Módulos del motor sin recortar: Cocos empaqueta todos por defecto, pero quizá solo necesitas algunos
• Dependencias npm demasiado pesadas sin revisar tamaño

Truco de autoprueba: antes de compilar revisa resources y mueve lo no esencial. En «Configuración del proyecto-Módulos» desmarca lo que no uses.

// Ejemplo de recorte de módulos (project.json)
{
  "modules": [
    "base",
    "2d",
    "ui",
    "audio"
  ],
  // No marques módulos innecesarios, por ejemplo:
  // "physics" - sin motor de física
  // "tween" - sin sistema de tween
}

6. Tamaño del paquete completo

Estándar: paquete completo (principal + subpaquetes) ≤16 MB. Los subpaquetes pueden cargarse en remoto, pero la velocidad depende de la red; el contenido clave conviene en principal y subpaquete de primera pantalla.

Cómo comprobarlo: el log de compilación muestra el tamaño de cada subpaquete; la suma es el total.

Métricas:

• Completo ≤15 MB (línea segura)
• Completo ≤16 MB (línea roja)

Estrategia de subpaquetes:

• Núcleo (principal + primera pantalla) <10 MB
• Funcional (modos secundarios) 20-50 MB
• Escenas (carga remota) 30-100 MB

Problemas frecuentes: subpaquetes mal divididos; el de primera pantalla demasiado grande y el usuario espera 8 segundos al descargar. Tuve un proyecto con todos los modelos de personajes en el subpaquete inicial.

7. Ratio de compresión de recursos

Estándar: texturas, audio y fuentes son los tres grandes del peso del paquete. En la práctica: texturas ~45 %, audio ~25 %, fuentes ~15 %. Comprimir bien estas tres categorías puede reducir el paquete a la mitad.

Cómo comprobarlo: compara tamaño original y tamaño tras compilar.

Métricas:

• PNG → JPG (sin canal alpha): −50-70 %
• WAV → OGG: −65-70 %
• Subconjunto de fuente (fontmin): −80-90 %

Herramientas recomendadas:

• TinyPNG: compresión PNG en web, arrastrar y soltar
• TexturePacker: atlas + compresión en un paso
• Audacity: transcodificación WAV a OGG
• fontmin: subconjunto de caracteres usados en el juego

Problemas frecuentes:

• Fondos en PNG sin transparencia: mejor JPG
• Audio en WAV: varias veces más pesado; usa OGG
• Fuente completa sin extraer: 10 MB+ frente a ~100 KB solo con los glifos necesarios

Truco de autoprueba: comprime un PNG con TinyPNG y compara. Un fondo de 500 KB puede quedar en 150 KB.

8. Configuración de subpaquetes

Estándar: la estrategia de carga no debe perjudicar el arranque. La primera escena debe estar en subpaquete; recursos no esenciales fuera del principal.

Cómo comprobarlo: revisa orden de carga y dependencias de la primera escena.

Métricas:

• Primera escena en subpaquete: sí
• Tiempo de carga primera escena: ≤3000 ms
• Recursos no esenciales fuera del principal: revisar directorio resources

Problemas frecuentes:

• Primera escena referencia recursos fuera del principal: hay que descargar subpaquete antes de entrar
• Subpaquetes sin lógica de negocio: el usuario entra a un modo y el subpaquete aún no terminó
• Momento de carga incorrecto: conviene empezar a descargar subpaquetes en la pantalla de loading

// Ejemplo de carga de subpaquete
cc.assetManager.loadBundle('level-pack', (err, bundle) => {
  if (err) {
    console.error('Error al cargar subpaquete', err);
    return;
  }
  bundle.loadScene('level-1', (err, scene) => {
    cc.director.runScene(scene);
  });
});

Truco de autoprueba: prueba la velocidad de subpaquetes en 4G. Si el de primera pantalla tarda más de 5 segundos, replantea la estrategia.

3. Revisión de adaptación: no fallar en un solo modelo

La adaptación es lo más ignorado. En tu móvil de prueba puede ir bien, pero tras publicar llegan quejas: UI tapada, bandas negras feas, desalineación al rotar. Es un problema sistémico; no basta con un solo dispositivo.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

9. Adaptación de pantalla

Estándar: resolución de diseño, estrategia de adaptación y bandas negras. Juegos verticales: 720x1280 (9:16) o 750x1334; horizontales, al revés.

Cómo comprobarlo: prueba real en al menos tres proporciones:

• 16:9 (tradicional, muchos Android)
• 18:9 (modernos Xiaomi/Huawei)
• 19.5:9 (iPhone X, notch)

Métricas:

• Resolución de diseño: 720x1280 o 750x1334
• Estrategia: vertical adapta altura; horizontal adapta anchura
• Bandas negras: ninguna, o distribuidas de forma uniforme

Código clave:

// Vertical: adaptar altura
cc.view.setDesignResolutionSize(720, 1280, cc.ResolutionPolicy.FIXED_HEIGHT);

// Horizontal: adaptar anchura
cc.view.setDesignResolutionSize(1280, 720, cc.ResolutionPolicy.FIXED_WIDTH);

// Obtener área visible real
const visibleSize = cc.view.getVisibleSize();
console.log('Área visible: ' + visibleSize.width + 'x' + visibleSize.height);

Problemas frecuentes:

• Estrategia equivocada: vertical con adaptación de anchura y bandas arriba/abajo
• Widget mal usado: nodos que no siguen los bordes
• Resolución de diseño demasiado ancha: contenido cortado en algunos modelos

Truco de autoprueba: fija la UI clave con Widget a los bordes. Por ejemplo, monedas arriba a la derecha con Widget en la esquina superior derecha, en cualquier proporción.

10. Notch / pantalla con muesca

Estándar: área segura; la UI clave no debe quedar tapada. El notch de iPhone X, las gotas y los agujeros en Android ocupan la parte superior.

Cómo comprobarlo: iPhone X/XR/11 y Android con notch (Huawei Mate, Xiaomi gama alta).

Métricas:

• UI clave ≥50 px del borde superior
• UI clave ≥50 px del borde inferior (zona del botón Home virtual)
• Detección de área segura: API SafeArea

Consejos de adaptación:

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

// Adaptar nodos
this.topNode.y = -topPadding;  // desplazar hacia abajo
this.bottomNode.y = bottomPadding;  // desplazar hacia arriba

O usa Widget con distancia al borde igual al valor dinámico del área segura.

Problemas frecuentes:

• Título tapado por el notch
• Botones inferiores solapados con el Home virtual
• Sin probar agujeros en Android: la posición varía por marca

Truco de autoprueba: en el simulador de WeChat elige «iPhone X» y comprueba el notch; repite en un Android con notch real.

11. Compatibilidad de modelos

Estándar: cubrir modelos mainstream; rendimiento aceptable en gama baja. La nube de pruebas permite lotes sin comprar docenas de móviles.

Cómo comprobarlo:

• Plataforma en la nube de WeChat: gratuita, modelos habituales de mini juegos
• Testin: de pago, cobertura más amplia

Modelos recomendados:

• iPhone 6s/7/8: referencia gama baja, límite de rendimiento
• iPhone X/XR/11: gama media-alta, notch
• Huawei/Xiaomi/OPPO/vivo mainstream: compatibilidad Android

Métricas:

• FPS gama baja ≥30
• Memoria gama baja ≤70 % del límite del dispositivo
• Tasa de cierre inesperado ≤2 %
• Tasa de instalación exitosa ≥99 %

Problemas frecuentes:

• Solo iPhone: Android varía mucho; gama baja Android puede ser más débil que iPhone 6s
• Ignorar modelos viejos: en 2024 aún hay usuarios con iPhone 7
• Sin probar WebGL: versiones bajas en algunos modelos ocultan efectos

Truco de autoprueba: tres tipos — tu dispositivo de desarrollo (alta), iPhone 7 (iOS baja), un Android medio de 2019. Cubren la mayoría de casos.

12. Cambio horizontal/vertical

Estándar: esquema de adaptación y fluidez al rotar. Algunos juegos permiten rotación (p. ej. puzzles); la UI debe reordenarse al cambiar.

Cómo comprobarlo: rotación en dispositivo real; escenarios forzados horizontal/vertical.

Métricas:

• Tiempo de cambio ≤500 ms
• Reordenación de UI sin desalineación
• Escena renderiza bien tras el cambio

Problemas frecuentes:

• Nodos desalineados al rotar: Widget sin actualizar
• Pantalla negra tras rotar: fallo al recargar escena
• Tirones: escena demasiado grande al re-renderizar

// Escuchar rotación de pantalla
cc.view.on('resize', () => {
  const isLandscape = cc.view.getFrameSize().width > cc.view.getFrameSize().height;
  this.updateUILayout(isLandscape);
});

// Lógica de reordenación de UI
updateUILayout(isLandscape: boolean) {
  if (isLandscape) {
    // Layout horizontal
    this.scoreLabel.x = -200;
    this.scoreLabel.y = 300;
  } else {
    // Layout vertical
    this.scoreLabel.x = 0;
    this.scoreLabel.y = 600;
  }
}

Truco de autoprueba: si solo soportas vertical u horizontal, bloquea la orientación en la configuración del proyecto para evitar desorden al rotar el móvil.

4. Revisión de auditoría: licencias, privacidad y contenido

La auditoría suele ser lo que más agobia. Los problemas técnicos los puedes probar tú; las normas de revisión tienen muchos matices en la práctica. WeChat documenta con detalle, pero en 2026 también hay revisión asistida por IA: actualizaciones en 2-4 horas, aunque la primera versión sigue tardando 1-2 días hábiles.

13. Completitud de licencias

Estándar: registro de software, ICP y número de edición (obligatorio con compras integradas). Falta una y rechazo directo.

Cómo comprobarlo: lista oficial punto por punto; nombre y titular idénticos.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Métricas:

• Registro de software: titular y nombre idénticos al de la cuenta (letra por letra)
• ICP: aprobado (7-20 días hábiles)
• Número de edición: obligatorio con IAP; opcional solo con anuncios

Problemas frecuentes:

• Nombre del registro con una palabra de más: p. ej. registro «Bilin Match-3» y juego «Bilin Match-3 Mini Juego» → rechazo
• Enviar antes de que aprueben el ICP: 7-20 días; envío anticipado = rechazo
• Titular del número de edición distinto al de la cuenta del juego

Truco de autoprueba: junta certificado de registro, captura ICP y número de edición (si aplica) y compara carácter a carácter nombre y titular.

14. Política de privacidad y protección de menores

Estándar: entrada a la política de privacidad, verificación de identidad real y sistema antiadicción. Requisitos obligatorios de protección de menores; en 2026 la auditoría los revisa con especial atención.

Cómo comprobarlo: simula flujo de login de menor y comprueba que la antiadicción funcione.

Métricas:

• Política de privacidad: entrada visible en inicio (ventana emergente o botón)
• Antiadicción: menores ≤1 h/día; prohibido jugar 22:00-8:00
• Aviso de edad recomendada: consejo de juego saludable en inicio

Problemas frecuentes:

• Sin ventana emergente de privacidad: el usuario entra a jugar directamente
• Sin antiadicción: sin entrada de verificación real o sin aplicar límites tras verificar
• Sin consejo de juego saludable: la auditoría pide añadirlo

Truco de autoprueba: prueba con un DNI de menor de 18 años. Comprueba límites y que entre las 22:00 no deje jugar.

15. Cumplimiento de contenido

Estándar: normas de nombre, anuncios y líneas rojas de contenido. El nombre debe coincidir con las licencias; los anuncios no pueden tapar funciones clave; el contenido no puede cruzar líneas rojas.

Cómo comprobarlo: autorevisión según normas de auditoría en nombre, anuncios y elementos.

Métricas:

• Nombre: sin inglés/marcas no permitidas; coherente con licencias
• Proporción de anuncios: ≤50 %; no tapar funciones clave
• Contenido: sin violencia, pornografía, apuestas ni temas políticos sensibles

Problemas frecuentes:

• Nombre con la palabra «software»: p. ej. «XX Software Mini Juego» → rechazo
• Anuncio sobre botón clave: el usuario quiere «Empezar» y pulsa el anuncio
• Compartir incentivado: «Comparte con amigos para desbloquear nivel» → rechazo
• Nombre en inglés: p. ej. «CocosGame» → cambiar a chino según normas

TOP 5 de causas de rechazo:

1. Paquete demasiado grande (principal >4 MB)
2. Nombre distinto al registro de software
3. Política de privacidad sin ventana emergente
4. Compartir/seguir incentivado
5. Anuncios que tapan funciones clave

Truco de autoprueba: repasa este TOP 5 punto por punto. Representa ~80 % de rechazos; evitarlos suele bastar para pasar a la primera.

Tabla rápida: 15 puntos antes del lanzamiento

Puedes imprimir esta tabla y marcar cada ítem antes de enviar la auditoría:

Marca cada ítem cumplido; envía solo cuando los 15 estén marcados. Cualquier fallo puede implicar rechazo y días de corrección.

Resumen

La revisión previa al lanzamiento no es un trámite opcional: define la tasa de aprobación. El rendimiento hace perder usuarios; el paquete grande implica rechazo directo; la mala adaptación trae quejas; el incumplimiento en auditoría puede costarte una semana.

El valor de esta lista: métricas concretas sin adivinar; métodos de comprobación sin improvisar; problemas frecuentes para no repetir errores ajenos.

Imprímela y déjala junto al monitor. Revisar punto por punto puede parecer pesado, pero frente a tres días rehaciendo tras un rechazo, merece la pena.

Es normal estar nervioso la primera vez; con esta lista puedes revisar de forma sistemática. Que tu mini juego pase a la primera y se publique sin sobresaltos.