I’ve been looking long and hard for a solution to the problem of creating high-performance games that are broadly portable across desktop, mobile, and in-browser platforms. Adobe Flash looks to be the closest solution to what I want, but FlasCC falls far short of offering the performance benefits it promises.
Flash’s cross-platform support is impressive. Naturally Flash applications run in browsers, but in recent years Adobe’s AIR technology has made it possible to make native-looking desktop and mobile applications as well. Flash’s mobile support offers many surprisingly useful features, including native deployment to connected devices, a handy mobile device simulator, and Scout support for profiling Flash applications running on a device.
Most recently Adobe released FlasCC, which lets you compile C/C++ code and embed the result into a cross-platform Flash file. This, I was sure, would be the magic bullet that would enable me to write high-performance game features in C++, while crafting the overall game interface in the Adobe Flash editor and deploy the resulting application anywhere, easily.
Alas, I discover today after a day of toiling that FlasCC does not compile to native code (contra Google Chrome Native Client, for example). Instead, FlasCC compiles to ActionScript bytecode, which executes with horrifying sloth, especially on mobile platforms. The Box2D example that comes with FlasCC simulates 500 colliding physical bodies with reasonable speed on a desktop, but can only simulate around 20 bodies at the same speed on my iPhone. That’s what happens when you execute ActionScript bytecode on a mobile device.
Therefore, if you’re making a game with no real CPU burden (something like Simon, perhaps?), Adobe Flash and FlasCC offers a great way to create cross-platform games using either ActionScript or C/C++. But if you’re making a game that needs to do some real computations—run physics, for example, or serious AI—FlasCC is useless.
Adobe should consider enabling a “universal native” mode in FlasCC—a switch that would cause FlasCC to compile to one or more native architectures, as selected by the user, and bundle the result into an executable SWF (or SWC). Alternatively, FlasCC could output LLVM bytecode, then run a JIT optimizer and linker on the native system when the app is first executed. That first run would have a long startup delay, but for many applications that would be a small price to pay for native SWF execution performance across all supported platforms.