As I’m thinking about evangelisation, I’d like to know what you use Haxe for and why you chose Haxe to do that.
Would you please mind sharing while keeping things short so I can easily compute all of that and try to start some Haxe evangelisation?
Also : would you be willing to appear in a video to briefly explain that?
Unsurprisingly, at my job I use it for shared client/server code in games. Apart for cross-target features, one of the good reasons to use Haxe is its nice type system and macro features that ease a lot of tasks of maintaining code and accompanying data (e.g. game data). I think Haxe is the only compiler that can produce controllable, clean and efficient JS code and nice C# code at the same time (we need those targets because we use node.js and Unity).
Would you be willing to share a bit more about your process/pipeline with me by chat?
I use Haxe primarily with JS target for various projects, either using OpenFL or integrating with other JS libraries such as OpenLayers, EaselJS, JQuery, or GSAP. My own website uses Ufront.
In the past I was heavy into Flash/AS3 and I wanted to keep using that skill set, plus I’m a big fan of modularity and well-organised code. So Haxe was a natural fit for me.
Yes I’d be willing to appear in a video.
I develop casino games targeting HTML. I find plain JS cumbersome for complex applications, and Haxe compiler is superior to TS in many ways (better type system, fast compile times, better performance of compiled code thanks to abstract types, inlining, etc).
I also like the ability to compile to native or WASM should the need arise in the future since the games can have a commercial lifespan of decades, and rewriting a large portfolio is very costly. At the moment we only target JS though, using HEAPS as platform abstraction.
how do you handle multi
screen resolution in HEAPS or did you use other technic ?
As many of Haxe users, I started using Haxe as a better version of ActionScript 2.0 back in the day.
Now I use Haxe for 2D games using a framework called OpenFL.
Haxe is now my replacement for Flash’s ActionScript 3.0:
- Full support of mobile and desktop targets as well as HTML5
- Extremely fast performance on any target
- Great to make games OR apps
- Very flexible and mature language
Reasons not to use Haxe:
- You will not have as many job opportunities as you would with C++ or C#
- There isn’t a 3D game engine that would be able to compete with Unity3d, let alone Unreal Engine
- Harder to find developers to help you on a larger project, because there aren’t that many people using Haxe
That’s all my opinion, I might be wrong.
The nice part of Haxe is that you can write code almost for any third-party software, like Unity3D or UE.
Example: GitHub - proletariatgames/unreal.hx: Unreal.hx: Haxe Integration for Unreal
I’ll add that the “there isn’t a 3D engine” is true of 99.99% of the languages, considering the small number of engines that can match thoses.
But few languages have target that can be used with these engines.
So if you compare haxe to something else than c++ or c# that’s actually a reason to use haxe.
We do make somewhat responsive layouts to make things look good on different screens, and can load different assets depending on device.
That is not built in to heaps, but that is not really the case with other framework I tried either, so we have custom solutions for that. Layout and core loading functionality is part of this lib I’m currently working on: GitHub - HacksawStudios/GASM: Framework agnostic EntityComponent System for Haxe
Yes, but there’s very little reason to use it in real production. C# and Haxe a very similar, you might as well use C# from the beginning and escape:
- Spending days trying to bridge the interfaces of Haxe-TargetEngine
- Not having to work properly with the Unity3d editor
- Having to re-write chunks of your work if the target engine ever changes and you need some of the new features
and so on. It’s a great little experiment and shows how powerful Haxe can be, but you really can’t expect a business to use that as a solution.
Yea, true, but why would I write about Perl, PHP or other of the 99.99% languages when talking about Haxe? The thing is - there’s no mature, publicly available 3d engine that would compete with Unity3d, Unreal Engine, Cry Engine etc. The fact that other languages might also not have it doesn’t make it easier for Haxe users who’d like to make a 3d game.
I basically found this to be true for my projects:
Pure 2d game - Haxe + OpenFL are the way to go.
Partially 3d or full 3d games (small to mid size) - Unity3d
Serious 3d games that rely on high-quality lighting - Unreal Engine.
I’m not saying everyone should follow my train of thought, but I’ve worked on small and large titles and I found this to be true for myself.
One thing that Haxe ALWAYS seems to have an advantage for is making tools, editors and content management apps for my games - works on any platform, really fast to create.
One solution that I use is to create a Layout class (it’s my own solution) that would receive an Event from the global onResize listener. Then the layout’s own
onResize() method would be triggered. In that function I would resize, re-position and do whatever else I need for my layout.
I found it pretty handy to separate the Layout from the functionality of the UI elements.
Indeed, we do our UI as a separate HTML/CSS overlay, which not only makes it easier to handle responsive and device specific layout, but also forces us to decouple it from the game code. That means we are able to plug in various integrations or modules without modifying game code simply by hooking in to the pubsub buss with all events between games and UI.
We just launched a new website which you can find here: www.hotspot3d.com. The entire site is built with Haxe