I'm just trying to collect my thoughts as to how I'd sell Bulldozer on the Chrome App Store so people could pay a buck, slap it on their ChromeOS netbooks, and start playing. ChromeOS has two different kinds of apps, "packaged" apps, which are zipfiles containing a complete copy of everything your webapp needs to run, and it can contain html, js, swf, and pdf. In structure, it's not all that different from AIR. It's just a complete little bundle of stuff to do a web app.
The other non-packaged method is basically just a shortcut to a web-app running on your server. For example, I could build an html page that grabs a bulldozer swf from my site and displays it full screen. Problem there is that that's gonna cost time and bandwidth. I'd much rather have the user copy my game to his machine and then have it run instantly rather than download it every time. Also, I like the user to be able to play without an internet connection. After all, he paid for it and I don't wanna tell the user when he can and can't play a game.
Looking at the documentation, the commerce API is only available to the non-packaged games, so Bulldozer for ChromeOS is gonna be required to run from my servers.
Looks like the process is gonna be something like this:
1. User buys Bulldozer from Chrome web store.2. User gets an icon for the "app", which is just a link to a page on my site (let's say www.thecodezone.com/bulldozerforchrome.php)3. If user clicks the "app" to run bulldozer, my PHP will quietly ask Google if this person has paid for my game. If "yes", I stream over a SWF of complete Bulldozer. If "no", I serve up an error message or the crippled version that urges him to buy the real thing.
While this works, it's pretty hard on bandwidth for users and me. The full-retail Bulldozer SWF is about 10 meg (90% of which is stereo music). Normally that's not a problem for my users because I bundle it up as an EXE tht they install to their machine, so it's a one-time hit. If that's gonna happen every danged time they click the icon, it's a problem. Especially if Google wants this thing to work with pay-by-the-byte phone cards.
Mind you, I could do two things to ease up on the bandwidth.
1. I could make things smaller. I could get Bulldozer down to less than 2 meg by compressing the music more and going with smaller and fewer eye-candy animations. Given that this will likely sell for considerably less than the $9.99 I charge for the full game on my site, that'd be understandable.
2. I could cache things up. Apparently ChromeOS has some custom directives in the app-manifest that tell Chrome "this file is part of an app, so don't just dump it from the cache when you get bored", so I could mark bulldozer-full.swf suchly. The problem is then that the user now has a full Bulldozer in his cache and could copy it out, so this swf would need to do a little checking to make sure it was launched legitimately. Since the consequence of having a paid app seems to be that it is necessarily non-packaged, I don't think this'll be a problem.
So I think the sequence would ultimately look like this (as a shortcut):
1. User buys Bulldozer from the Chrome app store.2. User gets an icon for the "app", which is just a link to a page on my site (let's say www.thecodezone.com/bulldozerforchrome.php)3. If user clicks the "app" to run bulldozer, my PHP will quietly ask Google if this person has paid for my game. If "yes", I stream over a SWF of complete Bulldozer. If "no", I serve up an error message or the crippled version that urges him to buy the real thing. Note that the SWF might already be cached up, so this step might be skipped.4. When Bulldozer.swf runs, it receives some tokens or it passes some code back and forth to my server to ensure that it's actually been served from the site and isn't just someone double-clicking on the SWF.
Although looking at the documentation, packaged apps DO have access to the payment API, but they say that it's "difficult to do securely". So I could do a packaged app thusly.
1. User downloads Bulldozer, receiving a CRX, which basically contains a static HTML file and a SWF.2. When user launches the "app", it displays the HTML, which has the SWF embedded. My SWF could be passed the user's info, and then I could communicate directly with Google's authentication server to determine if it's being run legitimately.
When Google says "difficult to do securely", I presume they're talking about how someone could take apart the app (since it's all zipped up on a user's machine) and defeat the token passing. And this is true, although SWF can be made considerably more difficult to decompile than obfuscated Javascript. And in either case (packaged or non-packaged), the user will necessarily have my SWF on his machine, and if he's good enough to decompile, defeat my token-passing, and recompile, it won't make much difference which scheme he's using.
So thus-far it looks like the rules I'm gonna have to follow are:
1. Paid games will necessarily have to communicate with Google to make sure they're paid for. The only way paid-for apps can run without an internet connection is if they're running on the honor system where the user pays for the app, gets the CRX, and hopefully doesn't put it on bittorrent.
2. You can package or not package. If you're not packaged, you should either (a) be small or (
tell Chrome to keep your assets in the cache. And if your assets are static and are rarely updated (as mine are), you might as well be packaged.3. The only way to securely determine if you've been paid for is to have your server talk to Google's server and then serve content dynamically, although this is impractical if your assets are large and relatively static.
4. You determine if your app's been paid for via OAuth. You can do that on your own server or directly from your client app. If you do it from your client app (i.e. on the user's machine), then you open your fly if you're easy to decompile.
Finally I must note that Flash apps on ChromeOS are running in the sandbox and won't be able to communicate with a site unless it has a crossdomain.xml file that allows that. I don't know if Google's store-authentication server has that. If it doesn't, I'll necessarily have to relay authentication through my own server. Ultimately I'd rather my SWF communicate with Google directly rather than relay through thecodezone.com. I like to follow the "what if I'm hit by a bus tomorrow" rule which roughly translates as "what if thecodezone.com disappears forever tomorrow". People who have my current games can still play 'em as long as they have the installer and unlock code, as I don't do server authentication. If "is my game paid for" requests always pass through thecodezone.com, then it's required that my authentication code exist on my site forever.
Oh well, another thing to think of.
Source
