Monday, August 27, 2012

Flash as a Native App

Just a heads-up: Readers of news at the Blue Bottle Games website will find much of this info to be familiar. It's an expanded version of the post from last Thursday. I wanted to share it here, as it may be useful to readers interested in publishing their game in Flash.

Last week, I mentioned I'd be looking into creating a downloadable version of NEO Scavenger. It turns out that's a bit more complex than I expected.

After nearly two full days of research and experimentation, I think I've got a way forward, but it isn't as elegant as I had hoped.

Why Flash?

Before I get into how, let me briefly speak about the why. Part of the reason I chose Flash as a platform was because a lot of people on the web have the Flash plugin. Adobe propaganda aside, it's probably one of the single largest install bases for game platforms in the world. People can just visit www.bluebottlegames.com and try the demo with little to no effort.

If I had chosen C++, C#, XNA, or any of the native application types, I'd have to present a "download" link, and people would have to:

  1. Trust me
  2. Download my game
  3. Install/Launch my game

It doesn't sound like much, but those three things cause an enormous drop-off in the number of people willing to try a game. Each of the above is a barrier to entry. The first is a trust barrier, the second a patience barrier, the third a laziness barrier.

As a rule of thumb, I estimate 50% of interested people just say "screw it" and move on to something else when presented with a barrier. There's some leeway, of course. Clicking a link is a smaller barrier than fishing out a wallet to pay for an app. But I assume I'm losing customers with each step along the way to trying my game (and selling my game). So minimizing that flow is important.

With Flash, the game just appears in the webpage. Players can pass a link to a friend, and all that friend has to do is click the link to see the game (and potentially wait for it to download).

Using Flash also means I can deploy the demo to Flash portals, to help spread the word. Plus, there's the unplanned bonus of people being able to play NEO Scavenger at their workplace, even in places that prohibit installing apps!

The down sides? It has a few, to be sure. This week, it's figuring out how to create downloadable versions for distribution on services like Desura and Steam.

Flash as a Native App

There's a way to make Flash into stand-alone executables. Several, in fact. However, as I'm discovering, each has it's own idiosyncrasies.

Flash Projector


The simplest, most straightforward way to get a downloadable version of Flash games is to create a projector. Just fire up the stand alone Flash player, load your swf, and "save as projector." Easy! Or is it?

Pros:

  • Easy - As above, just load the swf in a stand-alone player, and click File->Save as Projector. Voila! Native app created.
  • Cross-platform - The process works on PC, Mac, and Linux.
  • Packaging - The process makes a single executable. Neat and tidy.
  • Proven - Examples include Machinarium, VVVVVV, The Binding of Isaac.

