Goodbye Flash, Hello OpenFL: Next Generation Cross-Platform Game Development

Editor's Notes

• #3: We make virtual worlds and games. We havea teen-focused MMO called ourWorld that is played by over 35 million people. We also make a really fun social casino called Vegas World. In November 2013, we introduced our social casino white-label platform based on Vegas World technology. This platform powers MSN Game's Zone Casino, among others.
• #4: As the title and abstract of this talk indicate, we're here to discuss how we at Flowplay are moving to a new cross-platform game development technology stack and how some of you in the audience may as well. But before we get into the details of how we're using Haxe and OpenFL throughout our development organization, I think it is important to look at the motivation for making a move as disruptive as this. It's not an easy thing to ask your team to switch en mass to a new development environment and a new language and new tools. After all, developers are people too, and we fear and avoid change as much than anyone else – maybe even more so, when it comes to our tools. We'll discuss ways in which Haxe and OpenFL helped us minimize this disruption. But first the why. Flowplay has been an Actionscript/Flash shop since 2007. We have a massive amount of code written in Actionscript and we have an experienced team of game developers who are familiar with the platform. We also have a large and loyal audience that is still playing our games on the web. Some of our players have moved to mobile, and we are seeing a lot of growth in that area, but the web portion of our business is still the most significant. For all its problems, and these have been discussed extensively elsewhere, for us, Flash was and is a pretty good solution. So why switch? The short answer is, we were forced to.
• #5: Flash is dying. A few years back, Apple announced that they would never support it in their iOS browser. Steve Jobs famously hated Flash. His stated reason for this opinion was Flash's poor performance and security issues. Many also believed that Flash in a mobile browser represented a threat to Apple's App Store strategy in that it provided another channel to deliver applications to mobile devices. In any case, Apple controlled the platform and Flash was not welcome.
• #6: However, the clever folks at Adobe were not so easily turned away. There was nothing they could do about the browser, but after a couple of tries, they figured out a way to allow developers to create native applications using AIR. Flash developers (including us) rejoiced, as it meant we had an opportunity to leverage our significant investments in code and deliver our games as native apps on Apple mobile devices. We shipped iPad versions of both ourWorld and Vegas World this way.
• #7: But recently Flash has been attacked on another flank -- desktop browsers. The rise of media capabilities brought about by HTML5 has meant less and less need for the features provided by the Flash client. That, combined with a number of high profile security issues, has led browser makers to announce an end of life plan for Flash (and all other plugins). It would hurt, but we could maybe survive the loss of players using Safari and Firefox.
• #8: But Chrome? Not Chrome!
• #9: The headlines and terminology being used are pretty dramatic. We've been talking about the Apple and Google "killing" Flash. What does this mean in practice? Well, it's a slow, torture. At first, players will just see a warning when trying to access a page for the first time that contains Flash-based content. They can choose to accept it once or permanently. They can even go into their browser settings and allow Flash content to always run without prompting. You might see this and think, "that doesn't look so bad." Well, you'd be wrong. This is the same treatment that browsers used to give Java applets. Does anyone remember those? They're not too popular these days! For our prospective players, especially, who tend to be older and less technically inclined, that little puzzle piece may as well be a biohazard sign.
• #10: We don't yet know what the impact will be, but we expect to see a significant hit to our acquisition funnel as a result of these warnings. And this is just the warning shot. A full scale ban will come soon enough.
• #11: So Flash may not be totally dead, but it's certainly on the cart.
• #12: Now, for developers focused on the console or mobile spaces, this isn't really a problem. But, as I mentioned earlier, we have a large web-based audience, we need to be able to serve customers moving to mobile and we have a small team, so we'd like to have a single code-base. We've also got a ton invested in our current stack. Almost a million lines of AS3 code. A team of experiences actionscript developers. And an asset pipeline built around Adobe tools. In other words…
• #13: We’ve got a serious problem! Oh, not that problem. I mean, that’s a problem, but not the one I want to talk about right now. Or ever.
• #14: We’ve got a Flash problem. We needed help! We looked around a bit and found Haxe and OpenFL.
• #15: Haxe is a programming language, you can think of it a replacement for Actionscript. OpenFL is a library, you can think of it as a replacement for the Flash API.
• #16: Haxe was first introduced in 2005 and has gone through numerous changes and improvements since. Haxe acts as a source-to-source compiler. For instance, for the HTML5 target, it produces Javascript, for iOS and Android targets, it produces C++. This C++ source is then compiled by the platform specific tools to create native binaries.
• #17: As I mentioned, OpenFL is a library that provides an Flash-like API. It's written in Haxe. A number of companies, large and small, have developed games and other multi-media applications with it. For instance, the UI for modern TiVO boxes is built using OpenFL. Both EA and Zynga have used it and Zynga even recently contributed a Haxe Stage 3D implementation to the project. When I say, "it presents a Flash-like API", what I mean is that it provides the same class hierarchy and class interfaces as Flash. Code written in actionscript that utilizes Flash classes, can be ported to Haxe/OpenFL with minimal changes.
• #18: Here's an example of a simple program written in Haxe using OpenFL. It should feel very familiar to any Flash developers in the audience. But, this program can be output to more than just a SWF. Doing this is as easy as typing 'openfl test <platform name>'. Running that command will compile and run this code on the target platform. openfl test flash will run the swf in a local Flash player openfl test html5 will open a web page in your default browser openfl test mac/windows will create and run a native desktop app openfl test ios/android will create and run a mobile app on a device attached to your dev machine via USB Of course, there's some initial setup involved to support each platform, but once that's complete. Building and running for any of them is easy.
• #19: At Flowplay, we've embarked on several Haxe/OpenFL projects. We built our mobile Vegas World Slots product from scratch using Haxe/OpenFL. We ported some of our existing libraries by hand. And we built a number of Haxe extensions that allow access to native SDKs for thinks like analytics and monetization. We're targeting SWF for internal testing. This allows us to do very fast builds and source-level debugging directly from our IDE. We target HTML5 and wrap it to produces Universal Windows Apps for distribution through the Windows store, and we produce native iOS and Android builds.
• #20: We've recently embarked a large project to port our entire product line to Haxe/OpenFl. This comprises about a million lines of actionscript code. Rather than porting by hand, we're using a tool (provided by the Haxe community) called as3hx to mechanically port most of the code. This tool is not perfect and each translation unit needs to be manually checked and cleaned up, but using it is saving us a ton of time.
• #21: It works! It sounds funny. We, of course, had hoped that it would work when we embarked on our first project, but the devil is in the details with these things and you never know until you get things up and running. As someone who has done a lot of porting and cross-platform development, it is so satisfying to be able to type a command and see the game running in one place, and without changing a single line of code, type another command and see it running on an entirely different platform. Performance is good. The mobile code is native code and we get native performance benefits. OpenFl uses hardware accelerated rendering where available (GL on iOS and Android, WebGL on HTML5), so we get optimal frame rates. Porting from actionscript is straightforward. Haxe syntax is very close to actionscript. It supports stronger typing in some areas (when passing functions as arguments, for instance) so we've taken advantage of those features to improve our existing code. OpenFL supports reading/parsing SWFs and some SWF animation features, however, we chose to go a different route, moving most of our assets to texture atlases and implementing animations with Dragon Bones. Haxe and OpenFL work well with this pipeline. There's a small but responsive community behind both Haxe and OpenFL. They have been quick to answer questions, fix bugs and implement features.
• #22: But, there are a few gothcas. Native extensions are still a pain, especially for developers coming from actionscript. Creating a native extension for mobile platforms, for instance, wrapping a vendor SDK for iOS and Android requires knowledge of Haxe, Java, JNI, Objective C, Haxe's CFFI (JNI equivalent for C), not to mention various build scripts and config files. We've gotten pretty good at this, but it was difficult at first. Source level debugging on iOS, for instance, is possible, but not easy. You can debug the C++ output by the Haxe compiler. It maps nearly 1 to 1 with Haxe files and classes, but the code is machine generated and can be difficult to mentally parse. There is supposedly support for source level debugging in Haxe for native CPP targets, but we've never gotten it to work. We do most of our debugging against the SWF target and use XCode to debug the iOS target for really hairy iOS specific stuff. Finally, compared with AS3 the amount of documentation and example code for Haxe/OpenFL is sparse. It's growing, and, as I said, the community is very responsive, but it will be some time before the documentation reaches the level of robustness of what Adobe and others have provided for actionscript.
• #23: At Flowplay, we've fully committed to this path. Recently, Joshua Granick, founder and managing director of OpenFl, joined our team as scientist in residence. He'll be working full time to advance the platform and support the community. We're going to be hosting the a local OpenFL meetup in Seattle and supporting others that want to host their own meetups in their cities. And Joshua and I have been going to shows like this one to talk about the platform, what we've done with it, and where things are headed. We've also been contributing code to the community as well. Most recently we contributed an up-to-date port of the DragonBonesanimation library to Haxe. Finally, we’re going to be open sourcing a number of our native extensions for things like analytics and monetization SDKs in the very near future.
• #24: Here are a few links to help get you started exploring Haxe and OpenFL. Have fun and thanks for listening. Questions?