Haxe, as3, citrus engine, what to choose

26 posts (showing 1-20)
EntertainmentForge

Market Level 6Community Level 6
710 posts

Hey guys! I am considering giving Haxe a chance. I heard that with it games can be made not only for mobile devices that run smoothly, html5 games and also full screen pc games work smooth also. Is this all true in your experience? 

Also friend started learning citrus engine. What is your guys opinion on that one if you tried it?

I am already making games in as3 so from what I understood haxe will be very similar right?

Thanks!

posted 2015-05-25T11:09:12-07:00
bstone

Market Level 0Community Level 0
18 posts

I have no first hand experience with it but I've looked through related docs and you should be able to achieve the result you want if you go the OpenFL route.

I'd download Haxe and try building relevant demos for all the target platforms you're interested in. That will give you an idea whether the whole thing is up to your expectations.

posted 2015-05-26T06:53:45-07:00
EntertainmentForge

Market Level 6Community Level 6
710 posts

Yea that's the plan actually :)

But I wanted to hear opinion of you guys also since I heard some developers here use haxe.

posted 2015-05-26T08:34:41-07:00
b10b

Market Level 4Community Level 7
971 posts

I've used Haxe exclusively for 6 years now.  I'd choose it again simply because the language is expressive and the tooling is lightweight, free and just works.  But I don't subscribe to all the silver bullet / multi target claims of OpenFL etc.

Undoubtedly much of our code can be reused, more if we separate concerns and plan a little.  But specialisms and optimisations (and therefore bugs!) always exist in the target specific domain - therefore expertise for all targets is ultimately needed for a proper commercial release.  That's a tall ask for many, and hard to rationalise ahead of alternative approaches such as AIR, HTML5, or Unity that generally offer more documentation, more users, more momentum, more commercial releases to draw experience from.

That said, I would still choose to use Haxe to create AIR or HTML5 (& possibly Unity) - but I would treat them one at a time to operate specifically within each domain.

posted 2015-05-26T16:00:23-07:00
ozdy

Market Level 6Community Level 13
1482 posts

I've been using Haxe for almost 2 years and I love it. It has a learning curve and some bugs. But the language is very feature rich, now that I've learned target specific tricks, macros and enum stuff, I feel very productive. I use OpenFL which is sadly the one that is least complete, but I need both HTML5 and Flash targets (non-Stage3d/WebGL). If you don't need Flash non-Stage3d, go Flambe. If you don't need HTML5 or Flash, go Air :)

posted 2015-05-26T17:03:56-07:00
EntertainmentForge

Market Level 6Community Level 6
710 posts

Thanks guys. Well multi targeting was most appealing to me but I guess its too good to be true hehe :p

posted 2015-05-26T17:24:03-07:00
b10b

Market Level 4Community Level 7
971 posts

I don't think we're saying multi targeting is untrue, just that it is not magical or instantaneously available to a newcomer.  It takes time to develop a deeper understanding of each target - but Haxe definitely provides a powerful toolset towards leveraging that knowledge - further down the line.  In the meanwhile it's a great language that encourages the use of compiler patterns and time saving features (like Ozdy mentions).  So both the short-term transition and long-term adoption are equally well rewarded for the discerning Developer.

posted 2015-05-26T17:44:00-07:00
bstone

Market Level 0Community Level 0
18 posts

Ozdy, why is non-Stage3D critical to you? Are there any caveats to leveraging performance gains it provides? And WebGL in HTML5 builds?

posted 2015-05-26T18:05:55-07:00
b10b

Market Level 4Community Level 7
971 posts

I'd be interested to answer that too.

Canvas is essential to me for HTML5 ubiquity.  Given the objective of the platform is that it works, on anything, the bar is pretty low.  Whereas WebGL, however superior, isn't ubiquitous.  Next, given that the performance on most accelerated Canvas implementations is often on par with WebGL (for basic 2D), the choice for using Canvas for casual mobile web games is appropriate imo.

I'd make the reverse argument for Flash and Stage3D; I can't see any reason not to use it as the platforms with audience and commercial demand fully support it.

posted 2015-05-26T18:29:33-07:00
bstone

Market Level 0Community Level 0
18 posts

Yeah, I'm more puzzled with the Stage3D rejection. But to be honest I don't see a reason for not taking advantage of WebGL where it is available and fall back to Canvas where it's not. That's what most HTML5 game engines were doing for quite some time already, no?

posted 2015-05-26T18:51:51-07:00
b10b

Market Level 4Community Level 7
971 posts

