4 ms·

I want to talk about Haxe. Haxe is a small niche language. But I almost fell out of my chair when I saw the showcase of games written with Haxe. Quality indie g

I want to talk about Haxe. Haxe is a small niche language. But I almost fell out of my chair when I saw the showcase of games written with Haxe. Quality indie games I have played myself, like Dead Cells, and this level editor is another very polished example. Even things like Pokemon Sword and Shield. What's going on here? I need to learn me some Haxe. Are all of these using Kha - so called "SDL but super-charged"? Or are there even more great graphics libraries for Haxe? (Also, I found LDtk on a four month old HN post less than three hours ago, and now it's front page. I'm not the one who submitted it. My connection to the hive mind must be a good one.)

skymt 5y ago
Dead Cells and a number of other high-quality commercial games are using Heaps: https://heaps.io/ https://heaps.io/ The Haxe website has links to some other popular frameworks like OpenFL and HaxeFlixel: https://haxe.org/use-cases/games/ https://haxe.org/use-cases/games/
- Buttons840 5y ago
  Thanks for bringing heaps and the others to my attention. I look at this list and suddenly 4 of the top 10 game engines I'd consider for a personal project are from the Haxe ecosystem.
542458 5y ago
From my limited experience, Haxe seems like a really neat language but good grief the documentation and learning resources are awful. It’s possible that I was going about it wrong, but there was very little by way of “here’s where everything is and how you’re supposed to do things” resources. I feel if that issue was better handled the language would see much more use than it currently does.
- k_ 5y ago
  Do you have concrete examples of things that are missing? We are aware that documentation is generally lacking, but it's not easy to see exactly how/where from inside. Would gladly contribute on such a list.
  - 542458 5y ago
    Sure! My thoughts, taking a quick second look at the Haxe website: * The core docs are split across three different sites: https://haxe.org/documentation/introduction https://haxe.org/documentation/introduction, https://haxe.org/manual/introduction.html https://haxe.org/manual/introduction.html and https://api.haxe.org/ https://api.haxe.org/. To a new user this is extremely confusing. * Let's say I go with the first of those. I go through the pages, which contain lots of useful information, but it doesn't actually tell me how to do what I want - which is presumably "make a game" given how Haxe is marketed. As a new user, I'd like to know how to use your library to make a game - say, pong or tic-tac-toe. If graphics/input/whatever isn't part of the standard library that's fine, but then your intro should tell me that and give me some suggestions where I can find those libraries and how to install them. Compare to the nodejs.dev or reactjs into tutorials, which immediately show you how to do the thing that many/most people will want to do (make a server, or make a dynamically-updating frontend respectively) * On that note, your package manager is VERY hidden! It's just labeled as "haxelib" (very non-descriptive) at the bottom of the "Learn Haxe" menu. * The other thing that the docs aren't really telling me is "what's the typical way to combine these ingredients"? How do people typically work with haxe.Resource-s, macros, MainLoops, etc? What are the common patterns? * Many of Haxe Standard Library docs pages are minimally populated. For example, MainLoop sounds important, but the docs tell me almost nothing. https://api.haxe.org/haxe/MainLoop.html https://api.haxe.org/haxe/MainLoop.html
    - user123456780 5y ago
      I completely agree with this. I went through the process of learning/attempting to learn haxe earlier in the year. (I was on a nostalgia 'I want to build flash games again' journey) There is lots of information. But not a lot of direction. I thought about writing some stuff on 'here is how to get started building a game'. But I started running out of steam when I hit some bugs with heaps and the newest version of haxe.
    - k_ 5y ago
      Thanks :) For the first point, yeah I agree, though I would still keep standard API documentation separated. And it gets "worse" when you add the 4th site: https://code.haxe.org https://code.haxe.org which helps with 4th point (partly?). Tricky thing with guides like "how to make a game" is that it's not a haxe-specific thing; it's a haxe framework specific thing which they handle on their own: https://haxeflixel.com/documentation/ https://haxeflixel.com/documentation/, https://heaps.io/documentation/home.html https://heaps.io/documentation/home.html, https://github.com/Kode/Kha/wiki https://github.com/Kode/Kha/wiki (is there a better link for kha?), etc. There are links in https://haxe.org/use-cases/games/ https://haxe.org/use-cases/games/ but discoverability could likely be much better and include a generic "how to make a game" start point which points to either framework depending on your needs (2D/3D, mobile/desktop/console/web, etc.). Indeed Haxelib isn't visible :x Now that you mention it, we had a few haxe newcomers that didn't know about it. We need to do something about that (even if it might get a replacement in the near-ish future https://github.com/HaxeFoundation/haxe/issues/9135 https://github.com/HaxeFoundation/haxe/issues/9135) Good point about std lib docs too! Some, maybe including MainLoop, are harder for community to document but we should ask help from core compiler devs.
