En 2011 empecé mi carrera profesional en el desarrollo de videojuegos. Por aquél entonces no había motores de videojuegos 2D que cumplieran con mis expectativas en cuanto soporte y rendimiento, así que decidí crear mi propio motor.

Mis esfuerzos al desarrollar el motor fueron focalizados en dos puntos: que funcionara en cualquier dispositivo, por poco potente que fuera, y que se viera perfecto a cualquier resolución. Y lo conseguí. Mis juegos funcionaban en los dispositivos móviles más añejos, con las pantallas más minúsculas y en los móviles de última generación con las pantallas más punteras. Y, en todos ellos se veía tan bien que parecía diseñado ex profeso para ellos.

Aunque fue una experiencia interesante y aprendí mucho, no le recomiendo a nadie que quiera hacer juegos desarrollar paralelamente el motor con el que van a llevarse a cabo. Y, menos hoy en día que tenemos fantásticas opciones Open Source.

En 2017 di un cambio de rumbo laboral y decidí dejar mi motor atrás para pasar a utilizar Godot.

Nota: aunque aquí hablaré del motor de desarrollo Godot, los conceptos de adaptación de gráficos a cualquier pantalla sirven para cualquier motor. El artículo no es un tutorial de Godot, aunque en algunos conceptos se haga un paso a paso mediante la interfaz del mismo.

Godot Engine, el motor de desarrollo de juegos que estaba esperando

Después de unos 6 años desarrollando juegos para móviles decidí que era momento de pasar a hacer otro tipo de juegos y fue entonces cuando descubrí Godot. Se trata de un Open Source, multiplataforma, llevado por una comunidad de desarrolladores muy activa, que me permitía desarrollar juegos 2D, 3D y Realidad Virtual e incluso crear aplicaciones, de manera muy muy ligera.

Fue amor a primera vista. O casi, ya que ya había tenido un primer encuentro con él en 2014, cuando liberaron el motor. Sin embargo, en aquel entonces yo andaba muy enfrascado con mis proyectos como para poder prestarle atención. queda claro que a veces la primera vista no es suficiente.

El lenguaje de programación que Godot utiliza de base se llama GDScript y está fuertemente inspirado en Python, lo que lo hace un lenguaje fácil de aprender y muy conciso. También se puede programar en C# y en C++, pero realmente no son necesarios para la gran mayoría de proyectos: aunque sepamos alguno de estos dos lenguajes, GDScript es suficientemente óptimo y ágil como para que valga la pena aprenderlo. Además, como he dicho antes, es muy fácil de aprender, pero más si sabes otros lenguajes de programación.

El workflow, cada vez más depurado, permite crear con agilidad cualquier idea que se nos venga a la mente. Tiene sus puntos flacos, como toda pieza de software, pero que acabarán siendo pulidos por el equipo de desarrollo y su extensa comunidad.

Estos días se celebra el décimo aniversario de la liberación del proyecto y ha habido muchos cambios. En los últimos meses se creó una fundación que tiene como principal cometido asegurar que el proyecto seguirá siendo Open Source y gratuito, además de gestionar los recursos destinados a la contratación de mantenedores que aseguren que el proyecto salga adelante. En el momento de escribir este artículo, nos encontramos en la versión 4.2 que goza de muchas características que lo ponen al nivel de los grandes motores comerciales.

El futuro de Godot pinta aún mejor y voy a hacer lo posible por contribuir en él.

Creando juegos para dispositivos móviles

En estos últimos años he hecho muchos juegos y experimentos en 2D, 3D, VR, Apps y juegos que interactúan con los espectadores de los canales de directos, y prácticamente todos han tenido su versión para dispositivos móviles.

Godot hace inmediato el paso de nuestros proyectos a dispositivos con el sistema operativo Android, siendo lo más tedioso el proceso de configuración del kit de desarrollo de este último (y que es el mismo para cualquier otro motor).

Para saber qué pasos se deben seguir para configurar el SDK de Android y utilizarlo en Godot, aquí os dejo la documentación oficial del proyecto:

