DIARIO DE JA STUDIO APPS

Construir el mismo juego para móvil y escritorio

Space Runner nació como una experiencia vertical para Android y después incorporó una edición Windows. Documentamos aquí decisiones reales del proyecto, problemas encontrados y por qué algunas soluciones se mantienen diferentes en cada plataforma.

1. Una base compartida, dos experiencias

El proyecto utiliza LibGDX y Kotlin para compartir el núcleo del juego. Las pantallas, entidades, colisiones, recursos y traducciones viven en el módulo común. Android y escritorio agregan lanzadores propios porque no ofrecen las mismas capacidades.

Compartir el núcleo evita mantener dos juegos desconectados, pero no significa dibujar la misma interfaz sin ajustes. Un teléfono suele tener una pantalla vertical y entrada táctil; una computadora ofrece más ancho, teclado y posibilidad de dos jugadores. El objetivo es conservar reglas y contenido mientras la presentación respeta cada dispositivo.

Los componentes de interfaz reutilizables —botones, etiquetas, temas y navegación— reducen código repetido. Así, una corrección de color, alineación o comportamiento puede beneficiar varias pantallas sin redibujar manualmente cada elemento.

2. Escalado: porcentajes no siempre significan equilibrio

Las primeras pantallas calculaban posiciones como porcentajes directos del ancho y alto. Ese enfoque funciona bien dentro de proporciones similares, pero una ventana horizontal estira distancias y tamaños de forma distinta. La edición de escritorio necesita limitar el área útil y mantener relaciones visuales.

El escalador del proyecto conoce el tamaño real y una escala uniforme basada en el lado menor. Los diseños pueden centrar contenido en un área virtual y utilizar márgenes adicionales en pantallas anchas. El fondo sí puede ocupar toda la ventana, mientras HUD, naves y botones conservan proporciones reconocibles.

En Android la orientación del juego se mantiene vertical para proteger la composición original. La compatibilidad con pantallas grandes permite redimensionar cuando el sistema lo requiere, pero la experiencia principal continúa diseñada alrededor del recorrido vertical.

3. Cargar una textura una sola vez

Imágenes, fuentes, música y sonidos pueden provocar pausas si se cargan durante un cambio de pantalla. Space Runner utiliza un gestor de recursos con AssetManager y listas por contexto. Los elementos compartidos se solicitan una vez; la carga se presenta desde una pantalla dedicada antes de entrar a una sección pesada.

La tienda contiene variantes de naves, disparos y cinco familias de obstáculos. Mantener esas rutas en colecciones evita bloques repetidos. Las texturas usan filtrado lineal para conservar una apariencia suave cuando cambian de tamaño.

En escritorio surgió además una diferencia de audio: el backend utilizado requiere WAV PCM de 8 o 16 bits. Convertir archivos de 24 bits resolvió el fallo de carga sin alterar la lógica del sonido en Android.

4. Rendimiento en teléfonos de entrada

Un juego puede funcionar conectado a Android Studio y fallar después de publicarse si la compilación release transforma clases utilizadas por reflexión. Por eso la versión estable mantiene desactivada temporalmente la minificación de R8 mientras se validan reglas específicas de LibGDX. Estabilidad primero; reducción de tamaño después de pruebas reales.

Las colisiones comienzan con una prueba rectangular económica. Solo cuando existe superposición se realiza una comprobación más detallada. Los pixmaps utilizados para transparencia se almacenan en caché para evitar regenerarlos en cada fotograma.

También se evitan objetos innecesarios dentro del ciclo principal, se reutilizan fuentes y lotes de dibujo, y se limita el trabajo cuando una pantalla está pausada. El control por inclinación aplica lectura continua del acelerómetro; una respuesta agradable necesita suavizado suficiente para filtrar ruido sin crear retraso perceptible.

5. Botones, inclinación y teclado

Android ofrece dos estilos de movimiento seleccionables. Los botones son precisos y visibles. La inclinación libera espacio en pantalla, pero exige calibrar la postura y filtrar el sensor. Cuando se elige inclinación, los botones de dirección dejan de dibujarse para no duplicar controles.

En escritorio, las acciones principales tienen equivalentes de teclado. El modo local para dos jugadores asigna grupos separados de teclas y no muestra controles táctiles. Menús y pantallas también admiten navegación con teclado para que la edición no dependa constantemente del ratón.

La entrada se procesa separada del dibujo. Esta división permite actualizar estados de botones y punteros sin mezclar reglas de movimiento con el código visual.

6. Publicidad diferente en Android y web

La aplicación Android utiliza Google AdMob. El banner se aloja en una vista Android separada del área LibGDX y permanece en la parte inferior. Los anuncios recompensados se precargan y entregan la recompensa únicamente después de la confirmación correspondiente.

La edición Windows no incluye AdMob ni AdSense dentro del ejecutable. Se distribuye como producto independiente mediante itch.io. Este sitio puede utilizar AdSense cuando Google lo apruebe, con bloques separados de controles, botones de descarga y la misión interactiva.

Separar productos publicitarios evita utilizar un SDK móvil en un entorno para el que no fue diseñado. La política de privacidad explica proveedores, almacenamiento y opciones de consentimiento.

7. Preparar una actualización de Google Play

La versión 1.3.0 utiliza compileSdk y targetSdk 36. Cambiar el archivo Gradle no actualiza una versión ya publicada: es necesario generar un AAB firmado con un versionCode superior, probarlo y enviarlo a un canal de Google Play.

El paquete mantiene el mismo applicationId para que Play lo reconozca como actualización y debe firmarse con la misma clave utilizada anteriormente. Antes de producción conviene instalar una compilación release en un dispositivo físico, verificar el inicio sin cable USB, recorrer las pantallas y probar banner y recompensado.

La edición Windows se construye como un JAR completo y jpackage crea una imagen con ejecutable y runtime. La activación local se guarda fuera de la carpeta portable y se asocia al equipo para reducir copias casuales.

8. Qué sigue

Las siguientes mejoras deben guiarse por datos de estabilidad y comentarios reales: tiempos de inicio, dispositivos con fallos, dificultad de cada oleada y claridad de los tutoriales. Agregar contenido tiene valor cuando introduce una decisión nueva, no solo cuando aumenta la cantidad de objetos.

Este diario continuará en Actualizaciones. Si encontraste un problema reproducible, consulta la página de contacto y soporte e incluye plataforma, versión y pasos para reproducirlo.