Hi,

Haxe was the perfect solution for us so far at Gameduell.

We had even our build tool + dependencies management on top of haxe it is called duell adn it is explained here .

We have two games now created on haxe and one of them is soon will be launched.

We have more than 25+ developers now working with haxe and we'll have more soon.

Even though haxe still miss some decent profiling/debugging tools and IDE integration (I am not saying there are not) it gives you a lot of freedom to create amazing work.

Finally I started a project called http://learnhaxe.org/ and soon will posting tutorials and haxe talking about haxe related topics so make sure to keep an eye in there

Best,

kgar

The last time I looked at Haxe (which, admittedly, was a couple of years ago), the only fully-supported backend was Adobe Flash. And since Flash was already in the process of dying off, that made it pretty much useless, beyond developing for the handful of flash web portals.

You can export from Haxe to Flash directly, but I don't think there's many people doing that? Part of it's power is that because it's outputting several different languages, you can plug it into libraries like OpenFL and target a bunch of other platforms like desktop, mobile etc as well as Flash. For example, because Haxe can generate javascript some people have started working on projects like HaxePhaser (based on the JS engine Phaser).

Hi,

Haxe was the perfect solution for us so far at Gameduell.
We had even our build tool + dependencies management on top of haxe it is called duell adn it is explained here .
We have two games now created on haxe and one of them is soon will be launched.
We have more than 25+ developers now working with haxe and we'll have more soon.
Even though haxe still miss some decent profiling/debugging tools and IDE integration (I am not saying there are not) it gives you a lot of freedom to create amazing work.
Finally I started a project called http://learnhaxe.org/ and soon will posting tutorials and haxe talking about haxe related topics so make sure to keep an eye in there

learnhaxe.org could be a great resource, I'm looking forward to it! I've found it difficult to find Haxe tutorials that are aimed at games, so most of what I've learnt so far has been reverse-engineering open source projects.

I remember briefly looking at it a while ago and deciding it wasn't viable (for my specific use cases) due to the licensing.

Why? I dislike the GPL license family as much as the next clean-shaven* professional developer, but:

1) the compiler's license is irrelevant since your code is just data to the compiler not linked against it;
2) the standard library that's mixed into your application is all nice and friendly MIT; and
3) the runtime library's license is also irrelevant as you're merely consuming the API.

Recall that GCC is GPL and glibc is LGPL, so if Haxe's licenses were unusable for proprietary software developers, the entirety of the Linux ecosystem would be as well.

* I'm not actually clean shaven.

1. I wanted to make compiler modifications and/or reuse compiler code for building tools. This gets sticky with the GPL.

2. The standard library wasn't the problem. I'm a big fan of the MIT license and similar permissive license structures (I've arbitrarily settled on New BSD for my personal work but for no real reason of preference.)

3. Modifying and re-contributing improvements to an open-source project is highly contingent on license, especially if you're working for a business and not just soloing it.


It isn't about merely consuming the toolkit; as I'm sure you're familiar with, most middleware/tool consumption in a game product involves some degree of modification, however trivial. And as soon as that code gets touched with our fingerprints, licensing becomes a major concern for the legal group.

3) the runtime library's license is also irrelevant as you're merely consuming the API.

I've never seen/evaluated Haxe, but a runtime library running on the LGPL means it's a no-go for certain closed platforms such as PS3/4, XBox 360/One and iOS, since the LGPL says (in simple terms) the app must allow the user running the application to be able to use his own version of the DLL he compiled himself instead of the one shipped with the program.
Which is not possible in those platforms, and hence violates the license.

I agree its a wierdness with LGPL in general, but the haxe team at least promote its use in iOS apps which would also has the same restriction as you say -- So even if the letter of the LGPL says differently, Haxe themselves seem to be saying that their use of LGPL licensing is different in spirit, and they are the ones who would have to come after violators, not Richard Stallman and company. I'd wager that using the library on any platform that prevents normal LGPL use is expected and perfectly fine as far as Haxe are concerned. This would jive with the more pragmatic view of LGPL that Hodgeman spoke about.