https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_android.html

Para activar las opciones de desarrollo en el dispositivo móvil seguiremos los pasos que se correspondan con nuestro dispositivo ya que, aunque el proceso es más o menos el mismo para todos, puede depender de cómo, el fabricante del dispositivo haya diseñado la interfaz de configuración. En este caso, he utilizado un Samsung Galaxy S9 Ultra para documentar el artículo:

1. Acceder a los ajustes del dispositivo
2. Buscar la opción “Acerca de…”, en este caso “Acerca de la tableta”. Suele ser la última opción.
3. Buscaremos “Información de software”
4. Daremos 6 o 7 toques a “Número de compilación”. Sí, puede parecer extraño, pero es una medida de seguridad para evitar que cualquiera que no sepa lo que está haciendo active las opciones de desarrollo sin más.

[Figura 1: Dando toques a “Número de compilación” para activar el “Modo desarrollador”]

Al acabar, puede que el sistema nos pida confirmación mediante algún método de autenticación (pin, huella dactilar, etc.). Una vez introducido, nos aparecerá una nueva opción en el menú de los ajustes: “Modo desarrollador”.

[Figura 2: “Modo desarrollador”]

Una vez configurado todo, en Godot es tan sencillo como:

• Acceder a la opción “Exportar”, que se encuentra dentro del menú “Proyecto”.
• Añadir el exportador de Android en “añadir”. En caso de no tener un exportador, aparecerá un mensaje en rojo con enlaces [Figura 3]. Dichos enlaces abrirán pantallas que nos facilitarán la incorporación de los exportadores (la descarga es grande, porque no sólo descargará el exportador de Android, también el del resto de las plataformas).
• Ahora únicamente debemos dar un nombre único al paquete de nuestro proyecto, en el panel de opciones que aparece al seleccionar “Android”. Los nombres únicos en Android tienen la siguiente forma “extensión.dominio.proyecto”, en mi caso sería “com.rafalagoon.juego” o lo que corresponda con nuestro dominio y proyecto. Si no tenemos dominio, podemos crearlo sin uno, ya que es mera referencia, pero al publicarlo en las tiendas online podemos tener problemas. Ahora, no hace falta.

[Figura 3: “Mensajes de instalación de plantillas de exportación”]

Ahora, ya lo tenemos todo preparado para probar nuestros juegos en nuestros dispositivos móviles.

Cuando la fragmentación es un problema

Tantas pantallas, tantas formas, tantas configuraciones… El mundo del desarrollo para dispositivos móviles es un lugar en el que se hace prácticamente imposible predecir qué características tendrán los dispositivos en los que se ejecute. Con los ordenadores de escritorio y portátiles puede pasar algo similar, pero aquí tenemos un área donde la innovación es continua: las pantallas.

Pantallas panorámicas, plegables, extrapanorámicas, con el tamaño de un reloj de pulsera, ultrapanorámicas… Y nuestros juegos tienen que encajar en ellas lo mejor posible.

Por lo general cuando diseñamos juegos, sobre todo 2D, lo hacemos con una resolución concreta en mente. Debido a esto, el arte y el diseño de UI de cada una de las pantallas estará pensada de tal manera que todo encaje a la perfección: fondos, la disposición de personajes y objetos, etc. Y cuando esto ocurre, si lanzamos nuestro juego en pantallas con una resolución distinta, aparecerán unas franjas negras en los laterales o incluso puede que se reescale todo de cualquier manera.

A continuación, podréis ver una pequeña guía que he preparado para poder asegurar que nuestros juegos se adapten lo más dignamente posible a cualquier pantalla con la que nos encontremos. Todo lo que veremos sale de la experiencia y de probar mis juegos en muchos, muchos dispositivos.

Resoluciones y ratios

Primero de todo, hemos de entender los siguientes conceptos:

• Resolución es la cantidad total de píxeles que contiene una pantalla en alto y ancho. Se expresa comúnmente como dos números separados por una “x”. Por ejemplo, 1920x1080 o 1920 píxeles de ancho por 1080 píxeles de alto (un total de 2073600 píxeles). A mayor cantidad de píxeles más resolución y mayor calidad de imagen.
   
