We have been hearing for several years that the death of Flash is getting closer, whether because Steve Jobs at the time gave it very bad publicity, or because the technology is moving more towards other languages like JavaScript or HTML5. Well, Adobe has finally spoken on the matter and has set 2020 as the end date for Flash.
Several companies have been migrating their Flash applications to other technologies. One of them is Flowplay, a company whose flagship products ourWorld and Vegas World generate 1 million dollars per month. Flowplay's problem was that both applications had approximately 1.4 million lines of code, so news like "Flash is going to die soon" did not go unnoticed. Seeing the end of Flash approaching, they could not postpone a technology change for their products.
Choosing a New Platform#
Flowplay evaluated different platforms to transition to. One of them was Unity, which allowed them to compile for multiple platforms such as Android, iOS, or PC using a single (or nearly single) codebase. The problem they found is that Unity is a closed platform, and in their case they would most likely need to dig into the core of the framework to fine-tune everything. It should be kept in mind that this is not simply starting from scratch: the goal is to reuse existing work as much as possible.
Another platform they considered was HTML5, practically a standard today. The problem is that although HTML5 is very good for certain projects, for something like a game it can fall short (especially on mobile platforms). In the end you have an application running on too many layers (JavaScript, browser, etc.), which can generate poor performance depending on the device it runs on. In the end, and against all odds given the large number of "top" technologies in use today, Flowplay opted for Haxe as its main development framework.
In case you don't know Haxe (I didn't know it either), Haxe is an open-source strongly typed cross-platform development framework, allowing native development for both Android and iOS, as well as HTML5 for the web. The choice of Haxe would allow Flowplay to migrate thousands of lines of Flash code thanks to the OpenFL library. Furthermore, being an open-source platform, they could modify the framework to optimize it in certain aspects if they wished, providing a flexibility that Unity, for example, lacked.
Regardless, fears were present due to the enormous amount of code lines that needed to be migrated. So before going all in, the Flowplay team decided to split the transition into several parts.
Starting with Haxe: Rewriting the Code#
One of the fundamental parts of the refactoring was using multimedia content (icons, effects, images, etc.) as bitmaps for integration into Haxe. Since this change did not require months of intensive work, they decided to carry out this migration using ActionScript (the language used by Flash, which they knew perfectly).
After that, the Flowplay team began their foray into the Haxe framework and started working on a pilot test that would validate both the framework and the product. Using the back-end they already had, they rewrote part of the code in Haxe and exported it to Flash (SWF), iOS, Android, and HTML5. After confirming that everything worked practically the same as the current product, the next step was to try to port the new ActionScript code to Haxe.
The plan consisted of porting the code from ActionScript to Haxe without any changes to the interface or game usage. Once done, they would recompile the code back to Flash and check if Haxe had carried out the port correctly.
The idea behind all of this was to progressively rewrite parts of the code using Haxe, then compile it back to Flash and see if the new result was identical to the old one. If so, all that remained was to compile to HTML5, Android, and iOS to have the code completely migrated to a new technology, while reusing as much of the heavy lifting as possible.
Challenges and Good Decisions#
Any refactoring involves risks, but in Flowplay's case the concerns revolved around two aspects. The first was maintaining code repositories. Initially they had a huge codebase with the original product. Now they had a new codebase with the code ported to Haxe that they had to maintain.
The second aspect was the size, complexity, and global audience of their games. It is not easy to make changes to something like a social game where so many users are using it simultaneously. Any interruption of service could cause numerous losses, and possibly an increase in support workload. Doug Pearson, Flowplay's CTO, explains the problem they faced very well:
The situation was like trying to rebuild a car going down a highway. We needed to replace the engine and rewire all the electronics, but we couldn't stop the car because in our case, the car (the game) was what was making us money.
However, not everything was a bad experience. Thanks to the switch to Haxe and the hiring of highly qualified personnel, they were able to identify and resolve problems in other areas of the system. Furthermore, by having rewritten everything in ActionScript first, they were able to create a new version of the code without needing to modify the original product logic.
Undoubtedly, they consider the decision to migrate to Haxe a success, then recompile to various technologies using a single codebase (cross-compiling) written in ActionScript, a technology they knew inside and out.
Along the way we are left wondering whether there are aspects of the new game that work worse than in the original, or which parts took more work, or whether the back-end was not affected at all. In any case, hats off to the team for such a feat.