Cons:

  • Hardware - You need a Mac and a Linux box to create those versions. I only have a PC at the moment. I can probably get Linux running on one of the machines in my house, but Mac is out of my reach for the time being.
  • Sandbox - Save files must use the unintuitive (to a user) Flash SharedObject system, and can be deleted via browser cache/cookie clearing. (It's possible the fscommand() method offers a way around this, but I need to research it more.)
  • Mods - Modding support may be hard to setup in the future, if the projector cannot access local files.


Adobe AIR Projector

I could also create Adobe AIR projectors. AIR is Adobe's solution to cross-platform software. It's designed to allow a developer to create a single .air file which can be presented as a link in a webpage. Clicking that link on any platform launches the appropriate processes to download and install a native executable for the user's platform (including installing AIR, if necessary).

It also provides a means of creating native apps for each platform, which can be downloaded and installed like most traditional software. This bypasses the need for AIR on the user's machine, but creates a somewhat messy install (see below).

Pros:

  • Fairly Easy - Making an AIR app isn't as easy as making a Flash projector, but it's not too hard, either. Using FlashDevelop, it's possible to setup an AS3 AIR Projector project, import your source code, and follow the auto-generated readme to tweak the batch files needed for publishing. Compile to swf, then run the "packager" batch file to make the app. Some research into the packager parameters is needed to make .air vs native .exe/.dmg/.deb files, however.
  • Cross-platform - Output works on PC, Mac, and Linux*. In theory, it also supports Android and iOS, though I haven't looked into it much yet.
  • Sandbox - Local file access means save games can be safe from browser flushing.
  • Proven - Proven examples include Defender's Quest.

Cons:

  • Hardware - While generating an .air file can be done from any platform, and the output works on all destination platforms*, generating native apps still requires native hardware (Mac to generate .dmg, Linux to generate .deb, Windows to generate .exe).
  • *Linux - As of 2011, Linux is no longer supported for the .air path. The native apps approach still works on Linux, but generating a working .air file for Linux involves some heavy tweaking using older AIR versions.
  • Packaging - Both the .air and native app outputs generate an installer which must be executed, and this throws up all kinds of ugly prompts on most machines. Also, both paths will generate a messy collection of support files alongside the application.
  • Licensing - You may need permission from Adobe to distribute AIR installer. Looking into this, it may only be the case when including AIR's installer on its own with your download, and the .air and native app approaches may sidestep this. Still, it's a consideration, and that kind of legal complication is an effective deterrent to adoption, if anyone at Adobe's reading this.
Port NEO Scavenger to HaXe

While researching cross-platform distribution, it's impossible to miss HaXe. Purporting to "write once, deploy anywhere," it may sound a lot like Java. The difference is that HaXe not only compiles directly to multiple platforms, it compiles into other languages, including C++, C#, Flash, JavaScript, and soon, Java.

There's even a framework within HaXe, NME, which smooths the transition from Flash even further. It's a pretty impressive tool. However, it's a relatively young platform, meaning its community support pales by comparison to AS3. It's also just different enough from AS3 that it would mean a lot of rewriting of code.

Pros:
  • Packaging - Produces actual native apps. No virtual machines.
  • Cross-platform - Works on PC, Mac, and Linux (and iOS, and Android, and Flash, and...)
  • Sandbox - Local file access means save games can be safe from browsers, and mods are supported.
Cons:
  • Hardware - Need a Mac and Linux OS to generate native apps for those platforms.
  • Effort - I would have to rewrite huge amounts of code to port to HaXe. As mentioned above, AS3 and HaXe (NME especially) are close, but not close enough.
  • Support - As a young(ish) platform, community support is still pretty small. It can be harder to find answers to questions as compared to AS3/Flash. 



3rd Party Wrappers

There are also some third party wrappers out there (e.g. Zinc, SWF2EXE, mProjector). However, their reputation appears to be mixed. Some claim support is poor, others say the performance is bad, some don't even support all platforms. And then there's the price tag. With many of them costing several hundred dollars, I might as well buy a used, Intel-based Macbook, which not only lets me develop for Mac, but iOS devices as well.

Conclusion

Is there a conclusion? Not yet. No silver bullet, anyway. My likely approach for now is to actually go with the simplest option: the Flash projector. It generates native .exe files that work right now, and I can probably get Linux running on one of my PCs to do a .deb version. If sales pick up, I can probably justify $500 for an old Macbook to compile Mac versions.

And since I'm still in beta mode, the downloadable file will be updating with each new version. It's not too hard to swap in an .exe generated via another means when I need to. It's just the easiest working path open right now.

If you're looking for more info, here are a few links to resources I used in my research:

  1. Making Flash EXEs (Terry Cavanagh's VVVVVV research)
  2. Flash to EXE Projector Help (Leans towards projector)
  3. Packaging a desktop native installer (Adobe AIR documentation)
  4. Lone Survivor Linux Woes
  5. Flash for Downloadable game. Some tips? (Projector vs. AIR vs. HaXe)
Hope this helps some Flash devs out there. If you have any additional info or corrections to add, post in the comments!


12 comments:

  1. If you want to do a linux build, but don't want to actually run linux yourself, a virtual machine is the way to go. Download virtualbox, ubuntu and bob's your uncle.

    It's sketchy and probably illegal but I believe getting a vm of (non-server) osx up and running is also possible. Or just borrow a friends mac.

    If you had to start again, would you consider html5 for your next game?

    ReplyDelete
    Replies
    1. Linux actually turned out to be pretty easy. I tried the wubi installer on my laptop, and got it dual-booting. Runs a bit slow, but should be enough to convert a swf to projector occasionally.

      There's actually a rent-a-Mac service that hosts Macs in the cloud, and you can rent access to them. $20/month, so I may look into that as a stop gap. Friends with Macs are hard to come by in the middle of nowhere :)

      Re: HTML5, I'll roll that discussion into the reply to Jay, below :)

      Delete
  2. I've been meaning to ask you about this. My background is in front-end web development, not game development, and Flash is pretty much a four-letter word here. I was wondering if you had looked into HTML5 game development yet and what the shortfalls there are. I know it's new and probably missing some of the depth of Flash, but I wasn't sure if you had looked into it much yet.

    My concern with Flash is that while it still has wide desktop support, tablets and smartphones are increasingly abandoning support for it. And those seem like big indie gaming markets.

    ReplyDelete
  3. Hey Jay!

    HTML5 is pretty much a non-starter for me. It's not mature enough for me to build a business around yet.

    Don't get me wrong, Adobe and Flash both have their skeletons. But the idea of debugging my game on every browser for every platform is a tough pill to swallow.

    Remember a few months back, when I tweeted my frustration about cross-browser CSS? And how long has CSS been around? I'm not expecting HTML5 to be consistently adopted and performant any faster.

    What's more, source code and asset security are harder to maintain in an HTML5 game. Admittedly, Flash's security is imperfect. However, unless the HTML5 game is running server-side code (and you're committed as a business to keep that code running indefinitely for your customers), "decompiling" an HTML5 game and rebranding it as your own is pretty easy (i.e. professional piracy).

    What tech will I use next? It's hard to say. Despite it's shortcomings, I can produce faster in Flash (or more accurately, AS3) than anything else I've tested. And on Win/Mac/Linux browsers, it *just works.*

    However, extending beyond desktop browsers gets a bit muddy. In those cases, Flash can still get there, but other options are looking nicer.

    HaXe is definitely on my radar (the NME package in particular). Being able to use a single codebase and familiar language to deploy natively to any platform, including Flash and Javascript, is golden. Why would anyone use anything else? Or so the sales pitch goes.

    Unity was another consideration. It's adoption rate is lower than Flash, so it's not as attractive there. But it's a tight package, and again, it *just works* on its target platforms.

    I guess more than anything else, that's probably the biggest deal maker/breaker for me: if I write it, does it *just work* on the target platforms equally?

    ReplyDelete
    Replies
    1. I disagree with the "professional piracy" argument. Does flash have anything to stop someone from stealing your swf and hosting it on their own site?

      Javascript for games is also generally compiled for speed using something like the closure compiler, which has a side effect of heavily obfuscating the code. You can steal it outright sure, but it's hard to understand and alter it.

      Regardless, people will steal your game even if they don't steal the source or binaries - just look at the tiny tower zynga clone debacle. For a game like neo scavenger, the mechanics are what set it apart, and they can easily be stolen, code or not.

      Also can you get rid of the recapcha for posting comments? I swear those things are getting impossible to read for both bots and humans.

      Delete
  4. Hey Daniel!

    Yep, turns out I can disable recaptcha. I never noticed it before, probably not shown to me because I'm the admin for the blog. We'll give no captcha a shot!

    Re: professional piracy, there are tools that can be used, but as one would expect, nothing is guaranteed against determined attack. Site locking, code obfuscation, distributed data, and encryption tools are the prevalent mechanisms in the Flash scene.

    I wasn't aware that compiling was being used for JS games.

    And you're right that someone could clone a game, copy-protected or no. NEO Scavenger wouldn't be a trivial game to copy, in my mind, but it could be copied.

    My hope is that with more content to define the IP, the appeal of the game is more than just the sum of the features. Plus, regular beta updates means the game is a bit of a moving target (at least for now).

    ReplyDelete
  5. I'm not sure if blogspot allows alternate captcha ideas (probably not), but there's a great one at areyouahuman.com that basically makes you play a simple game to prove you're a human.

    HTML5 support is still an issue, yes, though Flash support will be too as time goes on. Apple can't run away from Flash support fast enough and even Microsoft has toyed with the idea of dropping Flash support from its tablets (they said it, then later retracted it).

    Dealing with HTML5 and CSS3 compatibility is a major portion of my day, so I totally understand that. I'm largely clueless on HTML5 game development, though I have heard people talking excitedly about it (which isn't to say it's actually terrific). I know Mozilla built an HTML5 multiplayer demo game called Browserquest (http://browserquest.mozilla.org/) that I've toyed around with a bit and was fun.

    I don't know anything about HaXe or Unity; do they compile into something that runs natively on Android and iOS?

    ReplyDelete
  6. The areyouhuman.com approach is pretty cool. Unfortunately, blogger's captchas are an on/off setting. Can't choose my own format.

    I setup bluebottlegames.com to use Riddler, which lets me ask custom questions that spambots can't answer, "like what color is the bottle on this website?" Doing that has dropped spam activity a ton as compared to vanilla captcha (even honeypot and timer mechanisms weren't as effective).

    I'm not too worried about Flash going the way of the dodo yet. I set out to make games for the desktop, my preferred gaming platform. And Flash was the easiest way to realize that goal (it still is, in my opinion).

    I'm not a Flash cheerleader or anything. When better pastures present themselves, I'll be happy to migrate. I just haven't seen a viable alternative yet.

    HaXe is definitely a contender I'm watching. To answer your question, yes. If you believe the sales pitch, the number of platforms it compiles to natively is staggering. The NME library in particular is designed to compile one codebase into native:

    Win
    Mac
    Linux
    iOS
    Android
    BlackBerry
    WebOS
    Flash
    HTML5

    Again, that's a sales pitch. I have yet to try it for myself.

    Unity has a fairly extensive deployment range as well. Their website makes it a bit difficult to tell, but the Wikipedia article lists the following native targets:
    Win
    PC
    Linux (Unity v4.0)
    iOS
    Android
    NaCl
    Wii
    Xbox 360
    Flash
    PS3
    BlackBerry

    It also deploys to web browsers via a plugin that must be installed, kind of like Flash does now. Nowhere near Flash's current adoption rate, though.

    Both HaXe and Unity seem like fertile ground to me. As NEO Scavenger v1 wraps up, I'll probably be considering those development environments next.

    ReplyDelete
    Replies
    1. Unity deploys to Flash SWF now.

      http://unity3d.com/unity/multiplatform/web

      The issue you didn't mention was cost. As soon as you add deployment options you'll have to pay $400-1500.

      https://store.unity3d.com/

      Delete
    2. Yeah, cost is one deterrent. Though, I might be ok with the cost knowing that it "just works." $1500 is pretty steep, though.

      I seem to remember that getting a decent IDE for Unity was hard, but that might be better now. I think that was the other main deterrent.

      Delete
  7. How are you going to go around the fact that flash projector uses the top tool menu ,the right click menu and comes with the flash logo on it.

    ReplyDelete
  8. The right click menu seems to work in Flash 11+ projectors, at least as far as I can tell. I was able to create a right-click context menu for items in the inventory screens in NEO Scavenger.

    The logo can also be replaced on Windows projectors using applications like Resource Hacker, and on Macs by opening the application resources and changing the logos. In fact, changing the icons in Flash projector itself seems to produce executables with the desired icon.

    I haven't yet tried hiding the projector menu, since NEO Scavenger doesn't really resize/scale well up to full screen. The latest version, though, may need to do this. I think I saw some as3 commands to hide the toolbar when I was researching fullscreen, but I haven't tried them yet.

    ReplyDelete