Did you miss a session from GamesBeat Summit 2022? All sessions are available to stream now. Watch now.
The tech industry has been calling for the death of Flash for years. Last year, the quiet rumblings calling for its demise turned into roars as the likes of Chrome and Firefox began to phase out support. A full-on war has been waged against Flash technology and much of the casual games industry is stuck on the losing side.
The latest example of a game to succumb in the fight is from Disney, which shuttered the Club Penguin desktop experience earlier this year. While Disney did launch a new mobile version that seems to be getting some traction, Club Penguin is a game that an entire generation grew up playing and has remained a cultural zeitgeist for millennials everywhere even to this day.
That said, Disney’s motivation to shut down the core Club Penguin desktop experience was understandable, at least at a technical level. At FlowPlay, we were in a similar situation last year with our flagship MMO, Vegas World. We had an aging codebase built in ActionScript, the Flash-exclusive programming language. We had millions of players playing our Flash games on the web and we well understood Flash would soon be going away due to lack of support from Adobe and concerted efforts by the tech community at large to move consumers away from the platform. We were also increasingly aware of the larger shift to mobile.
Despite Disney’s justification that completely scrapping the desktop experience was necessary in order to launch a new mobile experience, both supporting the old game while still innovating on mobile was entirely possible. I know because we recently did so, and did so with significantly fewer financial and engineering resources than Disney has at its disposal. Here’s how.
Finding a new platform
A few years ago, when it first became clear that Flash was not going to be a viable platform for the long-term, we started looking for alternatives. We wanted a platform that would provide:
- The ability to continue to support our existing games and communities
- A single codebase to target web, mobile, and other platforms
- The ability to leverage our existing ActionScript codebase as much as possible
- A smooth transition for our development team
- The ability to adapt to our existing pipeline of art assets
- Control of our own destiny, through avoiding proprietary platforms that would lock us in once again
- Support for high-end gameplay experiences and future innovation
A Haxe codebase can be leveraged to launch everything from native mobile and desktop apps to HTML5 apps for web browsers through a single codebase while remaining flexible enough to adapt to new languages, platforms, and technologies as the games industry evolves. Porting from ActionScript to Haxe is also relatively easy due to the similarities in language syntax, allowing us to utilize much of our existing codebase. Most notably, given the open-source foundation of Haxe/OpenFL, long-term support and continued innovation were guaranteed.
The porting process
The transition was, and continues to be, a significant undertaking. A year into the five-step process, we have learned many lessons but remain bullish on the technology capabilities and in our decision to leverage Haxe/OpenFL.
At a high-level, the process thus far has included:
- Testing – An important early step was to build and launch a small game in Haxe/OpenFL across iOS, Android, Windows and HTML5. This proved that the platform was viable and could produce the performance and functionality our games demanded, before expanding to the much more mammoth process of porting our entire codebase of more than a million lines of code.
- Automation – There are a number of tools available to help automate translation from ActionScript to Haxe, however, we found they often caused more problems than added productivity. Instead, we opted to write our own translation tool and do the rest of the porting by hand as necessary. Most files were straightforward to port, some requiring few to no manual changes.
- Actual porting – Under the philosophy of keeping the new code as close to the original ActionScript code as possible, we began by porting our core libraries and move out from there to third-party libraries, the game shell, social rooms, avatars, and finally the individual games housed within our larger metagame.
Today, the process continues with two key final steps:
- Identifying errors – Because Haxe/OpenFL supports output to Flash, the same format supported by ActionScript, we can compare the new game with the old to identify and fix any anomalies.
- Final conversions – Once we are satisfied we have achieved at least parity (if not improved) performance and functionality with the Flash version, we will use Haxe/OpenFL to generate and launch HTML5 and native mobile targets.
Make new friends, but keep the old
The impending demise of Flash meant we needed to make a choice – abandon our existing code, games and customers and build a new game on a new platform OR find a platform that allowed us to maintain support for our existing players while also supporting new players on mobile. We chose the latter path and it has worked well for us. It may have worked for Club Penguin and saved its passionate community of desktop players, too. Could it work for you?
Craig Robinson leads mobile strategy and development for FlowPlay as the vice president of mobile games
GamesBeat's creed when covering the game industry is "where passion meets business." What does this mean? We want to tell you how the news matters to you -- not just as a decision-maker at a game studio, but also as a fan of games. Whether you read our articles, listen to our podcasts, or watch our videos, GamesBeat will help you learn about the industry and enjoy engaging with it. Learn more about membership.