• Ratio, o relación de aspecto, se refiere a la proporción entre el ancho y el alto de la pantalla. Se representa con dos números separados por “:”. Por ejemplo 16:9, 16 unidades de ancho por 9 de alto. Si hacemos la división, 16/9 = 1.778. El resultado de esta división será igual a la división del alto y el ancho de la resolución equivalente a dicho ratio. Siguiendo el ejemplo del punto anterior 1920/1080 = 1.778. Es decir, que la resolución 1920x1080 tiene un ratio de 16:9.

Distintas resoluciones pueden tener la misma relación de aspecto: 1280x720 (HD), 1920x1080 (FullHD) y 3840x2160 (4k) las tres son 16:9 (o 1.778).

Otro ejemplo es una resolución bastante común durante los 2010 era 960x640 que tenían muchos dispositivos de gama media-baja. El ratio de aspecto es 6:4 (1.5).

Otras resoluciones muy interesantes las encontramos en los últimos dispositivos de Samsung:

Samsung Tab S9 Ultra

2960x1848 = 1.6 = 16:10

Samsung Z Fold5

Externa: 2316×904 = 2.562 = ~23:9

Interna: 2176x1812 = 1.2 = 6:5

En este último caso, el Samsung Z Fold5 ¡tiene dos pantallas! Y ambas muy especiales en cuanto a resolución y ratio.

Hay multitud de ratios, sólo hace falta echar un ojo a la lista que tiene Wikipedia de las más comunes:

https://es.wikipedia.org/wiki/Relaci%C3%B3n_de_aspecto

¿Cómo nos adaptamos?

No hay una fórmula mágica, pero sí que hay un par de consideraciones a tener en cuenta en el momento de diseñar las interfaces y pantallas de nuestros juegos.

1. Ratios antes que resoluciones

Una vez entendido cómo funcionan los ratios, vemos que las resoluciones HD, FHD y 4K tienen el mismo ratio y, por lo tanto, podemos reescalar de una resolución a otra sin deformar o cortar la imagen.

Pero ¿cómo adaptar la imagen a otros ratios?

Lo que haremos será diseñar pensando en el ratio más pequeño y común 6:4, pero, además, tendremos en cuenta al componer nuestras pantallas los dos ratios más comunes en diferentes ámbitos: 16:9, panorámica (para smartphones y pantallas de sobremesa) y 5:4 (para tablets), muy cercana a ser cuadrada y que a simple vista se parece al ratio 4:3 que tenían las pantallas de los 90 y principios de los 2000.

¿Por qué tener en cuenta estas resoluciones?

Veámoslo con la plantilla de ratios que creé hace más de 10 años y que actualizo cada tanto para tener en cuenta los nuevos ratios.

[Figura 4: Plantilla de ratios]

Cada color representa el principio y el final del ratio correspondiente, formando un rectángulo cuya superficie forma el lienzo visible en pantalla sobre el que trabajaremos.

Trabajar utilizando esta plantilla nos permite diseñar para cualquier ratio que pueda aparecer, siempre y cuando trabajemos con la orientación horizontal (landscape). En el caso de querer hacer diseños de orientación vertical (portrait) deberíamos diseñarlo con la imagen rotada 90º.

Los ratios anteriormente indicados (6:4, 16:9 y 5:4) juntos forman lo que yo llamo el meta-ratio: 1.479.

[Figura 5: El meta-ratio]

¿Cómo usar esta proporción?

La zona verde (ratio 6:4) es la que seguro aparecerá en cualquier pantalla. A partir de aquí, debemos decidir si hacemos un diseño panorámico (16:9, típico de muchos móviles de gama media y de pantallas de PC) o más tradicional (5:4, presente en muchas tablets).

Nuestro diseño cubrirá toda la superficie del meta-ratio, pero las zonas claves para el usuario sólo estarán presentes en la zona verde y en la zona del ratio que se corresponda con el diseño escogido (16:9 o 5:4). La otra zona no debe dejarse de lado: se utilizará para esos detalles que aportan contexto a nuestro juego, pero que en caso de no mostrarse no importan (techos, suelos, paredes, ventanas, etc.).

