Forums » Help » Alternative to Chrome webstore?

Hi All,

I'm planning to release a 'free trial/ paid full version' app early next year. I like the idea of putting it on the chrome webstore, because it means I can focus on making the game, rather having to set up my own website + payment gateway integration + webhosting etc etc.

However only about 20% of the world is on chrome, and it I'm not sure devices like the ipad will ever use the chrome webstore, so I'm wondering if there is any alternative to google's webstore that simply provides application hosting and payment gateway integration, but is not browser specific.

Thanks,

Matt.

No, there isn't, and I doubt there can be one so readily.

Chrome's Web Store is integrated into Chrome, while iDevices all use Apple's App Store, and Android devices have their different marketplaces.

Meanwhile, on desktop more generically, you're looking at things like Steam or Desura, which require executable files (which can't be done readily yet because there isn't an equivalent of iOSImpact for desktop), though I wonder if an iOSImpact binary could be cross compiled for Mac OS X without too much heartache.

Long and short: no. Each marketplace exists for a different reason and none of them seem to really care about providing for multiple platforms.

since our type of games sell for a relatively low price (unlike Modern Warfare) you need scale. Try to attack all fronts : chrome, iOS, Android, basically any platform that has lots of people using it. ImpactJS allows you to do this

Has anyone here made even 1$ from Chrome's webstore? I doubt it, but don't mean to disparage Impact or Google by this; just that the waters are uncharted for now, the engine and the platform are relatively young, and I'm hoping that this small bait will motivate someone to help shed some light on the matter. :)

Titanium Desktop + Impact = Steam?

Thanks for the info, I think I will go down the path of making my own website with its own link to paypal etc.

I like the idea of attacking all fronts, but I don't like the idea of actually packaging an android app, and an ipad/iphone app, and a chrome webstore app, and an online site.

There always seems something very wrong about my android phones weekly 'do you want to update these 1-5 apps procedure'. If these apps are hosted in the web, then there is no need to update thousands of devices, and deal with different OS's and different phones. Writing it in html5 and making it work in any browser, means I can simply host it in one website, and update it once.

I guess there is a business argument of making it an android/iphone package, as it might get more hits being on these stores, but in the long run I think I will be happier spending my time developing games, and having a simple update procedure where one website gets updated, rather than dealing with daily requests about how it doesn't work on the new motorola phone, or the IOS 5 update broke something...

I'm also planning to try and make it an offline app so it will cache and work on mobile devices when there is no network connection, and also try to make it have a 'full screen mode' experience even through it is still on the website.

Do others think this is a good path to go down?

I like your idea matt_nz.

If i would have to run my game on android i would try to build app that downloading whole resources as cache (at first time) and in case there is no internet connection game is running from the cache. But if there is connection game could run in online mode and download new resources. And this is the resolution for me. You don't have to upgrade android app or every other.

I don't know is it possible but it seems to be for me.

Your way with browser seems to me that there could be more memory needed to run the game becouse of the browser. But it is only guessing in my case :P

Anyway i like the idea :)

It's a bit harder to monetise a game by locking it on the browser side. I suppose in theory you can have a wrapper that sits between the browser request and the files themselves and only serves them if the user is authenticated (i.e. registered/paid)

The one thing I will add is that you cannot rely on caching on the client side to actually work as expected, especially in a mobile context. I don't know if iPhones do things differently, but they never used to cache things properly if they were larger than 25K, which means if your assets are any size at all, they'll fall foul of that, and require connection far more often than not.

I would also note that performance is noticeably improved when building without the browser. As a comparison, I tried Biolab Disaster on the main website on my iPad (running at original size) vs the iOSImpact version in the App Store (which I set to 2x because it runs as a phone app as well as an iPad one and can scale up as a consequence)

The app version was noticeably smoother, despite rendering larger, on a first-gen iPad running iOS 5.0.1 (though it was true for iOS 4.3.3 as well), so if performance is critical to your game, I don't think you can really ignore the app sector.

(Oh, and Biolab Disaster as an app also runs better than on my desktop with Chrome beta, even ignoring all the sound issues in Chrome on desktop, like the fact that sounds break after a while and won't work until the browser is restarted...)

hmm, when it comes to monetizing and building a business off games, we can't afford to say "meh, i feel like I just want to deploy on the web and forget other mediums"

successful web game portals are innovating ( look at MiniClip and ArmorGames, they're doing pretty well branching out into mobile games )