Yes, several HTML game engines have degrading WebGL to Canvas.  Within the scope of Haxe, Flambe requires Stage3D and has degrading Canvas->WebGL iirc.  And, last time I checked, OpenFL did neither Stage3D or WebGL by default (largely due to its mission of replicating the Flash DisplayList which is of value to its users).  Heaps is another multi target Haxe library worth review, and uses WebGL and Stage3D.

I'd argue that any automated degrading WebGL->Canvas or Stage3D->DisplayList approach has its own pitfalls as clearly the full features of either cannot be fully embraced due to the lowest common denominator approach.  This is the core paradox of multi target development, and I believe the compromise is not worth the claimed gain if making a diverse range of game types.  Imo better to structure a game with logic separated from concrete views that are then free to be optimised and tested on a per-platform basis.

posted 2015-05-26T20:02:55-07:00
bstone

Market Level 0Community Level 0
18 posts

I doubt that DisplayList-centric workflow/habit is the reason behind Ozdy's approach. But that will make his answer even more interesting.

Otherwise I'm totally on your side with the per-platform approach. It's so hard to discard an opportunity to deploy to 2x-3x more platforms with potentially no overhead though. I was going to use Cocos2d-x to target iOS and Android with a good deal of control but the Haxe/OpenFL combo has this appeal of tapping the Flash and HTML5 markets along the way. Yet I've been disappointed with OpenFL not benefiting from Stage3D/WebGL when it clearly could. And I'd prefer Flambe since it's much more aligned with my approach to developing games but AIR seems like so not the right way of doing it on mobile, sigh.

posted 2015-05-26T20:48:07-07:00
b10b

Market Level 4Community Level 7
971 posts

If we thought it made sense we could write WebGL & Stage3D backends for OpenFL.

Have you considered using Flambe for WebGL only, and then wrapping that for mobile using Crosswalk or similar to avoid AIR completely?

posted 2015-05-26T21:23:41-07:00
ozdy

Market Level 6Community Level 13
1482 posts

WebGL is a NO in the html5 licensing business model, I thought Stage3D was too, but I haven't been in the Flash licensing model for years, this might have changed :)

posted 2015-05-26T21:26:18-07:00
bstone

Market Level 0Community Level 0
18 posts

Ah, that explains it. I was sure WebGL was OK as long as everything works with Canvas though. Take Construct 2 for e.g., all games one could make using it would use WebGL and fallback to Canvas if they couldn't use GL. It's good to know that one should avoid WebGL completely in the HTML5 licensing world. Totally not obvious for noobs in this biz like myself.

posted 2015-05-27T05:37:20-07:00
ozdy

Market Level 6Community Level 13
1482 posts

Yeah, there are many guys in the HTML5 licensing business that use Construct 2, so it's not a problem.

posted 2015-05-27T07:47:49-07:00
b10b

Market Level 4Community Level 7
971 posts

Some sponsors / networks (e.g. GamePix) are specifically looking for WebGL content at this time.  Now that every major platform (desktop and mobile) supports WebGL this kind of strategy will gain traction fast.

Until then relying on fallbacks can be risky.  For example many Construct developers are caught completely off guard when that WebGL->Canvas fallback kicks in (a common thread in the support forums last time I looked).

posted 2015-05-27T15:33:59-07:00
pepperpunk

Market Level 3Community Level 11
2401 posts

I've been using Haxe and OpenFL for over a year now, works great and has become way more refined and with less issues than when I first started using it.

I'll have a game up very soon made 100% using Haxe/ OpenFL, didn't even use haxeflixel or any of the other engines available on top of it.

posted 2015-05-27T18:46:33-07:00
Totor

Market Level 0Community Level 2
109 posts

@pepperpunk, what's your target? html5, flash, mobile?

@EntertainmentForge, multi-target in haxe means the compiler outputs a project for the target in the target languages, then you compile. it's write once, compile anywhere iirc contrary to java/html5

@the webGL experts, do you know a way to effectively test if your target supports it because with my samsungs or even desktops, sometimes it says Yes, sometimes it says No... and when it says Yes, it's really working?

posted 2015-06-03T15:18:07-07:00
b10b

Market Level 4Community Level 7
971 posts

@Totor generally yes, if you can grab the webgl context it's working.  Until it doesn't!

We use the standard upfront test for 

window.WebGLRenderingContext

Followed by

canvas.getContext("webgl")

However, context can be lost at any time as the browser knows best!?!  So some more elaborate tricks are usually needed (based around the "webglcontextlost" event or similar approaches):

https://www.khronos.org/webgl/wiki/HandlingContextLost

Are you using a specific WebGL JS library?  Some of these events are not fully supported yet, so some workarounds are needed.

posted 2015-06-03T15:54:11-07:00