A call to the Haxe community

This a blog post version of my post on the Haxe forum which didn’t catch enough attention I think. Native Extensions are crucial for game development.

Update: Kha & OpenFL, for example, have their own IAP extensions because of the different engine architecture. The blog post mentionned share some thoughts on Native Extensions, in fact… but nothing concrete is going on at the moment, no repository shared. Finally the native code should be the same, but the wrapper around the extension can change depending the engine. A native extension should have different building scripts depending the engine targeted, but the same native & Haxe codes. I hope we’ll see examples in the near future.

We made recently several HTML5 games (Canvas/WebGL) that were also delivered as an app thanks to CocoonJS which deliver better performances than Phonegap/Cordova. But the journey wasn’t easy: no obb support on Android, push notification certificate needed for iOS, a custom analytics library didn’t work on Android but worked fine on iOS. It’s simple if you deliver your game with CocoonJS you don’t have any control on the packing solution and so the whole process could be a nightmare. Recently CocoonJS has updated its portal and finally announced pricing, no way! It’s time to reconsider some plan…
Unity WebGL is getting better, but still not ready to deliver properly WebGL browser mobile game. So it’s definitely time to focus (again) on Haxe!

There are a tons of awesome Haxe frameworks/libraries nowadays : OpenFL, NME, Luxe, Heaps, Kha… pick the one you want to make your mobile game! But each time I try a new “system” for mobile game I’m looking its ecosystem. Making a mobile game nowadays, is not only pushing pixels on screens, it’s also having access to native services like In App Purchase, Push Notifications, Facebook Connect… and many of them shouldn’t affect if you’re using OpenFL or Luxe…

I see engine offering their own solutions like Kha’s IAP or OpenFL’s IAP. But is there any reason why Kha created its own native extension?

Since native extensions should be engine independant it could be something managed via the Haxe Foundation! I was disappointed when I read the post on Sharing between frameworks (Nme / OpenFl / Kha / GameDuell / Heaps / Snow / YourGreatFramework ), nothing on Native Extensions!!

Making native extension is a complex task and require lots of works to be fully tested and updated (I made several for AIR), things like In App Purchase are critical in an application…

Is it something which could be managed by the Haxe Foundation? Or at least, be in one place? At the moment, it makes Haxe ecosystem feels way weaker than AIR’s one (and so hard to convince clients but also developers!) due to awesome ANEs developers like Distriqt & Milkman or also Unity thanks to Prime31 plugins. It would benefit to many developers. They could be free & open sourced available in one place, or even managed by a commercial company with pricing… at the moment Flambe sounds like the best way to go thanks to the AIR ecosystem which sounds more complete.

And you, what’s your current position concerning Haxe Native Extensions?

9 thoughts on “A call to the Haxe community

  1. I agree, this is the main reason I’m not yet using those great frameworks (and the fact I can’t generate an iOS app under Windows, as AIR does). I’m especially missing Amazon store IAP.

    I may have a try at Flambe though , even if I’m not sure how easy it is to use ANE with it yet.

    Thanks for the article!

  2. I totally agree, this is an Haxe evangelism friction point.
    How to convince my boss to use haxe for crossplatform development if it requires 1 month dev just to integrate iap or social ? no way…

  3. If I can share my thoughts here. Extensions are crucial points for every mobile application nowdays. Every developer if looking for sustainable incomes should implements some kind of payment for iOs/ Andorid or ads , should give easy access to game via Facebook login, Google + , etc, or it just should know what users do ( ga analytics). At the moment single developers try to create extension for specific haxe framework, which is not a bad idea, at least have something. If we all want extensions which can be used everywhete, someone should talk with these developers and create some stub to unify them ( it should answer of these questions: what JNI will be used to call native code, what is specific for this framework and how easy will be to separate the code) . Joshua ( from OpenFL) is trying to gather all extension under OpenFL branch ,which is maybe good start. I not seeing Haxe foundation managing these, yes someone shoudl do it, but all depends from developers who already create these extensions are the want to do it ? You should ask first them ( using specific framework forums or chat chanels)

  4. Many of the extensions that are hosted under the openfl banner can be used independently of OpenFL. If you look at the haxelib.json file you’ll note that many of those extensions don’t require the OpenFL library. The few that do require it can easily be retrofitted to eliminate the need for OpenFL if need be. Take for instance the admob extension hosted under openfl. From what i’ve seen it only leverages the timer() method from the openfl.Lib class. That can easily be replaced by a Haxe Timer instance if you want it to be library agnostic.

  5. Thanks dimu for the comment. What I’m afraid is about the extension architecture. Luxe, Kha & OpenFL don’t have a similar (engine) architecture and so not the same build process.

Leave a Reply

Your email address will not be published. Required fields are marked *