¿Y qué hay del resto de ratios?

Depende de nuestro criterio:

• Integrarlos de tal manera que si el usuario tiene un móvil con resoluciones especiales (en nuestro ejemplo, ultrapanorámicas) se vea recompensado con algún elemento extra que otros dispositivos no vean, pero que no aporte nada más que un extra en la experiencia de nuestro juego. Animaciones, detalles, pequeñas sorpresas, easter eggs…
• Aprovechar el espacio y recalcular el lugar donde se colocan controles, interfaz y demás elementos.
• Podemos poner un fondo sencillo, para que no quede vacío.
• Podemos ignorarlos totalmente dejando franjas negras, que es lo que ocurre por defecto en la mayoría de motores de videojuegos.

2. El tamaño importa

En este punto debemos pensar en qué resolución deben tener nuestros gráficos y cómo vamos a diseñarlos acorde con los ratios.

La plantilla de ratios está pensada para que la zona 16:9 tenga un tamaño 4K (3840x2160), siendo la resolución más grande actualmente de esta proporción (existe 8K, pero su uso es mínimo y sólo se encuentra en grandes pantallas de televisión o monitores profesionales).

Diseñar todos los elementos a la resolución más grande nos permitirá escalar nuestros gráficos “hacia abajo” (de 4K a FHD y a HD) sin perder detalle. Quizá sean necesarios algunos ajustes para gráficos que queden poco definidos con el escalado, pero serán mínimos.

Las imágenes resultantes serán enormes, pero vale la pena trabajar a un ratio proporcional y estándar y a la resolución más grande.

En caso de no trabajar con la resolución más grande, si utilizamos programas de diseño que hagan uso de gráficos vectoriales será fácil escalar a tamaños mayores y que todo quede bien, pero con herramientas que trabajan con bitmap (píxeles) siempre quedará borroso.

Una vez creado todo el arte y las interfaces a 4K, rellenando el resto del espacio de las resoluciones más grandes, podemos exportar con el formato que utilice nuestro motor de desarrollo de juegos (en este caso Godot).

El formato PNG suele ser el ideal si no queremos pérdida de calidad en la imagen y tiene soporte de transparencia, por lo que lo utilizaría para elementos del juego que vayan a ser colocados encima del fondo. Para fondos y elementos sin transparencia utilizaría el formato JPEG con una compresión baja, ya que a más compresión más pérdida de calidad.

Ahora hay tres posibilidades:

• Podemos utilizar los gráficos tal cual salen del programa, como si fueran a ser mostrados en resoluciones 4K y reescalar dentro del propio motor del juego para que encaje en resoluciones FHD o menores. Esto añade mucho peso en la app, y ralentiza la carga de la app, ya que todos los gráficos serán de gran tamaño, aunque la pantalla sea muy pequeña. Además, puede dar errores durante la carga al necesitar más memoria.
• Reescalar antes de exportar para que todos los gráficos estén en la resolución intermedia (FHD) y encoger (para HD) o agrandar (para 4K) la escala dependiendo de la resolución de la pantalla. Esto es bastante habitual y hace que los dispositivos menos potentes no se resientan, pero que en resoluciones altas (4K) los gráficos se vean algo más borrosos, aunque nada exagerado. Por lo general, esta es la opción escogida por la gran mayoría de desarrolladores.
• Generar, en el momento de la exportación, 3 paquetes de gráficos adaptados a las 3 resoluciones de pantalla que hemos comentado. Esto tiene mayor coste temporal de desarrollo y ocupa más espacio en el momento de empaquetar la app, pero como resultado tendremos gráficos que se verán perfectamente en todas las resoluciones y el tiempo de carga y consumo de memoria será proporcional a la potencia media de los dispositivos. Hay multitud de herramientas que pueden ayudarnos a preparar nuestros gráficos de esta manera (generadores de hojas de sprites, reescaladores automatizados, etc.). Es la manera que yo utilizo para mis proyectos comerciales y da mejores resultados.

