Parte: 11 — Móvil, consolas y plataformas · Fuente: Documentación de Godot 4 (Exporting projects) ⏱️ Duración estimada: 60 min · Nivel: Intermedio
Antes de tocar una sola opción de exportación conviene entender el terreno: un mismo proyecto de Godot 4 puede correr en PC, móvil, web y consola, pero cada destino impone reglas distintas de entrada, potencia, distribución y certificación. Elegir plataformas objetivo tarde en el desarrollo suele obligar a rehacer UI, controles y presupuesto de rendimiento.
En esta clase construimos un mapa mental de las plataformas y sus restricciones, y aprendemos a tomar decisiones tempranas de portabilidad: qué input soporta cada destino, cuánta GPU/CPU tienes disponible, qué tienda te distribuye y qué proceso de aprobación o certificación deberás pasar. El laboratorio produce una tabla comparativa que guiará el resto de la Parte 11.
La idea central es que la portabilidad no se improvisa al final: se decide al principio. Cuanto antes sepas a qué pantallas, controles y tiendas apuntas, más baratas serán tus decisiones de arquitectura y menos código tendrás que rehacer. Esta clase no exporta nada todavía; te da el criterio para que las seis clases siguientes tengan sentido.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | PC (Windows/Linux/macOS) | Plataforma de desarrollo y baseline de potencia. |
| 2 | Móvil (Android/iOS) | Táctil, batería y tiendas con revisión. |
| 3 | Consola (Switch/PS/Xbox) | Kits de desarrollo, NDA y certificación estricta. |
| 4 | Web (HTML5/WASM) | Sin instalación, pero límites de memoria y APIs. |
| 5 | Restricciones de input | Táctil, gamepad, teclado: cambian la UI. |
| 6 | Restricciones de potencia | GPU/CPU/RAM limitan el presupuesto gráfico. |
| 7 | Tiendas y certificación | Reglas de publicación y control de calidad. |
| 8 | Portabilidad temprana | Decidir pronto evita rehacer sistemas. |
No necesitas exportar nada todavía: esta clase es de análisis y decisión. Ten a mano tu proyecto del curso y una hoja de cálculo o un documento donde armar la tabla comparativa. Conviene revisar la matriz de features de Godot para ver qué soporta cada plataforma y qué renderer aplica.
Consulta la guía de exportación en https://docs.godotengine.org/en/stable/tutorials/export/exporting_projects.html y la lista de plataformas soportadas en https://docs.godotengine.org/en/stable/about/list_of_features.html. Para requisitos de tiendas, ten abiertas las páginas oficiales de Google Play y App Store como referencia.
No hace falta que decidas hoy todas las plataformas de forma definitiva, pero sí que dejes por escrito tus candidatas y sus riesgos. Ese documento vivo se irá refinando en las clases siguientes: la 201 y 202 aterrizan el export a Android e iOS, la 203 y 205 resuelven input y pantallas, y la 204 y 206 cubren rendimiento y monetización. La tabla de esta clase es el índice que conecta todas ellas.
Vamos a producir una tabla de decisión de plataformas para tu juego del curso.
Define el juego objetivo en una frase (género, cámara, controles). Ejemplo: "plataformas 2D con salto y ataque, control por gamepad/teclado en PC".
Crea una tabla con una fila por plataforma candidata y estas columnas: Input principal, Potencia disponible, Renderer recomendado, Tienda, ¿Certificación?, Esfuerzo de port (1-5), Decisión (sí/no/después).
Rellena PC: input teclado+gamepad, potencia alta, renderer Forward+, tienda Steam/itch.io, sin certificación estricta, esfuerzo 1 (es tu baseline), decisión "sí".
Rellena Móvil (Android/iOS): input táctil (necesitas controles en pantalla), potencia media-baja, renderer Mobile, tiendas Google Play/App Store con revisión, certificación media (políticas de tienda), esfuerzo 3-4 por la UI táctil, decisión según tu público.
Rellena Web: input teclado/ratón/táctil, potencia limitada (memoria WASM), renderer Compatibility, tienda itch.io/web propia, sin certificación, esfuerzo 2-3, decisión útil para demos.
Rellena Consola: input gamepad, potencia media-alta, renderer según SDK, tienda del fabricante, certificación estricta con devkit y NDA, esfuerzo 5, decisión normalmente "después". Anota que Godot no incluye export oficial de consolas: se hace vía terceros con contrato.
Marca en rojo cada celda que obligue a rehacer algo (p. ej. "Móvil: falta UI táctil"). Esas celdas son tu backlog de portabilidad y las abordaremos en las clases 201-207.
Escribe abajo 3 decisiones tempranas derivadas de la tabla. Ejemplo: "abstraer input en acciones, no en teclas concretas", "reservar presupuesto para renderer Mobile", "diseñar UI que quepa en 16:9 y en pantallas altas".
Añade una fila de "riesgo principal" por plataforma: la razón más probable por la que ese port fracase (p. ej. "Web: se queda sin memoria", "iOS: no tengo Mac", "Móvil: controles táctiles incómodos"). Tener el riesgo escrito te obliga a mitigarlo pronto en vez de descubrirlo al final.
Con esta tabla sabes a qué plataformas apuntas y qué trabajo implica cada una antes de escribir más código.
Una tabla de decisión no es un adorno: es un contrato contigo mismo. Cada "sí" te compromete a un presupuesto de rendimiento, un modelo de input y un proceso de tienda concretos; cada "después" te recuerda no cerrar puertas de diseño que luego costará reabrir. Si dos plataformas comparten input y renderer (por ejemplo PC y Web con teclado/ratón), portar entre ellas es barato; si difieren en ambos (PC y Móvil), el port es un mini-proyecto. Usa esa distancia para ordenar tu hoja de ruta: primero los destinos cercanos a tu baseline, después los lejanos.
Entrega una tabla comparativa completa de al menos cuatro plataformas (PC, Android, iOS o Web, y una consola) para tu juego, con las siete columnas del laboratorio rellenas, un puntaje de esfuerzo justificado por plataforma y una lista final de tres decisiones tempranas de portabilidad derivadas de la tabla.
Criterio de aceptación: la tabla incluye input, potencia, renderer, tienda, certificación, esfuerzo (1-5) y decisión por cada plataforma; cada celda de "esfuerzo" tiene una razón escrita; y las tres decisiones tempranas se conectan explícitamente con celdas concretas de la tabla.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| El juego "no cabe" en móvil al final del proyecto | No se decidió la plataforma temprano. Define destinos antes de diseñar UI e input. |
| Asumir que consola es "exportar y listo" | Godot no trae export oficial de consolas; requiere terceros, devkit y certificación. Plantéalo desde el inicio. |
| UI ilegible al portar a otra pantalla | Se diseñó para una sola resolución. Usa anclas y contenedores desde ya (ver clase 205). |
| Rendimiento inaceptable en móvil/web | Se usó Forward+ sin presupuesto. Prevé Mobile/Compatibility en la decisión. |
| Sorpresa con comisiones o requisitos de tienda | No se revisaron las políticas antes. Inclúyelas en la tabla de decisión. |
| Se prometió consola en el pitch sin plan real | Se ignoró el devkit/NDA/certificación. Marca consola como "después" hasta tener el acuerdo. |
| El mismo control no funciona en dos plataformas | Se acopló el input a teclas concretas. Abstrae en acciones del Input Map desde el diseño. |
❓ ¿Puedo exportar a Nintendo Switch o PlayStation desde Godot directamente? No de forma oficial: necesitas un acuerdo con el fabricante (devkit, NDA) y normalmente un porteador externo. Por eso el esfuerzo de consola es alto y se planifica aparte.
❓ ¿Web cuenta como plataforma con restricciones? Sí: hay límites de memoria del entorno WASM, algunas APIs no están disponibles y conviene el renderer Compatibility. Es ideal para demos, no siempre para el juego completo.
❓ ¿Debo elegir todas mis plataformas al principio? Al menos las principales, sí. Muchas decisiones de input, UI y renderer son difíciles de revertir; declararlas temprano ahorra rehacer trabajo.
❓ ¿La certificación aplica en Android e iOS? Hay revisión de tienda (políticas, contenido, permisos), más estricta en App Store. No es tan formal como la certificación de consola, pero puede rechazar tu build.
❓ ¿Diseño para la plataforma más limitada o para la más potente? Como regla, diseña el gameplay pensando en tu plataforma más restrictiva (input y potencia) y luego enriquece en las más capaces. Es mucho más fácil añadir efectos en PC que recortar un juego que solo cabe en un tope de gama.
❓ ¿Qué gano documentando el "riesgo principal" de cada port? Convierte un miedo difuso ("no sé si funcionará en móvil") en una tarea accionable ("validar controles táctiles en la semana 2"). Los riesgos escritos se mitigan; los no escritos explotan al final.
Clase 199 - Capstone Parte 10: una UI completa, accesible y localizada