- deleted 5y ago
  [deleted]
- megameter 5y ago
  Haxe is hard to document because its scope is large: "accommodate everything all these other languages do". So there isn't a one way of documenting it that will accommodate all users and workflows. It would help if you outlined what you need.
flxy 5y ago
As far as I can remember, Dead Cells specifically was made using Heaps[1], which the creator of Haxe himself made. Paper's Please uses OpenFL[2] instead. I'd say the Language has quite a few good libraries and frameworks to work with. The Haxe site itself lists a few others too [3] at the very bottom of the page. My advice would be to look at some sample code or documentation and see which one strikes you as either the most interesting or the most practical. [1] - https://heaps.io/ https://heaps.io/ [2] - https://www.openfl.org/ https://www.openfl.org/ [3] - https://haxe.org/use-cases/games/ https://haxe.org/use-cases/games/
koonsolo 5y ago
Haxe is awesome! I'm using that and Kha for my https://rpgplayground.com https://rpgplayground.com I think most games use Heaps, which is also written by the Haxe developer. Some other libraries such as OpenFL were ported from ActionScript to Haxe. (Basically Haxe took in a lot of Flash refugees :)). Definitely recommended technologies!
- chii 5y ago
  rpgplayground is pretty cool.
hawski 5y ago
Haxe is one of the very few languages in which a perfect cross-platform widget toolkit could be made. A toolkit that would produce platform-native binaries (no pesky FFI like JNI) using platform specific libraries: targeting Java (maybe even JVM?) for Android, targeting C# for Windows/the-current-Windows-toolkit, targeting Hashlink for Gnome/Gtk, targeting C++ for KDE/Qt, targeting C++ with Objective-C++ for MacOS/Cocoa and iOS/Cocoa Touch. Probably even a web target is viable. Other language, that it is possible to do with is Scheme, but it is quite a different beast all together. That's my little dream. I intend to do gobject-introspection bindings one day for it as my first step.
- japhib 5y ago
  The funny thing about a lot of these cross platform Haxe GUI applications is that they are actually made with Electron. I guess using Haxe means that you could also share libraries with your “real” game code that likely compiles to C++, which could be a big benefit. I just thought it was funny that LDtk could be written in JavaScript and be just as cross-platform as it is. Other examples of Haxe-Electron apps include the Ogmo level editor and the CastleDB editor.
  - tkp 5y ago
    Indeed, Electron is very useful for any compile-to-js language, and benefit from js popularity, toolkits and frameworks for rich UI. Writing in Haxe brings nice syntax, and some flexibility regarding target language/platform, and possible UI frameworks. - ArmoryPaint[1] and most Haxe games don't rely on Electron for UI. - HaxeUI[2] provide a nice list of components, rendered as composite or native on various backends[3] (html5, wxWidgets, experimental pdcurse..^^) - MVCoconut[4] also allow to bind to various front-ends : Dom, React, React-native There is always a degree of lock-in depending on the path you choose, but having a cross platform base for logic and glue is a nice feature. [1] https://armorpaint.org/ https://armorpaint.org/ [2] http://www.haxeui.org/ http://www.haxeui.org/ [3] https://github.com/haxeui/haxeui-core#backends https://github.com/haxeui/haxeui-core#backends [4] https://github.com/MVCoconut/ https://github.com/MVCoconut/
- k_ 5y ago
megameter 5y ago
Haxe is a great piece of technology on its own, and I am often working in it as a default, but I always caution potential users that it is more like a building block than a comprehensive package: if you want to do complex cross-platform things using Haxe, you will still want an full-time engineering team working with you to build out the full solution, since you will probably need to leverage the strengths and tooling of the target environments too. Haxe tries hard to get out of the way and give you the access you need, but builds and debugging always introduce challenges that depend on platform-specific behaviors. The quality of the results is more suggestive of the quality of the average Haxe user than the language itself doing anything magic(though it is a very sensible design). That said, you can make some great things just sticking within the available frameworks. OpenFL is good, as is Kha. HaxeUI is definitely worth checking out(it can use multiple backends). For editing tools there's still going to be a bias towards working with Electron because of the combined set of I/O features.
JoeyJoJoJr 5y ago
There aren’t many games using Kha, but I am using it for my game and think it’s absolutely awesome! I used to use the Flash display list, OpenFl, Heaps, but since learning React I have a developed a complete distain for the Object Oriented approaches for game development. Like the HTML canvas api, Kha allows me to build my own state structure, and then the visuals are just a functional expression of that structure. Combining this approach with Haxe’s extremely powerful Enum and pattern matching capabilities has been such an eye opening experience, and make it difficult for me to go back to just about any other language. Haxe is just so clean and well designed.