Implementando el escalado

Vamos a hacer un paso a paso con Godot para entender cómo podemos adaptar nuestros juegos a cualquier resolución. En este ejemplo, trabajaremos con el ratio 16:9 y resolución FHD.

Crearemos un proyecto en modo “Móvil” o “Compatibilidad”.

[Figura 6: Creación de proyecto]

Y al entrar en el proyecto añadiremos una escena 2D.

[Figura 7: Creación escena 2D]

Vamos a configurar el proyecto para que sea coherente con nuestro diseño.

Accederemos a la configuración del proyecto: en el menú “Proyecto”, acceder a “Configuración de proyecto”, y dentro de la ventana que aparecerá acceder a “Ventana”. Una vez ahí, en las opciones que nos aparecen, cambiaremos “Ancho del Viewport” por 1920 y “Altura de Viewport” por 1080.

[Figura 8: Configuración de alto y ancho de viewport]

De nuevo en el proyecto, añadiremos la plantilla copiando el archivo PNG de la misma al directorio de nuestro proyecto. Si lo hemos hecho bien, aparecerá en el panel “Sistema de Archivos”.

Ahora, arrastramos la plantilla a la escena (al lienzo de nuestro proyecto). Veremos la plantilla con sus colores y en el centro (más o menos) un rectángulo con unas líneas muy sutiles que representa los límites de la escena.

[Figura 9: Plantilla en la escena]

¡Nuestra plantilla es enorme! Así que debemos escalarla: seleccionaremos la plantilla, lo que activará el inspector. Desplegamos “Offset”, donde la opción “Centered” viene seleccionada por defecto, de no ser así seleccionaremos esta opción.

[Figura 10: Inspector]

Ahora, en “Transform” cambiaremos la escala poniendo “Scale” a 0.5 (la plantilla está a 4K, así que para adaptarla a FHD tenemos que dividir por la mitad). La plantilla no está centrada en la escena, así que la centraremos cambiando “Position” a 960 en “X” y 540 en “Y”.

[Figura 11: Transform]

Ahora, volvamos al árbol de nodos y añadiremos una cámara 2D. Para ello haremos clic en “+”, debajo de la pestaña “Escena” y seleccionaremos “Camera2D”.

[Figura 12: Camera 2D]

En el inspector nos aseguraremos de que la opción “Drag Center” esté activa y cambiaremos “Position” por 960 en “X” y 540 en “Y”. La escala no la tocamos.

[Figura 13: Propiedades de la cámara]

¡Vamos a probar el resultado! Conectaremos la tablet o el smartphone mediante USB y nos aseguramos que nuestro PC acceda al dispositivo (posiblemente aparezca una pantalla de confirmación).

Lanzamos el proyecto utilizando el botón de “Depuración Remota”, seleccionando el dispositivo sobre el que haremos las pruebas. En este caso, el “Samsung Tab S9 Ultra” que aparece con el nombre de modelo “Samsung SM-X910”.

[Figura 14 Depuración remota]

Lo ejecutamos y… la imagen sale centrada, no se adapta a la pantalla. En otros dispositivos puede haber quedado distinto o haber encajado perfectamente si son FHD. Sea como sea, no debemos conformarnos.

[Figura 15: Plantilla con márgenes grises]

El motivo es que no hemos dicho a Godot que adapte el “viewport” a la resolución de la pantalla.

Vamos de nuevo a la configuración del proyecto y buscaremos la sección “Estirar”. Por defecto, el modo de estirado será “disabled” (desactivado) y el aspecto “keep”. “Escala” y “Modo de Escala” no los tocaremos en este ejemplo.

Hay dos modos de estirado: “canvas_items”, que estira individualmente cada uno de los elementos siendo nosotros los encargados de readaptar todos los elementos en pantalla, y “viewport”, que reescala toda la escena de manera uniforme. En este caso, y para este ejemplo, será este último el que vamos a escoger.

