Llevamos varios años oyendo que la muerte de Flash cada vez está más cerca, ya sea porque Steve Jobs en su momento les dio muy mala publicidad, o porque la tecnología se está moviendo más hacia otros lenguajes como Javascript o HTML5. Pues bien, finalmente Adobe se ha pronunciado al respecto y ha puesto 2020 como fecha del fin de Flash.
Varias son las empresas que han ido migrando sus aplicaciones de Flash hacia otras tecnologías. Una de ellas es Flowplay, una empresa cuyos productos estrella ourWorld y Vegas World facturan 1 millón de dólares mensual. El problema de Flowplay es que ambas aplicaciones tenían aproximadamente 1.4 millones de líneas de código, así que una noticia como "Flash va a morir próximamente" no pasó desapercibida. Viendo el fin de Flash aproximarse, no podían postponer un cambio de tecnología para sus productos.
En Flowplay valoraron diferentes plataformas a las que hacer la transición. Una de ellas fue Unity, que les permitía compilar para múltiples plataformas como Android, iOS o PC usando un código único (o casi único). El problema que encontraron es que Unity es una plataforma cerrada, y en su caso lo más probable es que necesitaran meterle mano al core del framework para poder ajustarlo todo al milímetro. Hay que tener en cuenta que no es simplemente empezar de cero: se busca poder reutilizar lo ya existente en la mayor medida posible.
Otra de las plataformas que valoraron fue HTML5, prácticamente un estándar hoy día. El problema es que pese a que HTML5 es muy bueno para ciertos proyectos, para algo como un juego puede quedarse corto (sobre todo en plataformas móviles). Al final tienes una aplicación corriendo sobre demasiadas capas (Javascript, navegador, etc), lo que puede generar un rendimiento pobre dependiendo del dispositivo en que se ejecute. Al final, y contra todo pronóstico con la gran cantidad de tecnologías "top" que se están usando hoy día, Flowplay optó por Haxe como su framework de desarrollo principal.
Por si no conoces Haxe (yo no la conocía), Haxe es un framework open-source de tipado fuerte para desarrollo multiplafatorma, permitiendo el desarrollo tanto en Android o iOS nativamente, y la web HTML5. La elección de Haxe permitiría a Flowplay la migración de miles de líneas de código de Flash gracias al uso de la librería OpenFL. Además y al ser una plataforma open-source, podrían tocar el framework para optimizarlo en ciertos aspectos si lo desearan, aportando una flexibilidad de la que carecía Unity por ejemplo.
De todas maneras, los miedos estaban presentes debido a la enorme cantidad de líneas de código que eran necesarias migrar. Así que antes de lanzarse a por todas, el equipo de Flowplay decidió dividir la transición en varias partes.
Una de las piezas fundamentales de la refactorización era utilizar el contenido multimedia (iconos, efectos, imágenes, etc) usando bitmaps para su integración en Haxe. Como este cambio no suponía meses de intenso trabajo, decidieron realizar esta migración utilizando ActionScript (el lenguaje que utiliza Flash y que conocían a la perfección).
Tras ello, el equipo de Flowplay inició su incursión en el framework Haxe y comenzaron a trabajar en un test piloto que les permitiría validar tanto el framework como el producto. Usando el backend que ya tenían, reescribieron parte del código en Haxe y lo exportaron a Flash (SWF), iOS, Android y HTML5. Tras comprobar que todo funcionaba prácticamente igual que el producto actual, lo siguiente era intentar portar el nuevo código ActionScript a Haxe.
El plan consistía en portar el código de ActionScript a Haxe sin cambios de interfaz o de uso del juego. Una vez estuviera hecho, volverían a compilar el código de vuelta a Flash y comprobarían si Haxe había hecho la portabilidad correctamente.
La idea detrás de todo esto era ir reescribiendo parte del código utilizando Haxe, para luego compilarlo de vuelta a Flash y ver si el resultado de lo nuevo era idéntico al antiguo. De serlo, sólo restaba compilar a HTML5, Android e iOS para tener el código completamente migrado a una nueva tecnología, pero reutilizando la mayor cantidad de trabajo pasado posible.
Toda refactorización implica riesgos, pero en el caso de Flowplay las preocupaciones giraron entorno a dos aspectos. El primero de ellos fue mantener los repositorios de código. A priori tenían una base de código enorme con el producto original. Ahora tenían una nueva base de código con el código portado a Haxe que debían mantener.
El segundo aspecto era el tamaño, complejidad y la audiencia global de sus juegos. No es fácil realizar cambios en algo como un juego social donde hay tantos usuarios utilizándolo simultáneamente. Cualquier interrupción del servicio podría ocasionar numerosas pérdidas, y posiblemente un incremento del trabajo de soporte. Doug Pearson, el CTO de Flowplay, explica muy bien el problema que tenían:
La situación era parecida a intentar reconstruir un coche que va por la autopista. Necesitábamos reemplazar el motor, y recablear toda la electrónica, pero no podíamos parar el coche porque en nuestro caso, el coche (el juego) era lo que nos hacía ganar dinero.
Sin embargo, no todo fueron malas experiencias. Gracias al cambio a Haxe y a la contratación de personal muy cualificado pudieron identificar y resolver problemas en otras áreas del sistema. Además, al haber reescrito todo en ActionScript primero pudieron crear una nueva versión del código sin necesidad de modificar la lógica original de funcionamiento del producto.
Sin duda, todo un acierto según ellos la decisión de migrar hacia Haxe, y luego recompilar hacia diversas tecnologías utilizando un código único (cross-compiling) escrito además en ActionScript, una tecnología que conocían de sobra.
Por el camino nos queda la duda de si hay aspectos del juego nuevo que funcionan peor que en el juego original, o qué partes dieron más trabajo, o si el back-end no se vio afectado en absoluto. De todas formas, chapeau al equipo por semejante tarea.