De iPhone a AppUp: Migración de "Ancient Frog"
El siguiente es la continuación de una serie de artículos sobre la migración de aplicaciones desde el iPhone* al centro Intel AppUp(SM). Esta es mi entrevista con el desarrollador James Brown relacionada con su experiencia al migrar su juego galardonado "Ancient Frog" de iPhone al centro Intel AppUp.
P. ¿En qué se inspiró para crear el juego?
James Brown:
Ancient Frog nació de mi separación de la industria de juegos populares. Mi experiencia era muy amplia, había trabajado como diseñador, programador, artista, productor. Pero la industria de juegos se había convertido en algo enorme y muy estratificado y terminé en Lionhead, una división de Microsoft, como gerente de un equipo de programadores sin contribuciones creativas verdaderas, lo cual era lo más alejado de mi trabajo ideal de lo que podría imaginarme.
Decidí volver a comenzar a crear mis propios juegos. Fui guiado a la idea para Ancient Frog por las restricciones que me había fijado a mí mismo. Necesitaba un juego lo suficientemente pequeño que un solo desarrollador pudiera completarlo y satisfacer un estándar profesional. Con un juego rompecabezas, una vez que resuelves la mecánica del rompecabezas, el resto son solo variaciones sobre ese tema. También deseaba un personaje central, simpático sin ser infantil, con un poco de personalidad. Debido a que no soy un animador, eso me obligó a considerar sistemas de animación de procedimiento y la idea de un juego con escala de montañas que involucrara una salamanquesa surgió de todo eso.
Una vez que diagramé un prototipo con dibujos muy sencillos, la idea sufrió una metamorfosis y evolucionó a medida que iba jugando con él. La salamanquesa se convirtió en una rana debido a que las ranas tienen patas traseras más largas que las delanteras, lo cual introduce algunas decisiones muy interesantes para el jugador. El aspecto de escalar desapareció para introducir la idea más abstracta de pisar sobre gotas. El sistema de animación se volvió más explícito (no se puede dirigir a la rana, uno tiene que arrastrarla una pata cada vez), haciendo que el rompecabezas fuera más interesante, y eso quería decir que el jugador era el que estaba creando la animación, en lugar del juego.
Fue un recorrido bastante largo desde el prototipo inicial hasta el juego final (durante ese tiempo me mudé a otro país por un tiempo para crear programas interactivos digitales para museos), pero la idea fundamental permaneció muy clara en mi mente todo ese tiempo.
P. El aspecto de Ancient Frog es muy peculiar. ¿Qué utilizó para diseñar este juego, por ejemplo, herramientas, unas API?James Brown:
La herramienta principal para la creación de este juego fue el juego mismo. La mayoría del código escrito para Ancient Frog pasó por las herramientas internas y editores (inclusive el código para generar el rompecabezas y para buscar las soluciones óptimas para ellos, el cual fue un desafío particularmente interesante). El aspecto más importante de concretar el diseño preciso fue el hecho de que hice lo posible porque todo lo que creara se modificara al instante. No existe un substituto a la iteración constante, cuando se trata de crear una experiencia interactiva agradable. Prueba algo, examínalo, corrígelo, pruébalo y dale vueltas hasta que todas las imperfecciones y los impedimentos sean eliminados. A continuación, sigue adelante agregando los detalles que deleitan y sorprenden. Acto seguido, vuelve a eliminar las imperfecciones y los impedimentos que se introdujeron.
Todo es guiado por los datos y al supervisar el disco para determinar cambios, el juego puede recargar cualquier edición sin dificultades. Pinta una textura en Photoshop*, haz clic en Guardar y aparece directamente en el juego. No hay números mágicos en el código: tengo una pequeña clase 'rule' de plantilla que se comporta como un tipo nativo así que existe un umbral extremadamente bajo de conveniencia para exponer todo a los datos. ¿La ligereza de esa pata? ¿La duración de ese encadenado? ¿La aceleración debido a la gravedad? Incluso cuando estoy seguro que nunca desearé cambiarlo, allí está y si se me ocurre cuando estoy haciendo pruebas, simplemente puedo seguir cambiando lo que se me antoje y ver lo que sucede mientras hago cambios. Si usted necesita detener, recompilar y reproducir hasta donde estaba, rápidamente llegará al punto en el cual un cambio es demasiado esfuerzo para ocuparse de él.
El aspecto peculiar de Ancient Frog realmente resultó del requisito autoimpuesto de lograr una independencia de resolución máxima. Deseaba ejecutar a cualquier resolución a partir de 640x480 hasta, digamos, un monitor doble de 1920x1200 y a cualquier tasa de aspecto desde pantalla estándar hasta pantalla ancha. Una de las cosas que me había molestado sobre mi anterior juego en Lionhead era que cambiar la resolución requería el reinicio del juego. Ahora que estaba haciendo todo por mi cuenta, deseaba hacer todo correctamente, así que no solamente iba a permitir los cambios de resolución instantáneos, sino que iba a hacerlo de manera que pudiera seleccionar la ventana y arrastrarla a cualquier forma o tamaño y observar mientras el contenido se ajustaba sin dificultadas a medida que lo hiciera. Parecería una decisión técnica extrañamente trivial pero resultó en un impacto gigantesco en términos de aspecto único del juego y en la habilidad de migrar a una variedad más amplia de plataformas.
Si me hubiera conformado con una pequeña cantidad de tasas de aspecto razonable, hubiera sobrevivido creando gráficos con un margen pequeño adicional por los bordes y recortándolos para ajustarlos, pero el hecho de que cada vez que ejecutaba el juego podría manipular el tamaño de la ventana significó que deseaba ver qué pasaría si lo hiciera realmente ancho. O alto. O gigantesco. O diminuto. Y cuando se hace eso, rápidamente se topa con los límites de los diseños fijos. De manera que creé un motor de diseño guiado por archivos a nivel xml, lo cual agregaba niveles en capas. Cada capa puede tener todo tipo de reglas de diseño pero la estrategia básica consiste en tener una capa que sostenga el área de juego, que trata de ser tan grande como para caber en la ventana y una o más capas de primer plano y fondo que se pueden mostrar en mosaico, alargadas o recortadas para completar el resto de la pantalla.
Una vez que surgió la idea de construir los niveles en capas, fue natural usar eso para introducir algo de vida y movimiento a la pantalla, algo de profundidad de campo, algo de paralaje. Utilicé fotografías para suministrar las texturas para las capas: hojas, troncos de árboles, musgo, piedras, etc. y había algo prometedor acerca de este método, pero durante varios meses no se combinaba como una unidad coherente. La revelación se manifestó cuando estaba limpiando el desagüe en frente de mi casa y me distraje con el patrón de las sombras de los árboles en la puerta de garaje. Era un baile que evolucionaba constantemente, pero con una simplicidad subyacente basada en la interacción de unas cuantas formas y ritmos. Cuando regresé adentro, codifiqué una copia de ese efecto y lo superpuse sobre cada nivel usando una combinación multiplicativa para dar a todo un aspecto saturado enriquecido y terminé cimentando el estilo de todo el juego.
P. ¿En cuántos dispositivos está Ancient Frog y comenzó su desarrollo con el desarrollo de xplatform?
James Brown:
Ancient Frog está disponible en el iPhone* e iPad* de Apple*, Pre* y Pixi* de Palm* y ahora en netbooks basados en el procesador Intel® Atom™. También tengo una migración a Android* (pero en la actualidad no hay manera de venderla desde Nueva Zelanda) y las versiones para equipos de sobremesa PC y Mac, donde todavía estoy indeciso sobre los mejores canales de ventas.
El prototipo inicial fue escrito en realidad para mi teléfono (por entonces, un dispositivo Windows* Mobile con una pantalla 240x240). La mayoría de mis juegos se jugaban en momentos estrambóticos tales como en la parada del autobús o frente al cajero en el supermercado y deseaba crear algo para ese estilo juego. Pero esto fue antes de que se inventara el iPhone*: el mercado del smartphone estaba muy fragmentado y yo realmente no tenía una idea clara de qué especificaciones deberían ser mi punto de enfoque o cómo podría vender un juego a los usuarios de smartphones. De manera que dejé eso a un lado y dirigí mi atención al desarrollo para el PC. Pero la idea de poner el juego en el teléfono en algún momento en el futuro permaneció en mi mente, y durante el desarrollo, la capacidad de migración y escala eran centrales en mi manera de pensar.
He descubierto que cuanto menos dependo de bibliotecas externas, tanto más portátil es mi código. Es cierto que existen buenos argumentos para todo tipo de bibliotecas de utilidades, motores o middleware, pero éstos son solamente una ventaja si avanzan a una plataforma de destino interesante en su futuro. Si resulta que una de sus dependencias no funciona en el destino en el que está interesado, entonces no puede hacer mucho al respecto. Yo sí uso SDL (Simple DirectMedia Layer) en el PC, pero es una capa muy delgada y es lo suficientemente sencilla para codificar alternativas si se necesita (como tuve que hacer para iPhone* y Android*).
Por lo demás, es solo código C++ enfocado en OpenGL*. C++ es una opción segura, no importa qué lenguaje extraño sea recomendado para una plataforma particular, puede estar seguro que el compilador C/C++ se uso primero (aunque sea solo para compilar ese lenguaje). OpenGL* está disponible muy ampliamente de manera predeterminada (incluso en Windows*, ellos prefieren que se use Direct3D* pero no van a ir tan lejos como para insistir en ello). Además es muy sencillo utilizar un subconjunto bien definido de OpenGL* y en plataformas donde no está disponible, implemente sólo ese subconjunto por su cuenta.
Realizo la mayoría de mi desarrollo en Windows* usando Microsoft Visual Studio*, pero utilizo un Macbook* Pro para el desarrollo si deseo salir de la oficina. Es muy ventajoso para la capacidad de migración de su código si compila con regularidad en dos distintos compiladores y sistemas operativos. Eso es suficiente para resolver la mayoría de los problemas en varias plataformas antes de echar raíces y asentarse en algún lugar de manera incómoda, así que no he tenido muchas sorpresas durante la migración a otra plataforma.
P. ¿Qué herramientas y método utilizó para migrar su aplicación para una experiencia de netbook y por qué decidió ir en esa dirección?
James Brown:
El juego ya funcionaba en Windows* y las resoluciones para netbook ya fueron cubiertas por el trabajo que realicé en esa otra plataforma originalmente, de manera que 'migración' es posiblemente un término demasiado exagerado para el trabajo que era necesario.
No pude probarlo en una gama muy amplia de hardware de destino, de manera que compilé usando la configuración más conservadora, mi motor de juego tiene unas cuantas opciones que puedo utilizar según las capacidades del destino y apagué los objetos de framebuffer y la asistencia de sombreador. Cuando tenga un poco más de datos en el nivel de compatibilidad con el controlador en más plataformas, probablemente los encenderé y haré que el juego sea más atractivo.
P. ¿Qué hizo para resolver las diferencias de hardware tales como la función multitáctil frente al uso del ratón con el teclado y un acelerómetro en el iPhone*?
James Brown:
En realidad, Ancient Frog no utiliza ningún hardware que no pueda ser duplicado con un ratón o trackpad. Utilizo el acelerómetro para influenciar la dirección en que caen los pétalos en la animación 'win' pero perder eso no afecta en nada el juego. Se utiliza la función multitáctil en la versión para iPad* para insertar más de un dedo en el agua a la vez, pero no es gran cosa perder esa habilidad.
En las versiones para pantalla táctil de Ancient Frog, el juego comienza con un tutorial de introducción que quita el control del jugador. Algunos jugadores admitieron que esto les molesta y fastidia (pero las pruebas de juego han mostrado que era necesario para enseñar algunos de los gestos de control). Pero por algún motivo, en un equipo con control indirecto, tal como un ratón o trackpad, se vuelve algo completamente inaceptable. No estoy seguro por qué, posiblemente es que no responder a un toque es algo que siempre es sensible al contexto y tan esperado mientras que no responder al ratón se siente como si el equipo se hubiera bloqueado y esto fuera inesperado.
De cualquier manera, tengo la oportunidad de cambiar el tutorial para que sea una fuente de sugerencias más práctica. También quité los gestos 'deshacer' y 'rehacer', en parte porque los gestos son incómodos en un dispositivo de ratón o trackpad, y en parte porque el espacio de pantalla adicional significa que existe más espacio para los botones en pantalla. Tener botones en pantalla también significa que se anima al jugador a jugar con ellos para ver qué sucede, lo cual elimina parte de la carga del tutorial.
P: ¿Hubo algo que lo sorprendiera sobre el proceso de migración? ¿Fue más difícil o más sencillo de lo que creía? ¿Perdió o mejoró características para el netbook?
James Brown:
El enfoque que utiliza Ancient Frog para crear su aspecto, con varios pases para combinar, se lleva a cabo a una tasa de rellenado muy intensa. Me había costado mucho en la migración a iPad*, la cual había completado justo antes de la versión para netbook, debido a que la GPU de iPad* sencillamente no podía manejar tanta carga. Puse mucho empeño en incorporar el brillo a las texturas, en eliminar elementos del diseño y, en general, en simplificarlo de manera que pudiera ejecutarse. Así que al transicionar a la versión para netbook, estaba preocupado de que tendría el mismo problema. Al final resultó que me sorprendió mucho la velocidad del chip para gráficos integrado y no tuve necesidad de cortar nada.
P: ¿Cómo se compara la experiencia de jugar el juego entre los dispositivos?
James Brown:
La experiencia de jugar el juego es esencialmente la misma en todos los dispositivos. En los dispositivos de mano, la apariencia de los niveles está simplificada, los niveles tienen solamente una capa y están muy recortados para aprovechar al máximo el uso de esas pantallas pequeñas. En las versiones para netbook existe más espacio para que las ranas se muevan y algunos elementos de fondos festivos que puede activar. Pero aparte de algunos pequeños ajustes al progreso de dificultad, los rompecabezas son idénticos.
P: ¿Requirió de asistencia por parte de Intel en el proceso? ¿Cómo fue el proceso de envío y la asistencia del centro Intel AppUp en comparación con otras tiendas?
James Brown:
Todo el proceso fue sencillo. Tuve un fallo de validación porque logré compilar en comparación con una versión antigua del SDK, pero aparte de eso todo marchó de maravilla.
P: ¿Haría algo diferente o tiene algunas sugerencias para desarrolladores que están considerando migrar de iPhone* al centro Intel AppUp?
James Brown:
Lo único que cambiaría sería realizar todo esto antes. Requiere tan poco esfuerzo compilar en el centro Intel AppUp y estoy realmente ansioso de ver lo que nos depara el futuro.
El mejor consejo que tengo para la migración de iPhone* a AppUp es diseñar su aplicación para iPhone* con la migración en mente desde el principio, utilice C++ directamente y evite los API específicos para Apple*. Si ya terminó su versión para iPhone* y se pregunta si vale la pena la refactorización para que la aplicación sea más independiente de plataformas, existen otros beneficios para que el código original aparte de la migración a una nueva plataforma. Los distintos dispositivos tienden a exponer diferentes errores sutiles y, como el código es el mismo en todas las plataformas, las soluciones que implemente beneficiarán a todas las versiones.
Si va a crear tanto para iPhone* como para el centro Intel AppUp, tiene sentido tratar el centro Intel AppUp como su destino principal durante el desarrollo. Tiene que poder iterar rápidamente y depurar en un netbook es notablemente más rápido que el simulador de iPhone* o descargar en el hardware físico.