En cuanto “Aspecto”, todas las opciones excepto “expand” conservan el ratio de pantalla escogido, poniendo franjas negras. Como queremos que nuestro proyecto se adapte a cualquier resolución, escogeremos “expand”.

[Figura 16: “viewport” y “expand”]

Ahora, volvemos a lanzar el proyecto…

[Figura 17: Proyecto mejor adaptado]

¡Se ajusta al ancho como un guante! En la parte superior podemos observar parte de las franjas del ratio “cuadrado” que, si hubiera arte, deberíamos haber tenido en cuenta en el momento de diseñar la pantalla.

Pero ¿qué hay de otras resoluciones? Vamos a probar el mismo proceso con el “Samsung Z Fold5” que tiene 2 pantallas, a ver qué tal se ajusta a ambas. Empezaremos por la exterior, la más panorámica.

[Foto 18: Panorámica]

¡Encaja perfecto! No hemos llegado al ratio límite (24:1), pero asoma un poco. En este caso, dependiendo del juego, añadir un fondo bonito con una pequeña animación podría ayudar mucho en el hacer sentir más integrados a los usuarios con pantallas tán panorámicas.

Vamos a abrir el dispositivo para activar la pantalla interna que es de proporciones más cuadradas.

[Foto 19: Pantalla cuadrada]

¡Encaja perfecto! En este caso, se muestra toda la pantalla que engloba 16:9 y 6:5.

¿Y los ratios que no controlamos?

Aunque esto podría funcionar perfectamente para toda resolución y ratio, no sabemos si aparecerán pantallas con mayor resolución y ratios distintos.

Así que lo ideal sería hacer una función que detecte el tamaño en el que se ha escalado nuestro viewport y cambiar el zoom de la cámara para que se adapte a nuestras exigencias de ratio. Esto, aunque pueda parecer complicado, al final son “reglas de tres” fáciles de aplicar.

Por ejemplo, podemos controlar el alto del viewport que se genera al estirarse automáticamente y el tamaño máximo del alto que queremos para nuestra pantalla. La relación entre ambos es la cantidad de zoom que debemos aplicar para que se adapte.

[Figura 20: Ejemplo de código sencillo de zoom automático]

Conclusiones

Es muy satisfactorio hacer juegos que se adapten a cualquier pantalla, pero también a cualquier tipo de dispositivo y control. De hecho, gracias a todo lo que hemos hecho en este artículo, estamos mejorando la accesibilidad de nuestro proyecto, aunque sea un poquito.

Existen multitud de dispositivos y todos merecen que nuestro juego se adapte a ellos en las mejores condiciones.

Probando el Samsung Z Fold5 he descubierto que hay juegos comerciales que no sólo no se adaptan a sus pantallas de ratios peculiares… pero algo que he visto que es muy común es que, al pasar de una pantalla a la otra, se reinician o no se pueden adaptar. En algunos casos puede estar justificado, pero en otros tantos es debido a que no han pensado en que existen otros ratios.

En el caso de nuestra app se adapta sin problemas al cambio. Y sí, como he dicho, es muy satisfactorio hacer juegos que se adapten a todas las pantallas, pero ahora pensemos en la satisfacción de los jugadores que encuentran un juego que se adapta perfectamente a sus dispositivos, sin franjas negras, sin escalados que rompen el diseño. Y en eso consiste, en parte, el diseño de juegos: en el diseño de lo satisfactorio y accesible para el máximo número de personas posible.

[Figura 21: Dispositivos de Samsung con ratios totalmente distintos con la misma app]

Sobre el autor

Rafa Laguna es desarrollador de videojuegos, profesor universitario y de ciclos formativos y creador de contenido en Twitch donde realiza streamings prácticamente a diario y en Youtube donde tiene un canal personal y uno especializado en desarrollo de videojuegos con Godot (Todogodot).

Twitch | YouTube - Rafa Lagoon | YouTube - Todo Godot

Link al repositorio del proyecto donde se encuentra la plantilla y un ejemplo:

https://github.com/rafalagoon/resolutions_demo