Diseñar juegos móviles cuando cada dispositivo era un mundo
Entre 2006 y 2010 dirigí el diseño de juegos móviles. Cada teléfono tenía sus límites, y aquello me enseñó a decidir qué es esencial en un producto.
Entre 2006 y 2010 fui director de diseño en Kitmaker Entertainment, una empresa especializada en juegos, aplicaciones y contenidos para dispositivos móviles, con distribución internacional. Esa etapa aparece resumida en mi trayectoria, pero un resumen no cuenta lo más interesante, que es lo que significaba diseñar cuando el teléfono de cada usuario podía ser un mundo distinto del anterior.
Aclaro desde el principio que entonces no hacía Product Management. Mi cargo era director de diseño. Coordinaba la dirección visual y artística, participaba en las interfaces y los flujos, y trabajaba con equipos internos, con desarrolladores y con colaboradores remotos de otros países. Cuento lo que aquel trabajo me enseñó sobre límites, decisiones y escala, y por qué lo reconozco hoy cuando tomo decisiones de producto.
Un mercado anterior a la App Store
Conviene situar el momento. Cuando empecé en Kitmaker, el primer iPhone todavía no se había presentado. Se anunció en enero de 2007, salió a la venta en junio de ese año y la App Store no abrió hasta julio de 2008. Mi etapa empezó en un mundo y terminó cuando ese mundo ya estaba cambiando.
En aquel mundo, un juego llegaba al usuario a través de los portales de las operadoras, de los catálogos y de los agregadores. Se descargaba desde el propio teléfono y solía pagarse a través de la operadora. La distribución estaba tan condicionada por esos canales como el propio diseño, y cada canal tenía sus reglas.
Para entender los problemas hay que separar tres cosas que se mezclan con facilidad: el sistema operativo, la plataforma de ejecución y la aplicación. Java ME, que antes se llamaba J2ME, no era un sistema operativo sino un entorno de ejecución que funcionaba sobre el del teléfono. Un juego era un MIDlet, un programa escrito para el perfil MIDP sobre la configuración CLDC, y se distribuía como un archivo JAR acompañado de un descriptor JAD.
Symbian, en cambio, sí era un sistema operativo, con interfaces como la S60 de Nokia, y en esos teléfonos convivían aplicaciones nativas, escritas en C++, con aplicaciones Java. En los modelos más sencillos, como los Series 40 de Nokia, el sistema era propio del fabricante y Java era la vía habitual para instalar juegos.
Las versiones tampoco aclaraban tanto como parecía. MIDP 1.0 se aprobó en septiembre del año 2000 y MIDP 2.0 en noviembre de 2002. Que un teléfono declarase una de ellas decía poco de lo que había debajo, porque las implementaciones, las extensiones del fabricante y las condiciones del operador variaban de un modelo a otro.
Cada teléfono, su propio mundo
Llamarlo mundo no es una exageración, y las pantallas lo muestran bien. Un Series 40 de primera edición tenía 128×128 píxeles, y más tarde llegaron versiones de 128×160. Un Nokia 6600, con Symbian y S60, tenía 176×208. La segunda edición de Series 40 incluyó pantallas de 208×208, y la tercera trajo pantallas QVGA de 240×320, aunque algunos modelos de esa generación se quedaron en 128×160. Cito estos modelos como ejemplos del mercado, no como la lista de aquello con lo que trabajábamos.
Pero la pantalla era solo el principio. Estaban los teclados, con teclas programables cuyos códigos cambiaban según la marca, y los teléfonos de pluma, como los de la plataforma UIQ de Symbian, que se manejaban de otra manera. Estaban los formatos de sonido admitidos, la memoria para ejecutar el juego, el espacio para instalarlo y la rapidez con que cada terminal dibujaba en pantalla. Algunos fabricantes añadían sus propias extensiones a Java, y cada catálogo tenía condiciones propias para aceptar un producto.
La consecuencia práctica era que un juego no existía como una sola cosa. Existía como una familia de versiones, cada una pensada para un grupo de teléfonos. El diseño no terminaba al aprobar un concepto o un conjunto de pantallas. Terminaba cuando el producto cabía, se veía bien y se jugaba bien en los terminales a los que iba destinado.
Cada kilobyte importaba
Esta es la parte más técnica del trabajo, y la que más cambia la forma de mirar un gráfico. Primero estaba el tamaño. En los primeros Series 40, según la documentación para desarrolladores de Nokia de aquella época, el archivo JAR no podía pasar de 64 KB. En ese espacio tenían que caber el código, los gráficos, el sonido y los textos de un juego. Otros teléfonos y otros canales tenían límites propios, así que no existía una cifra general a la que ajustarse.
Eso convertía cada recurso visual en una negociación. El estándar MIDP obligaba a soportar imágenes PNG, y casi todo pasaba por ese formato. Una imagen indexada, con una paleta reducida, pesaba mucho menos que otra con muchos colores. Reducir una paleta de 256 colores a 64, a 32 o a 16 era una decisión de diseño con consecuencias directas. Un degradado suave se convertía en bandas, un detalle de contraste desaparecía y un personaje podía perder lo que lo hacía reconocible. Había que decidir qué colores sostenían la lectura y cuáles eran prescindibles.
Entre las técnicas habituales del oficio estaba eliminar lo que no aportaba y reutilizar todo lo posible, como el mismo fondo con otra paleta o un conjunto de piezas combinadas para formar escenarios distintos. También se agrupaban varios sprites en una sola imagen, para ahorrar lo que cada archivo añade por sí mismo, y se limpiaban los datos que algunas herramientas dejaban dentro de los PNG. El equilibrio entre calidad visual, legibilidad y peso cambiaba con cada teléfono.
Reducir un gráfico, revisar los colores, simplificar un detalle y probar otra vez era parte del trabajo. A veces el resultado se veía casi igual que el original, y otras obligaba a replantear el dibujo para que funcionara con menos. Lo que se aprendía era a distinguir lo que una imagen necesitaba para cumplir su función de lo que solo la adornaba.
Hay un matiz técnico que conviene no perder, y es que el tamaño del paquete y la memoria en ejecución no son lo mismo. Una imagen con pocos colores ocupa poco en el archivo gracias a la compresión. Cuando el teléfono la descomprime para dibujarla, en cambio, puede ocupar en memoria lo que dicten su anchura, su altura y el formato interno del dispositivo, que dependía de la implementación. Ahorrar en el JAR no garantizaba ahorrar en la memoria del juego en marcha, y cada una de las dos restricciones pedía sus propias decisiones.
Cada fotograma tenía un coste
Con las animaciones pasaba algo parecido, con un añadido. No solo pesaban, también tenían que leerse. Un personaje que anda, salta o recibe un golpe se construye con secuencias de imágenes. Más fotogramas daban más fluidez, y también más peso y, si se cargaban a la vez, más memoria. La relación con el rendimiento no era sencilla. Lo que costaba al procesador dependía sobre todo de cuánta pantalla se redibujaba y de cómo lo hiciera el juego, y no solo de cuántas imágenes hubiera guardadas.
Reducir fotogramas, por tanto, no era un truco para ir más rápido. Era una decisión sobre qué poses sostenían el movimiento. Un ciclo de carrera podía seguir entendiéndose con pocas imágenes si las poses clave estaban bien elegidas, y una animación con más fotogramas mal repartidos podía leerse peor. La frontera entre simplificar y empobrecer estaba en la legibilidad. Si el jugador dejaba de distinguir si el personaje saltaba o caía, la animación ya no cumplía su función, tuviera los fotogramas que tuviera.
Una animación podía verse mejor con más fotogramas. La mejor solución real, sin embargo, era la que funcionaba bien en el teléfono del usuario.
También se reutilizaba. Un personaje que mira a la izquierda es el mismo que mira a la derecha, reflejado. MIDP 2.0 incorporó una API de juegos con sprites que se podían reflejar y girar en múltiplos de 90 grados. En MIDP 1.0 no había acceso directo a los píxeles de una imagen, así que reflejarla en tiempo de ejecución no era una opción estándar. La versión reflejada podía ocupar su propio sitio en el paquete, salvo que el fabricante ofreciera extensiones propias.
El mismo producto, muchas veces
Adaptar un juego a muchos teléfonos era un trabajo en sí mismo, y yo trabajaba en ello desde el diseño. Una versión podía necesitar otra resolución y, con ella, otra distribución de los elementos en pantalla. Podía necesitar otras teclas para los mismos controles, otros recursos visuales y ajustes de rendimiento. Un idioma distinto cambiaba la longitud de los textos y obligaba a rehacer botones y menús. Cada operadora tenía requisitos propios, y cada mercado sus preferencias.
En la industria se hablaba de adaptar, o portar, el producto a cada terminal, y quienes distribuían a través de las operadoras solían tener que cubrir los modelos de cada red. Eso multiplicaba las versiones. Una cosa es diseñar un producto y otra conseguir que se instale y funcione en un catálogo amplio de terminales, en varios idiomas y para distintos canales. Esa segunda mitad del trabajo se veía menos y pesaba tanto como la primera.
Hoy hablaríamos de compatibilidad, de matrices de dispositivos, de gestión de variantes y de deuda de mantenimiento. El problema ya existía, aunque no se llamara así. Cada versión había que probarla, corregirla y mantenerla, y cuanto más se parecían entre sí, más barato resultaba hacerlo. Participé en procesos de estandarización y de escalado de catálogos digitales.
Dirigir diseño en un catálogo
Mi trabajo no se limitaba a lo técnico. Coordinaba el diseño gráfico y creativo, la ilustración, la animación, los recursos visuales y multimedia, las interfaces de los juegos y los materiales promocionales. Lo hacía con personas del equipo y con colaboradores externos, entre ellos profesionales freelance de otros países. Trabajar con colaboradores remotos era menos habitual entonces de lo que es hoy, y obligaba a que las cosas estuvieran claras para quien no podía preguntar en el pasillo.
Mantener la calidad y la consistencia visual cuando varias personas trabajan en productos, versiones y entregables distintos exige algo más que revisar si una pieza es bonita. Exige que los criterios se entiendan sin la presencia de quien los fijó, es decir, qué se considera suficiente, qué se puede sacrificar y qué no, y cuándo una versión está terminada.
Exige también coordinarse con programación y con producción, porque una decisión visual podía cambiar el peso de un paquete, la viabilidad de una versión o un plazo de entrega. Dirigir, en ese contexto, consistía en conseguir que las decisiones fueran claras, compartidas y ejecutables.
Lo que hoy veo como producto
Cuando miro aquella etapa desde producto, lo primero que veo es el efecto de los límites sobre las prioridades. Cuando no cabe todo, hay que decidir qué es esencial para la experiencia, y esa decisión se toma con más honestidad que cuando sobra margen. Es lo que defiendo hoy cuando digo que simplificar también es una decisión de producto.
También veo que la calidad depende del contexto de uso. Un juego técnicamente brillante que no funciona en el teléfono al que va destinado no es una buena solución, por muy bien que se vea en un ordenador. Y que escalar no consiste en hacer más versiones a mano, sino en buscar consistencia, reutilización y procesos que permitan gestionar la complejidad, de manera que añadir una variante cueste menos que la anterior.
Diseño y tecnología no eran mundos separados, porque una decisión visual alteraba la viabilidad técnica, los plazos y la experiencia a la vez. Quizá por eso me parece razonable pensar en los handoffs como deuda organizativa y no como un simple relevo.
La distribución, además, formaba parte del producto. No bastaba con construir algo: tenía que llegar al usuario en condiciones adecuadas, por el canal que lo ofrecía y bajo sus reglas. Y coordinar equipos también era construir producto, porque la claridad, los criterios compartidos y la relación entre especialidades decidían lo que acababa en el teléfono de alguien.
Lo que haría de otra manera
Con la perspectiva de hoy, hay cosas que haría con más sistema, y lo digo como reflexión y no como un reproche a nadie. Registraría las decisiones y las variantes, reuniría en un solo sitio las restricciones de cada familia de dispositivos y definiría criterios de calidad compartidos. Mediría mejor los problemas de uso, separaría con más cuidado lo esencial de lo accesorio y buscaría herramientas que redujeran el trabajo repetitivo.
Lo que enseñaban los límites
Aquellos teléfonos tenían muy poca memoria, pantallas limitadas y restricciones que hoy parecen absurdas, y precisamente por eso obligaban a decidir qué era realmente importante.
Con el tiempo he aprendido que el problema de producto sigue siendo parecido, aunque hayan cambiado los dispositivos. Hay límites, hay compromisos y hay decisiones que alguien tiene que tomar. Antes el límite venía impuesto por el teléfono. Hoy hay que ponérselo uno mismo.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.