skymt 5y ago

Dead Cells and a number of other high-quality commercial games are using Heaps: https://heaps.io/ https://heaps.io/ The Haxe website has links to some other popular frameworks like OpenFL and HaxeFlixel: https://haxe.org/use-cases/games/ https://haxe.org/use-cases/games/

Buttons840 5y ago
Thanks for bringing heaps and the others to my attention. I look at this list and suddenly 4 of the top 10 game engines I'd consider for a personal project are from the Haxe ecosystem.

542458 5y ago

From my limited experience, Haxe seems like a really neat language but good grief the documentation and learning resources are awful. It’s possible that I was going about it wrong, but there was very little by way of “here’s where everything is and how you’re supposed to do things” resources. I feel if that issue was better handled the language would see much more use than it currently does.

k_ 5y ago
Do you have concrete examples of things that are missing? We are aware that documentation is generally lacking, but it's not easy to see exactly how/where from inside. Would gladly contribute on such a list.
- 542458 5y ago
  Sure! My thoughts, taking a quick second look at the Haxe website: * The core docs are split across three different sites: https://haxe.org/documentation/introduction https://haxe.org/documentation/introduction, https://haxe.org/manual/introduction.html https://haxe.org/manual/introduction.html and https://api.haxe.org/ https://api.haxe.org/. To a new user this is extremely confusing. * Let's say I go with the first of those. I go through the pages, which contain lots of useful information, but it doesn't actually tell me how to do what I want - which is presumably "make a game" given how Haxe is marketed. As a new user, I'd like to know how to use your library to make a game - say, pong or tic-tac-toe. If graphics/input/whatever isn't part of the standard library that's fine, but then your intro should tell me that and give me some suggestions where I can find those libraries and how to install them. Compare to the nodejs.dev or reactjs into tutorials, which immediately show you how to do the thing that many/most people will want to do (make a server, or make a dynamically-updating frontend respectively) * On that note, your package manager is VERY hidden! It's just labeled as "haxelib" (very non-descriptive) at the bottom of the "Learn Haxe" menu. * The other thing that the docs aren't really telling me is "what's the typical way to combine these ingredients"? How do people typically work with haxe.Resource-s, macros, MainLoops, etc? What are the common patterns? * Many of Haxe Standard Library docs pages are minimally populated. For example, MainLoop sounds important, but the docs tell me almost nothing. https://api.haxe.org/haxe/MainLoop.html https://api.haxe.org/haxe/MainLoop.html
  - user123456780 5y ago
    I completely agree with this. I went through the process of learning/attempting to learn haxe earlier in the year. (I was on a nostalgia 'I want to build flash games again' journey) There is lots of information. But not a lot of direction. I thought about writing some stuff on 'here is how to get started building a game'. But I started running out of steam when I hit some bugs with heaps and the newest version of haxe.
  - k_ 5y ago
    Thanks :) For the first point, yeah I agree, though I would still keep standard API documentation separated. And it gets "worse" when you add the 4th site: https://code.haxe.org https://code.haxe.org which helps with 4th point (partly?). Tricky thing with guides like "how to make a game" is that it's not a haxe-specific thing; it's a haxe framework specific thing which they handle on their own: https://haxeflixel.com/documentation/ https://haxeflixel.com/documentation/, https://heaps.io/documentation/home.html https://heaps.io/documentation/home.html, https://github.com/Kode/Kha/wiki https://github.com/Kode/Kha/wiki (is there a better link for kha?), etc. There are links in https://haxe.org/use-cases/games/ https://haxe.org/use-cases/games/ but discoverability could likely be much better and include a generic "how to make a game" start point which points to either framework depending on your needs (2D/3D, mobile/desktop/console/web, etc.). Indeed Haxelib isn't visible :x Now that you mention it, we had a few haxe newcomers that didn't know about it. We need to do something about that (even if it might get a replacement in the near-ish future https://github.com/HaxeFoundation/haxe/issues/9135 https://github.com/HaxeFoundation/haxe/issues/9135) Good point about std lib docs too! Some, maybe including MainLoop, are harder for community to document but we should ask help from core compiler devs.
