¿Cuántos megas son demasiados para un mini-juego?
No hay un número mágico, y quien te da uno está vendiendo una regla de dedo como ley. Pero el tamaño tiene un costo medible, y para los mini-juegos muerde más fuerte que para las apps nativas —porque el jugador suele recuperar tu payload bajo demanda, dentro del runtime de otro, en un teléfono de gama media sobre una conexión inestable. Esto es cómo pensar el presupuesto en lugar de adivinarlo.
Q: ¿Por qué el tamaño del paquete castiga más a los mini-juegos que a las apps nativas?
Una app nativa se descarga una vez, la cachea el SO y la precalienta la plataforma. Un mini-juego corre frecuentemente dentro del WebView o runtime de una app anfitriona que ella misma tiene un presupuesto de memoria y arranque, y tu payload se recupera cuando el jugador toca —no se instaló hace días. Así que tu arranque en frío es descarga + parseo + primer frame, y cada mega es tiempo que el jugador mira un spinner. En un Android de gama media en un mercado emergente, la diferencia entre 3MB y 10MB iniciales es la diferencia entre un jugador que espera y uno que rebota antes del primer frame. Las apps nativas amortizan ese costo; tú lo comes por sesión.
Q: ¿Cuál es el presupuesto real, y cómo lo mides?
Olvida la discusión de megas y mide lo que el jugador siente: tiempo-real-a-interactuar en un perfil limitado, no tu laptop de desarrollo con wifi. Una meta útil es menos de ~4MB para el payload jugable inicial, transmitiendo el resto. Luego pruébalo como lo vive el jugador —4G limitado, dispositivo de gama media, caché limpia— con Lighthouse, WebPageTest o la herramienta de trace de la plataforma. La trampa es optimizar el tamaño de descarga mientras un solo archivo JS gigante bloquea el hilo principal en el parseo: un archivo más pequeño que pinta lento es peor que uno más grande que pinta rápido. El tamaño es un proxy; la interactividad es la verdad.
Q: ¿De dónde viene realmente el peso?
Tres sospechosos, y el tercero es el que los equipos pasan por alto. Primero, overhead del motor y runtime —el framework que elegiste tiene un piso, y algunos son más pesados. Segundo, inflación de assets: audio sin comprimir, texturas 4K para un puzzle 2D, sprite sheets que nadie recortó. Tercero, y el asesino silencioso: SDKs de terceros. Analítica, anuncios, auth, crash reporting —cada uno suma silenciosamente 0.5–2MB y una ida y vuelta de red al arranque. Los equipos se obsesionan con sus 200KB de código e ignoran seis SDKs que jalan 4MB. Audita el árbol de dependencias y etiqueta cada SDK como estructural o decorativo; la mayoría es decorativo y todos cobran impuesto al primer frame.
Q: ¿Cómo lo mantienes pequeño sin reescribir el juego?
Casi nunca necesitas una reescritura. Transmite assets y carga perezosamente: no envíes las texturas del nivel 50 el día 1, recíbelas cuando el jugador llegue. Comprime audio a un códec moderno, haz atlas de texturas e inicializa los SDK después del primer frame en lugar de antes. Elige un runtime o motor con huella pequeña desde el inicio —esta es una decisión que tomas una vez y cargas durante todo el proyecto. El tradeoff que hay que nombrar en voz alta: el code-splitting agresivo reduce el tamaño inicial pero añade un poco de latencia en cargas posteriores, así que cambias primer-frame-inmediato por tamaño-total. Mide ambos, no asumas que la división ayudó.
| Lever | Impacto en arranque | Esfuerzo | Riesgo si se ignora |
|---|---|---|---|
| Payload inicial < 4MB | alto | medio | rebote antes del primer frame |
| Streaming / carga perezosa | alto | medio | envía peso que no necesitas ya |
| Auditoría SDK + init post-frame | muy alto | bajo | impuesto silencioso 4MB |
| Elección de motor / runtime | alto | alto (temprano) | piso bloqueado |