deleted 5y ago
[deleted]
megameter 5y ago
Haxe is hard to document because its scope is large: "accommodate everything all these other languages do". So there isn't a one way of documenting it that will accommodate all users and workflows. It would help if you outlined what you need.

flxy 5y ago

As far as I can remember, Dead Cells specifically was made using Heaps[1], which the creator of Haxe himself made. Paper's Please uses OpenFL[2] instead. I'd say the Language has quite a few good libraries and frameworks to work with. The Haxe site itself lists a few others too [3] at the very bottom of the page. My advice would be to look at some sample code or documentation and see which one strikes you as either the most interesting or the most practical. [1] - https://heaps.io/ https://heaps.io/ [2] - https://www.openfl.org/ https://www.openfl.org/ [3] - https://haxe.org/use-cases/games/ https://haxe.org/use-cases/games/

koonsolo 5y ago

Haxe is awesome! I'm using that and Kha for my https://rpgplayground.com https://rpgplayground.com I think most games use Heaps, which is also written by the Haxe developer. Some other libraries such as OpenFL were ported from ActionScript to Haxe. (Basically Haxe took in a lot of Flash refugees :)). Definitely recommended technologies!

chii 5y ago
rpgplayground is pretty cool.

hawski 5y ago

Haxe is one of the very few languages in which a perfect cross-platform widget toolkit could be made. A toolkit that would produce platform-native binaries (no pesky FFI like JNI) using platform specific libraries: targeting Java (maybe even JVM?) for Android, targeting C# for Windows/the-current-Windows-toolkit, targeting Hashlink for Gnome/Gtk, targeting C++ for KDE/Qt, targeting C++ with Objective-C++ for MacOS/Cocoa and iOS/Cocoa Touch. Probably even a web target is viable. Other language, that it is possible to do with is Scheme, but it is quite a different beast all together. That's my little dream. I intend to do gobject-introspection bindings one day for it as my first step.

japhib 5y ago
The funny thing about a lot of these cross platform Haxe GUI applications is that they are actually made with Electron. I guess using Haxe means that you could also share libraries with your “real” game code that likely compiles to C++, which could be a big benefit. I just thought it was funny that LDtk could be written in JavaScript and be just as cross-platform as it is. Other examples of Haxe-Electron apps include the Ogmo level editor and the CastleDB editor.
- tkp 5y ago
  Indeed, Electron is very useful for any compile-to-js language, and benefit from js popularity, toolkits and frameworks for rich UI. Writing in Haxe brings nice syntax, and some flexibility regarding target language/platform, and possible UI frameworks. - ArmoryPaint[1] and most Haxe games don't rely on Electron for UI. - HaxeUI[2] provide a nice list of components, rendered as composite or native on various backends[3] (html5, wxWidgets, experimental pdcurse..^^) - MVCoconut[4] also allow to bind to various front-ends : Dom, React, React-native There is always a degree of lock-in depending on the path you choose, but having a cross platform base for logic and glue is a nice feature. [1] https://armorpaint.org/ https://armorpaint.org/ [2] http://www.haxeui.org/ http://www.haxeui.org/ [3] https://github.com/haxeui/haxeui-core#backends https://github.com/haxeui/haxeui-core#backends [4] https://github.com/MVCoconut/ https://github.com/MVCoconut/
k_ 5y ago

megameter 5y ago

Haxe is a great piece of technology on its own, and I am often working in it as a default, but I always caution potential users that it is more like a building block than a comprehensive package: if you want to do complex cross-platform things using Haxe, you will still want an full-time engineering team working with you to build out the full solution, since you will probably need to leverage the strengths and tooling of the target environments too. Haxe tries hard to get out of the way and give you the access you need, but builds and debugging always introduce challenges that depend on platform-specific behaviors. The quality of the results is more suggestive of the quality of the average Haxe user than the language itself doing anything magic(though it is a very sensible design). That said, you can make some great things just sticking within the available frameworks. OpenFL is good, as is Kha. HaxeUI is definitely worth checking out(it can use multiple backends). For editing tools there's still going to be a bias towards working with Electron because of the combined set of I/O features.

JoeyJoJoJr 5y ago

There aren’t many games using Kha, but I am using it for my game and think it’s absolutely awesome! I used to use the Flash display list, OpenFl, Heaps, but since learning React I have a developed a complete distain for the Object Oriented approaches for game development. Like the HTML canvas api, Kha allows me to build my own state structure, and then the visuals are just a functional expression of that structure. Combining this approach with Haxe’s extremely powerful Enum and pattern matching capabilities has been such an eye opening experience, and make it difficult for me to go back to just about any other language. Haxe is just so clean and well designed.